This page last changed on Apr 23, 2009 by digitaldan.

Hey guys, I wanted to discuss a few things here before I make a commitment to OR.  I have been doing HA stuff for a few years now and have a good idea of what has worked for me and what has not.  Over this period of time I have come up with an idea for what a HA system/hub should be. I just wanted to share what I envision for OR, and I'm hoping you can tell me if its similar or not to what you are thinking.
Bear with me for a minute
In this system you have a central message bus.  Attached to this bus are  modules that listen for events as well as send them out.
 At its core are Device interface modules.  These  represent things like KNX, X10, and IR classes.  So you might create a KNXLightContoller class that sends lighting events onto the bus and also listens for lighting commands from other modules.  You would also have an IR interface class that may listen for commands on the bus and fire off the right IR command to a global cache unit or local ir dongle.
Another integral component on this message bus would be the rules engine.  This is where you would have the various business logic located.  Users would say "when TV on, turn Living room lights to 20%" .  Jboss Drools is an excellent candidate for this functionality (one of their early examples was a house and thermostat rules engine) .   The rules engine would be just another module on the bus, listening for messages and running its rules logic on every event.
Lastly, the  bus would have a database and web services module.  Events and device state changes (light on, tv off, etc..) would be recorded to a database.  The web services layer would provide access to this data for easy querying as well as provide a way to send commands onto the main message bus.  This is where our iPhone and Web based apps would connect to.
For me this represents the missing part of HA.  We all have hardware, but no central system that connects them together in a generic and programable way.  With a system like this, it would be trivial to add more devices to the bus.  Lets say I wanted a media system like XBMC, no problem I would add a new HTTP Rest based module that would broker commands to and from XBMC's rest interface to our message bus.  Same thing to add MythTV, boxee, you name it.
From what I can tell OR goals are much simpler then this.  It sounds like logic for things like KNX would not live on a central server, but rather on something like the iphone.  So the central server will not have a whole lot of intelligence?  What do others believe are the long term architecture goals of OR.  One reason this project has sparked my interest is it roots in Linux and Java, 2 of my favorite things   I want to be realistic about where I'm focusing my development efforts.  If your interested about what my hardware looks like, I compiled a list at http://digitaldan.com/about/my-home-automation-setup/.
Thanks!


Yikes, the formatting toally sucked and I can't edit it, let me try again!

Hey guys, I wanted to discuss a few things here before I make a commitment to OR.  I have been doing HA stuff for a few years now and have a good idea of what has worked for me and what has not.  Over this period of time I have come up with an idea for what a HA system/hub should be. I just wanted to share what I envision for OR, and I'm hoping you can tell me if its similar or not to what you are thinking.

Bear with me for a minute

In this system you have a central message bus.  Attached to this bus are  modules that listen for events as well as send them out.
 At its core are Device interface modules.  These  represent things like KNX, X10, and IR classes.  So you might create a KNXLightContoller class that sends lighting events onto the bus and also listens for lighting commands from other modules.  You would also have an IR interface class that may listen for commands on the bus and fire off the right IR command to a global cache unit or local ir dongle.

Another integral component on this message bus would be the rules engine.  This is where you would have the various business logic located.  Users would say "when TV on, turn Living room lights to 20%" .  Jboss Drools is an excellent candidate for this functionality (one of their early examples was a house and thermostat rules engine) The rules engine would be just another module on the bus, listening for messages and running its rules logic on every event.

Lastly, the  bus would have a database and web services module.  Events and device state changes (light on, tv off, etc..) would be recorded to a database.  The web services layer would provide access to this data for easy querying as well as provide a way to send commands onto the main message bus.  This is where our iPhone and Web based apps would connect to.

For me this represents the missing part of HA.  We all have hardware, but no central system that connects them together in a generic and programable way.  With a system like this, it would be trivial to add more devices to the bus.  Lets say I wanted a media system like XBMC, no problem I would add a new HTTP Rest based module that would broker commands to and from XBMC's rest interface to our message bus.  Same thing to add MythTV, boxee, you name it.
From what I can tell OR goals are much simpler then this.  It sounds like logic for things like KNX would not live on a central server, but rather on something like the iphone.  So the central server will not have a whole lot of intelligence?  What do others believe are the long term architecture goals of OR.  One reason this project has sparked my interest is it roots in Linux and Java, 2 of my favorite things   I want to be realistic about where I'm focusing my development efforts.  If your interested about what my hardware looks like, I compiled a list at http://digitaldan.com/about/my-home-automation-setup/.
Thanks!

Posted by digitaldan at Apr 23, 2009 06:50

Hi Dan,

I think we (and I think I can speak for Marc and Juha here too) certainly share your dream.

That said there is a lot to from where we are now (I got my stuff working last night and can now actally use my iPhone to control my TV, DVD, Settop box and Roku player!) with 1.0 supporting just a few parts of that dream.

As for KNX, we agree here too. This will be support through the controller. But we have a 'quick fix' right now, right here that works direct from the iPhone.

Your not the only one here (Neil Cherry comes to mind) that wants to see a system developed that is able to both control and truly automate the home. Simply making super universal remotes is not the goal of OR.

This is the reason why we're heavily investing in the modelling part, eventhoug there too right now you will only see the GUI modeller and not the building modeller yet. But it's exactly the vision of a truly open, pluggable controller with two way communication and process modelling that we want to realize.

It's a major effort, that's probably one of the reasons it hasn't really been done yet.

And it's a software effort more than anything. And I think that so far HA has all been about the hardware with the software being second or third. We _are_ software. This is a HA software project.

I'm driving people like Juha crazy with my ideas and demands and the pressure to put things in the roadmap. But luckily he doesn't budge and keeps things focussed on getting actual stuff out. So we all have to be patient and take it one step at a time. And of course contributions from people like you are invaluable to a project like this. Because it's about a dream that gives the drive and the experience that can get things done.

We can only do and know so much. We're all pretty new in this HA field. We can start the revolutioniA  because of being outsiders. But we cannot win and realize the dream without insiders like you!

So let's do it!

And on the technical part the only part I think that we haven't really covered in our 'future' roadmap is the database (recording) part. The other aspects are all in our vision for the future. Or like I jokingly said we're not done before the guy from www.bwired.nl can run his house on Opren Remote

Posted by jlvh at Apr 23, 2009 14:23

Hi Jean-Luc,

do you or Marc already have a Gira Home-Server? For KNX users this seems to be the ultimate device for logic, database recording and visualization. If your guys vision goes that far to say that the ORB can do what the Home-Server can do and more this would be the ultimate goal

Posted by mredeker at Apr 23, 2009 15:28

I think neither of us have a home server (other than me having an Open Remote server running since last night )

And Marc is building his new home, so I guess the goal is not to need another one there either. So we have to hurry.

As for KNX: I'm in the States so I'm focussing on the US products and what's out here. We have others focussing on the KNX stuff.

Posted by jlvh at Apr 23, 2009 16:18

Hi Marcus!

First off, I have a home automation server! It runs lots of services and it runs on a 1GHz/512M system. It runs my local DNS (yes I need one), DHCP, Samba, print sharing, NTP, SVN/CVS, mail, web and SSH in addition to HA. I have X10, Insteon and one ZWave amongst many other things. I also have a lot of IP devices!

Don't worry before these guys are done you'll be able to plugin many types of home automation products into OR (yes many). I don't have KNX nor do I think I can get it for the US. I have Insteon, X10 (ick but of course), Z-Wave and lots of little things that need customized modules. Yes someone will have to write these modules but I'm willing to step up to more than just a few.

My background with HA software has be Misterhouse but I feel that isn't the right direction and I find the lack of a properly defined API confusing. But there are a great number of lessons I learned from Misterhouse.

One is the need for a macro/user language. Some of the simple things can be handled by a GUI front end, but more complex things need to be written in a language that's easy to understand. I'm hoping that Groovy may be that language.

The other was that everything must play nice. If I write a script and I want Event X to turn on device A (a Lutron module), device B (an X10 module) and device C (a KNX module), the scripting for each had better be exactly the same in the scripting language and that I don't need to know the details of the protocols to make it work. Something like DeviceA = ON or DeviceA.set(ON). This and some standard objects and libraries (such as Expect) will simplify some things.

I also want to see things other than modules get used such as access to email, facebook, twitter, weather service, blah blah blah - I think you get the idea. See my definition of HA for further information of my view on things.

Basically everything gets integrate into the central server though we can handle off-loaded processing to remote devices and even other OpenRemote servers (a more advance topic for a later date).

One thing I really like is the management possibilities of OpenRemote. The one thing I've learned from other HA packages is that downtime is not a good thing. SAF (Spouse Acceptance Factor) drops when you need to shutdown the system to make updates. It looks like we can avoid that with OpenRemote, and if we can't, we will!

I'd say I'll have my hands full figuring some of this out.

Posted by linuxha at Apr 24, 2009 02:14

So Neil I just put together your the person behind linuha.com, well done sir!

I'm Glad there are similar goals around here, and I agree with you that the system needs to be be be generic enough that it can talk to an X10, UPB or KNX light in exactly the same way.

Right now however I'm itching to get something going around this hub concept.

So far I have been looking at two differnt ideas.  One is based around Apache ActiveMQ the other around xPL.  Apache has the benefit of broad adoption, clear documentation and a robust community.  Its downside is that there are no other HA projects using it, so everything would have to be built my self.  xPL has a nice java implementaion, templates that suppport every device I need and other projects have implemented support for devices (like slimplayer, tivo display,etc..).  The down side is that its complicated, not hugely supported and I would hate to make a commitment to a protocal that will not be around in the future.

I think I may spend my time building this type of routing engine unitl OR is ready to start building its own backend HA framework.  Is this of any interest to people here?  Also I know xPL/xAp was discussed when OR first launched, an comments on them now?

Finally, I would love feedback about the concept of basing a HA system around something like ActiveMQ (or its subproject Camel).

Posted by digitaldan at Apr 24, 2009 18:02

Re: using message bus to build server software

Generally a good idea. Introducing the bus (a.k.a mediator) decouples components in the system in a nice way. There are some caveats to this with regards to runtime type decoupling (related to Java classloading) but it does force component decoupling using an intermediate "command" abstraction.

We explored (and championed) such an architecture on Java middleware with a server called JBoss. You may have heard of it (I vaguely recall writing a book on the subject...).

Now, whether you want to use something like JMS as the base of your bus depends if you want the bus itself to be distributed. Another alternative is to create a local (to the VM) bus to decouple the local components and have specific services attached to the bus that handle distribution for messages directed at them.

Both approaches have been implemented n-times over, distributed bus in the form of JMS implementations, and local buses in the form of various "micro/nano/etc containers" (at least I think that's a term that covers a lot of them).

Which you choose depends on your tolerance of people screaming "Bloat!" at you (poke*Neil*poke) in the case of JMS and whether you want the people writing components to your bus have to understand the implications of distribution where necessary. Also hardware requirements will vary but if you're using a regular low-end PC as the server won't really matter. For reasons of high-availability and fault tolerance you will want the redundancy options good JMS implementations will offer.

HTH

Posted by juha at Apr 26, 2009 17:13

Replicating the functionality of something like Gira has come up before and I think is a useful milestone on the road to world domination

Posted by juha at Apr 26, 2009 17:19

> "So Neil I just put together your the person behind linuha.com, well done sir!"

Thanks Dan, I take a lot of pride in my site, now I just need to clean it up, it's gotten huge!

I'll take a took at ActiveMQ, I'm not familiar with it (I'm also not the chief architect on the project ). Right now I'm working on understanding JBoss and Java (I have a lot to relearn). As far as xPL (and XAP), just another module. At least in my understanding of things.

BTW, your rules engine will probably fall in line with my macro/scripting language thinking. I'm still leaning towards Groovy as the scripting language and I have very fancy ideas fro what I want to see. I want a web front end for those who want simple timers and event. The front end will write the code for the user. The next level is more complex user 'macros' that use object libraries (beans?) to handle more complex scenes. Then there is the full bore, write a new module, user. I want this all to be dynamic in that there is no reboot of the OR server and it has to be fault tolerant of user mistakes. This is quite a tall order. I need it to properly handle the insertion/deletion of modules and 'do the right thing' with the current states and variables. While this is ambitious I don't see why it can't be done.

I have other ideas which are just as ambitious but I won't go into them right now as they are so far into the future that it's not time to even consider them.

Posted by linuxha at Apr 27, 2009 01:25

Couldn't agree with you more.

I was looking at Groovy as well.  I have never had a reason to use it but this seems like a good one.  To me the rules engine is the most important part of such a system.  In home automation, rules are kinda everything.  I can control most things in my house today with my iPhone, but while that was cool in the beginning, its much more useful to have a centralized hub that can react to events from things like lights, security and my Boxee  without my intervention.    I would hope a centralized rules engine is one of the top focuses.

Of course, this is one of the harder parts as well.  I have been looking at traditional rules engines like those that implement  JSR 94 (java sun standard for rules engine implementation).   Heavyweight, very very heavyweight.  I'm not sure its the right way to go, I think it may be better to go our own route with a much simpler approach.

There are two parts of the equation with a rules engine, matching logic (if)  and the executed logic (then).  For both it would be nice to have a simple ajax page that allowed you to add a rule by selecting the attribute of a device model from a drop down with a conditional flag and value (if) and then finally something to do (then).

For example, if (Light->state == On) then ( Send IR command "ON" to stereo).  I was thinking there would be no programming at this point.

For more advanced users, the matching logic (if) and the command logic (then) could be be a user supplied script.  So I could still match with a simple drop down (Light->state == ON) but supply my own script to say what to do if matched.  Or I could supply a script for both the match and trigger.

I was also thinking that rules could be saved in your rules library, you could then add them to your main rules logic, or create rule groups which pull many rules together.  This rule group could then be added to the main rule logic.

Freeswitch (an IP PBX) has an amazing model for plugging in scripting languages.  They support Lua, Java, Javascript, Python, Ruby, C, C++, and probably a few I'm missing.  They use SWIG to generate the language specific interfaces from a very well defined C api.  If you have not checked out Freeswitch, I highly recommend it, I have been using it for about 4 months and it has just blown me away.   I have used both the Javascript and Java modules for application development.

We could take this approach, its extra work but means people could use Lua and Javascript which is already familiar to those with only a little  programming knowledge.  Groovy would be a great first start however.

Posted by digitaldan at Apr 27, 2009 02:30

Juha, I see two books, and Marc's name on one. Man this place has a lot of authors.

So far I'm impressed with what I've read with JBoss. It has all the stuff I've been screaming about. I have only done a few simple things such as create the 'Hello world' app and dropped that in and removed it. Cool, but not that impressive. I'm reading interesting things but I'm overwhelmed by all the code. I think sticking to the bus is a good idea. I really like what I'm reading about the management of the applications. I do managed networks for a living and want to see similar services for the home automation application.

In fact my wife just had a fit on me because I had to take the server offline (she lost printing but not local DNS). Taking the home automation off line is just as annoying.

Juha, I see two books, and Marc's name on one. Man this place has a lot of authors.

So far I'm impressed with what I've read with JBoss. It has all the stuff I've been screaming about. I have only done a few simple things such as create the 'Hello world' app and dropped that in and removed it. Cool, but not that impressive. I'm reading interesting things but I'm overwhelmed by all the code. I think sticking to the bus is a good idea. I really like what I'm reading about the management of the applications. I do managed networks for a living and want to see similar services for the home automation application.

In fact my wife just had a fit on me because I had to take the server offline (she lost printing but not local DNS). Taking the home automation off line is just as annoying.

Allow me to amend my bloat comment, I'll accept bloat if I get appropriate functionality. I've noticed that Java is an extremely verbose language to write in (do we have to deal with so many streams and buffers, argh!). And that the libraries depend on libraries that depend on libraries (this is a lot like Perl). I really do hate that. I am pleased that JBoss can be pared down.

One last thing, I am in no way Java fluent, I'm still trying to catch up with the terminology so if I make a mistake please let me know so I can get the terms corrected.

Posted by linuxha at Apr 27, 2009 02:41

I was thinking that the bus would be local to the VM in the beginning, but could expand to the network level later on.  I like the way a bus architecture makes you think.  It also follows the patterns that will be echoed throughout this project, sending events to and from nodes (devices).  It just seems natural to me.

The complication is a factor.  I was looking at xAP/xPL this weekend.   It was designed to be run not just on IP network layers, but on serial and even more basic types of channels.  It was also designed to be so generic that to implement a simple device requires quite a bit of boiler plate code.  I just didn't get a great feeling looking through their source code.

The advantage however is that they have a successful server hub written in Java as well as many devices that support the protocol.

Even though ApacheMQ is a little heavy, its fairly easy to implement and has a TON of projects to handle other languages if we needed to add native or non java specific applications.  This is a great discussion we should have on a dedicated thread after the first release of OR is complete.

Posted by digitaldan at Apr 27, 2009 02:57

And in case Juha didn't see this movie, it's from Hudson Hawk, a Bruce Willis movie. It's a bad movie full of terrible one liners but I love those kinds of movies.

Posted by linuxha at Apr 27, 2009 03:06

Allow me to amend my bloat comment, I'll accept bloat if I get appropriate functionality. I've noticed that Java is an extremely verbose language to write in (do we have to deal with so many streams and buffers, argh!). And that the libraries depend on libraries that depend on libraries (this is a lot like Perl). I really do hate that. I am pleased that JBoss can be pared down.

No worries, I am just teasing you with the "bloat" comment

We were actually discussing language bindings for plugin API last week, which would enable other languages to be used to create protocol handlers and such (while the core "bus" stays in Java).

Posted by juha at Apr 27, 2009 15:52

I always worry about bloat, I often program on boards with as little at 128b of ram. You have to tip-toe through meemory usage very carefully.

Cool, I was similarly thinking about the scripting side of the API. I think I'm going to limit it to just the Groovy engine. It wouldn't take much to use it with JPython or something else but until we have enough of a community to start tackling  the scripting one is quite enough.

Of course allowing the module writer to use what they want is a very good idea.

Posted by linuxha at Apr 28, 2009 01:49

I like Groovy because it's Java like, I hate Groovy because it isn't Java. The idea of completely having to switch languages between Java for the modules and something else like JPython (which would have been my next choice)   is a rather uncomfortable one. I already deal with too many languages and switching back and forth is not easy. Groovy is close enough 'for government work'.

 if(LRDeskLamp.is(ON)) {  Stereo.cmd(ON) }
This is what the code attached to the GUI would write and that would be Groovy code, or something similar. At the moment I think the Java folks are trying to scare me. I read that there is a known problem with Java and execute. Something to do with buffering system I/O and 1K. Another problem I heard about is Java not using PTYs. At the moment I'm not going to concern myself with these problems as I have other things to learn. I'll burn the bridges when I get on them. I'm pretty sure I'll be getting myself in over my head in no time with scripting.

I was then thinking that the code generated above could be used by users as a template to further expand their knowledge and of course advanced users can use any of the Java libraries by importing them. The hard part is getting a CLI to the scripting prompt to allow users to write Groovy script and debug it while OR is running. That's something for a far off distant future. There are many other problems to be solved first.

I'll take a look at Freeswitch to see how they deal with the scripting. I don't want to try and support every language as then you have too many different examples in too many languages. In my opinion it's better to have a single scripting language for the users, at least at first.

C & C++ scripting??? Are you sure that not the programming API?

I used Asterisk, loved it, very powerful. What I hated was the ATAs. The software echo cancellation couldn't handle the worst of the echo on the POTS line. The hardware units are just too expensive. I'll probably attack VoIP again at a later date. I have a chapter on VoIP in my book. Lost the chapter on integrating Misterhouse and Asterisk (which was probably a good thing as the book was 90 pages over budget without it).

I really don't want to see Javascript being used as the scripting language inside of OR. On the browser side that's fine but on the scripting side, use Groovy instead, it's much closer to Java and we can compile the code if we need to to speed things up to Java byte code speed (JPython can do that too).

Posted by linuxha at Apr 28, 2009 02:26

So I agree groovy is a good start, but the scripting languages you dislike are very comfortable for other people. I agree, Javascript seems like a poor substitute for something like Groovy, but a whole lot more people know JavaScript (or least they think they do . I would like to take advantage of Java 1.6's "Java scripting API" (JSR 223) so we can plug other language modules when needed (or the user can do it). If you have not checked out https://scripting.dev.java.net/ , it has a nice list of supported languages.

Freeswitch uses the concept of modules, I should have said you can write your logic in what ever language you want, scripting languages go through their respective language module, or you can write your own module through the native C library, everything still uses the same API structure. So there's a session object in the scripting languages just as in the C API (because the C API is being exposed via swig generated bindings). It's really powerful. JSR 223 is kinda similar, so we have this framework (and language implementations) already in place in the JVM (hey we're half way there !)

This also means the example code looks very similar across languages, so answering a call in freeswitch looks like

Lua: session:answer();

Javascript: session.answer();

Java: session.answer();

Python: session.answer()

Asterisk's major drawback for me was its messy configuration files and structure. I used it for awhile as a back to back sip user agent (b2bua) to proxy my sip traffic through my home NAT. Freeswitch uses XML, but in this case it actually works very very well (I'm not a fan of XML for config files). And its feature sets are impressive. I have replaced my home PBX with FS and plan on replacing a bunch of in house SIP media servers at work with it. I have been doing SIP/VOIP stuff for about 10 years and its definitely the most impressive IP PBX I have seen so far.

Posted by digitaldan at Apr 28, 2009 15:24

Hey Neil and Dan,

Sorry for jumping into the discussion late, had lots to do and didn't have time to really digest the points being made here.

Couple of quick takes on the many topics:

Rule Engine

  • I don't find it appealing to implement our own, no matter how simple. I'm seriously only considering Drools as the engine at this point.
  • Don't agree with the heavy-weight argument, at least when it comes to Drools. Granted, I've only used Drools very little on a prototype-level project but I do remember it was very easy to strip down if you just wanted programmatic API to create a working memory, load the rule definitions yourself and fire them.
  • However, when you do start adding all the stuff to a rule engine that Neil is dreaming about for his scripting (domain specific languages, web user interfaces, auto-completes, graph views) then it does get much bigger. But that is size coming from the UI, not the rule engine itself.
  • I do think rule engine is interesting because I have a feeling (just a hunch) that it will cover many cases people tend to address (or want to address) with object-level scripting.
  • Rule engine will be natural for event handling because it is declarative. The need of building complex if-then-else hierarchies with imperative scripting is removed so the likelihood of missing a branch for one particular event condition is reduced.
  • Rules would be pushing something new into the field, rather than another ho-hum scripting engine (don't freak out Neil, there's still room for scripting, see below). Rules could be a differentiator which makes it appealing.
  • Writing rules against a more high-level object model would be more appealing although I think at first pushing events around might be sufficient. Building higher level object model requires a bit more scaffolding (at least for one that wouldn't immediately suck) so I would opt to iterate there.

Scripting

I think it is useful to separate scripting for two purposes. One is the object-level scripting which does call for an object model (which IMO this project is in no hurry to define, but more on that later), the other one is the protocol level scripting of pushing bytes around on the wire.

The first case (object scripting) is the one with all the API talk in recent threads with Remote.PowerOn() calls and what-not. At the moment I put this into "that's nice but jumping the gun" category. Spending time designing this before all the other major pieces are in place is not a high priority in my book.

The second case (protocol scripting) is related to work that Marcus Redeker is doing right now, creating generic IP, HTTP, telnet events and being able to script the input/output (protocol level) to those protocols is actually a lot more relevant and important at this stage of the project, in my opinion. We haven't really started to address this either but it should come well before any object-level scripting.

The Object Model

The one that will cure all our ills (after a generous dose of vague hand-waving). I'm not sure how to put this shortly put I will try:

  • Yes it will be nice! </Borat>
  • I don't believe in up-front design
  • I think static models tend to be sub-optimal
  • There are some use cases where static model is ok (the common example brought up is lights on/off/dim)
  • There are cases where static model with lowest common denominator is clearly not going to cut it (look at all that A/V equipment, or anything with higher level access API beyond bit on/off)
  • It would be nice for rule definitions but not mandatory (in an event-based system you could push the events around)
  • It would be sort of pointless to have object-level scripting (but perfectly reasonable to have protocol scripting) without a model but then you can scrape by with scripting the events directly for quite some time (it's not as nice but it won't kill you)
  • The object model is not going to be of much use if other key pieces (the parts that actually do stuff) are not established first
  • Introducing a static model into middleware is a bad idea.

Just to add to the last point the counter-argument is that HA is a simple domain so why complicate things with a dynamic model? For the afore-mentioned exceptions of lights or shutters, it seems a valid argument (for example, KNX has already done the work, so why not use their model. And I agree with that).

For A/V interfaces, gateways (GC, IRtrans et al), devices with any higher level interface via serial or telnet, allowing arbitrary interfaces (rather than enforcing lowest common denominator which btw does not prevent anybody from creating one) sounds better to me. While it seems like leaving the work undone (where's my model?), it may be better than cramming a model nobody thinks does good enough a job down everyone's throat. It does leave the door open for iteration, useful models are free to emerge and we've done the same thing with middleware before and things seemed to work just fine. The trick was to keep things decoupled (the bus), abstract away the commands (the event) and keep static models out of the middleware.

But since the whole object model thing doesn't show up anywhere in the critical path at the moment, all that is subject to change.

Posted by juha at May 08, 2009 04:11

Brilliant!  Quite a display of calm, clear thinking, and force.

Completely agree that not typing the messages that float around our system seem like the way to go when the role of the ORB is only to route messages from buttons (which come from the device so embed the semantics of the target as is captured in beehive today).

Not imposing a semantic on the middle also seems like an easy way to create integration, look at what marcus has done: open sockets to connect processes and exchange strings with a pre-determined, vendor specific, structure. There are no mappings involved, just declaration of buttons that send a IR code or Text structure over RS.

Excellent passage on scripting and Rules engines. Marc Proctor and Drools have been doing pretty heavy stuff for years.  Automation would be an interesting case study.

ORB after all the ORB can be many things.  At first, I think installers will see it as a way to serve iphone interfaces, possibly customize large installs. They also will see it as a way to access remote installs. As juha pointed out, Gira Homeserver is a valid goal for us to emulate. We can do that and much better in little time I think.

Posted by marcf at May 08, 2009 10:35

First I'm too stupid/stuborn/without a clue, to give up on the scripting portion so I won't. The only thing I have determined so far is that I haven't a clue how to shoehorn it into/onto JBoss. But it won't stop me from trying as I need it for other automation anyway. (dang it where's the Big Evil Grin!). I would seriously be careful of my definitions of what is what. I don't know the proper terminology for what I want. I just know what I want. Besides much of that was intended to just be modules that are added on the OR. Stacking that all on top of the scripting makes everything scripting based and I don't see that working well (I think that's what you are trying to say too).

  • Rules would be pushing something new into the field, rather than another ho-hum scripting engine (don't freak out Neil, there's still room for scripting, see below). Rules could be a differentiator which makes it appealing.

I thought that rules based is pretty much part of the field, maybe my definition of a rules engine is different. What I do know is that for the fancier stuff I want the rules engine isn't enough. It may be appropriate that the scripting works in conjunction with everything else (that is it available but not necessary for it's operation) instead of playing traffic cop (that's JBoss's job right?).

BTW, I'm now more calm as I'm riding some 200+ miles per week and I tend to be a little calmer. So no more freaking out until winter when my miles drop.

The second case (protocol scripting) is related to work that Marcus Redeker is doing right now, creating generic IP, HTTP, telnet events and being able to script the input/output (protocol level) to those protocols is actually a lot more relevant and important at this stage of the project, in my opinion. We haven't really started to address this either but it should come well before any object-level scripting.

Ah, these are the things I've been calling libraries. In Perl they have CPAN. You write Perl modules, include them with your code and you do stuff like this (this is not Perl, it's Groovy):

import org.apache.commons.net.telnet.TelnetClient

telnet = new TelnetClient();

telnet.connect( 'rainmaker.wunderground.com', 3000 );

reader = telnet.inputStream.newReader();
writer = new PrintWriter(new OutputStreamWriter(telnet.outputStream),true);

readUntil( reader, "-- " );  // Press Return for menu
                             // or enter 3 letter forecast city code--
writer.println("TTN");       // "TTN = Trenton"

Ignore that this looks like scripting, it's Groovy and it's just a sample. I just got Groovy talking with the Weather Underground. The main point is that I didn't need to write the telnet portion I just used what was written for my weather reporting module. I can now use the telnet elsewhere for talking to my local weather station on my Linux server.

  • The object model is not going to be of much use if other key pieces (the parts that actually do stuff) are not established first

Okay the events model has my attention but I am confused (not surprising). You are absolutely correct that we need a structure to build around for anything to work. So despite my leanings I'm listening. I'm not a software architect (Network and hardware - yes).

Just to add to the last point the counter-argument is that HA is a simple domain so why complicate things with a dynamic model? For the afore-mentioned exceptions of lights or shutters, it seems a valid argument (for example, KNX has already done the work, so why not use their model. And I agree with that).

Single domain? What does that mean (I really don't know).

I'll leave the static portion alone we're nowhere near tackling the dynamic portion.

Posted by linuxha at May 09, 2009 01:24
Document generated by Confluence on Jun 05, 2016 09:30