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

[GT2006]

@Andreas29

Sehr geil...

[Madmaxx126]

@freetz,

So, hat ein wenig gedauert, anscheinend passiert das beim atoi, bzw beim casten auf uint32_t.
Hier nur der Debug-Print:

Code Auswählen Erweitern


      if(val[0]!='\0'){
      Serial.print(F("val: "));
      Serial.print(val);
        uint32_t t=atoi(val);
      Serial.print(F("t: "));
      Serial.println(t);


Hier der Consoleoutput:

Code Auswählen Erweitern


GET /2604/S6235=44444 HTTP/1.1

/2604/S6235=44444
set ProgNr 6235 = 44444
val: 44444t: 4294946204
setting line: 6235 val: 06 FF FF AD 9C
Duration: 95
RGT1->HEIZ SET 6235 Konfiguration -  Zugangscode OEM2?: ---
DC 86 00 10 03 3D 05 17 73 06 FF FF AD 9C 55 5F
HEIZ->RGT1 ACK 6235 Konfiguration -  Zugangscode OEM2?:
DC 80 06 0B 04 05 3D 17 73 FF 24
My address: 6
Destination address: 0
Duration: 3
Duration: 74
Duration: 159
RGT1->HEIZ QUR 6235 Konfiguration -  Zugangscode OEM2?:
DC 86 00 0B 06 3D 05 17 73 5F 67
HEIZ->RGT1 ANS 6235 Konfiguration -  Zugangscode OEM2?: -21092
DC 80 06 10 07 05 3D 17 73 00 FF FF AD 9C 34 41
GET /2604/S6235=32444 HTTP/1.1

/2604/S6235=32444
set ProgNr 6235 = 32444
val: 32444t: 32444
setting line: 6235 val: 06 00 00 7E BC
Duration: 94


Sagt dir das was?
Ohne die atoi Funktion und den Datentyp genau zu kennen hätt ich das hier nicht vermutet.

-MadMaxx

[freetz]

Hm, also atoi konvertiert zwar in signed integer, aber die sind ja 32 Bit lang, also sollte der Wraparound nicht schon bei 32768 passieren. Kannst Du mal das uint32_t gegen ein normales int austauschen, bzw. noch als weitere Ausgabe ein Serial.println(atoi(val)); einfügen?

[Madmaxx126]

Ja, kann ich, ich vermute aber die atoi Funktion returned nur ein int, wie groß das auch auf der Maschine ist und das wird dann erst auf 32bit int gecastet.
Vielleicht muss da ein atol, oder so was in der Preisklasse her?

[Madmaxx126]

So, geändert auf:

Code Auswählen Erweitern


      Serial.print(F("val: "));
      Serial.print(val);
      Serial.print(F(" Atoi/val: "));
      Serial.println(atoi(val));
      Serial.print(F(" Atol/val: "));
      Serial.println(atol(val));
        int t=atoi(val);
      Serial.print(F(" t: "));
      Serial.println(t);




Ok, hier der Output:

Code Auswählen Erweitern


GET /2604/S6235=44444 HTTP/1.1

/2604/S6235=44444
set ProgNr 6235 = 44444
val: 44444 Atoi/val: -21092
Atol/val: 44444
t: -21092
setting line: 6235 val: 06 00 00 AD 9C
Duration: 94


der Cast auf int macht aus dem negativen t jetzt zufällig wieder den korrekten Wert

[freetz]

Stimmt, Du hast Recht, ein int hat auf dem Arduino nur 16 Bit, und da es signed ist, ist bei 32767 Schluss... Trotzdem ist der negative Wert ja letztlich nur eine Interpretation eines letztlich positiven Wertes, weswegen das jetzt beim Senden letztlich wieder passt. Es würde aber trotzdem bedeuten, dass bei 65535 Schluss ist, aber vemutlich werden von den vier zur Verfügung stehenden Bytes theoretisch bis zu drei gebraucht, um auch einen Code wie "99999" abbilden zu können.

Kannst Du mal statt der atoi-Zeile das hier probieren:
uint32_t = (uint32_t)strtoul(val, NULL, 10);

[Madmaxx126]

Irgendwo hast du unten t vergessen, ich habs mal nur im print ausprobiert:

Code Auswählen Erweitern


      Serial.print(F(" Atoi/val: "));
      Serial.println((uint32_t)strtoul(val, NULL, 10));
      Serial.print(F(" Atol/val: "));
      Serial.println(atol(val));
        int t=atoi(val);


Scheint aber zu funktionieren:

Code Auswählen Erweitern


GET /2604/S6235=44444.00 HTTP/1.1

/2604/S6235=44444.00
set ProgNr 6235 = 44444.00
val: 44444.00 Atoi/val: 44444
Atol/val: 44444
t: -21092
setting line: 6235 val: 06 00 00 AD 9C
Duration: 95


[Madmaxx126]

Final gehts auch:

Code Auswählen Erweitern


      Serial.print(F("val: "));
      Serial.print(val);
      uint32_t t = (uint32_t)strtoul(val, NULL, 10);
      Serial.print(F(" t: "));
      Serial.println(t);


Code Auswählen Erweitern


set ProgNr 6235 = 44444.00
val: 44444.00 t: 44444
setting line: 6235 val: 06 00 00 AD 9C


[freetz]

Prima, danke für's schnelle Testen, dann ist der Fehler ja schnell behoben ...

[freetz]

Ich habe mal noch etwas das brute-force laufen lassen,

Zeitprogramm Heizkreis 1 ist in 2D zb:

Code Auswählen Erweitern

78 1A 06 00 0C 02 00 14 07 2D 3D 0A 8C 12 0A 14 00 15 00 16 00 17 00 17 32 E9 94
500 Zeitprogramm Heizkreis 1 - Mo: 1. 18:10 - 20:00 2. 21:00 - 22:00 3. 23:00 - 23:50

Zeitprogramm Heizkreis 2 ist in 2E mit dem selben Aufbau.

Ja, das mit LPB scheint sich zu zeigen, dass manche Parameter in einer ganz anderen Gruppe, aber dann mit gleicher "Endung" landen. Anhand der letzten 4 Bytes kann man dann auch oft suchen und erahnen, worum es bei dem Parameter geht, wenn es da in einer anderen Kategorie einen Treffer gibt. Bei meiner Thision wandern, wenn ich den Adpater über das OCI420 per LPB anschließe, die Zeitprogramme von Kategorie 0x05 in 0x21, bei HK2 wäre es dann von 0x06 auf 0x22.

Ich habe Eure Brute-Force-Abfragen mal zum Anlass genommen, die brute-force.pl etwas zu erweitern, auch aus dem Grund, weil wir es platzmäßig nicht schaffen werden, alle unbekannten Befehle in die BSB_lan_defs.h einzubinden. Stattdessen erzeugt dieses Script nun fertige Definitionszeilen, die man entweder hineinkopieren oder über ein #include einbinden kann. Die Ergebnisse werden alle angehängt, so dass man, wenn man Kategorie-Byte für Kategorie-Byte durchgeht, am Ende ein entsprechend sortiertes File hat, das man dann hier veröffentlichen kann, bzw. das ich dann mit in GitHub aufnehmen kann.

Es rechnet auch gleich die entsprechenden Dezimal- und Temperaturwerte mit aus, so dass man auf einen Blick schnell sehen kann, ob sich hinter der CommandID etwas interessantes verbergen könnte.

Diejenigen, die jetzt schon die Arbeit gemacht haben, können einfach die $counter Variable entsprechend höher setzen, um gleich bei einem bestimmten Block anzufangen - man weiß ja wegen des ersten Durchgangs schon, wo die Treffer liegen werden.

Das Script erkennt auch den verwendeten Bus (BSB oder LPB) automatisch und schreibt auch gleich die Gerätebezeichnung dazu, so dass es später keine Verwirrung gibt.

Liegt jetzt auf GitHub.

[Andreas29]

Super, danke für die Rückmeldung @Andreas29. Dann lohnt sich der Aufpreis des originalen Shields wohl doch u.U...

Moin,

nach meinen persönlichen Erfahrungen kann ich für meine Betriebsumgebung von BSB-LAN sagen: Auf jeden Fall! 

@GT2006: Finde ich auch 

Noch zur Energiemengenmessung: Wie ja schon in früheren Beiträgen beschrieben waren bei mir die beiden Parameter 9626 und 9627 völlig falsch parametriert. Nach Korrektur auf die richtigen Werte läuft´s. Wie schon in den Diskussionen um die Energiemessung beleuchtet, erfolgt die Energiemengenmessung über die Umrechnung der Gebläsedrehzahl und dazu wird ganz banal und einfach eine Geradengleichung (die dann halbwegs eine Kennlinie abbildet) verwurstet.

Noch zur angepassten custom.h: Die Funktion mit den Pushnachrichten funktioniert ebenfalls zuverlässig und blitzschnell (habe diverse Tests und Ausfallszenarien durchlaufen lassen).
Die Pingerei (ich Pinge ja von BSB-LAN mein Raumgerät und auch den Max-Cube an, zwecks Verbindungsüberprüfung) bringt den "normalen" Datenverkehr zw. BSB-LAN und dem restlichen Netzwerk nicht durcheinander.

VG

Andreas

[uriel2006]

@freetz,

Das Script erkennt auch den verwendeten Bus (BSB oder LPB) automatisch und schreibt auch gleich die Gerätebezeichnung dazu, so dass es später keine Verwirrung gibt.

Die Zeilen:

Code Auswählen Erweitern

my $heater = `wget -q -O - $URL/JQ=6224 | grep "value"`;
$heater =~ /.*: "(.*)"/;
ergeben bei mir: RVA63.244/160
also versucht er eine Datei zu schreiben mit dem namen: defs-brute-force-RVA63.244/160.h
Was natürlich nicht funktionieren kann.

Code Auswählen Erweitern

my $heater = `wget -q -O - $URL/JQ=6224 | grep "value"`;
$heater =~ tr/./-/;
$heater =~ /.*: "(.*)"/;
Habe dann das "." durch "-" ersetzt.
aber den "/" bekomme ich nicht weg.
Perl ist auch nicht mein ding 

cu.

[postman]

Moin Andreas29,

(ich Pinge ja von BSB-LAN mein Raumgerät und auch den Max-Cube an, zwecks Verbindungsüberprüfung)

Das hat bei meinem Chield leider nichts ausgesagt; pingen ging immer, WEB war weg. Mittlerweile läuft allerdings mein BSB auch stabil
Ich werde es allerdings jetzt noch ein paar Monate beobachten.

Gruß Uwe

[freetz]

@uriel2006: Stimmt, ich habe die gefixte Version auf GitHub hochgeladen, allerdings sollte nur der Slash Probleme bereitet haben, ein Dateiname kann eigentlich (wenn man nicht FAT12 und kleiner verwendet) problemlos mehrere Punkte beinhalten.

[Andreas29]

Moin Andreas29,
Das hat bei meinem Chield leider nichts ausgesagt; pingen ging immer, WEB war weg. Mittlerweile läuft allerdings mein BSB auch stabil
Ich werde es allerdings jetzt noch ein paar Monate beobachten.

Gruß Uwe

Hi,

Uwe, ich pinge vom BSB-LAN auf die genannten beiden Komponenten um zu prüfen ob die beiden noch erreichbar sind, nicht um zu prüfen ob "Shieldschluckauf" vorliegt.
Vom Raumgerät frage ich regelmäßig in Richtung BSB-LAN Werte ab und wenn BSB-LAN da nicht antwortet oder erreichbar ist gibt das Raumgerät eine Fehlermeldung und eine Push-Nachricht raus.
Die Pingerei ist nur da um zusätzlich weitere Verbindungen zu prüfen und mögliche Ausfälle weiterer Komponenten zu detektieren.

Einen "Shieldschluckauf" kann ich nicht richtig simulieren insofern weiß ich derzeit noch nicht (weil nicht mehr vorgekommen) ob meine Notfallroutinen im Programm der custom.h dann auch greifen. Im Rahmen der Simulationsmöglichkeiten jedenfalls tun sie dies.

VG
Andreas