[Adapter] Shelly Adapter mit MQTT

[dos1973]

Ja, bei mir auch USG und 2 AP

Das Netz habe ich schonmal via Vlan separiert und alle shellys auf die beiden AP‘s verteilt. Mqqt mit iobroker funktioniert

Jetzt mal sehen ob ich die App zum laufen kriege.

[Stuebi]

@dos1973 sagte in [Adapter] Shelly Adapter mit MQTT:

Ja, bei mir auch USG und 2 AP

Das Netz habe ich schonmal via Vlan separiert und alle shellys auf die beiden AP‘s verteilt. Mqqt mit iobroker funktioniert

Jetzt mal sehen ob ich die App zum laufen kriege.

aber warum hast Du für jedes Stockwerk ein eigens WLAN erstellt?

[dos1973]

@Stuebi
Ich schaffe es nicht dass die shelly aus OG1 am Ap-OG1bleiben.
Und umgekehrt.

Ich habe mit der Sendestärke und minRssi gespielt, die verbinden sich einfach wild.
Ich habe dann einen Shelly aus dem OG1 der auf dem AP-OG2 mit ganz schwacher Verbindung hängt, obwohl der AP-OG1 gefühlt viel näher dran ist.

Ist über ein vlan Tag auf ein dhcp Netz gespannt...

[Apropo]

Guten Morgen,

ich habe gestern einen neuen Shelly Plug S eingebunden und in dem Zug auch direkt ein Firmware Update aller Shellys gemacht. Seitdem bekomme ich den Stromverbrauch in IoBroker nicht mehr angezeigt.
Ich dachte erst es stimmt was nicht mit der neuen Steckdose, aber eben habe ich dann gemerkt, dass die alte an der Waschmaschine, die gestern noch angezeigt hat, auch keinen Stromverbrauch mehr hergibt. Wenn ich über die Weboberfläche auf die Shellys gehe wird mir aber der Verbrauch angezeigt. Also denke ich es hat mit dem Firmware Update von gestern zu tun und es wird nicht über mqtt übertragen. Schalten kann ich die Stecker über IoBroker aber problemlos und sie sind auch per mqtt verbunden.Die aktuelle Firmware ist die 20200601-123307/v1.7.0@d7961837

Ist da was bekannt, oder hat jemand ne Idee was ich machen kann?

[Stuebi]

@Apropo , laut Shelly Dokumentation hat sich bei MQTT nichts geändert beim Shelly Plug für die States Energy und Power. Vielleicht ein Fehler in der Firmware?

[Apropo]

@Stuebi Sehr seltsam. Nachdem ich eben über 2 Stunden rumprobiert und getestet hab und dann aufgegeben / PC ausgemacht habe, bekam ich gerade plötzlich von Alexa gesagt, dass die Waschmaschine fertig ist. Hab dann verwundert den PC wieder angeschmissen und nachgeschaut. Auf einmal wird der Stromverbrauch angezeigt. Ich kann es mir nicht erklären, aber gebe erst mal Entwarnung und beobachte es weiter.

[actionbyte]

Ich habe einen Shelly1 als Detached Switch als Buttton Type konfiguriert. Leider sehe ich den Zustand vom Schalteingang nicht über MQTT, weder im MQTT Adapter, noch im Shelly Adapter. Der Datenpunkt "Input" bleibt immer auf "false". Spannungsversorgung und Potential am SW ist 12 Volt DC. Andere Infos werden korrekt angezeigt.
Welche Einstellung sind sonst noch relevant um den iIngang im MQTT korrekt darzustellen?

[valbuz]

@actionbyte Hast Du schon eine Lösung gefunden? Bei mir dasselbe.

Danke
Pat

[actionbyte]

@valbuz Ja, hab ne Lösung: ich hatte 12V+ an SW angelegt und geschaltet. Aber wie bei anderen GPIOs, muss auch beim Shelly eben Masse (L-) an SW gelegt werden. Also mein Fehler, hatte ich aber auch nicht anders erwartet.

[Bibo1984]

Hallo Zusammen,
vermutlich bin ich nur blind oder zu doof.... aber ich finde die MQTT einstellung in der Shelly App nicht.
ich habe den Eintrag bei "Internet/Security" nicht. muss ich das irgendwo erst aktivieren?

[harrym]

@Bibo1984 direkt via IP vom Shelly auf die GUI zugreifen.

[Bibo1984]

@harrym Danke dir Hätte ich auch selbst drauf kommen können

[Diggewuff]

@Denis1988 said in [Adapter] Shelly Adapter mit MQTT:

Hallo,

Hab auch mal ne Frage zum longpress. Ist es normal dass ich nach dem longpress auf true gesprungen ist, ich erst einen kurzen Tastendruck machen muss um longpress erneut nutzen zu können. Wenn longpress bereits auf True steht und ich ein zweites Mal einen longpress mache aktualisiert sich der Wert bei mir nicht. Der Zeitstempel bleibt auf der gleichen Uhrzeit.

@e-s said in [Adapter] Shelly Adapter mit MQTT:

@Denis1988
Leider Fehler in der Shelly Firmware, siehe auch hier
Ich stand mit einem dev von shelly im Kontakt und deswegen gab es in der 1.5.6 einen Change dazu, leider brachte dies keine Besserung. Seit dem reagierten die aber nicht mehr auf meine Mails.
Vielleicht versuche ich es anfang des Jahres nochmal-

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.

[e-s]

@Diggewuff
Nutzt du die aktuelle Version aus dem latest?
Schau mal hier

Alternativ meine Lösung zu dem Thema, viel mächtiger als nur longpush.

[Stuebi]

@Diggewuff , man kann den Shelly Adapter für MQTT oder im CoAP Modus betreiben. Das Verhalten des Adapters im MQTT oder CoAP Modus soll identisch sein. Sonst kommen 1.000 Fragen hoch, warum funktioniert das in CoAP so und in MQTT anders. Aus diesem Grund kann und werde ich die Entwicklung nicht auseinanderlaufen lassen.

Jetzt zum Longpush.
Wird bei MQTT der Longpush ausgelöst, erhalte ich jedes Mal eine Meldung mit longpush = 1. Bei CoAP erhalte ich aber nicht nur eine Meldung zum Longpush = 1 sondern gleichzeitig auch zu allen anderen Sates wie z.B. Switch, Batterie, Temperatur, ….. Wird also Longpush gedrückt ist der Wert 1 in der CoAP Meldung, ändert sich nun z.B. ein anderer Wert (Bsp. Temperatur), wird wieder Longpush mit 1 gemeldet. Wenn ich das jetzt weitergebe, dann sieht es in ioBroker so aus, als ob jemand longpush gedrückt hat. Das ist aber nicht der Fall!

Shelly soll die Firmware in Ordnung bringen und den Status beim Longpush zurücksetzen sobald man aufgehört zu drücken. Dann ist das Problem auch im Adapter behoben.

[Diggewuff]

@Stuebi danke für deine Erklärung. Dennoch halte ich die aktuelle Verhaltensweise nicht für richtig.
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. Der Shelly sendet über CoAP Aktualisierungen aller Werte und über MQTT Aktualisierungen aller Werte. So sollte es auch in ioBroker abgebildet sein.
Wer detailliertere Informationen haben möchte sollte den geeigneteren MQTT Standard nutzen.
Wer das nicht braucht muss sich dann mit dem vereinfachten CoAP anfreunden.
Mein Anliegen ist nur das die Daten nicht vorab gefiltert werden sondern so zur Verfügung stehen wie das Gerät es vorsieht inklusive Aktualisierungen.

Suggestivfrage: Warum sollte man MQTT dann überhaupt nutzen wenn es auf die beschränkten Möglichkeiten von CoAP kastriert wird?
CoAP und MQTT sind unterschiedliche Protokolle mit unterschiedlichen Verhaltensweisen.

Zur Shelly Firmware: Der Shelly teilt zu jeder Tasterbetätigung mit ob es sich um einen Longpush gehandelt hat oder nicht. Ich sehe da keinen Fehler. Man müsste die verfügbaren Daten nur verwenden anstatt sie zu verwerfen.

[Diggewuff]

@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

JoschaMiddendorf created this issue in schmupu/ioBroker.shelly

closed Implementation of an option in the settings that allows MQTT users to receive updates of unchanged values. #209

[apollon77]

@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

[Diggewuff]

@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]

@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.