ESPHome binding for the Native API

seime · July 25, 2023, 1:08pm

New improved version out:

OH3. Tested with OH 3.2.x and 3.4.x. Should run with both Java11 and 17 @Pedro_Liberal @Sonic
OH4 . Only runs on Java17 as this is required by OH. @moody_blue

Pedro_Liberal · July 25, 2023, 7:18pm

Time to get to work just a manual copy and restart oh yes?

seime · July 25, 2023, 9:55pm

Restart shouldn’t be necessary .

Just put the jar in the addons folder and it should discover your ESPHome devices. Note that only a subset of the functionality is supported, imho the most common ones.

I’ll put it on a marketplace when things are more mature and complete.

Happy hacking!

Pedro_Liberal · July 25, 2023, 10:34pm

Yep, I checked your detailed explanation on GitHub and it’s clear. Better start with fewer and as some troubleshooting is done, slowly increase the available options

Edit:
If anyone else is wondering:
“ Only sensor , binary sensor switch , climate and select is supported.”

davecorder · July 30, 2023, 5:12pm

I’m guessing this is just due to it not being properly implemented yet, but how do I refresh the channels for a ESPHome device?

I’ve updated one of my ESPHome devices with a new number item (and renamed the switch component), but I can’t get it to show up in the OpenHAB 3 UI. Even if I delete and re-add the thing (which, after deleting, does not show back up in the inbox). In fact, after deleting it, when I re-add it, it still has the original channel names from when it was first set up.

I did a bundle:restart on it, but that didn’t change anything.

seime · July 30, 2023, 5:24pm

Every time the thing is initialized, channels are updated to whatever the device reports. At least it is supposed to. A simple thing disable+ reenable should trigger this.

Regarding discovery this is based on the built in openhab mdns service. I’ve noticed it may take a few minutes before the device is rediscovered after being deleted.

Feel free to share logs at debug level.

Regards Arne

davecorder · July 30, 2023, 5:52pm

Thanks! You’re right, I was just being impatient - I gave it a few more minutes and it came back to the inbox and when I added it again from there, it had the right channels.

If I can repro the issue again later, I’ll gather debug logs.

Pedro_Liberal · August 5, 2023, 6:17pm

@seime hello friend sorry for the dela, babies have a way of throwing a wrench into our plans.
Anyway:
Jar worked great, esp device was auto discovered, all good until here.
However, the thing created had no IP assigned (the esp device has static IP set, and the esphome container has the variable “use IP” set to true because mDNS refuses to work on my network.).

Once I pointed it to the correct ip I get a parse error.

No other errors. I’m currently only able to use one hand. As soon as I get the second one back I’ll check the logs to see what’s up over there.

Edit:
Oh right, I added the mqtt component to the esphome device and the mqtt broker with openHAB homeassistant discovery worked fine:

Edit2:
God this post is becoming big. Sorry about that.
Okay so I went over my network and noticed that igmp was on and mDNS off over on my unifi network. Updated that and now mDNS works. I confirmed it by checking the logs through Wi-Fi:

So that takes care of one problem. But when adding the .local hostname on openHAB i get an error and it seems like it’s looking for the hostname, twice?
Hope the screenshot clarifies what I mean.
Maybe a hint but I seem to be unable to ping the .local addresses from inside the openHAB container, but the IP works. Would it be possible to allow both options??

And once again, sorry for the long post. It’s gotta be a record somewhere xD

Logs!

With ip I get the error socket closed:

error log #1

14:51:13.351 [WARN ] [ernal.internal.handler.ESPHomeHandler] - [192.168.2.64] Error initial connection
no.seime.openhab.binding.esphome.internal.internal.comm.ProtocolAPIError: Failed to connect to 192.168.2.64:6053: Socket closed
at no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextConnection.connect(PlainTextConnection.java:85) ~[?:?]
at no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.connect(ESPHomeHandler.java:162) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
14:51:13.355 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘esphome:device:bme680’ changed from UNKNOWN: Connecting to 192.168.2.64:6053 to OFFLINE (COMMUNICATION_ERROR): Failed to connect to 192.168.2.64:6053: Socket closed

With bme680.local I get “error initial connection”:

error log #2

14:54:31.388 [WARN ] [ernal.internal.handler.ESPHomeHandler] - [bme680.local] Error initial connection
no.seime.openhab.binding.esphome.internal.internal.comm.ProtocolAPIError: Failed to connect to bme680.local:6053: bme680.local
at no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextConnection.connect(PlainTextConnection.java:85) ~[?:?]
at no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.connect(ESPHomeHandler.java:162) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
14:54:31.392 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing

seime · August 6, 2023, 4:10pm

Hi Pedro,

fully understand you on the baby situation

After testing with an ESPHome device using api encryption (which is good - but I have not implemented it yet), I get the same error. I’ll see if I can detect encryption being requested by the device and provide a better error message.

Temprorary solution: Use something like

api:
  password: "MyPassword"

and not

api:
  encryption:
    key: <base64 encoded key>

… when flashing your ESPHome devices.

Regarding mDNS and hostname config; something else is fishy - reported on github: Reverts back to mDNS name · Issue #1 · seime/openhab-esphome · GitHub . Cannot see what the problem is since I have no code to update the thing configuration, only channels and properties. Must dig deeper.

Hope this helps, thanks for testing

Pedro_Liberal · August 6, 2023, 5:36pm

Regarding the api and encryption:
So that’s what you meant! I totally misunderstood you. Got it working now, all channels auto populates too.
The one thing that it would be cool to do was if both the IP and password got auto populated too, but maybe this isn’t possible?

Regarding the hostname, I confirmed that it’s not just my container that can’t ping the hostname, the host machine also cannot. So I assume that this is a problem on my network/server that I need to diagnose.
Regardless, i can now confirm that:

auto discovery works
channels are auto populated correctly with descriptions and everything (<3!!!)
no major errors in log.

A+!

There is one weird behavior I’m seeing and that is every once in a while the thing reverts to off-line with the error “ESPhome did not respond to ping requests. 4 pings sent in 10 s delay .” If I leave for a minute or two it reverts back to online. Then offline. And so on. Log doesn’t add anything else.

I’ll keep checking for other weird behavior.

Edit: small correction on my side, did find some info on the logs after all, dumping it below, hope it helps. Please let me know if you’d prefer for me to create a bug in GitHub based on the info below, I’ll happily do so. I’ve noticed that some channels use text or units and I’m guessing that’s why they are erroring out. I understand you’re still working on it so no pressure whenever you need me to test something just reach out!

ping responses failing?

[192.168.2.64] Ping responses lacking Waited 4 times 10 seconds, total of 40. Assuming connection lost and disconnecting

channel type not yet implemented

17:39:05.130 [WARN ] [ternal.message.AbstractMessageHandler] - Not implemented channel type for atmospheric_pressure. Defaulting to ‘Number’. Create a PR or create an issue at https://github.com/seime/openhab-esphome/issues. Stack-trace to aid where to add support. Also remember to add appropriate channel-type in src/main/resources/thing/channel-types.xml: [java.base/java.lang.Thread.getStackTrace(Thread.java:1602), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.channelType(AbstractMessageHandler.java:100), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:35), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:1), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:132), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.handleConnected(ESPHomeHandler.java:315), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.onPacket(ESPHomeHandler.java:260), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.decodeProtoMessage(PlainTextPacketStreamReader.java:173), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.dataReceived(PlainTextPacketStreamReader.java:157), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.lambda$1(PlainTextPacketStreamReader.java:85), java.base/java.lang.Thread.run(Thread.java:829)]
17:39:05.168 [WARN ] [ternal.message.AbstractMessageHandler] - Not implemented channel type for . Defaulting to ‘Number’. Create a PR or create an issue at Issues · seime/openhab-esphome · GitHub. Stack-trace to aid where to add support. Also remember to add appropriate channel-type in src/main/resources/thing/channel-types.xml: [java.base/java.lang.Thread.getStackTrace(Thread.java:1602), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.channelType(AbstractMessageHandler.java:100), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:35), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:1), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:132), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.handleConnected(ESPHomeHandler.java:315), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.onPacket(ESPHomeHandler.java:260), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.decodeProtoMessage(PlainTextPacketStreamReader.java:173), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.dataReceived(PlainTextPacketStreamReader.java:157), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.lambda$1(PlainTextPacketStreamReader.java:85), java.base/java.lang.Thread.run(Thread.java:829)]
17:39:05.187 [WARN ] [ternal.message.AbstractMessageHandler] - Not implemented channel type for . Defaulting to ‘Number’. Create a PR or create an issue at Issues · seime/openhab-esphome · GitHub. Stack-trace to aid where to add support. Also remember to add appropriate channel-type in src/main/resources/thing/channel-types.xml: [java.base/java.lang.Thread.getStackTrace(Thread.java:1602), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.channelType(AbstractMessageHandler.java:100), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:35), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:1), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:132), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.handleConnected(ESPHomeHandler.java:315), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.onPacket(ESPHomeHandler.java:260), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.decodeProtoMessage(PlainTextPacketStreamReader.java:173), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.dataReceived(PlainTextPacketStreamReader.java:157), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.lambda$1(PlainTextPacketStreamReader.java:85), java.base/java.lang.Thread.run(Thread.java:829)]
17:39:05.208 [WARN ] [ternal.message.AbstractMessageHandler] - Not implemented channel type for . Defaulting to ‘Number’. Create a PR or create an issue at Issues · seime/openhab-esphome · GitHub. Stack-trace to aid where to add support. Also remember to add appropriate channel-type in src/main/resources/thing/channel-types.xml: [java.base/java.lang.Thread.getStackTrace(Thread.java:1602), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.channelType(AbstractMessageHandler.java:100), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:35), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:1), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:132), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.handleConnected(ESPHomeHandler.java:315), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.onPacket(ESPHomeHandler.java:260), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.decodeProtoMessage(PlainTextPacketStreamReader.java:173), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.dataReceived(PlainTextPacketStreamReader.java:157), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.lambda$1(PlainTextPacketStreamReader.java:85), java.base/java.lang.Thread.run(Thread.java:829)]
17:39:05.225 [WARN ] [ternal.message.AbstractMessageHandler] - Not implemented channel type for carbon_dioxide. Defaulting to ‘Number’. Create a PR or create an issue at Issues · seime/openhab-esphome · GitHub. Stack-trace to aid where to add support. Also remember to add appropriate channel-type in src/main/resources/thing/channel-types.xml: [java.base/java.lang.Thread.getStackTrace(Thread.java:1602), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.channelType(AbstractMessageHandler.java:100), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:35), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:1), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:132), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.handleConnected(ESPHomeHandler.java:315), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.onPacket(ESPHomeHandler.java:260), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.decodeProtoMessage(PlainTextPacketStreamReader.java:173), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.dataReceived(PlainTextPacketStreamReader.java:157), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.lambda$1(PlainTextPacketStreamReader.java:85), java.base/java.lang.Thread.run(Thread.java:829)]
17:39:05.244 [WARN ] [ternal.message.AbstractMessageHandler] - Not implemented channel type for volatile_organic_compounds_parts. Defaulting to ‘Number’. Create a PR or create an issue at Issues · seime/openhab-esphome · GitHub. Stack-trace to aid where to add support. Also remember to add appropriate channel-type in src/main/resources/thing/channel-types.xml: [java.base/java.lang.Thread.getStackTrace(Thread.java:1602), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.channelType(AbstractMessageHandler.java:100), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:35), no.seime.openhab.binding.esphome.internal.internal.message.SensorMessageHandler.buildChannels(SensorMessageHandler.java:1), no.seime.openhab.binding.esphome.internal.internal.message.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:132), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.handleConnected(ESPHomeHandler.java:315), no.seime.openhab.binding.esphome.internal.internal.handler.ESPHomeHandler.onPacket(ESPHomeHandler.java:260), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.decodeProtoMessage(PlainTextPacketStreamReader.java:173), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.dataReceived(PlainTextPacketStreamReader.java:157), no.seime.openhab.binding.esphome.internal.internal.comm.PlainTextPacketStreamReader.lambda$1(PlainTextPacketStreamReader.java:85), java.base/java.lang.Thread.run(Thread.java:829)]
17:39:05.280 [WARN ] [ernal.internal.handler.ESPHomeHandler] - [192.168.2.64] Unhandled message of type io.esphome.api.ListEntitiesTextSensorResponse. This is lack of support in the binding. Content: 'object_id: “bme680_iaq_accuracy”
key: 1338075055
name: “BME680 IAQ Accuracy”
unique_id: “bme680text_sensorbme680_iaq_accuracy”
icon: “mdi:checkbox-marked-circle-outline”
'.

seime · August 6, 2023, 8:25pm

Great that you’ve progressed!

There would’nt be much security if the ESP shared it’s secrets? Regarding IP there is probably something that can be done. Maybe you can share your ESP (network) config so I can reproduce locally?

There is a watchdog/ping being sent every 10 seconds. If 4 fails in a row, the binding assumes the ESP stopped or network got blocked for some reason. And disconnects, waits a little while and reconnects. I now have this problem on 1 of my 6 ESPs, and not sure what it is. Cannot remember I saw this on OH 3, only on OH4. Which version are you testing on?

Regarding the channel types; I have spent some time this weekend to add support for more quantity types. However there are multiple warnings in the log; a few that should be fixed now, but those that say Not implemented channel type for . . Which device_class are these entities? Could you try adding an entry in the ESPHome config for this device? Note that string, enum and timestamp isnt supported yet, but numeric sensors should be ok AFAIK.

And there isn’t any support for TextSensor yet (last warning in log)

New version uploaded to existing links. Be aware that channel types have changed, you might need to recreate the thing if you are not using thing files (in that case it should be sufficient to make OH reload the file).

Regards

Pedro_Liberal · August 11, 2023, 11:46am

Sorry for the delay once again, here we go:

Thank you Let’s keep it up!

Ahah, certainly! But at least the IP ?
Heres the config, with passwords and keys taken out:

My BME680 esphome config

esphome:
name: “bme680”
friendly_name: BME680-fullConfig

esp32:
board: esp32dev
framework:
type: arduino

Enable logging

logger:

Enable Home Assistant API

api:
#encryption:
key: “notmykey”
password: notmypassword

ota:
password: “notmypassword”

wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password

manual_ip:

static_ip: 192.168.2.64

gateway: 192.168.2.1

subnet: 255.255.255.0

Enable fallback hotspot (captive portal) in case wifi connection fails

ap:
ssid: “Bme680-Fullconfig-Test”
password: “notmypassword”

captive_portal:

Enable MQTT

mqtt:
broker: 192.168.2.98

i2c:
sda: 21
scl: 22
scan: true
id: bus_a

bme680_bsec:
# i2c address
# -----------
# Common values are:
# - 0x76
# - 0x77
# Default: 0x76
address: 0x77

# Temperature offset
# ------------------
# Useful if device is in enclosure and reads too high
# Default: 0
temperature_offset: 0

# IAQ calculation mode
# --------------------
# Available options:
# - static (for fixed position devices)
# - mobile (for on person or other moveable devices)
# Default: static
iaq_mode: static

# Sample rate
# -----------
# This controls the sampling rate for gas-dependant sensors and will govern the interval
# at which the sensor heater is operated.
# By default this rate will also be used for temperature, pressure and humidity sensors
# but these can be overridden on a per-sensor level if required.
#
# Available options:
# - lp (low power - samples every 3 seconds)
# - ulp (ultra low power - samples every 5 minutes)
# Default: lp
sample_rate: lp

# Interval at which to save BSEC state
# ------------------------------------
# Default: 6h
state_save_interval: 6h

sensor:

platform: bme680_bsec
temperature:

Temperature in °C

name: “BME680 Temperature”
sample_rate: lp
filters:
- median:
window_size: 7
send_every: 4
send_first_at: 3

pressure:

Pressure in hPa

name: “BME680 Pressure”
sample_rate: lp
filters:
- median:
window_size: 7
send_every: 4
send_first_at: 3

humidity:

Relative humidity %

name: “BME680 Humidity”
sample_rate: lp
filters:
- median:
window_size: 7
send_every: 4
send_first_at: 3

gas_resistance:

Gas resistance in Ω

name: “BME680 Gas Resistance”
filters:
- median:
window_size: 7
send_every: 4
send_first_at: 3

iaq:

Indoor air quality value

name: “BME680 IAQ”
filters:
- median:
window_size: 7
send_every: 4
send_first_at: 3

iaq_accuracy:

IAQ accuracy as a numeric value of 0, 1, 2, 3

name: “BME680 Numeric IAQ Accuracy”

co2_equivalent:

CO2 equivalent estimate in ppm

name: “BME680 CO2 Equivalent”
filters:
- median:
window_size: 7
send_every: 4
send_first_at: 3

breath_voc_equivalent:

Volatile organic compounds equivalent estimate in ppm

name: “BME680 Breath VOC Equivalent”
filters:
- median:
window_size: 7
send_every: 4
send_first_at: 3

text_sensor:

platform: bme680_bsec
iaq_accuracy:
IAQ accuracy as a text value of Stabilizing, Uncertain, Calibrating, Calibrated
name: “BME680 IAQ Accuracy”

Openhab V3.3 Release Build (I’m remodelling the apartment and I’d rather not update Openhab before I have all devices setup again, otherwise troubleshooting will take longer to diagnose if it’s an openhab problem, device problem, or whatnot.)

I’m not sure how to check the device class, but, the esphome device config page is here, and the config is in the hidden box above. If those don’t have the info, can you tell me where to look please?

Copy that, tonight I should have some time to update the binding, recreate the thing and check the logs

Thank you and wish you a great weekend

seime · August 12, 2023, 5:38pm

I’ve pushed a new version with improvements in sensor UoM handling. Also added support for text_sensors.

Regarding ip address changing back to mdns hostname I’ve dug some more, details here mDNS discovery result overwrites existing thing configuration/property · Issue #3753 · openhab/openhab-core · GitHub
For now I’ve randomized the thing UIDs, so whenever you add one from the inbox I suggest you manually set decent thing names to avoid unreadable link names in item files as well as rules referring to the thing.

No progress on the ping getting stuck, plan to rewrite socket handling to java nio instead of the old style (socket + thread) that I’ve used. Maybe that helps.

Cheers

Pedro_Liberal · August 13, 2023, 2:58pm

@seime slow and steady clearly getting better

All units auto picked up, linking to old items also worked. Thank you for the text sensor, that was a nice surprise I made sure to include the calibration status in the screenshot above for you to see

I checked the logs and I don’t see any errors per se, I think they are just informative notes, but in case they matter I’ll share them as well below.

logs

14:42:35.427 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘ESPHomebme680_BME680Temperature’ changed from 28.272066 °C to 28.281914 °C
14:42:35.453 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘ESPHomebme680_BME680Humidity’ changed from 60.114280700683594 % to 60.10902404785156 %
14:42:37.536 [WARN ] [ternal.message.AbstractMessageHandler] - Unit ‘hPa’ unknown to openHAB, returning DecimalType for state ‘null’
14:42:37.574 [WARN ] [ternal.message.AbstractMessageHandler] - Unknown deviceClass ‘’ reported by device, binding needs to be updated
14:42:37.594 [WARN ] [ternal.message.AbstractMessageHandler] - Unknown deviceClass ‘’ reported by device, binding needs to be updated
14:42:37.612 [WARN ] [ternal.message.AbstractMessageHandler] - Unknown deviceClass ‘’ reported by device, binding needs to be updated
14:42:37.631 [WARN ] [ternal.message.AbstractMessageHandler] - Unit ‘ppm’ unknown to openHAB, returning DecimalType for state ‘null’
14:42:37.650 [WARN ] [ternal.message.AbstractMessageHandler] - Unit ‘ppm’ unknown to openHAB, returning DecimalType for state ‘null’

Now to leave the sensor running and see if the disconnects are affecting the data logging

seime · August 14, 2023, 1:29pm

Take a look at GitHub - seime/openhab-esphome: ESPHome native API implementation for openHAB binding , second question. The doc is a bit inaccurate about the exact log statement, but adding a device_class will help.

Also fixed a few bugs in the latest build that should reduce your log warnings.

Thanks for testing!

Regards

seime · August 15, 2023, 2:36pm

@Pedro_Liberal pushed a new version Java NIO instead of socket+thread. It fixed my stability issue / ping responses getting lost and subsequent reconnect.

Had it running for a day now, no disconnects on any devices.

Cheers

davecorder · August 27, 2023, 4:50pm

I’m running OpenHAB 4.0.2 now with the no.seime.openhab.binding.esphome-4.1.0-SNAPSHOT.jar for the native API binding.

When it works, it works great. But I’m having a problem with the binding staying connected to my devices (I have about a dozen configured right now on OH). Every so often, all the devices will go into an UNKNOWN state and just sit there until I reload the bundle. Then, a few minutes after the reload, they’ll finally all come back ONLINE. Until they get stuck again.

I had logging set for the bundle to DEBUG and didn’t see anything useful in the logs (but maybe I didn’t look back far enough, because in the most recent instance, they went offline sometime overnight).

I just enabled TRACE logging and will keep an eye on it for the next couple days.

FYI, I updated my log4j2.xml file with these sections to enable TRACE-level logging to a separate file for easier analysis later:

<!-- ESPHome Native API Binding file appender -->
<RollingRandomAccessFile fileName="${sys:openhab.logdir}/esphome.log" filePattern="${sys:openhab.logdir}/esphome.log.%i.gz" name="ESPHOME">
    <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n"/>
    <Policies>
        <OnStartupTriggeringPolicy/>
        <SizeBasedTriggeringPolicy size="16 MB"/>
    </Policies>
    <DefaultRolloverStrategy max="14"/>
</RollingRandomAccessFile>

and

<Logger level="TRACE" name="no.seime.openhab.binding.esphome">
    <AppenderRef ref="ESPHOME"/>
</Logger>

seime · August 27, 2023, 9:04pm

The filename of the bundle is the same even if I push new updates.

Could you check the bundle version in openhab-cli? Date should be indicate date around 15th of August if you are running the latest build. If not, try updating. There was a stability fix included there ref post above.

Does the thing have any detailed status message as well?

Regards

Andrew_Rowe · August 27, 2023, 9:28pm

Could you maybe update the first post and add the link to the bundles and the readme so new folks can find the latest without having to dig thru the whole thread?

I’d really like to see this become an official part of openHAB. ESPHome makes using microcontrollers super easy, I’ve got bizzilions of them and they can replicate sensor functionality that would otherwise be X3 or X4 much $$$
Most Zwave, Zigbee, WiFi sensors are $20-$25 usd min and you can do the same thing with a esp8266 for $5

seime · August 28, 2023, 5:19pm

Done

ESPHome binding for the Native API

Enable logging

Enable Home Assistant API

manual_ip:

static_ip: 192.168.2.64

gateway: 192.168.2.1

subnet: 255.255.255.0

Enable fallback hotspot (captive portal) in case wifi connection fails

Enable MQTT

Temperature in °C

Pressure in hPa

Relative humidity %

Gas resistance in Ω

Indoor air quality value

IAQ accuracy as a numeric value of 0, 1, 2, 3

CO2 equivalent estimate in ppm

Volatile organic compounds equivalent estimate in ppm

IAQ accuracy as a text value of Stabilizing, Uncertain, Calibrating, Calibrated