Homie, D1Mini Pro V2, Driveway gate opener and sensors

1

Hello all, I’m trying to make the mental jump into the homie philosophy, but am finding it’s taking a bit longer than anticipated, so I’m looking for a sanity check.

I had a mostly working arduino sketch for a driveway gate opener, then decided to veer into the homie architecture. I am using the Arduino IDE, and the 2.1 homie (latest stable) libraries. This is to be used in an openhab 2.4 system (although that part should be straight-forward).

I am looking to automate/control a driveway gate controller, as well as read the status of the car gate reed sensor and a nearby pedestrian gate. These would be all managed on a D1 Mini Pro (V2), with an external antenna for wifi signal reasons.

After this (most complex) application, I’ll be simplifying it a bit to some garage door openers (single reed sensor, simple toggling an opener; additional temperature and occupancy data), and if successful, then perhaps deployed a but further with other applications. I already have MQTT setup and working in OpenHab 2.4 with a non-Homie device (Temp and humidity on a DHT22, on node MCU esp8266 device)

==

I’ve been struggling with grasping the homie philosophy, and feel that I’m fighting the way that it wants me to do things. The examples are all single-node circumstances, and fairly simple. The documentation talks about multiple levels of handling, and all I want to do is write lower-level code that reads sensors and acts on it. Communication has been translated into an abstracted layer I’m working to get my mind around.
I have two gates - a driveway car gate (connected to an opener) and a pedestrian gate (simple push-to-open, if not locked). I have reed contact switches that will go on each gate, to let me know if they’re open. The driveway car gate opener has three contacts I’ll be shorting with a relay - open, toggle, and reset. The circumstances for each of these is fairly straight forward. (entering party mode with the gate kept open - ‘open’, delay, ‘reset’; trouble opening, ‘reset’; toggle - escapes party mode. Open -check to see if gate is open, and if not, activate ‘open’. Close - check to see if gate is closed, and if not, ‘toggle’.

My initial code had me intermittently reading all my sensors, if it found the pedestrian gate opening, it would send an MQTT message to this end (simple, non-Homie-standard topics). If it found the car gate was opening, it would look to see if this was intentional, and if not would send an intruder-type message (the gate is somewhat flimsy with no maglock, and could be manually overcome).

When the gate was being opened, a status string would be updated to ‘opening’, ‘trouble opening’, ‘open’, or ‘closed’ - to indicate the expected status of the gate sensor.

When I look at your code from Dec 2016, you seem to do things in a mix of using homie handlers and simply handling things yourself (which is my tendency). Have you changed to a more homie-handler centric mode? Is this work the cognitive effort?

My current understanding of the homie philosophy would have me go with:
Home Nodes:
Pedestrian gate sensor
Driveway gate sensor
Driveway gate opener

  • receiving commands of Open, Close, Toggle, Reset, Party; possibly also ‘Status’ to refresh sensors status and report wifi stats.

The driveway gate opener would have its own handler, but the sensors wouldn’t. I would be tempted to have a single update sensors function, and set the individual node properties for the pedestrian gate and car gate within this function. Additionally I’ve been considering a doorbell sensor, but that’s probably jumping into the deep end for now.

Any suggestions on if this is an appropriate plan, or alternate methods? Any feedback?
(I’ve rewritten the code twice already so far with different plans, I’m hoping to make this one the last)
Is it reasonable to continue with the push to homie?

Thanks for the sanity check!
Cheers

1 Like
2

Hi Ben!

There’s definitely some overlap in what we’re doing. Check out my Gate Adventures post.

Homie itself, while convenient, doesn’t really buy you anything or solve any logic problems. It’s a bunch of restrictions and conventions on top on MQTT to slightly simplify integration with openHAB but doesn’t do a whole lot else.

It is nice to be able to easily track the online/offline state of nodes in openHAB though… and to have a standardized way of exposing properties. But, it’s a very thin layer.

So, if your thing isn’t working without homie, then it’s not going to work with it either!
You may be interested in my homie library for arduino.

I strongly recommend putting as much as your logic as possible directly in the arduino so that you’re not dependent on openHAB to open and close your gate! openHAB is a nice plus, but my gate system is not reliant on it.

If you take openHAB and the MQTT controller down, the lights above my gates will no longer flash to show that it’s counting down to auto-close. Other that it will work precisely as usual.

When I add RFID access control, that will be dependent on openHAB… but the normal remotes will still work!

I think homie makes sense for the “Open, Close, Toggle, Party” commands you mentioned. Status should be periodic and automatic (and then it also functions as heartbeat). No need for a command for that.

But, for the communication between the pedestrian gate sensor and the driveway gate opener (although I didn’t quite understand it), my gut tells me that it should be direct between those two.

What sensors do you have on your gate? What about all the infinite number of states between Open and Closed? :slight_smile:

My gate has NO absolute position report sensors whatsoever – all it has is the pulse counter coming from the motor, which the gate controller uses to keep track of where it is. That, and the “overload” sense which it uses to determine the absolute end position (after slowing down the right amount to crawl very slowly when it reached the end point from the last run). By monitoring this pulse counter, my arduino knows exactly where the gate is, so I can have a progress bar for opening/closing. :slight_smile:

3

Thanks @leif
Your Gate Adventures post looks like quite the adventure indeed. I recall reading your post back last year, I believe, but hadn’t recalled enough to find it again (the hazards of reading just before bed).

Fortunately, my liftmaster gate system seems to coordinate both gates OK, so I don’t need to re-invent the control system - just hack into the three buttons on the board, and add my own contact sensors for the gate. I am keenly aware that a replacement version of the controller board can connect via an internet gateway (to the proprietary myQ system), which would give me access within the proprietary app to the fine details of the gate status as well as controlling it. My controller board is working fine, though, and I would like the ability to hack my own ‘gate open’ buttons at the house.

Anyway, thanks for the input.
I’m going to look through your homie adapted library - I see that if I were to do the same thing multiple times, it would be a no-brainer. I agree with the premise of putting the logic into the arduino controller - and this is what makes it more awkard to shoehorn my (poorly compartmentalized) code into a homie standard. I think I’ll try a bite-sized test project.

Ben

4

My post is actually only a couple of weeks old. I’ve only been working with microcontrollers for three months, actually :slight_smile:. Maybe someone else did something similiar?

I agree completely with you about not replacing an existing hackable system with a proprietary system! I can’t stand all these stupid proprietary app-based “solutions”. Yuck.

My only question is, do you really need to add a sensor? Wouldn’t it be cleaner to have your own circuit piggyback on whatever signals the liftmaster gate system is already using to do its job? If it knows the status of the gate, you should be able to know too from the same signals. :slight_smile:

I’m still using my original controllers and sensors, and the controllers are still controlling the motors. I’m controlling each of the two controllers with a single command each – the “toggle” command.

5

Hi @leif
Yes, it would be much nicer to do that - I just haven’t gotten around to tracing all the circuitry on the board. I plan on including a reed switch for a neighbouring pedestrian gate, so I figured it wasn’t much more to put a sensor in the gate. This would have the additional value of knowing if someone had pushed the gate enough to slip through (the gate isn’t very secure - mainly intended to keep deer out).
I may someday put in a maglock and a more secure gate.
[for a while I had planned on enabling the (absent) maglock, and watching the signals to the maglock for when the gate intended to open - I’ve decided the extra complexity of this (and the extra delay in opening the gate) wasn’t worth it - especially as it would only recognize when the gate was intended to be opened.]

1 Like
6

I have been looking at using the mini pro with this https://github.com/aderusha/MQTTCarPresence

i did get some of the cases printed and they work well - haven’t had time to implement it yet