Difference between revisions of "XMPPHWFS"

From Fixme.ch
Jump to: navigation, search
(→‎Device description)
 
(11 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
[[Category:Closed_Projects]]
 +
 
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 xml messaging protocol'''
+
'''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. ''locmon2'' seems like a good candidate to me.
  
−
and imagine doing stuff like
+
== Description ==
 +
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. Any suggestions are welcome, coding has not really started yet anyway.
  
−
garage_temp = myHome/garage/temperature
+
[[Image:Xmpphwfs arch.svg|thumb|XMPPHWFS architecture]]
−
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.
 
* 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. Some bot can catch these events and update the cache DB as well.
 +
* GUI can be implemented as a bot (ctrl_bot?). Simple and clean. Use of a cache DB is a good idea to minimize traffic and load on HALs. For the interface, I'd suggest HTML with Ajax with templates and possibility to include content like webcams and the such. Help is needed here.
 +
* some other bot (log_bot?) can generate [http://oss.oetiker.ch/mrtg/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 and the resulting filesystem can be mounted on any host. Any interface of this type (read: local interface, as opposed to html-based) should not talk directly to HALs, but communicate with a bot (ctrl_bot?) that has access to the cache database.
 +
* in case you ''really'' want to notify your friends through twitter, facebook or whatever else, create a bot and make it subscribe to particular events
  
−
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.
+
it was suggested to use IRC for communication, but device description is be greatly improved through use of XML and XMPP is just that. AFAIK, IRC does not have a PubSub mechanism.
  
−
it was suggested to use IRC for communication, but device description is be greatly improved through use of XML and XMPP is just that.
+
:I've been dreaming of a 3D GUI where you can walk around and interract  with the hardware in a natural fashion. Volunteers?
  
−
== Device description ==
+
=== Device description ===
−
Since XMPPWHFS is aimed towards real-world I/Os, for each variable we need info such as:
+
Since XMPPWHFS is aimed towards real-world I/Os, we need lots of useful info that must be made available by each HAL
 +
==== About the HAL ====
 +
* name
 +
* description
 +
* location (GPS coordinates and/or description)
 +
* icon? I think we don't really care about the HAL itself, it's just a way to conveniently group I/Os
 +
 
 +
==== About devices on each HAL ====
 
* variable name
 
* variable name
 +
* variable type and allowed values (int, float, enum..)
 +
* I/O type (lock, temperature, humidity...). a more or less standard list must be written
 
* ro/rw flag
 
* ro/rw flag
 
* unit (meters, seconds, °C..)
 
* unit (meters, seconds, °C..)
 
* update delay in seconds
 
* update delay in seconds
 
* last update timestamp
 
* last update timestamp
−
* variable type and allowed values (int, float, enum..)
+
* warn/alarm thresholds for event notification
−
* I/O type (door, temperature, humidity...)
+
* icon? maybe not necessary. one can be chosen from the I/O name or type.
−
* location (GPS coordinates and/or description)
+
 
−
* text/blob, possibly containing icon
+
==== Sample session ====
 +
;To HAL:This is to get the simple, human-readable output
 +
<pre>help</pre>
 +
;From HAL:
 +
<pre>
 +
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>
 +
 
 +
;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>
 +
<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>
 +
</pre>
 +
 
 +
;To HAL:
 +
<pre>temperature</pre>
 +
;From HAL:
 +
<pre><device name='temperature' value=23.5 /></pre>
 +
 
 +
;To HAL:
 +
<pre>door_lock unlocked</pre>
 +
;From HAL:
 +
<pre><device name='door_lock' value='unlocked' /></pre>
 +
;To HAL:
 +
<pre>door_lock foobar</pre>
 +
;From HAL: format needs to be thought a little better here..
 +
<pre><device name='door_lock' value='open' />error: new value out of range</device></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 with the Pub/Sub mechanism. other bots can subscribe to events, and then decide what to do.
 +
 
 +
we'll get something like: (suggestions welcome!)
 +
<pre><device name='temperature' value=11.8>warn_low_value</device></pre>
 +
 
 +
== Obstacle ==
 +
* lack of expertise and motivation to implement a client in a µC
 +
* weak programming skills
 +
 
 +
== Components ==
 +
=== Software ===
 +
Some things can can be handy:
 +
* [http://thp.io/2007/python-jabberbot/ JabberBot] in python
  
−
== Hardware ==
+
=== Hardware ===
 
to make XMPPHWFS as useful as possible, some hardware should be designed and the necessary firmware written
 
to make XMPPHWFS as useful as possible, some hardware should be designed and the necessary firmware written
 
* [[SuperCaptor]]
 
* [[SuperCaptor]]
 
* [[GPIO relay board]]
 
* [[GPIO relay board]]
  
−
== Software extensions ==
+
=== Software extensions ===
 
* communicate with Asterisk to send voice commands
 
* communicate with Asterisk to send voice commands
 
* have some fun with XMMS2 / MPD
 
* have some fun with XMMS2 / MPD
 +
 +
== Schedule ==
 +
=== as soon as possible ===
 +
* design a smart way to handle events (scripting/rules interface)
 +
* implement test HAL client/bot with Pub/Sub
 +
* implement event_master with Pub/Sub
 +
* implement ctrl_bot
 +
 +
=== when the above is done... ===
 +
* implement web interface on ctrl_bot
 +
* implement fs_bot
 +
* implement HAL bot on µC ([[SuperCaptor]]!!)
 +
 +
== Participant ==
 +
* [[User:Petaflot]]

Latest revision as of 15:04, 14 November 2019


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. locmon2 seems like a good candidate to me.

Description

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. Any suggestions are welcome, coding has not really started yet anyway.

XMPPHWFS architecture
  • 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. Some bot can catch these events and update the cache DB as well.
  • GUI can be implemented as a bot (ctrl_bot?). Simple and clean. Use of a cache DB is a good idea to minimize traffic and load on HALs. For the interface, I'd suggest HTML with Ajax with templates and possibility to include content like webcams and the such. Help is needed here.
  • some other bot (log_bot?) can generate 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 and the resulting filesystem can be mounted on any host. Any interface of this type (read: local interface, as opposed to html-based) should not talk directly to HALs, but communicate with a bot (ctrl_bot?) that has access to the cache database.
  • in case you really want to notify your friends through twitter, facebook or whatever else, create a bot and make it subscribe to particular events

it was suggested to use IRC for communication, but device description is be greatly improved through use of XML and XMPP is just that. AFAIK, IRC does not have a PubSub mechanism.

I've been dreaming of a 3D GUI where you can walk around and interract with the hardware in a natural fashion. Volunteers?

Device description

Since XMPPWHFS is aimed towards real-world I/Os, we need lots of useful info that must be made available by each HAL

About the HAL

  • name
  • description
  • location (GPS coordinates and/or description)
  • icon? I think we don't really care about the HAL itself, it's just a way to conveniently group I/Os

About devices on each HAL

  • variable name
  • variable type and allowed values (int, float, enum..)
  • I/O type (lock, temperature, humidity...). a more or less standard list must be written
  • ro/rw flag
  • unit (meters, seconds, °C..)
  • update delay in seconds
  • last update timestamp
  • warn/alarm thresholds for event notification
  • icon? maybe not necessary. one can be chosen from the I/O name or type.

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 with the Pub/Sub mechanism. other bots can subscribe to events, and then decide what to do.

we'll get something like: (suggestions welcome!) 

<device name='temperature' value=11.8>warn_low_value</device>

Obstacle

  • lack of expertise and motivation to implement a client in a µC
  • weak programming skills

Components

Software

Some things can can be handy:

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

Schedule

as soon as possible

  • design a smart way to handle events (scripting/rules interface)
  • implement test HAL client/bot with Pub/Sub
  • implement event_master with Pub/Sub
  • implement ctrl_bot

when the above is done...

  • implement web interface on ctrl_bot
  • implement fs_bot
  • implement HAL bot on µC (SuperCaptor!!)

Participant

Retrieved from "https://fixme.ch/w/index.php?title=XMPPHWFS&oldid=14392"