LAN-Anbindung für BSB-Bus (Brötje, Elco Thision etc.)

[freetz]

Hi Toms38,

very sorry for the delay in response - sometimes FHEM does not notify me about new posts - so strangely I got a notification for your message today, but not the previous ones from you and Schotty.

First of all, the easy parts ...

- "Betriebsart" being shown as 65xxx: This is purely a cosmetic issue that I haven't dealt with yet because hardly anyone else than me "reads" these serial logs . It displays a two-byte value where in fact only one byte is used later on. So the second last byte is the one that counts for this telegram, and it shows "0" in the passive log and "1" in the Raumgerät log. It only would be a problem if what is displayed in the webinterface is not the same as is on the controller.

- Parameter list: Thanks for this information, that is an important aspect that I haven't heard from yet. The thing is that with PPS, all parameters are sent all the time both in a specified order as well as upon request by the controller (FYI, Schotty, that's why not querying them won't prevent them from being sent). What you could try to do is remove those heating program parameters (if you _really_ don't need them) from pps_handling.h where it starts around line 115 with
case 15:
and comment out everything until the end of case 21. Then move case 22 and 23 up to case 15 and 16 and change all checks where msg_cylce > 23 to msg_cycle > 16.
However, having said that, it really makes me wonder that the room temperature is not send for a "long" time. Each parameter to be transmitted takes around 1-2 seconds. So with 23 cycles, the room temperature should at least be sent out to the controller once per minute. What makes me wonder is that you have sections in your Raumgeräte log where you query parameters with /JQ and there is no other telegram in between them. That shouldn't be the case, the telegrams should come up like rapid fire. If possible, can you do another log with timecoding, so I can see the time difference between each telegram?

- Präsenztaste: Thanks for letting us know. There seems to be an issue here that your controller _also_ sends information about the Präsenztaste (Schotty, that's something that you also observed, right?). So what happens here is that you set the status in the webinterface, that value is stored in BSB-LAN waiting for its turn to be sent to the heater, but then the heater is faster by sending what it thinks is the current status of the Präsenztaste. BSB-LAN takes this information and overwrites what you previously wanted to set. Does your controller have a Präsenztaste as well? If yes, then it's of course a bit difficult for me to decide which one should take precedence because someone may actively want to change the status on the heater and not fire up a browser to make the change there. I could try to circumvent that by trying to immediately send this parameter to the heater (basically jumping the line of the usual order of sending parameters), maybe that will help. But there are other anomalies with that controller as well: When looking at the passive log, it seems to send the presence status twice, and not with the usual FD as first byte, but with FB and FE respectively. I'm not sure if I can integrate that easily in my code - if it makes a difference at all. I'll first try to fix the first problem.

- TWW temperature at 127.5 degrees: That's still strange to me because BSB-LAN is not sending anything like that. The only thing you may want to change is setting the two TWW temperature settings from 0 degrees to something more reasonable and see if that changes anything. And this behaviour is also noticeable with version 2.2? That would be important to check because another user with your controller said that this problem was gone with that version, but maybe he just didn't wait long enough or so...

[Schotty]

- Präsenztaste: Thanks for letting us know. There seems to be an issue here that your controller _also_ sends information about the Präsenztaste (Schotty, that's something that you also observed, right?).

Yes, there was more than just one telegram for it (if I got you right with what you meant?): one was "PPS BUS INF 15001.0" and one was just "PPS BUS 15001.0", same as with the last v2.2 log from Toms38.

Btw: Yes, the QAA50 does have the presence button.

[freetz]

What I meant with the two telegrams are these lines, those starting with FB and FE to be precise:

Code Auswählen Erweitern

PPS RTS
17 00 00 00 00 00 00 00 00
PPS ANS 15001.0 PPS-Bus - Präsenztaste: 0 - Aus
FB 4C FF FF FF FF FF 00 BE
PPS RTS
17 00 00 00 00 00 00 00 00
PPS ANS 15001.0 PPS-Bus - Präsenztaste: 1 - Ein
FE 4C FF FF FF FF FF FF BC
PPS INF 15001.0 PPS-Bus - Präsenztaste: 0 - Aus
1D 4C FF FF FF FF FF 00 9C

The PPS RTS telegrams starting with 17 always come from the heater and tells the room unit to send its information, either one that has specifically been asked for or whatever the room unit decides should be sent.
The telegrams starting with F come from the room unit, and 4C in the second byte is the telegram for the presence status. The second last byte is the presence status. It's interesting that we have two telegrams from the room unit here, one starting with FB (where presence is 0, i.e. off) and one where it starts with FE (where presence is FF, i.e. on).
The 1D telegram stands for information from the heater to the room unit - and here presence is again 0. Which is strange, because it should be 1.

Later on, we have a similar thing:

Code Auswählen Erweitern

PPS RTS
17 00 00 00 00 00 00 00 00
PPS ANS 15001.0 PPS-Bus - Präsenztaste: 1 - Ein
FB 4C FF FF FF FF FF 01 BD
PPS RTS
17 00 00 00 00 00 00 00 00
PPS ANS 15001.0 PPS-Bus - Präsenztaste: 1 - Ein
FE 4C FF FF FF FF FF FF BC
PPS INF 15001.0 PPS-Bus - Präsenztaste: 1 - Ein
1D 4C FF FF FF FF FF 01 9B
The only difference here is that the FB/FE telegrams are not sent right after each other, but the FE telegram comes after it is being told so (with the 17 telegram from the heater). After the two telegrams are sent from the room unit, the heater confirms this with the 1D telegram where presence is now on.
So I don't really know if it is always necessary to send the presence status with FB/FE (and I have just overlooked that this is an error) or if this is specific to your controller.

[Toms38]

Hi Freetz,
You don't have to apologise and I really appreciate the support you bring, you and Schotty. I would understand that you have another life! 
Enclosed is a new SerMo with timestamps. I tried several times to set Presence to 1. No success.

In the "passiv" log file I sent you previously, I changed the presence status by pushing the button on the room unit. Sometimes, it flashes 2 or 3 times and comes back to the "Aus" state, especially if the heating mode (Betriebsart) is also "Aus", of course.

To your others answers:
- Betriebsart code: clear, topic closed.
- TWW-Temperatur: yes, by sending a positive value (10°C) it works, but it seems that it has to be sent regularly

One additional question: what is the impact of the QAA50/QAA70 parameter #15046? Both control units should be compatible with WRD 0.2.
Cheers.

[freetz]

Thanks for this log, this helps quite a bit.
As for presence mode, there may be a bug in my code that has gone completely unnoticed because at least in your setting, it always sending "off"/zero, no matter what is displayed in the webinterface. But that would be really strange if no one has noticed that in recent years. Anyway, I'll check it out if I have the time.

As for TWW temperature, setting TWW to a positive value really prevents the value from going up to 127,5 degrees completely? That would be good news.

As for QAA50/70, we simply don't know. The thing is that both QAAs are sending different values in that parameter, so we provided for both of this in case that a heating system only supports one and not the other.

[Toms38]

Yes, sending a positive TWW value seems to solves the issue.

Waiting for your feedbacks/ideas, when you find some time.

[lynckmeister]

Hallo zusammen,
ich habe den B2B-Bus Adapter an meiner Brötje LUB 25 laufen und habe ein Problem bei der Interpretation von zwei Statistikwerten, ich habe dazu in der Doku und auch im Thread nichts gefunden, was meine Frage  klärt...
Es gibt die Brennerlaufzeit Stufe1 und die TWW Laufzeit. Sind diese beiden Werte unabhängig voneinander zu verstehen oder ist die TWW Laufzeit in der Brennerlaufzeit mit enthalten?
Ich beobachte, dass die Brennerlaufzeit (manchnal?) zunimmt auch auch wenn der Heizbetrieb aus ist und eigentlich nur Trinkwasser erwärmt wurde...

[freetz]

@Toms38: Bug found. Presence status and temperature knob variables were somehow switched in memory.
@Dieter68: Da von diesem Vertauschen auch der Temperaturknopf betroffen war, könnte es sein, dass sich damit auch Dein Problem erledigt hat.
@lnyckmeister: Brennerzeit ist imme die Zeit, wann der Brenner an ist, egal warum. Brennerzeit minus TWW-Laufzeit ist daher die Zeit, in der der Heizkreis erhitzt wurde.

[n300]

Guten Morgen zusammen,

ist jetzt etwas peinlich und sicher ein typischer Fall von RTFM... Aber ich finds nicht
Wie kann man eigentlich "---" Values setzen bzw. umgekehrt wenn ein solcher Wert aktuell gesetzt ist diesen mit einem gültigen Zahlenwert überschreiben?
Bevorzugt über JSON-API.

[Schotty]

Moin,
muss dir nicht peinlich sein, denn das ist ne gute Frage und im Handbuch habe ich es nirgends stehen: "---" bedeutet ja eigtl aus/deaktiviert (im Gegensatz zu 0, bspw 0% Modulation = Minimalleistung). Also eigtl müsste man das dann erst aktivieren bzw sollte es ja mit dem Setzen eines Wertes aktiviert werden..hmmm..
Um welchen Parameter geht es denn genau? Ist der vielleicht generell nur lesbar, also ein Status-Wert o.ä.?

[freetz]

Deaktivieren geht mit Setzen eines leeren Wertes, aktiv ist er immer dann, wenn der Wert nicht leer ist.

[n300]

Moin ihr beiden. Ahh das ergibt natürlich Sinn. zumindest beim Setzen auf <null>. Allerdings hab ich auch schon festgestellt, dass derzeit deaktivierte Werte keine neuen Werte akzeptieren.
zB.: 760 Raumeinfluss HK1
Der ist momentan auf "---". Will ich den per UI auf 1 setzen, kommt kein Fehler aber das Ergebnis ist wieder "---".
Über das Raumgerät kann ich das natürlich ganz normal verändern.

[Schotty]

..aaahhh ja, stimmt, da war ja was mit dem "leeren Wert", danke freetz 
Also dann so:

Code Auswählen Erweitern


/Sxyz=

zum Deaktiveren?
Aber warum funktioniert dann das Aktivieren/Setzen des o.g. Raumeinflusses mit /S760=1 für 1% nicht..? Hast du da ne Idee?
EDIT: Raumeinfluss ist 750; 760 ist Raumtemperaturbegrenzung. Um 760 zu nutzen, muss Raumeinfluss mind. 1% betragen (also keine reine AT-Führung).

@n300: Kannst du da sonst evtl mal den SerMo mitlaufen lassen? Auch beim Setzen eines Wertes per RGT? Dann brauche ich hier mein Testsetup gerade nicht aufzubauen..

[freetz]

Keine Ahnung. Problembeschreibungen wie "da kommt ein Fehler" sind keine.

[n300]

Ja eh... es kommt ja eben kein Fehler

Hier das Monitor Output beim Setzen von --- auf 1

Code Auswählen Erweitern

...
GET /S760=1 HTTP/1.1
set ProgNr 760 = 1
setting line: 760 val: 01 00 40
LAN->HEIZ SET  760 Heizkreis 1 - Raumtemperaturbegrenzung: --- °C
DC C2 00 0E 03 3D 2D 06 14 01 00 40 2B E8
HEIZ->LAN ACK  760 Heizkreis 1 - Raumtemperaturbegrenzung:
DC 80 42 0B 04 2D 3D 06 14 7D 80
LAN->HEIZ QUR  760 Heizkreis 1 - Raumtemperaturbegrenzung:
DC C2 00 0B 06 3D 2D 06 14 A5 BE
HEIZ->LAN ANS  760 Heizkreis 1 - Raumtemperaturbegrenzung: --- °C
DC 80 42 0E 07 2D 3D 06 14 01 00 40 41 8C
#760: --- °C
EM1->HEIZ INF      05000257 00 00 00 00 15 00 00 00 00 00 00 00 00 00 00 00
DC 83 00 1B 02 05 00 02 57 00 00 00 00 15 00 00 00 00 00 00 00 00 00 00 00 0A 1E
...