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.

[Guybrush]

Ich weiß jetzt leider nicht genau, wie die Discovery Topics bei denen ausschaut. Poste die doch mal. Grundlegend ist es aber eigentlich üblich, dass diese in den discovery Topics passend abgebildet sind, so dass es mit dem nächsten Update wohl schon gehen dürfte.

[the ratman]

mal die readings, reichen die? ansonsten musst mir genau sagen, was du wie willst.
so schauen 1 sensor und 2 4fach taster aus:

Code Auswählen Erweitern

setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:42 params_bthomedevice_200_last_updated_ts 1789175732
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:42 params_bthomedevice_200_packet_id 73
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:42 params_bthomedevice_200_rssi -50
setstate shellyplugsg3_d0cf13d85610 2026-09-12 08:19:51 params_bthomedevice_201_battery 99
setstate shellyplugsg3_d0cf13d85610 2026-09-12 11:05:17 params_bthomedevice_201_last_updated_ts 1789203916
setstate shellyplugsg3_d0cf13d85610 2026-09-12 11:05:17 params_bthomedevice_201_packet_id 71
setstate shellyplugsg3_d0cf13d85610 2026-09-12 11:05:17 params_bthomedevice_201_rssi -69
setstate shellyplugsg3_d0cf13d85610 2026-09-11 23:40:42 params_bthomedevice_202_last_updated_ts 1789162833
setstate shellyplugsg3_d0cf13d85610 2026-09-11 23:40:42 params_bthomedevice_202_packet_id 136
setstate shellyplugsg3_d0cf13d85610 2026-09-11 23:40:42 params_bthomedevice_202_rssi -54
setstate shellyplugsg3_d0cf13d85610 2026-09-12 08:19:51 params_bthomesensor_201_last_updated_ts 1789193989
setstate shellyplugsg3_d0cf13d85610 2026-09-12 08:19:51 params_bthomesensor_201_value 99
setstate shellyplugsg3_d0cf13d85610 2026-09-12 11:05:17 params_bthomesensor_202_last_updated_ts 1789203917
setstate shellyplugsg3_d0cf13d85610 2026-09-12 11:05:17 params_bthomesensor_202_value 61
setstate shellyplugsg3_d0cf13d85610 2026-09-12 11:04:17 params_bthomesensor_203_last_updated_ts 1789203856
setstate shellyplugsg3_d0cf13d85610 2026-09-12 11:04:17 params_bthomesensor_203_value 18.3
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_channel -1
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_component bthomedevice:200
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_event single_push
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_id 200
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_idx 2
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_sensors_1_1_id 200
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_sensors_1_1_last_updated_ts 1789175732
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_sensors_1_1_value 100
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_ts 1789175732.46das davon

Code Auswählen Erweitern

setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_event single_push
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_id 200
setstate shellyplugsg3_d0cf13d85610 2026-09-12 03:15:33 params_events_1_idx 2sind die angabe, die mir zeigen welcher taster, welche druckart und welcher der 4 tasten ausgelöst wurde.
das

Code Auswählen Erweitern

setstate shellyplugsg3_d0cf13d85610 2026-09-12 11:05:17 params_bthomesensor_202_value 61
setstate shellyplugsg3_d0cf13d85610 2026-09-12 11:04:17 params_bthomesensor_203_value 18.3ist der sensor mit temp und luftfeuchte.

sprich: ich habe für jeden sensorwert ein eigenes 20x. die 4 tasten eines tasters sind aber immer das selbe 20x mit weiteren werten, welcher tastendruck es ist.
das ist, gelinde gesagt jetzt schon verwirrend für mich - zumindest nicht gerade intuitiv. wenn ich mir vorstelle, dass da wer 10 blu devices drauf hat ... viel spaß.

[Guybrush]

die readings bringen mir nicht viel. ich brauche die discovery message, weil ich nur die verarbeite und anhand derer ich die readings überhaupt erst erstelle

[the ratman]

deine bitte bringt mir nicht viel, weil ich nicht weiß, wie ich sie erfüllen kann

[Beta-User]

deine bitte bringt mir nicht viel, weil ich nicht weiß, wie ich sie erfüllen kann

War hier schon Thema: "Show MQTT traffic" am IO, per Kommandozeile mit mosquitto_sub. Oder ein Tool wie MQTT Explorer verwenden. Oder den Weg wählen, der im bereits genannten Wiki-Artikel genannt ist: In der readingList auch den discovery-Topic aufnehmen und die Payload im "Klartext" als Reading schreiben lassen (also nicht per json2nameValue() entpacken).

readings bzw die mqtt topics wären dann aber zum teil doppelt

"Mein" Vorschlag (auf martinp876 Konzept basierend) wäre für "reine" Discovery-Devices: Es wird GANZ auf das Anlegen von readingList verzichtet, das Dispatchen des MQTT-Traffices übernimmt für diese Instanzen von MQTT2_DEVICE AUSSCHLIESSLICH dein Modul. Die "Blaupause" für diese Art der Auswertung des eingehenden Traffics wäre MQTT_GENERIC_BRIDGE, das verteilt übrigens auch "seine" Attribute an die damit verwalteten Devices (und deren Änderung via notifyFn()), so dass die von matinp876 angedachten weiteren Infos ohne weiteres in einem passenden Attribut unterzubringen wären (ggf. mit mapping-Angaben ala jsonMap etc., parseParams() ist unser Freund).

Martin hat schon recht: Das heutige Konzept ist nicht nur eher unübersichtlich, sondern v.a. ineffizient, v.a was die Auswertung der Topics für vielkanalige Devices angeht, und (vermutlich) auch was die Kompilierung zur Laufzeit bei "sonstigen" Auswertungs-Perl-Routinen angeht. Ich habe daher auch insbesondere für das zigbee2mqtt-Zeug zwischenzeitlich auch teilweise eigenen Code (myUtils) gebastelt, der eingehende Messages in FHEM-konforme Syntax überführt. Das als Standard-Code vorzuhalten, wäre imo die nach heutigen Gesichtspunkten sinnvolle Vorgehensweise.

ch persönlich finde es zwar besser, wenn dies alles in einem device gebündelt ist

Ich war zu Beginn meiner MQTT-Zeit auch Anhänger der "unified"-Devices (attrTemplate-Sprech). Zwischenzeitlich sehe ich das anders, nachdem Rudi mich ein paar Mal dazu "geschüttelt" hat:
- SetExtensions brauchen "on"/"off" (state) setter, damit timer-Aktonen gestartet werden können
- Sprachsteuerung wird sehr viel schwieriger, wenn man "drumrum" was basteln muss
- Entsprechendes gilt für die Web-Darstellung mit fhemAPP etc.. Man braucht für jede Kleinigkeit ein mapping, was zwar per copy/paste einigermaßen einfach geht, aber letztlich unnötiger Aufwand ist, wenn man gleich auf der Eingangsseite eine/die "Normalisierung" vornimmt.
- Mir geht es mit FHEM um Automatisierung. Hardware zu tauschen ist sehr viel aufwändiger, wenn man einen Aktor aus der CUL_HM-Welt ersetzt durch ein mehrkanaliges (z.B.) zigbee2mqtt-Gadget, das nicht on/off kann. Entsprechendes gilt für andere "Wechsel", angefangen damit, dass jemand möglicherweise dieses "rpc-Gedönses" überdrüssig ist und Tasmota auf den ESP flasht => komplett andere Topics etc...

Klar kann man dann den Shelly-Modul-Weg gehen, und den Anwender auf readingsProxy verweisen. Das bedeutet aber auch, dass man Events braucht, um die Kette anzuschubsen, was eventuell gar nicht immer so gewünscht ist (für on/off eher kein Thema). Ich empfinde das jedenfalls als "workaround", weil wir eigentlich wissen, wie es ginge mit "ein Device je Kanal".

Gerne können wir dazu auch mal direkt sprechen, das alles nachvollziehbar aufzuschreiben ist ziemlich schwierig, v.a., weil ich keine Ahnung habe, wie tief du in den internen FHEM-Funktionen drin bis.