OTGW firmware 5.0

This Forum is about the Opentherm gateway (OTG) from Schelte

Moderator: hvxl

Re: OTGW firmware 5.0

Postby WimN » Fri Feb 19, 2021 1:21 pm

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
Starting Member
Starting Member
 
Posts: 28
Joined: April 2019

Re: OTGW firmware 5.0

Postby WimN » Fri Feb 19, 2021 5:26 pm

Thanks for the clarification.
WimN
Starting Member
Starting Member
 
Posts: 28
Joined: April 2019

Re: OTGW firmware 5.0

Postby hvxl » Fri Feb 19, 2021 5:39 pm

WimN wrote: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.

WimN wrote: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.

WimN wrote: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.

WimN wrote:Thanks for the updated 5.1 version!

You're welcome. I'm glad you like it.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1501
Joined: June 2010

Re: OTGW firmware 5.0

Postby TheSpanishInq » Wed Feb 24, 2021 10:22 pm

hvxl wrote: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
2021-02-24 20_50_07-Domoticz - DWH Temperature.png (95.04 KiB) Viewed 1173 times


FW upgrade ran smoothly, no problems.
TheSpanishInq
Starting Member
Starting Member
 
Posts: 6
Joined: January 2021

Re: OTGW firmware 5.0

Postby jacomina » Wed Apr 14, 2021 3:47 pm

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.
jacomina
Starting Member
Starting Member
 
Posts: 5
Joined: April 2021

Re: OTGW firmware 5.0

Postby hvxl » Fri Apr 16, 2021 11:24 am

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.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1501
Joined: June 2010

Re: OTGW firmware 5.0

Postby jacomina » Fri Apr 16, 2021 4:03 pm

How do I execute that test?
jacomina
Starting Member
Starting Member
 
Posts: 5
Joined: April 2021

Re: OTGW firmware 5.0

Postby jacomina » Fri Apr 16, 2021 4:37 pm

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
jacomina
Starting Member
Starting Member
 
Posts: 5
Joined: April 2021

Re: OTGW firmware 5.0

Postby hvxl » Fri Apr 16, 2021 9:37 pm

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.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1501
Joined: June 2010

Re: OTGW firmware 5.0

Postby jacomina » Fri Apr 16, 2021 10:49 pm

otgw-log.zip
OTGW log
(2.95 KiB) Downloaded 34 times

Try to attach the log again.
jacomina
Starting Member
Starting Member
 
Posts: 5
Joined: April 2021

Re: OTGW firmware 5.0

Postby hvxl » Sat Apr 17, 2021 12:43 am

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.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1501
Joined: June 2010

Re: OTGW firmware 5.0

Postby jacomina » Sat Apr 17, 2021 8:42 am

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.
jacomina
Starting Member
Starting Member
 
Posts: 5
Joined: April 2021

Re: OTGW firmware 5.0

Postby jgeo » Mon Jun 07, 2021 2:42 pm

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
Starting Member
Starting Member
 
Posts: 7
Joined: June 2021

Re: OTGW firmware 5.0

Postby jgeo » Wed Jun 09, 2021 6:13 pm

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
jgeo
Starting Member
Starting Member
 
Posts: 7
Joined: June 2021

Re: OTGW firmware 5.0

Postby hvxl » Fri Jun 11, 2021 12:25 am

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.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1501
Joined: June 2010

PreviousNext

Return to Opentherm Gateway Forum

Who is online

Users browsing this forum: No registered users and 1 guest