Opentherm Gateway 4.0 alpha/beta testers wanted

[pwhooftman]

What probably happens is that because your house is warm enough to not need the central heating to come on, also the pump hasn't been running. Inside your heater the same flame is used to heat the built-in hot water boiler and the water in the central heating system. So whenever the water in the boiler is heated, also a little bit of water in the central heating system is heated. And because the pump never runs, that water stays pretty much where it is. The temperature sensors for the boiler water temperature and return water temperature are very close to that point and will therefor show higher than expected values.

When you restart the heater, it probably also runs the pump for a short while. That brings in cooler water from the rest of the system, which makes the temperature sensor show reasonable values again.

The OTGW is unable to influence the temperature sensor readings, but thanks a lot for the accusation

Hi hvxl, thanks very much for this clear explanation! I meant no harm to the OTG, loving it!

[mike7]

hvxl,

I played a bit with otgw and have got couple of issue/questions:
- flame led doesn't turn on while monitor shows flame with checkmark, led is only producing few very short blinks (led is working if I change it's function);

- otgw doesn't inject alternative messages, does it have predefined set or should I add my own?

Code: Select all

07:46:42.002310  T9014472D  Write-Data  Day of week and time of day: Tue 07:45
07:46:42.176231  BF0140000  Unk-DataId  Day of week and time of day: Unk 00:00
07:46:42.187214  A5014472D  Write-Ack   Day of week and time of day: Tue 07:45

I have "OpenTherm Gateway 4.0b4" version installed without EEPROM save.

Thank you.

[hvxl]

You're the first one to report issues with the flame LED. I'm also using that function myself without any problems. Could you collect some logs so I can have a look if there is anything strange happening in your setup that might explain what you see?

The gateway initially has a set of 8 alternative messages (MsgID 116 through 123). But if your boiler doesn't support some of these messages, it will scratch those off the list. Given that the gateway is not sending any alternative message, it must have scratched them all. If there is some interesting information you want to get from the boiler, you can add the message IDs. But it's also not (supposed to be) a problem if there are no alternatives.

[mike7]

Thank you for quick replay

You're the first one to report issues with the flame LED. I'm also using that function myself without any problems. Could you collect some logs so I can have a look if there is anything strange happening in your setup that might explain what you see?

log for today morning attached

otgw.04.part.log.zip

(280.45 KiB) Downloaded 587 times

The gateway initially has a set of 8 alternative messages (MsgID 116 through 123). But if your boiler doesn't support some of these messages, it will scratch those off the list. Given that the gateway is not sending any alternative message, it must have scratched them all. If there is some interesting information you want to get from the boiler, you can add the message IDs. But it's also not (supposed to be) a problem if there are no alternatives.

I will try to add my msgs in the list.

PS. Boiler is Baxi LUNA 3 Comfort

[maartenp]

For now, "ignore multiple mid-bit transitions" seems to have solved the connection issues. I don't understand why connecting the OTGW USB connector causes error 01 in gateway mode? Apparently, when running in gateway mode while nothing is connected, everything works fine...

I guess I just have to accept this as "solved using workaround"?

Two more issues:
Room setpoint seems to always stay at 10 degrees (it is currently set to 19 degrees)
Room temperature always seems to indicate 20 degrees (while the thermostat shows other values)
Are those both caused by the Honeywell thermostat not sending the right values?

After reading some more throughout the forum I guess this is what some thermostats do

I do have two new, remaining issues/questions:
1. Remote temperature override does not seem to work.
The equipment matrix mentions "9 - Remote override room setpoint" as a valid data ID for the Honeywell Chronoterm Wireless Modulation. Although technically this is the case (it is accepting/sending it), the thermostat does not seem to process the Remote override setpoint as shown below:

18:41:58.163919 T10101400 Write-Data Room setpoint: 20.00
18:41:58.220380 B70101400 Unk-DataId Room setpoint: 20.00
18:41:58.265744 AD0101400 Write-Ack Room setpoint: 20.00
18:42:02.223959 T00090000 Read-Data Remote override room setpoint: 0.00
18:42:02.257739 BF0090000 Unk-DataId Remote override room setpoint: 0.00
18:42:02.289140 AC0091380 Read-Ack Remote override room setpoint: 19.50
18:42:02.318153 T00090000 Read-Data Remote override room setpoint: 0.00
18:42:02.344733 BF0090000 Unk-DataId Remote override room setpoint: 0.00
18:42:02.371282 AC0091380 Read-Ack Remote override room setpoint: 19.50
18:42:02.398969 T00090000 Read-Data Remote override room setpoint: 0.00
18:42:02.425457 BF0090000 Unk-DataId Remote override room setpoint: 0.00
18:42:02.451867 AC0091380 Read-Ack Remote override room setpoint: 19.50
18:42:56.740051 T10101400 Write-Data Room setpoint: 20.00
18:42:57.003573 B70101400 Unk-DataId Room setpoint: 20.00
18:42:57.026779 AD0101400 Write-Ack Room setpoint: 20.00
18:42:59.974428 T00090000 Read-Data Remote override room setpoint: 0.00
18:43:00.238072 BF0090000 Unk-DataId Remote override room setpoint: 0.00
18:43:00.259114 AC0090000 Read-Ack Remote override room setpoint: 0.00

Any ideas? The ability to remotely override the room setpoint was the main reason for me to implement the OTGW so any help would be greatly appreciated!


2. The Bosch HRC35 Top seems to report water pressure using a multiplication factor of 10 (13 bar water pressure seems to be very unlikely) It would be nice to have a configurable divider in the OTGW options, making "13.00" appear as "1.30".
18:42:04.981944 T00120000 Read-Data CH water pressure: 0.00
18:42:05.311211 B40120D00 Read-Ack CH water pressure: 13.00

Thanks in advance!

[hvxl]

mike7,

I see nothing unusual about that log. Would you mind capturing another log after you send a DP=06 command? Please also issue a PR=L command while you're capturing, so I can tell which LED is which. After capturing a few occurrences where the flame was on, it would be helpful if you could send a DP=A5 command and let the log run with that for a while.

[mike7]

mike7,

I see nothing unusual about that log. Would you mind capturing another log ....

Will try to capture tomorrow, when I'll be at home. But the weather is not so cool
Thank you.

[mike7]

Schelte,

I captured log, first I turned on HW and then CH also turned on flame several times.
Flame led only blinks sometime very shortly.
I'm ready to capture more if it's not enough.

Thank you.

[hvxl]

The log shows that the gateway correctly detects the flame state (A5 changing from 8 to 9 when the flame is on). However, port B3 doesn't reflect that. My current theory is that there's something messing with port B that turns the LED off, when it shouldn't.

When you say the LED flashes, Does it stay lit for about one second, or much shorter? Can you send the following serial commands and let me know the values they report (one value for each command is enough, you don't need to let it run for any amount of time): DP=A1, DP=A2, DP=A4, DP=A7, DP=AC, DP=AE, DP=AF, DP=B1, DP=B3, DP=B6, DP=B7.

What happens when you configure the Flame function on the other LEDs? Do they all show the same behavior? What if you configure all other LEDs (including E and F, even if they are not connected) to an unassigned function, like Z? Does LED A (with function F) still only flash?

Have you tried to power-cycle the gateway? It shouldn't be possible, but if another function somehow also got assigned to the same LED, that should clear it up. But please try my other suggestions first, because they may provide some useful information about which part of the code I should recheck for correct operation.

[mike7]

Schelte, thank you for your time.

Looks like it's a hardware issue, I have 2 red leds & 2 green. Both red leds don't light constantly with any function assigned. Red leds are brighter then green, does pic have current protection output?
Green leds can be configured for flame indication.
Unfortunately I don't have soldering iron in my hands and can change leds or increase resistors only in 2 weeks.
I'll post results after resoldering.

[hvxl]

The PIC output pins are limited to 25mA, at which current the LEDs should be really bright! But that would explain why the LEDs do light up briefly. LEDs are connected between the port and Vcc. So, to turn on a LED, the port pin is set to 0. If the current limitation kicks in, the port will raise its output voltage, but the LED lights up. Now, if another LED on PORTB is updated, the code reads the full 8-bit PORTB, manipulates the bit for the other LED, and writes the 8-bit result back. When reading the 8-bit port, the hardware actually looks at the input buffers even if the pins are configured as outputs. As a result, the raised voltage on the port due to the current limitation may come back as a 1. After the manipulation of the other I/O pin, that 1 is written back to the output port and switches off the LED.

But this should only happen if you used really small resistors for your LEDs, around 100 Ohm or less. If you used the same resistors for the red and green LEDs and the green LEDs work fine, you are probably close to the tipping point. One possible technique you can try that doesn't require a soldering iron is to increase the resistor value using a file:

I don't know how far you can take that, but if you expect to throw away the resistors anyway when you get your hands on a soldering iron, you can give it a shot.

[hvxl]

Firmware version 4.0b5 is available. The only change since 4.0b4 is better handling of abnormal signals on the serial line.

[hvxl]

maartenp,

It's very strange that connecting the USB connector would have an effect on whether you get multiple transitions on the opentherm line. However, ignoring multiple transitions is the default setting nowadays.

Unfortunately it is very well possible that the remote temperature setpoint override will not work on an RF thermostat. I know someone else was struggling with that too. A couple of things to look out for in general with Honeywell thermostats:

• The remote temperature setpoint override function may not work if you have enabled the TELE-function.
• Some thermostats will only use full degrees for the remote temperature setpoint override.

The gateway basically only reports the opentherm messages. I don't think it should report B4012014D when it really received 40120D00. How the hex data is translated depends on the application you use for that. That's where you should put your factor.

[mike7]

But this should only happen if you used really small resistors for your LEDs, around 100 Ohm or less. If you used the same resistors for the red and green LEDs and the green LEDs work fine, you are probably close to the tipping point. One possible technique you can try that doesn't require a soldering iron is to increase the resistor value using a file:
...
I don't know how far you can take that, but if you expect to throw away the resistors anyway when you get your hands on a soldering iron, you can give it a shot.

I've got leds with built-in resistors, according to datasheet current is up to 30mA. I'll change them or add resistors in 2 weeks when will come back to my country house.

How can I disable led function to prevent protection?

[hvxl]

How can I disable led function to prevent protection?

You can assign a letter that has no function, for example D or N. You can assign the same function letter to multiple LEDs. So it's fine to do LA=D, LB=D.