Extending hah
Hi ,
I'm looking at extending hah to support Comfort (Security/Automation System). I have successfully got the xap-comfort service running and would now like to integrate this into new web pages served by klone. I'd like to be able to set/get alarm status, get/set inputs, set X.10 etc.
With the exiting architecture, what is the best way of talking to other xap processes from klone? It seems the registry is used for this purpose today? I'm not aware that any of the existing pages directly display xap msgs? If this is done today, please point me in the right direction!
Finally, thanks go out to the developer(s) to such a fantastically well documented and architected system.
Cheers,
steve
Steve,
Great to have another pair of 'code' hands adding to the HAH project!
I'm thinking that the Lua route would be the ideal way to allow klone to be extensible. The Lua piece already has the xAP message cache facility and the language itself is very capable for most all tasks. Of course, any such extension isn't a trivial piece of work.
Brett is firmly 'the man' on this front.
Derek
I've started work on a new xAP support library
Steve,
The webserver is completely decoupled from all the xap daemon. If you want to see how the webserver talks to an xap-* process examine the xap-livebox (server.c) and the automation.kl1 code.
The webserver is stateless so to populate a webpage with data it makes a socket() call to the daemon directly using a non-xap protocol. This isn't well defined and I just made something up that probably isn't suitable in the generic sense.
I pondered whether this was the *right* thing to do when I wrote the code. The alternative was that the webserver would need to have some sort of XAP packet cache but that would mean running thread to gather this data and I didn't like this alternative either. Best it does nothing when not serving web pages i thought.
I have also thought briefly about how to "open up" the klone web server so that it could be made extensible without having to compile up C code. Perhaps using LUA as its already on the system might be the key.
The architecture is pretty clean for the most part. Every process is seperated from each other using xAP as the transport. The HUB providing the GLUE. Xap processes fall into two categories CONSUMERS and PRODUCERS. Keeping this in mind means that you can wire pieces up using the PLUGBOARD to suit the environment giving you N*N combinations (plus logic). This is alluded to on the plugboard wiki page its a very nice architectural separation.
If you need any help understanding how things are structured code wise let me know and I can fill in the gaps.
Brett