What did you build/automated today (with pictures)?

I’m loving this face recognition stuff. Seeing as my house generally has people in and out the same door it really changes how occupancy can be used

Given it’s accurate and cannot be cheated… :slight_smile: I have yet to see how many times this setup correctly identifies people… will get back and update once we have some flying hours under our wing.

Did you ever try if a stranger (i.e. not known by your system) can walk in just holding a printed picture of you (e.g. from a social network) in front of the camera? (Or even on a tablet screen.)


Thats exactly the reason i would not use if for security applications in my HA setup. e.g. never use it to open doors, disable alarms etc. The use cases i would support are generally the ones that are already described (e.g. doorbell, presence detection)

Makes sense :wink:

Gate Adventures

Moderators: I wasn’t sure whether to post this here, or in its own thread. I knew it would be a huge post. Feel free to move it to its own thread if you should so choose.

I just finished phase 2 of my gate project today. This project is near and dear to me because it is the reason why I got into microcontrollers (arduino/esp8266) just three months ago, and it has opened up a whole new world for me. This has been a huge project, and it’s not over yet, but I’m loving it.

So, this is my street-side gate.


It looks pretty normal, but there’s one thing that makes it unusual… it’s two gates, one from either side.
This is not a common configuration at all here but space constraints dictated this solution. I kind of like it. It looks cool, it opens twice as fast as a single gate, plus the fact that it opens from the middle so that a car or motorbike can slip through before it’s even fully open makes it even faster still. :slight_smile:

The gate systems are from E8, and the control board model is D2. Catchy names all around, I say.

There’s one slight issue though. The two systems are completely separate. There’s no factory supported way to link them. They’re intended to drive one gate, that’s it.

I was worried the installer might do something silly like install a separate remote receiver for each gate, which would have meant that the gates could get out of sync, so I made sure he used a single 315 MHz remote receiver with the relay output hardwired to both gates. He did just that, so I figured that would be that.

In theory, if you’re always triggering both gates, barring a physically obstructed gate, they should remain in sync.

In practice, there are two variables missing from the initial theory.

  • The gates travel at slightly different speeds
  • When one gate is close to the end of its travel, it starts braking, and ignores commands since it’s already braking.

So, if you hit the remote at just the right time, this is what you get.


You may ask, how often would that happen in reality?

My friend, if you know anything about Mr. Murphy and his law, you’ll know that it happened all the freaking time. Except when you wanted to show the installer, obviously.

Usually it happened when, already having driven through, someone would push the remote to close the gates after them.

I was able to show the installer, but he did not have a solution. It wasn’t a matter of throwing more money at the problem – no matter what, to him it was an absolutely impossible problem to solve.

At first, the only way to get them in sync again was for me to physically obstruct one gate to make it reverse direction. I then asked the installer to make the second remote button trigger only one of the gates, so we could at least sync it back up manually.

He did that, and it worked well enough, but it’s still a crummy solution. We used it like that for a few months but I knew I wasn’t going to be happy with that forever. So, that’s when I decided to take matters into my own hands. Down the rabbit hole we go.


This is what one of the circuit boards looks like in action.
There are some useful signals there. After staring at it for a while, I figured out that the four relays are: OPERATE, FULL SPEED, OPENING, CLOSING.
There’s also the pulse counter that comes from the motor, to let it keep track of where it is… and a signal that indicates whenever someone crosses the infrared beam between the gates… and an overload LED which is deduced from the power consumption of the motor. Note that this system does NOT use any actual position switches… it’s all done with the pulse counter. The gate remembers where it stopped last time, and brakes just in time to close nicely and softly.

At first I figured there might be a simple way to make the gate controllers lock each other out just by relays.

Then I remembered that I’m a programmer.

Phase 1

After consulting a friend, I ordered my first few NodeMCUs and a few surrounding components. While waiting for those, I wrote a gate simulator. Some people may find flight simulators more interesting, but personally, I love me a good gate simulator!


I figured that once I have a simulation of the gates in software, I can write and perfect an algorithm to control the simulated gates in a familiar environment and without leaving my chair. So, I did!

There aren’t all that many signals. There’s Opening, Closing, Counter for each gate, so that’s 6 inputs, plus the beam makes 7, plus the existing remote makes 8, and two outputs – one for the relay trigger input of each gate.

I figured this should be doable on a single NodeMCU (ESP8266) without any expansion besides optocouplers, and set out to wire up a prototype.

Now, mind you, this is NEW territory for me. I played with electronics a bit as a kid, but it’s been almost all software ever since. I had never done anything like this before. Still, it’s never too late to learn a new skill!

So here’s my initial breadboard prototype.

I’ll be the first to admit it looks horrendous, but it was a start, and I did get all the inputs and outputs to work on a single ESP8266, as well as the software! So, it was time to start making the actual circuit boards.

Before doing that, though, I did a feasibility check by counting the number of wires between the left and right gates. I knew there was a CAT5e cable between the two, used for the relay closure… so that’s four pairs. Opening/Closing/Pulse/Remote. Four pairs is all I need!
And then I realized I had forgotten the IR beam signal. Damn it! So I’m short one pair.

What’s an engineer to do? Run another cable?

Heck no. This seemed like a great opportunity to use RS-485 for the first time!

It took some doing, but after some days I had the master and slave systems communating bidirectionally on ONE pair. Single-pair communication over RS-485 is just like a pair of walkie talkies, you can totally have a conversation as long as you make sure not to talk over each other. I wrote my own little protocol where the master sets the pace and the slave responds, with CRC32 checking both ways.

Then came the actual circuit boards. Another first for me. I worked with some veroboards as a kid, and custom circuit board kits from Josty Kit and Velleman… but never perfboards. I tried just bridging some of the islands with solder… it did not work. Then I remember youtube, and looked up a video about perfboard. Oh! So you make the traces by soldering your own wires to the board! Alright then.

Let’s not even go into all the times I had to resolder and try different pins because of the anomalous responses I was seeing that I never saw on the breadboards… I eventually figured out that solder flux conducts electricity. Now there’s a kick in the pants. Ordered some flux remover and once I cleaned the circuit boards, suddenly things worked much better. Imagine that.

Finally managed to deploy.

The controllers did their thing, but the 315 MHz remote range was cut to absolute crap. You had to hold the remote right next to the receiver to be able to toggle the gate. What the heck?

My spectrum analyzer gave me the answer…
The ESP8266 emits interference at 80, 160 and 320 MHz. Awfully close to the 315 MHz. No wonder the receiver became deaf all of a sudden. I had to relocate it to its own cabinet on top of the gate posts. Ugly but okay as a temporary solution. What I wouldn’t give to be able to reduce the clock frequency to 70 MHz!

So anyway, this solved the problem with the desynchronizing gates! Phase 1 complete. The software makes sure the gates stayed synchronized, and it also allowed me to open the gates from my phone with the Fibaro app, by way of a virtual device calling the HTTP server on the ESP8266 when you pushed the buttons. This was a couple of months ago, before I started using openHAB, and before I had ever even heard of MQTT. It has been useful a couple of times to be able to let the delivery man into the yard when I wasn’t at home.

Phase 2

It’s rather inconvenient, not to mention dangerous, to be looking back at the gate to make sure it closes as you’re pulling out into traffic. I live right by a main road and there’s only a couple of meters between my gate and the road. So, it would be nice if the gates could close automatically after I have driven through.

At this point, I’ve fully switched to openHAB, and been very active on the forum, even making an actual library out of my LeifESPBase framework code and released it publically. This meant some changes in my existing projects, including the gate controller code. I hadn’t uploaded new code for a long time, and I almost hesitated to wipe out that beautiful uptime!

But, after reworking the code to use the new libraries and testing it as far as I could on ESP8266 systems on my test bench, even making sure the RS485 was communicating, I bit the bullet and uploaded the new code to the in-service gates.

The master worked perfectly on the first try… but the slave gate went NUTS!
It was toggling back and forth all the time. This huge gate going back and forth. Shit! And as it’s doing that, new code upload keeps failing too. Panic started setting in! You can imagine. I can’t leave it like that, it could cause real damage. I struggle for maybe 15 minutes to get it under control but to no avail, so I finally I go out there with a screw driver and pull the cover off and disconnect the relay. As I pulled the cover off I noticed that the relays were making a strange buzzing sound.

That’s when I realized my error.
led_pin used to be a global variable in the sketch, which my old framework code accessed as an extern… but LeifESPBase owns its own led_pin and has an accessor function.

And on the slave controller, I was using GPIO 16 (D0, the LED pin) as the Relay Trigger pin… so the gate slave controller code was fighting for control of this output with the WiFi activity light of all things. Heh. So the LED blink was clicking the action button.

I realized that I can’t take chances like that anymore… I had to build a full simulation on the bench, and keep that around for the future development. It was time to port the gate simulator itself to an ESP! This time I went with an ESP32 because the simulator must have a display and an ESP8266 definitely wouldn’t have enough pins for that and all the other output pins.


There we go! The two ESP8266’s are running the exact same software as the actual gates.
Now I can develop the auto-close feature in peace.

It took a couple of days, but it is now DONE and deployed!

Here’s how it works in practice.

We normally press the GREEN button to open and close the gate.
I’ve added a feature so that after you’ve pressed the GREEN button, you press the RED button to start the auto-close procedure. That starts a 60 second countdown, and the lights above the gate slowly flash as acknowledgement.

If you break the infrared beam (as you do when you drive through), the countdown is set to 15 seconds. Thus, if multiple vehicles are driving through, it’s set to 15 seconds every time.

When the countdown is at 15 seconds or below, the lights flash faster (once per second).
When the countdown is under 3 seconds, the lights flash very rapidly…
And finally when the countdown reaches 0, the gates close.

If you break the infrared beam while they’re closing, they’ll re-open, and increase the post beam-break countdown length to 30 seconds before trying again.
If it happens a second time, they’ll re-open again but the post beam-break countdown will be 60 seconds. And if it happens a third time, we re-open the gates and give up. We don’t try to close it again. This seemslike a good safety feature. (MCAS, anyone?)

Footage slightly sped up.

And, now I’ve fully integrated it into openHAB, so I can finally once and for all turn off and disconnect the Fibaro HC2, marking my COMPLETE transition to openHAB!! :partying_face:

Note that the clip above is not edited. The jump from 58 to 15 seconds is me interrupting the IR beam.

So does that mean it’s done?

No, don’t be silly. :slight_smile:

I’m starting Phase 3 tomorrow, which will be access control through UHF RFID. This will mean the gate could open itself as I pull up. This will also let my contractors (i’m currently building a new house) come and go during the day without having to leave the gate open all day.
If a designated RFID tag arrives outside of daytime hours, the system could automatically ring the doorbell.

And then Phase 4, the final phase. I want to put in a vehicle detection loop in front of the gate, so that it can open automatically to let guests out even if they don’t have an RFID tag, and also to automatically ring the doorbell so friends won’t have to get out of the car when coming to visit. :slight_smile:

Big kudos if you’ve made it this far! Thanks for reading, please let me know what you think. :slight_smile:


That is a cool project!

Have you considered getting proper pcb’s made?

I recently got a few made for my air condition controller (still waiting for the resistor networks to arrive).


For the gates I haven’t, is there any point to do that for one-offs like this?

But for my pool light controllers I will! I kinda went nuts with the pool lights – about 150 RGB lights that I’m planning to individually control. 10 lights per controller will mean 15 controllers, each with 30 PWM channels, communicating with the master controller by RS-485. That’s gonna need PCBs, and it will be my first time designing such.

Keep us posted on this project, please :smiley:


I finally got my air condition controller put together.

Those resistor arrays were a bit tricky to solder. Each resistor in the package is 0402, and they are pretty close to each other, but it works! :smiley:


Next time I will probably order a stencil too, and just reflow them.

If you’ve done that by hand with an iron then I’m impressed!

I did, using a genuine (verified by Hakko) Hakko FX888D, with the standard tip and some unknown smd solder. I can’t get the out of the holder I 3d printed without breaking it, but it is pretty thin.

Alignment isn’t perfect, but close enough.

That is very cool! I’ve never done any soldering at this scale but I know I will have to soon, if for no other reason than to change the I2C addresses of PCA9685 PWM module boards.

So, I bought this trinocular microscope:

The microscope itself is great!
I bought it because of this recommendation:

I also bought this camera:

…and it’s utter garbage. The field of view is… well… microscopic. No pun intended. The field of view is much, much smaller than what you see through the eyepieces.
Do you have any suggestions?

Edit: Watching the video again, I may have just answered my own question.

You need a different tip and also learn how to correctly drag solder with good quality ‘tacky flux’. It is a walk in the park when you have the right gear and technique. I use a BCM hollow conical tip. Video and guides are at this link.


1 Like

I might get something better, if I need to do more of this. For this I just needed to solder two resistor networks in, and then I might have to solder something like that in a few years again… But this was just for fun to see if I could do it, there was plenty of space to just go with 0805 sized.

With just about 50 lines of code I created the mapping between my shelly roller shutters and the openhab proxy items.
The code

  • automatically creates the corresponding openhab rollershutter items
  • listens for the mqtt position event, inverts the percentage and posts an update to the openhab item
  • listens for commands from openhab, translates them to shelly commands and updates the mqtt topic so the shutter moves
  • also adds some small logging

If I add more shutters, I just have to add the device-id in the dict and everything else will happen automatically.

import logging
import re
import time
import typing

from HABApp import Rule
from HABApp.core.items import Item
from HABApp.openhab.events import ItemCommandEvent
from HABApp.mqtt.events import MqttValueChangeEvent

log = logging.getLogger('Rollladen')

class Rollladen(Rule):
    def __init__(self, name, device_id):
        self.name = name
        self.device_id = device_id
        # Set custom rule name so if something goes wrong we know where
        self.rule_name = f'Map{self.name}'
        self.mqtt_topic_position = f'shellies/shellyswitch25-{self.device_id}/roller/0/pos'
        self.listen_event(self.name, self.command, ItemCommandEvent)
        self.listen_event(self.mqtt_topic_position, self.update_position, MqttValueChangeEvent)
    def create_items(self):
        # create openhab item
        if not self.openhab.item_exists(self.name):
                # add label with spaces after each uppercase character and percent value
                label=re.sub( r"([A-Z])", r" \1", self.name).replace('ae', 'ä').replace('ue', 'ü') + ' [%d %%]',
        # update position initially from cache
        self.update_position(self.get_item_state(self.mqtt_topic_position, 0))
    def command(self, event):
        assert isinstance(event, ItemCommandEvent), event
        target = {'UP': 'open', 'DOWN': 'close', 'STOP': 'stop'}.get(event.value, event.value)
        target = str(target)
        log.info( f'{self.name}: {target}')

        self.mqtt.publish(f'shellies/shellyswitch25-{self.device_id:s}/roller/0/command', target)
    def update_position(self, value_or_event):
        if isinstance(value_or_event, MqttValueChangeEvent):
            percent = value_or_event.value
            percent = value_or_event
        # assert and invert percentage
        assert isinstance(percent, (int, float)), type(percent)
        self.openhab.post_update(self.name, 100 - percent)
SHELLIES: typing.Dict[str, str] = {
    'RollladenZimmer1': 'BARCCA',
    'RollladenZimmer2': 'BARCDA'
    'RollladenZimmer3': 'BARCEA'
    'RollladenZimmer4': 'BARCFA'
# create all required rules
for name, value in SHELLIES.items():
    Rollladen(name, value)

I wrote a little python script to integrate the control of the apa102 rgb LEDs on a respeaker 2mic pi hat into openhab and Nodered over Mqtt.
Than I build a little box out of wood I had lying around and some old tights from my girlfriend :see_no_evil: which fits the respeaker and the pi zero w it’s attached too.
As I use Snips.ai for voice controlling openhab I can use this as a satellite for it but I can now also trigger the LEDs from Openhab over Mqtt to notify me about other things.
Here are some pictures


1 Like

Hi Johannes,
how is your experience with the respeaker pi hat? Can it process what you say directly or how many tries do you need? Also at which distance?

Would be intersting as I might want to order one but it must work for the whole living room.

I didn’t know you could create items from Jython code! Thanks for this incredibly useful piece of knowledge! :star:

Whilst this is possible with Jython, too, I am running HABApp. It’s “real” Python, provides full syntax highlighting and the possibility to use any python lib with it. You can easily try it out from any machine since there is a config switch makes the connection to your openhab instance in read-only mode and thus will not change anything. Here’s the link to the documentation.

1 Like