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:
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!