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 ![]()
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.
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 ![]()
PS: Choose either method


