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

[Schotty]

Hallo, sorry, habe ich gelesen un dauch umgesetzt!

Den Parameter 10000 kann ich nicht setzten.
192.168.1.226/S10000=22 führt zu 'FEHLER: Setzen fehlgeschlagen!'

Du nutzt den /S-Befehl, aber, Zitat Handbuch: "Mittels einer INF-Nachricht kann eine Raumtemperatur an den Regler gesendet werden" und dann "Beispiel:
Der URL-Befehl für den HK1, um eine Raumtemperatur von 19.5°C zu übermitteln, lautet: http://<ip-adresse>/I10000=19.5"

Also nochmal: Der Befehl lautet /I10000=20 und NICHT /S10000=20.

[Shortypower]

Jawoll, so gehts!

Danke vor allem für die Gedult!

[miwi]

So verhält sich BSB-LAN nun nicht gerade "sozial" auf dem Bus, aber wenn sich letztlich alle an die Regeln halten und nur einer nicht, dann funktioniert die Kollisionserkennung am Ende trotzdem. Ich wollte es hier aber trotzdem noch einmal zur Klärung einbringen. Falls jemand eine Idee hat, wie man CSMA/CD mit HardwareSerial umsetzen kann, freue ich mich über jeden Hinweis. Vielleicht reicht ja schon vor dem Senden den Empfangspuffer mit available() abzufragen und ggf. gerade auflaufende Daten abzuwarten oder etwas in der Art. Von HardwareSerial wieder abzugehen ist in meinen Augen aber keine Option, weil die Stabilitäts- und Geschwindigkeitszuwächse (ersteres insbesondere bei PPS-Usern) einfach zu eindeutig sind.

Richtig, UARTs fuehren zu einer unsozialen Implementierung, denn eine einmal begonnene Uebertragung eines Bytes kann bei einem UART nicht angehalten  werden (hoechstens vielleicht, wenn man den Takt abschaltet).  Man kann aber die Uebertragung am Ende so aendern, dass alle Teilnehmer am Bus sie als gestoert erkennen muessen,  Man sendet anstelle eines 'H' Stopbits ein 'L' Stopbit, womit ein character frame als falsch erkannt werden muss.
Ein Patent beschreibt diese Implementierung, die auch bestimmte Telegramm-Inhalte voraussetzt.  Die entsprechen dem Bus-Protokoll von BSB/LPB nicht exakt, sind ihm aber ziemlich aehnlich.  Ggf. kann das Verfahren auf das BSB/LPB Protokoll angewendet werden. 

Frage: Kann eigentlich nur nach einem SET command ein NACK vorkommen, oder kann man ein NACK ungestraft nach jedem command senden, wenn dessen Inhalt zerstoert war?

Patent US6385210 B1 "Method for detecting and resolving data corruption in a UART based communication network"
https://patents.google.com/patent/US6385210B1/en

[Mike_pa]

@freetz
Das CSMA/CD Verfahren mit UARTS ist in dem Patent
https://patents.google.com/patent/EP1515237A1/it
beschrieben. Es würde sicher ausreichen jedes gesendete Byte gleichzeitig mitzulesen und bei Ungleichheit kein weiteres Byte mehr zu senden sondern nach einer zufälligen Pause die Übertragung neu zu starten. M. E. wird die Sendeinformation doch schon auf die Rx Leitung zurückgekoppelt oder? Erkennung, ob Bus belegt bevor man eine Sendung startet geht, wenn man den Pegel des Rx Pin lesen kann oder diesen zusätzlich auf einen digitalen Eingang legt, den man vor der Sendung auf Ruhepegel für Zeit x überprüft.

[Jewe]

Danke, den Hinweis aufs Handbuch wollte ich auch gerade schreiben (bzw. hatte ich gerade, hab's aber wieder gelöscht ). Aber:
Der von dir genannte Link funktioniert seit der Umstruktierung nicht mehr (Hinweis gab's hier: https://forum.fhem.de/index.php/topic,29762.msg1139674.html#msg1139674), der korrekte Link lautet: https://1coderookie.github.io/BSB-LPB-LAN/kap06.html#63-raumtemperatur-%C3%BCbermitteln

Hey Schotty,

ja das hatte ich schon mal mitbekomen und deshalb extra auf den Link in Deiner Singatur geclickt und dort den link rausgesucht.... aber irgendwas habe cih da wohl falsch gemacht....

Danke für die Berichtigung.

Jens.

[freetz]

@miwi und @Mike_pa: Danke für Euren Input. Das Abfragen des gerade gesendeten Bytes sollte gehen, das werde ich mal ausprobieren. Direkt den RX-Pin auszulesen, sollte ebenfalls gehen (bzw. machen wir das m.E. schon), da ist halt nur das Problem, dass ich einen High-Pegel als Teil eines Datensatzes nicht von einem freien Bus unterscheiden kann, bzw. müsste man da dann den RX-Pin über eine Zeitspanne von 11(?) Schrittlängen (=11/4800 Sekunden) überwachen, ob da in der Zwischenzeit kein Start-Bit den Bus heruntergezogen hat.

@miwi: Ein NACK gibt es nur als Antwort auf ein SET, denn dies scheint der einzige Telegramm-Typ zu sein, der eine Antwort hervorruft (PPS ist da anders).

[loetmeister]

Wie gesagt, grundsätzlich ist das im Code wohl so angelegt, aber die Schleifen gehen eben byte- und nicht bitweise durch die zu sendende Message, und wenn dann ein ganzes Byte an die write Funktion übergeben wird, die selber wiederum nichts anderes macht, als ungestört dieses Byte bitweise auf den Bus zu geben, dann bringt das ja nichts. Im Anschluss daran wird dann zwar der RX-Pin überprüft, aber das sagt mir ja nichts, wenn sich bei den 10 zuvor gesendeten Bits ein etwaig anderes Gerät schon wieder zurückgezogen hat. Oder habe ich da jetzt was übersehen/missverstanden?

Ein Warten bringt ja auch nur bedingt was, denn auch da kann es ja sein, dass genau in dem Moment ein anderes Gerät anfängt zu senden. Auch in dem Fall würden meine 11 Bit (Start+8+Parity+Stop) ja unabhängig davon auf den Bus gehen, bis ich etwaig etwas erkennen würde, oder? Wenn etwas an Daten eingeht und GetMessage das erkennt, wird ja sowieso so lange gelesen, bis das Telegramm vollständig empfangen ist. Da der Arduino so lange eh' nichts anderes macht, hat man dadurch schon eine sichere zeitliche Distanz zu einem vorhergehenden Telegramm.

Ich würde bei dem Byte weisen Ansatz bleiben. Ob ein bit oder ein Byte die Übertragung für andere Teilnehmer gestört hat wäre ja erst mal nicht so entscheidend... in jedem Fall gilt ja dann eine Wartezeit (+Zufallsanteil) für alle Teilnehmer, welche größer als die Sendezeit eines Bytes sein müsste.. habe auf die Schnelle nicht die BSB Spezifikation gefunden - aber das nehme ich mal stark an (Stichwort DIFS, EIFS)

Wenn nicht nötig, dann würde ich de Teil mit dem RX Pin Pegel prüfen weglassen, stattdessen ein "lastReceive" Timestamp bei jeder Aktivität auf dem Bus aktualisieren... das solle mit passender Wartezeit doch ausreichen festzustellen ob der Bus frei ist. (unterschiedlich für BSB/PPS/LPB?)

Eventuell lässt sich hier was von brauchen?
https://github.com/MichaelJonker/HardwareSerialRS485/blob/master/src/utility/HardwareSerialRS485_Enabled.h#L623

Gruß,
Thomas

[sust]

@freetz: Also die Kollisionsprüfung über 11/4800 macht schon Sinn aber nur vor der Sendung.
Nur wenn 3msec ständig alles auf dem bus  frei ist darf man senden.
Damit dürfte niemand die laufende Sendung "stören". --Warum dann der 2. Check?
Und selbst wenn der Fall der Kollision eintritt, was bringt die Erkenntnis das da jemand sendet? Evtl.100mSec Zeitgewinn. --Dafür der Aufwand?
Und kann man wenn man das weiß noch was retten? --Wenn denn nur über CRC16--Das geht aber  mit einem Abbruchtelegramm auf keinen Fall.
Wenn schon kein Kollisionstest nach Sendungsbeginn erfolgt, wie stellt man dann Fehler fest? --Dafür hat ja jedes Telegramm die CRC16  Prüfsumme. Da fällt es auf.

Für mich spricht alles für einen Check nur vor dem senden, und der ist ja so schon vorhanden.
Der 2.Test zwar auch, der bringt aber eigentlich nichts.....

Hast du dir mal den Urahn vom jetzigen BSB_Lan angesehen? (BSB_Lan05-ss.ino+BSB.cpp  vom Forumsmitglied frank)
Die Kollisionsprüfung zu Anfang und während der Sendung ist da schon enthalten. Evtl. hat frank ja noch was zu dem Thema und ist über PM für dich zu erreichen.

Gruß sust

[freetz]

@sust: Danke, das klingt sinnvoll, dann würde ich die jetzige Prüfung auf den RX-Pin von einer Momentaufnahme auf 11/4800s ausdehnen und wenn der Bus frei bleibt, senden. Während des Sendens noch weiter zu überprüfen macht in meinen Augen auch keinen Sinn, dann ist halt das Telegramm inkonsistent und das wird dann durch die Prüfsumme auffallen, wie Du schon sagst.

@loetmeister: Ich verstehe noch nicht so ganz, was ein Timestamp bringen sollte, denn bei den meist mindestens drei Busteilnehmern, die alle theoretisch senden (Heizung, Display-Einheit, BSB-LAN), bringt mir die Info, dass vor X ms das letzte Telegramm gesendet wurde, ja keine Sicherheit darüber, dass nicht auch noch eines der anderen Geräte dann senden will und dann habe ich trotzdem die Kollision. Oder habe ich das missverstanden?

[freetz]

Habe mir die Software von frank angesehen, das ist die Grundlage, auf der Gero dann weitergemacht hatte und die im Prinzip auch jetzt noch im Code enthalten ist. Aber wie gesagt mit dem gleichen Problem, dass nur einmalig auf den Bus geschaut wird, ob der "high" ist (was aber eben auch während einer Datenübertragung der Fall sein kann). Dann wird auch nicht bitweise, sondern byteweise gesendet.

[Mike_pa]

Die Überprüfung auf Kollision während der Sendung bringt einen kleinen Zeitgewinn, weil das Telegramm nicht mehr zu Ende gesendet wird, bei kurzen Telegrammen sicher entbehrlich. Bei bitsynchronen Übertragungen macht das Sinn bitweise auf Kollision zu prüfen, da sich hier der Teilnehmer durchsetzt, dessen Telegramm zum Zeitpunkt der Kollision den dominierende Pegel sendet. Dieses Telegramm wird richtig zu Ende gesendet. Der Teilnehmer, dessen Telegramm den nicht dominierenden Pegel sendet, erkennt die Kollision und bricht ab. Ich würde hier auch auf die Kollisionsprüfung während der Sendung verzichten, wenn es mit größerem Aufwand verbunden ist.

[loetmeister]

@loetmeister: Ich verstehe noch nicht so ganz, was ein Timestamp bringen sollte, denn bei den meist mindestens drei Busteilnehmern, die alle theoretisch senden (Heizung, Display-Einheit, BSB-LAN), bringt mir die Info, dass vor X ms das letzte Telegramm gesendet wurde, ja keine Sicherheit darüber, dass nicht auch noch eines der anderen Geräte dann senden will und dann habe ich trotzdem die Kollision. Oder habe ich das missverstanden?

Das war nur als Alternative zum RX Pin "fühlen" gedacht... damit hier nicht die CPU blockiert wird (einer Momentaufnahme auf 11/4800s ausdehnen oder now - lastReceiveTimeStamp >= 3 ms)
Ja, zur Kollisionserkennung hilft das nicht.

Gruß,
Thomas

[freetz]

Prima, danke Euch beiden - dann ist der momentane Code doch ausreichend, denn dort wir vor dem Senden über eine Dauer von 26 bis 85 ms gewartet, ob der Bus belegt wird. Wenn bis dahin Ruhe ist, sendet BSB-LAN. Ich würde jetzt noch eine Überprüfung einbauen, um zu schauen, ob das gesendete Byte dem sofort darauf empfangenen entspricht. Wenn nicht, dann ist es so oder so zu einer Störung gekommen und das Telegramm wird nach einer weiteren Pause noch mal gesendet. Das sollte ein relativ "soziales" Verhalten bei gleichzeitiger Stabilität bedeuten.

Danke noch mal für Euren Input!

[Luposoft]

@Schotty
bist du mit deiner Handbuchumstellung eigentlich schon so weit, das es sich lohnt, den Link 'URL-Befehle' anzupassen?
Aktuell kommt man damit ins Kapitel 8 'Einbindung mittels zusätzlicher Software'

[Schotty]

Meinst du den Link im Webinterface von BSB-LAN, also der Button oben? Das ist eigtl schon geschehen, müsstest dazu aber updaten.
Oder meinst du bei dir aufm Rechner?
So oder so: Ja, die grundsätzliche Umstellung/Umstrukturierung ist soweit abgeschlossen - kann aber sein, dass ich hier und da noch einen internen Link übersehen habe (in dem Fall wie immer gerne melden )..