Yesterday I’ve upgraded to 4.3M1 (on Ubuntu). All ESPHome devices went offline, no binding. Installed the Binding again and they came to live, no problem. Today, they’re offline again and no matter what I try, they stay offline. With both password or encryption, nothing. Added one again, still nothing.
I think there’s something wrong on Binding level in 4.3?
My setup appears similar to yours, when I upgraded the binding jar was not loaded. I had to restart OpenHAB. Then everything loaded correctly.
Could you set log level to debug and send as pm? Also check in openhab-cli that the bundle has started
same here, just restarted and they all come online. Let’s wait some time to see if they stay online.
What’s the difference between a switch component and a button component?
A button generates an event. It doesn’t really have a state, like a switch that can be on/off.
I might have spoken too soon. All my esphome devices are in various degrees of “unavailability”.
Error in thing:
COMMUNICATION_ERROR
ESPHome device abruptly closed connection.
Fun bit, restarting openhab fixes it temporarily. Weird but ok.
I’m looking at frontail and nothing jumps out as an obvious issue…
@seime
Edit: found some time to take a better look at this. The binding is getting stuck in waiting state when OpenHAB starts it seems. Restarting it fixes it. Waiting some more time to see if it sticks or if the devices go offline again. I wonder if it’s something OpenHAB 4.3.0 M2 is causing…
This question is not about the binding, but more about an ESP32 board itself.
I notice the time of the clock is off by 4 seconds, after only 15 minutes… That seems like a significantly quickly arisen discrepancy. Is that normal? (Also, for my understanding: is this a synchronization with the openHAB (or Home Assistent) clock?)
[10:23:50][D][time:051]: Synchronized time: 2024-10-12 10:23:54
[10:23:50][D][time:051]: Synchronized time: 2024-10-12 10:23:50
[10:38:50][D][time:051]: Synchronized time: 2024-10-12 10:38:54
[10:38:50][D][time:051]: Synchronized time: 2024-10-12 10:38:50
What you sync against depend on the esp config. If you sync against oh, make sure oh itself syncs against a time server.
How does one make sure that happens?
I’m not confident it is just 1 problem. If the binding doesn’t start, ALL your esphome devices would be in OFFLINE. But your screenshot says otherwise.
My gut feeling is that the “binding stuck in waiting state” problem is related to karaf service dependencies and some mumbo jumbo startup order that sometimes gets right and sometimes doesn’t.
Whenever this happens again, please run in openhab-cli:
diag <bundleId>scr:info no.seime.openhab.binding.esphome.internal.handler.ESPHomeHandlerFactoryscr:info no.seime.openhab.binding.esphome.internal.message.statesubscription.ESPHomeEventSubscriberscr:info no.seime.openhab.binding.esphome.internal.handler.ESPChannelTypeProviderscr:info no.seime.openhab.binding.esphome.internal.discovery.ESPHomeDiscoveryParticipant… and post the logs here.
Then try to change the bundle startlevel to 81 (bundle:start-level <bundleId> 81) and reboot. I’d like to know if this helps (every time) or not.
I installed the ESPHome binding and used it to connect to my garage doors. I built the rat-ratgdo circuit boards, which use an esp8266 processor. The curcuit boards connect to the MyQ garage door openers and allow you to control the MyQ garage doors locally. I flashed the processor with the ratgdo software. The ESPHome binding finds the processor, and the only problem I had with it is that the ratgdo software defines some unconventional units of measure for a couple of channels that throw warnings in the openHAB log files. The way I got rid of the warnings was to edit the UOM in the Code tab on the thing. I built 9 circuit boards and all of them have been dependable so far. I also used it to control an ESPHome flashed relay board which controls a more commercial style garage door that has separate open, close, and stop buttons. The yaml code for the relay boards is pretty simple. I just needs to define a switch item for each relay.
Woah this is a lot of text.
The diag command did not seemingly output anything, or maybe I don’t know where to look for it, can you provide some hints?
Also, I now have a worse problem… all of my esphome devices are constantly going offline and become unresponsive/unreachable. But one problem at a time.
Class: no.seime.openhab.binding.esphome.internal.handler.ESPHomeHandlerFactory
Bundle: 247 (no.seime.openhab.binding.esphome:4.1.0.202409231705)
Enabled: true
Immediate: false
Services: [org.openhab.core.thing.binding.ThingHandlerFactory]
Scope: singleton
Config PID(s): [binding.esphome], Policy: optional
Base Props: (1 entry)
osgi.ds.satisfying.condition.target = (osgi.condition.id=true)
State: ACTIVE
Service: 789 [org.openhab.core.thing.binding.ThingHandlerFactory]
Used by bundle 169 (org.openhab.core.config.discovery:4.3.0.M2)
Used by bundle 214 (org.openhab.core.model.thing:4.3.0.M2)
Used by bundle 221 (org.openhab.core.thing:4.3.0.M2)
Config Props: (3 entries)
component.id = 517
component.name = no.seime.openhab.binding.esphome.internal.handler.ESPHomeHandlerFactory
osgi.ds.satisfying.condition.target = (osgi.condition.id=true)
References: (total 5)
Class: no.seime.openhab.binding.esphome.internal.message.statesubscription.ESPHomeEventSubscriber
Bundle: 247 (no.seime.openhab.binding.esphome:4.1.0.202409231705)
Enabled: true
Immediate: false
Services: [org.openhab.core.events.EventSubscriber, no.seime.openhab.binding.esphome.internal.message.statesubscription.ESPHomeEventSubscriber]
Scope: singleton
Config PID(s): [binding.esphome.eventsubscriber], Policy: optional
Base Props: (1 entry)
osgi.ds.satisfying.condition.target = (osgi.condition.id=true)
State: ACTIVE
Service: 788 [org.openhab.core.events.EventSubscriber, no.seime.openhab.binding.esphome.internal.message.statesubscription.ESPHomeEventSubscriber]
Used by bundle 156 (org.openhab.core:4.3.0.M2)
Used by bundle 247 (no.seime.openhab.binding.esphome:4.1.0.202409231705)
Config Props: (3 entries)
component.id = 518
component.name = no.seime.openhab.binding.esphome.internal.message.statesubscription.ESPHomeEventSubscriber
osgi.ds.satisfying.condition.target = (osgi.condition.id=true)
References: (total 1)
Class: no.seime.openhab.binding.esphome.internal.handler.ESPChannelTypeProvider
Bundle: 247 (no.seime.openhab.binding.esphome:4.1.0.202409231705)
Enabled: true
Immediate: false
Services: [no.seime.openhab.binding.esphome.internal.handler.ESPChannelTypeProvider, org.openhab.core.thing.type.ChannelTypeProvider]
Scope: singleton
Config PID(s): [no.seime.openhab.binding.esphome.internal.handler.ESPChannelTypeProvider], Policy: optional
Base Props: (1 entry)
osgi.ds.satisfying.condition.target = (osgi.condition.id=true)
State: ACTIVE
Service: 787 [no.seime.openhab.binding.esphome.internal.handler.ESPChannelTypeProvider, org.openhab.core.thing.type.ChannelTypeProvider]
Used by bundle 221 (org.openhab.core.thing:4.3.0.M2)
Used by bundle 247 (no.seime.openhab.binding.esphome:4.1.0.202409231705)
Config Props: (3 entries)
component.id = 516
component.name = no.seime.openhab.binding.esphome.internal.handler.ESPChannelTypeProvider
osgi.ds.satisfying.condition.target = (osgi.condition.id=true)
References: (total 2)
Class: no.seime.openhab.binding.esphome.internal.discovery.ESPHomeDiscoveryParticipant
Bundle: 247 (no.seime.openhab.binding.esphome:4.1.0.202409231705)
Enabled: true
Immediate: false
Services: [org.openhab.core.config.discovery.mdns.MDNSDiscoveryParticipant]
Scope: singleton
Config PID(s): [no.seime.openhab.binding.esphome.internal.discovery.ESPHomeDiscoveryParticipant], Policy: optional
Base Props: (1 entry)
osgi.ds.satisfying.condition.target = (osgi.condition.id=true)
State: ACTIVE
Service: 786 [org.openhab.core.config.discovery.mdns.MDNSDiscoveryParticipant]
Used by bundle 172 (org.openhab.core.config.discovery.mdns:4.3.0.M2)
Config Props: (3 entries)
component.id = 515
component.name = no.seime.openhab.binding.esphome.internal.discovery.ESPHomeDiscoveryParticipant
osgi.ds.satisfying.condition.target = (osgi.condition.id=true)
References: (total 1)
And finally:
bundle:start-level <bundleId> 81
^ done.
The cli commands (except for changing startlevel) was provided to me by an osgi expert as a way to figure out why a bundle doesn’t start. @splatch please help 
.
Also let me know if the changing of start level And restarting oh removes this problem.
For devices going offline there is a similar problem reported in a different thread. Does it look identical?
after every reboot, update etc, I need to reinstall the Binding. Devices come to life again after the binding is back.
There should not be any need to re-install the binding. Please provide DEBUG logs.
@Pedro_Liberal, how did you create the WebUI you show here?
The esphome one? It’s stock I believe in esphome.
You can check the code here:
Check the tab “downloads” and download the project.
Edit: found it -
Ooh…… I wonder….
I’m running the web server with esp8266….
Edit:
@seime flashed one of the dongles I have with an updated firmware without web server.
Same behavior, offline. Online (sometimes). I’m going to try to get deeper into the logs
