[Adapter] Shelly Adapter mit MQTT
-
@Diggewuff sagte in [Adapter] Shelly Adapter mit MQTT:
Der ioBroker und die installierten Adapter sind nicht dafĂŒr zustĂ€ndig um darĂŒber zu entscheiden welche Informationen relevant sind, sondern dafĂŒr die Informationen die verfĂŒgbar sind zusammenzutragen.
Der ioBroker kennzeichnet, absichtlich um dem von dir beschriebenen MissverstĂ€ndnis vorzubeugen, bei allen Aktualisierungen ob es sich um reine Aktualisierungen oder Ănderungen handelt. Daher finde ich das Aktualisierungen nicht verworfen werden sollten nur weil sie keine Ănderungen sind. Wenn jemand nur auf Ănderungen reagieren möchte kann er selber entsprechend einschrĂ€nken.Möchte speziell dazu mal meinen Senf dazu geben. Die Antwort ist in meinen Augen ein klares "kommt darauf an". Vor allem bei Adaptern die einen grossen State-Update Traffic mit "identischen Daten" machen kommt regelmĂ€ssig dieses Thema auf. Eine hohe Anzahl von State updates sorgen fĂŒr Last CPU-technisch, sorgen fĂŒr erhöhtes I/O (was vor allem bei SD Karten Systemen immer so eine Sache ist) und je nachdem auch zu gefĂŒhlt langsameren Systemen. Daher gibt es mehrere Adapter, die aus diesen Ăberlegungen heraus bewusst es genau so machen wie der Shelly Adapter - meistens weil es andere User gab deren Systeme mit vielen "unnötigen Updates" ĂŒberfordert waren.
Es ist also eine Balance und wenn ein Entwickler das so entscheidet dann ist das im ersten Schritt mal nicht falsch. Bei Shelly kommen die COAP Messages teilweise im Sekundentakt ... Du WILLST nicht das der Adapter diese ganzen Ănderungen immer ungefiltert weitergibt. Von daher ist diese genrelle Entscheidung im Falle des Shelly Adapters in meinen Augen vollkommen gerechtfertigt.
Das das jetzt bei der "Longpush" Funktion so eine Nebeneffekt hat ist blöd und da muss man jetzt ĂŒberlegen wie man das angeht. Auch das @Stuebi Coap und MQTT "identisch " funktionieren haben will ist nachvollziehbar. Und die Suggestivfrage (sorry) wenig hilfreich :-)
Ingo
@apollon77
Hallo Ingo,
danke fĂŒr dein konstruktives Feedback. Das Argument bezĂŒglich der Updates im Sekundentakt kann ich nachvollziehen.
Gibt es im io Broker eigentlich eine Möglichkeit Systemevents auf auf Instanzebene auf Ănderungen zu beschrĂ€nken?
MQTT arbeitet da natĂŒrlich effizienter.
Daher habe ich mich in meinem pull request fĂŒrs erste darauf beschrĂ€nkt, die Updates unter Verwendung von MQTT optional zur VerfĂŒgung zu stellen.
Was hĂ€lst du von der Idee?Ps: Sugestivfragen lasse ich nĂ€chstes mal weg. Da war ich gestern Abend etwas erregt ĂŒber geringe Bereitschaft sich der Herausforderung anzunehmen.
-
@apollon77
Hallo Ingo,
danke fĂŒr dein konstruktives Feedback. Das Argument bezĂŒglich der Updates im Sekundentakt kann ich nachvollziehen.
Gibt es im io Broker eigentlich eine Möglichkeit Systemevents auf auf Instanzebene auf Ănderungen zu beschrĂ€nken?
MQTT arbeitet da natĂŒrlich effizienter.
Daher habe ich mich in meinem pull request fĂŒrs erste darauf beschrĂ€nkt, die Updates unter Verwendung von MQTT optional zur VerfĂŒgung zu stellen.
Was hĂ€lst du von der Idee?Ps: Sugestivfragen lasse ich nĂ€chstes mal weg. Da war ich gestern Abend etwas erregt ĂŒber geringe Bereitschaft sich der Herausforderung anzunehmen.
@Diggewuff Am Ende ist jeder Adapter-Entwickler der "Guard" und muss fĂŒr das implementierte System und Protokoll solche Entscheidungen treffen. Ich glaube nicht das es "geringe Bereitschafft" ist in dem Fall.
-
@Diggewuff Am Ende ist jeder Adapter-Entwickler der "Guard" und muss fĂŒr das implementierte System und Protokoll solche Entscheidungen treffen. Ich glaube nicht das es "geringe Bereitschafft" ist in dem Fall.
-
Hallo zusammen,
erst einmal danke fĂŒr den super tollen Adapter :)
Ich hab am Wochenende einen:
https://shelly.cloud/products/shelly-button-1-smart-home-automation-device/connected und freute mich, dass dieser auch funktioniert.
Der Buttonklick wird unter der variable "Event" angezeigt.
S fĂŒr Short
SS fĂŒr 2x Short
usw.Allerdings wird (wenn ich es richtige verstehe) (vielleicht mach ich auch etwas falsch?)
Wenn ich zuerst einmal kurz drĂŒcke und warte und dann noch einmal kurz drĂŒcke, nicht zweimal
der Wert "s" gesetzt, sondern nur einmal.
Wenn ich also auf die Variable "Event" "Lausche" bekomme ich den zweiten Klick (wenn es der gleiche Event wie der VorgÀnger ist) nicht mit.Sollte man das anders Abfragen?
Oder sollte das Event ggf. doch doppelt gesetzt werden?Viele GrĂŒĂe
BB -
Hallo zusammen,
erst einmal danke fĂŒr den super tollen Adapter :)
Ich hab am Wochenende einen:
https://shelly.cloud/products/shelly-button-1-smart-home-automation-device/connected und freute mich, dass dieser auch funktioniert.
Der Buttonklick wird unter der variable "Event" angezeigt.
S fĂŒr Short
SS fĂŒr 2x Short
usw.Allerdings wird (wenn ich es richtige verstehe) (vielleicht mach ich auch etwas falsch?)
Wenn ich zuerst einmal kurz drĂŒcke und warte und dann noch einmal kurz drĂŒcke, nicht zweimal
der Wert "s" gesetzt, sondern nur einmal.
Wenn ich also auf die Variable "Event" "Lausche" bekomme ich den zweiten Klick (wenn es der gleiche Event wie der VorgÀnger ist) nicht mit.Sollte man das anders Abfragen?
Oder sollte das Event ggf. doch doppelt gesetzt werden?Viele GrĂŒĂe
BB -
@BlueBook , die Frage gab es schon ein einmal und wurde an Shelly weitergereicht. Wenn ich mich richtig erinnere, muss man warten bis der Button nicht mehr leuchtet. Anders geht es leider nicht.
@Stuebi Danke fĂŒr die Info.
Ja, mit der Verzögerung hatte ich zuerst auch nicht gerechnet, ist fĂŒr mich aber okay und auch verstĂ€ndlich, da der Button zum Strom sparen nicht dauerhaft ins WLAN connected ist.
Jeder Event braucht so seine 2-3 Sekunden. Man kann aber einstellen, wie lange der Button nach dem Klick aktiv bleibt - so könnte man schnelle Klicks hintereinander beschleunigen.Vielleicht hatte ich mich mit meiner Frage undeutlich ausgedrĂŒckt.
Folgendes Skript:
wird, wenn man zwei mal hintereinander die gleiche Aktion ausfĂŒhrt, nur einmal getriggert.
Anscheinend wird der Wert in der Variable "Event" nicht neu gesetzt - wenn der gleiche Event ein zweites Mal getriggert wird.
Zumindest steht in der Objektansicht bei Event noch der alte Zeitstempel.Das man zweimal hintereinander aber die gleich Aktion ausfĂŒhrt - wenn man z.B. eine Lampe darĂŒber ein- und ausschaltet - halte ich fĂŒr eine "normale" Anforderung. Diese bekomme ich aber schlecht abgebildet. Dies ĂŒber die Uptime des Buttons abzufragen - wĂ€re schon ein starker Workaround.
Daher meine Frage:
Hab ich hier einen Denkfehler?
Hat einer dieses Problem schon gelöst?
Oder sollte das Event nicht besser doppelt aus dem Adapter gesetzt werden, auch wenn es gleich ist?GruĂ
BB -
@Stuebi Danke fĂŒr die Info.
Ja, mit der Verzögerung hatte ich zuerst auch nicht gerechnet, ist fĂŒr mich aber okay und auch verstĂ€ndlich, da der Button zum Strom sparen nicht dauerhaft ins WLAN connected ist.
Jeder Event braucht so seine 2-3 Sekunden. Man kann aber einstellen, wie lange der Button nach dem Klick aktiv bleibt - so könnte man schnelle Klicks hintereinander beschleunigen.Vielleicht hatte ich mich mit meiner Frage undeutlich ausgedrĂŒckt.
Folgendes Skript:
wird, wenn man zwei mal hintereinander die gleiche Aktion ausfĂŒhrt, nur einmal getriggert.
Anscheinend wird der Wert in der Variable "Event" nicht neu gesetzt - wenn der gleiche Event ein zweites Mal getriggert wird.
Zumindest steht in der Objektansicht bei Event noch der alte Zeitstempel.Das man zweimal hintereinander aber die gleich Aktion ausfĂŒhrt - wenn man z.B. eine Lampe darĂŒber ein- und ausschaltet - halte ich fĂŒr eine "normale" Anforderung. Diese bekomme ich aber schlecht abgebildet. Dies ĂŒber die Uptime des Buttons abzufragen - wĂ€re schon ein starker Workaround.
Daher meine Frage:
Hab ich hier einen Denkfehler?
Hat einer dieses Problem schon gelöst?
Oder sollte das Event nicht besser doppelt aus dem Adapter gesetzt werden, auch wenn es gleich ist?GruĂ
BB@BlueBook ich glaube das es sich da um das gleiche Problem handelt, das ich auch habe.
@Diggewuff sagte in [Adapter] Shelly Adapter mit MQTT:
Der Shelly sendet einen wiederholten Longpress, aber dieser lĂ€sst sich nicht auswerten da der Adapter nur werte aktualisiert, wenn sie sich geĂ€ndert haben. Werte die (nur) aktualisiert werden, werden absichtlich verworfen. Daher ist der Longpress nicht nutzbar. Ich habe das Thema einmal auf GitHub platziert und wĂŒrde mich dort ĂŒber Feedback dazu freuen, ob Ihr das so fĂŒr sinnig haltet, oder ob Ihr auch denkt, dass Aktualisierungen die ĂŒber MQTT oder CoAP eintreffen auch in die ioBroker states geschrieben werden sollten.
Diese Funktionsweise habe ich in einem Fork des Adapters angepasst, sodass man bei Verwendung von MQTT mit einem Haken in den Instanzeistellungen wÀhlen kann, ob die werte auch aktualisiert werden sollen.
Wenn du möchtest, kannst du die Funktion gerne mal ausprobieren, vielleicht hilft es dir ja.
https://github.com/JoschaMiddendorf/ioBroker.shelly
Ich habe die Funktion auch als Pull Request eingereicht, sodass sie in den Adapter ĂŒbernommen werden kann, wenn @Stuebi einverstanden ist, worauf ich sehr hoffe.
https://github.com/schmupu/ioBroker.shelly/pull/209
Der Request ist allerdings noch offen. -
@BlueBook ich glaube das es sich da um das gleiche Problem handelt, das ich auch habe.
@Diggewuff sagte in [Adapter] Shelly Adapter mit MQTT:
Der Shelly sendet einen wiederholten Longpress, aber dieser lĂ€sst sich nicht auswerten da der Adapter nur werte aktualisiert, wenn sie sich geĂ€ndert haben. Werte die (nur) aktualisiert werden, werden absichtlich verworfen. Daher ist der Longpress nicht nutzbar. Ich habe das Thema einmal auf GitHub platziert und wĂŒrde mich dort ĂŒber Feedback dazu freuen, ob Ihr das so fĂŒr sinnig haltet, oder ob Ihr auch denkt, dass Aktualisierungen die ĂŒber MQTT oder CoAP eintreffen auch in die ioBroker states geschrieben werden sollten.
Diese Funktionsweise habe ich in einem Fork des Adapters angepasst, sodass man bei Verwendung von MQTT mit einem Haken in den Instanzeistellungen wÀhlen kann, ob die werte auch aktualisiert werden sollen.
Wenn du möchtest, kannst du die Funktion gerne mal ausprobieren, vielleicht hilft es dir ja.
https://github.com/JoschaMiddendorf/ioBroker.shelly
Ich habe die Funktion auch als Pull Request eingereicht, sodass sie in den Adapter ĂŒbernommen werden kann, wenn @Stuebi einverstanden ist, worauf ich sehr hoffe.
https://github.com/schmupu/ioBroker.shelly/pull/209
Der Request ist allerdings noch offen.@Diggewuff , Shelly stellt es sich wie folgt vor um Events wie Longpush / Shortpush abzufragen:
Right now such events are for example shortpush/longpush of buttons â devices will send a property of type âEVâ to denote the exact event type
(âSâ = shortpush, âLâ = longpush), and a property of type âEVCâ that will increment itâs value when a new event occurs (e.g. to be able
to know that two consecutive longpushes are actually two separate events). Please see âInput eventâ and âInput event counterâ in the
property list below for additional information.
In the future, itâs possible that a type âEVVâ (Event validity) will be added too, to denote how long an occurred event should be
considered âactiveâ (e.g. for motion, vibration, etc.).Es ist zusĂ€tzlich zum Event der Event Counter laut Herstellervorgaben zu berĂŒcksichtigen.
ioBroker auf Synology DS216+II im Docker Container
-
@Diggewuff , Shelly stellt es sich wie folgt vor um Events wie Longpush / Shortpush abzufragen:
Right now such events are for example shortpush/longpush of buttons â devices will send a property of type âEVâ to denote the exact event type
(âSâ = shortpush, âLâ = longpush), and a property of type âEVCâ that will increment itâs value when a new event occurs (e.g. to be able
to know that two consecutive longpushes are actually two separate events). Please see âInput eventâ and âInput event counterâ in the
property list below for additional information.
In the future, itâs possible that a type âEVVâ (Event validity) will be added too, to denote how long an occurred event should be
considered âactiveâ (e.g. for motion, vibration, etc.).Es ist zusĂ€tzlich zum Event der Event Counter laut Herstellervorgaben zu berĂŒcksichtigen.
@Diggewuff , ein kleines Update, ich habe Shelly gebeten, dass man analog zum MQTT Protokoll bei den CoAP Nachrichten nur die States in der payload mitschickt die sich wirklich Àndern und nicht imm alle states. Mit dieser kleinen Anpassung wÀre es ohne weiteres möglich, mehrere longpushes / shortpushes analog zu MQTT hintereinander auszuwerten.
Leider will der Shelly Entwickler von OpenHab diese Ănderung nicht :-( Ich habe parallel noch ein Ticket bei Shelly aufgegeben. Ich bin gespannt ob sich da etwas tut.
Das Lustige an der Geschichte ist, dass der Shelly DW2 mit Firmware 1.8 genau nur die Werte per CoAP liefert die angefasst wurden und nicht immer alle. Das ist aber ein Fehler in der Firmware :-( -
@Diggewuff , ein kleines Update, ich habe Shelly gebeten, dass man analog zum MQTT Protokoll bei den CoAP Nachrichten nur die States in der payload mitschickt die sich wirklich Àndern und nicht imm alle states. Mit dieser kleinen Anpassung wÀre es ohne weiteres möglich, mehrere longpushes / shortpushes analog zu MQTT hintereinander auszuwerten.
Leider will der Shelly Entwickler von OpenHab diese Ănderung nicht :-( Ich habe parallel noch ein Ticket bei Shelly aufgegeben. Ich bin gespannt ob sich da etwas tut.
Das Lustige an der Geschichte ist, dass der Shelly DW2 mit Firmware 1.8 genau nur die Werte per CoAP liefert die angefasst wurden und nicht immer alle. Das ist aber ein Fehler in der Firmware :-(@Stuebi danke fĂŒr deinen Einsatz. đ
Könntest du in deiner GitHub repository eventuell einen âlatestâ branch zur VerfĂŒgung stellen der jeweils den aktuellsten Release beinhaltet? Mir ist aufgefallen das der Master meist schon weiter ist als die releases.
Ein latest branch wĂŒrde es stark vereinfachen den Fork aktuell zu halten.
Beste GrĂŒĂe -
@Stuebi danke fĂŒr deinen Einsatz. đ
Könntest du in deiner GitHub repository eventuell einen âlatestâ branch zur VerfĂŒgung stellen der jeweils den aktuellsten Release beinhaltet? Mir ist aufgefallen das der Master meist schon weiter ist als die releases.
Ein latest branch wĂŒrde es stark vereinfachen den Fork aktuell zu halten.
Beste GrĂŒĂe@Diggewuff sagte in [Adapter] Shelly Adapter mit MQTT:
Ein latest branch wĂŒrde es stark vereinfachen den Fork aktuell zu halten.
Am besten arbeitest Du immer gegen Master - idealweise mergest DU auch wÀhrend deiner Entwicklung den Master immer in deinem Fork bzw rebased deine ARbeit auf Basis des Master - so ist es spÀter bei dem PR am einfachsten
-
@Stuebi Ich habe mal einen Pull Request gestellt, in dem ich die Anpassungen vorgenommen habe, um per Checkbox optional die Aktualisierungen die ĂŒber MQTT kommen zu nutzen. Diese zu nutzen stĂŒnde ja jedem frei und ohne Aktivierung Ă€ndert sich an der Verhaltensweise nichts.
Bitte sei so nett den Vorschlag nicht direkt zu verwerfen und teste die Anpassung wenigstens.
https://github.com/schmupu/ioBroker.shelly/pull/209@Diggewuff , ich habe die FunktionalitĂ€t Deines PRs in der Version 4.0.3 ĂŒberfĂŒhrt. Den Schalter "Update objects even if there is no value change" gilt nun fĂŒr CoAP, MQTT und http gleichermassen.
Kannst Du die Version 4.0.3 ĂŒber GitHub laden und bitte testen. -
@Diggewuff , ich habe die FunktionalitĂ€t Deines PRs in der Version 4.0.3 ĂŒberfĂŒhrt. Den Schalter "Update objects even if there is no value change" gilt nun fĂŒr CoAP, MQTT und http gleichermassen.
Kannst Du die Version 4.0.3 ĂŒber GitHub laden und bitte testen. -
@Diggewuff , ich habe die FunktionalitĂ€t Deines PRs in der Version 4.0.3 ĂŒberfĂŒhrt. Den Schalter "Update objects even if there is no value change" gilt nun fĂŒr CoAP, MQTT und http gleichermassen.
Kannst Du die Version 4.0.3 ĂŒber GitHub laden und bitte testen. -
@Stuebi
In 4.0.3 werden die Namen selbst umbenannter datenpunkte teilweise ĂŒberschrieben.@Diggewuff , ja das kann passieren, aber nur dann wenn im Shelly im Devicename oder Channelname etwas steht.
-
@BlueBook ich glaube das es sich da um das gleiche Problem handelt, das ich auch habe.
@Diggewuff sagte in [Adapter] Shelly Adapter mit MQTT:
Der Shelly sendet einen wiederholten Longpress, aber dieser lĂ€sst sich nicht auswerten da der Adapter nur werte aktualisiert, wenn sie sich geĂ€ndert haben. Werte die (nur) aktualisiert werden, werden absichtlich verworfen. Daher ist der Longpress nicht nutzbar. Ich habe das Thema einmal auf GitHub platziert und wĂŒrde mich dort ĂŒber Feedback dazu freuen, ob Ihr das so fĂŒr sinnig haltet, oder ob Ihr auch denkt, dass Aktualisierungen die ĂŒber MQTT oder CoAP eintreffen auch in die ioBroker states geschrieben werden sollten.
Diese Funktionsweise habe ich in einem Fork des Adapters angepasst, sodass man bei Verwendung von MQTT mit einem Haken in den Instanzeistellungen wÀhlen kann, ob die werte auch aktualisiert werden sollen.
Wenn du möchtest, kannst du die Funktion gerne mal ausprobieren, vielleicht hilft es dir ja.
https://github.com/JoschaMiddendorf/ioBroker.shelly
Ich habe die Funktion auch als Pull Request eingereicht, sodass sie in den Adapter ĂŒbernommen werden kann, wenn @Stuebi einverstanden ist, worauf ich sehr hoffe.
https://github.com/schmupu/ioBroker.shelly/pull/209
Der Request ist allerdings noch offen.@Diggewuff Danke fĂŒr den Hinweis und auch deine Erweiterungen!
Ich war gerade erfreut zu sehen, dass es eine neue Version gibt.
Hab auf diese upgedatet.Dabei kam folgendes im Log:
shelly.0 2020-08-23 17:09:52.951 info (10150) Delete old state: shelly.0.SHBTN-1#xxxxxxxxxx#1.Button.Input shelly.0 2020-08-23 17:09:52.878 error (10150) Cound not delete old state: shelly.0.SHBTN-1#xxxxxxxxx#1.Button.Input host.iobroker 2020-08-23 17:09:52.871 warn Objects 127.0.0.1:55783 Error from InMemDB: Error: ERROR delObject shelly.0.SHBTN-xxxxxxx.Button.Input: Not exists shelly.0 2020-08-23 17:09:52.373 info (10150) Shelly device 192.168.xxx.xxx (shellybutton1 / shellybutton1-xxxxxx / SHBTN-xxxxxxxxx) with CoAP connected!Da danach der Button zur keiner ZustandsĂ€nderung mehr im ioBroker fĂŒhrte, hab ich alle Instanzvariablen aus den Objekten und das Objekt gelöscht - ich hatte gehofft er erkennt den Button neu und legt diese neu an.
Leider ist das nicht passiert.
Der Button wird jetzt gar nicht mehr erkannt :/
War wohl doch eine dumme Idee ...Parallel hab ich die Firmeware des Buttons von 1.7 auf 1.8 erhöht - daher ist es jetzt leider schwer zu sagen, woran es liegt/lag.
Neustarts auf beiden Seiten haben leider nichts gebracht.
Wenn es ĂŒber Coap nicht lĂ€uft, ist es nicht schlimm.
Ich werde es die Tage dann auf MQTT umstellen - dass sollte ja funktionieren.Wollte euch nur hier das Feedback geben - ggf. hilft es ja :)
GruĂ
BB -
@Diggewuff Danke fĂŒr den Hinweis und auch deine Erweiterungen!
Ich war gerade erfreut zu sehen, dass es eine neue Version gibt.
Hab auf diese upgedatet.Dabei kam folgendes im Log:
shelly.0 2020-08-23 17:09:52.951 info (10150) Delete old state: shelly.0.SHBTN-1#xxxxxxxxxx#1.Button.Input shelly.0 2020-08-23 17:09:52.878 error (10150) Cound not delete old state: shelly.0.SHBTN-1#xxxxxxxxx#1.Button.Input host.iobroker 2020-08-23 17:09:52.871 warn Objects 127.0.0.1:55783 Error from InMemDB: Error: ERROR delObject shelly.0.SHBTN-xxxxxxx.Button.Input: Not exists shelly.0 2020-08-23 17:09:52.373 info (10150) Shelly device 192.168.xxx.xxx (shellybutton1 / shellybutton1-xxxxxx / SHBTN-xxxxxxxxx) with CoAP connected!Da danach der Button zur keiner ZustandsĂ€nderung mehr im ioBroker fĂŒhrte, hab ich alle Instanzvariablen aus den Objekten und das Objekt gelöscht - ich hatte gehofft er erkennt den Button neu und legt diese neu an.
Leider ist das nicht passiert.
Der Button wird jetzt gar nicht mehr erkannt :/
War wohl doch eine dumme Idee ...Parallel hab ich die Firmeware des Buttons von 1.7 auf 1.8 erhöht - daher ist es jetzt leider schwer zu sagen, woran es liegt/lag.
Neustarts auf beiden Seiten haben leider nichts gebracht.
Wenn es ĂŒber Coap nicht lĂ€uft, ist es nicht schlimm.
Ich werde es die Tage dann auf MQTT umstellen - dass sollte ja funktionieren.Wollte euch nur hier das Feedback geben - ggf. hilft es ja :)
GruĂ
BB -
@BlueBook , das kann ich nicht bestÀtigen. Ich habe gerade den Shelly Adapter in der Version 4.0.3 mit CoAP und MQTT und dem Button mit der Firmware 20200812-091606/v1.8.0@8acf41b0 getestet.
Es funktioniert alles wunderbar.@Stuebi Ich hab es gerade noch mal verglichen.
Gleiche Adapter-Versionen und gleiche Firmeware.
Keine Ahnung warum der Button nicht mehr möchte - lief zuerst super.Ich hab es eben auch noch einmal ĂŒber MQTT ausprobiert.
Der Button meldet sich erfolgreich an.
Es kommen sogar updateEvents, aber alle nur mit Event "s".
Ein komisches Verhalten von dem Button. Ich vermute, dass das Firmewareupdate nicht 100% geklappt hat? Ich hab gerade schon einen Reset probiert, er bleibt aber bei der Firmewareversion und löscht "nur" die Einstellungen.Ich hab es jetzt ĂŒber den direkt Aufruf der iobroker-RestApi vom Button beholfen, komischerweise funktioniert dies.
Alles nicht wichtig, aber bissel komisch schon.Liegt aber meiner Meinung nach am Button! und nicht am Adapter.
Schöne Woche euch noch!
GruĂ
BB -
@Stuebi Ich hab es gerade noch mal verglichen.
Gleiche Adapter-Versionen und gleiche Firmeware.
Keine Ahnung warum der Button nicht mehr möchte - lief zuerst super.Ich hab es eben auch noch einmal ĂŒber MQTT ausprobiert.
Der Button meldet sich erfolgreich an.
Es kommen sogar updateEvents, aber alle nur mit Event "s".
Ein komisches Verhalten von dem Button. Ich vermute, dass das Firmewareupdate nicht 100% geklappt hat? Ich hab gerade schon einen Reset probiert, er bleibt aber bei der Firmewareversion und löscht "nur" die Einstellungen.Ich hab es jetzt ĂŒber den direkt Aufruf der iobroker-RestApi vom Button beholfen, komischerweise funktioniert dies.
Alles nicht wichtig, aber bissel komisch schon.Liegt aber meiner Meinung nach am Button! und nicht am Adapter.
Schöne Woche euch noch!
GruĂ
BB -
Guten Morgen an die Community.
Ich bin neu im Forum, lese aber schon lÀnger eure BeitrÀge und diese konnten mir bereits mehrmals helfen.
Erst einmal vielen Dank fĂŒr die ganze Arbeit die alle Akteure hier bereits reingesteckt haben und alles kostenlos zur VerfĂŒgung stellen!!Nach dem ich mit dem IO-Broker in meiner Wohnung etwas rumgespielt habe, habe ich mich dann entschieden beim Hauskauf komplett auf das System zu setzen.
Hierzu habe ich rund folgende GerÀte im Einsatz:- Synology 218+
- Raspberry Pi
- 7x Shelly 4 Pro (4 per Cloud & 3 per MQTT)
- 10x Shelly 2.5
- 1x Shelly Dimmer
- 2x Shelly 1
- 2x Shelly 1PM
- 1x Sonoff 4
- 1x Sonoff Dual
- 3x Sonoff Mini
- 1x Ring-Klingel
- diverse Echo-GerÀte
- Shelly I-3 --> Derzeit nur zu Testzecken
Ich habe sĂ€mtliche Kabel in die UV gezogen und dort hardwaremĂ€Ăig verdrahtet.
Nun zu meinem eigentlichen Problem:
Ich habe letztes WE den Shelly-Adapter geupdatet, in der Hoffnung, dass der I3 funktioniert.
Im ersten Moment waren alle Shellys doppelt in der Liste und auf ihren ursprĂŒnglichen Namen benannt. Die Namen konnten nicht unbenannt werden.
Dieses Problem wurde mit der V4-0-2 behoben
Die doppelten Eintragungen habe ich per Hand gelöscht
Soweit so gut
Nun ist mein Problem, dass die drei GerĂ€te die per MQTT betrieben werden nicht mehr ĂŒber den Shelly-Adapter arbeiten können. Im MQTT-Adapter kann ich aber keine Relais steuern.
Das heiĂt ich sehe zwar ob die Lampen an sind, aber ich kann weder ĂŒber den Broker, noch ĂŒber Alexa die GerĂ€te ansteuern. Leider kann ich in den Einstellungen des Shellys die MQTT-Einstellungen nicht zurĂŒcksetzen, da es so aussieht als ob dort keine EintrĂ€ge vorhanden sind.
Beim Hardware-Reset eines GerĂ€ts (Shelly 4 - Pro) ist dieses leider komplett kaputtgegangen. Auf meine E-Mail antwortet natĂŒrlich wider niemand.Hat jemand von euch einen Rat, wie ich wieder an die Einstellungen komme, oder hilft mir ggf. die Version 4-0-3? Derzeit habe ich etwas Schiss was abzudaten, da die Gefahr besteht, dass noch weniger funktioniert.
Hoffe, dass mir jemand helfen kann.Beste GrĂŒĂe
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen BeitrĂ€ge zu scrollen? Wenn du dich fĂŒr ein Konto anmeldest, kommst du immer genau dorthin zurĂŒck, wo du zuvor warst, und kannst dich ĂŒber neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und BeitrĂ€ge positiv bewerten, um anderen Community-Mitgliedern deine WertschĂ€tzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden đ
Registrieren Anmelden596
Online32.9k
Benutzer83.2k
Themen1.3m
BeitrÀge