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

[freetz]

Also, es muss einmal ein Schreibvorgang ausgelöst werden (ein SET Telegramm muss im SerMo auftauchen). Aber es kann der bereit eingestellte Wert geschrieben werden (außer die Einheit ignoriert dann den Schreibbefehl, weil sie denkt, es ist ja der gleiche Wert, das kann ich aus der Ferne nicht sagen).

[FunkOdyssey]

Ein paar Fragen:

1)
Wie ist das Thema mit dem verdrehtem Transistor beim V3 eigentlich ausgegangen?
Ich habe gerade noch einmal alles gelesen und sehe keine wirkliche Antwort.
Soll der Transistor nun gedreht werden? Sind dann zusätzliche Widerstände nötig?
Sollte nicht ein Hinweis aufgenommen werden? Wo?

2)
Ich finde es hier im Thread nicht wieder und vielleicht wurde auch an anderer Stelle darüber diskutiert:
Wurde nicht neulich über das Reset-Problem beim Due gesprochen? Das nach der Stromversorgung der Reset-Button gedrückt werden muss? Wo stand das? Ich finde es nicht mehr.

Vielen Dank.

[freetz]

Der Transistor ist auf der Platine falsch herum eingezeichnet, das wird im nächsten Batch behoben. Bis dahin informiere ich die Leute, die bei mir bestellen, dass der BC557 gedreht werden muss, falls sie nicht eh' eine fertige Platine nehmen. Der Schaltplan ist korrekt, insofern muss da auch nichts geändert werden.

Von einem Reset-Problem weiß ich nichts (mehr).

[freetz]

Mir fällt gerade auf, dass wir auf der letzten Seite die 5000er-Marke der Beiträge erreicht haben und über eine halbe Millionen Treffer auf diesen Thread gingen - dafür an dieser Stelle einmal ein Danke an alle, die sich in dieses Projekt mit Ideen, Hinweisen und Fragen eingebracht haben, ich freue mich auf die nächsten 5000 !

[Schotty]

Wie ist das Thema mit dem verdrehtem Transistor beim V3 eigentlich ausgegangen?
Ich habe gerade noch einmal alles gelesen und sehe keine wirkliche Antwort.
Soll der Transistor nun gedreht werden? Sind dann zusätzliche Widerstände nötig?
Sollte nicht ein Hinweis aufgenommen werden? Wo?

Der verdrehte Transistor betrifft m.W. die Plative v4, die freetz in seinem Repo abgebildet hat - v3 ist davon nicht betroffen.
(FYI: Abbildungen und Schaltplan im Handbuch sind noch von v3; v4 stelle ich erst ein, wenn freetz ein neues Foto von der korrigierten Platine hat und mir grünes Licht gibt.)

[sust]

Moin,

Wow, 500 000 Treffer auf diesen Thread... Na dann versuchen wir mal es ein ein paar mehr werden zu lassen.

Kennt ihr diese Internetseite?

Code Auswählen Erweitern

https://www.gammon.com.au/forum/bbshowpost.php?id=11504&page=2

Da beschreibt Nick Gammon einen Weg aus der  Quartzfrequenz 16MHz des  Arduino ein um 2 geteiltes Signal an einem erreichbaren Pin des Mega bereitzustellen. Das wirklich Interesannte dabei ist, das dies allein über ein Hardwarsetup realisiert wird, Programmlaufzeit wird nicht benötigt.

An die am Quarz erstocherten  Quartz Frequenzwerte von mir glaubte ich zu dem Zeitpunkt  nicht mehr so recht.
Dieses bereitgestellte Signal beinhaltet ja aber noch die Quartzfrequenzfehler, also warum nicht zum messen benutzen.?
Das hab ich dann gemacht und siehe da mein Mega liegt 200 KHz zu tief. Und die Messung war auch reproduzierbar...

Wie man sieht besteht das Programm nur aus wenigen Zeilen Konfiguration und Setup.
Insofern hab ich es gewagt den Mega + die BSB_lan Software V0.44 damit zu belasten und die paar Zeilen im Code ergänzt. Funktioniert gut. Null Probleme dadurch.

Ehrlicherweise muss ich sagen, das ich das Ganze seit Februar nur 2 mal im praktischen benutzt hab ..

Aber wenns nichts kostet, kein Brot frisst und kein Wasser säuft, nur die nichtbenötigte(?) Hardwareresource Timer 1 wird benutzt..... Warum denn nicht. Irgendwann braucht mans und dann ist es da.

Vorgesehen hat der Autor Nick Gammon das nur für die kleinen Atmel (Uno,Nano, Micro) und dem 2560 Mega. Obs beim Due auch gehen würde, ich habs nicht angepasst/getestet.

Und noch eins: Ich hab mir die  beiden am Nano möglichen  Varianten   mittels Oszi angeschaut: Das gebufferte 16MHz Signal enthält einen Gleichspannungsanteil und der Pegel erreicht auch nicht gerade tolle Werte .Somit muss das  Ganze  für eine digitale Nutzung nachbearbeitet werden.
Das 8 MHz Signal nach der von Nick Gammon beschriebenen Methode ist absolut digitaltauglich. Sauberer  Rechteck, Pegel gut..

Ich kanns nur empfehlen, auch wenn man das nicht gerade täglich braucht.
Und: Copy & paste Kenntnisse reichen völlig aus, um der V0.44 das beizubringen.

Gruß sust

[freetz]

Danke, @sust, das ist für manche sicher interessant und kann ja über die _custom.h individuell eingebunden werden.

Was das Suchen nach den Flags für die SET Parameter angeht, kann man das auch mit Parametern machen, die es nur in BSB-LAN gibt, aber nicht an der Heizung.
Dazu muss man den dritten Wert in der Tabelle "optbl[]" (beginnt z.Z. etwa in Zeile 510 in der _defs.h) in der jeweiligen Zeile von "0" auf entweder "1" oder "6" ändern und einen Wert über BSB-LAN schreiben. Einer der beiden wird dann im Seriellen Monitor ein "ACK"-Telegramm als Antwort auf das "SET"-Telegramm erzeugen. Das ist dann der richtige Wert. Wenn ein NACK kommt, muss man es mit dem jeweils anderen Wert noch einmal probieren.
Bitte dann das SET/ACK Telegramm hier posten.

Hier noch mal der Link zur inzwischen um die gefundenen bereinigte Liste:
https://forum.fhem.de/index.php/topic,29762.msg1108593.html#msg1108593

[sust]

Moin Freetz,

Du schreibst

Danke, @sust, das ist für manche sicher interessant und kann ja über die _custom.h individuell eingebunden werden.

Nur zum einbinden in der custom.h gibst doch gar keinen  loop-Part?

Wenn du die custom_setup.h meinst, das könnte man bedenken. Ist Besonders dann wichtig , wenn man nach einiger Zeit ein update ausführen will.
Nur werd ich das bei der V0.44 wohl kaum noch machen. Insofern ist es mir egal ob ich die ino,config.h oder custom_setup.h benutze.

Ansonsten ist deine  Botschaft klar, es bleibt für sowas beim individuellen do it yourself.
Ich hab das ja schon so gemacht,  andere könnens ja so auch machen.
Ok, ich mach denn mal nen Haken an dem Thema dran und schließ das Ganze ab.

Gruß sust

[freetz]

Nur zum einbinden in der custom.h gibst doch gar keinen  loop-Part?

Doch, die _custom.h wird während des Loops ausgeführt. Die _custom_setup.h während der setup()-Funktion und in der _custom_global.h kann man globale Einstellungen vornehmen. Insofern kann man eigentlich fast alle Zusatzfunktionen darüber einbinden und vor'm Überschreiben durch ein Update schützen.

Vielleicht habe ich den Sinn dieser Frequenz-Funktion noch nicht ganz verstanden, aber einen direkten Bezug zu Heizungs- bzw. Heimautomationsfunktionen habe ich jetzt nicht gesehen. Deswegen wäre mein Vorschlag, es über die besagten _custom-Dateien einzubinden. Dann könntest Du diese Dateien hier posten und andere könnten es dann 1:1 übernehmen.
Wenn es doch einen Heizungs-Bezug gibt, könnte Schotty das dann auch zu den anderen Beispielen ins Handbuch mit übernehmen. Für eine dauerhafte Integration in den Hauptcode sehe ich aber wie gesagt den Nutzen für eine signifikante Nutzerschaft (noch) nicht.

[freetz]

Denn wenn man sich den Programmschnipsel im BSB_Lan anschaut und mit dem Programmschnipsel für den case VT_DATETIME vergleicht, stellt man fest, das die Telegrammlänge und Position von Kalendertag und Kalendermonat identisch sind.
Gibt es noch mehr verwendbare "Steuerbytes" außer 0 (VT_DATETIME), 16(VT_SUMMERPERIOD) und 17 (VT_VACATIONPROG)?

Ich habe jetzt erst Zeit gehabt, mich dem mal genauer zu widmen, das ist schon eine interessante Erkenntnis. Vermutlich verwendet Siemens nicht drei verschiedene Datentypen, wie wir, sondern eben einen Datentyp, der sich nur über das letzte Byte in der Payload in der Verwendung ausdifferenziert.
Interessant wäre mal zu testen, ob VT_SUMMERTIME zwingend 0xFF für die Leerstellen benötigt oder ob da auch 0x00 akzeptiert werden (oder umgekehrt). Dann könnte man die drei Funktionen zumindest im Programmablauf konsolidieren, bzw. für die Auslesen ist das bei VT_SUMMERPERIOD und VT_VACATIONPROG auch schon der Fall.

[sust]

Moin Freetz,

Ja, das in der custom_setup.h aufzunehmen ist eine gute Idee. Wäre dann ja ein 2. Beispiel für "custom" Fälle?
Bevor man das aber tun kann, müsste sich jemand auf der Due Plattform anschauen ob die Verhältnisse so sind wie beim Mega und Nano.
Wenn das keiner tut, gibt es nichts als Beispiel für das custom_setup.h zum übernehmen. Insofern abwarten ...Wenn sich nichts tut , Haken an die Sache und gut is. 

Mit dem fehlenden loop-Part meinte ich den im Gammon Vorschlag fehlenden loop. Man hat einfach nichts was man in der custom.h als loop eintragen könnte.


Was VT_SUMMERPERIOD/VT_DATETIME und das auffüllen der nichtbenötigten Stellen im payload angeht, scheint das egal zu sein was da steht: ein komplettes Datum von Jahr bis zur Sekunde mit 16 zum Abschluß führte bei mir nur zu einer Änderung des Tages und des Monats.
Interessant ist aber die Benutzung  von einem FF Telegramm (alle Stellen von Jahr bis Sekunde) trotzdem: mit 0 am Ende landet man im  Jahr 2099.. Mit 16 beamt man sich nur zum 31.12..... 

Gruß sust

[Schotty]

@sust: Also ich kann das bei Bedarf gerne mal auf dem Due testen, bräuchte allerdings dann wirklich den Codeschnipsel so, wie man es hinterher auch 'anbieten' könnte, also als Datei für die custom_irgendwas. Da selber irgendwo im BSB-LAN-Code rumzupfuschen möchte ich lieber vermeiden

Verständnisfrage: Wozu braucht man diese Funktion und wie ruft man dann das Ergebnis ab?

Als ich deinen Beitrag das erste Mal gelesen habe, kam mir die Problematik von freetz und seinem einen Problem-Clone wieder in den Sinn, damals zickte einer bei Verwendung mit LPB rum. Ob es unterm Strich wirklich der Clone oder doch ein Hardware-Problem beim Adapter(?) war, weiß ich nicht mehr. Aber damals war uns aufgefallen, dass auf dem Problemclone ein 12MHz Quarz verbaut war, und kein 16MHz. Ich habe gerade lange gesucht und es endlich gefunden - ist fast genau 2 Jahre her: https://forum.fhem.de/index.php/topic,29762.msg876250.html#msg876250

Passt das mit dem Code-Test zusammen, ob da dann am Ende wirklich 16MHz vorliegen, oder ist das was komplett anderes..? 

Der Due läuft ja mit 84MHz, allerdings scheinen die aus 16MHz 'gemacht' zu werden: https://forum.arduino.cc/index.php?topic=656268.msg4421913#msg4421913

[freetz]

User @konne ist auf ein sehr interessantes Dokument gestoßen, das endlich bestimmte Annahmen unseres reverse engineerings bestätigt:
https://polo.broetje.de/pdf/7715040=6=pdf_(bdr_a4_manual)=de-de_ma_modbm.pdf
Insbesondere Tabelle 9.6 ist dabei interessant, da es die Status-Bytes aufschlüsselt, die wir bisher für die Brennerlaufzeit nur vermutet haben. Sehr schön dabei ist, dass es in diesem Broadcast-Telegramm auch noch andere interessante Infos gibt, insbesondere ein allgemeines Fehler-Bit, das quasi die Glocke im Display erscheinen lässt. Dieses könnte man nun mit auswerten und (wenn wir z.B. Luposofts MQTT-Broker umgesetzt haben) zur externen Alarmierung verwenden. Dann muss man nicht immer die Fehlerkategorien abfragen und auf Veränderungen überprüfen etc., sondern weiß, dass sich die Anlage momentan in einem Fehlerzustand befindet.

Zur besseren Anzeige muss dafür noch ein neuer Datentyp angelegt und auswertbar gemacht werden (VT_CUSTOM_BIT). Dann müsste noch herausgefunden werden, wofür insbesondere Bit 3 steht, das in der Anleitung etwas kryptisch mit "Direct display of info display" beschrieben wurde. Aber dann wäre das sicher eine sehr hilfreiche Informationsquelle...

[sust]

Moin Schotty,

Du fragtest:

Verständnisfrage: Wozu braucht man diese Funktion und wie ruft man dann das Ergebnis ab?

Wenn die Frage die custom Sache betrifft: Die Stellt die Quarzfrequenz/2 an einem erreichbaren Pin des Mega zur Verfügung.
Es ist eine reine Hardwaregeschichte die nicht durch BSB_ lan abgefragt werden kann.
Alle anderen mir bekannten Messverfahren führten zu falschen Messergebnissen bei mir. Deshalb berichte ich hier von meinen Erfahrungen.

Du fragtest:

@sust: Also ich kann das bei Bedarf gerne mal auf dem Due testen, bräuchte allerdings dann wirklich den Codeschnipsel so, wie man es hinterher auch 'anbieten' könnte, also als Datei für die custom_irgendwas.

Ich lebe noch in der Mega 2560 Umgebung mit der V0.44. Ein geprüftes Programm für den DUE kann ich nicht erstellen.
Das müsste jemand der einen DUE hat erstellen.
Ich würde aber zu diesem Zeitpunkt erstmal prüfen, ob der DUE nicht die Quartzfrequenz geteilt oder vervielfacht an einem erreichbaren Pin zur Verfügung stellt.
Und mit einem Oszi checken ob das Signal ok ist. Nur wenn das nicht ok oder nicht erreichbar ist muss sich um den Code Gedanken machen.

Du hast angemerkt:

....damals war uns aufgefallen, dass auf dem Problemclone ein 12MHz Quarz verbaut war, und kein 16MHz. Ich habe gerade lange gesucht und es endlich gefunden - ist fast genau 2 Jahre her: https://forum.fhem.de/index.php/topic,29762.msg876250.html#msg876250

Da hat sich Freetz, genau wie ich damals auch, verguckt, der 12MHz Quartz gehört zum USB chip und nicht zum Prozessor. Ein paar Beiträge weiter unten schreibt freetz das auch.

Du erwähnst weiter:

Als ich deinen Beitrag das erste Mal gelesen habe, kam mir die Problematik von freetz und seinem einen Problem-Clone wieder in den Sinn, damals zickte einer bei Verwendung mit LPB rum. Ob es unterm Strich wirklich der Clone oder doch ein Hardware-Problem beim Adapter(?) war, weiß ich nicht mehr.

Wenn ich das lese, stell ich mir sofort die Frage "könnte das ein Frequenzproblem mit dem UART sein?" zumindest nach den Erfahrungen die ich beim Erreichbarkeitsproblem  meines Bediengerätes gesammelt hatte.
Ob man die Frage nach dem Frequenzproblem bejahen oder verneinen kann, ist einem erst dann möglich wenn man die Frequenzabweichungen auf einer Seite(dem 1. UART einer Verbindung) zumindest in etwa feststellen kann. Und dann zur anderen Seite(dem 2.UART der verbindung) einen Vergleich ziehen kann.
Erst als ich mir im klaren über den Frequenzfehler der eigenen UART Frequenz des BSB_Lan war, konnte ich Rückschlüsse auf das "Frequenzverhalten" des Bediengerätes bei mir ziehen.
Denn das war bei mir nicht zu erreichen gewesen vom BSB_Lan aus.
Man kann sich darüber streiten ob das Bedienegrät wirklich der Erforschung bedarf, ich konnte mir aber zumindest daran einige Fallstricke die es bei UARTs gibt klarmachen und etwas rätselhaftes entschleiern.
Die Lektüre des Kapitels UART im Datenblatt des Mega 2560 war dabei sehr,sehr aufschlußreich und hifreich gewesen. Bitte lesen-empfehlenswert.

Ich halte  es für sinnvoll sich bei Problemen auch mit den Frequenzabweichung vom eigenen Prozessor Quartz zu beschäftigen . Denn das UART hängt durch einen festen Teiler direkt davon ab.
Also messen und das möglichst genau....dann Rückschlüsse und Konsequenzen  daraus ziehen...und sich dann freuen, das man den Quark der Messmöglichkeit dann eigentlich nicht mehr braucht.

Aber bitte denkt auch an diejenigen, die erst nach euch neu beginnen und auf rätselhaftes stossen. Nachmessen an guten, stabilen Meßpunkten hilft denen evtl. sehr.
Muss man sich das sonst erst z. B. durch herumstochern am Quartz selbst ermitteln, kann es schiefgehen wie bei mir. Mit der Lösung für den Mega von Nick Gammon hätte ich das leichter gehabt.

Wenn die Lösung nichts kostet, nichts braucht, nicht stört, ist es eigentlich egal wie oft man sie braucht und ob sie sonst die meiste Zeit nur nutzlos ist.

Aber bitte meine Betrachtung fusst allein auf den Mega, was davon überhaupt für den DUE sinnvoll ist muss noch ermittelt werden. Mangels Due kann ich das nicht.


Weiter fragst du:

Passt das mit dem Code-Test zusammen, ob da dann am Ende wirklich 16MHz vorliegen, oder ist das was komplett anderes..?

Da weiss ich nicht so recht was du meinst. Wenn du damit den Einfluss des Fehlers des 16 MHZ Quartzes auf die UART Frequenz meinst: wie weiter oben schon gesagt, ist der Quartzfehler  pronzentual  exakt auch so am UART vorhanden. Ausnahme: der Fehler durch den nicht anders  möglichen Teilers verstärkt sich mit dem Toleranzfehler des Quartzes .oder hebt sich ganz/teilweise mit ihm auf.
Der Due wäre durch einen Systemtakt von 84Mhz hier erheblich im Vorteil gegenüber dem Mega oder Nano.

Gruß sust

[Schotty]

Moin sust,

danke für deine Ausführungen.
Meine Frage nach dem Verwendungszweck dieser Funktion bezog sich eigtl darauf, was man hinterher damit macht - die ermittelte Frequenz an einem Pin ausgeben lassen und dort mit einem Oszi nachmessen, ob die Frequenz des Ardu passt?

Was alles Weitere angeht, so werde ich da mangels Wissen leider nicht wirklich weiterhelfen können. Programmiertechnisch sowieso nicht, hardwaremäßig in diesem Fall auch nicht. Ich habe mir zwar letztes Jahr mal so ein kleines 30€-Oszi gekauft, habe es aber noch nicht benutzt, da ich mich bisher leider noch nicht wirklich damit auseinandergesetzt habe, wie man das richtig benutzt.. 

Gruß