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

[Schotty]

Nur mal so interessehalber: Ich dachte bisher immer, man kann BSB-LAN-seitig nur in EINEM Intervall die gewünschten Parameter via MQTT senden lassen, nämlich in dem definierten Log-Intervall, was dann aber eben für alle 'Logging'-Werte gilt. Habe ich da etwas verpasst..? 
..oder 'holst' du die Werte irgendwie FHEM-seitig via MQTT in unterschiedlichen Intervallen von BSB-LAN ab?

[Luposoft]

Hallo Schotty,

nein, da hast du nichts verpasst. Ich habe ein eigenes custom-Modul zu laufen.
Damit werden ohne Fhem in Anspruch zu nehmen, diverse Werte in frei definierbaren Intervallen, aber auch nur bei Änderung von Werten via MQTT an Fhem gesendet. Das ist für jeden Wert individuell einstellbar.

Das ganze gehört zu meinem Versuch, den Gasverbrauch zu berechnen.
Wenn ich soweit bin, wollte ich das ganze natürlich hier präsentieren.
Da du gefragt hast, im Anhang ist die aktuelle Version meiner custom-Files schon mal vorab.

[Schotty]

Ah ok, dann bin ich ja 'beruhigt' 
Klingt prinzipiell interessant (danke für die files, aber als Nicht-Programmierer verstehe ich da nicht viel von ) und könnte ja generell eine interessante Erweiterung von BSB-LAN sein, wenn man per se unterschiedliche Log-/Sendeintervalle für die Parameter einrichten könnte. Aber das ist was für freetz, davon habe ich keine Ahnung - ich teste und dokumentiere das dann nur 

[freetz]

Ja, die interne Uhr des Arduino ist nicht wirklich genau - pro Tag mindestens mehrere Sekunden, wenn ich mich recht erinnere, wenn nicht sogar noch mehr. Das ist der Grund, warum ich periodisch die Uhrzeit der Therme abfrage und damit die interne Uhr neu setze...

[freetz]

@marcodto: I have now added the parameters for your heater, updated version is on GitHub.

[Luposoft]

@freetz

Ja, die interne Uhr des Arduino ist nicht wirklich genau - pro Tag mindestens mehrere Sekunden, wenn ich mich recht erinnere, wenn nicht sogar noch mehr. Das ist der Grund, warum ich periodisch die Uhrzeit der Therme abfrage und damit die interne Uhr neu setze...

Genau daher meine Frage. Ich spreche nicht von Sekunden pro Tag sondern hochgerechnet von ca. 4 Stunden!
Das kann doch nicht sein, oder?
Und nochmal. Mir gehts um die Differenz der millis() zu der Differenz der Zeitstempel im Fhem-Log der zugehörigen MQTT-Daten.

Du stellst die Uhr des Arduino periodisch. Die hat doch aber keinen Einfluss auf den Programmablauf, geschweige auf die Zeitsteuerung, oder?

Kommen denn deine MQTT-Anforderungen in den Intervallen in Fhem an, wie von dir vorgegeben?

[freetz]

Wie gesagt, ich weiß nicht mehr, wie stark die Differenz war, aber die hängt natürlich vom der Taktfrequenz des Quarzed bzw. Oszillators ab. Wenn die vom Ideal abweicht, wird natürlich auch die millis()-Berechnung fehlerhaft. Sprich, wenn 60000 Millisekunden abgelaufen sind, ist das für den Arduino eine Minute, kann aber für FHEM auch 1:10 Minuten sein, was sich dann natürlich in den entsprechenden Timestamps niederschlägt.

Intervalle berechne ich grundsätzlich nur auf Basis von millis(), denn nur die habe ich auf jedem Arduino und jeder Heizung zur Verfügung.

Was die MQTT-Frage angeht, kann ich die nicht beantworten, weil ich kein MQTT verwende. Macht bei FHEM auch wenig Sinn, denn da hole ich mir die Daten, die ich will, in den Intervallen über HTTPMOD ab, wie ich sie brauche und kann die dann auch gleich richtig verarbeiten...

[Luposoft]

So unterschiedlich kann man das betrachten.

Denn für mich macht das sogar großen Sinn, ich brauche zum Beispiel die exakten Ein-und Ausschaltzeiten der Heizung.
Ohne dem macht eine Energieerfassung keinen Sinn.
Der Arduino sendet mir dieses Ereignis, ohne Fhem zu beanspruchen.

Mit HTTPMOD habe ich bei zu häufigem Abfragen sehr häufig timeout bekommen.
Ich benutze HTTPMOD daher so gut wie garnicht.

Meine Frage nach der Zeitdifferenz lief letzendlich darauf hinaus, dass ich einen Fehler im Code vermute, da wärst du der einzige gewesen, der mir hätte weiterhelfen können.

Ich werde mit separatem schmalen Sketch meine Arduino-Zeit testen. Mal sehen ob da die Differenz bestätigt wird.

[freetz]

Den Timeout kannst Du in der Konfiguration des HTTPMOD-Devices erhöhen, das macht auch Sinn, weil der Arduino (zumindest der Mega) oft nicht fix genug für die Default-Einstellungen war. Bei mir gibt es da seit Jahren keine Probleme, von kleinen Aussetzern hier und da mal abgesehen, deren Ursache ich aber nicht eindeutig auf HTTPMOD zurückführen kann.

[Schotty]

Bzgl der abweichenden Uhrzeit: Könnte da ein RTC-Modul evtl Abhilfe schaffen?
Bzw: Der DUE scheint RTC im SAM-Chip integriert zu haben: https://www.arduino.cc/reference/en/libraries/rtcdue/ (was allerdings bei einem Stromausfall nicht viel zu nützen scheint: https://forum.arduino.cc/index.php?topic=363041.msg2502867#msg2502867)
..nur so ein Gedanke eines Unwissenden.. 

[freetz]

Interessant, das wusste ich nicht  - dann müsste die interne Uhr auf dem Due exakt sein, das wäre dann auch bei den millis() zu sehen. Die Library ist nur nötig, wenn man daraus eine "richtige" Zeit ableiten will, aber das brauchen wir ja nicht für die Intervalle...

[Schotty]

[..] dann müsste die interne Uhr auf dem Due exakt sein [..] Die Library ist nur nötig, wenn man daraus eine "richtige" Zeit ableiten will [..]

Noch besser! 

[Luposoft]

Hallo liebe Leute,

hab jetzt meinen Arduino mit ganz kleinem Programm getestet.
(Alle 10000ms ein Serial.Print ...)
Da haut alles hin , heißt die Zeiten gehen nicht auseinander.

Dann hab ich mal mein custom-Code deaktiviert. Und da sehen die Zeiten viel besser aus.

Meine Vermutung:
In meinem custom-Code wird viel häufiger mit MQTT connected und disconnectet als in der Hauptroutine.
Dabei bleiben wohl die millis() auf der Strecke.
Das werde ich mal weiteruntersuchen...

[freetz]

Seltsam, die millis() bleiben dann "stehen", wenn die Interrupts deaktiviert werden. Keine Ahnung, ob/warum das bei MQTT- bzw. Netzwerkverbindungen der Fall ist, aber wenn Du das Problem darauf zurückführen konntest, wird es wohl daran liegen.

[Luposoft]

@freetz
Noch ist es meine Vermutung.
Frage: hat der MQTT-disconnect nach Abfrage aller Parameter einen tiefen Sinn.
Anders gefragt, kann der Versuch, MQTT offen zu lassen erfolgreich sein?

Einen Versuch wird es wert sein, oder?