shelly duo bulb gen3 über mqtt schalten

Begonnen von the ratman, 04 September 2026, 16:51:43

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Guybrush am 11 September 2026, 19:51:26wie 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?
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

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).
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors