Support: Manuell + Berechnung

[zut]

Danke für den Hinweis zum Schreibverhalten der Datenbank.
Das Löschen der mosquitto-Datenbank hat nichts gebracht. Heute nacht wieder:

Code: Alles auswählen

Sep 25 03:04:52 openWB/set/lp/1/manualSoc 84
Sep 25 03:04:52 openWB/set/lp/1/manualSoc (null)

Frisch die mosquitto-Datenbank kopiert und einem frisch übersetzten mosquitto_db_dump vorgeworfen:

Code: Alles auswählen

zut@hagen:~/mosquitto/apps/db_dump$ ./mosquitto_db_dump ~/mosquitto.db | grep -5 manual
DB_CHUNK_MSG_STORE:
	Length: 111
	Store ID: 196307
	Source Port: 1883
	Source MID: 0
	Topic: openWB/lp/1/manualSoc
	QoS: 0
	Retain: 1
	Payload Length: 2
	Expiry Time: 0
	Payload: 84
Warning: Unsupported chunk "8" in persistent database file. Ignoring.

Der unsupported chunk ist auch wieder dabei. Puh.

[yankee]

Ja moment mal. Es sieht so ähnlich aus, ist aber natürlich nicht das selbe. Es geht um das Topic "openWB/set/lp/1/manualSoc" und NICHT um "openWB/lp/1/manualSoc". Letzteres ist natürlich "retained" und findet sich natürlich in der DB wieder.

Ich habe jetzt auch mal bei mir das Skript mosquitto_db_dump kompiliert und ausgeführt. Ich bekomme die Warnung die du hast nicht. "openWB/lp/2/manualSoc" ist bei mir korrekt in der DB enthalten und "openWB/set/lp/2/manualSoc" ist korrekt NICHT enthalten. Sofern es nicht an der "warning" liegt die du erhälst ist das auch bei dir offenbar so korrekt.

Was kommt denn bei dir rum, wenn du es mit der Cloud versuchst?

Code: Alles auswählen

mosquitto_sub -h web.openwb.de -p 1883 -t DEIN_NUTZERNAME/openWB/set/lp/1/manualSoc -v -P DEIN_PASSWORT -u DEIN_NUTZERNAME --capath /etc/ssl/certs

Das gleiche wie lokal oder ist irgendwas anders? Bekommst du sofort beim Verbinden eine Nachricht oder erst wenn du den SoC anpasst?

[zut]

Es ist korrekt, daß das "set"-Topic nicht in der Datenbank ist. Ich hatte die Vermutung, daß der gespeicherte Wert möglicherweise bei Erneuerung der Verbindung nochmal als "set"-Topic versendet wird.

Zu den Cloud-Versuchen:
Ich habe einen zusätzlichen Logger auf dem raspi auf die Cloud angesetzt. Beim ersten Kontakt kam unaufgefordert keine Message. Bei manuellem Verstellen bekommt er das gleiche mit wie der, der an der Wallbox direkt lauscht; mit etwas Latenz dazwischen (500ms?). Mir ist nicht ganz klar, wie das funktioniert - geht der Wert erst in die Cloud und kommt von da aus zurück? Wenn ja, wie? Fragt der lokale mqtt-broker als Brücke die Cloud ab und verteilt intern weiter? Eine Kontaktaufnahme von außen sollte wegen des Routers ja nicht möglich sein?

Code: Alles auswählen

pi@heizung:~ $ tail -f openwbset_remote.log 
Sep 25 20:41:20 abcd1234/openWB/set/lp/1/manualSoc (null)
Sep 25 20:41:20 abcd1234/openWB/set/lp/1/manualSoc 82
^C

Code: Alles auswählen

pi@heizung:~ $ cat openWBset.log 
[...]
Sep 25 20:41:20 openWB/set/lp/1/manualSoc 82
Sep 25 20:41:20 openWB/set/lp/1/manualSoc (null)

Ich lasse das mal die Nacht laufen und schau, was passiert.

[yankee]

Mir ist nicht ganz klar, wie das funktioniert - geht der Wert erst in die Cloud und kommt von da aus zurück? Wenn ja, wie? Fragt der lokale mqtt-broker als Brücke die Cloud ab und verteilt intern weiter? Eine Kontaktaufnahme von außen sollte wegen des Routers ja nicht möglich sein?

Der lokale Broker baut eine persistente Verbindung zum Cloud-Broker auf. Wenn du was an die Cloud schickst wird es an den lokalen Broker weitergeleitet und umgekehrt. Somit sollte es nahezu egal sein mit wem du dich verbindest, du müsstest immer den gleichen Effekt haben. Nur mit anderer Latenz.

Code: Alles auswählen

pi@heizung:~ $ tail -f openwbset_remote.log 
Sep 25 20:41:20 abcd1234/openWB/set/lp/1/manualSoc (null)
Sep 25 20:41:20 abcd1234/openWB/set/lp/1/manualSoc 82
^C

Falschrum. Es hätte 82 und DANN (null) kommen sollen und nicht so rum. Die leere Nachricht soll ja gerade die 82 raus löschen. So würde ich jetzt erwarten, dass wenn du dich mit dem Broker verbindest um das topic abzufragen, du sofort nach Verbindungsaufbau die 82 wieder entgegengeschleudert bekommst. Ist dem so?

[zut]

Falschrum. Es hätte 82 und DANN (null) kommen sollen und nicht so rum. Die leere Nachricht soll ja gerade die 82 raus löschen. So würde ich jetzt erwarten, dass wenn du dich mit dem Broker verbindest um das topic abzufragen, du sofort nach Verbindungsaufbau die 82 wieder entgegengeschleudert bekommst. Ist dem so?

Tatsächlich! Bei Start einer zusätzlichen Abfrage kommt:

Code: Alles auswählen

pi@heizung:~ $ mosquitto_sub -h web.openwb.de -p 1883 -t abcd1234/openWB/set/lp/1/manualSoc -v -P passwort -u abcd1234 --capath /etc/ssl/certs
abcd1234/openWB/set/lp/1/manualSoc 82
^C

Das funktioniert sogar mehrfach. Dann schiebt die Cloud nach dem DSL-Verbindungsaufbau, der dem Abbruch folgt das letzte set-Kommando also nochmal in die WB und setzt den SOC auf den letzten eingegebenen Wert. Warum macht die das? Wieso kommt die Null da nicht hinterher?

[yankee]

Dann schiebt die Cloud nach dem DSL-Verbindungsaufbau, der dem Abbruch folgt das letzte set-Kommando also nochmal in die WB und setzt den SOC auf den letzten eingegebenen Wert. Warum macht die das? Wieso kommt die Null da nicht hinterher?

Das ist in der Tat die Frage. Ein Problem könnte sein, dass die mqttsub.py mit QoS=0 sendet, aber das Webinterface mit QoS=2. Die Reihenfolge der Nachrichten ist dann nicht garantiert.

Versuch doch mal das QoS zu ändern. Also ersetze in der mqttsub.py das qos=0 durch qos=2:

Code: Alles auswählen

sed -i 's/\(client.publish(msg.topic, "", qos=\)0/\12/' runs/mqttsub.py

Und dann starte den mqtt-client neu:

Code: Alles auswählen

pkill -f '^python.*/mqttsub.py'
nohup python3 "runs/mqttsub.py" >> "ramdisk/openWB.log" 2>&1 &

Und dann schau mal ob das Abhilfe schafft.

[zut]

Ich will mir Deinen Vorschlag sehr gerne ansehen. Vorher noch, was sich heute Nacht ergeben hat. Die Cloud schickte folgendes:

Code: Alles auswählen

Sep 25 20:41:20 abcd1234/openWB/set/lp/1/manualSoc (null)
Sep 25 20:41:20 abcd1234/openWB/set/lp/1/manualSoc 82
Sep 26 03:03:29 abcd1234/openWB/set/lp/1/manualSoc 82
Sep 26 03:04:02 abcd1234/openWB/set/lp/1/manualSoc (null)
Sep 26 11:58:11 abcd1234/openWB/set/lp/1/manualSoc 76
Sep 26 11:58:12 abcd1234/openWB/set/lp/1/manualSoc (null)
Sep 26 11:58:12 abcd1234/openWB/set/lp/1/manualSoc 76
Sep 26 11:58:12 abcd1234/openWB/set/lp/1/manualSoc (null)

Am 25. war noch die falsche Reihenfolge zu sehen. Ohne daß ich etwas geändert hatte, war es dann nach der Verbindungstrennung erstmal richtig; die Null kam nach dem Wert. Das anschließende manuelle Setzen war auch wieder korrekt (die 76%).
Wenn ich jetzt neu auf die cloud subscribe und dann manuell einen SOC vorgebe, kommt es auch wieder richtig:

Code: Alles auswählen

pi@heizung:~ $ mosquitto_sub -h web.openwb.de -p 1883 -t abcd1234/openWB/set/lp/1/manualSoc -v -P passwort -u abcd1234 --capath /etc/ssl/certs
abcd1234/openWB/set/lp/1/manualSoc 76
abcd1234/openWB/set/lp/1/manualSoc (null)
^C

Ich werde heute nacht noch etwas laden und dann schauen, ob wieder ein Rücksetzer erfolgt. Die QoS-Anpassung am Code möchte ich erst danach durchführen.

[zut]

Heute Nacht um 3:36 Uhr Verbindungstrennung. Nach Wiederherstellung keinerlei Neuübertragung von set-Topics:

lokal:

Code: Alles auswählen

Sep 26 16:38:31 openWB/set/lp/1/manualSoc 76
Sep 26 16:38:31 openWB/set/lp/1/manualSoc (null)

und remote:

Code: Alles auswählen

Sep 26 16:38:32 abcd1234/openWB/set/lp/1/manualSoc 76
Sep 26 16:38:32 abcd1234/openWB/set/lp/1/manualSoc (null)

Auch ein Neuverbinden mit der Cloud hat keine set-Topics mehr für mich.

Anscheinend Spontanheilung der Cloud. Ein Abgleich des QoS wäre vermutlich trotzdem sinnvoll, aber ohne reproduzierbaren Fehler kann ich über die Wirksamkeit nichts sagen.

[yankee]

Anscheinend Spontanheilung der Cloud. Ein Abgleich des QoS wäre vermutlich trotzdem sinnvoll, aber ohne reproduzierbaren Fehler kann ich über die Wirksamkeit nichts sagen.

Du könntest ja mal sowas versuchen:

Code: Alles auswählen

while true; do mosquitto_pub --qos 2 --retain -t openWB/set/lp/1/manualSoc -m "85"; sleep 3; done

Währenddessen auf die Cloud subscriben und schauen was passiert. Ist die Reihenfolge immer korrekt? Oder immer oder manchmal falsch? Wenn letzteres könntest du versuchen den qos in der mqttsub.py wie von mir vorgeschlagen zu ändern um dann zu schauen ob es immer richtig ist.

Es könnte aber natürlich auch sein, dass es nur im Zusammenhang mit dem JavaScript-Client im Browser passiert, weil vielleicht irgend eine Latenz ein bißchen anders ist. Wenn sich der Fehler mit dem mosquitto_pub nicht reproduzieren lässt, wäre es nochmal einen Versuch wert, im Browser das Topic einige Male neu einzugeben.

[zut]

Moin, heute wieder etwas Gelegenheit, das Problem zu betrachten, nachdem heute früh wieder der SOC-Wert zurückgesetzt wurde:

lokale Nachrichten:

Code: Alles auswählen

Sep 26 16:38:31 openWB/set/lp/1/manualSoc 76
Sep 26 16:38:31 openWB/set/lp/1/manualSoc (null)
Sep 28 13:44:22 openWB/set/lp/1/manualSoc 65
Sep 28 13:44:22 openWB/set/lp/1/manualSoc (null)
Sep 29 03:34:19 openWB/set/lp/1/manualSoc 65
Sep 29 03:34:19 openWB/set/lp/1/manualSoc (null)
Sep 29 08:53:25 openWB/set/lp/1/manualSoc 64
Sep 29 08:53:25 openWB/set/lp/1/manualSoc (null)
Sep 30 03:33:04 openWB/set/lp/1/manualSoc 64
Sep 30 03:33:05 openWB/set/lp/1/manualSoc (null)

Remote:

Code: Alles auswählen

Sep 26 16:38:32 abcd1234/openWB/set/lp/1/manualSoc 76
Sep 26 16:38:32 abcd1234/openWB/set/lp/1/manualSoc (null)
Sep 28 13:44:23 abcd1234/openWB/set/lp/1/manualSoc (null)
Sep 28 13:44:23 abcd1234/openWB/set/lp/1/manualSoc 65
Sep 29 03:34:20 abcd1234/openWB/set/lp/1/manualSoc 65
Sep 29 03:34:22 abcd1234/openWB/set/lp/1/manualSoc (null)
Sep 29 08:53:25 abcd1234/openWB/set/lp/1/manualSoc (null)
Sep 29 08:53:25 abcd1234/openWB/set/lp/1/manualSoc 64

Die lokal empfangenen Nachrichten im Topic von 3:33 Uhr kamen von remote nicht an, vermutlich, weil das Haus offline war.

Beim manuellen Abonnieren der Cloud kommt diesmal keine (null) und keine Botschaft, die übrig geblieben wäre. Nach dem manuellen Eingeben von Werten kam die Nachricht einmal korrekt durch und zweimal nicht. Ein erneutes Abonnieren der Cloud kam der letzte Wert erneut vorbei, ohne folgende (null).

Die Übertragungen von / zur Cloud scheint hinreichend instabil zu sein, um die von @yankee vorgeschlagenen Änderungen auszuprobieren. Anscheinend kommen manchmal die (null)-Nachrichten vor den eigentlichen SOCs an?? Ich komme die nächsten Tage bestimmt mal dazu, den Code anzupassen.