[gelöst] Shelly2.5 Aktor Channelauswahl

[MarkoP]

Hallo, hab heute einen Shelly2.5-Aktor in Betrieb genommen und in Fhem über das Shelly-Modul eingebunden.
Soweit, sogut. Die Readings werden für den geschalteten Channel angezeigt. Das Reading für den Energieverbrauch auch.

Aber wenn ich jetzt das Device schalten will (on oder off) geht das nicht weil wohl nicht voreingestellt ist für welchen Channel der Befehl gilt.
Es kommt immer die Fehlermeldung:

Code Auswählen Erweitern

Error: wrong channel  given and defchannel attribute not set properly

Was muss ich bei defchannel eintragen?
Habs schon mit relay_0, 0, 1, channel 1 probiert. Alles ohne Erfolg.

Außerdem die Frage, was sollte für die Config eingetragen werden?

[amenomade]

Mit defchannel 0 oder defchannel 1 sollte es gehen. Genauso mit "set name on 0" oder "set name off 1"
Hast Du die attr model und mode gesetzt?

[MarkoP]

Hallo, ja habe ich gesetzt.
Hab auch den Fehler gefunden. Bei der Null hatte sich davor ein Leerzeichen eingeschlichen, dass ich nicht gesehen habe. Schäm!
"1" konnte nicht funktionieren, da der zweite Channel derzeit unbenutzt ist.

Wie spreche ich den zweiten Channel an ohne den defchannel zu ändern? Einfach dem "set xxx on" die Channelnummer anfügen, in dem Fall 1 für den zweiten Channel?
Was bewirkt die Einstellung unter Config? Da blick ich noch nicht durch?

[roedert]

Probier doch alternativ mal die Anbindung über MQTT ... mit dem entsprechenden Template bekommst du je Kanal ein Device. In meinen Augen ist MQTT auch sinnvoller, da der Status in "Echtzeit" zurückkommt und nicht wie beim Shelly-Modul über periodisches Pollen.

[MarkoP]

Hallo, danke für den Hinweis.
Doch seit ich weiß ist die Rückgabe über MQTT nicht vollständig, besonders was die Verbrauchswerte angeht. Und die sind für meine zukünftigen Planungen existenziell.
Auch müsste ich dann erstmal MQTT einrichten, da ich dieses bisher noch gar nicht nutze.

[amenomade]

Wie spreche ich den zweiten Channel an ohne den defchannel zu ändern? Einfach dem "set xxx on" die Channelnummer anfügen, in dem Fall 1 für den zweiten Channel?

Ja, oder "set xxx xtrachannels" benutzen. Siehe CommandRef.

Was bewirkt die Einstellung unter Config? Da blick ich noch nicht durch?

Da verstehe ich nicht, was Du meinst. Welches Config?

In meinen Augen ist MQTT auch sinnvoller, da der Status in "Echtzeit" zurückkommt und nicht wie beim Shelly-Modul über periodisches Pollen.

Das kann man auch mit dem Shelly Modul konfigurieren. Zitat aus Wiki

Damit der Aktor im Stande ist, irgendwelche Zustandsänderungen von sich aus an FHEM zu melden, müssen diese als REST-Befehle (also URL-Aufrufe, für Nicht-Experten) in der Konfigurationsoberfläche des Shelly-Aktors eingetragen werden. Siehe CommandRef.

Diese Config meintest Du im oberen Punkt?

[MarkoP]

Ich meine die Config, die ich unter den Internals sehe und die oben mit dem Set-Befehl gesetzt werden kann.
Doch ich weiß halt nicht was welche Einstellung genau bewirkt, dazu habe ich keine Dokumentation gefunden.

Das kann man auch mit dem Shelly Modul konfigurieren. Zitat aus Wiki

Das verstehe ich jetzt nicht. In welchem Zusammenhang bzw. worauf bezogen?
Ich weiß aus der Dokumentation, dass man die Aktoren entweder mit dem Shelly-Modul oder über MQTT ansteuern bzw. abfragen kann.
Laut Doku soll MQTT aber nicht alle Informationen liefern, speziell die Leistungsangeben nicht. Diese will ich aber ganz speziell abfragen um darauf andere Sachen zu schalten.
In welchem Zusammenhang dazu steht deine obige Aussage?

Wenn es nur um das Polling-Interval geht kann man das doch auch im Shelly-Modul beeinflussen und relativ klein einstellen.

[Beta-User]

Sei doch bitte so lieb und mache nicht so viele Trockenübungen oder setze irgendwas auf Vermutungsbasis in die Welt...

Jedenfalls nach meiner Kenntnis senden sowohl der Shelly1pm wie auch der 2.5-er ihre Verbrauchsdaten auch über MQTT (es gab allerdings eine kurze Zeit ein 2-er Modell mit lediglich einem kummulierten Verbrauchswert; der ist aber seit längerem nicht mehr erhältlich). Falls das nicht korrekt sein sollte, bitte die Fundstelle angeben!

MQTT ist übrigens auch nicht schwer, jedenfalls, wenn man die MQTT2_.*-Modulfamilie nimmt.

Und es ist auch kein "echtes" "entweder ... oder ..." betreffend das Shelly-Modul und MQTT, sondern geht auch nebeneinander (auch, wenn das vermutlich dauerhaft nicht sinnvoll ist).

Was mMn. nicht sinnvoll ist: das polling-Intervall zu verkürzen; sowas führt tendenziell nur dazu, dass es irgendwo zu Engpässen, vielen überfüssigen Events oder ähnlichem kommt.

[MarkoP]

Quellenangabe: https://wiki.fhem.de/wiki/Shelly-Aktoren

Gegen die Nutzung von MQTT mit den Shelly-Devices spricht, dass (mit dem aktuellen Firmware-Stand) weder alle Daten übermittelt werden, noch alle Konfigurationsänderungen durchgeführt werden können.

Das speziell die Verbrauchswerte betroffen sind habe ich irgendwo in einem Forum gelesen, da muss ich die Quelle für schuldig bleiben. Dafür hab ich zu viele Foren und Threats gelesen.

Beide Verfahren parallel zu betreiben sehe ich als Sinnfrei an. Worin der Unterschied besteht wenn der MQTT-Server alle 30 Sec. eine Info bekommt und das Pollig auf 30 Sec heruntergestellt wird müsstest du mir erläutern. Da sehe ich aktuell keinen Unterschied drin.

[roedert]

Worin der Unterschied besteht wenn der MQTT-Server alle 30 Sec. eine Info bekommt und das Pollig auf 30 Sec heruntergestellt wird müsstest du mir erläutern. Da sehe ich aktuell keinen Unterschied drin.

Polling ist generell immer nur eine Notlösung .... Es wird regelmäßig eine Webseite abgefragt und die Werte entsprechend ausgelesen.
Funktionell ist der Unterschied bei MQTT aber vor allem dann wenn der Shelley "von außen" per Taster geschaltet wird - bei MQTT bekommt FHEM das sofort mit, sonst erst beim nächsten Poll. 

[MarkoP]

Funktionell ist der Unterschied bei MQTT aber vor allem dann wenn der Shelley "von außen" per Taster geschaltet wird - bei MQTT bekommt FHEM das sofort mit, sonst erst beim nächsten Poll.

Das ist bei mir eigentlich eh nicht vorgesehen, da ich die Steuerung zentral über Fhem machen möchte.
Werde aber deine Hinweise in meine Überlegungen einfließen lassen und mich mit MQTT auseinander setzen.
Speziell auch weil mich die Wasser- und Gas-Sensoren von Shelly interessieren, die aber wohl nur über MQTT in Fhem integriert werden können.

[Beta-User]

Man kann die Shelly auch via HTTP Statusänderungen mitteilen lassen, es gibt da irgendwo eine Konfigurationsmöglichkeit dazu...

Was MQTT angeht: MQTT2_SERVER einrichten ist easy, warum das lt Shelly-Web-Interface eine "Experteneinstellung" sein soll, verstehe ich nicht, und der Rest in FHEM geht fast automatisch.

Quellenangabe: https://wiki.fhem.de/wiki/Shelly-Aktoren
Das speziell die Verbrauchswerte betroffen sind habe ich irgendwo in einem Forum gelesen, da muss ich die Quelle für schuldig bleiben. Dafür hab ich zu viele Foren und Threats gelesen.

Danke für den Link, muß ich mal drüber nachdenken, ob bzw. inwieweit das noch dem "Stand der Dinge" entspricht; der Hersteller hat da jedenfalls gewaltig an der MQTT-Seite geschraubt, diese Wiki-Seite ist nach meinem Empfinden früher entstanden.
Verbrauchswerte werden jedenfalls beim 1pm übermittelt, den habe ich selbst, den Rest kenne ich nur von der attrTemplate-Seite her, aber auch da habe ich den Eindruck, dass die Shelly generell auch via MQTT eher als (zu) "gesprächig" bezeichnet werden können... (ich würde gerne die Fahrenheit-Temperaturangabe gar nicht übermittelt bekommen, aber bisher ist mir nicht über den Weg gelaufen, wie man das auf der Aktor-Seite unterbinden kann).

Dass man für Konfigurationsänderungen auf das Web-Interface der Geräte selbst gehen muß, sehe ich nicht als nachteilig an, das ist ja in der Regel eine einmalige Angelegenheit; wünschen würde ich mir allerdings mehr Einstellmöglichkeiten für das was & wann via MQTT.

Beide Verfahren parallel zu betreiben sehe ich als Sinnfrei an. Worin der Unterschied besteht wenn der MQTT-Server alle 30 Sec. eine Info bekommt und das Pollig auf 30 Sec heruntergestellt wird müsstest du mir erläutern. Da sehe ich aktuell keinen Unterschied drin.

Wir sind uns einig, es macht keinen Sinn, das dauerhaft parallel zu betreiben; es ging nur darum, dass man deinen Post so hätte verstehen können, dass das gar nicht ginge, und das ist eben (afaik) nicht so...

Ansonsten ist es ein großer Unterschied, ob man ein Device pollen muß, oder ob es pusht. Wenn möglich, würde ich immer eine push-Technologie vorziehen und von so einem Device auch erwarten, dass es nur dann Daten pusht, _wenn es Sinn macht_ (da sind die Shelly-firmwares m.E. verbesserungswürdig...). Beim Pollen kommt tendenziell immer "alles" und man muß auf der FHEM-Seite nachbearbeiten, was man eigentlich an relevanten Infos daraus ziehen will.
MQTT ist auch generell als Protokoll "einfacher" gestrickt und erlaubt bestimmte features, die man sonst eben anderweitig realisieren muß (angefangen bei LWT).

Aber jeder wie er mag . Ich mag z.B. keine WLAN-Geräte für Hausautomatisierungsaufgaben einsetzen, deswegen vertiefe ich das mit Shelly1pm auch nicht weiter und dulde den nur, bis ich was passendes als Ersatz gefunden habe... Und die Gas- und Wasser-Sensoren würde ich auch nie mit WLAN betreiben wollen, aber auch da gilt: jeder wie er mag...

[MarkoP]

Speziell beim Gas-Sensor ist mir bisher noch keine Alternative über den Weg gelaufen.
Für die anderen Sensoren könnte man auf andere Systeme ausweichen, das stimmt.

Grundsätzlich will ich auch nicht zu viele WLan-Geräte einbinden, aber ich muss einige Steckdosen schaltbar machen bzw. Leistungsüberwachungen realisieren. Da habe ich bisher nichts kompakteres als die Shelly's gefunden, sowohl Größentechnisch als auch Preistechnisch. Und mal ehrlich, selbst den Shelly2.5 bekommt man eigentlich nur hinter eine Steckdose montiert wenn man den Boden aus der UP-Dose herausschneidet und nach hinten leicht erweitert.

Aber auf jeden fall danke für die ausführlichen Erklärungen. Werde mich noch mal mit MQTT auseinander setzen.

[Beta-User]

Gas kann ich nicht sagen, vermute, dass sich da was mit ZigBee (Xiaomi?) oder ZWave finden ließe (tendenziell aber teurer).

Die Fibaro-ZWave-UP-Aktoren haben fast dieselben Abmessungen wie die Shelly, (sind aber viel teurer,) einen ähnlich kompakten Steckdoseneinsatz mit Leistungsmessung gibt es von innr (ZigBee) - ich habe den "alten" (SP120), der war erschwinglich (wie viel Strom die jeweils "abkönnen", sollte man aber gesondert prüfen!).

[MarkoP]

Ich bin noch nicht dazu gekommen mich weitergehend mit MQTT auseinander zu setzen.

Deshalb kurz drei Fragen:

Welche Unterschiede gibt es zwischen MQTT und MQTT2?
Was macht bezüglich der Shelly-Aktoren mehr Sinn?
Gibt es Spezielles worauf ich achten muss?

Schaue mal das ich mich heute Abend mal einlese.