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

[freetz]

@babajun: Die RegEx läuft auf Aussentemperatur, der Text lautet seit einiger Zeit aber Außentemperatur. Besser nicht auf Texte, sondern auf Parameter-Nummern matchen.

@loetmeister: Danke für die Rückmeldung, was ich mit "Signalisierung" meinte, war missverständlich, natürlich sagt meinem Hauptprogramm niemand, ob Daten da sind oder nicht, und ich muss immer mit available() pollen; was ich meinte, ist, dass ein eingehendes Bit in der SoftwareSerial Library einen Interrupt auslöst und dann das Hauptprogramm so lange anhält, bis das Byte vollständig gelesen ist (Funktion recv() ), so dass available() sofort danach anschlägt. Bei HardwareSerial würde das Hauptprogramm weiter laufen, bis der UART alle Bits empfangen hat (gut 2 ms), und erst dann würde available() anschlagen. Der Unterschied ist also beim Abfragen mehrerer Bytes, dass bei HardwareSerial das Hauptprogramm ca. 2 ms weiter läuft, wohingegen es bei SoftwareSerial bei einem while available() Loop sofort wieder anspringt. So jedenfalls mein Verständnis, das ist hier noch mal zur Diskussion stellen wollte, sorry für die missverständliche Darstellung oben.

Einen RX-Empfangspuffer haben übrigens beide Varianten, HardwareSerial aber auch noch einen TX-Puffer..

[babajun]

Danke für den Tip aber der Wert am Adapter is

Code Auswählen Erweitern


8700 Diagnose Verbraucher - Aussentemperatur: 1.3 °C
Brenner Laufzeit Stufe 1: 104943
Brenner Takte Stufe 1: 566
Brenner Laufzeit Stufe 2: 0

Und regex ist doch auf Nummern aufgebaut?

Code Auswählen Erweitern


reading0Regex
8700 .*:[ \t]+([-]?[\d\.]+)

[freetz]

Sorry, dann kann ich mir das auch nicht erklären. Wenn der Wert in BSB-LAN korrekt angezeigt wird und die Zeile korrekt gematcht wird, müsste es klappen.

[frank]

bei httpmod hat sich in letzter zeit viel getan bei regex.
versuch mal ein update.

[babajun]

@Frank: Vermute ich auch - Problem habe ich offenbar seit dem Update so welches ich kürzlich durchgeführt habe.

Code Auswählen Erweitern

ModuleVersion 3.5.19 - 29.11.2019
NAME Heizung
NOTIFYDEV global
NR 177
NTFY_ORDER 50-Heizung
STATE ???
TRIGGERTIME 1575717423.02375
TRIGGERTIME_FMT 2019-12-07 12:17:03
TYPE in HTTPMOD

[loetmeister]

@loetmeister: Danke für die Rückmeldung, was ich mit "Signalisierung" meinte, war missverständlich, natürlich sagt meinem Hauptprogramm niemand, ob Daten da sind oder nicht, und ich muss immer mit available() pollen; was ich meinte, ist, dass ein eingehendes Bit in der SoftwareSerial Library einen Interrupt auslöst und dann das Hauptprogramm so lange anhält, bis das Byte vollständig gelesen ist (Funktion recv() ), so dass available() sofort danach anschlägt. Bei HardwareSerial würde das Hauptprogramm weiter laufen, bis der UART alle Bits empfangen hat (gut 2 ms), und erst dann würde available() anschlagen. Der Unterschied ist also beim Abfragen mehrerer Bytes, dass bei HardwareSerial das Hauptprogramm ca. 2 ms weiter läuft, wohingegen es bei SoftwareSerial bei einem while available() Loop sofort wieder anspringt. So jedenfalls mein Verständnis, das ist hier noch mal zur Diskussion stellen wollte, sorry für die missverständliche Darstellung oben.

Einen RX-Empfangspuffer haben übrigens beide Varianten, HardwareSerial aber auch noch einen TX-Puffer..

Ok... nun verstehe ich deinen Punkt. Die Hauptunterschiede, (in meinen Worten)... Bei SoftwareSerial pausiert das Hauptprogramm solange ein byte bitweise vom RX pin ausgelesen gelesen wird. Weitere Interrupts sind in der Zeit deaktiviert.
Habe BSBSoftwareSerial und HBWSoftwareSerial mal verglichen... wir arbeiten mit fast der selben Version
HBWSoftwareSerial.cpp (https://github.com/loetmeister/HBWired/blob/master/libraries/src/HBWSoftwareSerial.cpp)

HardwareSerial available() ist wahr, wenn mindestens ein komplettes byte im Puffer verfügbar ist. Wären des Empfangs läuft das Programm weiter.


Es gibt für den ATmega2560 ein USART1 Rx Complete Interrupt:
Receive Complete Interrupt Enable (RXCIEn) in UCSRnB
Habe nicht so genau nachgelesen, aber möglicherweise klappt das nicht mit allen Framelängen, da USART selbständig Start und Stop erkennen muss?


Gruß,
Thomas

[loetmeister]

Hallo,

habe grade mal die aktuelle BSB-LAN Version geladen um zu schauen ob Hardware Serial bei mir läuft.
Seltsamerweise ist der TX pin bei HW-Serial: BSB bus(19,18); stumm... und auch die Ausgabe auf dem Arduino Serial Monitor ist etwas anders - es fehlen die Telegramme... 
Die beiden log Ausgaben unten sind direkt nach dem Start, mit einer /Q abfrage per Browser. Am Bus ist in beiden Fällen nichts anschlossen.

SW-Serial: BSB bus(68,69);

Code Auswählen Erweitern

21:09:41.131 -> 昆⸮ address: 66
21:09:41.131 -> Destination address: 0
21:09:41.131 -> READY
21:09:41.131 -> Size of cmdtbl1: 17612
21:09:41.131 -> Size of cmdtbl2: 31807
21:09:41.131 -> free RAM:5274
21:09:41.878 -> 192.168.11.66
21:09:41.878 -> Waiting 3 seconds to give Ethernet shield time to get ready...
21:09:47.928 -> DC C2 00 0B 06 3D 05 00 0B C3 A1
21:09:51.020 -> DC C2 00 0B 06 3D 05 00 02 52 88
21:09:51.020 -> query failed
21:09:54.078 -> DC C2 00 0B 06 3D 05 00 02 52 88
21:09:54.078 -> query failed
21:09:57.172 -> DC C2 00 0B 06 3D 05 00 02 52 88
21:09:57.172 -> query failed
21:10:00.264 -> DC C2 00 0B 06 3D 05 00 03 42 A9
21:10:00.264 -> query failed
21:10:03.324 -> DC C2 00 0B 06 3D 05 00 03 42 A9
21:10:03.324 -> query failed
21:10:06.417 -> DC C2 00 0B 06 3D 05 00 03 42 A9
21:10:06.451 -> query failed
21:10:06.451 -> Device family: 0
21:10:06.451 -> Device variant: 0
21:10:13.450 -> GET /Q HTTP/1.1

21:10:13.450 -> /Q
21:10:13.726 -> My address: 66
21:10:13.726 -> Destination address: 127
21:10:23.803 -> My address: 66
21:10:23.803 -> Destination address: 0


HW-Serial: BSB bus(19,18);

Code Auswählen Erweitern

21:15:03.893 -> 昆⸮ address: 66
21:15:03.893 -> Destination address: 0
21:15:03.893 -> READY
21:15:03.893 -> Size of cmdtbl1: 17612
21:15:03.893 -> Size of cmdtbl2: 31807
21:15:03.893 -> free RAM:5325
21:15:04.606 -> 192.168.11.66
21:15:04.606 -> Waiting 3 seconds to give Ethernet shield time to get ready...
21:15:09.635 -> query failed
21:15:10.621 -> query failed
21:15:11.606 -> query failed
21:15:12.626 -> query failed
21:15:13.611 -> query failed
21:15:14.631 -> query failed
21:15:14.631 -> Device family: 0
21:15:14.631 -> Device variant: 0
21:15:33.148 -> GET /Q HTTP/1.1

21:15:33.148 -> /Q
21:15:33.420 -> My address: 66
21:15:33.420 -> Destination address: 127
21:15:34.436 -> My address: 66
21:15:34.436 -> Destination address: 0


Gruß,
Thomas

[freetz]

Danke für die Rückmeldung, dann deckt sich das mit meinem Verständnis von Software- vs. HardwareSerial. Eine Benachrichtigung via Interrupt brauche ich eigentlich nicht, weil der RX-Buffer bisher immer groß genug war, dass nix verloren ging (und wenn, dann waren das eh' nur Broadcast Nachrichten, denn auf die Antworten auf Anfragen/Set-Befehle wartet BSB-LAN ja explizit).

Was mich aber wundert, ist dass bei Dir weder Software- noch HardwareSerial richtig läuft. Du hast die Platine selber gebastelt, oder hast Du eine von mir? Auf den ersten Blick in die Glaskugel würde ich vermuten, dass Lötbrücke SJ1 nicht geschlossen ist, kann das sein?
Aber auch so müsste der Serial1 TX- und RX-Pin auf 5V im Ruhezustand liegen. Wenn nicht, dann hat vielleicht was mit der Initialisierung nicht geklappt? Poste doch bitte mal Deine _config.h. Bei der Bus-Angabe ist es wichtig, dass die Reihenfolge "19, 18" ist, wobei bei meinem Mega die Beschriftung bei den beiden Pins falsch ist (da geht es von Serial3 herunter TX3, RX3, TX2, RX2, aber dann RX1, TX1), obwohl die Pins TX1, RX1 beschaltet sind.

[loetmeister]

Hi,

Arduino Pins habe ich grade noch mal geprüft, Beschriftung stimmt.
Ich beziehe mich ausschließlich auf die Ausgabe im Arduino Serial Monitor. Im Code konnte ich nicht erkennen warum die Telegramme (z.B. DC C2 00 0B 06 3D 05 00 03 42 A9) im SoftwareSerial Modus sichtbar sind, nicht aber bei Verwendung HardwareSerial. Wenn "query failed" ausgegeben wird, dann auch printTelegram()? ("verbose" war immer = 1)

Ich schaue mit einem Oszilloskop auf die TX Pins. Bei "BSB bus(68,69)" sehe ich Daten, mit "BSB bus(19,18)" nichts...

Gruß,
Thomas

[freetz]

Hm, das klingt alles seltsam, Du hast auch wirklich die alleraktuellste Version vom Master Repository (nicht die Release-Version)? Unabhängig von der Hardwareanbindung muss auf TX1 zumindest kurz nach dem Starten des Arduino was zu sehen sein, wenn bus(19, 18) aktiv ist. Hast Du sonst mal geschaut, ob bei bus(19, 18) statt auf Serial1 TX1 was auf Pin 69 (also dem SoftwareSerial Pin) zu sehen ist? Nicht, dass da bei der Erkennung was schief gegangen ist.

Aber wie gesagt, sowohl bei mir und Ulf hat es ohne Probleme geklappt...

[loetmeister]

Hm, das klingt alles seltsam, Du hast auch wirklich die alleraktuellste Version vom Master Repository (nicht die Release-Version)? Unabhängig von der Hardwareanbindung muss auf TX1 zumindest kurz nach dem Starten des Arduino was zu sehen sein, wenn bus(19, 18) aktiv ist. Hast Du sonst mal geschaut, ob bei bus(19, 18) statt auf Serial1 TX1 was auf Pin 69 (also dem SoftwareSerial Pin) zu sehen ist? Nicht, dass da bei der Erkennung was schief gegangen ist.

Hi freetz,

Version war aktuell. Habe das Problem gefunden... es muss eine Spannung am Bus anliegen, da sonst nie ein freier Bus erkannt wird und man in den 1 Sekunde timeout läuft. "(HwSerial == true && digitalRead(RX_PIN) == 0)"
War mir nicht bewusst... 
Habe 5V über einen 440 Ohm Widerstand an den Busadapter geklemmt, dann ging es. (Signal an TX1, die LED geht kurz aus beim senden und Telegramme sind im Seriellen Monitor sichtbar)

Hab noch ne frage zu den letzten Änderungen.. wozu werden Pins 22, 23, 53 als OUTPUT gesetzt? Was ist da angeschlossen?
https://github.com/fredlcore/bsb_lan/blob/05e1c5442b498846fdad4d123ac340a49ebdd6de/src/BSB/bsb.cpp#L22


Wäre es nicht übersichtlicher/code sparender mit einem Pointer, z.b. "Stream* serial_bus;" in der Klasse BSB zu arbeiten, statt zwei serial_sw/serial_hw pointer?


Bzgl. Kollision... noch eine Idee. Statt das grade gesendete Byte zu ignorieren könnte man es mit dem Byte vergleichen was gesendet wurde.

Code Auswählen Erweitern

      serial_hw->write(data);
      serial_hw->flush();
  // TODO: read byte and compare to the one we just send? (to detect collisions)?
      serial_read(); // Read (and discard) the byte that was just sent so that it isn't processed as an incoming message
https://github.com/fredlcore/bsb_lan/blob/05e1c5442b498846fdad4d123ac340a49ebdd6de/src/BSB/bsb.cpp#L423

Gruß,
Thomas

[freetz]

Ah, hatte ich mir fast schon gedacht, dass das kein "normales" System ist. Aber wieso testest Du ohne (Spannung am) Bus?

Auf jeden Fall danke für die hilfreichen Tipps, das mit dem Pointer hatte ich ursprünglich auch so umgesetzt, siehe hier:
https://github.com/fredlcore/bsb_lan/blob/fc8c627e081ae70a245461f3122c47ecc5c451a9/src/BSB/bsb.h
(am Ende)
und hier:
https://github.com/fredlcore/bsb_lan/blob/fc8c627e081ae70a245461f3122c47ecc5c451a9/src/BSB/bsb.cpp

Das Problem war nur, dass ich per Define ein entsprechendes Objekt verwendet habe (also SoftwareSerial oder HardwareSerial bzw. später beim Due dann USARTClass), aber dass ich dieses Define nicht von der BSB_lan_config.h "durchreichen" kann. Und ich wollte es Newbie-Usern dann nicht zumuten das Define in den Tiefen der Quellcodeunterverzeichnisse in einer header-Datei zu ändern. Aber wenn Du da einen Tipp hast, wie ich der "serial"-Variable zur Laufzeit ein Referenz zu einem der drei Objektklassen(?) zuweisen kann, dann wäre das natürlich sehr viel übersichtlicher.

Pin 53 wird später die Referenzsspannung für den RX-Pfad liefern, da ich den nicht wie bisher von 5V ziehen kann, wenn beim Due die Pins nur 3.3V vertragen. Beim Raspi wird dieser Weg schon in der jetzigen Schaltung so gegangen. Die Pins 22 und 23 habe ich nur wegen meiner Testplatine hier noch drin, das fliegt dann natürlich demnächst wieder raus.

Der Tipp mit dem Testen auf einen identischen Wert ist auch gut, wobei dieser Wert theoretisch ja auch von einem anderen Gerät kommen könnte, so dass es vermutlich keine größere Sicherheit wäre, oder?

Danke auf jeden Fall und VG, F.

[loetmeister]

Ah, hatte ich mir fast schon gedacht, dass das kein "normales" System ist. Aber wieso testest Du ohne (Spannung am) Bus?

Die Heizung steht ca. 30 Kilometer von mir entfernt... daher die "Trockenübung"
"normal" ist relativ... hab mal nen Foto angehängt. Wenns getestet ist, stelle ich auch den Schaltplan zur Verfügung. Ist aber nur eine kleine Abwandlung der Referenz in GitHub.

wenn Du da einen Tipp hast, wie ich der "serial"-Variable zur Laufzeit ein Referenz zu einem der drei Objektklassen(?) zuweisen kann, dann wäre das natürlich sehr viel übersichtlicher.

Ja, das mit den Header Dateien ist schwierig.... schlage mich bei Arduino damit auch rum.
Die Klasse des Pointers wäre einfach "Stream", das ist die Basisklasse von Soft-/Hardware serial. Vermutlich müsstest du das aus dem Konstruktor in eine "init" Funktion verschieben... z.b. in setup() dann bus.init(&seral1) / bus.init(&sw_serial) ausführen. So ist es bei dem HBWired (Homematic Homebrew) Projekt gelöst, an dem ich mich beteilige...

Pin 53 wird später die Referenzspannung für den RX-Pfad liefern, da ich den nicht wie bisher von 5V ziehen kann, wenn beim Due die Pins nur 3.3V vertragen. Beim Raspi wird dieser Weg schon in der jetzigen Schaltung so gegangen..

Ah. ok. Bei meinem Mega Klon ist 3,3V separat herausgeführt, da bräuchte ich keinen IO Pin nehmen. Die Pins sind glaube ich auch nur mit max. 20 mA belastbar (für eine LED im Optokoppler reicht es natürlich).

Der Tipp mit dem Testen auf einen identischen Wert ist auch gut, wobei dieser Wert theoretisch ja auch von einem anderen Gerät kommen könnte, so dass es vermutlich keine größere Sicherheit wäre, oder?

Ich hab mich nicht mit dem Protokoll auseinander gesetzt...  wie wahrscheinlich ist es das ein genau gleiches Byte, in den selben X Millisekunden empfangen wird?

(Edit: vertipper)

Gruß,
Thomas

[freetz]

Ah, ok - was hast Du denn für Abwandlungen vorgenommen? Noch irgendwelche Tipps, die ich für eine neue Revision berücksichtigen sollte? Und ja, 3.3V werden auf allen Arduinos ausgeführt, allerdings nicht an dem "hinteren" Ende des Mega/Due. Und da ich nicht nur deswegen eine Platine über die ganze Länge des Arduinos herstellen lassen will und auch Jumper Kabel dafür keine gute Lösung sind, bin ich dann über die IO-Pins gegangen.

Das mit dem Stream-Objekt werde ich mal probieren, das wäre eine sehr elegante Lösung für dann perspektivisch drei Anbindungsmöglichkeiten.

Was das zufällige Byte angeht, würde es schon reichen, wenn das zweite Byte der Prüfsumme ein 0xDC (bei BSB) oder 0x78 (bei LPB) wäre. Ein nachfolgendes Telegramm würde dann mit dem entsprechenden Start-Byte starten, das dann nicht ignoriert werden dürfte...

[loetmeister]

Hi,

habe mal bsb_lan in mein repo kopiert und Serial Stream eingebaut... auf die schnelle: https://github.com/loetmeister/bsb_lan/commit/7db7927f89bd13918aadd970956a99787203b6a2
So super hübsch ist es noch nicht... sollte aber funktionieren. Ich meine Serialxx.begin() gehört in setup() und dann kann man den Pointer sauber  übergeben (z.b. void begin(Stream* _serial_bus)

Mir ist auch aufgefallen das es viele variablen doppelt gibt. Als globale variablen und in der Klasse BSB (z.B. bus_type, len_idx) - wäre doch eigentlich unnötig?

Gruß,
Thomas