Beiträge von Jo_Be

    Soweit ich das verstanden habe benötigen die BLU TRV das mitgelieferte BLU Gateway um sich connecten zu können. Was sehr schade ist da ich Flächendeckend in meiner Anlage Plus und Pro Geräte verteilt habe und diese auch als BLE Gateways nutze. Leider kann man - soweit mein Wissensstand - aber die TRV nicht mit diesen Gateways verbinden.

    Ich dagegen finde das sehr gut: Man betrachte beide Teile (Ventil und Gateway) als ein Gerät. Ich finde nur den Namen "Gateway" marketingmässig falsch gewählt, sonst ist alles okay. Das Ventil braucht eben kein "Gateway" sondern beide Teile sind die beiden Hälften eines Gerätes.

    Kleiner Nachtrag noch: Ich habe bei dem mitgelieferten USB BLU Gateway MQTT aktiviert, finde es aber im IO Broker nicht.

    Vielleicht, weil das neue Ventil eben noch nicht in IO Broker implementiert ist.

    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)?


    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.

    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.

    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.

    Habe vor einigen Wochen mit einem Flash-Tool Erfolg gehabt

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

    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

    Shelly Gerät von Tasmota zurück zur original Firmware flashen
    Auch ich habe einige Shelly Geräte mit Tasmota geflasht. Es gibt eine Möglichkeit wieder die Original Firmware von Shelly zu flashen. Wie das funktioniert ze...
    www.youtube.com

    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.

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

    Mosquitto Broker Installation unter Windows
    Der Open Home Automation Bus (openHAB) ist eine Open-Source-, Technologie-agnostische Heimautomatisierungsplattform, die als das Zentrum Ihres Smart Home…
    wiki.instar.com

    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)

    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.

    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)


    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.

    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.

    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

    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).