Stand alone lighting control system
I've been playing with MySensors for a while now but have finally gotten around to ordering some boards and components en masse. My plan is to automate my lighting for my entire house by replacing all of the light switches with nodes and placing a relay / dimmer node on each light fitting. I also want this to be independent to my home control system. I.e. I don’t want all my lights to stop working when I reboot my Pi for instance.
The way I see it is, either I write custom switch and light nodes, each of which can receive a command to tie light to switch and they then talk directly to each other, or I write software on the gateway to manage these connections and turn light A on when switch Q is switched etc. Either way I’d like to be able to re-assign things without dismantling the network and re-programming each device. I'd also like to monitor and record every switch event and be able to send light control messages via the gateway from external software when needed.
I was thinking the easiest way would be to put software on the gateway to map switches to lights which could be set up with external software but would be stand alone once set up. This option would be the simpler to write. However, a direct node-to-node system may be advantageous in the case of communication problems, with the proximity of the switch to light being an advantage. I don’t know how reliable larger networks are (I’m estimating 25-30 lights and 15-20 light switch nodes).
Also, would it be sensible to have this network completely separate to any other networks I may want in the house (temperature sensors for instance) in order to limit traffic?
I’m going to start work on this and I guess I’ll see how it evolves, but I would be interested in hearing other people’s opinions.
@Stuart-Middleton - interesting, I will follow your project.
For light switches there are some project on openhardware.io that seems really good. For relay/dimmer its more of a complex question - I have deceloped my (not dimmer) relay switch but since we are working with high power its a safety aspect as well. A hard nut to crack.
Im not familiar with 2.0 but i think there is a node to node communication already... someone with better knowledge here can tell you but I have seen some discusson about this.
@Stuart-Middleton Node to Node communication is very ease. Nodes can communicate directly to each other - no interference by the gateway needed. Just look at the Ping Pong example sketch, if you want to know how to do this.
If you want to control minimal logic from withing the gateway, you'll nee a gateway with lots of memory. For instance an AT-mega. It can all be done, but the question is. Why would you want all of the separate networks? How many time are you going to reboot your pi? I've rebooted my Pi lots of time. But my MySensors network kept on working.
It's probably because of me. But I just don't understand your problem.
Also the way all commercial Home Automation switches work, is that they can be operated manually in case the controller dies. My advice is to add a switch so you can still operate the switch even if the controller is offline.
As @sundberg84 stated. Dealing with high voltages is really difficult. So please be careful with what you design. I don't think your insurance will cover any damage caused by DIY made circuits. At least mine doesn't.
Using separate networks will not limit traffic. Unless you have networks on different frequencies. But I wouldn't worry too much about high traffic. My temperature sensors report every 10 minutes or whenever the temperature changes for more than 0,5 degrees from the last send values. I just don't see the need for sending sensors values very often.
Hope this helps you.
Thanks for the info. Regarding the rebooting of the controller. I was thinking if the controller held the logic to rough switches to lights, then rebooting (or having it crash) would mean the system would fail. Doing node-to-node or building the logic into the gateway means the lighting would always work with no controller attached. Hope that makes sense.
Hello, I'm thinking about this too, and I see two solutions :
- when possible, put the actuator in the wall behind the switch, the switch is connected directly to the actuator so the action is direct, then actuator sends it's new status to gateway/controller, if sending fails because they are offline, no problem
- if not possible, then link the switch to the relay actuator: switch will send the switch message directly to the actuator, then actuator will report it's status to the gateway controller. I think the most convenient way to do that is to add a custom "sensor" for each switch you have, and save the id of the actuator node you want to action in that custom value. You read it at startup of the switch sensor and instead of sending switch action to the gateway/controller you send directly to the related sensor
Another way to do that would be to make it like cheap radio sensors, I have some of those and the behavior is :
- switches always send the same code, and a status value
- to make the link, the actuator is in "learning" mode during 10-15s at startup, if during that time it receives a switch message then it will save it.
For MySensors it means sending a broadcast message from the switch, but that doesn't sound like a good solution as you cannot get an ack with this solution.
I am planning on doing this too, and I was planing to use one node dedicated to the lights controller, then all the switches would send data to that node, and it would have logic about which command to send to which light. It would also keep track of light groups, their location etc. So pseudo code would be
"received switch a1 single click"
bunch of if/else (or other rules)
"sending command to actuators Z2 and Z5"
(you could send commands like double click, short hold - which would toggle other set of lights (floor lights etc))
I wrote about this some time ago but didn't got the time to do something about it, maybe you get some additional ideas
I'll be implementing a few ideas over the coming months and hope to get a working solution, probably using the gateway node as the logic controller for deciding which switch controls which light. It should be simple enough. However finding the time to build and write it all may be an issue
But that would add a level of complexity to the system, adding dependancy to another module/node doesn't sound like an improvement if we are looking for fallback measure ?
About double click/hold/... I think you are also trying to make something too complex. In my opinion this should be managed inside the sensor on which you perform the action, and each action on the same button is seen as a different "switch" in the controller.
Do you mean adding a level of complexity above using home automation software to handle the logic, or a level of complexity above just linking switches directly to nodes?
The latter I agree with. A controller node may add complexity, but it would give much more flexibility and configuration without having to write more complex switch nodes.
For example. A lighting system in a house is usually just one (or sometimes two) switches controlling a single or multiple set of lights. I would like a system where this is true, but at any point you can change which switch controls which light. Or add a switch to the system at any point. Or have a double tap on a switch (assuming touch switches) turn off a set of light. Have a triple touch turn off all lights for bedtime, but only on a certain subset of switches. Have the whole thing controllable from my phone from anywhere in the world. Have the system remember a weeks worth of lighting to replay while I'm away on holiday.
From my point of view, having switches as input nodes only and having a single controller node (probably built into the gateway node) would be the easiest to write as all the logic is in one place. I am thinking that node-to-node logic would work, but would mean having smart switches that could be programmed over-the-air to change their designated lights, or control multiple lights. I'm not 100% sure that this is the better way, but this is my current thinking. The main disadvantage of node-to-node is that the gateway may never see the switch commands and therefore would not be able to log the usage.
Maybe I'll change my mind by the time I've built it!
For me personally the main focus is not fallback as is independency from the controller/domoticz.
Also there is delay when you use domoticz as controller, which annoys me so much. I click on the switch, sometims it is 2s before the light comes on. And there is always "stress" of switch not working, rebooting or what not.
Also there is convenience on only programming one single node when new lights are added (or existing changed). And when we talk 25-30 lights and 15-20 light switch nodes as mentioned in the first topic, I would like to avoid ever touching those 40-50 nodes and edit logic in one place.
There is always a balance between convenience / reliability, but one can have clone of the "controller" node as a backup, just in case main dies, you just plug inn the backup
I'd never even considered the delay! Yes, I agree. I'm after a stand alone lighting system that has the flexibility to connect to home automation software, but works quite happily by itself and is immune to the house software crashing or being rebooted. We get power cuts sometimes, and I'd hate to have to wait for my system to reboot before the lights work! And I'm pretty sure my wife would leave me if the light switches were unreliable!
@Stuart-Middleton you can do node-to-node as well as node-to-gateway communication one after the other.
Your switch node can send a command to the relay node, and send a command to the gateway. But to be honestly, I would have the relay nodes communicate their changed status to the gateway, that way if you press a button on a switch node, and it does not arrive at the relay node, but it arrives at the gateway, you controller will think the light is on while it is not.
Regarding the mapping, i would build my switching nodes so that when they boot up, they ask the controller for the mapping and store that in the eeprom. (or make a function that when button 1 on a switch node is pressed for 5 secs, it asks the controller for the mapping) This makes it all independent from any gateway and/or controller while you retain the flexibility of changing mappings afterwards.
Just my 2c's
That is an option. I like the idea that the switch nodes that are physically close to the lights they control. The delay is less than relaying through the gateway (and possibly relay nodes) and the signal strength would be the strongest. I still think for functions such as "turn all lights off", a controller would be easier rather than a single switch needing to send messages to all lights in the house, but I could use a combination of both techniques. This method would make it more robust as if the gateway or repeater goes down, the system would still work. If I wanted to log the system for playback, I could always poll the lights every minute or so and get their state.
I've not started building it yet so I'm just after ideas, but a combination of node-to-node and controller for more complex actions and node setup may be the ideal solution.
Not sure if I'm getting this right. You want to add logic to a Node or Gateway in case the controller shuts down? But what happens if the node/gateway containing the logic will go down?
That's right. But the node or gateway are far less likely to go down than the controller. Especially in an environment where I'm constantly messing with my home control by adding new software to the controller and rebooting it. The gateway, in theory, will never be switched off
@Stuart-Middleton I have a second Pi with a second gateway I use to do my experiments on. On just want my production environment to run 24/7.
I have some weird problem when power goes down, I have to have domotics up and running first, and then power on the gateway and click reset on it, and then MySensors starts working again. Which is manual job, not difficult for me but if my wife comes home from work before me, then "nothing works without the wires" topic appears on the table.
That should be probably fixed in the code/communication it self, but it was also one of the reasons why independent light control made sense for me, it just sounds more reliable.
But second PI is also good idea for experiments. Although often experiments work when I test them, but when scenarios are used in real life quite some bugs appear forcing me to test and fix "live" (and then lights are off and cable topic appears again)
I like the idea that all of the systems are essentially self contained to a point where they can perform their main task without a master controller. I.e. lights work without domotics or whatever needing to boot up. I also have an alarm system I'm working on. All controlled from a central server, BUT it still works as an alarm if the controller fails, I just can't get useful info from the web interface or control it remotely.
@dakipro I'm not saying that I find this a bad idea. I just can't see why I would wanna go through all of this trouble and lots of work. When, in my opinion some of the problems mentioned in this topic could be solved differently.
First of all, building all the logic in a node with supporting scenario's and things like that is really complicated and might be getting to big for a normal Arduino. So you probably need an Atmega which is quit a bit more expensive. Also you'll loose a lot of flexibility, because you have to reprogram the logic node with every addition you make to your network.
I've read the following problems:
a.) Gateway not stable. Regardless to what solution you come up with. You should try to make the gateway stable. Mine runs for more than a year and so far no need to reset the gateway. In most cases problems like these are power related or you might have a bad radio.
b.) the lights can't be controlled when the gateway/controller isn't up and running: This is in my opinion not caused by the gateway/controller going down. I always add some kind of switch to my actuators, so that I'm able to control everything manually. This is a good practice when designing Home Automation solutions. HA should enhance our lives not take it over.
c.) Controller can shutdown: Why not use an MQTT gateway? And add emergency logic on the MQTT bus with NodeRed? This is really easy and takes less time to implement. It's also a good architecture, because you create an extra layer and have a loose coupling between mySensors and the controller logic. Also you can add logic, you just can't with most of the controllers. Because by using MQTT you can use MySensors at it's fullest capability.
d.) Als0 scenario's for turning on/off multiple lights are there for your convenience. You should still be able to control any light manually regardless of the logic in your controller.
But that's just my 50 cents.
@Stuart-Middleton Fair. But please consider using MQTT. It saves you a lot of time.