ESPHome binding for the Native API [4.0.0.0;6.0.0.0)

After recreating the thing with a different thing Id it sorted itself out

I am getting the errors below with a climate device. I am using version 4.1.0.202408240749

2024-09-01 15:03:40.516 [WARN ] [me.internal.comm.AbstractFrameHelper] - [waterclosetheater] 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) ~[?:?]
	at no.seime.openhab.binding.esphome.internal.handler.ESPHomeHandler.onPacket(ESPHomeHandler.java:282) ~[?:?]
	at no.seime.openhab.binding.esphome.internal.comm.AbstractFrameHelper.decodeProtoMessage(AbstractFrameHelper.java:104) ~[?:?]
	at no.seime.openhab.binding.esphome.internal.comm.PlainTextFrameHelper.headerReceived(PlainTextFrameHelper.java:103) ~[?:?]
	at no.seime.openhab.binding.esphome.internal.comm.AbstractFrameHelper.processBuffer(AbstractFrameHelper.java:72) ~[?:?]
	at no.seime.openhab.binding.esphome.internal.comm.AbstractFrameHelper.processReceivedData(AbstractFrameHelper.java:119) ~[?:?]
	at no.seime.openhab.binding.esphome.internal.comm.ConnectionSelector.processReceivedData(ConnectionSelector.java:97) ~[?:?]
	at no.seime.openhab.binding.esphome.internal.comm.ConnectionSelector.processKey(ConnectionSelector.java:80) ~[?:?]
	at no.seime.openhab.binding.esphome.internal.comm.ConnectionSelector.lambda$0(ConnectionSelector.java:42) ~[?:?]
	at java.lang.Thread.run(Thread.java:840) [?:?]

There was a regression in that version that was fixed. Try the latest.

Now that this binding is available I’m evaluating the possibility to flash esphome in my relays but I’m facing a problem. Almost all my relays are flashed with tasmota and I use pulsetime in more than half of them.

From what I’ve read esphome has nothing equivalent to pulsetime. But has scripts that can use variables. I’ve seen examples in the HA forum where these variables can be updated by HA, unfortunately I’ve seen no OH examples.

Is this possible using this binding ? How ?

Many thanks

I don’t know what pulsetime does, but with ESPhome, every variable you define in the esphome yaml is picked up by the ESPhome binding in OH, so works perfectly.
Just try one and see what happens :wink:

Powers off the switch after a number of milliseconds Defaults to 0 (no automatic power off)

Sorry, I’m an esphome newbie, can you post an example ? Thanks

sure, you start with ESPhome.com, lots of examples of sensors.

I have 2 climate sensors (SCD30 and SEN54) connected to and ESP32 board. Next to the basic yaml commands, here are the variables of those 2 sensors in the yaml file for the ESPhome config on the board:

sensor:
  - platform: scd30
    co2:
      name: "StudySCD30CO2"
      accuracy_decimals: 1
    temperature:
      name: "StudySCD30 Temperature"
      accuracy_decimals: 2
    humidity:
      name: "StudySCD30 Humidity"
      accuracy_decimals: 1
    temperature_offset: 1.0C
    address: 0x61
    update_interval: 60s
  - platform: sen5x
    id: sen54
    pm_1_0:
      name: " PM <1µm Weight concentration"
      id: pm_1_0
      accuracy_decimals: 1
    pm_2_5:
      name: " PM <2.5µm Weight concentration"
      id: pm_2_5
      accuracy_decimals: 1
    pm_4_0:
      name: " PM <4µm Weight concentration"
      id: pm_4_0
      accuracy_decimals: 1
    pm_10_0:
      name: " PM <10µm Weight concentration"
      id: pm_10_0
      accuracy_decimals: 1
    temperature:
      name: "Temperature"
      accuracy_decimals: 1
    humidity:
      name: "Humidity"
      accuracy_decimals: 0
    voc:
      name: "VOC"
      algorithm_tuning:
        index_offset: 100
        learning_time_offset_hours: 12
        learning_time_gain_hours: 12
        gating_max_duration_minutes: 180
        std_initial: 50
        gain_factor: 230
    nox:
      name: "NOX"
      algorithm_tuning:
        index_offset: 100
        learning_time_offset_hours: 12
        learning_time_gain_hours: 12
        gating_max_duration_minutes: 180
        std_initial: 50
        gain_factor: 230
    temperature_compensation:
      offset: 0
      normalized_offset_slope: 0
      time_constant: 0
    acceleration_mode: low
    store_baseline: true
    address: 0x69
    update_interval: 60s
 

Next you add an ESPhome Thing to Openhab containing the ESP32/ESPhome board with the sensors. Once added, these items show up in OpenHab:

And the variables of the ESPhome Yaml file show up as items in OH.

As mentioned, start with an ESP32 board, a couple of sensors and configure them with ESPhome via ESPhome.com. And if they’re working, connect them to OH.

Turns a standard GPIO based relay off after 300ms after turning on (used to simulate garage gate button)

switch:
  - platform: gpio
    pin: 33
    id: gate_relay
    name: "Gate Relay"
    on_turn_on:
      - delay: 300ms
      - switch.turn_off: gate_relay

This is pure esphome config and has nothing to do with OH or HA. If you send an ON command to the OH Switch item linked to the corresponding channel, the OH switch will update to ON first and then OFF after approx 300ms.

Thank you both, but:

@seime Your solution may work for small delays, but it has problems for large delays. See here a better solution.

@emiel What I want is to write in OH. I think your solution allows read only. This is the solution for HA folks. I’ve tried it with OH without success.

https://github.com/seime/openhab-esphome?tab=readme-ov-file#sending-state-from-openhab-to-esphome

Not very well tested, if you think there is a bug, please open an issue.

Happy hacking!

perhaps mqtt is also an option for sending commands.

is the switching that complex that you need a specific solution instead of native OH switching? again, I don’t know what pulsetimer exactly adds to regular switching.

There are multiple solutions to the same problem of course. Pulsetime runs on the device itself so assume OpenHAB goes down, it will still turn off, iirc.

There are cases (sprinkler systems) where pulsetimes can be 20min or higher. I cannot risk water waste in case OH (or Wi-Fi) goes down during that period. My watering system (sonoff 4ch pro) is autonomous once OH sets pulsetimes for each zone (that depend on soil moisture level and wheather forecast) and starts the cycle. Short cycles can also be started using RF command (my gardener uses it to verify and adjust sprinklers) without any OH intervention. This is a complex case.

I have another case (bath water heating) where the resistance can be turned on for hours. I cannot risk not having it switched off. Same concept as above, OH computes pulsetime (depending on actual and desired water temperatures) and switches on if needed.

There are simple cases (such as the garage door pulse mentioned by Arne) where you want to mimic ā€œbutton short pressā€ functionality. And once you are used to pulsetime why bother OH with yet another rule (or expire) to switch off ? Whenever possible I use pulsetime (or expire in cases where pulsetime is not available) to switch off relays automatically. So even in simple cases there is a benefit of using pulsetime.

See Actions, Triggers, Conditions - ESPHome - Smart Home Made Simple - most likely identical or similar to the forum post. But from the official docs. Should solve your case in a good manner.

You can also execute i.e. valve shutoff on ESP boot and/or shutdown as another failsafe in case your ESP reboots for some reason (ie OTA during a watering/heating cycle). ESPHome Core Configuration - ESPHome - Smart Home Made Simple

Make your device as autonomous as possible as @Pedro_Liberal points out.

This right here. This should be best practice for all important devices. I have recently helped a colleague troubleshoot an extreme increase of electrical consumption and we found out that a water pump had gotten ā€œstuckā€ ON because the contacts got submerged somehow. If it had an external relay, the pulse time would have resolved the issue by cutting power all together to it.

I understant personal choices, no problem. But let’s not focus on exceptions. I have more esp32 crashes (a few in the last few months since I started using them) than OH crashes in the last 3 years (0!).

my sprinkler system therefor has ran fine without any problems in 3 years, 100% controlled by OH.

@seime quick question! I’m still using a jar on the folder. Should I update to the marketplace/add on store binding? Or are the jars here more recent?

The jar listed in the first link of this thread is the one used on the Marketplace - and is always the latest (until I change the version number, it is still at 4.1.x something). (ā€œchangelogā€ here - btw basic lock support added last week)

The binding/linked jar is updated every now and then (on code push), but the Marketplace as no concept of updating a binding nor telling the user about a new version. (Remove+Reinstall is the only option). The only difference between downloading to the addons folder vs installing from the marketplace is what you see in the ā€œAdd-on Storeā€ list of installed addons. If installed from the Marketplace, you’ll get some more context info.
I.e.:


vs

Then if I understood correctly, if I install from the market place it will be updated now, but if you do an update later, the way to update the binding would be to reinstall it (uninstall + reinstall).
Conversely I could just download the jar and dump it on the folder ….

Humm…

AFAIK that is how the Marketplace works.
If you want to always be up to date, create a cron task that download the jar automatically to the addons folder at fixed intervals instead :wink:

PS: Choose either method