Only just noticed this, coming back to the subject after a hiatus (building a house!).
Sorry for reanimating an old thread - it seems the most appropriate way.
I do appreciate the commercial constraints imposed by open source. I presume nobody has any objection to me selling the Barionet firmware itself, although I may just open source it in case anyone's interested (Currently it isn't LinuxMCE-specific in any way).
I suspect I'm not the only one thinking "I really enjoy this stuff. How can I make a living at it?"
Kudos of course to totallymaxed (and anyone else) who has already achieved this!
I have the Barionet supporting control algorithms, schedules and scenarios in a self-contained way.
The interface is currently HTML, and I am starting to approach the DCE interface part of the problem. Two approaches occur to me, and Id welcome any thoughts on the relative merits...
- Write a plug-in that runs on the Core, and interprets DCE messages into HTML exchanges
- Write DCE support on the Barionet itself
...I realise the latter is the obvious response, but the sheer variety of DCE messages the Barionet needs to support, and the fact that I will need to write this support in BCL (primitive Basic variant) leans me towards the former.
Also, looking at the lighting plug-in, I will have to do some similar querying of database tables to fetch things like lighting scenarios. I'm assuming that it is relatively straightforward for a plug-in to be a proxy for messages intended for multiple Barionets (or actually for lights controlled by Barionets that can have no DCE support). The same thing goes for climate and other scenarios, I assume.
At the moment, with an HTML front-end, it's a breeze to do integration/soak/stress tests. I'm not sure how easy it would be if program size constraints mean that DCE has to be the only interface!
All thoughts, comments, WTF's gratefully received