Difference between revisions of "XMPPHWFS"
(→Sample session: sending commands does not require XML... updated after playing with jabberbot-python) |
(modification after corecore's PUBSUB suggestion) |
||
Line 3: | Line 3: | ||
Under the barbarian name of XMPPHWFS stands the following idea: | Under the barbarian name of XMPPHWFS stands the following idea: | ||
− | '''hardware IOs made available on a fuse filesystem through | + | '''hardware IOs made available''' (on a fuse filesystem) '''through xmpp messaging protocol'''. The latest idea is to use fuse only as on option, so the name will definitely change a bit. ''locmon2'' seems like a good candidate to me. |
− | and | + | XMPPHWFS is meant to replace [http://david.lutolf.net/dt/locmon locmon], which in my opinion was a good idea but is too buggy and impractical. from a recent copy of ''20 minutes'', it seems the industry is also heading towards something alike, only for home robots and social networking. WTF, tell me why your vacuum cleaner should tell all your facebook friends there's a plant in its way. |
− | + | [[Image:Xmpphwfs arch.svg|thumb|XMPPHWFS architecture]] | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | |||
− | |||
− | |||
* Debugging new hardware is simply done through communication with a human client. | * Debugging new hardware is simply done through communication with a human client. | ||
− | + | * ''corecode'' suggest to use the [http://xmpp.org/extensions/xep-0060.html PubSub] [http://jabber.org/protocols/pubsub mechanism] for event notification, I think he's bloody right on this. | |
− | [ | + | * GUI can also be implemented as a bot (ctrl_bot?). Simple and clean. Use a of cache DB is a good idea to minimize traffic and load on HALs. For the interface, I'd suggest HTML with Ajax. Help is needed here. |
− | + | * some other bot (log_bot?) can generate [http://oss.oetiker.ch/mrtg/MRTG graphs] and update the cache database on the same occasion. MRTG config can of course be generated automatically and graphs included in the GUI. | |
− | + | * The Fuse inteface, if needed, should also be implemented as a bot. Simply specify where to mount the filesystem, connect your bot, you're done. No need to have a modified jabberd. Any interface of this type should not talk directly to HALs, but communicate with a bot (ctrl_bot?) that has access to the cache database. | |
it was suggested to use IRC for communication, but device description is be greatly improved through use of XML and XMPP is just that. | it was suggested to use IRC for communication, but device description is be greatly improved through use of XML and XMPP is just that. |
Revision as of 08:11, 12 January 2012
Under the barbarian name of XMPPHWFS stands the following idea:
hardware IOs made available (on a fuse filesystem) through xmpp messaging protocol. The latest idea is to use fuse only as on option, so the name will definitely change a bit. locmon2 seems like a good candidate to me.
XMPPHWFS is meant to replace locmon, which in my opinion was a good idea but is too buggy and impractical. from a recent copy of 20 minutes, it seems the industry is also heading towards something alike, only for home robots and social networking. WTF, tell me why your vacuum cleaner should tell all your facebook friends there's a plant in its way.
- Debugging new hardware is simply done through communication with a human client.
- corecode suggest to use the PubSub mechanism for event notification, I think he's bloody right on this.
- GUI can also be implemented as a bot (ctrl_bot?). Simple and clean. Use a of cache DB is a good idea to minimize traffic and load on HALs. For the interface, I'd suggest HTML with Ajax. Help is needed here.
- some other bot (log_bot?) can generate graphs and update the cache database on the same occasion. MRTG config can of course be generated automatically and graphs included in the GUI.
- The Fuse inteface, if needed, should also be implemented as a bot. Simply specify where to mount the filesystem, connect your bot, you're done. No need to have a modified jabberd. Any interface of this type should not talk directly to HALs, but communicate with a bot (ctrl_bot?) that has access to the cache database.
it was suggested to use IRC for communication, but device description is be greatly improved through use of XML and XMPP is just that.
Device description
Since XMPPWHFS is aimed towards real-world I/Os, for each variable we need info such as:
- variable name
- ro/rw flag
- unit (meters, seconds, °C..)
- update delay in seconds
- last update timestamp
- variable type and allowed values (int, float, enum..)
- I/O type (door, temperature, humidity...)
- location (GPS coordinates and/or description)
- text/blob, possibly containing icon
- min/max trigger values
Sample session
- To HAL
- This is to get the simple, human-readable output
help
- From HAL
rfid_reader: last RFID tag read door_lock: status of door lock lock_delay: how long should the door stay open temperature: tell me how cold it is outside
- To HAL
- Here, it should be a good thing to have flags such as force_update if bot supports it.
describe
- From HAL
- I suppose it would be nice to include output from the help command above. XML validity needs to be checked anyway. Too many line breaks are added on purpose for readability on the wiki.
<hal name='HalName' target='event_main' backup_target='event_backup'> <description>This device is a sample that does many things and actually nothing</description> <location lat='47°00N' long='8°00E' elevation=495>Main door of building on route de Genève</location> <devices> <device name='rfid_reader' attrs='ro' type='rfid' last_update_timestamp=1326310608 value='00EFC0B554' /> <device name='door_lock' attrs='rw' type='enum'> <value>open</value> <value selected="selected">closed</value> <value>locked</value> <value>unlocked</value> </device> <device name='lock_delay' attrs='rw' type='int' last_update_timestamp=1326310915 value=4 unit='s' /> <device name='temperature' attrs='ro' type='float' last_update_timestamp=1326312490 value=23.5 unit='°C' alarm_high=28.0 warn_low=12.0/> </devices> </hal>
- To HAL
temperature
- From HAL
<device name='temperature' value=23.5 />
- To HAL
door_lock unlocked
- From HAL
<device name='door_lock' value='unlocked' />
- To HAL
door_lock foobar
- From HAL
- format needs to be thought a little better here..
<device name='door_lock' value='open' />error: new value out of range</device>
Discussion must be done around where the values should go in the XML, and if the whole device XML string should be sent back when requesting a single value. I say it should, as it simplifies the code (and let's not care too much about the overhead)
Events
When an event is detected by a HAL (threshold exceeded for example), the HAL sends the info to event-master who will then decide what to do. In this case, the syntax does not much, so we get something like:
<device name='temperature' value=11.8>warn_low_value</device>
Hardware
to make XMPPHWFS as useful as possible, some hardware should be designed and the necessary firmware written
Software extensions
- communicate with Asterisk to send voice commands
- have some fun with XMMS2 / MPD