Beiträge von Jo_Be

Zitat

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.

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

Zitat

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 hast du denn in der fraglichen Zeit angefragt und mit welchen Ergebnissen (und ist es sicher, dass du alles via python local richtig protokolliert hast)?

Per Mqtt klappt ja alles problemlos. Deshalb ist das beschriebene Verhalten sowieso für mich nicht relevant und ich empfehle auch, auf Mqtt umzusteigen.

Zitat

hatte dein Pro 3EM am 27.10. noch einen FW-Stand vor 1.4.3 ?

Das weiss ich leider nicht mehr genau. Ich vermute aber ja. Um die Zeit - ich vermute aber später - habe ich alle Shellys - in einem Rutsch - upgedated.

Wie auch immer: hier ergibt sich auch das folgende bei http://<shelly-ip>/rpc/EMData.GetRecords?id=0:

.......

{"ts": 1729987320, "period": 60, "records": 1}, <------ 27.10.2024 - 02:02:00

{"ts": 1729989120, "period": 60, "records": 1}, <------ 27.10.2024 - 02:32:00

{"ts": 1729990800, "period": 60, "records": 16477}, <------ 27.10.2024 - 02:00:00

Aber wie gesagt: Keinerlei Lücke in der Datenübertragung per mqtt durch das Gerät in dieser Zeit.

Ich denke eher, dass da bei den Routinen im Gerät der eine Entwickler etwas anderes gemacht hat als der andere, so dass die Daten lückenlos sind, während die Kontrollroutinen (GetRecords) es nicht richtig mitbekommen haben.

Zitat

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.

Das kann ich nicht bestätigen.

Ich lasse mir die Daten vom Shelly Pro 3EM per Mqtt an einen Broker schicken, hole sie beim Broker mit einem Mqtt-Client ab und speichere diese Rohdaten - bevor ich sie weiter verarbeite - in einem Log ab. Die vom Gerät per Mqtt übermittelten Daten enthalten keinen Timestamp. Allerdings stelle ich im Log vor jeden Datensatz das Datum mit der Zeit. In diesem Log sehe ich, dass keine Lücke vorhanden ist. Es werden also am 27.10.2024 hintereinander zweimal Daten in der Zeit zwischen 2 und 3 Uhr ohne Lücke vom Shelly Pro 3EM gesendet und im Log abgespeichert.

In meiner Grafana-Auswertung finde ich dann allerdings eine Lücke in dieser Zeit. Der Fehler (die Lücke) ergibt sich also eindeutig aus nachgeordneten Systemen bzw Anwendungen, die mit einem 25 Stunden Tag nicht klarkommen. In dem oben genannten Fall im Ausgangs-Posting würde ich auf python als Fehlerveursacher tippen oder einen Fehler im Script oder ein simples, fehlerhaftes Überschreiben im Log, zumal die Daten ja offenbar aktiv selbst von Gerät abgeholt werden.

Die Doku ist jetzt online: https://shelly-api-docs.shelly.cloud/gen2/Devices/Gen3/ShellyBluGwG3

Zitat

Das Tool ist vom Entwickler. Mehr sage ich jetzt ohne meinen Anwalt nicht...

Ja, schade, aber verständlich

Zitat

Habe vor einigen Wochen mit einem Flash-Tool Erfolg gehabt

Aha, das ist ja interessant. Ich dachte bisher, das ginge gar nicht.

Zitat

Das darf ich allerdings nicht weitergeben (und seinen Namen nicht verbreiten)

Ach, wer ist das denn, der das verbietet?

Ein Link ohne Namensnennung würde ja auch reichen...

Zum Beispiel ausgehend von diesem Video:

Shelly Gerät von Tasmota zurück zur original Firmware flashen

https://www.youtube.com/watch?v=ZaOJLdfjBWs

Zitat

Beacon Modus bei den BluMotion ist nicht verwendbar, hat mehr Nebeneffekte als Nutzen

Das kann ich nicht bestätigen. Ich kann es auch nicht nachvollziehen. Im Gegenteil, der Beacon Mode sendet hier absolut zuverlässig und das schon seit nun mehreren Monaten. Ich kann das unterbrechungsfreie Senden auch genau verfolgen, denn mit jedem Paket wird ja wie üblich im Beacon Mode vom Blu Motion eine von 0 bis 255 hochzählende Paketnummer mitgesendet, mit der man mitbekommt, ob man alle Pakete empfangen hat. Und genau das ist hier der Fall. Leider werten einige Empfänger diese Nummer nicht aus bzw übermitteln sie nicht weiter. Der hier verwendete Empfänger der Pakete macht das aber und genau deshalb verwende ich ihn auch. Und es gibt dabei hier keinerlei Lücken, die einen Paketverlust anzeigen würden und es wird auch immer in genau gleichen Abständen vom Blu Motion gesendet, ausser natürlich, wenn eine Bewegung erkannt wird.

Danke für den Link

Zitat

zur Visualisierung.

Dafür bietet sich ja influxdb und grafana an.

Wie gesagt, ich nutze Mosquitto unter Windows selbst nicht (sondern unter Linux), aber das habe ich gefunden:

https://wiki.instar.com/de/Erweitert/O…_unter_Windows/

Bitte beachten: es ist nicht die Installation von OpenHAB gemeint, sondern nur die Anleitung zur Installation von Mosquitto. *)

Üblicherweise wird, auch von mir, zum Checken und Testen von Mqtt der hervorragende MQTT-Windows-Client benutzt:

MQTT-Explorer http://mqtt-explorer.com/

Der MQTT-Explorer arbeitet natürlich auch problemlos mit Brokern auf anderen Systemen zusammen (nicht nur lokal, nicht nur Windows).

Bitte den Link zum "anderen Forum" nicht vergessen und hier einstellen.

*) Unter Linux ist das natürlich gar kein Problem: einfach "mosquitto" (den Broker) installieren (und "mosquitto-clients") und binnen Sekunden erledigt. (Wie gesagt: Broker und Client können auf ein und demselben System laufen)

Zitat

Ok. Unter Components danke.

Letztlich ist die Web-Oberfläche der Shellys nur Schall und Rauch (kann Fehler haben und zeigt nur Namen an, die wenig bedeuten). Die wahren Infos bekommt man mit den rpc.

Dann hilft doch eventuell die Abfrage weiter: http://GatewayIP/rpc/Shelly.GetComponents

Vielleicht mal ein Update der Firmware auf dem Gatewy und dann auf dem TRV machen?

Schon einen eigenen Namen vergeben?

Bei mir erscheint die ID (in Klammern) sowohl bei "Home" als auch bei "Components"

Auf jeden Fall solllte der rpc "Shelly.GetComponents" weiterhelfen.

Zitat

Wo finde ich die BluTrvID?

Zum Beispiel per http://GatewayIP/rpc/Shelly.GetComponents

und auch in der Weboberfläche: dort ist die ID defaultmässig in Klammern angegeben: BluTrv (200)

Zitat

Bzw. Wieso 200?

Tja, da musst du Shelly fragen. Ich vermute, dass sie das deutlich von den ID=0 der sonstigen Shellys absetzen wollten (etwa: ab 200 ist es Bluetooth...) Auf jeden Fall wird bei bestimmten Abfragen von 200 an hochgezählt, auch für die anderen (nicht vorhanderen) TRV.

Zitat

Nach meinen Recherchen bräuchte ich eine HW auf der der MQTT Borker läuft und eine HW die die Daten vom Broker abruft, da er keine Daten sammeln kann.

Das ist Quatsch. Beides kann auf einem System laufen und tut es in der Ragel auch.

Und sehe da keine grossen Unterschiede. Trotzdem würde mich ein Link zu den Beiträgen im "anderen Forum" interessieren.

Zitat

Nachdem ich wohl mit MQTT nicht weiterkomme

Warum das denn nicht? MQTT kann ohne jedes zusätzliche System verwendet werden und ist perfekt für eine einfache Anwendung. Wenn es einen MQTT-Server auch für Windows gibt (was ich nicht weis, ich nutze MQTT-Server unter Linux, aber für sehr wahrscheinlich halte), dann kann man den MQTT-Server (den sogenannten Broker) im Hintergrund laufen lassen und zusammen mit einem MQTT-Client verwenden und alle Datensätze selbst auswerten. Einfacher und sparsamer geht es nicht. Es ist dabei keinerlei Smarthome-System erforderlich, die Auswertung und Verarbeitung der Daten liegt in der eigenen Hand.

Voraussetzung ist natürlich, dass die Geräte (H&T Gen3) MQTT über WLAN unterstützen, was ich nicht beurteilen kann, ich kenne die Geräte nicht, dazu wissen andere hier mehr.

Hier (im Vorgang auf die entsprechende Dokumentation, die demnächst bei Shelly erscheinen wird) Befehle mit denen man via HTTP über das Gateway Gen3 das BLU TRV abfragen und einstellen kann (ohne Cloud und App):

Abfrage (erste _BluTrvID_: 200):

http://GatewayIP/rpc/BluTrv.GetRemoteStatus?id=_BluTrvID_"

Einstellen (erste _BluTrvID_: 200, _Temp_:4.0 - 30.0):

http://GatewayIP/rpc/BluTrv.Call?id=_BluTrvID_&method=Trv.SetTarget&params={"id":0,"target_C":_Temp_}

Damit kann man eine lokale Fenster-Auf/Zu-Routine perfekt realisieren, auch wenn man den Fenster-Zustand woanders (Kamera, Relais usw) her bezieht.

HTH

Jo_Be

Zitat

Kann man den Bacon Mode per Shelly Script steuern?

Wie ist das gemeint? Was könnte man da steuern wollen? Da muss man doch überhaupt nichts steuern.

Kann man diesen Thread, der inzwischen völlig daneben ist (lesen und gucken ist offenbar nicht die Stärke von jedem), einfach endlich beenden. Danke. Ich jedenfalls warte jetzt erst einmal Erfahrungsberichte ab (und keine Videos, die ein Bild der Webseite zeigen und das als Information verkaufen wollen).

Zitat

Weiß jemand, ob dies als Gateway fungieren kann? Oder brauche ich noch eines extra? Dann wäre es ein Ausschlusskriterium für mich.

Für mich wäre das kein Ausschlusskriterium. Aber die Geschmäcker sind verschieden...

Es wurde ja am bisherigen Shelly TRV kritisiert, dass kein Frostschutz-Modus im Gerät vorhanden war. Ich gehe davon aus. dass Shelly das nun im Gerät selbst implementiert hat...

Zitat

Hier gibts Taufrisch ab 3:39 News und auch Bestätigung der technische Limitierungen zu dem TRV BLU...

Überhaupt nicht.... Werde ich mir nicht weiter antun, das Gejammere...

Ich hoffe, dass sich Shelly für diese nicht unheikle mechanische Sache externes Knowhow geholt hat oder sogar eingekauft hat.

Zitat

https://kb.shelly.cloud/__attachments/…27-e6143dfdbf1a

Danke für den Link