OTGW firmware 5.0

[WimN]

Just flashed the 5.1 firmware without any problems. The LEDs now work again and return water temperature is being reported. Also updated the otmonitor on my RPi to version 5.1.
When I use that software it shows that 'Flame status' is ON, 'CH mode' is ON and 'CH enable' is ON and 'DHW mode / enable' are OFF. Just checked on the boiler itself but it is not burning.
So this seems not to be wright. OpenTherm version slave is reported as '3.00'. The status field reports: 00000001 00001010

Another strange thing is that when I go to 'Options' -> 'I/O pins' the GPIO for port A and B report 'none', the 'LEDs' are reported correctly. But the returnwater temperature is being reported so it seems to work.
When I set GPIO_A to Vcc and GPIO B to Temp sensor and press Done all seems to be ok. When I then open the I/O Pins configuration again the values are correctly shown. This also was the case wuth the 5.0 version.
Thanks for the updated 5.1 version!

[WimN]

Thanks for the clarification.

[hvxl]

Just flashed the 5.1 firmware without any problems. The LEDs now work again and return water temperature is being reported. Also updated the otmonitor on my RPi to version 5.1.

That's the wrong way around. You should update OTmonitor before upgrading the firmware. The old OTmonitor doesn't know about the newer firmware, so it doesn't know how to transfer the EEPROM settings. As a result, you will get the default settings.

When I use that software it shows that 'Flame status' is ON, 'CH mode' is ON and 'CH enable' is ON and 'DHW mode / enable' are OFF. Just checked on the boiler itself but it is not burning.
So this seems not to be wright. OpenTherm version slave is reported as '3.00'. The status field reports: 00000001 00001010

If you check the Opentherm specification, you will see that the indicated status matches the bits in the status field. If the boiler is lying in its opentherm reports, there's not much the OTGW can do about it. Of course there may be some delay for the status field to be updated. So there could be a mismatch if the boiler just stopped.

Another strange thing is that when I go to 'Options' -> 'I/O pins' the GPIO for port A and B report 'none', the 'LEDs' are reported correctly. But the returnwater temperature is being reported so it seems to work.
When I set GPIO_A to Vcc and GPIO B to Temp sensor and press Done all seems to be ok. When I then open the I/O Pins configuration again the values are correctly shown. This also was the case wuth the 5.0 version.

As indicated above, this is probably due to upgrading the firmware with an old version of OTmonitor. I suspect the return water temperature that is being reported is an old measurement that somehow survived across the upgrade.

Thanks for the updated 5.1 version!

You're welcome. I'm glad you like it.

[TheSpanishInq]

A number of problems with firmware 5.0 have been reported. These have been fixed in 5.1, now available on the web site.

Thank you for that!
I can confirm the values in the PS=1 report for the 'DWH Temperature', MsgID=26, now show the same values as in otmonitor.

2021-02-24 20_50_07-Domoticz - DWH Temperature.png (95.04 KiB) Viewed 8054 times

FW upgrade ran smoothly, no problems.

[jacomina]

Well..
I have 5.1 running and now I tried to get a sensor for return water temp working.
I connected the sensor on GPIO and set the pins. The sensor is working but:
If I set TS=R nothing is displayed; also ID28=0
If I set TS=O then the sensor temp is displayed in outside temp.
So return water temp always remains empty.
Can I only use that sensor as the outside temp? Is return water temp no longer supported?

I want to use the OT command to send outside temp from OWM, not a sensor.

[hvxl]

That is supposed to work. This exact situation is covered by the sensor-6 test. Here is the log for a run of that test:

Code: Select all

10:44:37.793000	OpenTherm Gateway 5.1
10:44:38.132000	T80000200	Read-Data 	Status: 00000010 00000000
10:44:38.189000	B4000020C	Read-Ack  	Status: 00000010 00001100
10:44:38.480000	T10010A00	Write-Data	Control setpoint: 10.00
10:44:38.535000	BD0010A00	Write-Ack 	Control setpoint: 10.00
10:44:38.631000	UI: 28
10:44:38.669000	TS: R
10:44:38.710000	GB: 7
10:44:38.750000	OT: 7.60
10:44:38.829000	T100E0000	Write-Data	Maximum relative modulation level: 0.00
10:44:38.879000	B500E6400	Write-Ack 	Maximum relative modulation level: 100.00
10:44:39.159000	T00120000	Read-Data 	CH water pressure: 0.00
10:44:39.203000	BC012021A	Read-Ack  	CH water pressure: 2.10
10:44:39.494000	T80190000	Read-Data 	Boiler water temperature: 0.00
10:44:39.537000	BC0192B80	Read-Ack  	Boiler water temperature: 43.50
10:44:39.822000	T001B0000	Read-Data 	Outside temperature: 0.00
10:44:39.863000	BF01B0000	Unk-DataId	Outside temperature: 0.00
10:44:39.869000	A401B079A	Read-Ack  	Outside temperature: 7.60
10:44:40.145000	T801C0000	Read-Data 	Return water temperature: 0.00
10:44:40.150000	R00060000	Read-Data 	Remote parameter flags: 00000000 00000000
10:44:40.189000	BC0060303	Read-Ack  	Remote parameter flags: 00000011 00000011
10:44:40.194000	AC01C1C30	Read-Ack  	Return water temperature: 28.19
10:44:40.471000	T80000200	Read-Data 	Status: 00000010 00000000
10:44:40.513000	B4000020C	Read-Ack  	Status: 00000010 00001100

So it works as expected, as you can see.

If you see different behavior, please provide a log.

[jacomina]

How do I execute that test?

[jacomina]

In OTmonitor I send these commands:
PR=A
PR=D
PR=G
TS=R
The result in in the attached log file.

As you can see there is no Return water temperature

[hvxl]

Sorry, I did not mean for you to run the test scenario. So let me restate: If you see different behavior in reality, please provide a log.
It looks like you tried to provide such a log, but the attachment is missing.

If you're curious about the test suite anyway: Instructions for running it are in the readme.txt file in the source package.
Note: The test suite can only be executed on linux.

[jacomina]

otgw-log.zip

OTGW log

(2.95 KiB) Downloaded 470 times

Try to attach the log again.

[hvxl]

Your thermostat never requests the return water temperature. So, while the OTGW does the measurements, the thermostat shows no interest in the results. In such a case there's not much use in having a return water temperature sensor. The most you can do is issue a PS=1 command every now and then. That will report the measured return water temperature as the 17th parameter.

[jacomina]

Ah, thanks that's a clear explanation.
Then I will use the outside temp (TS=O) for a while, just to show the return water temp in the graph.
After I succeed in keeping the return water temp low, I will use OT to sens to outside temp again.

[jgeo]

I don't know if it's firmware related, but I noticed that when 'Heater' is set to 'Economy mode' (in Opentherm Monitor), a Read-Data Status (MsgID=0) is duplicated, once with "DHW enable: enabled (1)" and one immediately after with "DHW enable: disabled (0)". In 'Comfort mode', only the "DHW enable: enabled (1)" is send. Since the commands are so close together, it seems the boiler (Remeha Calenta Ace) cannot process them in this order, and operates last in-first out. So the DHW enabled command is queued, since next command arrives before processing, and then DHW disabled is processed, but immediately overwritten by the DHW enabled that is still on the process stack. This seems to be confirmed by the acknowledgement response, which responds first to the 2nd command, and then to the 1st.
Shouldn't the PIC firmware, if HW=1 or HW=0 is set, just modify the MsgID=0 message from the thermostat, and then parse it? It looks now like the original message is parsed, and then it sends it again, but then modified. So duplicate, but slightly different messages are send to the boiler, giving rise to erroneous operation?

Code: Select all

01:13:52.851183	Command: HW=0
01:13:52.938225	HW: 0
01:13:56.294053	T80000200	Read-Data 	Status (MsgID=0): 00000010 00000000
		   - CH enable: disabled (0)
		   - DHW enable: enabled (1)
		   - Cooling enable: disabled (0)
		   - OTC active: not active (0)
		   - CH2 enable: disabled (0)
		   - Summer/winter mode: winter (0)
		   - DHW blocking: unblocked (0)
01:13:56.400088	R00000000	Read-Data 	Status (MsgID=0): 00000000 00000000
		   - CH enable: disabled (0)
		   - DHW enable: disabled (0)
		   - Cooling enable: disabled (0)
		   - OTC active: not active (0)
		   - CH2 enable: disabled (0)
		   - Summer/winter mode: winter (0)
		   - DHW blocking: unblocked (0)
01:13:56.510335	BC0000000	Read-Ack  	Status (MsgID=0): 00000000 00000000
		   - Fault indication: no fault (0)
		   - CH mode: not active (0)
		   - DHW mode: not active (0)
		   - Flame status: flame off (0)
		   - Cooling status: not active (0)
		   - CH2 mode: not active (0)
		   - Diagnostic indication: no diagnostics (0)
		   - Electricity production: not active (0)
01:13:56.623566	A40000200	Read-Ack  	Status (MsgID=0): 00000010 00000000
		   - Fault indication: no fault (0)
		   - CH mode: not active (0)
		   - DHW mode: not active (0)
		   - Flame status: flame off (0)
		   - Cooling status: not active (0)
		   - CH2 mode: not active (0)
		   - Diagnostic indication: no diagnostics (0)
		   - Electricity production: not active (0)

[jgeo]

It seems like mainly an issue of the MQTT interface of OTGW.
Now I use another Home Assistant integraton (Opentherm_gw) that doesn't use MQTT but the web API, and now, after setting the Remeha DP200 parameter to 0 for making it externally controllable, I can get the behaviour I want.
The Evohome thermostat keeps sending the comfort mode bit, but the OTGW clear that indeed, when the OTGW is set to Eco mode.
However, the MQTT topic report both: the comfort setting by the thermostat, and the eco setting by the OTGW: it flips every few seconds. Furthermore, the MQTT inerface does not allow for setting the mode of the OTGW, at least not in the interface it advertises to Home Assistant. So I think there are two things to do:
1) implement a MQTT interface to set eco/comfort mode, and
2) prevent an MQTT message of a status when that is overruled by the OTGW anyway

[hvxl]

Both points you mention are already implemented in OTmonitor. I checked them again today and in my tests they work as intended.
1) Use the topic actions/otmonitor/hotwater[*] with a value of 0, 1, or A.
2) OTmonitor delays the signalling of changes by 50 ms. This includes MQTT reports. If the data is overridden during that time, only the final version is reported.

If it doesn't work for you, please provide a message log from OTmonitor and an MQTT log with time stamps. On linux you can obtain the latter using the following command[*]:

• mosquitto_sub -h mqttserver -v -t events/central_heating/otmonitor/# | ts %.T

mosquitto_sub is included in the mosquitto-clients package, ts in moreutils.

[*] Adjust as necessary if the topics have been modified from their defaults.