Thanks @chris for those precious advices.
For you, what would be good modules to go DIY and start in Zigbee ?
I agree with you that WIFI might be problematic in case you have many nodes. I have multiple acces points which are capable of more than 100 clients, so I do not face any problems.
It ls also obvious that using 2 technologies is real redundancy (thatās why I mentions ākind of redundancyā) at least the lighting in the house divided, so if one of the 2 infrastructures is down, there is no need to stay in the dark.
From low power point of view Zwave and/or Zigbee are definately more capable than WIFI.
Not sure if it satisfies your definition of mesh, but the MySensors project is basically this: super cheap nrf24 radios attached to super cheap arduino clone boards, perfect for battery powered operation.
Iām basically an idiot when it comes to software and programming, but even Iāve managed to get a DHT22 sensor up and running and communicating through the MQTT Gateway with openHAB.
Iād keep it simpleā¦ Z-wave dimmers such as fibaro/aeotec/qubino.
If you in the uk and donāt have a neutral - no problem - find the light that has the switched live present and wire it in above the fitting.
It will physically work with the existing switch even if your system failed.
Out of all my devices, Zwave is by far the most reliable and wish I could get everything in its format.
Thanks for your advices all.
But I would like to stay with a DIY compatible protocol, to be able to add custom sensors in the mesh network (I would probably mainly go with custom sensors and nodes). And for what I know, Z-wave board modules are not easy to find, and not the cheap.
Zigbee board modules seems to be simpler to find and cheaper.
I still need to find the good oneā¦
I will take a look at the MySensors project too.
Edit : MySensors is star network and not mesh network. Itās not as reliable as a mesh network like zigbee or assimilated.
That one does it too. I think there is an internal relay triggered either by the local physical switch or through Z-Wave,
Assuming weāre using the Wikipedia definition:
In a star network, every host is connected to a central hub.
Then this is both true and false for MySensors, depending on your interpretation. As described on the pages I linked in the previous post:
- MySensors nodes can act as repeaters for other nodes, and that topology is dynamic - i.e. you can move nodes around and the network will automatically update, just like Z-Wave and Zigbee.
- By default all data comes back to a central controller, just like with Z-Wave and Zigbee. However, you can directly associate non-controller nodes with each other, bypassing the controller directly - just like Z-Wave and Zigbee.
Certainly, using MySensors is more of a faff, and probably not as robust as Z-Wave and Zigbee by virtue of its DIY nature. I would personally love to be able to make DIY Zigbee modules, but the off-the-shelf prototyping boards cost an order of magnitude more than a MySensors build. I did come across a project which used IKEA Tradfri products, and just pulled them apart and used the boards for DIY projects but my Google search skills are failing me.
I personally use Silabs chips - itās what I know, and they have good software etc, although I think you need to buy a devkit to activate it (but I think they arenāt very expensive). Iām sure NXP and TI have similarly good devices and tools.
1 Like
Ok, I think we have a different definition of redundancy. For me, a redundant system provides the same functionality through two mechanisms - so you would duplicate all your lights? I guess this isnāt what youāre doing - but instead you have some lights that are one technology, and a different set that are a different technology?
Anyway, this sort of thing is personal, and whatever works for you is of course best 
.
2 Likes
The boards are around $35 direct from silicon labs. Youād need to buy the dev kit though which is about $379.
Also, with the vast amount of Zwave products out there I donāt see the need to make yourself when you have things such as fibaroā smart implant for sensors / digital inputs and a whole host of relays and switches. The only real thing missing from the uk market is actual āsocketsā (not plugs).
1 Like
Sorry, are you talk about specifically wireless system? I have a knx ecosystem and I think it is expensive but it donāt have single point of failure except for the openhab. Actually with KNX you donāt have physical dongle or other particular stuff, so I think it should be possible to do a redoundant configuration whit 2 raspberry and a simple script
Ok I havenāt seen that, that nodes can communicate without pass by the central controller. I will look deeper in this way. But what if a node need to communicate with one other node, passing by an intermediate ? In other words, can MySensors be used to realize a real mesh network or does it have limitations ?
Thanks, i will look at TI CC2530. It seems to be largely diffused, and someās custom firmware for Zigbee 3.0 have been released :
TI Z-stack
Zigbee 3.0 custom firmware zith GUI
Zigbee 3.0 custom firmware
It could be a good starting point.
Yes, it what I have said. It is not cheap. If you want to design and implement multiple sensors and actuators on your house, it can be expensive. At this price, it seems better to go with existing devices.
You donāt see the need, but I see differently.
ā¢ Fibaro devices, and Zwave generally, are expensive. The smallest Fibaro dimmers reach easily 40-50ā¬. If you want to implement a lot of sensors and actuators, it can be easily out of budget.
ā¢ Using existing devices is an easy way to reach the goal (add automation in house), but is limiting in some way. If you want to add, for example, light + temp + humidity + door contact, you can do that the DIY way on only one node. If you go with existing devices, you must buy light node, temp+hum node, and door contact node. And some sensors not exist or are very expensive (VOC or gas for example).
ā¢ Going the DIY way permit learning and develop some knowledge. It is a hobby.
I am not telling what you said is a wrong. If you donāt want to spend a lot of time to develop things and you have some money, it is probably a good way. But I just want to make by myself and learn about a new wireless protocol (I havenāt done mesh network yet).
KNX is a must yes. I have learned it at school at his beginning. If I could build a new house or if I remake all my electric system, I will probably go with it.
I donāt know what boards you mean, but this sounds expensive. Iād expect about 1/2 or 1/4 of the price - 10 to 15 dollars depending on exactly what youāre doing. Certainly modules Iāve been using are well below 10 British Pounds.
You can spend a lot on starter kits for sure, but I think the basic kit is probably below $100 - and similar to other manufacturers such as TI and NXP.
Sure - there are plenty of ZigBe devices available to do most things, but people always like to make things - as we see in this discussion.
I had to support the 2531 a while back, and TI told me they were not supporting this any more. Really Iād suggest not to go down that route, but of course itās up to you.
Well, itās not expensive if you know what youāre doing. You can get PCBs made from China for a few $$$ - very cheap. Then the Silabs modules are reasonably cheap - not super low cost, but you could put everything together with a custom module for less than Ā£20. To me, thatās pretty cheap, but I guess everyone has a different view on what cheap means 
Below is one example of a simple to use Silabs module - just add your own sensors and power -:
I use a lot of Silabs stuff for the commercial ZigBee work and in general Iād recommend it. As another example I had these dongles made in China and delivered - all up it cost about Ā£120 for 5 units - not super duper cheap, but still not bad given all I had to do was send off the list of parts and board layout to China, and a couple of weeks later these arrived in the postā¦
2 Likes
Thanks for this precious information, it will allow me not to go on a siding.
Yes it is what I want to make.
Thatās pretty cheap, sufficiently to do some experiments, and later to be implemented in the entire house scale.
I will look at the MGM12P02F1024GA-v4 and his devkit. Thanks again 
Edit : It appears that purchase the 499$ devkit is mandatory to use Silicons Labs EmberZnet stack (zigbee stack) and develop zigbee devices with Silicon labs modules. Too bad =/
Iām a little surprised that the starter kit does not provide the same access to the tools to be honest. The starter kit is $100 as I said earlier.
If I look at this, it clearly states it āprovides all the tools to develop IoT applicationsā - why do you think the more expensive kit is required?
1 Like
You donāt need a mesh network to eliminate single point of failure. In a system with central controller you can easily add redundancy by adding backup controller in cold backup. E.g you just need a couple of Wi-Fi or Z-wave relays. Changeover will take maximum few mins until your controller boots up.
Yes it seems that I was wrong. Only kits that are on this page give access to the EmberZnet stack, and the SLWSTK6021A is listed in :
I think i will give it a try.
Yes, but it is more a backup solution, or cold strategy. It is not adding reliability but fast hardware replacement.
It can be a good compromise between mesh network cost (time developement) and no solution.
One other could be a peer-to-peer network. Like MySensors seems to be able to. This way, there is no central broker or gateway that create single point of failure.
In fact, it is the minimum needed. In comparison with peer-to-peer network, and in case that each node can talk with each other without a relay node, mesh network is not adding reliability but just range. But in case some nodes are to far to be able to communicate and a third node is needed to relay message, it add reliability.
At least like i think the things.
If you setup it right, the system with central controller is already reliable enough for HA needs. It means it would fail in random fashion once per couple of years or even less often and most failures will contribute to HW issues, like SD card problem or power supply failure. This means you are in the middle of a reliability bath curve.
Many people mixing terms. In this case what you need is not reliability, but availability - you need to guarantee, that system will do itās work for 99.99% of time(e.g downtime of your system should be less than 50 mins per year). Achieving this number by increasing reliability of a non-redundant system - itās a tricky task if your system is already reliable. Better way of doing this - is to add redundancy, as I mentioned above.
Yes, this will decrease MTBF as now you have two HW pieces, which both can fail independently, but effect on availability will be opposite and this is what you really need for home automation
BTW you asked about used architectures - I have a central controller with Z-wave in this redundant configuration since few years already. And I didnāt have yet any changeover to backup controller till now. Only during manual tests. And yes, I did it because of lights and heating control - I donāt have any physical light switches and thus availability becomes critical here.
You are right @Artyom_Syomushkin. I have mixed the two terms. I mainly spoke about availability instead of reliability.
I think the main and final aim in home automation is to have maximum availability, with a good reliability. As close as possible to non-smart home.
I will try to explain exactly how I see the things.
For me, home automation is, and need to be, adding intelligence on top of existing installation and usages. Lighting example is well explaining this case :
ā¢ On existing and non-smart installation (by ānon-smart installationā I mean ānon-smart home setupā or ānon-smart home configurationā, maybe I donāt use the right term, forgive me and tell me what is the right term please), you have wall switches with light bulbs and wires to link them directly. Wires never breaks down. Wall switches are highly reliable and rarely break down. Light bulbs are less reliable and break down after a few years, sometime less. This configuration is convenient for most of us, and in any case is usual. You change lights bulbs, and you go for one other ride.
ā¢ On very simple smart installation, smart wall switches are linked to light bulbs by wires. As far as the smart wall switches reach a reliability close to non-smart wall switches, the case is the same case as non-smart installation. Wire can not break down and light bulbs break down after a few years. We just add some intelligence by adding an external way (central OH controller) to control smart wall switches. And if the central controller fail, we go back to a non-smart installation case. This configuration can be more convenient than a non-smart installation, but in case of fail, this configuration is at least convenient than a non-smart installation.
It just adds some advantages (external controller), as far as the smart wall switches reach a reliability close to non-smart wall switches.
ā¢ On advanced installations, the main change is that the wires that link wall switches and light bulbs are replaced by wireless links. Advanced feature case example : dimming features on led lighting canāt use old AC dimming way. Using led driver with dimming capability is mandatory, and those led drivers are mainly located on the led lighting element. So wireless links to transmit dimming value from smart wall switches (or external controller) are mandatory.
(I donāt talk about wired solution like KNX that are often impossible in existing installation.)
Those wireless links are by nature less reliable than wired links. In some case reliability and availability can be quite good, but depending on hardware and environment (SW bugs, RF noise or crowded network), reliability and availability can vary a lot and be poor. This is already less convenient than a non-smart installation.
But on top of this, you could use a central gateway/broker, that each node must use to communicate with other nodes (star or tree network). In this case, if the gateway/broker fails (bugs, SW update, SD corruption, etc), the ENTIRE installation is not available. This is not a single light bulb or a single wireless link in the installation, this is all the parts of the installation that are not available. An addition of multiple simultaneous non-availability. You still have central controller + local controller, with few more features, but with less reliability and less availability.
If you make addition of the seriousness of this central failure case (high seriousness but little probability) and the failure probability of a single wireless link (little seriousness but high probability), you have a result that is far less convenient and usual than a āsimple smartā or a non-smart installation.
For me this is the main problem : loss of reliability and especially of availability in comparison of a non-smart installation. It is inherent to more complex systems, yes. But this, adding significant disadvantages and loss of convenience compared to simple smart installations, is a kind of wall that prevents people going further in home automation and limit them to āsimple smart installation stateā with simple smart wall switches. Not a really āsmart and convenientā home but more a āgadget homeāā¦ (without any offense 
)
The main weakness is the star/tree network with his central gateway/broker. Replacing it with mesh network directly remove the disadvantages and weaknesses of advanced smart home installation.
Yes you could have a central controller failure, but your installation stay at least as convenient as a non-smart home.
I hope it was clear and not too longā¦
Well itās still unclear to me what you want to tell us by this.
Availability is essentially the product of MTBF and MTTR.
Many (data center minded) architects tend to believe they must get the lower (physical) layers redundant and invest in dual switches and servers for example to get MTBF up.
Experienced (smarthome) architects on the other hand have a feeling for where itās worth to invest in redundancy (rarely anywhere at all in fact) and instead focus on getting the MTTR down.
For example they āinvestā in a well tested backup + restore process rather than in redundant hardware.
Good ones also have a concept of āgraceful degradationā, for example have one (but only one) light per room on a local switch that also works if the central controller is down - and donāt care about redundancy for the rest. Thatās all you need in emergency situations, noone cares if your fancy mood lightingās availability is fives nines or just 90%.
The most advanced installations to have the best availability actually are not those with some highly sophisticated Active-Active-Failover-whatever-dual-controller mechanisms but those that stick with the āKeep It Simple, Stupidā principle.
3 Likes