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

[Schotty]

Aus aktuellem Anlass nochmal zwei wichtige Hinweise:

1. Wie bereits hier https://forum.fhem.de/index.php/topic,29762.msg992034.html#msg992034 erwähnt, ist bei den DS18B20er Sensoren die spezifische Sensor ID hinzugekommen - die Programme / regulären Ausdrücke müssen diesbzgl also angepasst werden. Dies betrifft allerdings nur die Ausgabe von /T.
AUßERDEM hat sich die Bezeichnung dahingehend geändert, dass die Sensoren nun mit "1w_temp" bezeichnet sind! Somit ist eine eindeutigere Unterscheidung möglich, wenn zeitgleich auch DHT22er installiert sind (an deren Bezeichnung hat sich nichts geändert).

Die Ausgabe sieht somit wie folgt aus:
Webinterface bei /T:

Code Auswählen Erweitern

1w_temp[0] 28ff5854c216040e: 22.13 °C Die 16-stellige ID ist natürlich immer eine andere und die jeweilige Nummer in den eckigen Klammern ist nach wie vor von der Anzahl der verwendeten Sensoren abhängig.

Im SerMo erscheint es nach wie vor so:

Code Auswählen Erweitern

temp[0]: 22.06

2. Vor geraumer Zeit wurde die Ausgabe von /H eingestellt, die Werte der DHT22er Sensoren werden seit dem ebenfalls unter /T mit angezeigt (falls wir das hier noch nicht so ausdrücklich erwähnt haben). Bei einem Update auf die aktuelle Version muss somit u.U. auch die URL geändert werden, unter der die Sensoren bisher ausgelesen wurden (wenn /H genutzt wurde).

Eine Bitte an die User, die die Beispielskripte für das Handbuch erstellt haben:
Könnten diejenigen, die in den Skripten eine Abfrage von /H und /T bzw von den DS18B20ern an sich mit aufgeführt haben, die Skripte dahingehend bitte anpassen und mir die aktualisierte Version zuschicken? Am Besten per Email.. DANKE!

[Luposoft]

Ein liebes Hallo an das Forum,

ich habe zufällig bemerkt, dass einige Parameterabfragen bei mir nicht stimmen

Exemplarisch: -
2441 - lt. Definition - Gebläseleistung Hzg Max - zeigt im Browser 0.0 kW an.
lt. Display - Gebläsedrehzahl Hzg Max - 4620 rpm

ich habe mit SerMon die CommandID abgefragt, diese ist noch garnicht hinterlegt
Ich hab die ID eingetragen und den Typ geändert, nun funktioniert dieser Wert.
ABER
Ich bin mit der Gerätefamilie 195 ja nicht alleine!

Kann es sein, dass diese Parameter noch nicht endgültig kontrolliert worden sind (dann mache ich das) , oder Gott bewahre es Unterschiede innnerhalb der Familie geben kann?

eine Verständnisfrage habe ich noch:
zum Umschalten der Abfrage auf das Display habe ich folgendes gefunden:

man muss dazu das "Ziel" kurzfristig von 0 (=Heizung) auf 10 (=Display) ändern, also /P0,6,10

warum wurde für die eigene Adresse 6 statt 0 genommen?

das gilt auf für die Web-Abfrage mit /Y06 (warum nicht /Y00 ?)

die Frage zielt auf eine korrekte Brute-Force-Abfrage auf das Display...

[freetz]

Also erst mal danke für das genaue Hinschauen!
In der Tat kann es bei jeder Kombination aus Gerätevariante und -familie sein, dass für eine bestimmte Parameternummer
a) die Bezeichnung,
b) der Wert,
c) der Datentyp
d) irgendeine Kombination von a)-c)
unterschiedlich sind.

Die meisten User machen sich nicht die Mühe, jeden einzelnen Parameter an ihrer Heizung mit BSB-LAN zu vergleichen, und das ist auch gar kein Vorwurf, denn die Parameter, die 95% der User zu 95% der Zeit verwenden, lassen sich wahrscheinlich gut an 1-2 Händen abzählen. Alles darüber hinaus sieht zwar bei der Komplettabfrage gut aus, aber wird nicht wirklich genutzt und von daher auch nicht kontrolliert.

Wenn Du nun also Abweichungen zwischen Deiner Heizung und der Anzeige in BSB-LAN gefunden hast, ist das erst mal prima - im Idealfall gibt es dadurch eine neue, bisher unbekannte Command ID, von der auch andere profitieren könnten, und ansonsten können wir zumindest für Deine Gerätefamilie den Parameter korrekt darstellen.

Dabei gehe ich so vor: Wenn es zu dem Parameter bisher noch keine gerätefamilienspezifische Eintragung gibt, füge ich den für die gemeldete Gerätefamilie hinzu (in Deinem Fall dann DEV_195_ALL). Wenn es den Eintrag schon gibt, jedoch mit einer der oben genannten Abweichungen, dann wird der neue Eintrag gerätefamilien- und -variantenspezifisch hinzugefügt (also dann z.B. DEV_195_123). Damit ist sichergestellt, dass es keine Kollisionen gibt, zumindest, wenn die Leute ab und an mal schauen, ob noch alle Werte stimmen (kann man am einfachsten mit einer Komplettabfrage alle paar Monate machen), denn es kann natürlich sein, dass bei Heizung A die generelle Command ID gepasst hat (also DEV_ALL), und nun bei Heizung B eine spezifische Command ID hinzugefügt wird (also z.B. DEV_195_ALL). Heizung A ist aber auch in Gerätefamilie 195, braucht aber dann eine Differenzierung zu Heizung B anhand der Gerätevariante, die ich dann entsprechend nachtragen kann, wenn ich davon weiß.

Was die Zielumschaltung angeht, besagt der Aufruf
/P0,6,10
dass die Kommunikation auf BSB (/P0) eingestellt wird mit der eigenen Adresse 6 und dem Ziel 10. Aktueller wäre, wenn dort statt 6 die 66 stehen würde, die wir vor einiger Zeit für BSB-LAN definiert haben (6 ist Raumgerät 1 (RGT1)). Die 0 als eigene Adresse wäre nicht sinnvoll, weil es die 0 schon gibt, nämlich die Heizung selber. Daher ist der normale Aufruf ja /P0,66,0 (eigene Adresse 66, Ziel 0).

Der /Y-Befehl erwartet hingegen den Nachrichtentyp als ersten Parameter, und da steht 06 für "Query"; eine Alternative wäre z.B. 01 (Query INF).

Bei der Brute Force Abfrage wird im Übrigen immer die aktive Einstellung von BSB-LAN übernommen, d.h. das, was unter /C angezeigt wird. Mir ist dabei eben aufgefallen, dass diese Erkennung nur mit der deutschen Sprachversion korrekt funktioniert, da muss ich noch mal nachstellen, damit das auch sonst klappt...

[freetz]

Es gibt eine wieder eine Neuerung, die vor einiger Zeit von @justme1986 vorgeschlagen wurde, nämlich, dass man BSB-LAN auch ausschließlich über die serielle/USB-Schnittstelle steuern kann.
Wenn man den Arduino über die USB-Schnittstelle mit einem Rechner verbindet (in meinem Fall ist das sogar die Synology NAS, auf der auch FHEM läuft) und mit einem Terminal-Programm auf die entsprechende serielle Schnittstelle zugreift (kann z.B. auch der Serielle Monitor der Arduino IDE sein), dann ist es jetzt möglich, die gleichen Befehle an BSB-LAN zu schicken, die man auch per URL-Aufruf absetzen kann.
Statt also z.B.

Code Auswählen Erweitern

http://<ip>/<passcode>/8700 zum Abruf der Außentemperatur aufzurufen, kann man über die serielle Schnittstelle auch direkt

Code Auswählen Erweitern

/<passcode>/8700 absetzen und bekommt dann die entsprechende Antwort ebenfalls über die serielle Schnittstelle, die dann z.B. so aussieht:

Code Auswählen Erweitern

#8700: 8.3 °C.

Zum einfacheren Parsen der Antworten sind zwei Dinge zu beachten: Antwortzeilen auf Aufrufe haben ein "#" als erstes Zeichen einer Zeile, gefolgt von der Parameternummer (etwas abweichend entsprechend bei /A und /T, aber immer mit # am Anfang).
Darüber hinaus kann man nun die ganzen Debug-Meldungen an einen Telnet-Client umleiten, dafür gibt es in der _config.h dann das Definement

Code Auswählen Erweitern

#define DebugTelnet 1
Damit werden außer der Startmeldung auf der seriellen Schnittstelle nur noch die zu erwartenden Antworten ausgegeben, es sei denn man aktiviert den Monitor Modus, dieser gibt weiterhin die Ausgaben auf dem seriellen Port aus.

Über das ECMD Modul von FHEM könnte man auf diese Weise auch jetzt schon BSB-LAN über diese serielle Anbindung nutzen und könnte damit auf das Ethernet-Shield verzichten. Mir fehlt da momentan die Zeit, eine grundlegende Anbindung mit ein paar beispielhaften Parametern aufzusetzen, aber vielleicht hat ja jemand anders die Muße, dann würden wir das auf jeden Fall ins Handbuch aufnehmen.

[Luposoft]

@freetz   - kurze Rückmeldung zu brute-force.pl

das Script habe ich abgeändert, die eigene Adresse ($orig) 66 passt so nicht mehr in die wget-Abfrage. Gleich in Hex gewandelt.

der erste Run läuft. Da kommen noch Unmengen an neuen ID's.

Ich will versuchen, für die bessere Zuordnung die OEM-Pin rauszubekommen.
Wenn ich das richtig verstanden habe, ist ein möglicher Weg, mit /P0,66,10 auf das Display zu schalten und dann major group x05 durchlaufen lassen. Ist das korrekt?

mit /Q wird bei mir für das Bedienfeld die richtige Softwareversion angezeigt.
wird dafür auch auf das Bedienfeld umgeschaltet? Welche CommandID wird dafür angesprochen?

Ich frage das, um vor dem Run so gut wie möglich zu wissen, dass ich richtig liegen könnte mit den Abfragen ...

[Schotty]

..nur ganz kurz zwischendurch @freetz diesbzgl: Wir hatten doch damals brute force Abfragen gemacht, oder hatten wir das nur für die Regler durchlaufen lassen?

Zu den AVS37-Bedieneinheiten: Die scheinen übrigens modellspezifisch geflasht zu sein. Ist mir aufgefallen, als ich mal ein Brötje WGB-AVS37 an einen Siemens SSR-Regler angeschlossen habe, da erscheinen nicht alle Parameter am Display oder werden manchmal ohne Text dargestellt.

[freetz]

@luposoft: Es wäre schön, wenn Du noch dazu schreiben könntest, warum die eigene ID nicht mehr passt und wie Du das Script abgeändert hast. Dann haben auch andere (und ich) etwas davon.
Dass Unmengen neuer IDs kommen, wundert mich ein wenig, kannst Du stichprobenartig mal nach ein paar gefundenen IDs in der _defs.h suchen?

Und ja, mit /P0,66,10 schaltest Du als Ziel auf das Display um, jedoch ist das nur begrenzt von Interesse, weil man das Display ja kaum Funktionen hat, die irgendetwas bringen.

Mit /Q wird der Reihe nach auf alle gefundenen Geräte umgeschaltet. Das erfolgt nicht über eine CommandID, sondern analog zu /P.

@Schotty: Wir hatten das auch für unsere Displays gemacht (ich zumindest), aber wie gesagt, mit begrenztem Erfolg.

[Luposoft]

@freetz - zu brute-force.pl

im originalem Code fand keine Hexumrechnung statt. Funktionierte auch, da <10.
Mit der neuen Adresse 66 eben nicht mehr.
daher:

Zeile 44: my $orig = $2; geändert in:  my $orig=sprintf("%02X", $2);

Zeile 71: $answer = `wget -q -O - $URL/Y06,0x$ID | grep "DC 8$dest 0$orig"`; geändert nach : `wget -q -O - $URL/Y06,0x$ID | grep "DC 8$dest $orig"`

Damit funktioniert es mit 6 und mit 66

Ihr macht so geile Sachen, da fand ich es sehr vermessen, eingehende Erläuterungen anzustellen.

[freetz]

Ah, klar, danke! Selbst wenn das wirllich so prima ist, was wir hier machen, muss das ja nicht heißen, dass man immer auch an alle Sachen denkt - wie hier bei dem Script, wo ich damals wohl zu kurz gedacht habe (und es schon damals bei der Brute Force auf das Display mit der "10" nicht funktioniert hätte)...

[freetz]

Übrigens sehe ich jetzt beim Testen, dass da natürlich viele IDs kommen - relevant sind aber nur die, die dann am Ende auch in der defs-brute-force-...h stehen ...

[freetz]

Eine Frage inbesondere an die Elektrotechnik-Affinen User hier:

Ich habe mich etwas mit der Frage beschäftigt, warum Gero damals auf SoftwareSerial gesetzt hat und nicht das HardwareSerial Interface des Mega nutzt, der davon ja vier Stück hat. Ich vermute, dass es damals nicht die Konfigurationsmöglichkeit gab, die etwas exotische Übertragungsart 8O1 zu nutzen. Inzwischen weiß ich aber aus einem anderen Projekt, das das geht und habe mich dann einmal daran gemacht, den Bus über das HardwareSerial Interface anzusprechen. Mit Erfolg: Nicht nur hat das gut geklappt, es ist auch möglich, dies mit der bisherigen Platine über die Raspberry Pi Pins diese Verbindungsart zu nutzen, wenn man sie um einen Pin verschiebt (mehr dazu in Kürze, wenn Schotty und ich das abschließend getestet haben). Der größte Vorteil wird sein, dass dabei vermutlich/hoffentlich die vereinzelt auftretenden Übertragungsprobleme bei Clone-Arduinos mit ungenauer Taktgebung der Vergangenheit angehören werden, weil die Übertragungsgeschwindigkeit dann nicht mehr über die Software basierend auf der Taktfrequenz berechnet werden muss. Außerdem wird das System dadurch prinzipiell protabler für andere Systeme.

Nun zu meiner Frage: Der Raspi-Teil der Schaltung ist ja etwas "von hinten durch die Brust ins Auge", weil Gero bei der SoftwareSerial-Implementation mit einer invertierten Logik gearbeitet hat. Die musste dann über zwei Transistoren wieder zurückgewandelt werden, was eigentlich unnötig ist, wenn man erst gar nicht invertiert. Ich habe nun eine Schaltung aufgebaut, die an sich erst mal auf dem Breadboard funktioniert und mit weniger Bauteilen auskommt (allerdings mehr, als bei der jetzigen SoftwareSerial-Schaltung).
Könnte einer von Euch da mal einen Blick drauf werfen und mir insbesondere sagen ob bei einer Referenzspannung über einen GPIO (ARD_23-53 Pin 1 bzw. RasPi Pin 09) der bisherige 4k7 Widerstand wirklich wegfallen kann, wenn ich am Optokoppler-Ausgang einen 10k Pulldown habe? Oder sollte der Strom vom GPIO-Pin, der ja bei Ruhe auf dem Bus (also die meiste Zeit) zu RX1 fließt, mit einem zusätzlichen Widerstand noch begrenzt werden? Ich bin mir nicht ganz sicher, ob ich das mit den invertierenden und nicht invertierenden Schaltungen richtig verstanden bzw. umgesetzt habe.

Und dann noch eine Frage zu den PullUp/Down Widerständen: Sind da 10k sowohl für die 5V des Arduino als auch die 3.3V des Raspberry passend? Oder sollte ich da (im Interesse des Raspi) auf 4k7 runtergehen?

Danke schon mal im Voraus und viele Grüße

F.

[loetmeister]

Hi Freetz,

hardware serial finde ich super.
Hab alle Teile (Arduino Klon, LAN Adapter, etc.) und eine Lochrasterplatine hier liegen und wollte es die Tage mal zusammen klöppeln. Welchen von den (drei verbliebenen) USART würdest du nutzen?

Ich hatte den raspi Teil bisher ignoriert, da ich nur die Schaltung für den Arduino brauche... Hatte die beiden Transistoren als Pegelwandler abgetan - was aber nicht stimmt.  Mich hat nur gewundert das der Vorwiderstand der TX Optokopplerdiode 300 Ohm für 5V als auch 3,3V ist...

der bisherige 4k7 Widerstand wirklich wegfallen kann, wenn ich am Optokoppler-Ausgang einen 10k Pulldown habe? Oder sollte der Strom vom GPIO-Pin, der ja bei Ruhe auf dem Bus (also die meiste Zeit) zu RX1 fließt, mit einem zusätzlichen Widerstand noch begrenzt werden?

Im alten Schaltplan meinst du R11 und R4? Eigentlich sollte es egal sein ob ein IO Pin auf GND oder Vcc liegt... Schutzschaltung ist ja schon im Chip...

Und dann noch eine Frage zu den PullUp/Down Widerständen: Sind da 10k sowohl für die 5V des Arduino als auch die 3.3V des Raspberry passend? Oder sollte ich da (im Interesse des Raspi) auf 4k7 runtergehen?

10k bei 5V klingen gut, für 3,3V könnte es möglicherweise knapp sein, wenn die Frequenz hoch ist? Denke mit 4k7 hast du schnellere Ansprechzeiten - wobei ich eigentlich keine keine kapazitiven Lasten sehe...

An meinem MEGA-PROMINI gibt es auch 3,3V... man könnte die Schaltung für ausschließlich 3,3V bauen?

Gruß,
Thomas

[freetz]

Hi loetmeister,

es wird auf Serial1 (TX1/RX1) hinaus laufen, weil man dann die bestehende Platine einfach nur um einen Pin verschieben muss.
Was die Widerstandswerte angeht, hat damals der Entwickler der Raspi-Software bei dem Schaltplan geholfen und ein paar Leute haben es am Raspi auch im Einsatz, von daher scheint das so zu klappen. Ich meine, dass z.B. die 300 Ohm für 5V eher niedrig angesetzt sind, so dass es deshalb passt?

Und ja, im alten Schaltplan meine ich R4 (R11 ist ja nur für den invertierenden Transistor nötig, den ich bei der neuen Schaltung ja nicht mehr brauchen würde). Der begrenzt ja den Strom, der vom 5V-Pin im Ruhezustand auf den RX-Pin geht. ich dachte, dass das ein PullUp ist, und dass es dabei weniger um Schutzmechanismen als um Senkung des Stromverbrauchs geht? In der neuen Schaltung fließt der Strom ja von dem stromversorgenden Pin über den OK direkt in den RX-Pin. Von daher die Frage, ob da in Form eines weiteren Widerstands eine Begrenzung Sinn macht.

Was 10k vs 4.7k angeht, war ich jetzt auch bei 3.3V von 10k ausgegangen, weil die in der alten Schaltung auch so drin waren. Wenn Du meinst, dass 4.7k besser wären, was wäre das für ein Nachteil bei der 5V-Schaltung?

Ziel sollte es sein, dass die Schaltung (wie bisher) bei Komplettaufbau sowohl an einem 5V als auch an einem 3.3V-System betrieben werden kann. Problematisch sehe ich da wenn überhaupt in der neuen Schaltung nur R6 und evtl. R3, und die würde ich dann versuchen so anzupassen, dass sie auf beiden Systemen zuverlässig funktionieren, im Zweifelsfalls auf Kosten des Stromverbrauchs. Oder habe ich da was übersehen?

Danke auf jeden Fall und VG, F.

[Schotty]

Loetmeister?! Hast du den Adapter in Betrieb? Ich glaube, ich habe dich noch nicht in meiner Userliste, kann das sein..?
Falls ja, poste doch bitte einmal Hersteller, Modellbezeichnung und /Q - danke

[loetmeister]

Hi,

@Schotty, ja.. von mir hast du noch nix. Ich fiebere (oder besser "fröstel") der Inbetriebnahme entgegen. Ist eine BGB EVO 20 i. (Stand- nicht Wandgerät) Sollte diese Woche laufen. Sobald ich kann, stelle ich dir die /Q Ausgabe zur Verfügung.

@freetz,

Ich meine, dass z.B. die 300 Ohm für 5V eher niedrig angesetzt sind, so dass es deshalb passt?

Ja, ist eher am unteren Ende angesetzt. Bei 3,3V sind es ca. 7mA. Bei 5V fast 13mA. Die 4N25 haben ab 10mA schon fast 100% Übertragungsverhältnis (Current Transfer Ratio). Bis 20mA ist alles ok. Da ich nur für Arduino baue, also 5V werde ich wohl auf 470R gehen. (~8mA)

Und ja, im alten Schaltplan meine ich R4

Ok... wenn ich das nicht ganz falsch sehe, dann ist in der alten RPI Beschaltung R13 der Pullup? R4 Begrenzt den Strom der durch den Transistor in U1 zu GND fließt. Nur in Arduino Beschaltung ist R4 der Pullup.

In der neuen Schaltung ist R6 ein pulldown. Wenn OK1 schaltet liegt 3,3V an RX1. Das sollte aber meiner Meinung kein Problem sein, da Eingangspins sehr hochohmig sind.
Würde sagen das passt.

Wenn Du meinst, dass 4.7k besser wären, was wäre das für ein Nachteil bei der 5V-Schaltung?

Das verdoppelt in etwa den Strom (0,5mA zu 1mA)... kein Drama. Wenn es mit 10k am raspi läuft, dann bleib dabei. Bei 5V ist es auf jeden Fall ok.


Ich benötige keine Platinen, aber ich persönlich würde sie so bauen das beide Versionen das selbe Layout nutzen (wie jetzt auch), aber etwas abweichende Bestückung für 5 oder 3,3V benötigt wird. Dann ist natürlich ab dem Auflöten der Bauteile festgelegt wie ich die Platine nutze... keine Ahnung wie oft man das nachträglich noch mal wechseln würde. 

Gruß,
Thomas