[BUG] PPS Errors with BSB-LAN Versions > 2.0.16

[malansk]

BSB-LAN Version 2.0.16 (ok but hangs after 3months uptime) 2.0.113 (PPS "Betriebsart" not switchable, PPS "Zieltemperatur" always 0°C -> Heater not running) 2.2.1 (PPS-Error Displayed on Heater Control Module) 3.x (PPS-Error Displayed on Heater Control Module)

Architecture Arduino Due w. LAN shield

Bus system PPS (Siemens RVA53.242 from year approx. 2008)

Describe the bug I have Version 2.0.16 running since 12/2020 but after approx. 3 months uptime I always need to restart the Arduino Due because BSB-LAN is no longer running (Web-Interface not reachable, WGET from Smarthome system gives no values)

Today I tried newer Versions of BSB-LAN but they are missing some PPS values or they block the PPS bus on the heater control module if PPS write is enabled.

Version 2.0.113 PPS "Betriebsart" can be changed but no change on heater control module PPS "Zieltemperatur" always shows 0°C (with Version 2.0.16 it shows 15°C or 24°C depending on Presence Switch) Heater is not running in Automatic mode (only OFF mode w. Freeze-Protection)

Version 2.2.1 & 3.x As soon as the Arduino Due is up and running, I get "Err" Message on the Heater Control Module. It shows Error 146 - PPS-Bus-Error If I change the configuration from "Raumregelgerät" to "Passive" (no writing on PPS bus) the Error dissappears and I get some PPS values but not all the PPS values I got with 2.0.16

I am uploading each version from different folder on hard-drive, with the config files renamed (from .default) and with the necessary configuration settings (e.g. Bus Type "PPS" etc.). I have even cleared the EPROM content by command line switch /NE

After Downgrading to 2.0.16, everything works ok (but after 3 months uptime needs restart).

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Logs If possible, attach or copy/paste a log of the Arduino IDE's serial monitor when performing the above actions. If the error is reproducible, do so after pressing the reset button on the board.

Expected behavior Versions 2.0.113 and 2.2.1 should give all of the PPS values from Version 2.0.16. I have read that the category numbers for PPS values are changed, this is not the problem. PPS bus should not be blocked by Version 2.2.1 or higher if PPS write on bus is enabled.

Can I use the PPS category definiton of version 2.0.16 (in BSB_LAN_defs.h) with the newer versions ? Or can I somehow disable some PPS command / change their physical address/identifiert to make them work again like in 2.0.16 ?

//-> upon further investigation of the BSB_lan_defs.h and BSB_lan files, the PPS bus commands in BSB_LAN_defs.h did not change (only their category number). //-> but the heater bus handling (send/receive date) in BSB_lan.io sketch looks very different in the new versions if I compare it to the 2.0.16 version from 2020. So maybe the new heater bus code routines are not working propperly with my controller (even though the both should emulate QAA70 device).

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (if applicable, please complete the following information):

• OS: Windows 10
• Browser Chrome
• Browser version 116.0.5845.141 (Offizieller Build) (32-Bit)

Additional context Add any other context about the problem here.

Attach your BSB_LAN_config.h file to your bug report (remove any confidential information if necessary). Bug reports without this file attached will be closed immediately. BSB_lan_config_V2.0.16.zip BSB_LAN_config_V2.0.113.zip BSB_LAN_config_V2.2.1.zip

[fredlcore]

Since I no longer have access to a PPS controller, I would need serial monitor log files from all three versions, both when running in passive mode as well as in room unit mode. The logs need to begin when booting the Arduino and need to run for 1-2 minutes and during that time you should change the problematic parameters.

[malansk]

Yes, I was trying to get serial monitor log files from the Arduino Due but was not successfull. Later I found some reference posts that one the Due it‘s not possible to get the SerialMonitor output from the same port like the programming was done, so I will try to open the case and switch over the USB cable from native port to programming port to get some logfile. Would logfile from SD-Card also work ? I saw some options to enable logging of telegrams.

[fredlcore]

No, that is wrong information. Yes, the Due has two USB ports, but for BSB-LAN, both programming as well as serial output is via the programming port. And no, logging to SD card is not enough in case of troubleshooting as the logs do not cover both sending and receiving data.

[fredlcore]

I have had reports from PPS users using the most recent BSB-LAN version on a rather old (even for PPS) RVA36 controller. So I assume your situation is a bit more specific. With the said log files, I can nevertheless have a look, but without these, there's nothing I can do. So for the moment, I'm going to close this issue until there is further background information.

[malansk]

Today I had finally time to collect some log files with Serial Monitor running on the Arduino Due Programming port.

1. "PPS Bus Errors when write on bus is enabled" where probably caused by bad EEPROM content e.g. Heating start / end-times of >24h. EEPROM was probably not cleared by /NE switch due to missing definition of #define RESET in config.h. After properly clearing EEPROM, no more PPS BUs Errors shown in the heating controller display

2. Version 2.0.16 shows real data on almost all channels and can write to all channels which have SET button in WEB-GUI (Betriebsart, Präsenztaste, Außentemperatur, Vorlauftemperatur, Mischervorlauftemperatur, Trinkwassertemperatur, TWW Reduziertsollwert, TWW Nennsollwert, Komfortsollwert, Reduziertsollwert, Frostschutzsolltwert, Sollwert Maximum, Raumtemperatur (set by BSB-LAN), Heizperioden, Uhrzeit, Zieltemperatur.

   Version 2.016 is missing data on these channel (not shure if this is bug or if the heating controller doesn't send them over PPS) Brennerstatus, Außentemperatur gemischt, Vorlaufsollwert

3. Version 2.1 is showing the most Temperature data in the Serial Monitor with 0°C and showing wrong values for Außentemperatur in the Serial Monitor. Many telegramms are missing at all (Brennerstatus, Heating Times).

4. Version 3.3.5 does not recognize any PPS telegrams at all in PPS Bus read mode, even though the raw messages look the same (et least the unrecognized ones). With write mode enabled, the same telegrams like in 2.1 are shown (also with 0°C for the temperatures and missing the Brennerstatus and Heating times).

5. Version 3.3.5 is not able to connect to MQTT server with PPS write mode enabled.

Please let me know if you need some more logs / information.

[malansk]

BSB-LAN Web_2.0.16.pdf BSB-LAN Web_2.0.16_PPS.pdf BSB-LAN Web_2.1.8.pdf BSB-LAN Web_2.1.8_PPS.pdf BSB-LAN Web_2.1.8_PPS_AfterEPROMCLEAR.pdf BSB-LAN Web_2.1.8_Sensoren.pdf SerialMonitor_2.0.16_readonly.txt SerialMonitor_2.0.16_write.txt SerialMonitor_2.1_readonly.txt SerialMonitor_2.1_write.txt SerialMonitor_2.1_write_EEPROM_Cleared.txt SerialMonitor_3.3.5_read_EEPROM_Cleared.txt SerialMonitor_3.3.5_write_EEPROM_Cleared.txt SerialMonitor_Vergleich.txt

[malansk]

I have copied some interesting differences in the SerialMonitor_Vergleich.txt. Is looks like some parts of the telegrams are missing the second half of the values (only 00) - the first half seems to be ok. The values which I am able to set via WEB-GUI (e.g. Komfortsollwert or Reduziertsollwert) seems to be complete. Maybe the PPS Bus read function truncates the second half of the telegrams ?

[malansk]

@fredlcore please have a look at this, I'm not shure if you see this update since the issue has already been closed.

[fredlcore]

Thanks for the intensive research, however, 3.3.5 is already several weeks/months old, current version is 3.4.6, and I also fixed a non-trivial bug for PPS in the meantime. So could you please check again with the most recent version and let me know if the problem persists? Thanks!

[malansk]

Where do I get it ? On Github it shows 3.3 as latest... https://github.com/fredlcore/BSB-LAN/releases

[malansk]

Found it by enabling the Update search in WEB-GUI !

[fredlcore]

From the master repository, as described in the manual...

[malansk]

Version 3.4.6 gives me PPS Bus Error on the heating system if I set PPS bus to write - even with EEPROM cleared. Depending on QAA Type, Serial Monitor gives "Collision on Bus detected".

Attached are the latest logfiles for read and write.

[malansk]

SerialMonitor_3.4.6.txt SerialMonitor_3.4.6_write_PPSBUSERROR.txt SerialMonitor_Vergleich.txt

[fredlcore]

You seem to have the "monitor" function active. Don't do that, that's basically only necessary for specific debugging purposes which is why it is turned off by default. In this case, it might cause problems because PPS is a very timing sensitive protocol. Furthermore, I don't see bus errors in your file S.erialMonitor_3.4.6_write_PPSBUSERROR.txt.

[malansk]

I have changed #define DEFAULT_FLAG from 0 (which I was using in 2.0.16) to FL_SW_CTL_RONLY and now I am getting live PPS values from the heating controller :-)

But there are some issues:

*Mischervorlauftemperatur is shown as -512°C (this was ok in 2.0.16 but changed already in Version 2.1 to -512°C) (2.0.16 PPS-Bus - Mischervorlauftemperatur: 30.6 °C00 2c 00 00 00 00 07 a5 00

15004: 30.6 °C

30.600000 30.600000) (3.4.6 PPS-Bus - Mischervorlauftemperatur: -512.0 °C 00 2C 00 00 00 00 80 01 00

15034: -512.0 °C)

QAA Type (was "15062 PPS-Bus - QAA Modell: 83 - QAA 70fd 38 ff ff ff ff ff 53 7d" in Ver 2.0.16) is now "15046.0 PPS-Bus - QAA Modell: 65363FD 38 FF FF FF FF FF 53 7D" (Modell 83 changed to 65363 or so some other number starting with 65...). Betriebsart (was "15010 PPS-Bus - Betriebsart: 0 - Automatischfd 49 ff ff ff ff ff 00 bf" in Version 2.0.16 is now "PPS ANS 15000.0 PPS-Bus - Betriebsart: 65281" or some other number starting with 65...

Please check the logs for the values of QAA Type, Betriebsartumschaltung and Mischervorlauftemperatur. By the way, "Präsenztaste" is working and I can switch it on and off.

Heating controller still shows "PPS Bus error" since Version 3.4.6 (it is not shown in the log of the serial monitor) and I can't change Betriebsart on the controller. Maybe it is blocked by wrong QA type and wrong Betriebsart from BSB-Lan ?

I have turned off the "monitor" function off now.

[malansk]

SerialMonitor_3.4.6_write_PPSBUSERROR_PPS_Values_read_ok_FL_SW_CTL_RONLY_MonitorOFF_Betriebsartumschaltungen.txt

[fredlcore]

First of all, glad to hear that it's working now. As for your observations:

1. -512 degrees is correct for a telegram that contains 80 01 in payload (as opposed to 07 A5, which would be 30.6 degrees). -512 usually means the temperature sensor is not connected or broken. So unless the "2C" data telegram does not contain anything else, it cannot display a different value.
2. For the other two parameters, I have come up with a fix, please install the most recent version and check if there's an improvement now. But just to be clear: That was just for the display in the serial monitor, right? In the webinterface, it should have displayed the value correctly? If not, then please also check the output on the webinterface.

[malansk]

There is no broken sensor, with 2.1.16 is shows the correct temp, with each version higher it shows -512°c.

The fix looks completely broken, for most telegrams, showing decoding error in GUI and other error in logfile (refer to log file)

[malansk]

SerialMonitor_3.4.6_newBuilt_Broken.txt

[fredlcore]

Well, the imortant info (also) is that the telegrams in question before are now displayed correctly. With the bugfix I've just uploaded, it should work fine. As for the sensor, I cannot change the telegrams coming from the heater. This is what your heater sends to BSB-LAN: 1D 2C FF FF FF FF 80 01 3A The first byte (1D) indicates a broadcast information telegram from the heater to the QAA. The second byte is indicating the type of parameter (2C = Mischervorlauftemperatur) and the 3rd- and 2nd-last bytes are the temperature (0x8001 divided by 64 (temperature operand) is -512). In version 2.0.16 you quoted a different telegram, so that's the reason for the different temperatures displayed. As to why your heater sends different telegrams with the different versions, I have no idea. Maybe you use a different QAA mode, but whatever it is, I have no PPS heating system to figure this out. If you figure out what causes the different telegrams and if this can be influenced by BSB-LAN, I can certainly try to adjust that, but otherwise, there is no chance for me to do so. Could it be that this specific temperature now shows up on a different parameter?

[malansk]

I have found detailed manual, it shows that the "PPS Error" I was refering to on the Heater controller is in fact Error Code "146" which is "Ungültige Anlagenkonfiguration". The Anlagenkonfiguration specifies which type of heater (1-stufig / 2-stufig / modulierend) and which type of peripherals (Pumpen, Mischer). That's why in Version newer then 2.1.16 it shows -512°C for Mischervorlauftemperatur and "Ungültige Anlagenkonfiguration" because BSB-Lan somehow changes my original "Anlagenkonfiguration" Type 15 (1-stufig, Mischerkreis) to something else if write to pps bus is enabled ! Was there an update from 2.1.16 which somehow sets heater type / family type / device type ? In the config.h I have always used this:

/* Set the device family and device variant of your heating system. Only change this if you _really_ know what you are doing!
 * Set fixed_device_family and fixed_device_variant to your device family and variant (parameters 6225 and 6226) here
 * if heating system is not running when BSB-LAN is powered on.
*/
uint16_t fixed_device_family = 0;
uint16_t fixed_device_variant = 0;
======================

Maybe this setting was not working for PPS in 2.1.16 but was updated to actually work from 2.1.xx ? Is there a way to disable this in the code for testing ?

[fredlcore]

That's a helpful hint - we have added some more telegrams which were required by some PPS heaters (there is no standard, unfortunately) where we don't know their meaning yet and just sent these parameters as we found them. So it could be that such a parameter was added in the meantime and it contains the wrong Anlagenkonfiguration in your case. You can find out which one it is if you compare the telegrams that start with FD (these are the ones coming from the QAA/BSB-LAN) between when BSB-LAN is in passive mode (i.e. the QAA sends the FD telegrams) and when BSB-LAN is in write mode. I would suspect telegrams with 55 as well as 4E in second position to be the culprits. These were added because the QAA50 sends them for whatever reason (there is hardly anything you can set with the QAA50, so it could well be the "Anlagenkonfiguration". If you compare this with the corresponding telegrams from your system when in passive mode, we could figure out the meaning. If you can read "Anlagenkonfiguration" on your heater, and it says 03 or 00 instead of 15, then it's even easier to figure out.

[fredlcore]

If you want to try some more, you can either uncomment the two tx_msg in lines 24 and 25 in include/pps_handling.h (case 3) or in lines 28 an 29, so we can figure out which causes the issue. But still, a comparison with what your QAA sends in these cases would be helpful in order to hopefully decode what the actually mean...

[malansk]

Uncommenting case 3 or case 4 doesn't make a difference. But uncommenting case 0 (QAA Type setting) solves the issue - no more "Ungültige Anlagenkonfiguration" Error and everything is working like in 2.1.16 ! The weird thing is that looking at the Serial monitor I get the same result (FD 38 FF FF FF FF FF 53 7D) if case 0 is active in 3.4.6 like I get from 2.1.16 so I doubt that the actual code from this line in pps_handling.h is the culprit. But since in case 0 "pps_values[PPS_QTP] = QAA_TYPE" is set, maybe it triggers a bug later somewhere in the code. e.g. "case 0x38: pps_values[PPS_QTP] = msg[7+pps_offset]; break; // QAA type" or "case 0x38: msg_cycle = 0; break;"

If I leave case 0 enabled and uncomment the "case 0x38: msg_cycle = 0; break;" line the heater starts and runs for approx. 5 minutes before throwing the "ungültiger Anlagentyp" error.

So it looks like there is definitly something buggy with this QQA Type / address 0x38 handling at least for my system.

[malansk]

I will let it run overnight with case 0 uncommented to see if this is truly stable,

[malansk]

SerialMonitor_3.4.6_latestBugfix_read.txt SerialMonitor_3.4.6_latestBugfix_write.txt SerialMonitor_3.4.6_latestBugfix_write_case0-uncommented.txt

[malansk]

One more thing, after restart of heating controller and BSB-LAN, I sometimes get "Verbindung Unterbrochen 1 - JA". Maybe this is related to my uncommenting of case0 ? To get rid of that, I undid my change, restartet (which gave the error "ungültiger Anlagentyp"), did my change to uncomment case0 and everything was workinG again.

[malansk]

One more thing, "15023 PPS-Bus - TWW Nennsollwert:" is not persistend. After restart it's at 0°C and I don't get warm water. After setting it manually to 55°C in WEB-GUI, the value gets transfered to the heating controller. But after next restart of BSB-LAN, it's again at 0°C. The value should be written to EEPROM after setting and read back from EEPROM after restart. If I cange this value in the heating controller, BSB-LAN will not register this change. Looks like writing this value to PPS is ok but reading from PPS fails.

Btw. "TWW Reduziersollwert" is working as expected.

"15008 PPS-Bus - Raumtemperatur" is also not persistend after restart of BSB-Lan.

[fredlcore]

Well, the reason the error is going away is that the heating system thinks that there is no QAA (i.e. BSB-LAN) connected and thus ignores any other kind of data from the QAA. That's why you also get the "connection interrupted" telegram with which the heating system informs any QAA to start sending telegram type 38 again. That's why it's case 0 because this has to be sent most often so that the heating system doesn't think the connection is interrupted. So there is nothing buggy with that, but some other kind of telegram case in the message queue causes the problem. You could try to go through it one by one, but as you said that the "Anlagentyp" is not correct, it would be helpful to let me know which value it is at now that the error occurs?

For TWW Nennsollwert, I'll have to have a look, that should already be written to EEPROM, as it has FL_EEPROM flag set in BSB_LAN_defs.h. Room temperature is not written to EEPROM for safety reasons. Imagine your home automation which delivers the room temperature to BSB-LAN is no longer updating. Then the last known room temperature (say, 21.4 degrees) would continue to be written to the heater even if it is below zero already. This would at least become obvious when BSB-LAN restarts and does not get a fresh room temperature. The other reason is that the room temperature usually changes most often and would thus lead to continuous writes to the EEPROM, reducing its lifespan. Since you have no other way to inform the heater about the room temperature anyway (because in write mode you have no QAA anymore that could do it for you), you have to make sure that there is a continuous and reliable source of room temperature.

[fredlcore]

By the way, a room temperature of 0 sent to the heater is most likely the reason for the error, because your configuration requires a valid room temperature. In the unlikely case that it's not, check telegram types 4E, 55 and 56. These are the only ones that do not have a known function yet.

[malansk]

I have set a room temperatur wie WEB-GUI but it does not change the Error of "Ungültiger Anlagentyp". I have disabled Room-Temperatur correction function in the heater controller since longe time because I don't have a good room for reference anyhow.

The controller is expecting "Anlagentyp [1...150]" but shows "0" when I have write enabled. 15 would be the correct type which is shown with write disabled.

I have uncommented all 4E / 55 / 56 telegrams without change.

In the Serial Monitor it shows "Collision on the bus, retrying". I did not find this in any of the include files or in the .io sketch - where is this "Collision" detected & what's the retry code doing ?

[malansk]

[malansk]

In pps_handlinh.h there is this line: if ((msg[0] & 0x0F) == 0x0E) { // Heater requests information from the QAA (i.e. BSB-LAN) with telegram type 0x1E

The value 0x0E does not seem to match the value in the comment 0x1E. Which one is the right one ?

In V2.1.16 log I see several times: "Unknown request: 1e 00 00 00 00 00 00 00 00" Maybe V2.1.16 is not answering the 1E requests but 3.4.6 does and this could be the problem ? How can I disable answering 1E requests ?

[fredlcore]

Please don't try to look for solutions in the code if you don't really understand what's going on, for example that 0x1E & 0x0F is actually 0x0E. The only time BSB-LAN sends a zero (matching your wrong Anlagetyp) is with telegram type 0x4E. So you might want to change line 34 to 0x0F to see if that makes a difference. Also check what is necessary for the heater to go back to normal. Do you have to turn it off and on again or is it enough to set BSB-LAN to read-only? Maybe it takes a bit of time for the uncommented/changed telegram types to take effect? Otherwise the only solution would be to disable each sent telegram one by one, starting from the bottom (case 26).

[malansk]

I did change line 34 to 0x0F but no difference. The heater goes out of error mode after 5..10s after switching from write to read. I also did try several cold-start of heater and BSB-Lan. I did uncomment each case, but the only thing that makes a difference is when I uncomment case 0 (QAA Type). This makes me think that the case 0 is the actual problem with my system.

I made this test: case 0 activ (original condition) compile sketch, upload -> heater in Error mode, "Verbindung unterbrochen 0 - Nein" case 0 uncommented tx_msg's compile sketch, upload -> heater out of Error mode, "Verbindung unterbrochen 0 - Nein" -> I can now use WEB-GUI to change heater mode, Presence, WW Temperatursollwert, ... so everything is working like in 2.1.6., only problem is that after next restart of BSB-LAN or heater controller is is shown "Verbindung unterbrochen 1 - JA" Obviously my heater needs case 0 for first time initialization apower up, (but there is somewhere an error in the data leading to error message), but after initialization it is happy to accept any command from BSB-lan (except for the 38 - QAA type which throws immediate error).

[malansk]

Could you please provide a pps_handling.h stripped down to the bare minimum needed for initialization (set QAA type to QAA50, set Betriebsmode to Manual, read one known working value from heater e.g. Außentemperatur, set one known working value to heater e.g. Warmwassersollwert) without any variables & if..then..else ... switch ... case ... logic ? Just to confirm that the low-level initialization done by QAA type announcment is working ?

I did remember that updating from 2.1.16 to 2.1 also threw an Error "ungültiger Anlagentyp" until i re-initialized the EEPROM with /NE. Maybe there is some bad data packet send somewhere to the heater which then reacts with a general failure "ungültiger Anlagentyp". Therefore the whish for a simple stripped down pps_handling.h

Do you know where the "Collision on the bus, retrying" message is generated which is shown in SerialMonitor ?

[fredlcore]

Since you choose to ignore my knowledge about the PPS protocol, why should I invest hours to strip down the pps_handling.h so that it works the way you think it should work? I told you what you can do, and that is to eliminate the problematic telegram. The only telegrams that BSB-LAN sends are the FD telegrams, and I told you how you can disable them step by step. Maybe it's a combination of several telegrams, maybe its specific values that your heater doesn't like, who knows. If you have a QAA70, you can comare the telegrams that BSB-LAN sends with the ones the QAA sends and then figure out which telegrams need to be changed.

Your heater will work without a 38 telegram for a few minutes, but none of the known heaters do longer than that. It is basically the heartbeat of the QAA, and since you yourself admitted, it's the same telegram that gets sent in 2.0.16.

To repeat it again: The problem stops when you disable case 0 because none of the other telegrams will be accepted by the heater, even though you keep sending them. And don't get confused by the fact that the values you change are visible in the webinterface. They will always do, even if you disconnect the heater. But check a few minutes after you disable case 0 whether these values can still be checked on the heater itself. As I said, after a few minutes (once "Verbindung unterbrochen 1 - JA" comes up), none of the values will be accepted anymore.

[fredlcore]

In your last log (SerialMonitor_3.4.6_latestBugfix_write.txt) there are a number of parameter values that can cause the error on the heater:

PPS ANS 15023.0 PPS-Bus - TWW Nennsollwert: 0.0 °C
FD 0B FF FF FF FF 00 00 FC
PPS ANS 15022.0 PPS-Bus - TWW Reduziertsollwert: 0.2 °C
FD 1E FF FF FF FF 00 0A DF
PPS ANS 15006.0 PPS-Bus - Frostschutzsollwert: 0.1 °C
FD 1B FF FF 00 00 00 06 E4
PPS ANS 15008.0 PPS-Bus - Raumtemperatur: 0.0 °C
FD 28 FF FF FF FF 00 00 DF

So if you want to work on a fix, fix these values first by setting them to valid parameters. The 0.2 and 0.1 values are a bit odd and may result from an issue in the EEPROM, but you can try setting them to sane values first and see what happens. Take note that in PPS mode, all parameters that can be set are sent, continuously. The Set-button only stores them in BSB-LAN's memory/EEPROM. So just because you don't set a specific parameter doesn't mean that the parameter is not sent to the heater.

[fredlcore]

I have now fixed the TWW-Reduziertsollwert issue and also added debug warnings if some of the main temperature values are not above 0.

[malansk]

Thanks, I have tried it out but was not able to get it to send values because its complaining of invalid temperatur values. I tried to set everything, but TWW Reduziertsollwert can't be set (SET Button missing).

[malansk]

[fredlcore]

Good call, removed TWW-Reduziertsollwert in the check, so for now only current room temperature as well as comfort/reduced setpoint and TWW Nennsollwert are being tested against a value of 0.

[malansk]

It's still complaining. Maybe these values are after all 0 ? How do they get populated - from EEPROM ? In the WEB-GUI the values are shown & they are persistend after restart. Will test some more after dinner.

[fredlcore]

Sorry, I made a mistake there, of course the test must check for equal to zero, not the other way round. No need to download all again, just replace the line in 245 with this one: if (pps_values[PPS_RTI] == 0 || pps_values[PPS_RTS] == 0 || pps_values[PPS_RTA] == 0 || pps_values[PPS_TWS] == 0) {

[malansk]

The check is now working, no error after start (write mode disabled) but error as soon as I enter 21 degree as room temperature.

I did now uncomment all tx_msg from case1 until case26 but I still get the error. However, now the heater controller switches from error to no error several times every few seconds. Maybe not the content is the problem but the way how the pps_handling.h is called from the main program ? Since I use the Arduino Due which is quite powerfull maybe the bus messages are transmitted to fast to too many at the same time overflowing some receiver buffer in the heater controller ?

[malansk]

pps_handling.zip SerialMonitor_3.4.6_write_case0only_PPSBUSERROR.txt

[malansk]

Or did i uncomment the tx messages in wrong way ? Maybe you would be so kind to check the zip file with my modifications.

[fredlcore]

You comment out the right lines as far as I can see quickly, but I see now that commenting out will still send the telegram, just one with a wrong checksum (which should just be ignored, not raise an error). Try this: Change this line: if (msg_cycle > 24 || (pps_values[PPS_QTP] == 0x52 && msg_cycle > 5)) { // QAA50 sends fewer parameters to this if (msg_cycle > 0 || (pps_values[PPS_QTP] == 0x52 && msg_cycle > 5)) { // QAA50 sends fewer parameters That should only send FD 38 messages after a 17 request from the heater. The result should be that the connection is not interrupted, and the error might go away. It could still result in an error because now too few messages are coming, so you can increase the > 0 to > 1, > 2 etc. This will then send the telegrams from case 0, case 1 and case 2 (uncomment them before, of course). You can then change the contents of case 1 and 2 with other cases so that other telegrams are sent and see what happens.

If you really think that the code is the problem, just do a comarison between pps_handling.h between version 2.0.16 and the current version and adjust as you like and see if it changes anything (I'd bet it doesn't).

Have you tried out using a different room unit model in the settings? Such as QAA50? That only sends 5 parameters, maybe this way it's easier to check? You still have to have valid values in the relevant parameters, though.

[malansk]

Changing the msg_cycle from 0 to 2 gets rid of the FF FF FF ... telegram as well as the "Verbindung unterbrochen 1 - ja" message due to too few messages. But the heater still goes into error mode. I have tried every possible option as QAA type but it does not change the behaviour. I have searched the sourcecode of 2.0.16 for the include files but there are none, the program structure is completely different, all the functions are directly coded in the BSB-LAN.ino sketch.