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.
Die Antwort im "Zitat" stammt vermutlich hierher: https://community.shelly.cloud/topic/9423-firmware-15x-sntp-change-default-server-to-timecloudflarecom
Es ist immer gut, wenn man Quellen angibt und auch kenntlich macht, wenn man kein Zitat bringt sondern den Text übersetzt hat.
Wie zufällig fand sich dort ein Frager...
Ich selbst verwende allerdings sowieso überwiegend etwas von ntp.org, also von den Servern von pool.ntp.org, europe.pool.ntp.org bzw auch de.pool.ntp.org
Ah, okay.
Zwei Links dazu:
1. hier im Forum in der Übersetzung als "Ankündigung" in der Rubrik "Artikel":
2. ... und das Original auf den Shelly-Api-Docs-Seiten (...shelly.cloud):
https://shelly-api-docs.shelly.cloud/gen2/changelog/#150-2025-02-20
Bleibt allerdings immer noch die Frage nach dem Warum.
Die zwei Beiträge bisher beantworten nicht die Frage nach dem geänderten default NTP Server, deshalb noch einmal:
Wird dazu {...} irgendwo irgend etwas erklärt / begründet?
Der Default NTP server ist in Version 1.5.1 geändert worden auf: time.cloudflarre.com
Das betrifft alle Gen2/3/4 Geräte, die das Update auf Version 1.5.1 erhalten.
Version 1.4.4 benutzte noch time.google.com als default.
Wird dazu zur Version 1.5.1 (Gen4 auch 1.5.99) irgend etwas erklärt / begründet?
Ohne die Möglichkeit der Offline- und rein lokalen Nutzung würden manche User Shellys gar nicht nutzen und nicht kaufen. Das ist ein sehr gutes und auch in der Zukunft unverzichtbares Feature.
Na bitte, klappt doch...
Es ist doch im Tempo etwa so wie bei den üblichen Zigbee-Koppelvorgängen auch.
Ich sehe hier auch bei näherem Hinschauen weder einen geschäftlichen noch geschäftsmäßigen Zweck in dieser Skript-Dokumentation.
Das muss auch bei näherem Hinschauen keineswegs direkt ersichtlich sein.
Es soll auch Leute geben, die sich über so eine Einführung freuen…
Wer würde das bezweifeln wollen, ändert aber nichts, insbesondere wenn hier die Seite aktiv beworben wird.
dafür meine kleine Skripteinführung
Ein kleiner Hinweis: Das Fehlen einer "Start"-Seite ala eichelsdoerfer.net bzw http://www.eichelsdoerfer.net oder ähnlich enthebt nicht der Impressums-Pflicht auf einer Subdomain wie zum Beispiel iotig.eichelsdoerfer.net. insbesondere, wenn dafür extra ein Let's Encrypt Zertifikat generiert wurde und die Seite aktiv betrieben und beworben wird.
curl ist standardmäßig in Windows 10/11 enthalten!
Gucke an und in den üblichen Linux-Distros muss man es extra installieren 
Jo_"kleiner Scherz am Rande"_Be
Die Umschaltung per 5xReset funktioniert aber ist alles andere als leicht wenn man nicht den richtigen "Takt" erwischt. Das PDF hilft da leider nicht wirklich weiter. Den Takt hab ich mir vom Video abgeschaut!
Also ich fand das überhaupt nicht schwierig. Das PDF beschreibt es doch genau so, wie es einfach geht. Das ist doch nun wirklich kein Problem. Dazu gibt es ein Video? Unglaublich, was es alles gibt
Auch den AP-Mode vermisse ich natürlich nicht. Und habe ihn nur beschrieben für den Fall, dass jemand die Umstellung auf Zigbee am Device vorgenommen hat, bevor er das Device im lokalen WLAN angemeldet hatte und das nachträglich erledigen will.
Schmerzich vermisse ich aber den ZLL-Modus zum integrieren ins HUE-System. Shelly ist bei mir bekannt für wirklich gute Softwareentwickler/-Entwicklung und für grosse Offenheit der Schnittstellen. Für Shelly dürfte es keinerlei Problem sein auch dieses Öko-System in das tolle Device zu integireren. Ich bitte wirklich herzlich darum, denn ich möchte mit einem zusätzlichen Zigbee-Stick nicht ein zusätziches Fass aufmachen müssen.
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"
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.
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?
Siehe diesen Beitrag: Zigbee aktivieren
Dok: https://www.shelly.com/de/blogs/docum…y-1pm-mini-gen4
User guide: https://kb.shelly.cloud/__attachments/…6a-5d99df125bc9
Siehe diesen Beitrag: Zigbee aktivieren
Dok: https://www.shelly.com/de/blogs/docum…y-1pm-mini-gen4
User guide: https://kb.shelly.cloud/__attachments/…6a-5d99df125bc9
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 und wo als Gruppe zusammenfassen? Da sich die TRV zum Beispiel per http steuern lassen. reicht in diesem Fall ein vierzeiliges Script um alle vier Ventile einzustellen.
wird einmal pro Tag der EMData-Speicher bzgl. der Werte des Vortags als CSV-Datei runtergeladen und analysiert. Dabei sind dann natürlich die fehlenden 58 Einträge auch aufgefallen.
Das werde ich mir auch ansehen. Aber wie gesagt: Mqtt liefert...
