The # subscriber

In a recent comment on my new ideas to make my Domotica system more flexible, the term broker was mentioned. ZeroMQ doesn’t have one, Mosquitto, for instance, does. But do I really need a broker? I don’t think so; I think I can very well live without one. In fact, what’s the point of a broker when there will be a part of the automation system that will need to do a # subscription.

This subscribe-to-all entity is in fact the heart of the system, the brains, the glue to it all; the part of the system that does the real automation part.

Automation is actually based on events/scenarios; if all conditions for a specific event are met, the event fires and a series of actions are performed/executed. Some examples:

  1. There’s an incoming phone call which results in lowering the AV receiver volume level in the livingroom. Once the phone call has ended, the AV receiver goes back to its previous volume level. (these are actually 2 events)
  2. The garage door is being opened and a light bulb is switched on. When the door closes again, the light bulb is switched off again. (ditto)

These are 2 very simple examples that everyone can understand.
But the phone line can’t publish anything by itself, nor can the AV receiver subscribe to anything all by itself. For that, a driver, interface or plugin (pick your favorite) would be needed – a piece of software that can monitor one or more phone lines, control one or more AV receivers or switch one or more light bulbs on/off.

First thing I want to accomplish is removing all the interfaces to the hardware (the drivers) from the core application, cause those are the most error-prone; reconstructing incomplete/fragmented frames, faulty data (RF!), bad connections, misbehaving hardware and stuff like that is what’s causing the most problems. So for the sake of stability it would be best to start there. Each hardware interface (driver) will eventually become a stand-alone process, taking care of communicating with the sensors and actors belonging to that specific driver. The PLCBUS will handle all of my PLCBUS modules, the IRTRANS driver enables me to communicate with all the IR controlled devices in range of the IRTRANS transmitter, and so forth. Hardware specific code is nicely tucked away inside the driver, just like it should; for example, the mandatory 400 ms. delay between 2 consecutive (RF) Roller shutter commands is taken care of inside the driver; nothing else knows this delay is needed. This construction makes that it is the driver that does the publishing, not the device. 

Inside the System process every physical piece of hardware (temperature sensor, motion sensor, light actor, TV, AV receiver) is represented by an instance of a specific object class. To make these devices really come alive, they will need to receive the information from their physical counterparts; so all drivers will need to publish to the System process. Or better: the System process needs to subscribe to all the drivers; right?

OK, back to events (or scenarios) again.

Now it’s time for an Event that’s a bit more complicated; ‘house power save mode’. I’ve made a first attempt with this some weeks ago. Goal is to determine whether energy consuming devices can be turned off (or in standby) since there’s no one around anyway: PC’s, laptop, lights, garage door openers, AV equipment, you name it. I’m not going to bore you with the issues that arise once you start with this, but believe me when I say that it can be really hard to determine whether everybody’s out the door or there’s still somebody laying on the couch watching TV – you need every possible input you can get.

Likewise, the devices that will be turned off to save power are handled by various drivers – PLCBUS or X10 for lighting, TCP/IP for networked devices, Infrared or any other hardware specific driver. Should the TV device subscribe to dozens of publishers so it can decide for itself when it’s time to go into power save mode? Just like the laptop(s), lights etc.? BTW, the TV also needs to locally store status information about all the sensors it uses to be able to make the ‘I can turn myself off now’-decision just like the the laptop has to do (for itself); and the light bulbs, and so on..

The effect of the last example is in fact the same as the 2 I gave at the start of this post (something happens automatically), but the numbers are bigger and suddenly direct pub/sub between devices doesn’t sound that appealing anymore – in my opinion, event handling is a typical task that performs best when a single event handler instance takes care of all the events, no matter the complexity. Devices don’t interact directly – a ‘higher power’ is needed for that- at least for how my domotica system works right now.

And this makes me believe I don’t need a broker – I will need some kind of self-made broker anyway, with events acting as some sort of advanced routing rules…

Tagged . Bookmark the permalink.

2 Responses to The # subscriber

  1. Carlos I. Macias says:

    i have a project where i am using a Rs 485 RTS somfy transmitter, i need your help, is there a way to send you an email, regards

Leave a Reply

Your email address will not be published. Required fields are marked *