XMPPHWFS - Revision history

Rorist at 14:04, 14 November 2019

2019-11-14T14:04:36Z

Petaflot: fixed locmon link

2012-02-01T20:03:18Z

fixed locmon link

Petaflot: added project template and minor corrections

2012-02-01T20:01:24Z

added project template and minor corrections

Petaflot: /* Software */

2012-01-17T20:37:06Z

‎Software

Petaflot: social networking is still possible

2012-01-12T08:37:57Z

social networking is still possible

Petaflot at 08:09, 12 January 2012

2012-01-12T08:09:39Z

Petaflot: modification after corecore's PUBSUB suggestion

2012-01-12T07:11:37Z

modification after corecore's PUBSUB suggestion

Petaflot: /* Sample session */ sending commands does not require XML... updated after playing with jabberbot-python

2012-01-12T01:16:35Z

‎Sample session: sending commands does not require XML... updated after playing with jabberbot-python

Petaflot: added image for architecture

2012-01-11T21:55:01Z

added image for architecture

Petaflot: /* Sample session */ removed useless crap

2012-01-11T21:03:26Z

‎Sample session: removed useless crap

← Older revision		Revision as of 14:04, 14 November 2019
Line 1:		Line 1:
−	[[Category:~~Ongoing_Projects~~]]	+	[[Category:Closed_Projects]]

	Under the barbarian name of XMPPHWFS stands the following idea:		Under the barbarian name of XMPPHWFS stands the following idea:

@@ Line 6: / Line 6: @@
 == 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.
+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.
 [[Image:Xmpphwfs arch.svg|thumb|XMPPHWFS architecture]]

@@ Line 5: / Line 5: @@
 '''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.
 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.
@@ Line 20: / Line 21: @@
 :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, we need lots of useful info that must be made available by each HAL
-=== About the HAL ===
+==== About the HAL ====
 * name
 * description
@@ Line 28: / Line 29: @@
 * 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 ===
+==== About devices on each HAL ====
 * variable name
 * variable type and allowed values (int, float, enum..)
@@ Line 39: / Line 40: @@
 * icon? maybe not necessary. one can be chosen from the I/O name or type.
-=== Sample session ===
+==== Sample session ====
 ;To HAL:This is to get the simple, human-readable output
 <pre>help</pre>
@@ Line 112: / Line 113: @@
 === 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:
+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.
 <pre><device name='temperature' value=11.8>warn_low_value</device></pre>
-== Software ==
+== Obstacle ==
 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
 * [[SuperCaptor]]
 * [[GPIO relay board]]
-== Software extensions ==
+=== Software extensions ===
 * communicate with Asterisk to send voice commands
 * have some fun with XMMS2 / MPD

@@ Line 114: / Line 114: @@
 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 ==

@@ Line 14: / Line 14: @@
 * 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.
 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.

@@ Line 3: / Line 3: @@
 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.
+'''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.
-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.
+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.
 [[Image:Xmpphwfs arch.svg|thumb|XMPPHWFS architecture]]
 * 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.
+* ''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 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.
+* 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 graphs] and update the cache database on the same occasion. MRTG config can of course be generated automatically and graphs included in the GUI.
+* 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. 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.
+* 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.
-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. AFAIK, IRC does not have a PubSub mechanism.
 == 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
 * variable name
 * ro/rw flag
 * unit (meters, seconds, °C..)
 * update delay in seconds
 * 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
-* min/max trigger values
 === Sample session ===

@@ Line 40: / Line 40: @@
 === 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>
 <pre>
-<describe />
+rfid_reader: last RFID tag read
 </pre>
 ;From HAL:
 <pre>
 <hal name='HalName' target='event_main' backup_target='event_backup'>
@@ Line 53: / Line 62: @@
    <device
      name='rfid_reader'
-     attrs='ro' type='rfid'
+     attrs='ro'
      last_update_timestamp=1326310608
      value='00EFC0B554' />
@@ Line 59: / Line 69: @@
      name='door_lock'
      attrs='rw'
-     type='enum'
+     type='enum'>
-   value='closed'>
     <value>open</value>
-    <value>closed</value>
+    <value selected="selected">closed</value>
     <value>locked</value>
     <value>unlocked</value>
@@ Line 85: / Line 94: @@
 </hal>
 </pre>
 ;To HAL:
-<pre>
+<pre>temperature</pre>
-<set device='door_lock' value='open' />
 </pre>
 ;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:
-<pre>
+<pre>door_lock unlocked</pre>
-<get device='temperature' />
 </pre>
 ;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)
 == Hardware ==