search

ihormelnyk / opentherm_library

Arduino/ESP8266/ESP32 OpenTherm Library for HVAC system control communication
MIT License
228 stars 95 forks source link

Protocol instability, request for help #61

Closed pvginkel closed 10 months ago

pvginkel commented 10 months ago

I've built a gateway using this library. One end is connected to a Google Nest, and another to a boiler. I'm seeing a lot of instability in the messages. Examples are: invalid thermostat and boiler messages, timeouts, duplicate boiler responses, boiler response being received after the thermostat has sent a new message (so, a response to the previous thermostat request).

My best guess is that the cause of this issue is the other stuff I'm doing on the Arduino Nano Every. It's a ZigBee device (ZHA connected to Home Assistant). I'm using SoftwareSerial to connect to the XBee radio and I'm (currently) printing a lot to Serial.

Could this be the cause of the instability I'm seeing, or does the problem likely lie elsewhere? If this is the cause of the issue, are there known ways in which I can solve this issue? I can attach a log of the messages, but honestly it's all over the place.

The code of my project is here: https://github.com/pvginkel/ZigBeeHomeAutomation/tree/master/ThermostatProxy.

UPDATE

I should have checked this before I created the ticket. I've tested the program with XBee, SoftwareSerial and ZHA disabled, and removing all Serial print messages until after I send back the response of the boiler to the thermostat. This works better. At least the boiler is now responding to commands by the thermostat.

However, I'm still seeing errors. Sporadic ones and sometimes a flurry of them. And other times I see no errors for a prolonged duration.

I still have the following questions:

pvginkel commented 10 months ago

I figured it out. I wasn't aware the Arduino Nano Every has an additional hardware UART (4 in total actually). I switched communication with the XBee device over to the hardware serial, which made the timing issues go away. The remaining errors are due to the way the library interprets valid responses. DATA_INVALID and UNKNOWN_DATA_ID are valid response message types, but the library rejects them. That's fair enough, but there's no way to distinguish between errors (parity errors and invalid responses) and these two response codes. I have a copy of the library with these changes, and the communication is flawless now :).