Closed unbreakab1e closed 3 years ago
api source api issues api recent changes (message by IssueLinks)
Hmm, yeah we could handle that a bit better (but certainly running once every second will not be officially supported, as many other things like binary sensors etc also suffer). Probably just a timeout value that needs to be updated somewhere in aioesphomeapi
Yeah, of course I was thinking that I am trying to do something really strange and unsupported here 😅 Running OpenTherm communication in a loop() instead of update() produces the same result, so maybe there are some better options to implement such a custom component I should investigate? Maybe some async communication with boiler is possible? Unfortunately I couldn't find any examples in the ESPHome docs or DIY section and I only recently started using C++ so I cannot devise a solution myself yet. If this is not possible, well, then the ability to increase aioesphomeapi
timeout in hass configuration will do the trick.
Otto is saying that aioesphome shouldn't die if ESPHome dosn't replay quickly which is ok,
however it seems you don't know how to deal with this? In general when you delay() for more than 16ms = 1000ms / 60hz (ESPHome loop rate) then you might be halting the processor unnecessarily. You'll do lower delays only when handling very little delays.
Your polling component is to be called every 10 seconds, so you don't need to delay any, just let the function end and it will be called again in 10 seconds, and aioesphome will be happy.
The thing is that as far as I understand the OpenTherm specification, master device (thermostat) should communicate with slave device (boiler) at least every second. At the same time it allows a response time ranging from 20 to 800 milliseconds. Arduino implementations are leaning towards longer periods and they have a hardcoded timeout of one second after which they present communication failure.
I will have immediate access to boiler only the next weekend, so right now I am preparing the software and package for the thermostat beforehand, and there are two possibilities. In case my boiler is fast to respond, running a loop() inside Generic Component with small delays and having a separate Polling Component to present sensor values should be ok, right? But if it is slow to communicate, and the OpenTherm library will block for 800ms, are there any ways to deal with it in ESPHome?
Hi @unbreakab1e ,
I found this issue after posting mine : https://github.com/esphome/issues/issues/1455. I'm currently experiencing the exact same issues.
Did you managed to fix this within ESPhome? Or are you using the MQTT solution ?
It looks like this is going to be impossible to solve within ESPhome unfortunately.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Operating environment/Installation (Hass.io/Docker/pip/etc.):
venv installation (python3.7) on MacOS 10.15.6
ESP (ESP32/ESP8266, Board/Sonoff):
Tested on ESP32 Devkit v1 and Wemos D1 Mini
ESPHome version (latest production, beta, dev branch)
1.14.5
Affected component:
Found the issue while implementing a Custom Component
Description of problem: As I mentioned earlier, I was tinkering with creating a Custom Component to control my boiler which uses OpenTherm for communications. I have an adapter board built and confirmed it is working with simple Arduino sketches both on Wemos D1 and Arduino UNO. For the OpenTherm library I opted for this one https://github.com/ihormelnyk/opentherm_library Due to the nature of OpenTherm protocol, each communication session with the boiler takes considerable amount of time and after raising logging to
VERY_VERBOSE
I can see a number of lines like this:This would not bother me at all, but the problem is that under these circumstances Home Assistant Integration broke. I can discover new ESPHome device using mDNS or add it using hostname/ip address, but after the password entry device is added without any entities: no sensors, in this case. Home Assistant log shows lines like this:
Removing all OpenTherm communication from the node got rid of this problem. Since I had some spare time I decided to check if I could reproduce the same behaviour without OpenTherm, so I started with a simple update() function with delay(1000) and gradually lowered to 937-954ms -- by this time I got bored of bisecting the value and compiling the firmware :) It is worth mentioning that MQTT on this node continues to work as intended and Home Assistant can discover node's entities via MQTT discovery topic, so for a while I resorted to MQTT as a workaround, but still having API working would be great.
Problem-relevant YAML-configuration entries:
Logs (if applicable):
At the same time, Home Assistant log with
aioesphomeapi.connection
turned to debug looks like this:Additional information and things you've tried: The minimal custom component to reproduce this issue looks like this (I deliberately removed all real functionality because a simple delay() is enough to reproduce)