i think i miss something essential right now, sorry.
How do i get, to stay with the example, the cannel outside_tempersture in OH.
The auto discovery is not showing it for the created ESPHome Thing.
Add interal: false to the ESPHome config:
sensor:
- platform: homeassistant
name: "Outside temperature"
entity_id: ItemStateChangedEvent.MyTemperatureItem
device_class: temperature
internal: false
This basically then means:
- Listen for OH item state changes for
MyTemperatureItem - .. and export changes back to OH on channel
outside_temperature(that you can link to a different Item - not the same or you will have created a loop)
It does not make much sense to do this unless you are looking to just debug/verify that it works.
I’ve got a few Tuya-based fans I’ve converted to ESPHome firmware. Right now I’m just controlling them through MQTT and that’s working fine, but it would be nice to get them natively supported. They show this message in the logs:
14:42:18.139 [WARN ] [phome.internal.handler.ESPHomeHandler] - [tower-fan-02] Unhandled message of type io.esphome.api.FanStateResponse. This is lack of support in the binding. Content: 'key: 2367400422'.
I wouldn’t mind taking a stab at this myself if I can find some spare time, but I don’t even have a build environment set up yet. In the meantime, any tips on what sort of handler(s) I would need to add and where in order to fully support fans?
EDIT:
I made a stab at it, latest version should have at least some fan support. Feel free to test and give feedback ![]()
Excellent! As I don’t have any fans myself, I have not added support as I cannot test the integration.
Thank you for this binding.
I am measuring the water consumption and it works fine. Calculating the total water consumption in OH is not entirely reliable, so I would like to calculate it in the ESP32.
But I am struggling on how to set the total amount of pulses from OH.
Here is the relevant yaml code fragment:
api:
encryption:
key: !secret encryption_key
sensor:
- platform: pulse_counter
name: "Waterverbruik"
id: pulse_counter_id
pin:
number: GPIO5
mode:
input: true
pullup: true
unit_of_measurement: "l"
filters:
- multiply: 0.5 # 2 pulses per liter
total:
unit_of_measurement: 'm³'
name: 'Totaal waterverbruik'
filters:
- multiply: 0.0005 # 2000 pulses per m³
- platform: homeassistant
name: "Set pulse total count"
entity_id: ItemStateChangedEvent.esp1WaterSetTotalPulses
id: totaal
internal: false
on_value:
then:
- pulse_counter.set_total_pulses:
id: pulse_counter_id
value: !lambda 'return id(totaal).state;'
In OH the channel set_pulse_total_count is discovered as a Number. I can then define an item esp1WaterSetTotalPulses.
With the API explorer I can enter a value for the item esp1WaterSetTotalPulses. In the ESP32 the total number of pulses and hence the total water consumption is not set.
I am new to ESPHome. Probably there is something wrong in the platform:homeassistant section.
Found it myself, I was very close:
- platform: homeassistant
name: "Set pulse total count"
entity_id: ItemStateChangedEvent.esp1WaterSetTotalPulses
internal: false
on_value:
then:
- pulse_counter.set_total_pulses:
id: pulse_counter_id
value: !lambda 'return int(x);'
Not clear yet what internal: false means. If it’s not there, the channel is not discovered. If it’s defined, according to what is written above, a loop is created. Does this have negative consequences?
From the Esphome docs:
- internal (Optional, boolean): Mark this component as internal. Internal components will not be exposed to the frontend (like Home Assistant). Only specifying an
idwithout anamewill implicitly set this to true.
Can you return empty {} in your lambda to avoid the Esphome device to update the value back to openhab?
I would also consider to store this value in a global variable in Esphome to avoid the Esp to be dependent on OH to get the value on boot? Or just hardcode it on the pulse counter config if it isnt supposed to change?
Ps I have not tested it myself.
@seime hello my friend!
Quick question, have you added compatibility for presence sensors yet? I’m looking at one right now and I was wondering if it would work.
Hi @Pedro_Liberal, I think they would work just fine. Most of the entity types are now supported!
Cheers
After all, calculating totals in the ESP does not seem to be a good idea for two reasons:
-
If OH is restarted, the old pulse value count that was once set, is restored from the persistence (restoreonstartup) and written to the ESP. The total is therefore totally wrong. This can be avoided by unlinking channel and item. If you have to send a new value of the pulse value count to the ESP, you have to temporarily link channel and item again.
-
The total in the ESP is stored in volatile memory. After a power outage, the total is reset to 0.
So I prefer to calculate the total with a rule in OH. But after a week or so I see a difference of about 5L with the reading on the water meter. I’ll experiment further with the pulse meter sensor, which works in a different way than the pulse counter sensor.
Anyway, thanks again for this nice binding.
FYI, I’m using LD2410 MM sensor on esp32 and work fine in OH
Ah cool! That’s my exact setup
I’ll set it up today and have a go at it.
Thank you for this binding! It works like a charm =)
One thing I was not able to figure out from the README is the server configuration parameter: The thing has a server parameter, in the README it says Expected name of ESPHome. Used to ensure that we're communicating with the correct device. However I do not understand what to put in there.
I tried the name of the ESPHome web interface but then the connection did not come up.
What exactly shall I enter in this field?
Hi @Felix_Schneider , thanks for your kind words.
Use esphome.name value like below:
esphome:
name: <VALUE_FROM_HERE>
platform: ESP32
board: nodemcu-32s
friendly_name: ...
Thank you very much, works like a charm! Maybe
Use
esphome.name
would be a good addition to the README
There is a test version with some Bluetooth proxy support available here; Release Latest Build · seime/openhab-esphome · GitHub
For now it only supports beacon advertisements (device broadcasts data but without any 2-way connection being made with the device). So no need to test connectable devices such as Airthings etc, it might blow up.
I’ve tested it with a the new BTHome Binding and gotten a handful of b-parasite plant sensors up and running via ESPHome devices.
I’d love for someone to test it and give some feedback. There are a few steps that must be taken in order to enable this functionality, so please head over to Github to read the details.
Are there any plans to merge this binding into main of the openhab bindings repo making this an official binding that can be installed without the marketplace?
Hi, thank you for this great binding - I was able to connect my ESP32 via the binding successfully, if I configure the IP address or the device name „shell-dpm“. However, after some hours the binding overwrites the hostname with „shell-dpm.local.“, and at that moment, the connection ist lost.
Does anyone have an idea, why the host entry doesn‘t stay as configured, and how I maybe can change this „shell-dpm.local.“ as default?
Second question: I did not figure out any valid configuration for „ ESPHome device server name“ - the solution esphome.“name“ does not work. As long as I keep it empty, the connection works (for some hours).
Yes. See mDNS discovery result overwrites existing thing configuration/property · Issue #3753 · openhab/openhab-core · GitHub
TLDR: It’s a feature, not a bug of openHAB. The suggested workaround in OH just got stalled, so I suggest you define the thing in a file to deny openHAB overwriting the address.
See ESPHome binding for the Native API [4.0.0;6.0.0) - #175 by seime . But this does not work for you? Please send logs via PM and I’ll take a look.
There are no plans to merge at this time.