Hello,
I am working on an ambitious project to run my house. I will be using OpenHab running on a Pi3 as the main control. I have Sonoff switches that are running Tasmota on them to control the lights as well as a Z wave hub connected to the Pi3. I want to still be able to use the normal switches in the house so, since the Sonoff’s will be controlling the power to the lights themselves, I will change the power running to the normal house switches to be 5 VDC. I have signal voltage converters that will be installed at the receiving Pi (a CM3) that will change that 5 VDC to 3.3 VDC so that it is compatible with the inputs of the GPIO. I am going with the CM3 for this task because it has more I/O’s available than a standard Pi, 45 total. I have worked out how to control the Sonoffs via MQTT and OpenHAB. What I am having trouble with is understanding how to setup the system to monitor changes to the I/O on the CM3 so that I can link those changes to changed the designated OpenHAB item. Basically I want to have the advantages of OH so that I can use rules and remote commands but I also want my non-techy friends and family to be able to flip a switch and have the lights work as well. I want the system to look for state changes in the switch and then change the state of the item connected to it. For example, flipping the hall light switch will change the state of that light. It will not matter if the switch is already on or off or if the light is on or off. If the switch changes state then the light changes state. Before this project I had zero experience in coding so I have been learning a lot along the way but getting this function to work has me stumped. I have looked at various python code but since I am learning as I go… I can’t seem to find a good solution that will do what I want done.
Could I do something simple like have the CM3 as a client on of my MQTT server, have it send an update when a switch changes state and have that update trigger my system change I am looking for? Is that something I could program in Node-Red on the CM3?
Thanks for any direction you can provide.
D
Excellent approach, use openHAB to add functions to a system, (wall switches), not replace.
I suggest a different plan. Use wallswitches wired to control the Sonoffs directly, an extended onboard pushbutton if you like.
openHAB then needs to monitor the Sonoff on/off state, not the switches. You’ll be able to distinguish expected/automatic events from manual interventions, if you wish.
I’ve actually been very happy with Shelly’s which won’t require separate wiring and lets you control the switch. It might be an option that saves you some effort dealing with running new wires and converting voltage and such. The Shelly’s end up between the switch and the light and will both control the power to the light and will also report over MQTT that the switch has been flipped. One great advantage is that if OH is down, the switch will still work. OH can also control the switch over MQTT.
One of the settings for Shelly will set the switch as a toggle so your hall light example is well covered, and it is actually how I use mine.
rossko’s idea to have the switches control the sonoffs directly is another good one with all the same advantages.
At a high level, you want your devices to be as smart as possible so they can operate properly independently. That way when when something goes wrong the device still works. Build escalators instead of elevators. When an escalator breaks, it’s still usable as stairs. If every switch needs to go through WiFi to OH or NodeRed or some other central software then if anything in that chain breaks you lose the ability to control your lights. But if the switches can directly control the light without going through all that stuff, then as long as your switch has power it can control the light.
Yes. Not exactly the same problem as you are trying to solve, but a similar one is what had me write GitHub - rkoshak/sensorReporter: A python based service that receives sensor inputs and publishes them in various ways..
The logic is actually pretty simple. In Rules DSL the code would be something like:
rule "Switch toggled"
when
Item MySwitch changed
then
MyLight.sendCommand(if(MyLight.state == ON) OFF else ON)
end
Any time MySwitch changes state then send the command to the MyLight so it toggles from ON to OFF or from OFF to ON. Obviously you would want to make this Rule generic so it can handle all of your switches and lights but the overall approach is the same.
Thanks for the reply. Wiring the switches to be an extension of the ones on the Sonoff would eliminate the need for the second Pi but the way things are wired in the house it would make the physical install much more involved. Most of my setup is using a 4ch so that I can control lights in different rooms. Running the switches to a Pi will let me control any sonoff output from any switch in the house as well as have some switches control multiple switches. I would also need timer relays in the line so that even though the switch was on it wouldn’t “keep the button pushed” non-stop as well. The original play was way more complex and involved relay pairs for each light. OH would control one relay with the switch controlling the other. That would have let either device change the light state. But as I go into it things turned into a wiring nightmare. I would end up needing 3 of the little blue relays per light and require not only the output signal to drive the Pi relay but an input as well so that OH would know the light changed state if someone flipped the switch.
Thanks for the code help. I did look at the Shelly site but they run much more that what the Sonoff’s I already have do. I did think about the problem of the Pi failing but the solution that I could come up with as I was doing the design required much more instillation. Right now it is just me here so I don’t have to worry about having to sleep in the shed if the system goes down with a non-techy partner at home. I am going to have a full software and hardware backup on hand for both Pi systems so that I can swap in a replacement if and when that happens. I am out in the country here so a cloud based solution is not practical either. My only two choices for internet are satellite (worst experience ever!) or AT&T wireless going to a modem that is designed for home use. The second is what I use but I am limited to 100G a month and since all my video and music is streamed, I have to watch my usage. That goes doubly for security cameras. (which is the next step after this is up, integrating them into OH)
But… I would like your thoughts on using something other than Pi as OH server in my case. Would there be a benefit of using an older netbook instead? I could put linux on it and although it would draw more power than a Pi it would use less than a desktop or even a laptop. I am just wondering if that would overcome the hardware failure issue of OH on a Pi server and would the advantage out weigh the additional operating cost per month.
That’s why I recommended the Shellys or print a Sonoff wired to the regular old dumb switches. There is no additional wiring required. You just put the little devices in your junction boxes and boom, you can control them from OH or locally at the physical switch even when OH is down.
The official recommendation for hardware to run oh is what ever you got or whatever you are most comfortable with. Only if you don’t already have something awaiting a job to do or have no preference do we recommend an RPi with openHABian.
Give it a try. As long as the netbook has the same or better specs than an RPi 2 it should be fine for running OH. Just install any Debian based Linux and follow the manual instructions for installing openHABian.
Hindsight being what it is, I agree with you. Using single devices in some of the switches would have made things easier and more bullet proof. But I already have the 4CH ones now so I am going to have to make that work.
After doing some searching around I decided to download Visual Studio Code to try and help me as I learn to write the code for the project. I looked at your code that you linked to and believe that the rpiGPIOConn is the file that I will need to edit and have on the CM3 module to send the state changes out to OH. Is there a way to batch configure inputs on the GPIO? I will be using at least 32 of the 45 that my board has available. They will all be set the same and output to the same broker with the only difference being their individual pin numbers.
Here is the Wiki for the CM board I am using.
https://www.waveshare.com/wiki/Compute_Module_IO_Board_Plus
I don’t want to tie the switches on the CM side to a set light. I just want it to send “input 5 on” or off as it changes. On the OH side is where I will set the rules to read "if status of input X changes toggle (mqtt client msg)
Thanks for all your help.
D
No, you don’t need to edit any code (unless you need something more than commanding a single pin or reading a sensor on a single pin). You just need to populate the config file. For example, here is my config file for my garage controller which has two reed sensors wired to two GPIO pins and two relays wired to two more that I use to simulate a button push. Commands and sensor readings are reported to OH through MQTT.
[Sensor1]
Class = rpiGPIOSensor.rpiGPIOSensor
Pin = 7
Connection = MQTT
Destination = entry_sensors/main/garage/door1
PUD = DOWN
InitialState = UP
EventDetection = BOTH
; StateCallback = path to script
; StateCallbackArgs = script args
Poll = -1
[Sensor2]
Class = rpiGPIOSensor.rpiGPIOSensor
Pin = 8
Connection = MQTT
Destination = entry_sensors/main/garage/door2
PUD = DOWN
InitialState = UP
EventDetection = BOTH
; StateCallback = path to script
; StateCallbackArgs = script args
Poll = -1
[Sensor3]
Class = heartbeat.heartbeat
Type = Heartbeat
Connection = MQTT
Poll = 60
Num-Dest = status/cerberos/heartbeat/number
Str-Dest = status/cerberos/heartbeat/string
[Actuator1]
Class = rpiGPIOActuator.rpiGPIOActuator
Connection = MQTT
Pin = 17
InitialState = ON
Topic = entry_sensors/main/garage/door1/cmd
Toggle = True
; The 0 indicates no polling and no separate thread is needed to run the listener
Poll = 0
[Actuator2]
Class = rpiGPIOActuator.rpiGPIOActuator
Connection = MQTT
Pin = 22
InitialState = ON
Topic = entry_sensors/main/garage/door2/cmd
Toggle = True
; The 0 indicates no polling and no separate thread is needed to run the listener
Poll = 0
[Logging]
File = /tmp/sensorReporter.log
MaxSize = 67108864
NumFiles = 10
Syslog = YES
;Level = INFO
[Connection1]
Class = mqttConn.mqttConnection
Name = MQTT
Client = cerberos
User = rich
Password = password
Host =broker.host
;Port = 8883
;TLS = YES
Port = 1883
TLS = NO
Keepalive = 60
Topic = entry_sensors/getUpdate
LWT-Topic = status/cerberos/lwt
LWT-Msg = OFF
Garage door 1 sensor is on GPIO pin 7, garage door 2 sensor is on GPIO pin 8, garage door 1 relay is on GPIO pin 17, and garage door 2 relay is on GPIO pin 17. The heartbeat sensor is just a message that gets published every so often to let OH know that the script is still running and for how long it has been running.
For the actuators, the Toggle option when set to True will simulate a button press (i.e. LOW for half a second then back to HIGH). If you set that option to False the pin will be set to and kept LOW when the received message is “ON” and LOW when the received message is “OFF”.
The logging section sets up where sensorReporter writes it’s logs and the connection section sets up the MQTT connection.
The rpiGPIOConn was written by another contributor because he wanted a way to control an LED attached to his RPi in response to changes in a Sensor. For example, turn on a green LED when the garage door sensor says the door is open.
All of the config options are documented with comments in default.ini.
That’s all up to you in how you want to configure the MQTT topics. Personally I prefer to have as much smarts at the devices themselves as possible so I would do the mappings between pin number and what light it controls in sensorReporter.
As for batch config, I’m afraid that option is not available. But if you want to just expose all the GPIO pins, then there are other options that just exposes all your GPIO pins that you can control using the HTTP binding or sendHttp*Request Actions from Rules.
Ok, so I have edited the ini file for my inputs. I named it and made sure the name is set in the sensorReporter file. When I try to start with sudo command to test, I get this. What did I probably screw up?
/usr/bin/python: can’t find ‘main’ module in ‘sensorReporter’
Show the command you are running you start it.
sudo python sensorReporter sensorReporter.ini
From which folder are you running this command?
Also, you are missing the .py.
sudo python sensorReporter.py sensorReporter.iniOk, with the .py and running from the sensorReporter folder this is what I got.
Starting…
Loading sensorReporter.ini
Traceback (most recent call last):
File “sensorReporter.py”, line 230, in
main()
File “sensorReporter.py”, line 71, in main
loadConfig(sys.argv[1])
File “sensorReporter.py”, line 207, in loadConfig
configLogger(config.get(“Logging”, “File”),
File “/usr/lib/python2.7/ConfigParser.py”, line 607, in get
raise NoSectionError(section)
If I replace
import RPi.GPIO as GPIO
with
import wiringpi
in the rpiGPIOSensor file will it use the wiring pi numbers instead? Since this board has a non-standard layout BCM numbering doesn’t cover all the pin’s available.
It is unlikely that the wiringpi library works exactly the same as the RPi.GPIO library so you will likely need to largely rewrite the whole rpiGPIOSensor file.
Thanks for the help. I tried to get it to integrate but the pins just didn’t want to work correctly. I did find a solution however. There are OpenHAB integration nodes for node-red. They let you send and receive from a Pi running node-red to another Pi that is running and OH server. Setup is super easy and no coding required. It talks right to the web page port of OH and lets you select the item to send or receive from when you are setting up the node.