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

[loetmeister]

Hi freetz,

Interessante Ergebnisse.
Kannst du mal die pegel an RX messen? Mit dem Bus Adapter angeschlossen und einmal mit INPUT_PULLUP gesetzt und einmal ohne?

Gruß,
Thomas

[freetz]

Also mit INPUT_PULLUP sind es 3,6V und ohne 3,4V.

[freetz]

...wobei ich jetzt noch mal etwas länger gemessen habe und in den "Ruhephasen" eher 3,22V ohne INPUT_PULLUP und 3,18V mit INPUT_PULLUP sind, also eigentlich kein Unterschied...

[schuppi139]

Hallo Zusammen,

bin neu hier und versuche mich durch viel einlesen, daran das Data logging mit dem Arduino Adapter an meiner Brötje Heizung umzusetzen.

Ich habe folgende Komponenten:
https://www.amazon.de/gp/product/B01MA5BLQI/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
https://www.reichelt.de/arduino-shield-ethernet-shield-2-ohne-poe-w5500-arduino-shd-eth2-p159410.html

Zu meiner Anlage:
Es ist eine Brötje Gastherme WGB EVO 15H mit ISR LMS 15. Inkl Solarthermie, was alles über die Therme geregelt wird.

Ich habe die Adapterplatine selbst bestückt und alles nach der Anleitung im Github durchgeführt.
https://1coderookie.github.io/BSB-LPB-LAN/inhaltsverzeichnis.html

Nun zu meinem Problem, ich bekomme als Rückmeldung im Single monitor beim Arduino tool immer die Meldung "Query failed" (siehe Anhang). Wird wahrscheinlich daran liegen dass keine Device family und device varaint vergeben werden.
Ich habe schon so ziemlich alles Tipps versucht zu prüfen. Die im Github erwähnt sind, es liegt wohl meistens an der Hardware, da kenn ich mich aber leider wenig aus, habe es so zusammengebaut wie es beschrieben war.

An der Adapterplatine flackert die rote LED auch leicht, was ja wohl bedeutet, dass die Bus Kommunikation funktioniert.

Hat jemand eine Idee was ich noch prüfen kann?

Was ich noch vergessen hab zu erwähnen, war dass ein IDA Raumgerät an die Heizung mal angeschlossen war.

Frage die ich mir stell, kann hier was in der Heizung eingestellt worden sein, was die Kommunikation jetzt verhindert?`

Ich hoffe ich habe soweit alle Infos geteilt.

Viele Dank schonmal

[Schotty]

Moin schuppi139

Also dass IDA mal angeschlossen war, ist nicht das Problem, dahingehend kann ich dich schonmal beruhigen. Die verlinkten Komponenten sehen auch gut aus, das sollte auch nicht das Problem sein.

Dass "device family & variant" nicht vergeben werden, liegt am 'query failed': Die Anfrage oder Antwort vom Regler kommt nicht durch, deshalb wird er nicht erkannt.
Flackert die LED in dem Moment, wenn du einen Befehl abschickst? Oder nur in Ruhe?
Hast du bei SJ1 einen Lötpunkt gesetzt und den Kontakt somit geschlossen?
Dioden und Optokoppler richtig herum verbaut?

[freetz]

@loetmeister: Mir fällt gerade auf, dass Du vermutlich die Spannungswerte meinst, wenn die Schaltung zwar angeschlossen ist, aber nicht an den Bus. In dem Fall ist die Spannung 0V ohne INPUT_PULLUP und 0,14V bei aktiviertem INPUT_PULLUP. Hilft das weiter?

[Fox]

Hallo zusammen,
ich lese ja jetzt schon seit längerem mit und komme hoffentlich auch bald dazu mir einen passenden Adapter zu bauen, so das meine Heizung dann auch mit mir spricht. Bisher kann ich also noch nicht aus praktischer Erfahrung sprechen 

Bezüglich der Verwendung der HW-Serial hab ich noch eine Sache im Hinterkopf, wo ich allerdings nicht weiß (und grad auch nicht im Code geprüft hab), ob das nicht vielleicht sogar umgesetzt ist / wird.
Die Sende- und Empfangseinheit hängen ja immer gleichzeitig am Bus, also müsste beim Senden das gesendete Byte immer auch empfangen werden. So lange alles gut läuft sollte immer genau das Byte empfangen werden, welches auch gesendet wird. Bei einer Kollision würden sich diese unterscheiden. So könnte man zumindest byteweise eine Erkennung durchführen.

Der eigentliche Grund für den Post war allerdings, der Mangel an Flashspeicher. Wenn ich das beim Überfliegen richtig gesehen habe, dann wird ja der Großteil des Flashspeichers von den Konfigurationsdateien und Texten belegt. Das ganze könnte man natürlich erheblich reduzieren, wenn das alles nicht im Flash gelagert wird. Meine Idee ist jetzt die folgende, man legt diese ganzen Dateien auf einer SD-Karte ab und lädt die entsprechenden Daten nur bei Bedarf nach.

Der Nachteil ist natürlich, das man dann immer eine SD-Karte gesteckt haben muss.

Allerdings ergeben sich daraus auch einige zusätziche Vorteile:
- Speicher ist unabhängig von der gewählten Sprache
- Änderungen im Protokoll können durch Austausch der SD-Karte erfolgen ohne das der µC neu geflasht werden muss (da es sich hier "nur" um einen Austausch von Dateien handelt wäre es perspektivisch sogar möglich das ganze über das Web-Interface zu erledigen)
- Es könnte weiter bei einer HW-Platform bleiben, so das sich der Aufwand für die Pflege reduziert.
- Durch relativ unabhängige Komponenten könnte die Arbeit besser verteilt werden (eventuell findet sich dann jemand der die Daten der SD-Karte pflegt oder jemand anders übernimmt die SW)

Gruß Jan

[freetz]

@Fox: Es sind noch Platinen da, falls Du es nicht selber auf Breadboard aufbauen willst.
Und danke für den Input! Was die Erkennung des gesendeten Bytes angeht, wird das nach meiner Erinnerung schon so gemacht, das Problem ist ja nur, dass, wenn das nicht der Fall ist, ja schon ein anderes Gerät gesendet haben muss, dessen Nachricht durch das Senden von BSB-LAN dann ja auch verfälscht wird. Daher war der Ansatz (auch bisher schon, zumindest in der Theorie), dass gelauscht wird, ob der Bus gerade heruntergezogen wird, also eine logische 1 gesendet wird. Wenn das der Fall ist, wird gewartet und dann erneut gelauscht. So bleibt ein bereits gesendetes Telegramm unversehrt.

Was das Auslagern der Sprachdateien angeht, ist es richtig, dass das den größten Teil des Speichers ausmacht. User "dukess" auf GitHub, der auch die russischen Sprachdateien beiträgt, die wegen Unicode zwei Byte pro Zeichen verbrauchen, arbeitet auch schon an so einer Lösung. Ich glaube allerdings nicht, dass das besonders performant ist, denn dann muss ja trotzdem für jede Anfrage immer der entsprechende nachgeladen werden, denn der Speicher reicht ja nicht dafür aus, einfach alles nachzuladen. Es ist ja auch jetzt schon so, dass nicht alle Sprachen im Flash sind, sondern nur die, die zur Zeit des Kompilierens angegeben ist. Es gibt Leute, die alle 30 Sekunden 10 Werte abfragen, da hat man dann schon ein ganz schönes Dauerfeuer auf der SD-Karte, wenn für jeden Parameter dann ein SD-Karten-Lesezugriff gemacht werden muss...

Nach den letzten Tests bin ich sehr zuversichtlich, dass wir mit dem Due eine Plattform haben, die langfristig (also so lange der Due erhältlich ist) die Bedürfnisse des Projektes abdeckt. Darüber hinaus erspart mir ein 32-Bit-System die wirklich unschönen Hacks, die ich anwenden muss, um mit einem 16-Bit Adressbus auf 256kB Flash-Speicher zuzugreifen.
Grundsätzlich werden es dann auch keine zwei Codebasen sein, die ich warten muss, wenn ich den jetzigen Code etwas "säubere" - (unsigned) int sind z.B. auf dem Mega nur 16 Bit groß, wohingegen es beim Due 32 Bit sind. Das passiert an manchen Stellen implizit, wo ich dann explizit den Typ uint16_t casten muss. Auch beim Zugriff auf die SD-Karte des Ethernet-Shield gibt es noch Probleme, da die SD-Karte nicht erkannt wird, aber das sind keine grundsätzlichen Hürden mehr. Wenn wir die Schaltung dank Eurer Hilfe einmal "wasserdicht" haben, ist es am Ende nur noch Fleißarbeit...

[schuppi139]

Moin schuppi139

Also dass IDA mal angeschlossen war, ist nicht das Problem, dahingehend kann ich dich schonmal beruhigen. Die verlinkten Komponenten sehen auch gut aus, das sollte auch nicht das Problem sein.

Dass "device family & variant" nicht vergeben werden, liegt am 'query failed': Die Anfrage oder Antwort vom Regler kommt nicht durch, deshalb wird er nicht erkannt.
Flackert die LED in dem Moment, wenn du einen Befehl abschickst? Oder nur in Ruhe?
Hast du bei SJ1 einen Lötpunkt gesetzt und den Kontakt somit geschlossen?
Dioden und Optokoppler richtig herum verbaut?

Hey Schotty,

Danke für deine Antwort.

Ich habe alles nochmal kontrolliert. Leider ist meiner Meinung nach alles richtig bestückt. Magste mal schaun, hab ein Bild im Anhang von meiner Platine? Ich werde jetzt nochmal alles nach löten, falls sich dich ne kalte Lötstelle eingeschlichen haben sollte.

Sonst ne Idee?

Gruß

[Fox]

@Fox: Es sind noch Platinen da, falls Du es nicht selber auf Breadboard aufbauen willst.

Ne, das hatten wir schon

Und danke für den Input! Was die Erkennung des gesendeten Bytes angeht, wird das nach meiner Erinnerung schon so gemacht, das Problem ist ja nur, dass, wenn das nicht der Fall ist, ja schon ein anderes Gerät gesendet haben muss, dessen Nachricht durch das Senden von BSB-LAN dann ja auch verfälscht wird. Daher war der Ansatz (auch bisher schon, zumindest in der Theorie), dass gelauscht wird, ob der Bus gerade heruntergezogen wird, also eine logische 1 gesendet wird. Wenn das der Fall ist, wird gewartet und dann erneut gelauscht. So bleibt ein bereits gesendetes Telegramm unversehrt.

Ist mir ja nur so nebenbei eingefallen und wenn es schon umgesetzt ist, dann ist ja gut. Alles andere wäre vermutlich ziemlich aufwendig.. Wobei mir da gerade noch eine Idee kommt, das elektrische Protokoll klingt ziemlich nach dem LIN-BUS, eventuell könnte man hier mit einem Baustein das ganze erschlagen, das muss ich aber noch mal prüfen...

Was das Auslagern der Sprachdateien angeht, ist es richtig, dass das den größten Teil des Speichers ausmacht. User "dukess" auf GitHub, der auch die russischen Sprachdateien beiträgt, die wegen Unicode zwei Byte pro Zeichen verbrauchen, arbeitet auch schon an so einer Lösung. Ich glaube allerdings nicht, dass das besonders performant ist, denn dann muss ja trotzdem für jede Anfrage immer der entsprechende nachgeladen werden, denn der Speicher reicht ja nicht dafür aus, einfach alles nachzuladen. Es ist ja auch jetzt schon so, dass nicht alle Sprachen im Flash sind, sondern nur die, die zur Zeit des Kompilierens angegeben ist. Es gibt Leute, die alle 30 Sekunden 10 Werte abfragen, da hat man dann schon ein ganz schönes Dauerfeuer auf der SD-Karte, wenn für jeden Parameter dann ein SD-Karten-Lesezugriff gemacht werden muss...

Na ja, was das angeht könnte man ja einen Teil der Daten von der SD-Karte zwischenpuffern, so das die häufigsten Anfragen direkt aus dem RAM / Flash beantwortet werden. Dann könnte man sich vielleicht auch das für den Due notwendige EEPROM sparen.

Nach den letzten Tests bin ich sehr zuversichtlich, dass wir mit dem Due eine Plattform haben, die langfristig (also so lange der Due erhältlich ist) die Bedürfnisse des Projektes abdeckt. Darüber hinaus erspart mir ein 32-Bit-System die wirklich unschönen Hacks, die ich anwenden muss, um mit einem 16-Bit Adressbus auf 256kB Flash-Speicher zuzugreifen.
Grundsätzlich werden es dann auch keine zwei Codebasen sein, die ich warten muss, wenn ich den jetzigen Code etwas "säubere" - (unsigned) int sind z.B. auf dem Mega nur 16 Bit groß, wohingegen es beim Due 32 Bit sind. Das passiert an manchen Stellen implizit, wo ich dann explizit den Typ uint16_t casten muss. Auch beim Zugriff auf die SD-Karte des Ethernet-Shield gibt es noch Probleme, da die SD-Karte nicht erkannt wird, aber das sind keine grundsätzlichen Hürden mehr. Wenn wir die Schaltung dank Eurer Hilfe einmal "wasserdicht" haben, ist es am Ende nur noch Fleißarbeit...

Also spätestens wenn die Hacks für den 16-Bit Addresse rausfliegen wird sich ja die Codebasis unterscheiden

[schuppi139]

Flackert die LED in dem Moment, wenn du einen Befehl abschickst? Oder nur in Ruhe?

Die Diode flackert die ganze Zeit leicht, nachdem ich die Therme eingeschlatet habe.

Hier nochmal der Ablauf.

Nur Adapter und Therme verbunden.
Therme einschalten
USB und LAN an Adapter
Arduino Tool starten

Dann kommt es zu dem Verhalten was ich im Screenshot gepostet habe.

Ich habe aber nie etwas im Single Monitor gesendet. Weil du fragtest ob das flackern sich ändert wenn ich was sende.

Nachlöten hat nichts geändert

Gruß

[freetz]

Ne, das hatten wir schon

War nur ein Angebot. Bei einem User mit erst einem Beitrag gehe ich erst mal davon aus, dass wir uns noch nicht gesprochen haben ...

Na ja, was das angeht könnte man ja einen Teil der Daten von der SD-Karte zwischenpuffern, so das die häufigsten Anfragen direkt aus dem RAM / Flash beantwortet werden. Dann könnte man sich vielleicht auch das für den Due notwendige EEPROM sparen.

Der Mega hat 8kB an RAM, davon sind zur Startzeit des Scripts noch ca. 4kB frei, nicht mit eingerechnet, was zwischendrin noch in so einigen Funktionen gebraucht wird. Was willst Du da in welchem Umfang groß zwischenpuffern, bei momentan ca. 120kB Text?
Das EEPROM braucht man bei Due hauptsächlich für das Speichern der Soll-Temperaturen etc. am PPS-Bus, da die normalerweise in der QAA gespeichert sind und von der Heizung ständig abgefragt werden. Die müssen beim Start des Gerätes also bekannt sein. Könnte man auch alles über die SD-Karte machen, aber gerade weil ich die Codebasen nicht trennen will, will ich da auch weiterhin auf ein EEPROM setzen (was im Übrigen auch schon gut klappt).

Also spätestens wenn die Hacks für den 16-Bit Addresse rausfliegen wird sich ja die Codebasis unterscheiden

Natürlich unterscheiden sie sich, aber gerade der genannte Aspekt besteht beim Due dann nur noch aus einer Zeile, die ich (wie dann an einr andern, bisher überschaubaren Anzahl von Stellen auch) per #ifdef ein- bzw. ausblende.

[freetz]

@schnuppi139: Das sieht vom Aufbau her erst einmal gut aus - ich bin mir allerdings nicht 100% sicher, ob ich beide 5V-Pins verbunden habe, normalerweise nehme ich den, der in einer Reihe mit der GPIO-Leiste ist. Das könntest Du noch mal prüfen. Ansonsten mal mit offenem SerMo schauen, ob die LED auch leicht flackert kurz bevor die query failed kommen. Dann wäre das ein Indiz, dass das Senden schon mal funktioniert. Wenn da nichts flackert, ist der TX-Pfad "undicht". Andernfalls der RX-Pfad. Wobei ein identifizierter "undichter" TX-Pfad nicht ausschließt, dass auch im RX-Pfad eine kalte Löststelle ist.

[freetz]

@loetmeister: Ich habe jetzt auch noch mal am Mega mit (0,58V) und ohne INPUT_PULLUP (0V) getestet. Also auch hier ein messbarer, aber ggf. nicht signifikanter Unterschied. Jedenfalls lief es auch dort mit der entsprechenden pinMode-Zeile...

[Schotty]

@schnuppi139: Das sieht vom Aufbau her erst einmal gut aus - ich bin mir allerdings nicht 100% sicher, ob ich beide 5V-Pins verbunden habe, normalerweise nehme ich den, der in einer Reihe mit der GPIO-Leiste ist.

Exakt, das dürfte die Ursache sein, die Leiterbahn geht nur zu dem anderen 5V-Pin. (EDIT: Kannst du sehen, wenn du ganz genau hinsiehst: Der kleine helle Strich von dem Lötauge zum SJ1.)