Difference between revisions of "XMPPHWFS"

From Fixme.ch
Jump to: navigation, search
m (added image for architecture)
(→‎Sample session: sending commands does not require XML... updated after playing with jabberbot-python)
Line 40: Line 40:
  
 
=== Sample session ===
 
=== Sample session ===
−
;To HAL:
+
;To HAL:This is to get the simple, human-readable output
−
Here, it should be a good thing to have flags such as ''update_all_values'', ''used_cached_values''
+
<pre>help</pre>
 +
;From HAL:
 
<pre>
 
<pre>
−
<describe />
+
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
 
</pre>
 
</pre>
−
;From HAL:
+
 
 +
;To HAL:Here, it should be a good thing to have flags such as ''force_update'' if bot supports it.
 +
<pre>
 +
describe
 +
</pre>
 +
;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.
 
<pre>
 
<pre>
 
<hal name='HalName' target='event_main' backup_target='event_backup'>
 
<hal name='HalName' target='event_main' backup_target='event_backup'>
Line 53: Line 62:
 
   <device  
 
   <device  
 
     name='rfid_reader'  
 
     name='rfid_reader'  
−
     attrs='ro' type='rfid'  
+
     attrs='ro'
 +
    type='rfid'  
 
     last_update_timestamp=1326310608  
 
     last_update_timestamp=1326310608  
 
     value='00EFC0B554' />
 
     value='00EFC0B554' />
Line 59: Line 69:
 
     name='door_lock'  
 
     name='door_lock'  
 
     attrs='rw'  
 
     attrs='rw'  
−
     type='enum'
+
     type='enum'>
−
  value='closed'>
+
 
   <value>open</value>
 
   <value>open</value>
−
   <value>closed</value>
+
   <value selected="selected">closed</value>
 
   <value>locked</value>
 
   <value>locked</value>
 
   <value>unlocked</value>
 
   <value>unlocked</value>
Line 85: Line 94:
 
</hal>
 
</hal>
 
</pre>
 
</pre>
 +
 
;To HAL:
 
;To HAL:
−
<pre>
+
<pre>temperature</pre>
−
<set device='door_lock' value='open' />
+
−
</pre>
+
 
;From HAL:
 
;From HAL:
−
<pre>
+
<pre><device name='temperature' value=23.5 /></pre>
−
<hal name='HalName'>
+
 
−
<devices>
+
−
  <device name='door_lock' value='open' />
+
−
</devices>
+
−
</hal>
+
−
</pre>
+
 
;To HAL:
 
;To HAL:
−
<pre>
+
<pre>door_lock unlocked</pre>
−
<get device='temperature' />
+
−
</pre>
+
 
;From HAL:
 
;From HAL:
−
<pre>
+
<pre><device name='door_lock' value='unlocked' /></pre>
−
<hal name='HalName'>
+
;To HAL:
−
<devices>
+
<pre>door_lock foobar</pre>
−
  <device name='temperature' value=23.5 />
+
;From HAL: format needs to be thought a little better here..
−
</devices>
+
<pre><device name='door_lock' value='open' />error: new value out of range</device></pre>
−
</hal>
+
 
−
</pre>
+
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:
 +
<pre><device name='temperature' value=11.8>warn_low_value</device></pre>
  
 
== Hardware ==
 
== Hardware ==

Revision as of 04:16, 12 January 2012


Under the barbarian name of XMPPHWFS stands the following idea:

hardware IOs made available on a fuse filesystem through xml messaging protocol

and imagine doing stuff like 

garage_temp = myHome/garage/temperature
garage_heat = myHome/heating/pump1

if (( $garage_temp < 2 ))
then
 echo 1 > $garage_heat
fi

the above example is crappy, because it would be better done with the event-driven interface that must be included. I propose sending all events to a bot, maybe event-master by default. This bot should then do what is needed with the event. For large systems, devices can communicate with specialized bots.

  • The Fuse inteface 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.
  • GUI can also be implementd as a bot. Simple and clean.
  • Debugging new hardware is simply done through communication with a human client.
XMPPHWFS architecture

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.

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
Retrieved from "https://fixme.ch/w/index.php?title=XMPPHWFS&oldid=1427"