Jump to content

michaelst

Members
  • Gesamte Inhalte

    14
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von michaelst

  1. Wie gesagt, dass erste Mal trat es bei mir im April auf. Es wird also vermutlich nicht an einer der letzten Änderungen liegen.
  2. OK, verstehe. Da frage ich nochmal meine Frau, ob die Led wirklich aus war ;-) Nehmen wir an, dass nur der ESP-Brick ausgefallen ist, dann könnte das nicht funktionierende Laden doch damit erklärt werden, dass der NFC-Tag zum Starten benötigt wird und das NFC-Bricklet am "stehenden" ESP hängt und damit nicht erkannt wird. Richtig? Der DB-Server und MQTT-Server läuft über Nacht nicht. Er fährt um 23:45 Uhr herunter und startet um 5:55 Uhr. Die erste Tabelle ist eventgetriggert. Der erste Datensatz des Tages (hier 1489) ist technisch bedingt immer Null. Die letzte Änderung war am Tag vorher 1490 ist der erste DS nach dem Neustart Der zweiten Tabelle wird jede Stunde ein DS hinzugefügt. Abends vorher läuft noch alles, am nächsten Tag nicht mehr, erst nach dem Neustart.
  3. Wir haben vor ca. 1 Jahr eine der letzten WARP1 bei uns installiert. Ein NFC-Bricklet habe ich irgendwann selbst nachgerüstet, funktioniert prinzipiell einwandfrei.. In dieser Zeit ist es, heute das zweite Mal, passiert, dass die Wallbox stehen bleibt. Vermutlich geht die Firmware in einen deadlock. D.h. die Box ist komplett ohne Funktion. Es gibt keine Reaktion auf das Anschließen des Autos, keine Reaktion der Led. Kein Interface ist erreichbar, weder HTTP, noch MQTT, usw. . Ein kompletter Neustart, also einmal spannungslos schalten, hilft natürlich. Den Debug-Log nach dem Neustart habe ich angehängt. Hilft auch nur bedingt, aber es gab keine Chance, an den letzten zu kommen. Beim ersten Mal, Ende April (Firmware 2.0.1), da habe ich es ignoriert und gehofft, dass eine der folgenden Firmwaren das Problem löst. Jetzt ist die 2.0.7 installiert. Eine Vermutung, wie die Box in diesen Zustand kommt ist, dass es passiert, wenn die Wallbox eine längere Zeit nicht in Benutzung ist. Durch private Umstände wurde die Box bei uns aktuell ca. 8 Tage nicht benutzt. Im April waren wir eine Woche im Urlaub. Es ist natürlich schwer zu sagen, ob dies der Grund ist, aber zumindest ein Ansatz. Ansonsten ist an unserem System nichts geändert worden. Da ich diverse Werte (Quelle ist MQTT) teils regelmäßig, teils eventgetriggert in einer Datenbank speichere, kann ich sagen, dass vorher kein Fehler aufgetreten ist. Die Werte bleiben dann einfach auf Null, bedingt durch den Ausfall von MQTT. Kann ich programmiertechnisch irgendetwas einbauen, um den Fehler ggf. zu erkennen? Lieben Gruß, Michael debug-report-warp-ULJ-2022-11-08T10-09-42-009.txt
  4. 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 :-)
  5. 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.
  6. 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
  7. 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
  8. Sorry, jetzt wo du es schreibst ... hätte ich mich bei der Fragestellung etwas deutlicher ausdrücken können. Keine internen Fragen. Es geht um verschiedene Topics, die per Mqtt ausgelesen werden können. Bei denen haben einfach gesagt, die "SW-internen Zustände" nicht gepasst.
  9. Wunderbar, kein Problem. esp32_brick ist ebenfalls false ... Ich vermute, dass das nicht nur beim Ethernet Brick true sein sollte.
  10. Hallo, seit mindestens der Firmware 2.0.4 steht das "http"-Modul bei der WARP1 auf false. Funktionieren scheint es aber dennoch, wobei ich nicht die gesamte Funktionalität getestet habe. War das beabsichtigt?
  11. Auf den Überlauf der 32-Bit habe ich schon gewartet ;-) Alles klar, danke!
  12. Hallo, ich habe die WARP1 (FW1.3.0) per MQTT mit einem Broker verbunden. Mit meiner Haussteuerung (TwinCAT) lese ich dort diverse Werte zur Weiterverarbeitung und Visualisierung aus. Unter anderem sind es die evse/state/uptime, .../time_since_state_change, evse/btton_state/button_press_time Mit der aktuellen PLC-Zeit (sekundengenau), welche täglich mit einem externen Zeitserver synchronisiert wird, bilde ich die Differenz und erhalte so die exakten Zeitpunkte, an dem die Box gestartet wurde, der letzte Statuswechsel und Knopfdruck statt gefunden hat. Da ich die Wallbox nicht neu starte, keinen Statuswechsel triggere und den Knopf nicht drücke, sollten sich die drei berechneten Zeitpunkt auch nicht verändern (siehe Online-Werte). PLC-Code: tWallboxUptime := DINT_TO_TIME(Wallbox.diUptime); tWallboxStart := tCurrentTimeDate - DINT_TO_TIME(Wallbox.diUptime); tWallboxButtonPressed := tWallboxStart + DINT_TO_TIME(Wallbox.diButtonPressTime); tWallboxLastStateChange := tCurrentTimeDate - DINT_TO_TIME(Wallbox.diTimeSinceStateChange); Online-Werte: Wir betrachten uns, als Beispiel, die Berechnung von tWallboxStart: tCurrentTimeDate (aktuelle Zeit der PLC) und Wallbox.diUptime werden (theoretisch) gleichmäßig größer, daher ist die Differenz, also tWallboxStart, konstant. Da die beiden Uhren (PLC und Wallbox) in der Praxis nicht synchron sind, sollte die Differenz mit der Zeit etwas weglaufen. Das ist ja grundsätzlich auch OK. Bei mir, ich vermute auch bei anderen, ist es aber so, dass ich eine Ungenauigkeit von ca. 6 Minuten pro Tag habe. Das bedeutet, dass der oben zu sehende Online-Wert am nächsten Tag von 15:17 Uhr nach 15:11 Uhr zurückläuft. Dies wiederum bedeutet, dass die Uhr der Wallbox zu schnell läuft, die Uptime, also zu groß ist. Meine Frage ist jetzt: wo liegt die Ursache? Wie wird intern der Zeittakt erzeugt/gebildet? Gruß, Michael
  13. Hallo, der Wunsch der Erweiterung mit NFC wäre bei mir auch da. Ich hatte schon selber überlegt dies zu tun. Ich bin selber Firmware-Programmierer, daher sollte es doch möglich sein die WARP1 mit NFC zu erweitern. Es sollte meiner Meinung nach auch kein großes Problem darstellen eine WARP1 Firmware zu erstellen, in der beim Booten, nach einem NFC-Modul gescannt wird und dieses dann benutzt wird oder eben nicht, je nach Ergebnis des Scans. Was meint ihr? Gruß, Michael
×
×
  • Neu erstellen...