search

mvn23 / pyotgw

A library to interface with the OpenTherm Gateway through serial or network connection.
GNU General Public License v3.0
27 stars 16 forks source link

Boiler doesn't respect max relative modulation #25

Closed iamkarlson closed 3 years ago

iamkarlson commented 3 years ago

Hi, I'm trying to restrict boiler's max flame modulation with set_max_modulation to 50. However, after this call is successfully made from Home Assistant I still can see that the boiler keep turning on for a short period with 100 flame modulation. Is there any way to diagnose an issue? I'm pretty sure that this is a quirk of the boiler but my old-fashioned thermostat could handle flame settings so I'm wondering why is OTGW not setting it right.

andriej commented 3 years ago

Do you restart in between? Boiler respects max modulation for me, but I send it to OTGW every restart of HA with automation.

Also, it ignores MM for DHW, it's only for central heating.

iamkarlson commented 3 years ago

Hi @andriej no, I didn't restart in between. I read it in the doc that this parameter is reset after restart so I just set it and expected it to be used by the boiler. That's what I have with MM set to 50: image

mvn23 commented 3 years ago

To see where it goes wrong, first enable debug logging for pyotgw.protocol and then check for the snippet below in the log. Line number and queue size may differ of course.

DEBUG:pyotgw.protocol:Sending command: MM with value 50
DEBUG:pyotgw.protocol:Received line 38: MM: 50
DEBUG:pyotgw.protocol:Added line 38 to command queue. Queue size: 1
DEBUG:pyotgw.protocol:Got possible response for command MM: MM: 50

If this is present, then pyotgw is working as expected. Its involvement ends here and the rest is handled by the OpenTherm Gateway firmware.

Next, you can check for the following lines, which should appear in this order, but may be separated by some other lines. The last 2 bytes on each line may differ based on the actual values - 64 00 means 100%, 32 00 is 50% - but the rest of the bytes must be the same.

DEBUG:pyotgw.protocol:Processing: T 01 0e 64 00
DEBUG:pyotgw.protocol:Processing: R 01 0e 32 00
DEBUG:pyotgw.protocol:Processing: B 05 0e 32 00
DEBUG:pyotgw.protocol:Processing: A 05 0e 64 00

If all lines are there, then the gateway is sending the override to the boiler (R message) and the boiler is acknowledging the new value (B message). If both R and A messages are missing, then the gateway is not overwriting the value sent from the thermostat. Unfortunately, if anything goes wrong here then there is nothing we can do from pyotgw.

The pyotgw version currently in use in Home Assistant (0.6b1) is still affected by #19, so slave_max_relative_modulation will not provide reliable information.

iamkarlson commented 3 years ago

@mvn23 Thank you so much! That's exactly what I was looking for! Let me check what's going on and I'll come back if the issue is actually in the implementation.

mvn23 commented 3 years ago

Is this still relevant? Were you able to confirm whether or not this is a bug in pyotgw?

iamkarlson commented 3 years ago

Hi, yes it's relevant, but I didn't have to time to work on it! Thanks for the info, if it wouldn't help I'll open a new issue.