Best way to implement rollershutter control - Choosing hardware!

Hi!

I’m building a house and I decided to make my own automation control. Being a big fan of the Raspberry, I searched for options and sure enough I found OpenHAB. After a few days of tinkering and going back and forth with some bugs, I have an initial setup from which I can build on, I think.
The house is simple and I want to keep the system as simple as possible. Only a ground floor with a garage/man cave, an open space kitchen/living room, an office, three bedrooms and two bathrooms, and the garden.

For now, what I really need to implement is the roller shutter control. I have an electrical box in a wall where all the roller shutter local wall switches and motor conduits lead to. The OpenHAB raspberry will be inside this box with two 8-relay boards.
I am planning on using the GPIO on the raspberry to control the outdoor garden lighting and some other things.

Now, for the roller shutters - There are a total of 13: 12 outdoor roller shutters, and one indoor roller blackout.
To keep it cheap and seeing I have wired access to all the the wall switches, I could use some a couple more raspberry’s (I have quite a few), hooking GPIO outputs up to relays and connecting the wall switches as GPIO inputs. The these “slave” RPi’s could communicate with the OpenHAB RPi over MQTT maybe.

A similar approach could perhaps be using ESP8266 modules with NodeMCU or ESPEasy and having these talk to OpenHAB through MQTT.

A more ready to use approach could maybe be ZWave? This would bring the cost significantly high, but perhaps it’s more reliable and easier to implement? Also easier to grow the system over time?

Any suggestions? Any other brand or automation system that has shutter controllers that may be cheaper or has other advantages?

Currently I have an RPi2 running Wheezy and the latest openhab 1.8.3. Started on Jessie but found out about the GPIO input issue and so I rolled back to Wheezy.
The GPIO and weather bindings are working well.

In time I would like to add to the system, maybe some Hue and Wemo devices, controlling heating etc. but for now I really need to make a decision on the roller shutters so I can start ordering hardware and hooking things up.

Thanks!!

If you have the option of wired I would go with a fit approach. I think it will be cheaper and more reliable in the long run. However, wired is harder to expand but luckily OH supports almost 150 technologies. You won’t be stuck with just one.

Accessing and controlling the GPIO pins from Python is pretty trivial so I have a script that triggers the pins based on MQTT messages and reports their state over MQTT fit sensors. This would make it easy to support GPIO with the problems from the binding and support remote Pis (remote Pi is why I wrote it).

This isn’t too day that there are not other commercial options that are very reliable and easy to set up, but if you already have the wires this is one case where I think DIY can be nearly as easy and reliable.

1 Like

Hey Rich,

Many many thanks for your help.
My openHab Rpi2 is running as an MQTT broker, I can connect to it both on my laptop and locally on the openhab rpi.

I’ve been trying to setup a second raspberry to run your script, but haven’t had much luck.
I’m having a hard time understanding the documentation.

Started with a clean Wheezy install and ran:

sudo apt-get install python-pip

sudo pip install paho-mqtt

mkdir sensorRep

cd sensorRep/

wget https://github.com/rkoshak/sensorReporter/archive/master.zip
unzip master.zip
mv sensorReporter-master/ sensorReporter
cd sensorReporter/

sudo ln -s `pwd` /opt/sensorReporter

chmod a+x /opt/sensorReporter/sensorReporter.py

ln -s $HOSTNAME.ini /opt/sensorReporter/sensorReporter.ini

sudo cp ./config/sensorReporter /etc/init.d

sudo update-rc.d sensorReporter defaults


This is what sensorReporter.ini is looking like:

[Sensor1]
; Native Raspberry Pi Library
Class: rpiGPIOSensor.rpiGPIOSensor
Pin: 18
Connection: MQTT
Destination: sensor1/topic
PUD: DOWN
Poll: 0.5

[Actuator1]
Class: rpiGPIOActuator.rpiGPIOActuator
; The chosen connection must support a register(path, handler) method the actuators can call
; to receive specific incoming messages. See mqttConn.py for an example
; restConnection is not supported.
Connection: MQTT
Pin: 4
Topic: actuators/actuator1
; When true set the pin to ON for half a second then turn off, otherwise switch the pin from one state to the other
Toggle: True
Poll: 0

[Logging]
File: /var/log/mqttReporter.log
MaxSize: 67108864
NumFiles: 10
Syslog: NO

[Connection1]
Class: mqttConn.mqttConnection
Name: MQTT
User =
Password =
Host = 192.168.1.105
Port = 1883
Keepalive = 60
; Topic to listen on, when any message is received, the current state of all
; are published to their respective topics.
Topic = sensors/getUpdate
; The MQTT broker will publish the following message on the following topic
; when the client disconnects (cleanly or crashes)
LWT-Topic = status/sensor-reporters
LWT-Msg = mqttReporter is dead
; If TLS is yes the connection will be encrypted, the Certificate is expected to be in
; ./certs/ca.crt"
TLS = NO

But so far not working… I have no user or password for the MQTT broker.
Tailing mqttReporter.log only tells me this:

2016-10-15 23:09:55,364 INFO - Unexpected disconnect: code = 1 reconnecting
2016-10-15 23:09:56,376 INFO - Disconnected from the MQTT broker with code 1
2016-10-15 23:09:56,379 INFO - Unexpected disconnect: code = 1 reconnecting
2016-10-15 23:09:57,391 INFO - Disconnected from the MQTT broker with code 1
2016-10-15 23:09:57,394 INFO - Unexpected disconnect: code = 1 reconnecting
2016-10-15 23:09:58,406 INFO - Disconnected from the MQTT broker with code 1
2016-10-15 23:09:58,409 INFO - Unexpected disconnect: code = 1 reconnecting
2016-10-15 23:09:59,421 INFO - Disconnected from the MQTT broker with code 1
2016-10-15 23:09:59,427 INFO - Unexpected disconnect: code = 1 reconnecting
2016-10-15 23:10:00,438 INFO - Disconnected from the MQTT broker with code 1
2016-10-15 23:10:00,442 INFO - Unexpected disconnect: code = 1 reconnecting
2016-10-15 23:10:01,453 INFO - Disconnected from the MQTT broker with code 1
2016-10-15 23:10:01,457 INFO - Unexpected disconnect: code = 1 reconnecting

Broker doesn’t receive anything from sensorReporter.
Any ideas? Did I mess up somewhere?

Thanks!

Hey again Rich!

I’ve been tinkering about and it’s sort of working.

I defined a username/password in my mosquitto.conf broker config for v3.1 MQTT compatibility, and modified this line in your mqttConn.py:

self.client = mqtt.Client("", True, None, mqtt.MQTTv31)

It’s reporting sensor status well, but when the daemon starts the LED connectd to actuator1 lights up, when I then sen an ON or OFF command it always behaves the same way: it turns of for half a second and turns back on, despite the log registerinf the appropriate reaction to the command.
It’s always on after I restart the sensorReporter daemon, and briefly turns off wether my command is ON or OFF, turnin back on after that.
This is the log now:

2016-10-16 00:13:24,584 INFO - Received a request for current state, publishing
2016-10-16 00:13:24,586 INFO - getting states
2016-10-16 00:13:24,591 INFO - ----------Configuring rpiGPIOSensor: pin 18 on destination sensor1/topic with PULL DOWN
2016-10-16 00:13:24,599 INFO - Published message OPEN to sensor1/topic
2016-10-16 00:13:24,608 INFO - ----------Configuring rpiGPIOActuator: pin 4 on destination actuators/actuator1 with toggle True
2016-10-16 00:13:24,610 INFO - Registering for messages on actuators/actuator1
2016-10-16 00:13:24,615 INFO - Kicking off polling threads...
2016-10-16 00:13:36,717 INFO - Received command on actuators/actuator1: OFF Toggle = True PIN = 4
2016-10-16 00:13:36,720 INFO - Toggling pin 4 HIGH to LOW
2016-10-16 00:13:37,223 INFO - Toggling pin 4 LOW to HIGH

Any idea?
Thanks!!

It sounds like the pin you are using is opposite to the way my relays worked. Try swapping the HIGHs and LOWs in the rpiGPIOActuator.py class and see if that makes a difference. If that fixes it I’ll make the configurable.

I’ve never tried the MQTT connection without a user and password so I’m not surprised it didn’t work. I do recommend ashtrays having it though so an not sure how high a priority I would place on making it work. But ilk capture that as an issue on github next time I can sit at a computer.

Thanks again for your input!

MQTT is working, I just need to set it up so mosquitto runs on boot.
I can connect and interact through MQTT.fx.
I can see in the log the openhab apparently connects to it:

1476626095: New client connected from 127.0.0.1 as mosq_sub_3209_codhab.
1476627440: New connection from 192.168.1.107.
1476627440: New client connected from 192.168.1.107 as paho/0A4F6DDF1700D9DF77.

But I can’t seem to get openHAB to do anything. Trying to read the sensor or switch the actuator, but having no luck. I see nothing being published by openhab on the topics. Here are my items&sitemap:

Items:

Switch         MySwitch                                 (Luzes)            {mqtt=">[mybroker:/actuators/actuator1:command:ON:1],>[mybroker:/actuators/actuator1:command:OFF:0]"}
Contact     sensor1             "Sensor 1 [%s]"     (gSensores)     {mqtt="<[mybroker:/sensor1/topic:state:default]"}

Sitemap:

               Switch item=MySwitch
               Text item=sensor1

and the config file:

# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883
mqtt:mybroker.url=tcp://localhost:1883

# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a default one is generated.
mqtt:mybroker.clientId=openhab

Any clues to where I am going wrong?

Cheers!

Everything looks right at a glance but I’m not great at debugging MQTT problems. A couple of minor things are that at least according to the Mosquitto site, topics shouldn’t start with a leading “/”. I don’t remember why, just that they recommend against it.

Do you see in openHAB;s log that it is connecting to the broker? Those client IDs in your mosquitto log don’t look right to me. After all, you are explicitly setting the clientId to “oepnhab” so I would expect to see “New client connected from … as openhab” or the like.

1 Like

Managed to get it working. OpenHAB wasn’t authenticating correctly with the broker.

As for sensorReporter, I’m tuning it for my setup, I tried setting the “Toggle” to false but to no avail, Toggle is always set to true no matter what I do. I’ve tried using “0” instead, but it’s not working.
Python isn’t my strong suit, so probably something obvious getting by me.

If nothing else, I can remove that section entirely and just have it do what I want, but makes it a bit less flexible in the future.

log:

2016-10-17 11:12:01,517 INFO - ----------Configuring rpiGPIOActuator: pin 4 on destination actuators/actuator1 with toggle True
2016-10-17 11:12:01,519 INFO - Registering for messages on actuators/actuator1

rpiGPIOActuactor.py:

        GPIO.output(self.pin, GPIO.LOW)

        self.destination = params("Topic")
        self.connection = connection
        self.toggle = bool(params("Toggle"))

        self.logger.info('----------Configuring rpiGPIOActuator: pin {0} on destination {1} with toggle {2}'.format(self.pin, self.destination, self.toggle))
        self.connection.register(self.destination, self.on_message)

    def on_message(self, client, userdata, msg):
        """Process a message"""
        self.logger.info('Received command on {0}: {1} Toggle = {2} PIN = {3}'.format(self.destination, msg.payload, self.toggle, self.pin))
        if self.toggle == True:
            self.logger.info('Toggling pin %s HIGH to LOW' % (self.pin))
            GPIO.output(self.pin, GPIO.HIGH)
            time.sleep(.5)
            GPIO.output(self.pin, GPIO.LOW)
            self.logger.info('Toggling pin %s LOW to HIGH' % (self.pin))
        else:
            out = GPIO.HIGH if msg.payload == "ON" else GPIO.LOW
            GPIO.output(self.pin, out)

sensorReporter.ini actuator portion:

[Actuator1]
Class: rpiGPIOActuator.rpiGPIOActuator
; The chosen connection must support a register(path, handler) method the actuators can call
; to receive specific incoming messages. See mqttConn.py for an example
; restConnection is not supported.
Connection: MQTT
Pin: 4
Topic: actuators/actuator1
; When true set the pin to ON for half a second then turn off, otherwise switch the pin from one state to the other
Toggle: False
Poll: 0

Cheers!

I only use toggle right now so don’t really have opportunity to debug the non-toggle code. The code uses the standard Python bool() function to parse the parameter into a boolean. I would expect it to support everything you have tried already so I’m not sure what is going on. The code is pretty straight forward:

    self.toggle = bool(params("Toggle"))
    ...
    if self.toggle == True:

I’ve done similar in other Python code and it worked just fine. This is indeed off.

When sensorReporter first starts up it prints a line '-------------------Configuring rpiGPIOActuator: …` to the logs. What does it say on this line for “toggle”?

The weird thing is by default if there is an error bool() is supposed to return False, not True so that point at there not being an error. Perhaps the .ini file is not being parsed correctly.

The only thing I can think of is to try changing the if statement to:

if self.toggle:

or remove the bool( ) and just treat self.toggle as a String

    self.toggle == params.("Toggle")
    ...
    if self.toggle == "True":

The above change will treat everything else, including “true” as False and the toggle should not run.

1 Like

Hi there!

I ended up replacing that whole section, eliminating the toggle statement. It runs well now.

    def on_message(self, client, userdata, msg):
        """Process a message"""
        self.logger.info('Received command on {0}: {1} Toggle = {2} PIN = {3}'.format(self.destination, msg.payload, self.toggle, self.pin))
        if msg.payload == "ON":
                out = GPIO.HIGH
                self.logger.info('Toggling pin %s LOW to HIGH' % (self.pin))
                GPIO.output(self.pin, out)
        else:
                out=GPIO.LOW
                self.logger.info('Toggling pin %s HIGH to LOW' % (self.pin))
                GPIO.output(self.pin, out)

At the moment I have the basis for creating the system. I can read and write to GPIO’s locally on the OpenHAB RPi, remotely on the sensorReporter RPI’s, and remotely on my ESP8266 modules running ESPEasy.

Now, the next step is figuring out how to implement control of roller shutters using this hardware and relay boards.

I’m thinking I will need 2 relays for each roller shutter, but I figure I can wire them in at least two different ways, according to whatever best suits my needs and what is possible in openhab.

Now, I need to figure out how I can create items and rules so that I can raise, lower or stop.

Ideally I could use rules to set raising and lowering times to switch off the relays once the rollers are completely up or down. I have something very rudimentary like this but it would need to be improved or completely changed:

Items:

Contact     Roller_Wall_Switch         "Roller Switch [%s]"    (gSensores)        { gpio="pin:18" }        
Switch        Roller_Out              "LED"                    (Luzes)            { gpio="pin:4" }         
Switch       Roller_Timed                                     (Luzes)        

Rules:

rule "LED"
when
  Item Roller_Wall_Switch changed
then
  if (Roller_Wall_Switch.state == OPEN) {
    Roller_Out.sendCommand(ON) }
  else {
    Roller_Out.sendCommand(OFF) }
end

rule "Test"
when
    Item Roller_Timed received command ON
then
    var i = 0
    while((i=i+1) < 3) {
        sendCommand(Roller_Out, ON)
        Thread::sleep(10000)
        sendCommand(Roller_Out, OFF)
        Thread::sleep(10000)
        sendCommand(Roller_Timed, OFF)
    }
end

Sitemap:

               Switch item=Roller_Out
               Text item=Roller_Wall_Switch
               Switch item=Roller_Timed

Any suggestions on how best to implement this control? Rollershutter items? Regular switches?
A slider to set how much raise time/percentage?

Any ideas are appreciated! Thanks!

Hi. I went with 2 relay configuration, one for power, other for direction. It’s the safest way.

My specs where both local and remote control (for maximum WAF), so I did 8266 in each roller, all communicating with MQTT.

Each 8266 resets on poweron to the lowest end, and I have timed each roller from top to bottom. With some tricks and a lot of ugly arduino code on the 8266, it works like a charm. Even reporting % to OpenHAB.

I can share my code if you wish.

1 Like

Hi Guillermo!

Thank you very much, I will take all the help I can get!
It would be awesome if you could share your code!

I can use ESP8266’s modules, but seeing as I have all the local switches and roller motors going to a centralized electrical box, I was planning on using Raspberry’s insteads. If I can’t, I don’t mind going with ESP’s.

I wanted to implement the UP/DOWN/STOP and % timing control in OpenHAB, keeping the clients simple - just switching GPIO’s ON and OFF. That way if I ever need to make changes I can just do them in OpenHAB and not have to repeat them a bunch of times in Raspberry’s or ESP’s.

On the other hand, it might be simpler on OpenHAB’s side if I just modify Rich’s script to accept UP/DOWN/STOP instead of just ON/OFF.

So, if you can share your code I would be very grateful, I am sure I can learn a lot regarding how I could implement the items and rules in OpenHAB, and perhaps try your way, with ESP’s as I also have a few blackouts I would like to control but aren’t routed to the “automation” electrical box.

Thanks again!

There are obviously those 2 strategies, centralized vs distributed. You
already have the difficult part which is the pipes. I hadn’t and then I
took other decisions, like allowing the blinds to function normally without
openhab running. It gives me more peace of mind.

But regardless of the strategy, the up/down and position % is the same. You
have to take the time for the full ru, then estimate the position. It
recalibrates itself every time you go 0% or 100% (by letting it run a
little more).

I’m trying to attach my arduino (for 8266) code. It’s a little messy
because I added MQTT and some sensors, and a switch for lighting.

Regards

1 Like

That’s a good point, what you mentioned about being able to use the shutters without openhab running, hadn’t thought of that. So maybe not a bad idea to use the ESP’s, even if I keep them all in the centralized electrical box.
Really looking forward to being able to check out your code.

If I use ESP’s I’ll have to order a few more as I don’t have enough, but everything else I either already have or is on it’s way: power supplies, raspberries, relay boards, cables etc etc.

I’m going to assemble a complete panel with everything on it, just slightly smaller than the electrical box, so I can test the whole system offsite and once it’s ready I’ll just install the panel inside the electrical box and connect all the wires.

Thanks for everything! Let me know if you want an email address in case you can’t attach it here.
Cheers!

Having ducts (which I envy you), I would go with something simple like
arduinos and ethernet at each roller

The Wi-Fi on the 8266 has it’s glitches

I have sent the code, but not sure if it’s visible

2 Likes

I have 10 Roller Shutters in my home and all controlled by Z-wave relay modules - Fibaro or Duwi. Benefits of those is that you install them behind your existing wall switches and connect switches to their inputs, so local control remains as it is with addition of remote control.
So far I did not have any trouble with them except one time healing I have to perform since I installed many new modules.
I would suggest this approach - Z-wave + USB Z-Stick + Raspberry. It is better from overall system availability: In case of GPIO if your Raspberry fails for whatever reason, it will cause you to search for another Raspberry, because you are using specific hardware interface.
In case of Z-wave you just take away USB Stick, insert it into another PC or laptop and run OpenHAB there. It will work - I tested it couple of weeks ago, and it did take me something like 15 minutes to setup everything, and I have a little bit more than just OpenHAB - Node-RED and Mosquitto. Off-course all my configuration files were cloned to the cloud, so I just checked them out. So next time it will be just a matter of seconds.

1 Like

Actually GPiO is pretty standardized across all the board computers so that isn’t that big of a problem.

1 Like

Guillermo shared his code for the ESP and after cutting some unnecessary (in my case) bits out, it’s working well.

Hardware wise at the price things are, it’s quite easy and cheap for me to have spare RPI’s (I have more than I need) and cloned microSD cards to replace instantly if it goes wrong.

The fact that I can ssh into each RPi is also cool, I don’t need to physically connect the computer or pull out modules to program them. Just log in, make the adjustments I need and log out.

I just need to adapt Rich’s sensorReporter to be more like Guillermo’s ESP code. In the end I’ll probably end up using both solutions, the RPi’s in the electrical box and a few ESP’s in points where I don’t have ducts to.

It’s going well with the help of you incredibly helpful people.
In the end I’d like to share what I did, for that perhaps someone may also save a few hours of sleep, just not sure what’s the best way/platform to share the code.

Thanks again! Further news when I make progress!

2 Likes

Hi Jose and Guillermo,

I’m really interested in the code you mentioned. I’m using a Raspberry Pi with a 8-relay board and also using the GPIO to control the relays. I have four roller shutter motors which I plan to control like this. Until now I was able to control one of the GPIO pins with OpenHAB2 by defining it as a switch item. Now I’m looking for the necessary OpenHAB configs to define those four roller shutters. I also need code to control the percentage of how far to close the shutters. It sounds like this is what you created, I would be very thankful to get your code.

To your question Jose of how to share the code publicly, would GitHub work for this?

Greetings,
Daniel

I will give you one low budget tip:
2x Sonoff 4ch with custom firmware. you can use mqtt to comunicate with openhab, and use the buttons to control the rollershutters.
Regards

1 Like