[PIC16F88] Pin2=0V instead of 4.3V after many years of no issues

[tzieg]

Dear Schelte,

I'm using OTGW since many years (2016) without issues.
Board: Opentherm Gateway Rev B, (c) 2012 - Schelte Bron
IC2: No Max232, direct serial -> USB converter in a USB-A plug
Pins 11-14 and 12-13 connected
I don't have any LEDs connected.


Still using OpenTherm Gateway 4.3 on the PIC16F88
otmonitor-6.5 on a Raspberry-3

In late summer, I had issues with General Heating got enabled despite the Thermostat Siemens QAA73 was manually set to hot water mode only, no heating.
When bypassing the OTGW-unit completely, this did not happen. With the OTGW-unit, General Heating got enabled, despite the Thermostat was still set to heating-off and ot-monitor was always configured as Monitor-only. I also saw occasional Error-03 going up; maybe ~5...10 per day. That did not happen when I started many years ago. I'll address those issues, once I could validate, the OTGW-HW works flawlessly again.

Anyway I removed the OTGW-unit before the heating period and have now time to check for the root cause there. I'm a bit afraid to get it in the loop again for now, would first like to exclude HW-issues which might damage my heating system.

I followed your Trouble Shooting page /w settings to Original & PIC16F88:

• Power supply: ok, 5V between pins 5 and 14 of IC1

• Opentherm interface: ok. Voltages and currents match, also /w the opto-coupler and X1/X2 connected back-to-back

• Serial interface also works. When power cycling the OTGW, get on the Log
  15:36:39.270635 üOpenTherm Gateway 4.3
  15:36:39.313313 Thermostat disconnected
  
  What I do not get are the repeated messages (about once a second) as described in the trouble shooting page like
  15:19:41.689448 R00000000 Read-Data Status: 00000000 00000000
  
  Note: the OTGW is still on my lab table, i.e. not connected to neither thermostat nor the boiler.

• Issuing commands via ot-monitor works, e.g. this one
  15:40:00.855969 Command: PR=B
  15:40:00.906110 PR: B=14:30 07-01-2021

• I also measured the voltages on the pins for the PIC. They are all correct except for pin2 which is 0V instead of 4.6V !!!

Any recommendations how to track down the issue?
As stated above, I'm a bit hesitating to put the OTGW into the loop w/o further validation there are no HW-issues which could damage our heating system.

• Do you need more input / details to narrow down the problem?

• Should I upgrade to the latest firmware 5.8 at this point in time?
  I did hesitate in the past as there was a potential incompatibility announced /w Version 5.0.

• could the wrong value on pin2 above indicate an OTGW HW-issue?

• Is there a possibility to reset all settings of the OTGW to default values?

• Is there anything else I should consider

Thanks in advance,
Thomas

[hvxl]

I loaded firmware 4.3 on an OTGW to make sure the trouble shooting instructions are also applicable for this old firmware. They are. However, they assume the default settings. You indicated that you had changed the OTGW to monitor mode. That setting is stored in EEPROM and will therefor survive a reset, even a power interruption.

In monitor mode the comparator inputs are directly connected to the outputs in hardware, although the comparator configuration does cause the signal to be inverted: A high level on pin 17 results in a low level on pin 2. Without a thermostat connected, the thermostat interface is pulled up to around 24V. This results in a high level on pin 17, and consequently a low level on pin 2; 0V. Also no messages are generated by the OTGW in monitor mode. So what you found is completely consistent with an OTGW configured to monitor mode. If you switch the OTGW back to gateway mode (GW=1), you should find the results described in the trouble shooting instructions.

The potential incompatibility of version 5.X only relates to the PS=1 output. It was really only ever an issue for Domoticz users. But even the Domoticz OTGW integration was changed a long time ago to handle the 5.X report layout. So there is hardly any reason for anyone to still be using 4.3.

When loading firmware, the "Transfer old EEPROM settings to the new firmware" option is on by default. After loading firmware that way, you will get a button that shows an overview of the transferred settings when clicked. If you switch the option off before loading the firmware, all settings will return to their defaults.

[tzieg]

Hi Schelte,
it took me a while until I could explore your proposal yesterday:

• I made sure, I'm using the latest otmonitor-6.5 (armhf) from your download site

• Upgrading from 4.3 to 5.8 (also latest from your download site) did work well

• By intention, I did not select " Transfer old EEPROM settings to the new firmware"

• Also the repeating messages as described in your trouble shooting page did apprear
  13:54:05.047958 PR: B=14:30 07-01-2021
  13:59:37.217602 OpenTherm Gateway 5.8
  13:59:37.243516 Thermostat disconnected
  13:59:38.180196 R00000000 Read-Data Status: 00000000 00000000
  13:59:39.172427 R00000000 Read-Data Status: 00000000 00000000
  
  all, so promising such that I did not validate the voltage on Pin2

• Inserting the otgw between boiler an thermostat did work as well.

Here are two screenshots during day-mode about status and the summary. As expected, Central heating enable is always checked, independent, if Flame status is on or off.
Capturing via mqtt and display the most important values (boiler- and return water temp, modulation level, room- and outside temp, hotwater temp and setpoints) via node-red does also work as well again.

I did some experiments with monitor and gateway mode, but did not see high level functional differences. Did choose monitor mode as I'm mainly interested in capturing / visualizing the behavior of the heating system --to minimize energy consumption.

However, last night, I realized Central heating enable at night mode is never checked. I'm not sure, if this was the case in the past *). In the status (summary for completness), Central heating enable and Central heating mode were not checked --and thus no heating. Ok, the room setpoint was a bit low, only 12°C. I'll check this night with a higher setpoint if it's the same behavior.

I've a Brötje WGB 2 boiler with a Siemens QAA73 thermostat.

Questions:

• Any ideas why Central heating gets disabled when switching to night mode?

• What is the preferred mode: Gateway or Monitor mode?

• Could it happen that too many trials lead to a instable behavior and a reset is a wise decision?

• Is a SW-reset (GW=R) equivalent to a HW-reset (don't have a pushbutton connected)?

-Thomas

PS: *) I've a ton of recorded data (since Jan 2020) for both the "otlog-????????.txt" format and the otdata.txt format.
Do you have a tool to analyze / visualize e.g. the Status? For me it's difficult to "look" at the status flags and identify, e.g. if the
central heating mode got activated even if the thermostat was set to Domestic hot water enable only like I had it in the past in summer?

[hvxl]

> As expected, Central heating enable is always checked
Central heating enable always being checked is not what I expect. This may be done for boilers that do their own low-off and pump control function. But in the equipment matrix I see for your model boiler that ID3:HB4 = 0, meaning that it allows the master to do the low-off and pump control function. In that configuration, the central heating enable bit will cause the pump to run. That is just a waste of electricity when the heating is not on. An average pump consumes around 80W of power.

> Any ideas why Central heating gets disabled when switching to night mode?
Central heating enable should be off when not requesting heating. The real question is why it is enabled all the time during the day?

> What is the preferred mode: Gateway or Monitor mode?
You can generally assume that the default is the preferred setting.

> Could it happen that too many trials lead to a instable behavior and a reset is a wise decision?
A well designed central heating system should continue to work as best as it can under all circumstances. But I have no experience with the equipment you are using, so I can't say how well they are engineered.

> Is a SW-reset (GW=R) equivalent to a HW-reset (don't have a pushbutton connected)?
A PIC16F88 doesn't have a SW reset instruction. The GW=R command pulls RB1 low. RB1 is connected to MCLR, so this action actually causes a hardware reset. The PIC16F1847 does have a SW reset instruction, making a SW-reset very slightly different from a HW-reset. However, the difference is only in a few bits that affect what is reported with the PR=Q command.

> Do you have a tool to analyze / visualize e.g. the Status?
Yes: OTmonitor. You can pass a log file as an argument to otmonitor and it will give you the same information as with a live system. I expect that you can just drag and drop a log file onto otmonitor.exe in windows explorer. But I'm not a windows user, so I don't know for sure. You probably will want to extract the interesting part from a large log file, because otmonitor will limit the graph to some reasonable amount of time (2 hours by default).

[tzieg]

>> As expected, Central heating enable is always checked
> Central heating enable always being checked is not what I expect. This may be done for boilers that do their own low-off and pump control function. But in the equipment matrix I see for your model boiler that ID3:HB4 = 0, meaning that it allows the master to do the low-off and pump control function. In that configuration, the central heating enable bit will cause the pump to run. That is just a waste of electricity when the heating is not on. An average pump consumes around 80W of power.

Ok, I understand your point with the pump always on.
The Installation Manual (found only a German version) on page-39 talks about the pump to automatically adapt to energy requirements based on a PWM-signal from the internal control unit -so not from the thermostat. So maybe that explains the always on in day-mode. What do you think?

I tried to follow your point with the equipment matrix:

• Selecting "Brötje WGB2" in the Equipment Information and then press Show Details at the bottom.

• This leads to a table from 2017-01-09 (could be actually my upload as I bought my OTGW-kit from Kiwi in Dec-2016 and did soldering / installation during the Xmas break)

• In that table, ID3 has the value 00001001/4, i.e. ID3:HB4 = 1, at least assuming bit counting starts /w zero.
  What does the /4 stand for?

• Looking up OpenTherm-Function-Matrix-v1_0.xls, tab FunctionMatrix, ID3:HB4 seems to be the correct one regarding the pump control.

I never digged that deep into the details --good to learn this.


>> Any ideas why Central heating gets disabled when switching to night mode?
> Central heating enable should be off when not requesting heating. The real question is why it is enabled all the time during the day?

Now clear, agreed!


>> What is the preferred mode: Gateway or Monitor mode?
> You can generally assume that the default is the preferred setting.

Message understood : I'll switch to the default then.


>> Could it happen that too many trials lead to a instable behavior and a reset is a wise decision?
> A well designed central heating system should continue to work as best as it can under all circumstances. But I have no experience with the equipment you are using, so I can't say how well they are engineered.

I was referring to the OTGW itself. With the lessons learned, I'm sure it's more a lack of my understanding than the OTGW HW/SW.


>> Is a SW-reset (GW=R) equivalent to a HW-reset (don't have a pushbutton connected)?
> A PIC16F88 doesn't have a SW reset instruction. The GW=R command pulls RB1 low. RB1 is connected to MCLR, so this action actually causes a hardware reset. The PIC16F1847 does have a SW reset instruction, making a SW-reset very slightly different from a HW-reset. However, the difference is only in a few bits that affect what is reported with the PR=Q command.

A really elegant solution: a SW instruction pulls the PIC's HW-reset pin low.


>> Do you have a tool to analyze / visualize e.g. the Status?
> Yes: OTmonitor. You can pass a log file as an argument to otmonitor and it will give you the same information as with a live system. I expect that you can just drag and drop a log file onto otmonitor.exe in windows explorer. But I'm not a windows user, so I don't know for sure. You probably will want to extract the interesting part from a large log file, because otmonitor will limit the graph to some reasonable amount of time (2 hours by default).

Also a very elegant solution to feed the analysis tool with the saved log-data instead of data from the live system. I also found the connect / disconnect button stops / starts the playback. Is there also a hidden possibility to just pause?

BTW: I'm also not a windows user, 1st experiments /w Linux at kernel version 0.13 . Linux @home on PC & embedded, @work partially OSX.

[hvxl]

The ID3 data has format flag8/u8. So the high byte is a set of bit flags. The low byte is an unsigned 8-bit integer. The value shown is 00001001/4, where 00001001 represents the bit flags and 4 is the value of the unsigned 8-bit integer. The flags are numbered starting at 0 for the least significant bit, so from right to left. This means that only bit 0 and bit 3 are 1. Bit 4 is 0. You can also see this clearly if you enable the "Include details of bit fields" option in otmonitor:

Code: Select all

00:08:03.611749	T00030000  Read-Data  Slave configuration: 00000000 0
00:08:03.936529	B40030904  Read-Ack   Slave configuration: 00001001 4
                   - DHW: present (1)
                   - Control type: modulating (0)
                   - Cooling: not supported (0)
                   - DHW: storage tank (1)
                   - Master pump control: allowed (0)
                   - CH2: not present (0)
                   - Remote water filling: available/unknown (0)
                   - Heat/cool mode control: heat (0)

The low byte is the slave MemberID code, with 4 being "Siemens Building Technologies HVAC".

[tzieg]

Ok, my mistake. I did interpret the LSB on the left side without reading the docs carefully. The Broetje WGB 2 docs are using LSB on the right side as well :- (. And yes, the "Include details of bit fields" check mark helps.

The question is still: why does the boiler report Master pump control: allowed (0) ?

As stated before, according to the docs, the pumps are PWM controlled by the boiler.
Is there a possibility to check at what level the pumps work? --that's maybe more a topic for the general Hvac, Heating Opentherm Forum. Let me know if you prefer to continue there.

[hvxl]

One thing doesn't rule out the other. The bit indicates Master low-off&pump control. This means that the thermostat is allowed to switch to a kind of on/off heating mode at the lowest power level, if that lowest power level is still too high for a continuous heating requirement. The thermostat can only indicate when the heating (and the pump) should be on. The boiler can still decide how fast the pump runs. But with that bit cleared, your thermostat shouldn't tell the boiler to run the heating (and pump) continuously, even when the control setpoint is too low for heating to actually start.