Stand alone lighting control system
-
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 :)C: OpenHAB2 with node-red on linux laptop
GW: Arduino Nano - W5100 Ethernet, Nrf24l01+ 2,4Ghz mqtt
GW: Arduino Mega, RFLink 433Mhz -
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
Greetings
-
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
-
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.
-
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)
@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. -
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.
@Stuart-Middleton Fair. But please consider using MQTT. It saves you a lot of time.
-
very good points @TheoL , I am all for easy AND very reliable solutions.
Honestly, I didn't find much info about MQTT, on build pages it says that "The MQTT gateway is basically a Ethernet Gateway with modified software which makes it act as a MQTT broker", and first comment says there are bunch of errors, and for me as a beginner in mysensors/HA it is probably another "complicated" term and technology I need to get my hands on.
I will try to find more info about benefits of the MQTT protocol, but if it would be possible to have a "backup" controller as you describe it or something else that would be dedicated to the "lighting control" logic, then I would definitely like to try it. Please do tell more :)C: OpenHAB2 with node-red on linux laptop
GW: Arduino Nano - W5100 Ethernet, Nrf24l01+ 2,4Ghz mqtt
GW: Arduino Mega, RFLink 433Mhz -
very good points @TheoL , I am all for easy AND very reliable solutions.
Honestly, I didn't find much info about MQTT, on build pages it says that "The MQTT gateway is basically a Ethernet Gateway with modified software which makes it act as a MQTT broker", and first comment says there are bunch of errors, and for me as a beginner in mysensors/HA it is probably another "complicated" term and technology I need to get my hands on.
I will try to find more info about benefits of the MQTT protocol, but if it would be possible to have a "backup" controller as you describe it or something else that would be dedicated to the "lighting control" logic, then I would definitely like to try it. Please do tell more :)@dakipro I'll try to add an MQTT tutorial within a couple of weeks. I want to do an MQTT presentation for my colleagues so why not combine it with a tutorial for the MySensors community. It's a bit hard to understand in the beginning, but once you understand the basics, you wonder why you not have used it before.
But again, there should be no need for an master/slave controller implementation. The only thing I can't prevent is an power outage. Everything else runs very stable in my house at least. And if I don't want to control my lighting with my Home Automation controller, I'm still able to use manually operated switches, which is one of my main design principles when designing new MySensors actuators.
Most important for each Node is that you simply don't used the Arduino as a power supply. I found that out the hard way. I now power everything from an power adapter, incl. the Antenna.
-
@dakipro I'll try to add an MQTT tutorial within a couple of weeks. I want to do an MQTT presentation for my colleagues so why not combine it with a tutorial for the MySensors community. It's a bit hard to understand in the beginning, but once you understand the basics, you wonder why you not have used it before.
But again, there should be no need for an master/slave controller implementation. The only thing I can't prevent is an power outage. Everything else runs very stable in my house at least. And if I don't want to control my lighting with my Home Automation controller, I'm still able to use manually operated switches, which is one of my main design principles when designing new MySensors actuators.
Most important for each Node is that you simply don't used the Arduino as a power supply. I found that out the hard way. I now power everything from an power adapter, incl. the Antenna.
-
I agree with @TheoL - I run Domoticz and Ethernet GW without major issues for 1.5 years now... offcourse there was some initial setup problems. You need to be able to run everything on a smaller arduino. Lightswitches and spaces you are going to work in are most of the times very tight so dont forget about that.
I also run a arduino + relay with the switch connected to this relay through D3 for example. If MySensors fail (untested in real enviroment so far) the switch should still work by hitting the switch.
-
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 :)@dakipro said:
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.This might help if someone could make it as configurable value and will merge it to codebase: https://www.domoticz.com/forum/viewtopic.php?p=93701#p92910
I've designed my setup another way: The house is divided in 5 areas. Every area has its own relay box where all the actuators of that area are living. So in normal wall boxes I have only weak current. I'll try to implement everything based on rs485. Most of the buttons will be directly tied to actuator and some are action buttons for HA controller. Mainly for scenes I think.
Another solution I was thinking is that as fall back I could use nexa remote to control those actuator-boxes directly since it has ability to control 4x4 devices or 4x8 if you use it for toggle... but the problem might be that the remotes are always lost..
-
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 :) -
are you using domoticz as well?
I've read that mqtt is "officially" not supported, but it could work. Anyway, I am looking forward to your presentation :)C: OpenHAB2 with node-red on linux laptop
GW: Arduino Nano - W5100 Ethernet, Nrf24l01+ 2,4Ghz mqtt
GW: Arduino Mega, RFLink 433Mhz -
are you using domoticz as well?
I've read that mqtt is "officially" not supported, but it could work. Anyway, I am looking forward to your presentation :)@dakipro I'm using Domoticz as controller as well. I mainly use it as a gateway to all the devices I want to control and defining the scenes I use.
I have for instance one scene in my living room for normal lightning. This means there's an additional lamp on which is standing next to the tv (It's actually my gesture controlled MySensors lamp).
When I want to watch TV I don't want that additional light to be on. So in my watch tv scene I turn that one off.
And I have an additional Scene for turning all lamps in my living room off.
Now when I use the domoticz GUI it's some times really slow. Especially when I use my mobile because, I have crappy WiFi. So I just have a MySensors scene controller talking to Domoticz (not MQTT) for controlling the light scenes. Even that one causes instant responses from my lamps in the living room.
When I send MQTT commands to Domoticz it's acts instantly. Meaning really fast. Which is the same when I send rest calls to Domoticz.
I'm not sure where you've read that MQTT is not supported by Domoticz. I've been using it for more than a half year. But I'm one Domoticz release behind. And it works like a charm. I let Domoticz do the Home Automation and do my IoT stuff through MQTT.
