LinuxMCE Forums
General => Developers => Topic started by: ajward on March 11, 2011, 04:21:43 pm
-
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 (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 (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.
-
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.
-
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.
-
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.
-
You cannot sell linuxmce. You can only make service contracts.
Unless you get a license
-
You cannot sell linuxmce. You can only make service contracts.
Unless you get a license
...and you cant get licenses any longer.
Andrew
-
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.
-
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
-
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
-
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.
-
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.
-
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...
-
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.
-
A note: MiCasaVerde's and Pluto's father are one and the same.
-
@ 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.
-
That's interesting. The only weakness of the message routing architecture that I can see is that it is hard to avoid a single point of failure.
To be honest, when I looked at LinuxMCE, the biggest quandry for me was "what do I use as the actual control bus/network?" Here are my conclusions:
Z-wave is great for retro-fit, and the mesh capabilities give it a fighting chance in real life situations (14" solid stone internal walls, that sort of thing). But it is relatively expensive to equip a whole house, and I worry that WiFi, Z-Wave, Bluetooth, Microwave ovens and so on all sharing the same space is likely to cause problems.
X10 is too slow for a whole house implementation these days. I'm surprised someone hasn't updated it with the HomePlug Ethernet-over-mains standard - I looked into it, and all the parts are there. Imagine just reaching out over the network to each auto-configured light fitting directly!
Knx/EIB is a powerful standard, but look at the price of a dimmer or a light switch. I didn't look any deeper for that reason.
Clipsal/CBus has most of the characteristics of Knx/EIB (including the price!). Nice kit, though.
DMX512 looks good as a lighting standard (fast, easy to run cables, low cost per lamp), but the whole house would depend on one PC if I used a USB or serial DMX controller on the Core. I could use Media Directors to spread the control a bit, but the DCErouter is still in the path to every lighting change.
1-Wire is capable and cheap, but sensors and controls are limited
I had been working with WebBrick Systems to try and build solution for my house, and they got a lot of things right before their unfortunate demise, but the engineer in me could see something better and more capable. That led me onto the Barionet, and MythTV led me onto LinuxMCE. I believe I have the skills to put the two together - let's see what comes out!
I just thought I'd explain this in case anyone is coming to the conclusion I'm just plain crazy (maybe it's too late :) ).
Andy.
-
Z-wave mesh networks will periodically go through a "healing" process where the devices work out amongst each other how to best route messages back and forth. The more devices you have, the more solid the mesh network. Your fix for stone walls, concrete and rebar are to have enough devices to work around those obsticals. Lag is inherent in any home automation system. I'm generally impressed with z-wave responsiveness, but there are occasional annoying lags.
As for cost, z-wave can be relatively cheap, or it can be obscenely expensive. It depends what you want. I have 2 z-wave thermostats, 3 door locks, 4 in wall dimmers, 4 appliance modules, an infrared multi-sensor (infrared, light, temperature), a MCV Vera as master controller, a second Aeon Labs z-wave USB inclusion controller for the LinuxMCE core, a radio signal/scene controller, and a z-wave enabled universal remote. But I didn't buy all my stuff at once. I bought a few things at a time. I will be buying more too. Plus I have a wired IP camera, and a whole house full of computerized gadgets. It's a lifestyle choice. Nobody (short of the physically handicapped) needs a home automation and multimedia system. It's a luxury/choice/hobby.
PS: As to signal interference, z-wave works on a frequency apart from normal wireless (in the US at least). You get more z-wave interference from baby monitors than anything else. Wifi and Bluetooth will bang heads with each other more often.
-
Remember that LinuxMCE acts as a mediator for different system busses, so you can mix and match different bus topologies in the system; use the right tool for the job.
-Thom
-
/me is mostly using KNX sprinkled in with DMX512 where it makes sense (RGB LED dimming).
KNX is not (much) more expensive than Z-Wave, IF you factor in quality of the parts. Especially dimmers. There are good ones, and non-working ones ;)
I will continue to use KNX for switching stuff, and DMX for dimming stuff. Together they work without a problem so far.
/me doesn't tell about the one remaining X10 switch
-
Z-wave is great for retro-fit, and the mesh capabilities give it a fighting chance in real life situations (14" solid stone internal walls, that sort of thing). But it is relatively expensive to equip a whole house, and I worry that WiFi, Z-Wave, Bluetooth, Microwave ovens and so on all sharing the same space is likely to cause problems.
Z-Wave does not use 2,4GHz, so no interference from Wifi, Bluetooth, Microwave ovens etc.
Knx/EIB is a powerful standard, but look at the price of a dimmer or a light switch. I didn't look any deeper for that reason.
when you use REG units you can be cheaper than with Z-Wave depending on your existing wiring..
-
@tschak909
I understand. My system is coming out as a combination of DMX, MODBUS, 1-Wire and a bit of X10. The difference is the lights will still come on and the heating will work with just the Barionets running (probably off local batteries). Still controllable from any Orbiter/Media Director of course.
Most of my lighting is LED-based, and it's hard to beat a 9-channel DMX PWM LED driver for £50 (+PSU, but you need that anyway);
DMX mains dimmers can be got for £30-50;
MODBUS is for digital and analogue I/O (I have 9 zones controlled by 14 dampers with 0-10v control), LCD room controls and touch switches;
1-Wire is for the large number of temperature, pressure and flow-rate sensors in the plant room
X-10 is just for integrating a few plug-in lamps into the lighting scenes
@hari, JaseP
My mistake about the frequencies - I haven't used Z-wave because I don't think I need to in a new house. 900MHz is one of the 2G mobile frequencies in Europe, but I'm guessing it's not close enough to interfere.
Andy W.
-
I haven't been to Europe in over 20 years, so I am nobody to talk about z-wave frequency collisions there. But in the US, only legacy (analog) cordless phones and baby monitors tend to collide with z-wave here. I've been pleasantly surprised that as I have added z-wave nodes, the network has become more robust. I'm only smarting that I missed the big Radio Shack exodus from the z-wave retailer market... I saw references to the sales and wish I had picked up a half a dozen appliance modules...
Z-wave is fairly strong as home automation goes... But remember, even the biggest thing in this market is a niche product as far as the general public is concerned... Most of the world is 20 years behind in the home automation scheme of things...
-
My mistake about the frequencies - I haven't used Z-wave because I don't think I need to in a new house. 900MHz is one of the 2G mobile frequencies in Europe, but I'm guessing it's not close enough to interfere.
Z-Wave in Europe does not use the US frequency (908,42 MHz). in Europa ZWave is at 868,42 MHz.
-
As per my other thread, I haven't had much luck with reliability from my GC-100 - but i'm still investigating the reasons.
We've found GC products to be very reliable in our experience. So you may have a faulty unit... but in our experience that's very rare indeed.
All the best
Andrew