Trotzdem braucht es einen Button im Zigbee Bereich der WebGUI meiner Meinung nach, um das Pairing zu starten. Das wird Shelly sicher hinkriegen und hoffentlich irgendwann nachliefern...
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.
-
-
Vielen Dank an die Produktverantwortlichen und das Entwicklungsteam! Tolle Arbeit!
So ganz kann ich die Begeisterung nicht teilen, denn es fehlt weiterhin die Möglichkeit, die Firmware als File herunterzuladen und selbst zu hochzuladen. Damit ist zum Beispiel das Zurückgehen auf ältere Versionen bei Fehler verbaut. Die Bereitstellung der Software als File ist eigentlich üblich und sollte möglich sein.
-
Das Shelly Zigbee macht ohne HUE zu unterstützen ergibt für mich keinen Sinn aber die werden sich wohl was dabei gedacht haben.
Naja, mit der Verbindung zur Hue Bridge und also Zigbee ZLL fallen natürlich alle zusätzlichen Funktionen des Shelly Device ausser dem simplen Schalten weg. Da werden sie sich gedacht haben, das machen wir nicht...
Aber diese Sicht der Shelly Entwickler ist nicht richtig:
- alle Daten, die über das simple Schalten hinausgehen, kann man ja auch per WLAN abfragen/geliefert bekommen vom Device
- Hue hat eine riesige Nutzerbasis, die würde sich Shelly damit erschliessen
- Die Anschaffung eines zusätzliches Zigbee Gateway zusätzlich zur Hue-Bridge nur für Shellys kommt für viele (mich eingeschlossen) nicht in die Tüte
- Ein simpler Schalter in der GUI im Bereich Zigbee würde das Problem ja lösen, denn als sie den Zigbee Modus einführten, haben sich die Entwickler ja schon mit den Zigbee Protokollen beschäftigt und kennen also auch ZLL wahrscheinlich genau.
Also Shelly: Bitte das ZLL Protokoll zusätzlich implementieren mit einem simplen Schalter in der GUI und bei der Gelegenheit auch einen Software-Schalter in der GUI im Bereich Zigbee einbauen, der das Device in den Pairing-Mode versetzt.
Danke
-
Ich vermute ein korruptes Filesystem des Update-Servers…
Oder das Update-File wude zwischenzeitlich entfernt.
-
Das deckt sich insoweit ja mit meiner Beobachtung. Ich vermute einen Fehler in 1.6.1.
-
Einfach kurz warten....
Ist 8 Stunden kurz genug?
Macadresse des Shellys
Ja klar ist die gleich, sonst ergäbe das ja für den Router ein neues Device... Aber wie gesagt, hier nicht das Thema
-
> "Maybe you have to add .....?id=0 to your request."
No, not to "Shelly.GetConfig". This is totaly clear.
But for example to "http://192.168.1.11/rpc/EM.GetStatus?id=0"
-
Try: http://192.168.1.11/rpc/Shelly.ListMethods and have a look at that list
Maybe you have to add .....?id=0 to your request.
-
Müssen nicht Devices der Gen 1 (Shelly Plug S gehört - glaube ich - dazu) nicht immer erst kalibriert werden?
-
Das verstehe ich, und es ist auch völlig ok. Aber es bleibt, dass deine Posts grössere Beachtung finden als manche anderen. Und in diesem Fall können sowieso nur die Shelly Entwickler selbst etwas dran fummeln. Es geht also darum, dies mit Hilfe einer grösseren Anzahl an Usern zu befördern. Zumal es - aus meiner Sicht - ein geringer Enwicklungsaufwand für Shelly ist, mit erheblichem Vorteil für Shelly, weil es die grosse Gruppe der Hue-Bridge-Besitzer für Shelly erschliesst.
-
Das dort Beschriebene hat hier - wie geschrieben - geklappt.
Würdest du bitte den Vorschlag der ZLL Implementierung unterstützen. Deine Stimme hat Gewicht.
-
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.