shelly duo bulb gen3 über mqtt schalten

[Beta-User]

wie meinst du das denn mit mehreren channels? MQTT2_DISCOVERY legt bereits alle an, die ein device hat.

Das mit "channels" ist ein "Sprech", der an Martins Konzept aus https://forum.fhem.de/index.php?topic=145198.0 übernommen ist (bzw. wie ich es interpretiere).

Ein Beispiel - man nehme einen Tasmota-ESP32 und klemme ein 8er Relays-Board daran. Ergibt zunächst einmal (ohne Attribute in FHEM) "POWER1" bis "POWER8" als Readings in einem MQTT2_DEVICE. Dann konfiguriert man die ersten beiden Relays als "cover".

Nach FHEM übersetzt sollte das dann 7 Instanzen von MQTT2_DEVICE (aka channels) ergeben:
- 1 "cover" (on/off in "state", dazu "pct" von 0-100 für den Stand des Behangs, dazu die Status-Readings für den ESP an sich (online, heap, ...). Das versteht dann "pct"-Anweisungen ebenso wie "set <coverdevice> on" und "off" für ""öffnen" und "schließen" (bzw. umgekehrt für die User, die das an die Konvention im ROLLO-Modul anpassen wollen)
- 6 normale "Relay"-Devices, die je im "state"-Reading "on" und "off" (und die Zwischenzustände "set_on" etc.) kennen und über "set <relaydevicex> on" etc. schaltbar sind.

Die semantische Umsetzung findet also direkt so statt, dass in FHEM bereits "gängige" Benennungskonventionen eingehalten sind.

Für Martins 2-Relay Shelly (mit rpc) wären das shellyPlus_2pm_split (2 channel-Devices in FHEM) und shellyPlus_2pm_roller_invert_0 (für die als "cover" konfigurierte firmware), das dann nur 1 Device für 2 relays ergibt.

Hoffe, diese Beispiele sind verständlich?

[Guybrush]

also du meinst eine art Splitmode, bei dem dann - wenn gesetzt - alle set optionen auf einzelne MQTT2_DEVICES aufgeteilt würden, so dass jedes device nur ein setbefehl aber trotzdem alle readings (außer die bzgl der anderen setter) dann hat? sowas dürfte machbar sein. man müsste nur mal schauen, ob das auch mit allen möglichen discoverymessages funktioniert. die namensgebung ist ja nicht verbindlich. so kann power_0 z.b. relais 0 schalten und switch_0 dann den status anzeigen. das ist zwar im Regelfall gleich benannt, aber das müsste man dabei bedenken.

Meintest du das?

[Beta-User]

Wenn man von "alle Readings" absieht.

Konvention ist: der 1. Kanal bekommt "alles", außer dem, was in den anderen Channel-Devices ist, und jeder andere Channel bekommt nur das, was für ihn relevant ist.
In meinem Beispiel gibt es für die 6 relay-Devices dann nur state (mit on/off).

[Guybrush]

das bekommt man so hin. readings bzw die mqtt topics wären dann aber zum teil doppelt, damit jedes device die notwendigen readings bekommt. was man nicht automatisch hinbekommt ist z.b. eine Trennung dass die ersten 2 Kanäle in eins sollen und die anderen 4 in ein anderes. Es gibt zwar Entitäten, die man nutzen kann, aber auch die sind nicht unbedingt verlässlich, dass man es in fhem devices dann sicher auftrennen kann. Ich persönlich finde es zwar besser, wenn dies alles in einem device gebündelt ist, aber wenn das jemand so haben will, könnte man das entweder über ein Attribut beim anlegen steuerbar machen oder ein splitDevice Befehl fürs händische splitten nach dem Anlegen integrieren.

[the ratman]

was vielleicht (oder auch nicht *g*) hier rein passen würde ... meine geliebten blu devices. wenn man da brauchbare readings hinbekommen würde wäre das genial.

ohne templates schaut das derzeit ja schön verwirrend aus:

1) jeder blu sensor (z.b. auch batterie) hat nur eine fortlaufende nummer. wenn man da die im webinterface vom shelly vergeben namen abfragen könnte ... ein träumchen. dann könnte man auch wieder die einzelnen batteriestände automatisiert einem gerät zuordnen. 200, 201, 202, ... ist ja nicht gerade aussagekräftig

2) habe ich z.b. mehrere 4-fach blu taster, dann werden alle tasten aller taster in ein und denselben readings abgebildet. also z.b. welche art tastendruck, welche nummer des geräts, usw. die batteriestände werden als "sensor" aber weiterhin in eigenen durchnummerierten readings geführt.
wenn das irgendwie brauchbar zusammengefasst wäre in einzelne taster mit druck und batterie, egal obs ein eigenes device wird, oder brauchbar benannt, wäre das echt genial.