Yes I asked the forum about it a few days ago; [core.thing.internal.ThingManagerImpl] - Check result is 'not ready'
Have you looked into Binding in “NOT_YET_READY” state after recent core changes · Issue #3394 · openhab/openhab-core (github.com)?
If you create channel (or thing) types dynamically all you have to do is store them in the storage based channel-type provider (when they are first created). They are available on on next startup then and you’ll have no issues. If you chose a type name that is unique for each thing (e.g. because it includes the thing uid), you can automatically remove them when the thing is removed (see handleRemoval in HarmonyDeviceHandler).
2 Likes
I’m having lots of issues where the automatic creation does only work partially. E.g. I’ve had roller shutters without the rolller shutter channel or battery powered devices which don’t create all the channels even after multiple weeks, yet are correctly reporting their values on some of the created channels.
So I think it would be nice if something like the mqtt binding was possible.
There you can define the thing and the corresponding textually.
Arbitrary example I copied from another thread I was reading:
Thing mqtt:topic:PlugWaschmaschine "PlugWaschmaschine" (mqtt:broker:MosquittoMqttBroker) { Channels:
Type switch : state "state" [ stateTopic = "zigbee2mqtt/PlugWaschmaschine/state", commandTopic = "zigbee2mqtt/PlugWaschmaschine/set/state", on="ON", off="OFF" ]
Type datetime : last_seen "last_seen" [ stateTopic = "zigbee2mqtt/PlugWaschmaschine/last_seen" ]
Type number : power "power" [ stateTopic = "zigbee2mqtt/PlugWaschmaschine/power" ]
Type number : energy "energy" [ stateTopic = "zigbee2mqtt/PlugWaschmaschine/energy" ]
Type number : current "current" [ stateTopic = "zigbee2mqtt/PlugWaschmaschine/current" ]
}
This defines a thing and a channel of the type switch with the name state, etc…
Since I also create the yaml for esphome I know what channels should be there.
So it should be easy to create the corresponding thing file.
Additionally when I update the yaml I can just add/remove the corresponding channel.
Even a yaml → things file converter should be relatively easy to do.
If you have experienced channel trouble with this binding, I’m happy to take a look at TRACE level logs.
I’m using your suggested setup myself for MQTT topics from HA - works well but tedious setup. Which was in fact one of the main reasons for starting this binding. If this is what you are after, why not simply use the mqtt transport instead of api?
One could of course start parsing the ESPHome yaml files, but that might not be what the device is actually running.
(What I personally would love to see is GUI support for broken links detection between items and things. Same data as outputted from openhab> openhab:links orphan list. This would make it much quicker to find broken links than logging into the openhab server via ssh/openhab-cli)
I used the shelly binding as an example because I’ve spent lots of time trouble shooting and these are very hard to track down errors. I am confident your binding is bug free and issues will never arise during channel creation 
, however it’s always nice to have a fallback if things go south and that’s the only thing I am asking for.
Do the automatic discovery except if the user has configured the channels manually, then only do the subscribe.
Additionally this gives the user a choice: do I like the convenience or is it worth a little bit of extra effort.
I get what you’re hinting at and that’s why this would only work manually. Only then it’s possible to ensure that what was flashed is the same that generated the yaml. The workflow would be
- Flash the esp from the yaml
- Immediately generate the corresponding *.things file.
A python yaml to thing generator is definitely something I would use.
That’s how I do it now.
Thanks for the reminder. This has been on my HABApp backlog for ages but I forgot about it.
I think I’ll add it into the next release. 
Once I set the log to TRACE, the log is flooding crazily to the extend that it affect openhab to run smoothly and lag a lot.
What I did now to solve the problem is to stop the binding every hour and start it again after 3 seconds (strangely binding restart don’t work), so far it work smoothly for 4 days already without any problem.
FYI, I’m on OH 3.4.5 and using binding 3.4.5 now.
Thanks.
Heads up: 2 weaks ago after implementing ESPHome binding for the Native API - #58 by J-N-K - the binding is no longer compatible with OH3. This means the OH3 version will no longer get updates, only OH4.
The info in the original thread post has been updated.
Should I manually update then? Due to a crap up of my own I’m now on the latest milestone, so I can easily test the binding now if needed.
(Which btw I have been using happily with zero issues).
Yes, there are no automatic update mechanism in OH except apt etc for all of openhab.
Suggestion: Follow the repo Commits · seime/openhab-esphome · GitHub .
Every push builds a new version and publishes it here: Release Latest Build · seime/openhab-esphome · GitHub. I might not post here unless I’m providing a fix to a problem mentioned in this thread.
1 Like
Following your releases now updated the binding to the latest version just now. Will provide feedback soon.
Update:
Running the latest binding on the latest milestone I’m getting this error:
2023-09-24 16:10:35.836 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘esphome:device:026e7ed3-5d2b-45b6-a332-213930b226b1’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): ESPHome did not respond to ping requests. 4 pings sent with 10 s delay
Thing goes offline and then quickly returns to online. Reminds me of the same behavior I saw initially.
The mqtt connection however is stable, so it seems to be the api only.
1 Like
Could you set log to Trace and send? Also if possible, please set ESPHome logs to VERY_VERBOSE and add as well. Thanks
Awesome work @seime ! Thank you so much 
I just bought and set up an everything presence one sensor everything presence one sensor with your plugin. After setting the IP Adress it found and connected to the device. From the 16 Entities on the sensor it automatically set up 7 channels. I would like to get things working without having to install Home Assistant for configuration of the mm-Wave sensor sensitivity etc.
Are you going to add more sensor types?
Yes I’ve been looking at this one myself but ended up with the Aqara FP2 instead since he was out of stock earlier this year.
Could you enable TRACE logging and send me the logs on PM? I need logs from the very moment you Disable/Enable the Thing until it is up and running and reporting the first sensor value.
Regards
Awesome. But I think it’s the not yet implemented types that are causing issues here. I sent you a PM with the relevant log entires.
I think the easiest way to add the Dashboard to the left side is a new Page with a Web Frame Card.
Does anybody know how to install the ESPHome Dashboard on an Openhab Raspberry?
I’ve not tried it on a Raspberry but I found the easiest way was installing the dashboard in a docker. I followed these instructions (linked below)
It did not like to run in Firefox on Mint Linux but ran great in Chromium
The dashboard makes setting up micro-controllers so easy
I could install and start it at the Openhab Raspberry.
sudo apt-get install python3-venv
python3 -m venv venv
source venv/bin/activate
pip3 install esphome
pip install tornado esptool
cd /etc/openhab/html
mkdir esphome
esphome dashboard /etc/openhab/html/esphome
The issue is that it blocks the shell once the dashboard is started. Either it can be run as service, but I think docker is the way to go even if I don’t have it?
I also have a “menu” entry ESPHome now in the Openhab MainUI; the web frame card works.
do you have any other computers or laptops other then your Raspberry?
The dashboard can be installed on any computer on your lan (local area network)
I have it working now on another PC. Nevertheless best would be to have it on the same machine like Openhab. Easiest would be if it could be installed over the Openhab Marketplace.
1 Like