ESP8266 Community Forum

- Tue Feb 17, 2015 10:51 pm #10074 The panics are most likely when it tryst to publish two messages at the same time, extending the 120 second ping time in the mqtt setup will help minimize.

I am working on a similar garage door control, Lawrencejeff.blogspot.com is my site with some info on my code and openhab config.

Does your relay activate upon reboot when the bootloader outputs to gpio2?
I have about given up on Openhab, the fact that it has no ability to indicate loss of device connectivity. I would be interested in your thoughts.

- Wed Feb 18, 2015 2:08 pm #10113 This could be a debounce Problem.
When you press a button it sends multiple pulses before it goes to the final State.
You could add a debounce circuit to your design or just add a "cooldown" to the function so after it gets triggered you can't trigger it again for a second or so.

- Wed Feb 18, 2015 2:21 pm #10114 Hi Lawrence -

You might be right on the panics during the publish. I do not have debounce circuitry in this setup, and may be suffering from a burst of publish messages. I will add that to my to-do list!

Yes, my relay does activate on power cycle. I am unsure if it's from the ESP bootloader powering the pin, or if it's something in the logic of the relay board I'm using. Yet another thing on my to-do list to debug.

Another problem with this is voltage on GPIO0 causes the unit to not boot up correctly on occasion. This could be it simply booting into flash mode. I'm unsure how to get around that at the moment.

You could write a rule to poll the device in openHAB. I could be a simple ping on occasion to see if the network connect to the ESP is up, or it could be a MQTT publish to the listening ESP, expecting an ack message of some sort back.

During testing I did this where openhab would publish a request for memory status, and the ESP would publish back node.heap()

So much to do, so little a project....

- Fri Feb 20, 2015 9:45 am #10237 I think if you flip your GPIO0 to being held high and your button to ground that should take care of the boot issues, the way you have it now its floating so might go into the bootloader on occasion.

I'm sure the relay being triggered is the bootloader spitting out data to GPIO2 (some serial debug at an odd baud rate)- this is before the LUA code runs and sets the pin to an output (and apparently you can't change the bootloader). I have been unable to find a resolution for this yet other than use a different module.

On the OpenHAB question - I understand how to detect that I have lost connectivity to the ESP, where I struggle is how to reflect that in the web UI, a switch in OpenHAB only has three states (on, off, uninitialized) there is no error state to update it to (and you can't seem to force it to uninit) so if it dies OpenHAB might know about it but the graphic will still reflect the last updated state (on or off) - which may not be accurate. Looking at some of the other software out there they have a built in Last Updated time/date default property for all objects so at least at a UI glance you can see that the update time is out of whack... so I am considering dumping OpenHAB for my project. (In my case I want to be able to check the garage door as a key use case not just open/close it - you may not be as interested in the check part)