Beiträge von Horst2303

    Jo_Be

    Zitat

    Wie kann es denn sein, dass du in genau dieser Stunde GetStatus aufgerufen hast (eine Abfrage, die ja keine echten NutzDaten zurückgibt)?

    Zum ersten Satzteil siehe "Zusatzinfo 2" in meinem ersten Post oben.

    Und wieso gibt GetStatus keine Nutzdaten zurück? Also die EM-Komponente liefert mir 22 Messwerte (Momentaufnahmen, keine Mittelwerte) und EMData gibt nochmal 8 Summenwerte dazu.

    Zusätzlich finden sich im EMData-Minutenspeicher noch die Wirkenergieangaben jeweils mit und ohne Oberwellenanteil. Auch die dort abgelegten Werte zu voraus- und nacheilender Blindenergie interessieren mich (vor allem weil die PowerFactors aus der EM-Komponente leider ohne Vorzeichen sind).

    Der Pro 3EM reicht zwar von der Präzision nicht an Messgeräte im vierstelligen Euro-Bereich ran, aber ermöglicht mir doch Einblicke und Analysen, die mir so günstig bisher verwehrt waren.

    Zitat

    Wie hast du denn in der fraglichen Zeit angefragt und mit welchen Ergebnissen

    Zusätzlich zu den sekündlich laufenden GetStatus-Abfragen wird einmal pro Tag der EMData-Speicher bzgl. der Werte des Vortags als CSV-Datei runtergeladen und analysiert. Dabei sind dann natürlich die fehlenden 58 Einträge auch aufgefallen.

    HighFive

    Super, danke für die Daten. Dir ist die Bedeutung wahrscheinlich ja klar, aber für etwaige Mitleser in diesem Thread:

    Bei beiden Geräten endet die kontinuierliche Datenspeicherung um 2:01 MESZ und startet dann wieder um 2:00 MEZ.

    Für die 59 Minuten dazwischen hat das linke Gerät zwei (statt 59) Datensätze (um 2:07 und 2:37 MESZ). Beim rechten Gerät sind es 4 Datensätze (jeweils 2 um 2:16 und 2:46 MESZ).

    Sehr interessant ist ja (ich hoffe, FW-Entwickler lesen hier mit), dass der Abstand der singulären Einträge bei beiden Geräten (und auch bei mir - siehe ganz oben) genau 30 Minuten beträgt.

    Schade, dass mit FW 1.4.4 dieser Fehler immer noch drin ist (und meine Vermutung bzgl. Changelog 1.4.3 falsch war.

    Hallo Jo_Be,

    danke für deine GetRecords-Daten.

    Daraus geht hervor, dass auch in deinem Gerät im "kritischen" Zeitraum (2:00 MESZ bis 2:00 MEZ) statt 60 Datensätzen nur 2 gespeichert wurden. Bei mir waren diese beiden singulären Einträge um 2:22 und 2:52 MESZ.

    Wie schon eingangs gesagt, wurde bei mir nicht nur nichts gespeichert, sondern das Gerät war auch für diese Stunde über GetStatus nicht erreichbar.

    MQTT ist ja dagegen eine Push Data Situation. Das läuft intern sicherlich über komplett andere Software-Module. Auch ist MQTT für einen permanenten Datentransfer quasi der Standard, sodass ein Fehler im Umfeld der Zeitumstellung hier schon viel früher registriert worden wäre.

    Jetzt wäre abschließend nur noch zu klären, ob dieser Fehler mit der FW 1.4.3 behoben wurde (das Changelog lässt es ja nur vermuten).

    ---------------------------------------------

    Daher eine neue Bitte, diesmal an alle, die vor der Zeitumstellung einen FW-Stand 1.4.3 oder neuer hatten (1.4.3 kam am 22.08., 1.4.4 und 1.4.5 beide am 17.10.)

    Im Browser als URL eingeben (für <shelly-ip> die IP-Adresse des Pro 3EM im eigenen Netzwerk einsetzen):

    http://<shelly-ip>/rpc/EMData.GetRecords?id=0

    Das angezeigte Ergebnis einfach hier in den Thread kopieren. Es braucht nicht aufbereitet zu werden (so wie Jo_Be es gemacht hat. Als Beispiel hier meine Antwort auf die Abfrage:

    Code
    {"data_blocks":[{"ts":1725840000,"period":60,"records":6515},{"ts":1726230960,"period":60,"records":36683},{"ts":1728432000,"period":60,"records":14472},{"ts":1729300380,"period":60,"records":10297},{"ts":1729918260,"period":60,"records":1149},{"ts":1729988460,"period":60,"records":1},{"ts":1729990260,"period":60,"records":1},{"ts":1729990800,"period":60,"records":14961},{"ts":1730888520,"period":60,"records":2525}]}

    Ein oder zwei Posts (mit Angabe des FW-Stands am 27.10.) würden mir reichen. :)

    HighFive

    Ich liege aber jede Nacht wach und grüble über die Ursache des Fehlverhaltens. :)

    Und das möchte ich nicht noch 145 Nächte - außerdem ist die Nacht Ende März ne Stunde kürzer. Wer weiß, was dann passiert...


    Daher nochmal meine Bitte aus Post #4 an den Rest der Pro 3EM Besitzer bzgl. des GetRecords Aufruf (siehe dort).


    Bevor es einer vorschlägt: Ich könnte natürlich auch einen lokalen Timeserver aufsetzen und meinen Shelly damit auf Zeitreise schicken, um die Situation auch mehrfach zu testen (... und täglich grüßt das Murmeltier :D )

    Aber zuerst hoffe ich doch noch auf ein paar GetRecords-Ausgaben (vor FW 1.4.3)

    Hallo HighFive,

    danke für den HA-Log.

    Ich wusste, dass meine FW nicht ganz aktuell ist. Hab aber im Vorfeld das Changelog gecheckt und nichts Auffälliges gefunden (dachte ich).


    Auf deinen zweiten Post hin hab ich nochmal kritisch geschaut und zur FW 1.4.3 folgenden Eintrag gefunden:

    Zitat

    Fixed

    • ProEM, Pro3EM Fix status response when non-critical errors are present

    Könnte natürlich sein, dass zur Umstellung im Zeit-Umfeld (Abfrage des Zeit-Servers etc.) ein "non-critical error" entstand, der den GetStatus blockiert hat.


    Es wäre schön, wenn sich noch jemand findet, der einen Pro 3EM mit FW-Stand vor 1.4.3 hat - und der zumindest mal die eingangs bereits erwähnte GetRecords Abfrage im Browser durchführt und das Ergebnis einfach hier in den Thread kopiert.

    Also oben in der Adresszeile als URL eingeben (der Pro 3EM sollte natürlich im triphase Profile betrieben werden, und nicht im monophase:(

    http://<shelly-ip>/rpc/EMData.GetRecords?id=0

    Für <shelly-ip> die IP-Adresse des Pro 3EM im eigenen Netzwerk einsetzen


    Danke und Grüße

    Horst

    Pro 3EM - Keine Messungen am 27.10.2024 zwischen 2:00 MESZ und 2:00 MEZ

    Hallo miteinander,

    bei der Analyse meiner Datenaufzeichnungen vom Sonntag, 27.10.2024 (Tag der Zeitumstellung) stieß ich auf eine Aufzeichnungslücke beim Shelly Pro 3EM genau für die Stunde, die "doppelt" durchlaufen wird.

    Folgende Datensätze sind für diesen Zeitraum im Speicher vorhanden:

    Code
       Zeitstempel     Uhrzeit         Bemerkung
       1729987140      01:59 MESZ      letzer fortlaufender Eintrag (davor alles okay)
       1729988460      02:21 MESZ      singulärer Datensatz
       1729990260      02:51 MESZ      singulärer Datensatz
       1729990800      02:00 MEZ(!)    erster Eintrag nach Zeitumstellung (ab hier wieder gut)

    Eine API-Abfrage mit .../EMData.GetRecords?id=0 bestätigt diese Situation (Ausgabe für hier vereinfacht):

    Code
       "ts"            "records"
       <ältere weggelassen>
       1729300380      10297
       1729918260      1149
       1729988460      1
       1729990260      1
       1729990800      13465

    Hat jemand von euch dieses Verhalten bei sich auch beobachtet?
    Am einfachsten lässt es sich ja über "GetRecords" prüfen, also im Browser als URL eingeben:
    http://<shelly-ip>/rpc/EMData.GetRecords?id=0
    (Evtl. die Ausgabe durch einen Online-JSON-Formatter übersichtlicher darstellen lassen.)

    ---------------------------------------------------------------------------------------
    Zusatzinfo 1:

    Mein Gerät:

    Code
        id:    shellypro3em-34987a681448
        fw_id: 20240726-114514/1.4.0-gb2aeadb

    ---------------------------------------------------------------------------------------
    Zusatzinfo 2:

    Für spezielle Analysen wird mein Gerät schon seit Wochen durch ein von mir geschriebenes Python-Programm im Sekunden-Abstand auf seinem GetStatus-API gepollt und die Ergebnisse werden gepeichert.

    In der Tagesdatei von 27.10.2024 ist hier ebenfalls eine Lücke von genau 3600 Sekunden (zwischen 2:00 MESZ und 2:00 MEZ).
    ---------------------------------------------------------------------------------------

    Der 27.10.2024 hatte ja eine Länge von 25 Stunden.
    Kann es sein, dass die Firmware hier bewusst auf eine Aufzeichnung in der genannten Stunde verzichtet, um so die Aufzeichnung auf 24 Stunden zu reduzieren?

    Nachgeschaltete Auswertungssoftware könnte ja mit dem XXL-Tag Probleme haben...

    Ich würde mich freuen, wenn einer der Spezialisten hier mir kompetente Aufklärung geben könnte.

    Gerne liefere ich auch noch weitere Infos aus meinen gespeicherten Daten.

    Danke und viele Grüße,
    Horst