Problem with gateway - boilers starts heating without reason

[milux]

I bought the USB version of the opentherm gateway: [1]. Soldered it, and it looked fine. The otmonitor works fine. I did a test by turning the thermostat and I could see the values and flame status change. I also did a hot water test, and that went fine to. Nice work!

But when I unplug the USB cable from my laptop, the boiler starts heating automatically (e.g. no heat request from the thermostat). I tried to put the gateway in monitor mode (GW=0), but it makes no difference.
I have no idea what to test or how to tackel this issue. From what I understand from [2] the behaviour should not be possible.

Any ideas?

Hardware:
Central heating system: Vaillant HR Solide Plus
Thermostat: Remeha Isense

[1] http://www.opentherm-gateway.com/compon ... t-usb.html
[2] http://otgw.tclcode.com/firmware.html#failsave

[hvxl]

You didn't mention which version of the firmware you are using. If it's 3.4, you may want to try 4.0b4. It contains some fixes for these types of problems.

[milux]

Sorry,

I tried gateway.hex version 3.4 and gateway-4.0b4.hex already. Same result.

I also tried the delay symmetry test from diagnose.hex version 1.0 which gives:
Enter test number: 4
OK1A high-to-low: 10us
OK1A low-to-high: 25us
OK1B high-to-low: 4us
OK1B low-to-high: 5us

This doesn't look right to me, as the website states that de delays should be approximately the same. But I do not understand how this can be related because the boiler shows it is receiving a heating request, but the thermostat is not sending one. So, somehow I suspect that the gateway is sending this request when I unplug the USB connector.

[hvxl]

The delay symmetry is acceptable and totally unrelated to the issue you are seeing.

What probably happens is that the unplugged USB device pulls the serial line low, which is a signal to the gateway to reset itself. When that happens repeatedly, the gateway may not get to the point where it sends messages to the boiler. The boiler then interprets that as an OT/- signal to start heating.

See also this topic for some things I suggested that may help. Do you have LEDs attached? Do they flash as described there?

[milux]

I just soldered the leds onto a breadboard.

When the gateway is in normal operating mode, only the led "Transmit" is blinking twice every second. When I disconnect the USB plug, the led is not blinking anymore (e.g. all off).

When the USB device was not plugged in, I disconnected the USB gnd lead from the opentherm gateway. Then the gateway starts working correctly again.

I do not have to reset the device when it's connected again to USB. It just starts working again when I connect the USB or remove the USB gnd from the opentherm gateway. You suggested here to use some pull-ups to avoid resetting of the device. I do not know whether it is save to try here.

[hvxl]

If you don't get the blinking LEDs, this must be a different situation, which should be handled correctly by the 4.0b4 firmware. Just to be sure, when you disconnect the USB plug from your laptop is the 5V supply to the PIC still 5V, without too much of a ripple? I.e.: 5V DC, 0V AC?

[milux]

I did more experiments while keeping an eye on the leds and notice a difference between the firmware versions. This is what I noticed.

gateway.hex version 3.4:
After powerup and USB connected: good situation, transmit led blinking twice every second.
Disconnecting USB: bad situation, no leds active.
Reconnecting USB: good situation, transmit led blinking twice every second.

gateway-4.0b4.hex version 4.0b4:
After powerup and USB connected: good situation, transmit led blinking twice every second.
Disconnecting USB: bad situation, all four leds blink very fast synchronously (>10 times a second)
Reconnecting USB: not deterministic and one of two situations can occur:
- Situation 1: good situation, transmit led blinking twice every second.
- Situation 2: bad situation, all four leds start blinking synchronously every 1 second.

From my perspective firmware version 3.4 works better in the sense that by reconnecting the USB the gateway always goes back to a good state. Firmware version 4.0b4 behaves nondeterministic as described above.

Measuring the voltage of the microcontroller gives 5 volt. I cannot measure the AC with my cheap multimeter accurately. But I noticed something else worth mentioning:
I measured the RX line (IC1, pin 8 ) with my cheap multimeter while the USB is disconnected (using firmware version 4.0b4). When measuring, all four leds start blinking synchronously every 1 second (situation 2 described above). When disconnecting the multimeter, all four leds start blinking very fast synchronously again (>10 times a second). So it seems that my (probably not so high impedance) multimeter has some influence.

Thank you for your support, I really appreciate it.

[nlrb]

When the USB is disconnected, just hold a GND pin with your finger. You'll see that the flashing will stop and the OTG will start up (with you as stable ground).

[milux]

Indeed, touching the ground seems to have some effect.
The reason I like to have this issue fixed is because I intend to connect this gateway to my router. If the router resets, I do not like my opentherm gateway to instruct the boiler to start heating

Maybe the only option is to install the rs232 chip and to connect a usb-serial converter or something like that? All suggestions are welcome.

[hvxl]

A device to which the USB interface is connected resetting is a very different situation from what you have been testing. First of all ground stays connected, so you will probably not have the grounding issue causing the fast blinking LEDs. Also, the USB interface will stay powered, or will only be unpowered for a short amount of time. The boiler should not start heating unless it doesn't see a valid message for some time between 5 and 15 seconds.

Can you connect the gateway to your router and then reset it to verify that will actually cause problems? There's not much use in spending a lot of effort trying to fix a problem that doesn't really exist.

Having said that, I will try to come up with a way to stop the gateway from resetting every second because of a continuous BREAK condition. Unfortunately there's not much I can do about the grounding issue in firmware.

[milux]

Thanks for the suggestion. I tried to get the gateway in an incorrect state without touching the USB cable plugged into the router.
The fast blinking leds only happen when I remove the power from the router. Currently, I can't find another way.

Nevertheless, I'm not happy with the situation. Not because there is a high chance of this happening, but because the impact is high. When I'm not home a couple of days and the fuse of the router blows, the boiler doesn't stop heating anymore. Maybe there is another situation when this can happen (i.e. short power disruption). Who knows.

I'm happy to try a hardware patch if you have suggestions. Otherwise, I think I'm going to order a rs232 chip to see if that makes any difference.

Sorry for my maybe too carefull approach.

Thinking about it: I remember a broken adapter a year ago, from that same router. No idea whether that would have triggered the situation.

[hvxl]

No need to be sorry. I can totally understand your trepidation. I wouldn't want to risk it either.

As I indicated, the fast flashing is not something that can happen when the PIC is able to normally run its program. So there must be a hardware issue. I suspect that the ground would still be OK if the router fuse blows or the power adapter dies, but obviously I cannot give guarantees about that. One thing you could try is to put a ceramic decoupling capacitor across the power pins of the PIC (on the bottom side of the circuit board) to see if that helps. The capacitor should be something between 0.1uF and 1uF, I've been told.

If the fast flashing has been fixed, everything else can be dealt with in firmware.

[milux]

Just a quick update. I tried placing a cap between the power pins, but no difference. I also connected the ground and power pins directly to the regulator to be sure the issue wasn't caused by an unstable ground due to possible high ground currents, but this seems to have no influence either.

Unfortunately I don't have a scope to do some measurements.

I receive the rs232 chip in a couple of days. I will install that with a USB to serial (rs232) conferter. Hopefully this changed setup will make it more stable. We will see. If I can get my hands on a good scope, I will try to do some measurements first.

[hvxl]

I just discovered that the framing error functionality of the PIC's AUSART works a bit differently from what I understood before. Based on this new knowledge I came up with a possible way to get the fast flashing while the PIC runs normally. The idea was that this could happen when the serial input picks up a 50Hz signal. So as a test I hooked up an old doorbell transformer to the serial line (~10V AC, a MAX232 can handle +/- 30V -- don't hook it up directly to the PIC pin!), and sure enough the LEDs started flashing as described.

I still believe it should be possible to solve this with a resistor if it's noise that's being picked up by a floating input rather than an actual hard 50Hz signal as in my test. But at least I now understand what's going on and I have a way to test it, so I should hopefully be able to come up with a firmware solution soon.

[hvxl]

I have just published firmware version 4.0b5. It would be nice if you give a once over with your original setup to see if the latest changes fix the problem you had.