Fehlerzähler (wallbox/meter/error_counters) inkrementiert regelmäßig

[michaelst]

Warum inkrementiert der Kommunikations-Fehlerzähler {"meter":195,"bricklet":0,"bricklet_reset":0} des Energiezähler regelmäßig?

Was ich nachstellen kann ist, dass wenn ich manuell, per MQTT ("wallbox/meter/reset"), die relative Energie lösche, der Zähler um 1 inkrementiert.
Es scheint aber auch bei der normalen Kommunikation, beim Auslesen der Werte, zu passieren. Einen Durchschnittswert, z.B. Fehler pro Tag oder
Stunde habe ich aber noch nicht aufgenommen.

Als SW-Entwickler für Embedded Geräte tue ich mich immer ein bischen schwer, wenn ich Fehler sehe.
Eine Kommunikation sollte eigentlich fehlerfrei funktionieren.

LG, Michael

[rtrbt]

Kommunikationsfehler mit dem Stromzähler treten in der Tat manchmal auf, sind aber nicht kritisch.

Um ein Gefühl für die Frequenz zu bekommen kannst du einen Blick ins Ereignis-Log werfen. Wenn du Glück hast, dann sind die Nachrichten vom Start noch erhalten, dann interessant ist eine Nachricht der Form

2022-05-13 15:24:42,264  NTP synchronized at 16,571!

Diese sagt z.B. dass die Wallbox am 13.05. um 15:24:26 gestartet ist (die Zeit hinten ist die Zeit seit dem die Box läuft in Sekunden).

Falls die Boot-Nachrichten schon aus dem Event-Log geschoben wurden, kannst du dir einen Debug-Report ziehen. In Zeile 4 siehst du die Uptime. (Achtung: 32-Bit Zähler in Sekunden, der kann überlaufen)

Damit du das in ein Verhältnis setzen kannst: WARP1 liest alle 500ms drei Werte vom Zähler aus. Da die Modbus-Register nicht direkt hintereinander liegen sind das 6 Modbus-Lese-Anfragen pro Sekunde.

[michaelst]

Es tritt schon relativ häufig auf, wie ich finde.

2022-05-24 07:20:13,686  Exception code -1
2022-05-24 07:31:41,019  Exception code -1
2022-05-24 07:59:11,655  Exception code -1
2022-05-24 08:00:19,799  Exception code -1
2022-05-24 08:03:00,783  Exception code -1
2022-05-24 08:36:44,923  Exception code -1
2022-05-24 09:56:09,557  Exception code -1
2022-05-24 10:07:24,691  Exception code -1
2022-05-24 10:46:12,706  Exception code -1
2022-05-24 11:33:45,062  Exception code -1
2022-05-24 12:02:48,196  Exception code -1
2022-05-24 12:04:18,438  Exception code -1
2022-05-24 12:04:26,629  Exception code -1
2022-05-24 12:42:14,422  Exception code -1
2022-05-24 12:43:28,556  Exception code -1
2022-05-24 13:07:07,797  Exception code -1
2022-05-24 13:22:36,695  Exception code -1
2022-05-24 13:50:29,043  Exception code -1
2022-05-24 13:51:21,311  Exception code -1
2022-05-24 14:10:13,102  Exception code -1

 

[rtrbt]

Das sind durchschnittlich 21,5 Minuten zwischen den Fehlern, ~ 0,012% Fehlerrate, aber trotzdem mehr als ich erwarten würde. Exception Code -1 heißt, dass das RS485-Bricklet (das kommuniziert per Modbus mit Zähler) eine Antwort des Zählers nicht innerhalb des Timeouts (eine Sekunde) bekommen hat.

Was mir jetzt beim Schreiben auffällt: Es werden keine Request-IDs mit ausgegeben. Bist du auf der aktuellen Firmware? Falls ja, dann sind das alles Fehler, die beim Zurücksetzen der Zählerwerte aufgetreten sind. Eventuell ist der Timeout da einfach zu kurz gewählt.

[michaelst]

Ja, ich bin auf Version 2.0.5.

Allerdings muss ich zugeben, dass ich bei mir im PLC-Programm scheinbar auch noch einen Fehler habe. Muss ich noch prüfen.
Normalerweise sollte das Löschen einmal beim Ladestart erfolgen. Das hatte ich ganz früh eingebaut, als es den Ladetracker noch nicht gab.
Jetzt scheint das Löschen sehr oft zu erfolgen.

Es ist dann aber so, dass wir eine 100 prozentige Fehlerquote beim Löschkommando haben.
Wenn ich das Kommando manuell absetze inkrementiert der Zähler jedes Mal.

[rtrbt]

Ich bin dem mal nachgegangen: Anscheinend hat der Stromzähler einen Bug in der Modbus-Kommunikation.

Was beim Reset intern passiert ist, dass ich einen Schreibbefehl auf ein spezielles Register schicke, worauf hin der Zähler den Wert zurücksetzen und mir darauf antworten sollte, dass er das getan hat. In Modbus funktioniert das so, dass die Slaves (also der Zähler in dem Fall) IDs haben, damit wenn mehrere an einem Bus angeschlossen sind, der Master spezifisch mit einem Slave reden kann. Damit die Antworten unterschieden werden können, müssen die Slaves ihre eigene ID in die Antwort schreiben.

Wenn ich z.B. einen Zählerwert lese sieht das mit dem Logic Analyzer so aus:

Request an DeviceID 1 (den Zähler):

Response von DeviceID 1:

Der Zähler schickt jetzt aber, wenn ich den Reset auslöse eine Antwort nicht mit seiner ID (der 1) sondern aus irgendeinem Grund mit einer 0. Die 0 ist reserviert für Broadcasts, die darf von Slaves überhaupt nicht verwendet werden.

Request an DeviceID 1:

Response vom Zähler mit falscher DeviceID:

Das Problem tritt aber nur bei dem Reset auf, beim Lesen der Zählerwerte, selbst beim Schreiben anderer Konfigurationswerte (mit der selben Funktions-ID) ist die Antwort korrekt.

Das RS485-Bricklet (mit dem wir mit dem Zähler kommunizieren) sieht beim Reset dann die kaputte Antwort, wirft sie weg und betrachtet das als einen Timeout.

Die Lösung des Problems wird sein, dass wir in der Wallbox-Firmware, falls beim Reset auslösen ein Timeout auftritt diesen ignorieren. In der Praxis habe ich es bisher nicht beobachten können, dass der Reset nicht funktioniert. Das sollten wir aber trotzdem prüfen, z.B. indem die Firmware dann den Wert, der zurückgesetzt wird, nochmal ausliest und prüft, dass er erwartet klein ist (also z.B. maximal x ms * 32 A * 230 V * 3 Phasen groß, wobei x die Zeit vom Auslösen des Resets bis zum Empfang des neuen Werts ist). Falls der Wert dann zu groß ist, lösen wir den Reset nochmal aus, mit maximal z.B. 3 Versuchen. Das zu implementieren ist etwas Aufwand, deshalb habe ich erstmal ein Issue dafür angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/147

Als schnelle Lösung für die nächste Firmware nehme ich erstmal raus, den Fehlerzähler bei Reset-Timeouts hochzuzählen. Das fühlt sich immer etwas falsch an zu sagen "nein nein hier zählt der Fehler nicht weil..." aber ich glaube in dem Fall ist es berechtigt: https://github.com/Tinkerforge/esp32-firmware/commit/7ec89afcbad67460b14527bbf318f7d266800392

[michaelst]

Alles klar und vielen Dank für die Telegramme, wäre aber nicht nötig gewesen ;-)

Mir tun solche Workarounds auch immer weh.
Da es ja ein proprietäres System ist, könnte man für diesen Fall eventuell auch auf ID 0 und die Zähler-ID (hier: 1) schauen (falls die Zähler mal gefixt werden).
Wäre ja einfacher und schneller zu implementieren. Aber das müsst Ihr ja entscheiden.

Vielen Dank, so habe ich meinen Bug auch gefunden :-)

[rtrbt]

Der Work-Around ist in der frisch veröffentlichten 2.0.6, damit sollte der Fehlerzähler nicht mehr beim Reset hochzählen.