michaelst Posted May 21, 2022 at 01:16 PM Share Posted May 21, 2022 at 01:16 PM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted May 23, 2022 at 07:02 AM Share Posted May 23, 2022 at 07:02 AM 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. Quote Link to comment Share on other sites More sharing options...
michaelst Posted May 24, 2022 at 12:27 PM Author Share Posted May 24, 2022 at 12:27 PM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted May 30, 2022 at 08:17 AM Share Posted May 30, 2022 at 08:17 AM 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. Quote Link to comment Share on other sites More sharing options...
michaelst Posted May 31, 2022 at 06:43 AM Author Share Posted May 31, 2022 at 06:43 AM 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. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 1, 2022 at 09:26 AM Share Posted June 1, 2022 at 09:26 AM 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 Quote Link to comment Share on other sites More sharing options...
michaelst Posted June 1, 2022 at 02:16 PM Author Share Posted June 1, 2022 at 02:16 PM 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 :-) Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 7, 2022 at 12:13 PM Share Posted June 7, 2022 at 12:13 PM Der Work-Around ist in der frisch veröffentlichten 2.0.6, damit sollte der Fehlerzähler nicht mehr beim Reset hochzählen. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.