Changes

Jump to: navigation, search

XMPPHWFS

510 bytes added, 08:24, 11 January 2012
/* Device description */
fi
the above example is crappy, because it would be better done with the event-driven interface that must be included. maybe fill an sql table and bots that read it? 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 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.
 
== 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
== Hardware ==
77
edits