Beiträge von Jo_Be

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

  • Zigbee aktivieren

    Ob der Modus von Matter zu Zigbee umgestellt wurde, sieht man im Browser. Das Device sollte dazu vorher(!) sinnvollerweise schon ins WLAN intergriert sein (weil im Zigbee Modus der AP des Devices deaktiviert wird *) ) über die zugewiesene IP (die kann man ggf in Router nachsehen) auf die Weboberfläche des Geräts gehen. Dort sieht man dann Matter oder Zigbee im Menü.

    Man hält sich an sinnvollsten an das, was die Anleitung schreibt, die beiliegt oder als PDF verfügbar ist: https://kb.shelly.cloud/__attachments/…6a-5d99df125bc9: "Um das Gerät von der Matter-Firmware (Standard) auf Zigbee umzustellen, drücken Sie 5 Mal die Reset-Taste"

    Wenn Zigbee bereits aktiviert ist, kann man das Pairing wieder aktiveren indem man die Reset-Taste 3x drückt: "Wenn Sie das Gerät nicht finden können, drücken Sie 3 Mal die Reset-Taste"

    *) Man kann (wenn ich es richtig sehe: nur bis zum nächsten Reset des Geräts) den AP im Zigbee-Modus wieder aktivieren (siehe PDF): "m Zigbee-Modus ist der AP des Geräts standardmäßig nicht verfügbar. Um ihn zu aktivieren, müssen Sie die Reset-Taste 5 Sekunden lang gedrückt halten"

  • 1PM Mini Gen4 und Hue Bridge

    Shellys Technical Support Sofia schreibt in Beantwortung einer entsprechenden Anfrage von mir:

    "Philips Hue should not work because it is a ZLL (Zigbee Light Link) and a proprietary network developed by Hue based on the Zigbee protocol."

    Aber ich hoffe, da ist noch nicht das letzte Wort gesprochen. Es muss ja nur das AN/AUS als "Lampe" (im Hue Bridge Sinne) unterstützt zu werden. Wie es andere Hersteller ja auch tuen (zB IKEA).

    Hier also die Bitte an die Shelly-Firmware-Entwickler: Bitte implementiert einen ZLL Modus, in den man optional bei Zigbee wechseln kann.

    Weil Zigbee- und WLAN-Antennen beim Espressif-C6 (auf dem Shellys Gen4 basiert) getrennt sind, können Zigbee und WLAN bei Gen4 gleichzeitig laufen und man kann alles, was über AN/AUS im ZLL-Modus hinausgeht in der Kommunikation via WLAN abwickeln (incl Mqtt zum Beispiel).

    Auf diese Weise würde Gen4 ins Hue-Ökosystem (App, Zmmer, Zonen, Schalter, Dimmer) intergriert werden können.

    Man könnte sich unter anderem einen zusätzlchen Zigbee-Stick ersparen.

  • 1PM Mini Gen4 und Hue Bridge

    Meine Hoffung (nicht meine Erwartung) war, dass es mit einer Verbindung zur Hue Bridge (v2) klappt. Leider ist das nicht so, Die Hue Bridge findet nichts. Weiss jemand Näheres dazu? Vielleicht von Shelly selbst? Test, Erfahrungen, Aussagen? Wie sieht es mit dem Protokoll 802.15.4 aus auf der Gegenseite (Hue Bridge). Liegt es eventuell einfach am (von mir) falsch aktivierten Pairing-Mode auf den Shelly?

  • Shelly BLU TRV und Gateway in IO Broker

    Zitat

    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.

    Zitat

    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.

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

    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.

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

    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.

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

    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.

  • Shelly Plus 2PM von Tasmota auf Original

    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

  • Bluetooth Gateway Funktion nicht stabil

    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.

  • H&T Gen3 nutzen ohne Cloud

    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)

  • BLU TRV einstellen via HTTP

    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.

  • BLU TRV einstellen via HTTP

    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.