embedded Ethernet control device support in LinuxMCE

[ajward]

Hi,

I'm proposing to use embedded Ethernet control devices to do much of the legwork in my home automation system. It isn't something that LinuxMCE seems to support, but I think it should: here's my reasoning...

It strikes me one of the limitations of LinuxMCE is that the Core runs on a single PC, and is by definition a single point of failure. If that PC has a brain fart at the wrong moment, the whole house in non-functional. Not acceptable, in my book.

Nevertheless, the idea of a central system integrating security, cameras, lighting control, multimedia entertainment etc. is seductive. That's why I'm persevering.

The Barionet is a small, DIN rail device that can be commanded over TCP/IP (including SNMP, MODBUS RTU & HTTP), and has local digital I/O, and support for 1-wire devices and RS232/RS485 connected slave devices (typically more MODBUS). It also has local intelligence, programmed in a variant of Basic (ho hum!).

For those of you who haven't heard of this kind of device, details are available here...

http://www.barix.com/Overview/781

There are other, similar devices, this one for example...

http://www.h2m8.com/products/product.php?type=5&detail=1&liststyle=mainlist

...but this is the most suitable I've found so far.

My plan is that things like heating and lighting control are configured and controlled from LinuxMCE, but most of the low-level functions (lighting scenes, heating control loops) are delegated to the Barionet devices.

I think I then get the best of both Worlds - central control, distributed intelligence: resilience.

I realise this is a fair amount of work, I'm just wondering what people think of my analysis, and my plans.

Thoughts?

Cheers,
Andy.

[Marie.O]

Andy,

welcome, and enjoy the work with this. If you understand the barionet, read all you can read about DCE messages in the wiki. You should come up with a working prototype fairly fast.

[merkur2k]

so what you are doing is to move the single point of failure from a pc to an external device?
i am not in any way trying to discourage you as i would love to see more network controllable devices as well, just make sure youre doing it for the right reasons.
its is very easy to make nearly every system in a pc redundant, so that reduces the chance of single point of failure. regular scheduled maintenance can reduce that even further.

[ajward]

so what you are doing is to move the single point of failure from a pc to an external device?
i am not in any way trying to discourage you as i would love to see more network controllable devices as well, just make sure youre doing it for the right reasons.
its is very easy to make nearly every system in a pc redundant, so that reduces the chance of single point of failure. regular scheduled maintenance can reduce that even further.

You miss the point...Since there are multiple Barionets handling different parts of the house, and they are intelligent enough to execute simple control loops and lighting scene control without intervention from the centre: there need be no single point of failure.

Also, the MTBF of a simple embedded processor is incredibly high compared with a PC. I have yet to see a motherboard that can't be crashed with a loose PCI connector or refuse to boot because the battery-backed RAM has failed prematurely.

PCs are too complicated to rely on for a whole house, IMHO. For example, I've just had to service a 2 year old mini-itx motherboard in a simple web server, because the CMOS RAM battery failed - if that was the LinuxMCE core, that would be the whole house down whatever clever redundancy I put in there.

Regular scheduled maintenance is exactly the sort of thing that should not be necessary for electronics used in home automation. Ultimately I plan to sell what I create here - how many people are going to be interested in a home automation system that requires the sort of maintenance schedule an IT data centre uses just to keep it running?

Surely the goal of home automation is to make a system that is as reliable and low-maintenance as a light-bulb: then it can go (more) mainstream and look like something other than a geek's pass time.

[bongowongo]

You cannot sell linuxmce. You can only make service contracts.
Unless you get a license

[totallymaxed]

You cannot sell linuxmce. You can only make service contracts.
Unless you get a license

...and you cant get licenses any longer.

Andrew

[ajward]

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

Andy.

[golgoj4]

As a former builder of high end homes / water features, I can say that maint is _expected_ at regular intervals. Anything that runs. Heck, even a home itself needs yearly maint.

Just my 2cent but im very interested none the less in redundancy solutions your working on

-golgoj4

[ajward]

I agree that anyone who pays £100k for a high-end Crestron/AMX system or whatever is going to expect annual maintenance, and probably 4-hour call out for re-programming on a whim as well, I shouldn't wonder.

And I agree that a house needs maintenance, primarily to repair wear and tear.

But I'm not convinced that mid-range home automation system with less complexity than a modern TV and a wiring system similar to a small business network needs routine maintenance.

Of course things go wrong and need changing & fixing, and many people will have limited time and knowledge to rummage around in a LinuxMCE Admin panel. Some arrangement has to be made to deal with these cases, if the householder cannot or does not want to.

That doesn't mean a system should be built out of low-MTBF components (as PCs generally are) patched up with a maintenance contract. PCs that don't have low MTBFs are expensive, because most people don't need them. That's why data centres generally use redundancy rather than high MTBF.

Paradoxically, at the high end of the HA market, you can justify all sorts of high-reliability components and architecture, which are unlikely to need replacing.

Alarms systems are an interesting example: sensors are easy to replace, the alarm systems can self-test and hardly ever fail (IME), and wiring fails pretty much only when damaged. Annual maintenance consists of running the tests and replacing batteries. They have no internal redundancy, and very simple circuitry (compared with a PC, for example). Yet the principle reason people have maintenance contracts is because insurance companies insist.

Most of the cost of a maintenance contract is the cost of attendance at site, it seems to me. If remote logging and diagnosis were simpler and more comprehensive, and DIY replacements were part of the design, I don't see what there is left for annual maintenance to do.

Andy

[Marie.O]

One thing I missed: LinuxMCE already has support for the GC-100 line from GlobalCache. Those little device can be used in quite a lot of scenarios.

[davegravy]

One thing I missed: LinuxMCE already has support for the GC-100 line from GlobalCache. Those little device can be used in quite a lot of scenarios.

As per my other thread, I haven't had much luck with reliability from my GC-100 - but i'm still investigating the reasons.

[JaseP]

Ajward, what you're describing sounds more like a MCV Vera, than it does LinuxMCE. LinuxMCE isn't just about home automation, it's about integration of home automation, multimedia, telephony, security, etc. The MCV guys already "lifted" the DCE router stuff from LinuxMCE/PlutoHome, so, you're a little late to the game in development of a new project or product.

I'm not saying that there's no room in the market for what you're contemplating, just that you'll have competition that's already established. A Vera "light" costs about $180 USD. I have the older Vera model, which cost about $375 at the time I got mine. MCV doesn't charge for basic online access either. Other smart home controller manufacturers have devices in that range and slightly more expensive too. You have to be able to compete with all of them.

Z-wave forms a mesh network similar to what you describe, but accessed through a master control unit. Building your own tech to do the same means making sure it's secure (more secure than WiFi), reliable, can integrate with other systems, ... etc. That's a tall order. But if you can build a better mouse trap...

[ajward]

I hadn't heard of the MCV stuff before, and taking a look it's quite interesting. A bit of a "jump on the eco bandwagon" style of marketing, but I get the relevance.

As far as I can see, the Vera devices can't directly control much - in the same way the Core doesn't directly control much, it just controls things which do. What external hardware would you need to closed-loop control a pump on return temperature in a heat exchanger, for example?

The nice thing about the Barionet family is that it's quite capable out of the box (1-Wire, TCP/IP, RS485, RS232, direct I/O, ...), and very cheap per I/O.

I like the distributed architecture of Vera, but is the system dependent on a central portal (like the Nest) or not? I couldn't tell on a quick reading.

I'm not looking to replace anything of LinuxMCE, but I just don't like the thought of being dependent on a PC for everything in my entire house. Capable though GC100's might be, they can control precisely nothing without the Core up and running. There is no distributed control or intelligence.

The media-centric design of LinuxMCE is the right way to go IMHO, and it needs PC power to do it (or maybe ARM soon, but in any case something fairly powerful). My goal is simply to provide a "better" LinuxMCE implementation. Or more options. Or both.

Andy.

[Marie.O]

A note: MiCasaVerde's and Pluto's father are one and the same.

[JaseP]

@ poside:

Yeah, I heard that, but didn't know if it was the complete truth ...

@ ajward:

The MCV Vera is basically a repurposed router with a (now internal)  USB Z-wave control stick and some USB ports. The Vera runs the DCE router stuff and acts as the main controller for the z-wave (and other home automation systems like x10, etc.). With z-wave secondary controllers can control scenes as well as the master, but there's always a master on the mesh network.  There is basically nothing on the market where each device is independent of the others.

Some have explored the idea of pairing the Vera and LinuxMCE directly through the network, but the DCE routers are not compatible (each wants to rest control from the other). So the only way to integrate them now is to make one a secondary z-wave controller to the other (and talk control speak across z-wave instead of the the Ethernet lines). That means you need a second inclusion controller stick for your LinuxMCE core, besides the one in (or inside) the vera. Of course,  I could be wrong about that, and it might have been worked out by now,... but I haven't seen anything to that effect on either forums. Of course,  what I mean above has nothing to do with the ability of the Vera to act as a router for internet purposes with a Linux MCE system.