That’s a really clever idea to use two sensors! I hadn’t thought of that. I’ll definitely look into it.
Hi @CDriver
Thanks for sharing. Could you explain a bit more about how this works and what type of gas meter you have please?
Thanks
I love those technical details but I think this discussion is really worth an own thread.
Please guys, open a new topic for 433mhz buttons. Maybe some of the admins could move relevant messages to that new topic? @digitaldan @hmerk or someone who is fallowing?
5 Likes
I’ve got one that looks similar to this
I cut the gas line and inserted a flow meter. It smells a bit but works just fine… 
I jest - don’t do this at home kids 
Next to the right hand numbers is a magnet which comes round with the zero.
My esp8266 goes to deep sleep and when the magnet comes around it resets.
When it boots up it connects to the wifi, publishes a message to mqtt and goes back to sleep.
Within OH I have an item and a rule
Item:
Switch UtilityGasPulse (g_persist_change) {mqtt="<[mqtt:home/utility/gas/tick:state:MAP(gasTick.map)]"}
rule:
rule "Count Gas Useage"
when Item UtilityGasPulse changed to ON
then
UtilityGasPulse.sendCommand(OFF)
UtilityGasLastPulse.sendCommand(now.toString)
if (UtilityGasVolumeTotal.state == NULL) return;
val Number calorificValue = UtilityGasCalorificValue.state as Number
//logWarn("calorificValue", calorificValue.toString)
g_Utility_Volume?.members.forEach[item |
val newVal = (item.state as DecimalType + 0.001);
//update volume
sendCommand(item.name, newVal.toString)
//units = value * 1.02264 * Calorific value * price per kWh
val newUnits = (newVal * 1.02264 * calorificValue) / 3.6
sendCommand(item.name.replace("Volume", "Units"), newUnits.toString)
//logWarn("FFF", item.name + " - CV - " + newVal.toString + " -- " + newUnits.toString)
]
end
I count the ticks and just keep adding them up. it works quite well and keeps in sync.
I am also, as the code shows, working out what my actual gas bill will be though this is still a WIP.
I was planning on telling SWAMBO how much her cooking costs
I can post the code (in another thread) should you want it.
C
1 Like
I’ve no idea how that meter works, but is there the chance you’re affecting the meter’s reading by putting a bit of resistance to the free turning of that magnet? Or more importantly, would your gas company have grounds to say you are?
Are you getting the ESP to reset with a reed switch?
Unlikely as it’s widely used for this. A read switch or hall effect senor offers, I suspect, nothing in the way of drag.
Yes. Wakes it up
Today, since it was raining the entire day on my holiday location, i decided to finally look for a solution to implement Face Recognition in our OpenHAB integrated doorbell.
Currently my doorbell setup:
- Takes a snapshot of the front door camera and sends this to our phones using pushover.net
- Plays a doorbell chime through our SONOS speakers
- Blinks the Hue lights red a few times throughout the house
- Starts a live video feed of the front door camera on the various wall mounted tablets throughout the house.
All of the visual components are showing “There is someone at the door”.
For sure it is way cooler if we could make this text say who is actually at the door (given we are able to recognise the person(s))
The Doorbell:
- Wemos D1 ESP8266 board with LED pushbutton sitting outside next to our front door
- This ESP8266 sends an ON/OFF message through MQTT towards OpenHAB whenever the doorbell is pressed.
The video camera:
- Unify NVR running on VMware ESXI
- Unifi UVC-G3-FLEX IP camera
Face Recognition solution:
- FaceBox container running on my docker server
- Free version restricted to 100 faces (should be enough for the average household)
Logic/Rules:
- I have entirely switched over to Node-Red for rule processing so it was suiting to use Node-red to integrate the whole.
Diagram of the doorbell flow:
Node-red doorbell flow:
FaceBox has proven to be easy to learn new faces. Simply upload 1 (preferably more for better results) pictures of the faces you would like to recognize. Immediately after the learning process you can start with the detection and recognition of faces. The REST API of facebox is pretty flexible and will give enough details to succesfully integrate the face recognition results into a system like OpenHAB/Node-red.
Besides that, FaceBox runs locally on my own docker environent preventing me from having to share my front door snapshots with any public cloud service.
I will write a more elaborate write-up once this solution has left the test bench and fully entered my production environment.
In the mean time i’ve also updated my Habpanel Doorbell view:
- It shows the main video feed
- an overlay bar showing the names of the face(s) detected (bar is not shown if no faces recognized)
- the buttons on the right will eventually link to the most recent doorbell recordings (coming from my NVR)
20 Likes
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… 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.)
2 Likes
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 
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.
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!! 
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.
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.
Big kudos if you’ve made it this far! Thanks for reading, please let me know what you think.
41 Likes
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).
2 Likes
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 
2 Likes
