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.
Bei allem Beschriebenen gab es keine Probleme hier (IIRC wird das meiste sogar auch auf dem den Devices der Gen 4 beiliegenden Papier beschrieben 
). Aber wie auch immer:
Es fehlt im Wesentlichen im Zigbee Mode eine optionale Implementation des ZLL Protokolls für die Kopplung mit der Hue Bridge.
Bitte diese Anforderung gegenüber Shelly dafür hier mit unterstützen:
https://community.shelly.cloud/topic/9421-gen…-eg-hue-bridge/
Ich benutze weder OpenHAB noch einen Shelly1plus. Aber nach meinem Eindruck ist da tatsächlich etwas nicht richtig im Wifi-Bereich implementiert in Version 1.6.1.
Natürlich wird problemlos eine Verbindung hergestellt mit dem Router und alles ist okay soweit.
Aber: Irgendwas ist bei der Anmeldung am Router nicht okay. Es wird in einem konkreten Fall bei einer Neuverbindung eines Plus Plus S (also Gen. 2) bei Version 1.6.1 von Router nicht bemerkt, dass sich das Device neu verbunden hat und zwar weder beim Reset noch bein Neueinstecken des Plugs. Bemerkt habe ich das nur, weil ich im Router eine´neue feste IP zuweisen wollte, die ab dem nächsten Neustart des Geräts gültig werden sollte, was aber nicht passiert ist. Die Meldung steht immer noch da (trotz - wie gesagt - mehrfachen Neustarts des Geräts) und es wird immer noch die alte IP zugewiesen. Das müsste man einmal näher untersuchen, ob und was da nicht richtig abgewickelt wird.
Insofern können aus meiner Sicht alle Aussagen richtig sein:
- Die Verbindung mit dem WLAN gelingt
- OpenHAB erkennt nicht, das das Device (wieder) verfügbar ist
PS: ich habe das in meinem Fall (in dem es nur um eine andere IP ging) übrigens damit gelöst, dass ich im Device selbst die richtige IP (feste IP incl. Mask, Gateway, DNS) zugewiesen habe. Insofern ist die Sache in meinem Fall erledigt. Hinweise für meinen Fall sind also unnötig.
Persistenz durch Speicherung im nichtflüchtigen Speicher (KVS).
Ja, das ist für mich ein wichtiger Punkt, wobei ich mich aber frage, ob das mit dem Pro3EM im Laufe welchen Zeitraums möglich ist: Gibt es dazu Erfahrungen oder sogar Angaben?
Negativ
Für den Rest des Scripts gilt für mich: es ist mir Wumpe... funktioniert und gut ist's.
Ich habe nicht alle Beiträge in diesem Thread durchgesehen, ob es hier schon erwähnt wurde:
Ich nutze dieses Script auf dem Pro3EM und bin damit zufrieden und kann es empfehlen:
Trotz der inzwischen 3 Daumen hoch für meinen Beitrag direkt hierdrüber kann ich nicht vermeiden auf meinen Beitrag in einem anderen Thread (Bluetooth Gateway Funktion nicht stabil (Seite 3)) vom 30. Juni 2024 zu verweisen...
Es wäre natürlich schade und keine gute Sache bei Shellys, wenn die Entladung der Batterie dort anders geprüft und übermittelt würde, als es bei anderen einfachen BLE-Geräten der Fall ist, wie zum Beispiel von Xiaomi Mi Thermometern, die das sehr präzise tun. Tja, auch wenn hier einige offenbar so negative Erfahrungen in dieser Hinsicht mit Shellys gemacht haben, bleibt das erst einmal abzuwarten.
... und den entsprechenden Thread unter dem Aspekt Batterie noch einmal genau zu lesen.
Denn ich kann nicht verhehlen, dass, auch wenn man von einer (durch Shelly) angekündigten Batterie-Lebendauer von 4 Jahren ausgeht (oder sind es 2 Jahre?), die von Anfang an übermittelten 98% sich in dem fast vergangenen Jahr kein Stück geändert haben...
Allerdings würde ich wg. der vielen Vorteile niemals auf den Beacon Mode beim BLU Motion verzichten.
Ich habe bei fast allen meinen BLU Motions den Beacon Mode aktiv. Die laufen damit jetzt schon ein reichliches Jahr. Der Batteriestand beträgt immer noch 98 bis 100 %.
Das kann ich genau so bestätigen.
Ja, genau, das ist das normale Verfahren, um alle Methoden direkt beim Device abzufragen, die das jeweilige Device unterstützt.
Ich meine dagegen, dass die Aussage vom Support die Sache trifft: ZLL (Zigbee Light Link) ist ein bestimmtes Protokoll innerhalb von Zigbee (sowohl vor Version 3.0 und auch innerhalb von Version 3.0 gibt es ZLL). Dieses ZLL betrifft Leuchmittel (und zwar nur diese, weil die zum Beispiel so etwas wie RGB und Dimmung haben, was von ZLL unterstützt wird).
Nun können auch andere Devices sich als simple "Lights" via ZLL zu erkennen geben. Das machen zum Beispiel Ikea Plugs (uralte Osram Plugs auch). Das ist klug von Ikea, denn dann funktionieren sie auch mit Hue. Aber natürlich unterstützt ZLL keine Energiemessung usw.
Deshalb hat sich Shelly natürlich zunächst für Standard Zigbee entschieden in der Implementierung. Standard Zigbee kann aber das ZLL der Hue Brigde *) nicht (ZLL als Teil innerhalb Zigbee v3.0). Wenn Shelly nur ZLL sprechen würde, dann gingen natürlich alle anderen Daten ausser AN/AUS flöten.
Mein Wunsch nach dem ZLL mode für Shellys basiert nun darauf, dass die Einbindung in Hue möglich wäre, weil man ja alle anderen Daten auch via WLAN (http,mqtt,.... ) abrufen kann. Das wäre (für mich) das Beste aus beiden Welten.
*) die Hue Bridge hat zusätzliche proprietäre Erweiterungen innerhalb Zigbee, die nun für ihre Geräte (Kamera, Plug mit Leistungsmessung) und die ihrer Freunde ("friends of Hue") zur Verfügung stehen, die aber nicht öffentlich sind (und die man als anderer auch tunlichst nicht verwenden sollte...).
Zwei Bedenken bleiben:
- Gibt es eventuell zu viele Supportanfragen, wenn im Zigbee mode unbedacht ZLL aktiviert würde von Leuten, die die Zusammenhänge nicht verstehen (dass zum Beispiel keine Energiemessung via Hue möglich sein wird).
- Ist der Aufwand für die Implementierung zu gross/zu teuer.
Meine Antworten an Shelly:
- ZLL kann man mit einem kurzen Text bei der Option in der Shelly-WebUI erklären.
- ZLL implementieren: Ja, unbedingt. Das erschliesst einen sehr, sehr grossen zusätzlichen Kundenkreis für Shelly
Bitte diesen Thead unterstützen:
https://community.shelly.cloud/topic/9421-gen…-eg-hue-bridge/
Meine Aussage bezieht sich unmissverständlich auf die Inhalte.
Ich bezog mich auf die Connect Message, in der die LWT Inhalte optional sind und vom Client mitgeschickt werden. Insofern wertet der Broker aus ob lastWillMessage vorhanden ist und merkt sich ggf diesen Inhalt.
Den Inhalt legt der Client fest, der Broker merkt sich den LWT und versendet ggf.
LWT-Nachrichten sind Nachrichten, die sich der Broker gemerkt hat und die versendet werden, wenn die mit dem Client vereinbarte Keepalivezeit, die ebenfalls während des connects vereinbart wurde. verstrichen ist und der Client nichts gesendet hat.
Dem Broker sind die Inhalte von MQTT Nachrichten völlig wurscht
Das trifft auf die LWT-Nachrichten nicht zu.
Thanks. Hoffentlich wird es was.
dann beschwere dich aber auch nicht über zu wenige IPs
Ich beschwere mich nicht und benutze gerne ein /24-Netz und weiss, dass es irgendwann voll ist.
Aber das passiert eben viel, viel langsamer/zuhause überhaupt nicht, wenn nicht die vielen kleinen WLAN-Edge-Geräte dazu kämen, die sich immer mehr ausbreiten. Da wird es halt voll und voller.
Doch nun hilft auch Shelly dabei ab: Das ist sicher ein sinnvoller Grund für Shelly, diesen Zug nicht zu verpassen und Gen3 sehr schnell durch Gen4 zu ersetzen.
Das würde ich niemals tun ;-), alle IP in der Fritzbox (speziell bei Fritzboxen dauert das ewig ... ) einzeln sinnig zuzuordnen, nachdem sie vergeben wurden. Noch schlimmer wäre, at the Edge (in jedem Device) rumzufummeln. Nein bei Fritzboxen zuhause wirklich nicht. Bereiche in der Umgebung sind hier auch teilweise mit Wireguard belegt ua. um verschiedene DNS zu nutzen.
Ja, zwischen .2 und .20 ist es bei mir randvoll (alle Plätze belegt (mit fester IP)).
Wenn man die obere Grenze von .200 auf zum Beispiel .240 ändert, dann verändern sich die VPNs von 201... auf .241... (auch die schon existierenden). Wo sie auch verbleiben, wenn man die Grenze wieder runtersetzt.
Deshalb: von "jeder Menge" würde ich in diesem Zusammenhang nicht sprechen.
Wer es aber mit einem 10-Netz auf den Heimgebrauchs-Fritzboxen versucht und es dann noch möglichst sinnig organisieren will, hat höllisch viel Arbeit. Uninteressant.
Meine Shellys haben heute „alle“ die neue FW als Option bekommen
Hier die letzten fünf verbliebenen heute auch. Wobei ich das Update manuell anstosse.
Gen4 ist übrigens schon viel weiter: 1.5.99
Wie kommst du darauf? Dazu schreibt Shelly jedenfalls nichts.
Ach ja, Matter ist ja default. Aber der C6 unterstützt Thread wie gesagt.
Das ist nicht der Fall.
Ich habe ein /18er Netz eingerichtet. Damit habe ich die Möglichkeit:
Default ist aber nun mal /24, was die meisten nicht ohne Not ändern werden. Also 255 Adressen, wovon die Fritzbox sich (defaultmässig) die ersten 20 und die Adressen über 200 vorbehält, sodass 180 für die Zuweisung durch die Fritzbox übrig bleiben.
Ich persönlich würde dann ja lieber Thread bevorzugen.
Matter hat Shelly ja bereits, die neue ESP32-C6 können Thread - vielleicht wird das ja was
Die Shelly-Gen4 haben einen C6. Das ist ja gerade der Cloud (und deshalb wurde ja auch Gen3 so schnell abgelöst). Allerdings gibt es den C6 schon seit mehreren Jahren zu kaufen und der C6 wurde bereits 2021 angekündigt von Espressif. Shelly ist also eher spät...
Und natürlich kann Gen4 Thread (das ist sogar der Default-Modus). Aber nicht jeder hat ein passendes Gateway. Deshalb kann man auf Zigbee umstellen. Es fehlt nur noch eine zusätzliche(!) Implementierung eines speziellen (Spar-)Zigbee-Modus: nämlich ZLL *) für die Verbindung zur Hue-Bridge, die immerhin einen hohen Marktanteil hat.
*) Zigbee light link (ZLL) Ein offizieller Zigbee Modus der in einer bestimmen Gruppe von Beleuchtungs-orientierten Herstellern verwendet wird (zB Busch-Jaeger usw)
