FYI, after the upgrade to openHAB 4.2.1, the binding was uninstalled on my system… Installing it again fixed the issue
I tried integrating an Uptime Sensor, but the linked item reads UNDEF…
time:
- platform: sntp
id: tijd
sensor:
- platform: uptime
type: timestamp
name: laatste herstart
label: laatste herstart
type: DateTime
category: mdi_timer-outline
groupNames: []
tags:
- Measurement
Anyone any idea how to get it working? I assume there’s something missing in the [Time Component(Time Component - ESPHome - Smart Home Made Simple)?
@seime feedback!
I am now the happy owner of 5 Bosch 6000i indoor units. These absolutely kick ass.
The dongles I used are from smlight, after reflashing all of them (the original firmware seemed iffy) things were auto populated and I got access to all channels.
Some items aren’t being populated but I haven’t yet looked at the logs to share more info about it.
At least I have the basic functionality available so that’s already great.
Oh small interesting thing I noticed: the mode item created from the esphome channel does not work correctly with Google home. It borks the mode in Google home and becomes unusable, modes become “on” instead of “cool”, and other weird behavior.
I created a new item and “linked” it over to the esphome one and it works fine, so it seems that something is weird on the created item by the channel itself. Can you try this out?
Added support for sensor of type timestamp
Congrats!
The binding does not add any semantic tags to the Mode channel afaik. And I don’t have a Google setup to try with 
Cheers
Super, thanks!
Should I use the latest jar, or is the latest version in the marketplace also updated?
@seime, I installed the jar file in the addons directory, deleted the thing, restarted openhab, unwittingly even deleted the items that were linked to the thing and finally re-added the thing (and recreated items of course).
But still…:
Any other thoughts? Is there any logging I can provide?
Then again, when I restart the ESP32, this is what I see in its logs:
[08:48:56][C][uptime.sensor:032]: Uptime Sensor 'laatste herstart'
[08:48:56][C][uptime.sensor:032]: Device Class: 'timestamp'
[08:48:56][C][uptime.sensor:032]: State Class: ''
[08:48:56][C][uptime.sensor:032]: Unit of Measurement: ''
[08:48:56][C][uptime.sensor:032]: Accuracy Decimals: 0
[08:48:56][C][uptime.sensor:032]: Icon: 'mdi:timer-outline'
[08:48:56][C][uptime.sensor:033]: Type: Timestamp
So maybe there’s something wrong with my yaml?
openhab> bundle:list|grep ESPHome
328 │ Active │ 80 │ 4.1.0.202408240749 │ Seime Add-ons :: Bundles :: ESPHome Native API
Also:
erik@MinipcLG2:/usr/share/openhab/addons$ ls -pal
totaal 4040
drwxr-xr-x 2 openhab openhab 4096 aug 25 17:42 ./
drwxr-xr-x 4 openhab openhab 4096 aug 10 02:46 ../
-rw-r--r-- 1 root root 3539683 aug 25 17:42 no.seime.openhab.binding.esphome-4.1.0-SNAPSHOT.jar
-rw-r--r-- 1 root root 581448 aug 5 21:29 org.openhab.binding.shelly-4.3.0-SNAPSHOT.jar
-rw-r--r-- 1 openhab openhab 70 aug 9 15:35 README
Also, the GPIO channels work…
(I assume the 4.1.0 in the binding file name is still a relic? ;))
I changed sntp to homeassistant, and now it works:
time:
- platform: homeassistant
id: tijd
Maybe your ESP is unable to reach the sntp servers? The homeassistant source fetches time from openHAB, should work fine
No, the binding is still compiled against 4.1.0, but it should work on future versions as well - as long as they are backwards compatible enough.
Understood! I need to further investigate this.
Oh one weird issue I’m having is that every once in a while the hostname gets replaced by the .local one published by the device (I assume):
In this example I have the IP (I use IP because the .local domain doesn’t work on my network setup). Would it be possible to have a way to make the IP stick??
Is this the same problem as last year? ESPHome binding for the Native API [4.0.0;6.0.0) - #29 by seime
If not, logs are needed!
Yes! Only, it’s not reproducible.
Or rather, for the last two days everything was fine, today I had one ac down and when investigating it had reverted back to the .local.
While not related to the binding, I’ve noticed that the controllers I bought seem to restart somewhat frequently. Could it be a “when offline revert to .local and try again”? Situation? After which it stays with the .local? Maybe an esphome behavior?
Just make sure your things doesn’t have the same thing uid as the discovery result (with the REMOVEMEWHENADDING text). Or it will get overwritten unless you use thing files.
In my experience, ESPHome devices do eventually crash if you add too much sensors etc, especially the Bluetooth stack.
!!! Oh! Can it be….
What’s too many? I only have 5 in use right now… it that per device or per channel/item?
Edit:
Indeed I had one thing with the “removeme “. Recreated it now, should be good 
No clue, probably depends on how much memory each particular component aquires (and/or leaks). Take a look at the pink warning box here; Bluetooth Proxy - ESPHome - Smart Home Made Simple
Hi,
I’m testing this binding with an Apollo MTR-1 sensor. During initialization it throws an exception on this particular response:
2024-08-29 23:17:04.313 [DEBUG] [home.internal.handler.ESPHomeHandler] - [mtr-1] Received message type ListEntitiesSensorResponse with content 'object_id: "ltr390_uv_index"
key: 1710247030
name: "LTR390 UV Index"
unique_id: "apollo-mtr-1-cc93a4sensorltr390_uv_index"
icon: "mdi:brightness-5"
unit_of_measurement: "UVI"
accuracy_decimals: 5'
2024-08-29 23:17:04.313 [WARN ] [me.internal.comm.AbstractFrameHelper] - [mtr-1] Error parsing packet
java.lang.NullPointerException: Cannot invoke "no.seime.openhab.binding.esphome.internal.message.SensorNumberDeviceClass.getItemType()" because "sensorDeviceClass" is null
at no.seime.openhab.binding.esphome.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:66) ~[?:?]
at no.seime.openhab.binding.esphome.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:1) ~[?:?]
at no.seime.openhab.binding.esphome.internal.message.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:254) ~[?:?]
at no.seime.openhab.binding.esphome.internal.handler.ESPHomeHandler.handleConnected(ESPHomeHandler.java:373) ~[?:?]
whereupon the binding disconnects and stops creating further channels.
I don’t know why the device_class is missing in this case. There are several earlier messages that include this field, eg
2024-08-29 23:17:04.297 [DEBUG] [home.internal.handler.ESPHomeHandler] - [mtr-1] Received message type ListEntitiesSensorResponse with content 'object_id: "ltr390_light"
key: 3680477510
name: "LTR390 Light"
unique_id: "apollo-mtr-1-cc93a4sensorltr390_light"
icon: "mdi:brightness-5"
unit_of_measurement: "lx"
accuracy_decimals: 1
device_class: "illuminance"'
It was easy enough to fix: Fix NPE if device_class is missing by marcusb · Pull Request #29 · seime/openhab-esphome · GitHub
I don’t what the answer is, but I had the same thing happening to me. My workaround was to just add an entry to the /etc/host file with the <host>.local. entry pointing to the correct ip.