Wired opening sensor integration

Hi There,

I am running OpenHab 4.2.1 on a Raspberry Pi 4 4GB and at the moment I am about to plan the wiring / smarthome of a single family house. The wiring of the building has still to be done, so that is not a problem, but an opportunity.

I tried to find an easy, quite cheap and energy saving solution for each task :

So far I have:

  • lights, power outlets and shutters via z- wave ( not all of them, for sure. Most stuff will be wired and prepared for a receiver. Most shutters will be wired as well, just what I need )
  • sun and wind for shutters / raffstores via Eltako and FGBS-222 ( 3 imputs )
  • Fingerprint on ESP 32 with Door Bell and Opener via mqtt and FGBS Smart Implant ( 2 outputs )
  • Axis Camera that thats pictures on ringing / opening and send it via Pushover
  • wired 12V smoke sensors with wired sirene with battery backup via FGBS-222 ( 1 input )
  • 12 DS18B20 sensors via FGBS-222
  • Garage door opener via 2 third FGBS-222 with 2 inputs ( endlimit ) and 1 output ( toggle switch ) as well as numeric keypad with RFID
  • some 12V Slim Relais, mostly for FGBS, movement, smoke

It works quite well on a small board so far.

Now I want to add some opening sensors, at best for all windows, maybee doors…
And now, I am looking since some days without finding a nice solution.

My best thought is to have 20-30 12V slim relais ( I think, that would work quite good with low energ consumption ), an esp32 withsome I2C extensions and mqtt
But then I would have about 40-60 rules, just for this stuff. Is this too much?

Is there a better way? Could I use the RaspBerry itself? Should I use a wireless solution?

Thank you very much for your time

Personally, I’d just use Zigbee contact sensors. I’m very happy with IKEA’s new PARASOLL sensors.

Nothing wrong with hardwiring, but I suspect that will cost you a lot more for all of the installation work.

Hi rpwong,

thank you very much for your input.

The price for 1 window is lower than 5 €:

Opening Sensor

Slim Relais

As I use wires like that, there are no special costs for those 2 wires from the window to the DIN rail:

Wire Example

If you are creating 40-60 rules “just for this stuff” you are likely missing opportunities to combine logic and rules. You should be able to write one rule to handle all of the open sensors.

Since you have opportunity to run wires, you have the opportunity to avoid battery powered devices. If you run low voltage wires like you link to to each window you can use cheap magnetic reed sensors (a pack of 5 < $10 US) and an RPi, ESP, Arduino, etc. These will work with standard 3.5v output by the RPi so no voltage converters would be required.

The come in all sorts of form factors. My favorite for doors are the ones the fit in a hole you trill in the top of the door.

Also if you’ve several sensors in one location you can run one power cable that you split to each of the sensors and then only need one wire coming back for each sensor.

Of course you’ll need to compare the up front cost of running the wires with the long term time and cost of keeping up with battery replacement.

I was referring to labour costs for installation, but that wasn’t clear. If you’re doing it yourself, labour isn’t a cost factor, just a time factor.

Thank you very much for your reply.

Yes, I was planning to use some of those cheap reed contacts / magnetic sensors. I am still searching for a product, that fits in the window frame/reveal ( like the slim opening sensor io from Somfy ).
I do not really like batteries, but as there will be enough wires for sure for everybody.

Do you think, those 3.3V from RaspBerry’s GPIO ( maybe with I2C extension ) are powerful enough? There are several dozen meter on 3 floors. This was the only reason, I was choosing a higher voltage.

So my further questions would be:

  • is the voltage of 3.3V enough for those long ways through the whole house?
  • if I use my RaspBerry directly, I will need the GPIO binding. Is my “problem” with logic and rules the same here? Maybe you could give me a good hint for the one rule to rule them all?
  • it should not make any difference, if I use an I2C bus to have more PINs?

@rpwong my bad. I didn’t explain it good enough. I have 3 friends ( retired electricians ) to do the labour stuff ( they say, 1 day only ) and I get the wires and needed Fibaro devices for net purchase or free. The rest of the stuff is already purchased and mounted on a test wall.

My main goals are to stay as simple, reliable and cheap as possible, hopefully energy saving and that kind of automated, that I don’t have to intervene manually. I’m open for every suggestion

So what you’re saying is it’s a beer cost? :wink:

I would guess no, due to voltage drop. This might be helpful.

I have a pair of magnetic reed sensors on my garage doors that I run off of an RPi 3. Ran them off of an RPi 1b before that. They work fine.

There was a security system installed in my house prior to moving in and there were a bunch of sensors about with wires all leading to the basement. I was able to get the reed sensors working with the 3.5v GPIO on an RPi 0w.

Note, I’m not doing I2C. Each sensor is direct wired to the GPIO and I use GitHub - rkoshak/sensorReporter: A python based service that receives sensor inputs and publishes them in various ways. to publish their state to MQTT. I don’t know if I2C will impose other problems/ restrictions.

If I were to do it over again (and I plan on doing so some day), I’d use ESP8266 or ESP32 instead of RPis to push the sensor states to MQTT. But I’ve been running with the RPis for about seven or eight years now without problem.

Not necessarily. See above for one solution. There’s several other options. You don’t need to mess with the GPIO stuff directly by OH. That’s not always practical anyway (e.g. the wires may not be where you want to run OH).

As for one rule, it largely depends on what you want to do in that rule. See Topics tagged designpattern for lots of different ways to make a rule to handle lots of different Items.

For one simple example, let’s say you want to send an alert if a sensor remains open for too long.

  1. Put all the open/closed sensors into a Group
  2. Create a rule that is triggered by any member of the Group created in 1 changing.
  3. In Blockly using openHAB Rules Tools [4.1.0.0;4.9.9.9] (which implements a lot of the Design Pattern posts):

It doesn’t matter if you have one sensor or 100, this one rule will log out if any one of them remains open for more than five minutes.

In JS Scripting the same rule, without using the OHRT library’s TimerMgr would look something like:

var timer = cache.private.get(event.itemName);
if(event.itemState.toString() == "OPEN") {
  timer?.cancel();
  cache.private.put(event.itemName, actions.ScriptExecution.createTimer(time.toZDT('PT5M'), (itemLabel) => {
    console.info(itemLabel + ' has been open for more than five minutes!');
  }, items[event.itemName].label);
}
else {
  timer?.cancel();
}

These ten lines of code can handle all your open sensors (assuming you want them all to behave the same way). Note, I’m using a brand new feature added to the openhab-js above that allows us to pass variables into the timer function.

There are also rule tempaltes that can handle these. For example, you can install and instantiate Threshold Alert and Open Reminder [4.0.0.0;4.9.9.9] with:

  • Triggering Group: the Group created in 1 above
  • Threshold State: OPEN
  • Alert Delay: PT5M
  • leave the rest of the properties at their defaults

This handles all your open sensors and you don’t have to code the rule. And as a bonus the rule template supports repeating the reminder, customized properties on a per Item basis, and a do not disturb period, all for free. All you need to do is write the code that responds (e.g. send the alert) when the sensor is OPEN for too long.

It depends on the distance of course. I can say they work for me with wires in the 30’-45’ range (really rough estimate, I can’t say I really know how these wires are routed). At least the magnetic reed sensors do. Since they operate with a simple open/close circuit just enough voltage needs to get through for the GPIO to pick up (1.8v for RPi, don’t know for ESPs). We aren’t powering LEDs here, just detecting if the circuit is open or closed so we have lots of room for voltage drops.

Feeding in what I know about the RPi GPIO specs (3.5v, 50mA) assuming PVC conduit, 8AWG copper wiring, and DC power of course, there’s only a drop of 0.11% in voltage over 500’. Obviously @derHerrdesSchreckens should put in their actual wire specs but as I mess around I can’t get more than a percent drop over 500’.

tl;dr: you it’s probably going to work for simple reed sensors.

1 Like

I guess, using this guthub sensor reporter is far beyond my skills at the moment, but thank you very much for your input on the rules side. Maybe, I look for templates first and have another honest look at blockly. To be honest, that was a little bit too much, I will read this post and the links several more times in the future, I think.

This should make one think :slight_smile:

Regarding the calculator, AWG8 is 8mm². We should better look at AWG18, which is similar to an YSTY X x X x 0,8mm, which is a kind of good standard. In the estimated resistance part, we get around 35m until the voltage falls under 1.8V. That’s a really nice distance in theory. Per floor, I guess it will be more than 35m.

Maybe I will test it with some cable that I have here for testing purposes. But since all the wires will meet again in a fuse box, it is no problem for me to change to 12V or find a good spot for the RaspBerry, if there is a chance to use it directly.

The wire specs - without big thinking would be 3 kind of wires:
NYM 5x1.5 for 230V
YSTY 2x2x0.8 for the single devices
YSTY 10x2x0.8 for the common ways to the floors and rooms ( maybe 20x2x0.8 )

If you can set up and user openHAB, you can set up and use sensorReporter. In most respects it’s much simpler to use than OH is. And while I use it with MQTT, it has a plug-in to update Items in OH directly, nothing else is required.

And of course you have the original author of it right here if you run into trouble to ask questions from.

There’s an installation script now that installs everything need to run. Once installed you just need a relatively simple config. Here’s the config that runs my garage door openers (two openers, two reed sensors, MQTT configuration).

Logging:
    File: /tmp/sensorReporter.log
    MaxSize: 67108864
    NumFiles: 10
    Syslog: YES
    Level: INFO

Connection1:
    Class: mqtt.mqtt_conn.MqttConnection
    Name: MQTT
    Client: cerberos
    User: username
    Password: password
    Host: MQTT_broker_host
    Port: 1883
    TLS: NO
    Keepalive: 60
    RootTopic: sensor_reporter/cerberos
    Level: INFO

SensorLargeGarageDoor:
    Class: gpio.rpi_gpio.RpiGpioSensor
    Connections:
        MQTT:
            Switch:
                StateDest: garagedoor1/state
    GpioChip: 0
    Pin: 7
    PUD: DOWN
    Btn_Pressed_State: HIGH
    EventDetection: BOTH
    Level: DEBUG

SensorSmallGarageDoor:
    Class: gpio.rpi_gpio.RpiGpioSensor
    Connections:
        MQTT:
            Switch:
                StateDest: garagedoor2/state
    GpioChip: 0
    Pin: 8
    PUD: DOWN
    Btn_Pressed_State: HIGH
    EventDetection: BOTH
    Level: DEBUG

ActuatorLarageGarageDoor:
    Class: gpio.rpi_gpio.RpiGpioActuator
    Connections:
        MQTT:
            CommandSrc: garagedoor1/cmd
    GpioChip: 0
    Pin: 17
    InitialState: ON
    SimulateButton: True
    Level: DEBUG

ActuatorSmallGarageDoor:
    Class: gpio.rpi_gpio.RpiGpioActuator
    Connections:
        MQTT:
            CommandSrc: garagedoor2/cmd
    GpioChip: 0
    Pin: 22
    InitialState: ON
    SimulateButton: True
    Level: DEBUG

That’s it. with that I can configure OH to subscribe to an MQTT topic and see when the doors are OPEN or CLOSED and send a message to a different MQTT topic to trigger the garage door openers. It’s even simpler with a Homie config as OH can automatically discover those and of course, sensorReporter can talk to OH directly instead of going through MQTT.

1 Like

that sounds uplifting. I will receive some I2C expanders these days and then I try to set up the sensorreporter. I saw an I2C folder there.But “installation script” really sounds way different now.

I just did a quick try with a 0.8mm² cable, 10m, one contact. Worked very well on the ESP itself. But this needs to be more stressed out.

I totally know to whom I’m talking, I don’t type, but I read quite a bit on these sites. It is not the first time,you gave me a good hint. You helped me dozen times before. Thank you. I will come back after some more trial & error.

1 Like