UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[41vsy]

Hi zusammen,

welche Übertragungsprotokolle nutzt ihr an euren Shelly? Welches Protokoll ist besonders zuverlässig?

VG Tim

[OpenSourceNomad]

@41vsy native api, esphome

[peterfido]

@41vsy
Hi,

ich nutze nur noch mqtt. Und das über mosquitto. Der mqtt-ioBroker-Adapter ist client. Läuft sehr zuverlässig.

[da_Woody]

@41vsy ich hab mit CoAP keine probleme, original FW

[OpenSourceNomad]

@peterfido said in Unterschiede / Vor- Nachteile Shelly Protokolle:

ich nutze nur noch mqtt.

Hatte ich auch gemacht bis vor etwa zwei/drei Jahren. Wenn es läuft, läuft es zuverlässig. Allerdings ist es, meiner Meinung nach, das mit Abstand Zeit- und Wartungsintensivste Protokoll. Mit dem mqtt-broker hat es einen weiteren (unnötigen) single-point-of-failure und grundsätzlich ist es halt ein über 20 Jahres altes Protokoll, so steht es eben auch um die usability.

Einen kurzen Vergleich was ein modernes Protokoll besser macht als mqtt findet sich hier.

@da_woody said in Unterschiede / Vor- Nachteile Shelly Protokolle:

ich hab mit CoAP keine probleme, original FW

Hatte ich selber nie im Einsatz. Kenne dieses Protokoll nur weil es mal negativ aufgefallen ist und neue Shellys es nicht mehr unterstützten (oder nur noch mit cloud zwang?) und das es mehrere Versionen gibt die nicht miteinander kompatibel sind (Stichwort Wildwuchs)?

@41vsy said in Unterschiede / Vor- Nachteile Shelly Protokolle:

Welches Protokoll ist besonders zuverlässig?

Ich behaupte mal frech: Alle hier genannten Protokolle sind zuverlässig, allerdings hängt die æchte Zuverlässigkeit von deiner vorhandenen WLAN Infrastruktur ab

[Samson71]

@opensourcenomad sagte in Unterschiede / Vor- Nachteile Shelly Protokolle:

(oder nur noch mit cloud zwang?) und das es mehrere Versionen gibt die nicht miteinander kompatibel sind (Stichwort Wildwuchs)?

Definitiv ohne Cloud und mit Originalfirmware. Mittels CUxD hat man die Dinger auf dem Weg bei Bedarf sogar "nativ" in der CCU. Von verschiedenen Versionen oder sogar dadurch verursachte Inkompatibilitäten ist mir auch nichts bekannt.

[da_Woody]

@opensourcenomad sagte in Unterschiede / Vor- Nachteile Shelly Protokolle:

das es mehrere Versionen gibt die nicht miteinander kompatibel sind

nachdem in der plusserie ein anderer chip drinnen ist, wird das meines wissens nach, über die FW zusammengeführt. soweit ich weis, kann man die plus in den grundfunktionen auch verwenden.
da größere problem wird der adapter sein. der wird neu geschnitzt werden müssen...

[OpenSourceNomad]

@samson71 said in Unterschiede / Vor- Nachteile Shelly Protokolle:

Definitiv ohne Cloud

Finde gerade leider nix auf die schnelle (am Mobilfunkdelefon), aber ich bin mir ziemlich scher hier im forum (und nicht vor zu langer Zeit) davon gelesen zu haben. Ein user hat "gewarnt" das neue shellys da CoIoT (=CoAP?) nur noch mit aktiver cloud können Oder war es ein Parallelbetrieb von CoIoT und MQTT? Egal, vielleicht wurde da elegant (wahrscheinlich ohne technischen Grund) der "erste" cloudzwang (bei bestimmter Konfiguration) eingeführt?

Das gute ist so lange die Teile ESP basiert sind lassen sie sich jederzeit befreien

@da_woody said in Unterschiede / Vor- Nachteile Shelly Protokolle:

größere problem wird der adapter sein. der wird neu geschnitzt werden müssen...

Habe mich gerade mal kurz durch die shelly docs geklickt und dort gibt es wohl mindestens zwei verschiedene (und miteinander inkompatible?) "CoIoT" Version.

Wie auch immer, mir ist das schon zuviel Wildwuchs. Ich bleibe bei meiner 0-Konfigurations-API von esphome. Da weis ich was ich habe, die funktioniert immer und läuft "automagisch" ohne jeglicher Konfiguration

[Samson71]

@opensourcenomad
Fakt ist, ich habe gar keinen Cloud-Zugang und mein Bruder, der nur Shellys benutzt, auch nicht. Den Shellys ist das "Raustelefonieren" auch dank kompletter Unifi-Umgebung technisch untersagt. Von daher kann ich da mit an Sicherheit grenzender Wahrscheinlichkeit einen Cloudzwang ausschließen.

[da_Woody]

@opensourcenomad sagte in Unterschiede / Vor- Nachteile Shelly Protokolle:

der "erste" cloudzwang (bei bestimmter Konfiguration) eingeführt.

das wäre mir absolut neu.
es gibt aber gute übersichten von den änderungen auf den seiten im unteren drittel.:
Shelly1
Shemmy1PM
da siht man, daß mit MQTT auch (gleichzeitig) cloudbetrieb möglich ist. von zwank keine rede.

[SSW-mcor]

@da_woody, @opensourcenomad, @Samson71 Ich verwende auch CoAP und auch ganz ohne Cloud.

[da_Woody]

@ssw-mcor das wirds IMHO auch weiter so tun, auch wenn CoAP weg fällt.

weiterer vorteil, gleichzeitig im WLAN ansprechbar und acesspoint verwendbar. ein resetknopf, kein gekünstel mehr bei einem echten hardreset.

[SSW-mcor]

@da_woody sagte in Unterschiede / Vor- Nachteile Shelly Protokolle:

das wirds IMHO auch weiter so tun, auch wenn CoAP weg fällt.

[BananaJoe]

@41vsy Alle Shelly die es unterstützen habe ich auf Tasmota umgeflasht und nutze dort MQTT per Mosquitto und den MQTT-Adapter als Client in ioBroker.

Hauptgrund war die native Unterstützung von Alexa, Siri und Google etc. ohne Cloud (Tasmota kann nativ Lampe oder Steckdose simulieren).

Alle anderen Geräte (3 EM und Shelly Button) per Shelly Adapter der auf CoAP and http steht.
Bei den Geräten habe ich immer zusätzlich MQTT mit eingetragen, aber beim 3EM sind die Werte aus meiner Sicht im Adapter besser aufbereitet.
Die Buttons hatte ich mir gekauft weil ich das damals toll fand das die per WLAN laufen.
Ist total doof, dauert "ewig" nach der betätigung bis sich das Ding im WLAN eingebucht und die Meldung versendet hat.
Von 2 Stück liegt einer ungenutzt in der Bastelkiste, der andere hängt am Schlüssel vom Briefkasten und dient dazu die "Es liegt Post im Briefkasten"-Meldung wieder zurück zu stellen.
Ansonsten nutze ich inzwischen ZigBee Buttons diverser Colour, gerade die Ikea Shortcut Buttons für 6 Euro halte ich Preislich für ungeschlagen und ein angehängtes Skript ist schon durchgelaufen bevor ich den Finger wieder vom Knopf genommen habe.

Und einen Shelly 2.5 habe ich für meine einzige elektrische Jalousie. Den habe ich auch auf der Shelly Firmware gelassen. In Tasmota war mir das mit den Endpunkten zu umständlich und bei der Jalousie funktionieren die eigenen Endabschaltungen nicht mehr. Durch Stromunterbrechung habe ich den unteren Punkt im Shelly programmiert bekommen, den oberen Punkt habe ich zusätzlich per mechanischen Endschalter abgesichert.

Ich habe - aus meiner Zeit der Begeisterung das Shelly alles mit WLAN macht - auch 4 Door/Window-Sensoren.
Die sind mit dem gleichen Problem wie der Button behaftet. Wenn ich da eine Tür öffne bin ich einmal durch die Wohnung und zurück bis er das meldet. Per ZigBee hab ich die Tür noch nicht ganz geöffnet. Vorteil an den Door/Window ist das die auch den Neigungswinkel erfassen, die könnten also melden ob ein Fenster geschlossen, offen oder gekippt ist.

[da_Woody]

@bananajoe sagte in Unterschiede / Vor- Nachteile Shelly Protokolle:

bei der Jalousie funktionieren die eigenen Endabschaltungen

wenn der 2.5er richtig kalibriert ist, brauchts keine endschalter.
der button ist bißchen zäh, aber wenn er am ladegerät hängt, tuts.
meine DW reagieren unter 1sec. dazu sollte aber auch die IP fix im shelly eingetragen sein. wie bei allen batterie betriebenen shellys...

[BananaJoe]

@da_woody sagte in Unterschiede / Vor- Nachteile Shelly Protokolle:

@bananajoe sagte in Unterschiede / Vor- Nachteile Shelly Protokolle:

bei der Jalousie funktionieren die eigenen Endabschaltungen

wenn der 2.5er richtig kalibriert ist, brauchts keine endschalter.
der button ist bißchen zäh, aber wenn er am ladegerät hängt, tuts.
meine DW reagieren unter 1sec. dazu sollte aber auch die IP fix im shelly eingetragen sein. wie bei allen batterie betriebenen shellys...

Da hast du Recht ... aber ... es ist kompliziert.
Ich habe ich schlichtweg nicht getraut den Shelly anhand des Stromverbrauches den oberen Abschaltzeitpunkt finden zu lassen. Ich hatte nicht mehr so viel Vertrauen in die vorhandenen mechanischen Sperren. Wollte aber auch keine 60 Euro in ein Programmiergerät für die Jalousie stecken (ohne zu wissen ob das auch funktioniert), die Jalousie ist wohl so um die 25 Jahre alt.

Ich hatte den Shelly nach der Methode "Strom unterbrechen" eingestellt, für unten hat das auch perfekt funktioniert, für oben halt nicht.
Zufällig lief das Stromversorgungskabel für die Jalousie eh an der passenden Stelle vorbei ... kleine Halterung für einen mechanischen Endschalter war schnell im 3D Drucker gedruckt und ich konnte den oberen Punkt millimetergenau einstellen. Jetzt bleibt die Jalousie stehen und der Shelly will noch 1 bis 2 Sekunden weiter machen (97%).

Und der ganze Aufwand nur damit ich faul auf dem Sofa liegen bleiben kann wenn mir die Sonne ins Gesicht scheint ...
Und naja, die Sache mit den fehlenden Endschaltpunkten nervte mich auch schon seit 13 Jahren.

[da_Woody]

@bananajoe sagte in Unterschiede / Vor- Nachteile Shelly Protokolle:

Jalousie ist wohl so um die 25 Jahre alt
nervte mich auch schon seit 13 Jahren

dann wirds wohl auch weiterhin so bleiben...

[OpenSourceNomad]

@samson71 said in Unterschiede / Vor- Nachteile Shelly Protokolle:

Den Shellys ist das "Raustelefonieren" auch dank kompletter Unifi-Umgebung technisch untersagt.

Für mich ist software/firmware die das (leider neumodische) "nach hause telefonieren" nicht komplett deaktivieren lässt ebenfalls tabu. Die stock shelly firmware ist da ja leider auch ein bekannter Kandidat der selbst wenn man alle Optionen abwählt immer noch gerne in's Internetz will.

Das die Hardware für die Steuerung im eigenen Hauses in ein VLAN ohne jeglichen Internetzugang gehört, sollte ja sowieso jedem klar sein. Das ich dafür ebenfalls (ausschließlich) auf open source firmware vertraue wurde mir ja gerade eben erst wieder bestätigt:

"Neun WLAN-Router bekannter Hersteller fanden sich kürzlich unter Laborbedingungen im Sicherheitstest wieder – mit verheerenden Ergebnissen im Bereich IT Security: Insgesamt 226 potenzielle Sicherheitslücken wurden auf den millionenfach verbreiteten Geräten von Asus, AVM, D-Link, Netgear, Edimax, TP Link, Synology und Linksys gefunden.
[...]
Die größte Gefahr neben den herstellerseitig eingebrachten Schwachstellen ist die Nutzung nach dem Motto ‚plug, play and forget‘“

Quelle: https://www.iot-inspector.com/de/blog/router-sicherheits-test-2021/

Wer proprietär kauft (ohne eine Möglichkeit auf "Befreiung" = Open Source Firmware/Software) besitzt weder das Produkt noch hat er ein Recht auf Reparatur. Beides sind für mich aber Grundvoraussetzungen für eine Anschaffung, weswegen es bei mir immer wieder auf (gebrauchte) Hardware hinausläuft die sich "komplett" (manchmal leider nicht ganz ohne Binärblobs, speziell wenn WLAN im Spiel ist) mit Open Source Firmware/Software betreiben lässt.

@da_woody said in Unterschiede / Vor- Nachteile Shelly Protokolle:

da siht man, daß mit MQTT auch (gleichzeitig) cloudbetrieb möglich ist. von zwank keine rede.

Vielleicht hatte ich da tatsächlich was verdreht

@tuskam said in Shelly mit Parser auslesen:

Shelly und MQTT — Die originale Firmware enthält auch einen MQTT-Stack, ... Dieser Betrieb ist aber nicht zeitgleich mit der Shelly-Cloud möglich ..

...war wahrscheinlich der Kommentar den ich falsch im Hirn abgespeichert hatte

@da_woody said in Unterschiede / Vor- Nachteile Shelly Protokolle:

weiterer vorteil, gleichzeitig im WLAN ansprechbar und acesspoint verwendbar.

Das liegt übrigens einfach daran das alle esp's (sowohl die 82xx als auch 32er) den STA+AP modus unterstützen und hat grundsätzlich rein gar nichts mit der shelly fw zu tun.
Deswegen eigenen sich die (esp) Teilchen ja auch für "nette" Spielereien wie z.B. EvilTwin, Deauth und beim esp32 sogar für handshake captures! Aber halt, wir sind ja in Deutschland, Hackertools sind hier ja verboten und deswegen nicht existent! Nicht's gesehen, nichts gehört, bitte weiter gehen

@da_woody said in Unterschiede / Vor- Nachteile Shelly Protokolle:

das wirds IMHO auch weiter so tun, auch wenn CoAP weg fällt.

Nur mal für mein Verständnis. Shellys "CoIoT" (="CoAP"?) ist doch nichts anderes als eine (rest?) api welche über http(s) erreichbar ist? Ist die schon abgekündigt oder warum fällt die weg?

Esphome hat übrigens auch eine rest api (für Menschen die sowas brauchen )

[da_Woody]

@opensourcenomad sagte in Unterschiede / Vor- Nachteile Shelly Protokolle:

Das liegt übrigens einfach daran das alle esp's (sowohl die 82xx als auch 32er) den STA+AP modus unterstützen und hat grundsätzlich rein gar nichts mit der shelly fw zu tun.

grundsätzlich nicht, aber bisher halt nicht unterstützt.

Nur mal für mein Verständnis. Shellys "CoIoT" (="CoAP"?) ist doch nichts anderes als eine (rest?) api welche über http(s) erreichbar ist?

war von mir missverständlich geschrieben. wegfallen würde war gemeint. sorry...
einen vergleich alt und neu hat Sascha auf youtube gemacht.