hiho,
ich bräuchte mal wieder hilfe. es geht um eine shelly duo pulg der 3. generation, eingebunden per mqtt.
mqtt ansich funktioniert wie immer problemlos - was nicht funktioniert, bin ich *g*
was muss ich den bei dieser birne im mqtt-client in redingslist/setlist/userreadings eintragen, um sie schalten und dimmen zu können?
vielen dank im voraus für hilfe!
das passende topic & payload :P
alternativ kannst du ja mal MQTT2_DISCOVERY ausprobieren. das sollte dir das alles automatisch einrichten...
"das passende topic & payload"
da ich keine ahnung hab, ein kleines listing ...
define shelly_duo_bulb_wz MQTT2_DEVICE shelly_blug_duo_wz
attr shelly_duo_bulb_wz group licht
attr shelly_duo_bulb_wz readingList shelly_blug_duo_wz:shellyduobulbg3-9070694a9e14/events/rpc:.* { json2nameValue($EVENT) }\
shelly_blug_duo_wz:shellyduobulbg3-9070694a9e14/online:.* online
attr shelly_duo_bulb_wz room shelly
# CFGFN
# CID shelly_blug_duo_wz
# DEF shelly_blug_duo_wz
# FUUID 6a9ad6b1-f33f-7571-7208-f02479ff8f51872a
# IODev ratBroker
# LASTInputDev ratBroker
# MSGCNT 79
# NAME shelly_duo_bulb_wz
# NR 192
# STATE off
# TYPE MQTT2_DEVICE
# eventCount 97
# ratBroker_CONN ratBroker_xxx_51700
# ratBroker_MSGCNT 79
# ratBroker_TIME 2026-09-04 17:16:43
# READINGS:
# 2026-09-04 16:33:21 IODev ratBroker
# 2026-09-04 17:15:07 dst shellyduobulbg3-9070694a9e14/events
# 2026-09-04 17:15:07 method NotifyStatus
# 2026-09-04 17:16:43 online false
# 2026-09-04 17:14:53 params_ble_addr xxx,p
# 2026-09-04 17:14:53 params_ble_flags_1 scanning
# 2026-09-04 17:14:53 params_bthome_discovery_duration 30
# 2026-09-04 17:14:53 params_bthome_discovery_started_at 1788531201
# 2026-09-04 17:15:00 params_cct_0_aenergy_by_minute_1 12.419
# 2026-09-04 17:15:00 params_cct_0_aenergy_by_minute_2 0.000
# 2026-09-04 17:15:00 params_cct_0_aenergy_by_minute_3 0.000
# 2026-09-04 17:15:00 params_cct_0_aenergy_minute_ts 1788534900
# 2026-09-04 17:15:00 params_cct_0_aenergy_total 0.012
# 2026-09-04 17:15:07 params_cct_0_apower 0.0
# 2026-09-04 17:15:07 params_cct_0_brightness 50
# 2026-09-04 17:15:07 params_cct_0_ct 4600
# 2026-09-04 17:14:53 params_cct_0_id 0
# 2026-09-04 17:15:07 params_cct_0_output false
# 2026-09-04 17:15:07 params_cct_0_source WS_in
# 2026-09-04 17:14:53 params_cloud_connected false
# 2026-09-04 16:56:22 params_events_1_cfg_rev 22
# 2026-09-04 16:56:22 params_events_1_component cloud
# 2026-09-04 16:56:22 params_events_1_event config_changed
# 2026-09-04 16:56:22 params_events_1_restart_required false
# 2026-09-04 16:56:22 params_events_1_ts 1788533782.05
# 2026-09-04 17:14:53 params_mqtt_connected true
# 2026-09-04 17:15:03 params_sys_available_updates_beta_version 2.0.1-beta1
# 2026-09-04 17:14:53 params_sys_bthc_rev 5
# 2026-09-04 17:14:53 params_sys_btrelay_rev 0
# 2026-09-04 17:14:53 params_sys_cfg_rev 23
# 2026-09-04 17:14:53 params_sys_fs_free 581632
# 2026-09-04 17:14:53 params_sys_fs_size 1048576
# 2026-09-04 17:14:53 params_sys_kvs_rev 0
# 2026-09-04 17:14:53 params_sys_last_sync_ts 1788534893
# 2026-09-04 17:14:53 params_sys_mac xxx
# 2026-09-04 17:14:53 params_sys_ram_free 133860
# 2026-09-04 17:14:53 params_sys_ram_min_free 124036
# 2026-09-04 17:14:53 params_sys_ram_size 278808
# 2026-09-04 17:14:53 params_sys_reset_reason 1
# 2026-09-04 17:14:53 params_sys_restart_required false
# 2026-09-04 17:14:53 params_sys_schedule_rev 0
# 2026-09-04 17:14:53 params_sys_time 17:14
# 2026-09-04 17:14:53 params_sys_unixtime 1788534893
# 2026-09-04 17:14:53 params_sys_uptime 4
# 2026-09-04 17:14:53 params_sys_utc_offset 7200
# 2026-09-04 17:14:53 params_sys_webhook_rev 0
# 2026-09-04 17:15:07 params_ts 1788534907.74
# 2026-09-04 17:14:53 params_wifi_bssid cc:ce:1e:b1:dc:09
# 2026-09-04 17:14:53 params_wifi_channel 1
# 2026-09-04 17:14:53 params_wifi_rssi -54
# 2026-09-04 17:14:53 params_wifi_ssid xxx
# 2026-09-04 17:14:53 params_wifi_sta_ip xxx
# 2026-09-04 17:14:53 params_wifi_status got ip
# 2026-09-04 17:14:53 params_ws_connected false
# 2026-09-04 17:15:07 src shellyduobulbg3-9070694a9e14
# 2026-09-04 17:00:37 state off
#
setstate shelly_duo_bulb_wz off
setstate shelly_duo_bulb_wz 2026-09-04 16:33:21 IODev ratBroker
setstate shelly_duo_bulb_wz 2026-09-04 17:15:07 dst shellyduobulbg3-9070694a9e14/events
setstate shelly_duo_bulb_wz 2026-09-04 17:15:07 method NotifyStatus
setstate shelly_duo_bulb_wz 2026-09-04 17:16:43 online false
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_ble_addr xxx,p
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_ble_flags_1 scanning
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_bthome_discovery_duration 30
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_bthome_discovery_started_at 1788531201
setstate shelly_duo_bulb_wz 2026-09-04 17:15:00 params_cct_0_aenergy_by_minute_1 12.419
setstate shelly_duo_bulb_wz 2026-09-04 17:15:00 params_cct_0_aenergy_by_minute_2 0.000
setstate shelly_duo_bulb_wz 2026-09-04 17:15:00 params_cct_0_aenergy_by_minute_3 0.000
setstate shelly_duo_bulb_wz 2026-09-04 17:15:00 params_cct_0_aenergy_minute_ts 1788534900
setstate shelly_duo_bulb_wz 2026-09-04 17:15:00 params_cct_0_aenergy_total 0.012
setstate shelly_duo_bulb_wz 2026-09-04 17:15:07 params_cct_0_apower 0.0
setstate shelly_duo_bulb_wz 2026-09-04 17:15:07 params_cct_0_brightness 50
setstate shelly_duo_bulb_wz 2026-09-04 17:15:07 params_cct_0_ct 4600
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_cct_0_id 0
setstate shelly_duo_bulb_wz 2026-09-04 17:15:07 params_cct_0_output false
setstate shelly_duo_bulb_wz 2026-09-04 17:15:07 params_cct_0_source WS_in
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_cloud_connected false
setstate shelly_duo_bulb_wz 2026-09-04 16:56:22 params_events_1_cfg_rev 22
setstate shelly_duo_bulb_wz 2026-09-04 16:56:22 params_events_1_component cloud
setstate shelly_duo_bulb_wz 2026-09-04 16:56:22 params_events_1_event config_changed
setstate shelly_duo_bulb_wz 2026-09-04 16:56:22 params_events_1_restart_required false
setstate shelly_duo_bulb_wz 2026-09-04 16:56:22 params_events_1_ts 1788533782.05
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_mqtt_connected true
setstate shelly_duo_bulb_wz 2026-09-04 17:15:03 params_sys_available_updates_beta_version 2.0.1-beta1
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_bthc_rev 5
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_btrelay_rev 0
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_cfg_rev 23
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_fs_free 581632
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_fs_size 1048576
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_kvs_rev 0
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_last_sync_ts 1788534893
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_mac 9070694A9E14
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_ram_free 133860
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_ram_min_free 124036
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_ram_size 278808
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_reset_reason 1
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_restart_required false
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_schedule_rev 0
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_time 17:14
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_unixtime 1788534893
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_uptime 4
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_utc_offset 7200
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_sys_webhook_rev 0
setstate shelly_duo_bulb_wz 2026-09-04 17:15:07 params_ts 1788534907.74
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_wifi_bssid xxx
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_wifi_channel 1
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_wifi_rssi -54
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_wifi_ssid xxx
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_wifi_sta_ip xxx
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_wifi_status got ip
setstate shelly_duo_bulb_wz 2026-09-04 17:14:53 params_ws_connected false
setstate shelly_duo_bulb_wz 2026-09-04 17:15:07 src shellyduobulbg3-9070694a9e14
setstate shelly_duo_bulb_wz 2026-09-04 17:00:37 state off
rest muß ich mal schauen, bin grad unterwegs.
btw - bei obigen daten war die birne nicht am strom. nur, dass da keine verwirrung aufkommt *g*.
nachtrag:
wenn ich dieses discovery finde, haut mir das was bei vorhandenen clients durcheinander?
hab da ein paar steckdosen, an denen hängen tonnen bt sensoren und taster. da würd' ich das we durch weinen, wenn da was durcheinander kommt ... *g*
das listing bringt wenig. du musst die topics kennen. die stehen in den discovery messages zb
MQTT2_DISCOVERY lässt bereits angelegte MQTT2_DEVICES in ruhe, solang du das Attribut existingDevice nicht auf replace setzt. du kannst dann gezielt dieses device mit set rebuildDevice von Discovery übernehmen lassen. Händische Einträge bleiben aber danach auch bestehen. Trotzdem vorher die fhem.cfg sichern 8)
bei dir sollte das gehen:
update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
update
define mqtt2Discovery MQTT2_DISCOVERY ratBroker
ist aber auf https://github.com/next81/fhem.MQTT2_Discovery auch sehr umfassend dokumentiert
ach, kannt ich gar ned ... thx für die infos!
hab mal installiert, und versuch jetzt mal zu kapieren, was ich wie tun soll.
ist das discovery quasi soetwas wie der "mqtt explorer"? (nur, damit ich mal ein paar gehirnzellen in die richtige richtung drehen kann)
derweil krieg ich gleich mal einen schönen logeintrag:
2026.09.05 09:47:16 1: PERL WARNING: Prototype mismatch: sub main::decode_json ($) vs none at /usr/lib/x86_64-linux-gnu/perl-base/Exporter.pm line 63.(ich fahre fhem in einem aktuellen debian über eine wsl2 in win11pro, nur, falls dies wichtig sein sollte)
derzeit ist das discovery auf inaktiv.
seh ich das richtig, das ich meine bulb mal löschen müsste, und warten, was der discovery dann so zu sagen hat?
aja, noch ne frage:
in meinem mqtt_server, so nehme ich an, sollte ich dann das autocreate ausschalten? derzeit ist das auf "simple"
discovery ist quasi ein Adapter um aus den Discovery Messages passende reading/setList Einträge zu bauen, damit das ohne händische Zuarbeit wie bei HA funktioniert. Schau dir am besten die Readme auf Github an. Da hab ich wirklich viel Zeit investiert um das für jedermann verständlich zu machen. Einmal eingerichtet musst du nie wieder irgendwas bei MQTT Devices einrichten. Das macht dann MQTT2_DISCOVERY für dich automatisch
glaubs dir. is sicher a super idee. und ich werds schon hinbekommen irgendwie.
für mich würds halt a simple bedienugsanleitung tun.
du redest hier mit an fortgeschrittenen dau. im gegensatz zum normalen dau weiß ich, dass ich nix weiß und das sicher auch so bleibt. *g*
auf github für mich also viel zu viel info, mit lauter schönen worten, die ich ned verstehe.
ich nehme mit:
automatik beim server aus, bei deinem modul an.
schauen, was passiert ...
ich steh an ...
1) einen mqtt client aus fhem gelöscht, bulb vom strom genommen, autocreate im mqtt2server aus, fhem restartet.
2) mqtt2discovery active, autocreate 1, createreadings 1.
3) bulb unter strom gsetzt, ein/aus geschaltet. kein neues device.
4) nochmal mit get devices probiert. auch keine neues device.
5) mqtt2server autocreate wieder ein.
6) bulb wird sofort gefunden. leider natürlich ohne den erhofften schaltmöglichkeiten.
dann nochmal rebuild device probiert.
"shelly_blug_duo_wz wird von mqtt2Discovery nicht verwaltet"
was mach ich falsch?
autocreate sollte beim mqtt2_server aus bleiben, sonst kollidiert das mit Discovery. Dein Shelly muss HomeAssistant Discovery messages schreiben. ein list von den 3 devices würde helfen..
Moin Ratman,
bei mir steht im setlist:
off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":false}}
on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":true}}
toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Toggle","params":{"id":0}}
pct:colorpicker,BRI,0,1,100 $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"brightness":$EVTPART1}}
ct:colorpicker,CT,2700,100,6500 $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"ct":$EVTPART1}}
Habe ich auch irgendwo im WWW "geklaut"..
Gruss
Enno
autocreate - habs mal mit, mal ohne probiert beim server. man weiß es ja nie *g*
"Dein Shelly muss HomeAssistant Discovery messages schreibe" somit ist mal klar, warums nicht geht *g*
weil: im webinterface vom shelly find ich auch nix zu homeassistant.
@enno ...
haste gut geklaut, vielen dank!
on/off geht schon mal
kannst du mir eventuell noch deine readinglist zu zeigen, weil der rest fehlt noch.
Hast du doch oben selbst gepostet. Meins sieht fast genauso aus:
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT) }
$DEVICETOPIC/online:.* online
$DEVICETOPIC/rpc:.* {}
Gruss
Enno
man weiß es doch nie ... und wenns um fhem und mich geht, prüf ich lieber 2 mal - und das liegt nicht an fhem *bg*
so, jetzt mal wieder schnell heim kommen, dann kann ichs auch probieren.
dank dir nochmal!
nachtrag:
wird immer besser ... ct geht auch schon mal
pct zwar ned als schieberegler, aber als wert ... also was solls *g*
Der slider erwartet den richtigen Wert in pct, bei Dir steht er aber in params_cct_0_brightness, darum springt er auf 0.
attr shelly_duo_bulb_wz jsonMap params_cct_0_brightness:pctmappt das Reading zu pct. params_cct_0_brightness kannst dann mit deletereading löschen.
Damit das Attribut jsonMap greift muss in dem ReadingListeintrag über den der Wert kommt in der Funktion json2nameValue im dritten (https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt#json2nameValue()) Parameter $JSONMAP angegeben werden:
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }
hehe, jetzt wird das langsam was ... auch dir vielen dank.
muss ich nur noch meine hue lightstripes mit shelly ersetzen (wenn mir conrad den einen zum testen mal zusenden mag), dann ist philips aus dem spiel bei mir.
btw ... falls es bei den "shelly plus rgbw pm" irgendwelche stolpersteine beim einbinden gibt, und die jemand im betrieb hat, sag ich zu infos auch nicht nein *g*
habe ich hier zwei im Betrieb. Aber weil ich auch faul ;D bin, nutze ich das Shelly Modul und nicht MQTT. define Shelly_LED Shelly 192.168.178.150 Funktioniert tadellos.
Gruss
Enno
das wäre blöd für mich. was ich weiß, geht ja beim modul kein blu - oder hat sich da was die letzten wochen getan?
derweil hab ich nämlich viele sensoren an einer 4fachsteckdose (damals zum shelly kennenlernen besorgt). die würden danach schreien an die unterputzschalter zu dürfen.
fux, jetzt muss ich auch noch einstellungen per readingsgroup für pct und ct machen.
also wirds doch nicht die lösung direkt im gerät und der jasonmap...
vielleicht weiß ja auch da einer von euch gleich wieder eine lösung?
eigentlich hab' ich in der readingsgroup scheints ein ähnliches problem: ich kann per schieberegler werte ändern, die auch übernommen werden, aber merken tut sichs die anzeige in der rg nicht.
die def:
shelly_blug_duo_wz:<wohnzimmer<br>deckenfluter>,params_cct_0_output
shelly_blug_duo_wz:<helligkeit>,params_cct_0_brightness
shelly_blug_duo_wz:<wärme>,params_cct_0_ct
das müsste doch eigentlich per "command" gehen, oder?
{
'params_cct_0_output.false' => 'set %DEVICE on',
'params_cct_0_output.true' => 'set %DEVICE off',
'params_cct_0_brightness' => 'pct:colorpicker,BRI,0,1,100',
'params_cct_0_ct' => 'ct:colorpicker,CT,2700,100,6500',
}
das schaut dann derweil so aus:
'params_cct_0_brightness' => 'pct:colorpicker,BRI,0,1,100',
Du hast doch gar kein params_cct_0_brightness Reading mehr, das heisst doch jetzt pct?
Und nur Du kannst sagen ob das params_cct_0_ct Reading analog zum pct Reading umgestellt/gemappt hast.
@TomLee
nachdems ja scheints keine alternative gibt, hab' ichs mit jsonmap versucht.
und wie sollts bei mir anders sein - jetzt merkt er sich im regler die werte, aber stellt keine neuen ein. derzeit schaut das so aus:
in der jsonmap steht:
params_cct_0_brightness:pct params_cct_0_ct:ct
in der readinglist steht:
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT) }
$DEVICETOPIC/online:.* online
$DEVICETOPIC/rpc:.* {}
shelly_duo_bulb_wz:fhem/rpc:.* { json2nameValue($EVENT) }
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }die ersten 3 hab ich angelegt, das 4. kommt immer von selber und dann, wieder von mir angelegt, deines.
ich dachte dann, dass deine angaben "$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT) }" ersetzen sollen und hab's rausgenommen, was aber auch nix ändert.
in setlist steht:
off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":false}}
on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":true}}
toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Toggle","params":{"id":0}}
pct:colorpicker,BRI,0,1,100 $DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }
ct:colorpicker,CT,2700,100,6500 $DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }
ajo, nur der vollständgkeit halber - hab meine bulb nun auch so benannt ... interessant, was man für lustige namen vergibt, wenn ma ned aufpasst.
ab nun also: shelly_duo_bulb_wz
was mach ich den nun wieder falsch?
Warum wirst du hier so kreativ und nimmst nicht einfach den Vorschlag von Enno für die setList?!?
Die readingList ist auch nicht optimal...
kreativ?
ich mach doch nur, was man von mir will - oder: wie ich das gewollte verstehe.
erst das setlist von enno aus #11, und dann soll ich doch den dreh mit der jasonmap und den entsprechenden anpassungen von tomlee aus #13 machen. dachte, das passt so, tut es nicht und d'rum frag ich ja nochmal.
und über eine "saubere" readinglist würde ich mich freuen - weil, wie grade du von mir schon wissen solltest: ich tippe hier dumm-dämlich im blindflug alle eure infos ab, weil ich sowieso ned kapiere, was ich da mache ...
jsonMap ist nur für "den Rückweg" (=> readingList) relevant.
Also: setList von Enno übernehmen, und ggf webCmd anpassen, damit es in der Raumansicht funktionaler ist.
Dann erst schauen wir readingList noch mal an.
ich nehme also die setlist aus #9
off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":false}}
on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":true}}
toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Toggle","params":{"id":0}}
pct:colorpicker,BRI,0,1,100 $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"brightness":$EVTPART1}}
ct:colorpicker,CT,2700,100,6500 $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"ct":$EVTPART1}}
passe mein webcmd an (ja, schaut blöd aus, is nur zum testen):
ct 2700:ct 4300:ct 6500:on:pct 25:pct 50:pct 75:off:pct:ct und auch webcmdlabel (damit ich ned ganz den überblick verliere)
wärme : : : |
:hell: : : |
:pct
:ctsoweit, wie gehabt - pct und ct können auch per balken gesteuert werden, gehen aber immer wieder auf 0
der vollständigkeit halber:
jsonmap
params_cct_0_brightness:pct params_cct_0_ct:ctund
readinglist
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT) }
$DEVICETOPIC/online:.* online
$DEVICETOPIC/rpc:.* {}
shelly_blug_duo_wz:fhem/rpc:.* { json2nameValue($EVENT) }
Bitte schau mal ins Wiki - "Schritt für Schritt".
Da ist erklärt, wie die Dinge aufeinander aufbauen. setList passt also, jetzt geht es darum, die Rückmeldungen passend auszuwerten (bzw. Zu verwerfen !). Bitte dazu auch die vorhandenen attrTemplate zu den aktuellen Shelly ansehen, tippen am Handy macht einstweilen keine Freude....
schöner text - hat sich sciher wer bemüht - aber verstehen tu ichs trotzdem nicht.
und mit den templates bin ich sowieso auf kriegsfuß - ich kann ja nur lustig irgendeines nehmen. weil für meine dinger find ich da eher nix.
Ich würde ja vielleicht sogar versuchen, eines bereitzustellen, aber der Anfragende hat viele "Bringschulden" (=>erster Beitrag im Thread) nicht erfüllt, und ich hatte bisher keine Lust, alles selbst zusammen zu suchen...
dann wird der beantragende mal schauen, was so im beitrag #1 steht.
aus sicherer quelle weiß ich, das das aber a elendslange diskussion werden wird, weil der dann natürlich auch nix gegen weitere templates haben wird
erst also mal am nachmittag nach deinen wünschen schauen, und hier mal die bulb rein schreiben, obs dir so passt.
- vorrangig eine RAW-Definition von dem, was "autocreate" so liefert, damit man das in einem Testsystem zumindest mal einen Eindruck von dem Gerät bekommt.
define shelly_duo_bulb_wz MQTT2_DEVICE shelly_blug_duo_wz
attr shelly_duo_bulb_wz alias wz sofa ambient licht
attr shelly_duo_bulb_wz devStateIcon on:light_floor_lamp@green:off off:light_floor_lamp@gray:on .*:light_floor_lamp@darkgreen:off
attr shelly_duo_bulb_wz devicetopic shellyduobulbg3-9070694a9e14
attr shelly_duo_bulb_wz fp_fp_start 305,120,0,shelly_bulb_duo_wz
attr shelly_duo_bulb_wz group client
attr shelly_duo_bulb_wz jsonMap params_cct_0_brightness:pct params_cct_0_ct:ct
attr shelly_duo_bulb_wz readingList $DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/online:.* online\
$DEVICETOPIC/rpc:.* {}\
shelly_blug_duo_wz:fhem/rpc:.* { json2nameValue($EVENT) }
attr shelly_duo_bulb_wz room shelly
attr shelly_duo_bulb_wz setList off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":false}}\
on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":true}}\
toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Toggle","params":{"id":0}}\
pct:colorpicker,BRI,0,1,100 $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"brightness":$EVTPART1}}\
ct:colorpicker,CT,2700,100,6500 $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"ct":$EVTPART1}}
attr shelly_duo_bulb_wz webCmd ct 2700:ct 4300:ct 6500:on:pct 25:pct 50:pct 75:off:pct:ct
attr shelly_duo_bulb_wz webCmdLabel wärme ;: ;: ;: ;|\
:hell: ;: ;: ;|\
:pct\
:ct
# CID shelly_blug_duo_wz
# DEF shelly_blug_duo_wz
# FUUID 6a9d616e-f33f-7571-174c-00678c8fe8ff05d6
# IODev ratBroker
# LASTInputDev ratBroker
# MSGCNT 450
# NAME shelly_duo_bulb_wz
# NR 187
# STATE off
# TYPE MQTT2_DEVICE
# eventCount 497
# ratBroker_CONN ratBroker_192.168.178.15_55830
# ratBroker_MSGCNT 450
# ratBroker_TIME 2026-09-08 14:08:00
# JSONMAP:
# params_cct_0_brightness pct
# params_cct_0_ct ct
# OLDREADINGS:
# READINGS:
# 2026-09-08 08:35:46 IODev ratBroker
# 2026-09-08 14:08:00 dst shellyduobulbg3-9070694a9e14/events
# 2026-09-06 16:12:47 error_code -103
# 2026-09-06 16:12:47 error_message Invalid argument 'ct': should be >= 2700 and <= 6500!
# 2026-09-08 12:01:59 id 0
# 2026-09-08 14:08:00 method NotifyStatus
# 2026-09-08 08:35:49 online true
# 2026-09-06 17:07:45 params_ble_addr 90:70:69:4a:9e:16,p
# 2026-09-06 17:07:45 params_ble_flags_1 scanning
# 2026-09-06 17:07:45 params_bthome_discovery_duration 30
# 2026-09-06 17:07:45 params_bthome_discovery_started_at 1788697792
# 2026-09-06 17:08:12 params_bthomecontrol_200_learning_duration 0
# 2026-09-06 17:08:12 params_bthomecontrol_200_learning_err_code 8
# 2026-09-06 17:08:12 params_bthomecontrol_200_learning_err_msg No BLU devices found
# 2026-09-06 17:08:12 params_bthomecontrol_200_learning_stage error
# 2026-09-06 17:08:12 params_bthomecontrol_200_learning_ts 1788707291
# 2026-09-08 14:08:00 params_cct_0_aenergy_by_minute_1 0.000
# 2026-09-08 14:08:00 params_cct_0_aenergy_by_minute_2 0.000
# 2026-09-08 14:08:00 params_cct_0_aenergy_by_minute_3 0.000
# 2026-09-08 14:08:00 params_cct_0_aenergy_minute_ts 1788869280
# 2026-09-08 14:08:00 params_cct_0_aenergy_total 30.150
# 2026-09-08 12:01:59 params_cct_0_apower 0.0
# 2026-09-08 12:01:59 params_cct_0_brightness 38
# 2026-09-08 12:01:59 params_cct_0_ct 6500
# 2026-09-08 08:35:49 params_cct_0_id 0
# 2026-09-08 12:01:59 params_cct_0_output false
# 2026-09-08 12:01:59 params_cct_0_source MQTT
# 2026-09-08 08:35:49 params_cloud_connected false
# 2026-09-06 17:08:12 params_events_1_cfg_rev 39
# 2026-09-06 17:08:12 params_events_1_component sys
# 2026-09-06 15:57:20 params_events_1_device_addr 7c:c6:b6:75:1c:73
# 2026-09-06 17:08:12 params_events_1_device_count 0
# 2026-09-06 15:57:20 params_events_1_device_encrypted false
# 2026-09-06 15:57:20 params_events_1_device_local_name SBHT-003C
# 2026-09-06 15:57:20 params_events_1_device_rssi -93
# 2026-09-06 15:57:20 params_events_1_device_shelly_mfdata_flags 17
# 2026-09-06 15:57:20 params_events_1_device_shelly_mfdata_mac 7c:c6:b6:75:1c:73
# 2026-09-06 15:57:20 params_events_1_device_shelly_mfdata_model_id 3
# 2026-09-06 17:08:12 params_events_1_event component_removed
# 2026-09-06 17:08:12 params_events_1_restart_required false
# 2026-09-06 17:08:12 params_events_1_target bthomecontrol:200
# 2026-09-06 17:08:12 params_events_1_ts 1788707291.94
# 2026-09-08 08:35:49 params_mqtt_connected true
# 2026-09-08 08:35:49 params_sys_available_updates_beta_version 2.0.1-beta1
# 2026-09-08 08:35:49 params_sys_bthc_rev 20
# 2026-09-08 08:35:49 params_sys_btrelay_rev 0
# 2026-09-08 08:35:49 params_sys_cfg_rev 39
# 2026-09-08 08:35:49 params_sys_fs_free 581632
# 2026-09-08 08:35:49 params_sys_fs_size 1048576
# 2026-09-08 08:35:49 params_sys_kvs_rev 0
# 2026-09-08 14:05:40 params_sys_last_sync_ts 1788869139
# 2026-09-08 08:35:49 params_sys_mac 90706xxyyzzxx
# 2026-09-08 08:35:49 params_sys_ram_free 162292
# 2026-09-08 08:35:49 params_sys_ram_min_free 120848
# 2026-09-08 08:35:49 params_sys_ram_size 279072
# 2026-09-08 08:35:49 params_sys_reset_reason 1
# 2026-09-08 08:35:49 params_sys_restart_required false
# 2026-09-08 08:35:49 params_sys_schedule_rev 0
# 2026-09-08 14:05:40 params_sys_time 14:05
# 2026-09-08 14:05:40 params_sys_unixtime 1788869139
# 2026-09-08 08:35:49 params_sys_uptime 142086
# 2026-09-08 08:35:49 params_sys_utc_offset 7200
# 2026-09-08 08:35:49 params_sys_webhook_rev 0
# 2026-09-08 14:08:00 params_ts 1788869280.00
# 2026-09-08 08:35:49 params_wifi_bssid xx:xx:xx:xx:xx:xx
# 2026-09-08 08:35:49 params_wifi_channel 1
# 2026-09-08 08:35:49 params_wifi_rssi -54
# 2026-09-08 08:35:49 params_wifi_ssid xyz
# 2026-09-08 08:35:49 params_wifi_sta_ip 192.168.178.15
# 2026-09-08 08:35:49 params_wifi_sta_ip6_1 fe80::9270:69ff:fe4a:9e14
# 2026-09-08 08:35:49 params_wifi_sta_ip6_2 2001:16b8:a287:4f00:9270:69ff:fe4a:9e14
# 2026-09-08 08:35:49 params_wifi_sta_ip6_3 fddf:3375:e7db:0:9270:69ff:fe4a:9e14
# 2026-09-08 08:35:49 params_wifi_status got ip
# 2026-09-08 08:35:49 params_ws_connected false
# 2026-09-08 14:08:00 src shellyduobulbg3-9070694a9e14
# 2026-09-08 12:01:59 state off
#
setstate shelly_duo_bulb_wz off
setstate shelly_duo_bulb_wz 2026-09-08 08:35:46 IODev ratBroker
setstate shelly_duo_bulb_wz 2026-09-08 14:08:00 dst shellyduobulbg3-9070694a9e14/events
setstate shelly_duo_bulb_wz 2026-09-06 16:12:47 error_code -103
setstate shelly_duo_bulb_wz 2026-09-06 16:12:47 error_message Invalid argument 'ct': should be >= 2700 and <= 6500!
setstate shelly_duo_bulb_wz 2026-09-08 12:01:59 id 0
setstate shelly_duo_bulb_wz 2026-09-08 14:08:00 method NotifyStatus
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 online true
setstate shelly_duo_bulb_wz 2026-09-06 17:07:45 params_ble_addr 90:70:xx:yy:zz:xx,p
setstate shelly_duo_bulb_wz 2026-09-06 17:07:45 params_ble_flags_1 scanning
setstate shelly_duo_bulb_wz 2026-09-06 17:07:45 params_bthome_discovery_duration 30
setstate shelly_duo_bulb_wz 2026-09-06 17:07:45 params_bthome_discovery_started_at 1788697792
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_bthomecontrol_200_learning_duration 0
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_bthomecontrol_200_learning_err_code 8
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_bthomecontrol_200_learning_err_msg No BLU devices found
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_bthomecontrol_200_learning_stage error
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_bthomecontrol_200_learning_ts 1788707291
setstate shelly_duo_bulb_wz 2026-09-08 14:08:00 params_cct_0_aenergy_by_minute_1 0.000
setstate shelly_duo_bulb_wz 2026-09-08 14:08:00 params_cct_0_aenergy_by_minute_2 0.000
setstate shelly_duo_bulb_wz 2026-09-08 14:08:00 params_cct_0_aenergy_by_minute_3 0.000
setstate shelly_duo_bulb_wz 2026-09-08 14:08:00 params_cct_0_aenergy_minute_ts 1788869280
setstate shelly_duo_bulb_wz 2026-09-08 14:08:00 params_cct_0_aenergy_total 30.150
setstate shelly_duo_bulb_wz 2026-09-08 12:01:59 params_cct_0_apower 0.0
setstate shelly_duo_bulb_wz 2026-09-08 12:01:59 params_cct_0_brightness 38
setstate shelly_duo_bulb_wz 2026-09-08 12:01:59 params_cct_0_ct 6500
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_cct_0_id 0
setstate shelly_duo_bulb_wz 2026-09-08 12:01:59 params_cct_0_output false
setstate shelly_duo_bulb_wz 2026-09-08 12:01:59 params_cct_0_source MQTT
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_cloud_connected false
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_events_1_cfg_rev 39
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_events_1_component sys
setstate shelly_duo_bulb_wz 2026-09-06 15:57:20 params_events_1_device_addr 7c:c6:xx:yy:zz:xx
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_events_1_device_count 0
setstate shelly_duo_bulb_wz 2026-09-06 15:57:20 params_events_1_device_encrypted false
setstate shelly_duo_bulb_wz 2026-09-06 15:57:20 params_events_1_device_local_name SBHT-003C
setstate shelly_duo_bulb_wz 2026-09-06 15:57:20 params_events_1_device_rssi -93
setstate shelly_duo_bulb_wz 2026-09-06 15:57:20 params_events_1_device_shelly_mfdata_flags 17
setstate shelly_duo_bulb_wz 2026-09-06 15:57:20 params_events_1_device_shelly_mfdata_mac 7c:c6:xx:yy:zz:xx
setstate shelly_duo_bulb_wz 2026-09-06 15:57:20 params_events_1_device_shelly_mfdata_model_id 3
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_events_1_event component_removed
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_events_1_restart_required false
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_events_1_target bthomecontrol:200
setstate shelly_duo_bulb_wz 2026-09-06 17:08:12 params_events_1_ts 1788707291.94
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_mqtt_connected true
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_available_updates_beta_version 2.0.1-beta1
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_bthc_rev 20
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_btrelay_rev 0
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_cfg_rev 39
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_fs_free 581632
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_fs_size 1048576
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_kvs_rev 0
setstate shelly_duo_bulb_wz 2026-09-08 14:05:40 params_sys_last_sync_ts 1788869139
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_mac 9070694A9E14
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_ram_free 162292
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_ram_min_free 120848
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_ram_size 279072
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_reset_reason 1
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_restart_required false
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_schedule_rev 0
setstate shelly_duo_bulb_wz 2026-09-08 14:05:40 params_sys_time 14:05
setstate shelly_duo_bulb_wz 2026-09-08 14:05:40 params_sys_unixtime 1788869139
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_uptime 142086
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_utc_offset 7200
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_sys_webhook_rev 0
setstate shelly_duo_bulb_wz 2026-09-08 14:08:00 params_ts 1788869280.00
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_wifi_bssid cc:ce:xx:yy:zz:xx
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_wifi_channel 1
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_wifi_rssi -54
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_wifi_ssid Goldstaender
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_wifi_sta_ip 192.168.178.15
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_wifi_sta_ip6_1 fe80::9270:xx:yy:zz
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_wifi_sta_ip6_2 2001:16b8:a287:4f00:9270:xx:yy:zz
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_wifi_sta_ip6_3 fddf:3375:e7db:0:9270:xx:yy:zz
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_wifi_status got ip
setstate shelly_duo_bulb_wz 2026-09-08 08:35:49 params_ws_connected false
setstate shelly_duo_bulb_wz 2026-09-08 14:08:00 src shellyduobulbg3-9070694a9e14
setstate shelly_duo_bulb_wz 2026-09-08 12:01:59 state off
- sollten komplexe JSON-Strukturen als payload verwendet werden, dann bitte möglichst auch Infos, was das Gerät wie sendet. Wer das nicht mitschneiden kann/will, kann autocreate am IO auf "complex" stellen, dann kann ich besser raten...
mach ich nachträglich, am besten wie? was ist komplex? mein ... für mich ist alles komplex *g*
- links auf die Projekthomepage, optiomalerweise (auch) dahin, wo der MQTT-spezifische Teil zu finden ist (topic-Pfade und payload-Beschreibungen).
da mußt mir weiterhelfen, was du gerne hättest und wo ich das bei shellys her nehme.
das homeassistant dingens hat bei mir sowieso ned gefunzt, also verstorben ...
gut, viel neues ist es nicht, aber du wirst mir schon sagen, was ich noch wie zu liefern habe.
nach der vorlage, die wir (hoffentlich) hier zusammen kriegen, kriegst auch den rest meiner spielsachen dann, so du magst.
im speziellen frag' ich mich ja, ob das mit den bt-devices auch einzubinden wäre. die müsste man dann halt auch gleich irgendwie benennen können, weil 201, 202, 203, ... is auch ned abendfüllend. das wäre aber nur so ne idee. ich leb auch ohne ganz gut.
schau dir MQTT2_DISCOVERY an. das ist jetzt auch nativer Shelly Support drin, damit das auch ohne addon script funktioniert. Ich hab das gerade mal mit 2 meiner Shellys probiert. Die wurden nach einem fhem Neustart oder im MQTT2_DISCOVERY Device per set "discoverShelly" gefunden und wie folgt angelegt:
define shelly1g4_********* MQTT2_DEVICE shelly1g4_*********
attr shelly1g4_********* readingList mqtt2_discovery/MQTT\.Discovery/shelly/198459e3cba11474/state/rpc:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_0bf3ff61f299274d', $EVENT) }\
shelly1g4-*********/events/rpc:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_25410cae45d93477', $EVENT) }\
shelly1g4-*********/online:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_074aad52d83c06af', $EVENT) }\
shelly1g4-*********/status/input:0:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_4be59e8e22296b47', $EVENT) }\
shelly1g4-*********/status/switch:0:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_c73acdc6faa3cb76', $EVENT) }\
shelly1g4-*********/status/sys:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_c9999ea02320ace1', $EVENT) }\
shelly1g4-*********/status/wifi:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_bec2055c577e274d', $EVENT) }
attr shelly1g4_********* setList switch_0:on,off { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_773c31e37677a16e', $EVENT) }
setstate shelly1g4_********* 2026-09-08 16:42:28 IODev mqtt2s
setstate shelly1g4_********* 2026-09-08 16:57:01 availability online
setstate shelly1g4_********* 2026-09-08 16:57:01 input_0 true
setstate shelly1g4_********* 2026-09-08 16:57:01 switch_0 true
setstate shelly1g4_********* 2026-09-08 16:57:01 switch_0_temperature 43.3
setstate shelly1g4_********* 2026-09-08 16:57:01 sys_uptime 4100
setstate shelly1g4_********* 2026-09-08 16:57:01 wifi_rssi -78
Alles direkt funktional. Teste das doch einfach mal mit der neuen Dev Version.
update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
update
auf https://github.com/next81/fhem.MQTT2_Discovery/tree/dev einfach nach Shelly suchen, wenn du da noch was erklärt brauchst.
Hab mich mit dem MQTT2_DISCOVERY noch nicht beschäftigt und auch nie was in so einem Json drinsteht.
Kann man es nicht an irgendwas festmachen (wo es geht), gleich auf die Fhemtypischen Readings zum mappen: https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings
jetzt sperren ma die 2 in ein tiefes loch und warten, bis es selbsterstellende templates mit readings nach der genfer konvention gibt ... *bg*
Irgendwo wo oben (finds nicht mehr, ist jetzt weg) war deine Vorgabe du willst es in ein paar Jahren auch noch verstehen.
Das beste für dich wär halt, das gar nix anrührst und es out of box funzt...
wäre tatsächlich das beste.
und nur zur sicherheit:
mein geistiger erguss von oben sollt eher witzig sein, den irgendeine forderung.
ich würd mir auch nie die frechheit raus nehmen, eine forderung zu stellen (dafür zahl ich hier zu wenig), ich erkläre max. meine situation.
Zitat von: TomLee am 08 September 2026, 17:47:48Hab mich mit dem MQTT2_DISCOVERY noch nicht beschäftigt und auch nie was in so einem Json drinsteht.
Kann man es nicht an irgendwas festmachen (wo es geht), gleich auf die Fhemtypischen Readings zum mappen: https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings
wird es ja, nur intern. das Problem ist, das man es händisch bearbeiten können soll und dafür brauchts referenzen. Das hab ich jetzt so gelöst. Es wird ja richtig gemapped. Das kann man oft viel einfacher machen. Das Problem sind aber die Sonderfälle, die manche devices mit sich bringen
Zitat von: the ratman am 08 September 2026, 18:25:02mein geistiger erguss von oben sollt eher witzig sein, den irgendeine forderung.
ich würd mir auch nie die frechheit raus nehmen, eine forderung zu stellen (dafür zahl ich hier zu wenig), ich erkläre max. meine situation.
Das hatte ich schon so verstanden, und auch den Willen erkannt, die "Bringschulden" zu erfüllen.
Die vorhandenen attrTemplate sollen v.a. funktionale Devices bringen, die aus FHEM-Sicht "typisch bedienbar" sind. Das geht ausdrücklich an manchen Stellen zulasten der Performance, um auch mal auf den Thread MQTT best current practice (https://forum.fhem.de/index.php?topic=145198.0) zu verweisen und klarer zu machen, warum es (berechtigte) Kritik an der einen oder anderen Stelle gibt.
Zitat von: TomLee am 08 September 2026, 18:13:50Irgendwo wo oben (finds nicht mehr, ist jetzt weg) war deine Vorgabe du willst es in ein paar Jahren auch noch verstehen.
Das beste für dich wär halt, das gar nix anrührst und es out of box funzt...
Das Beste wäre, wenn man auch noch nach Jahren halbwegs nachvollziehen kann, wie die nach dem aktuellen Stand der Dinge erforderlichen Puzzleteile zusammengehören. Also nochmal zum vertiefteren Verständis ein paar Anmerkungen dazu, wie man Helfern für MQTT-Themen hilft, wenn man wenig Ahnung hat:
- Man versucht rauszufinden, was das betreffende Gadget sendet, wenn man es lokal (oder per eigenem Web-Interface) bedient. Dazu kann man den "Show MQTT traffic"-Knopf am jeweiligen MQTT2_(SERVER|CLIENT) aktivieren, was zwischenzeitlich auch wieder voll funktional sein sollte. Alternativ arbeitet man sich in "mosquitto_sub" ein, siehe auch https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Mqtt#step-6-receive-notifications-over-mqtt.
- Manche Gadgets versuchen, einem zu helfen, indem sie "discovery"-Informationen schicken. Für FHEM war das bisher völlig sinnfrei und ergab nur ein Haufen unverständlicher Readings, daher war seither die Empfehlung, diese Messages direkt zu verwerfen (ignore am IO). Dennoch steht da natürlich drin, wie sich das Gadget per MQTT steuern läßt. Prinzipiell hilfreich, wenn man den JSON-Blob mit den Infos sinnvoll darstellt.
- Die Alternative ist, entweder zu rätseln, bekannte Geräte derselben Quelle (Shelly) durchzuprobieren oder eben die dazu passende Doku zu suchen (und zu verlinken). Das wäre hier https://shelly-api-docs.shelly.cloud/gen2/Devices/Gen3/ShellyDuoBulbG3, aus der dann insbesondere abzulesen wäre, wie man das Ding steuern kann.
Letzteres ist hier ja schon bekannt, und eventuell (!) auch nicht der einzige Weg (anscheinend kann man auch andere Formate wie dieses ausgesprochen komplizierte rpc-Gedöns verwenden, wenn man Lust hat, das auszuprobieren oder die Doku findet).
- zu guter Letzt ist es v.a. für komplett unbekanntes Terrain hilfreich, wenn man Topic-Payload im Klartext hat (dann kann man z.B. mosquitto_pub verwenden, um testweise nachzustellen, was passiert, oder wenigstens raw-Definitionen einspielen, ohne lange umformatieren zu müssen (z.B. aus dem "Copy for forum" Format).
Da der Kontext hier klar ist, (und wir daher eigentlich auf umfangreiche Tests verzichten können?!?) stellt sich jetzt v.a. die Frage, wie man auf dem Hin- und Rückweg dieselben Readings verwendet/setzt.
Das macht die Kombi aus readingList und jsonMap - vorausgesetzt, man weist json2nameValue() an, das letztere auch zu benutzen - wir brauchen also die "lange Form":
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }
$DEVICETOPIC/online:.* online
$DEVICETOPIC/rpc:.* {}
fhem/rpc:.* {}
Der letzte eintrag dient dazu, die (mir völlig unsinnig vorkommende) Rückmeldung des Aktors zu verwerfen, mit der dieser mitteilt, dass er die prc-Infos bekommen hat... Diesen braucht man allerdings eigentlich in einer FHEM-Installation genau ein mal, dann hat sich das. (Siehe "Effizienz" oben).
Klarer?
Die Sonderfälle hab ich ja mit "wo es geht" erstmal ausgenommen.
Kannst mal zeigen welche Readings mit dem JSON der Bulb von @the Ratman erstellt würden?
das geht nicht so mal eben, weil das bei shellys aktiv abgefragt werden muss. aber grundsätzlich alle die es gibt mit vernünftigen namen. ich habs halt nur mit shelly 1 gen 4 testen können, weil ich nur die hab. ich hab das aber universell integriert. deswegen ja mal testen 8) sollte eigentlich alles funktionieren und alle verfügbaren readings/sets/gets liefern
gut, ich ersetze mein zeug mit
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }
$DEVICETOPIC/online:.* online
$DEVICETOPIC/rpc:.* {}
fhem/rpc:.* {}alles andere lass ich derweil mal, wie es ist.
ct, pct kommt mal neu als reading (hatte die mal weggemacht zum suchen) - traraaaa - sowhl pct und ct werden gemerkt, sind verstellbar ... ich wäre also somit abgespeist und zufrieden - danke euch nochmal!
falls man von mir was benötigt, und ich dazu nicht mein fhem killen muss - nur sagen.
ich besitze derweil:
o) 2 dieser bulbs
o) eine 4fach steckdose
o) eine einfach steckdose (die kleine mit a bissi weniger ampere)
o) einen shelly plus uno noch ungelötet, also noch ein nackter. mit dem könnt ihr mich bei lust fernsteuern. der hats noch nicht eilig eingesetzt zu werden, stünde also zur verfügung. der würde wahrscheinlich eh auch ein paar tunings vertragen. ich hab dessen einstellungen zusammengekrazt und sicher falsch, wenn er auch mal grundlegend macht.
und daran hängen div. blu sensoren/aktoren:
o) mehrere 4fach taster
o) temp sensoren
o) einen fensterkontakt https://www.conrad.de/de/p/shelly-blu-zb-door-window-white-shelly-sensor-bluetooth-zigbee-3775976.html mit total sinnloser lux funktion, dafür super kipperkennung.
o) sobald conrad mit mir gnädig ist (also in gefühlt 10 jahren), einen https://www.conrad.de/de/p/shelly-shelly-plus-rgbw-pm-controller-bluetooth-wi-fi-3308356.html rgbw unterputz schalter für 12 bis 24v.
was ich noch hätte wären gehäuse für die dinger zum selber drucken. wer die will kriegt die stl's zugesendet, wenn er verspricht sie nicht an andere als fheml'er weiter zu geben.
ein paar bilder: https://www.kodinerds.net/thread/81059-shelly-halterungen-mit-3d-druck/
ajo, die wandtaster haben schon mehrere halterungen. vor allem welche, die keinen rahmen mehr brauchen, also nur noch das einstecken des tasters erfordern. bspl. im anhang
Zitat von: Beta-User am 08 September 2026, 18:56:32Klarer?
sagen mas mal so: ich glaube so halbwegs zu kapieren, was du mir grade zeigen willst. allerdings bezweifel ich, dass ich jetzt lustig ein neues device anlegen könnte.
ich hab mir jetzt am mqtt2server mal show mqtt traffic gegeben - kannst mir eigentlich auch gleich den matrix screensaver anwerfen ... hat ungefähr die selbe bedeutung für mich *g*. ich denke aber, ich würde dort nach anweisung was finden, dass dann hier helfen könnte.
@the Ratman
Kannst du mal in deiner MQTT2_SERVER Definition "ratBroker" oben auf "Show MQTT traffic" klicken, bei Filter "discovery" eingeben, die Bulb einmal neu starten und die Ausgabe hier posten?
Ich kenns aus der Vergangenheit nur so, kann sein das der Zweig auch abgefragt werden muss, keine Ahnung.
Guybrush sein Agent bekommts nicht hin, anhand der bisher gezeigten Readings nachzuvollziehen wie json2nameValue Readings erstellt um den Json abzuleiten...
hmm,
wenn ich dicovery als filter nehme, die bulb einschalte und wieder ausschalte kommt gar nix.
die zeile schaut dann so aus: "Hide MQTT traffic Reset Filter: discovery"
mit .* kommt (ich hoffe, ich hab den rest weg) - für einmal on und einmal off:
19:51:46.069 SENT shellyduobulbg3-9070694a9e14/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":true}}
19:51:46.091 shelly_blug_duo_wz fhem/rpc {"id":0,"src":"shellyduobulbg3-9070694a9e14","dst":"fhem","result":null}
19:51:46.118 shelly_blug_duo_wz shellyduobulbg3-9070694a9e14/events/rpc {"src":"shellyduobulbg3-9070694a9e14","dst":"shellyduobulbg3-9070694a9e14/events","method":"NotifyStatus","params":{"ts":1788889905.11,"cct:0":{"apower":4.5}}}
19:51:46.125 shelly_blug_duo_wz shellyduobulbg3-9070694a9e14/events/rpc {"src":"shellyduobulbg3-9070694a9e14","dst":"shellyduobulbg3-9070694a9e14/events","method":"NotifyStatus","params":{"ts":1788889905.11,"cct:0":{"brightness":50,"ct":2700,"output":true,"source":"MQTT"}}}
19:51:48.349 SENT shellyduobulbg3-9070694a9e14/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":false}}
19:51:48.370 shelly_blug_duo_wz fhem/rpc {"id":0,"src":"shellyduobulbg3-9070694a9e14","dst":"fhem","result":null}
19:51:48.398 shelly_blug_duo_wz shellyduobulbg3-9070694a9e14/events/rpc {"src":"shellyduobulbg3-9070694a9e14","dst":"shellyduobulbg3-9070694a9e14/events","method":"NotifyStatus","params":{"ts":1788889907.39,"cct:0":{"brightness":50,"ct":2700,"output":false,"source":"MQTT"}}}
19:51:48.408 shelly_blug_duo_wz shellyduobulbg3-9070694a9e14/events/rpc {"src":"shellyduobulbg3-9070694a9e14","dst":"shellyduobulbg3-9070694a9e14/events","method":"NotifyStatus","params":{"ts":1788889907.40,"cct:0":{"apower":0.0}}}
gehen ma mal von aus, du meinst ned nur schalten, sondern reboot ... kommt gleich
nö, nach bulb reboot kommt auch nix
Zitat von: Guybrush am 08 September 2026, 19:34:41das geht nicht so mal eben, weil das bei shellys aktiv abgefragt werden muss.
Dann wird es wohl so sein, ich will und mag mich damit aktuell nicht beschäftigen...
shelly schickt nativ keine discovery messages. das muss aktiv abgefragt werden. sonst reichts ja passiv zu lauschen (bei homeassistant kompatiblen devices). die capabilities bekommt man so aber nicht mit. mit autocreate werden zumindest readings erstellt. wenn man aber fertige listen haben will, geht es nur mit discovery messages oder in dem fall bei shelly mit aktiver abfrage. das ist nativ im Modul drin. Ich hab das Modul ja auch deshalb entwickelt, weils für viele zu kompliziert ist/war die reading/setLists richtig zu konfiguieren und auch mir das mit den templates offen gesagt schon immer zu aufwendig war. lief am ende immer darauf hinaus alles zu matchen und dann step by step zu reduzieren. war aber alles zuviel aufwand...
Ja, sry. Reboot war gemeint oder kurz Spannungsfrei machen.
würde man dass über den mqtt explorer raus kriegen? https://mqtt-explorer.com/
hätte den unter win installiert, aber mich damit nie beschäftigt. da müsstes also auch sehr genau sagen, was und wie ...
Selbst mit Rechtschreibfehlern in den Suchwörtern zeigt mir die KI Übersicht bei Google die Antwort auf deine Frage:
Zitatdiycovery request mqtt shell gen4
natürlich bekommt man das alles raus, wenn du den mqtt stream mitließt. das ist aber alles aufwendig und nicht ganz trivial. versuch doch einfach nochmal das MQTT2_DISCOVERY. Das funktioniert mit Shellys nativ in der neuen Version. Das ist eher das, was du brauchst
Zitat von: TomLee am 08 September 2026, 20:55:46Selbst mit Rechtschreibfehlern in den Suchwörtern zeigt mir die KI Übersicht bei Google die Antwort auf deine Frage:
Zitatdiycovery request mqtt shell gen4
update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
update
save
shutdown restart
nach neustart:
define mqtt2d MQTT2_DISCOVERY <DEVICE MQTT2_SERVER|CLIENT>
set mqtt2d activate
set mqtt2d discoverShelly
mehr musst du nicht tun! danach sollten deine shellys automatisch angelegt werden. vorher deine jetzigen shelly devices am besten löschen (copy&paste lokal in ner txt sichern schadet nicht..)
ich hätte noch eine große bitte!
es geht um eine shelly plug s gen3. in ermangelung intelligenter ideen hab ich einfach alles von einer shelly 4fach steckdose übernommen.
das funzt zwar, aber es ist sogar mir klar, dass das unten gelistete grotten falsch ist. also bitte nicht gleich lachen ...
defmod shellyplugsg3_d0cf13d85610 MQTT2_DEVICE shellyplugsg3_d0cf13d85610
attr shellyplugsg3_d0cf13d85610 devStateIcon on:weather_pollen@green off:weather_pollen@grey .*:weather_pollen@orange
attr shellyplugsg3_d0cf13d85610 devicetopic shellyplugsg3-d0cf13d85610
attr shellyplugsg3_d0cf13d85610 readingList shellyplugsg3_d0cf13d85610:shellyplugsg3-d0cf13d85610/online:.* online\
shellyplugsg3_d0cf13d85610:shellyplugsg3-d0cf13d85610/events/rpc:.* { json2nameValue($EVENT) }\
shellyplugsg3_d0cf13d85610:shellyplugsg3-d0cf13d85610/rpc:.* { json2nameValue($EVENT) }\
shellyplugsg3_d0cf13d85610:fhem2shelly/rpc:.* { json2nameValue($EVENT) }
attr shellyplugsg3_d0cf13d85610 setList off:selectnumbers,0,1,3,0,lin $DEVICETOPIC/rpc {"id":$EVTPART1,"src":"fhem2shelly","method":"Switch.Set","params": {"id":$EVTPART1,"on":false}}\
on:selectnumbers,0,1,3,0,lin $DEVICETOPIC/rpc {"id":$EVTPART1,"src":"fhem2shelly","method":"Switch.Set","params": {"id":$EVTPART1,"on":true}}
und darf i no a frage stellen, wegen der mqtt templates?
wie ist das eigentlich aufgebaut? bisher war ich der meinung, es kommt halt irgendein neues device von shelly raus, jemand schreibt ein template dafür und stellts zur verfügung. denke, das ist falsch?
wonach geht das bei shelly? generationen, firmware, ...? sprich: wie erkenne ich, welches template ich für was verwenden kann?
btw - hab mich mit meiner plug gespielt ... auf an grünen zweig komm ich damit nicht.
was ist da falsch dran?
attr shellyplugsg3_wz_3d_drucker readingList $DEVICETOPIC/online:.* online\
$DEVICETOPIC/rpc:.* {}\
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT) }\
shellyplugsg3_wz_3d_drucker:shellyplugsg3-wz_3d_drucker/events/rpc:.* { json2nameValue($EVENT) }
attr shellyplugsg3_wz_3d_drucker setList off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":false}}\
on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":true}}\
toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"CCT.Toggle","params":{"id":0}}
ich versteh nicht mal, warum mein device jetzt shellyplugsg3_wz_3d_drucker:shellyplugsg3-wz_3d_drucker/ heißt.
das war doch sonst das, was im src reading stand? in dem fall: shellyplugsg3-d885ac1b0f54
templates sind nichts anderes als vorkonfiguierte topic/list verknüpfungen. Nimm MQTT2_DISCOVERY .. mach dir doch das Leben nicht so schwer
@Guybrush ... weil ich gerne so nahe wie möglich am "original" bleibe.
in fhem hab ich wenigstens im ansatz eine chance, hilfe zu kriegen, wenn z.b. der original maintainer keine lust mehr hat.
hörst du auf - aus welchen gründen auch immer - schauts wohl nicht so lustig aus. wer hilft mir dann bei einem ungewarteten zusatzmodul, das scheints auch noch umstritten ist?
gut, es geht mich auch nix an, aber ich verstehe schon nicht, warums ihr euch ned zusammen tuts, und was gemeinsames machts. ein simples modul, dass auch von simplen menschen wie mir bedient werden kann.
ein (nur leicht dramatisiertes) beispiel, wie ich das empfinde:
1) hast eine neue shelly, nimmst du das shelly modul. logisch, oder? bis du drauf kommst, dass das ganze blu zeugs da ned funzt (oder das letzte mal, als ich geschaut hab, nicht ging).
2) nimmst du mqtt, bis du drauf kommst, dass du da irgendwelche readings erst mal zusammentragen musst, um einen dämlich knopf drücken zu können.
3) probierst du templates - so ohne sinn und verstand, weil du keine ahnung hast, was da was sein soll. was die forensuche bringt, funzt auch max. semi gut.
4) gehst du zum 1000 mal in 1000 foren, kriegst 1000 verschiedene infos - irgendwann mal gibts auf, das alles zu probieren.. der überblick ist eh nimma da.
5) mittlerweile sind 6 monate um, und du hast endlich a bissl funzende zeugs zusammen gebracht, schon sollst du wieder auf irgendwas anderes umstellen, musst dein ganzes zeug neu anpassen, ohne zu wissen, ob das dann auch noch alles geht und du überhaupt noch weißt, was da dann was ist.
6) und wenns nicht geht, kannst wieder irgendwelche backups zurück spielen und dir anhören, dass das ja alles, anders gelöst, viel einfacher wäre. und du wolltest eigentlich nur eine steckdose einschalten ...
Der einzige Sinn und Zweck von MQTT2_DISCOVERY ist es deine readingList und setList automatisiert anzulegen. Du bekommst damit also genau das was du die ganze Zeit suchst. Du kannst die Einträge danach ja wieder selbst bearbeiten, wenn du das willst. MQTT Templates sind jedenfalls nur ein Behelf, weil FHEM bislang kein natives Discovery hatte. Du musst es ja nicht nutzen. Ich sag nur, dass es damit plug&play ist und du ein fertiges device in fhem danach hast, was die Funktionalität deines Shellys abbilden sollte. Du kannst natürlich auch alles händisch machen. Das war mit aber auch schon immer zu viel, weshalb ich dann das Modul dafür entwickelte
gut, hab mal eine neue plug mit deinem discovery angelernt und funzt auf anhieb.
ich ärger mich grad nur mit webcmd und devstateicon rum, dass will nicht, aber jo mei ...
auf jeden fall mal vielen dank!
aber geht schon los - erste plug erfolgreich.
drum hab ich auch die 2. gelöscht, fhem restartet, aber nun findet dein modul das device nicht - ist eine baugleiche steckdose wie die erste ...
gut, also device wieder über den server eingebunden - und rebuild probiert ...
shellyplugsg3_sz_angi_venti wird von mqttDiscovery nicht verwaltet
ich sehe grade, dafür hat dein discovery meine andere, schon ins system eingebundene plug und auch meine 4-fachsteckdose erweitert. dachte, der greift vorhandenes nicht an?
ach, die lampen aber nur halb *g* jessas maria ...
aber immerhin - den shelly plus uni hat er in ruhe gelassen - liegt wahrscheinlich hauptsächlich daran, dass der nicht am strom war ...
Zitat von: the ratman am 10 September 2026, 20:45:49gut, hab mal eine neue plug mit deinem discovery angelernt und funzt auf anhieb.
ich ärger mich grad nur mit webcmd und devstateicon rum, dass will nicht, aber jo mei ...
auf jeden fall mal vielen dank!
8) ;D
wie heisst denn dein discovery device? du musst in dem einmal rebuildDevice shellyplugsg3_sz_angi_venti clearReadings machen. Dann übernimmt discovery das device und verwaltet es. Manuell angelegte readinglists bleiben sonst aussen vor. Einrichtung startet aber erst wenn messages von dem shelly kommen. ohne gehts nicht. daher auch den shelly einfach mal neu starten. wenn bei dir was erweitert wurde, dann nur deshalb weil du nicht alle readings in deinen lists hattest. überschrieben/geändert wird da aber nix (jedenfalls solang du den modus auf conservative belässt und nicht auf replace stellst)
das probier ich morgen dann.
lästig ist halt, dass div. readings auch anders heißen.
z.b. online true/false wird availability online/offline.
wenn ich wirklich alle devices mit deinem modul angreife, gibt das 'ne nette fleißaufgabe. weil wenn, dann mach ich alles neu und bau dann auch meine doifs usw. auf deine benennungen um.
und ich geb zu: ist sehr verführerisch. aber da tritt wieder meine angst vom "verschollenen maintainer" in meine gedankengänge.
availability ist mehr als nur ein online status. es ist möglich, dass mehrere bedingungen erfüllt sein müssen, damit ein gerät als online gilt. je nachdem was in den discovery messages gemeldet wird. das macht discovery aber alles, weshalb ich da Jinja Support integriert hab. Ich hab da echt viel Zeit reingesteckt um die Flexibilität, die fhem nunmal im Vergleich zu HA bietet, erhalten zu können. Mit strikten Vorgaben wäre es einfacher gewesen, aber das will (zu recht) nicht jeder. Deswegen gibts auch die Kapselungen mit MQTT2_DISCOVERY_runtimeRef(). Muss dich aber alles nicht interessieren, was unten drunter im Detail passiert. Wichtig ist nur dass vernünftige Readings entstehen und die Sets funktionieren, die es gibt.
du könntest zur Kompatibilität erstmal auch einfach ein userReadings online availabilty anlegen.
bleiben tatsächlich nur noch die fragen, was mit blu readings passiert. bei neu angelegten und zu übernehmenden devices und wann du die der pulps einbaust.
Shelly: Komponente cct:0 wird noch nicht unterstuetztajo, wegen
Zitatwenn bei dir was erweitert wurde, dann nur deshalb weil du nicht alle readings in deinen lists hattest. überschrieben/geändert wird da aber nix
is schon klar. aber ahnungslos, wie man halt ist, ist auf einmal alles doppelt gemoppelt. ich kann dann ja mit alten und neuen schaltern schalten. und - ohne es lange probiert zu haben - ist der verdacht bei mir aufgekommen, dass dann um die hoheit gekämpft wird. so schaltet zwar alles richtig, aber in einer readingsgroup (mit den originalen readings) im floorplan wird der zustand nur verzögert oder nach neuem laden angezeigt.
bin grad am probieren ... ein rebuildDevice shellyplugsg3_sz_angi_venti clearReadings
(dein modul, siehe screenshot, erkennt den namen auch richtig)
endet leider auch nur in "shellyplugsg3_sz_angi_venti wird von mqttDiscovery nicht verwaltet". egal, ob reboot des plug, vom strom nehmen, dein rebuilddevice vor oder nach dem reboot ...
das kommt im nächsten update rein. ich kann das aber leider nur über unittests und shelly doku validieren, weil ich so einen shelly nicht selbst hab. dadurch zieht sich das etwas
wegen deines anderen shelly:
wie ist da der mqtt prefix von? den nachfolgend einsetzen
set mqttDiscovery discoverShelly <MQTT-Topic-Prefix>
set mqttDiscovery rebuildDevice shellyplugsg3_sz_angi_venti clearReadings
problem gefunden - mein prefix hatte leerzeichen. scheint den mqtt2server nicht zu stören, deinen discover schon
gut, nun hab ich 2 steckdosen nach deinen einstellungen neu drinnen.
der rest hat mal deine angaben zusätzlich in der readinglist und teilweise in der setlist. schauen ma mal, ob ich mir gestern die "streiterei" nur eingebildet hab.
was mir noch fehlt, is tasächlich der status. ich kriege keine schaltbare, grafische anzeige hin. also z.b. für dose ein aus.
gut, schaltbar geht mit webcmd *g*. aber das wäre in meinen augen nicht "fhem standard"
was die pulps angeht ... kann ich dir helfen?
wenn dann aber wie immer: ich hab 0 ahnung und mach nur blöd, was du mir hier schreibst. denken wirst in der beziehung ausschließlich du!
das geht einfach mit devStateIcon. z.b.
müsste bei dir in etwa so aussehen (vorausgesetzt switch_0 ist das was du steuern willst):
attr shellyplugsg3_sz_angi_venti devStateIcon true:control_on_off@green false:control_standby@orange
attr shellyplugsg3_sz_angi_venti eventMap /switch_0 on:Ein/switch_0 off:Aus/
attr shellyplugsg3_sz_angi_venti stateFormat switch_0
attr shellyplugsg3_sz_angi_venti webCmd Ein:Aus
Zitat von: Guybrush am 11 September 2026, 12:02:21das geht einfach mit devStateIcon. z.b.
müsste bei dir in etwa so aussehen (vorausgesetzt switch_0 ist das was du steuern willst):
attr shellyplugsg3_sz_angi_venti devStateIcon true:control_on_off@green false:control_standby@orange
attr shellyplugsg3_sz_angi_venti eventMap /switch_0 on:Ein/switch_0 off:Aus/
attr shellyplugsg3_sz_angi_venti stateFormat switch_0
attr shellyplugsg3_sz_angi_venti webCmd Ein:Aus
eventMap ist imo Mist und sollte vermieden werden.
genau die hätte ich vergessen. naja, zumindest zeigt mir jetzt der schalter an und aus an. schalten tut er eh nicht.
ich nehme natürlich gerne alternive/bessere/lustigere/... lösungen *g*
schalten sollte aber gehen. dann musst du gucken was du hast. switch_0 wirds ja wohl sein?
klar, sonst würd er auch nix anzeigen.
allerdings müsste das ja ein toggle sein, und den haben ma ja nicht, is mir so nebenher eingefallen *g* oder wart, da war doch was mit schaltbefehl hinten dran ... ich schau nochmal
aber passt schon - ich hab meine zustandsanzeige wieder fürs schnelle "drüber schauen", das is da eh das wichtigste. der rest rennt bei mir eh über readingsgroups. und die hab ich zum glück grundlegend im griff ...
hab ich doch mal richtig geraten:
devstateicon --> true:control_on_off@green:Aus false:control_standby@orange:Ein
Zitat von: the ratman am 11 September 2026, 14:00:08hab ich doch mal richtig geraten:
devstateicon --> true:control_on_off@green:Aus false:control_standby@orange:Ein
Ohne dieses unselige eventMap:
true:control_on_off@green:switch_0+onImo sollte ein "Hauptkanal" immer on und off ohne Channel-Nummer verstehen. Sonst geht auch SetExtensions nicht (on-for-timer usw.).
natürli no schöner, und funzt. eventmap is auch geschichte.
dank dir!
so, nun hab ich das erste device mit blu sensoren übernommen - ich hätte warscheinlich noch a 3. mal fragen sollen ... wie komm ich an miene blu devices, weil die sind weg?
mit dem nächsten update von mqtt2_discovery werden die auch behandelt. das schaff ich vielleicht morgen zu publishen
tu ned hetzten - habs backup zurück, die pflanzenlampen schalten wieder, die sensoren sensoren wieder, die taster tasten wieder.
ich glaub aber, wir müssen no an unserer kommunikation arbeiten. dachte, das is kein thema, nachdem du dazu nix gesagt hast.
sind dann übrigens alle blu drinnen?
bisher hab ich zumindest mal blu ht, blu wallswitch4, blu door/window davon meistens mehrere und ein paar auch in der neueren zigbee version (aber das dürfte ja ned wirklich stören)
Zitat von: the ratman am 10 September 2026, 13:31:37und darf i no a frage stellen, wegen der mqtt templates?
wie ist das eigentlich aufgebaut? bisher war ich der meinung, es kommt halt irgendein neues device von shelly raus, jemand schreibt ein template dafür und stellts zur verfügung. denke, das ist falsch?
wonach geht das bei shelly? generationen, firmware, ...? sprich: wie erkenne ich, welches template ich für was verwenden kann?
Zitat von: Guybrush am 10 September 2026, 17:37:12MQTT Templates sind jedenfalls nur ein Behelf, weil FHEM bislang kein natives Discovery hatte.
Vielleicht noch ein paar Anmerkungen dazu, nachdem ich jetzt eine richtige Tastatur benutzen kann:
Man kann die Sammlung in attrTemplate als "Behelf" abtun, aber zum einen ist das entstanden, als viele gängige Gadgets auch noch kein "discovery" kannten, und zum anderen folgen diese "Vorlagen", oder vielleicht besser als Gestaltungsvorschläge zu bezeichnete Sammlung, einer gewissen Logik, die v.a. auch darin besteht, "workarounds" für typische Probleme anzubieten, die eben mit den Gadgets verbunden sind.
Das beginnt bei "Kleinigkeiten", wie eben der Präferenz von "split"-Templates, bei denen jeder Kanal als eigene MQTT2_DEVICE-Instanz repräsentiert wird, damit man je einen eigenen "on" und "off"-setter erhält.
Entstanden ist es als kurratierte Sammlung, zu der im Prinzip jeder beitragen konnte, der wollte. Von daher hat recht häufig jemand einen Vorschlag gemacht (oder auch nur ein fertig konfiguriertes Device gezeigt), aus dem dann unter Beachtung der oben kurz angerissenen Designvorgaben dann eben ein template wurde, das im Ergebnis eine gewisse "Einheitlichkeit" im look&feel mit anderen Devices mit ähnlicher Funktionalität erreicht werden kann.
Nicht alles ist "gut" oder entspricht meinem ganz persönlichen Geschmack, aber jeder kann das Ergebnis ändern, wie er mag und sollte erst mal eine funktionale Ausgangsbasis haben.
Da ich als "Kurator" weder in der Lage bin, alle bekannten Gadgets je mit einem 1:1 passenden template zu versehen, und das auch nicht sinnvoll ist, sind die in der Regel so organisiert, dass man erst mal innerhalb der Familie (z.B. Shelly "alt" oder "rpc") sieht, welche Auswahl da ist, und sich dann das funktional am nächsten liegende (anhand der Beschreibung oder der "Kommandos") aussuchen muss oder kann. Wenn man also eine Bulb hat, kann es sein, dass für sowas schon was da ist (vielleicht mit Farbe, aber ohne cct), in der Regel paßt zumindest der "plug" auch für ein dimmbares Licht (dann halt nur on/off).
Mein Wunsch an "MQTT2_DISCOVERY" wäre, dass Klarheit über die zu erzielenden Design-Vorgaben herrscht. Von daher fand ich den Ansatz von Martin gut, es durch "ergänzende Angaben" zu ermöglichen, dass ggf. auch mehrere "channels" angelegt werden. Zumindest für "häufige Devices" (wie Tasmota-basiert oder Shelly, vielleicht auch zigbee2mqtt) dürfte es möglich sein, das zu leisten.
Falls Fragen zu den Design-Vorgaben (aus der "alten Welt") an sich bestehen sollten, gebe ich gerne meinen Senf dazu, wenn ich an einer Tastatur sitze dann ggf. auch mit etwas weniger kurzen Fassungen wie "eventMap ist unselig".
wie meinst du das denn mit mehreren channels? MQTT2_DISCOVERY legt bereits alle an, die ein device hat. Ich bin da aber auch total offen für konstruktive Vorschläge!
Im Unterbau hab ich z.b. schon eine semantic map drin. Damit kann man dann auch automatisiert visualisierungen umsetzen. das hab ich bei mir lokal schon seit längerem laufen und ist ganz cool geworden. Das ist im prinzip FTUI3 und lässt sich entsprechend anpassen, aber man hat dann halt für jedes device schon ein passendes template, wo man nur noch mit css ran muss (wenn gewünscht). Das ist quasi ein HA Frontend für Fhem. Die Semantic Map lässt sich aber auch für anders gut nutzen. Ist jedenfalls ein nettes Ding, wenn jedes reading "weiß", ob es ne Temperatur darstellt oder einen Zustand.
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?
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?
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).
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.
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.
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.
mal die readings, reichen die? ansonsten musst mir genau sagen, was du wie willst.
so schauen 1 sensor und 2 4fach taster aus:
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
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
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ß.
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
deine bitte bringt mir nicht viel, weil ich nicht weiß, wie ich sie erfüllen kann
Zitat von: the ratman am 12 September 2026, 11:18:43deine 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).
Zitat von: Guybrush am 12 September 2026, 10:03:24readings 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.
Zitat von: Guybrush am 12 September 2026, 10:03:24ch 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.
was meinen kleinen part hier angeht:
den mqtt explorer hab ich installiert, wie gesagt. der wäre mir auch ganz genehm, weil er "weit weg" von fhem ist, und ich somit nix an fhem ruinieren kann *g*
wie ich den verwende, weiß ich allerdings nicht.
wie g'sagt: punkt für punkt anleitung, sonst schreib ich euch hier wieder seitenweise zeug hin, das keinen interessiert.
aber mal probiert ... hab jetzt mal den einen plug für die pflanzenlampe unter beobachtung.
mit der zeit kommen meldungen, die hab ich mal mit der copyfunktion hier rein gestellt - geht das in die richtige richtung? blu scheint hier nix zu melden, aber ich warte mal ab, wie ich das machen soll ...
{"src":"shellyplugsg3-d0cf13d85610","dst":"shellyplugsg3-d0cf13d85610/events","method":"NotifyStatus","params":{"ts":1789287300.02,"switch:0":{"aenergy":{"by_minute":[0.000,0.000,0.000],"minute_ts":1789287300,"total":24196.846},"apower":0.0,"current":0.000,"freq":50.05,"ret_aenergy":{"by_minute":[0.000,0.000,0.000],"minute_ts":1789287300,"total":0.000},"voltage":233.3}}}
ist folgendes hilfreich?
die 1. 3 zeilen wären ein sensor blu ht
die weiteren zeilen müssten der druck eines 4fach tasters sein
{"src":"shellyplugsg3-d0cf13d85610","dst":"shellyplugsg3-d0cf13d85610/events","method":"NotifyStatus","params":{"ts":1789288905.79,"bthomedevice:201":{"last_updated_ts":1789288905,"packet_id":195,"rssi":-73}}}
{"src":"shellyplugsg3-d0cf13d85610","dst":"shellyplugsg3-d0cf13d85610/events","method":"NotifyStatus","params":{"ts":1789288845.35,"bthomedevice:201":{"last_updated_ts":1789288845,"packet_id":194,"rssi":-82}}}
{"src":"shellyplugsg3-d0cf13d85610","dst":"shellyplugsg3-d0cf13d85610/events","method":"NotifyStatus","params":{"ts":1789288845.34,"bthomesensor:202":{"last_updated_ts":1789288845,"value":63}}}
{"src":"shellyplugsg3-d0cf13d85610","dst":"shellyplugsg3-d0cf13d85610/events","method":"NotifyStatus","params":{"ts":1789289137.64,"bthomedevice:202":{"last_updated_ts":1789289118,"packet_id":143,"rssi":-51}}}
{"src":"shellyplugsg3-d0cf13d85610","dst":"shellyplugsg3-d0cf13d85610/events","method":"NotifyEvent","params":{"ts":1789289118.19,"events":[{"component":"bthomedevice:202","id":202,"event":"single_push","idx":3,"channel":-1,"ts":1789289118.19,"sensors":{"1":[{"id":204,"value":100,"last_updated_ts":1789289118}]}}]}}
{"src":"shellyplugsg3-d0cf13d85610","dst":"shellyplugsg3-d0cf13d85610/events","method":"NotifyEvent","params":{"ts":1789289118.19,"events":[{"component":"bthomedevice:202","id":202,"event":"single_push","idx":1,"channel":-1,"ts":1789289118.19,"sensors":{"1":[{"id":204,"value":100,"last_updated_ts":1789289118}]}}]}}
{"src":"shellyplugsg3-d0cf13d85610","dst":"shellyplugsg3-d0cf13d85610/events","method":"NotifyEvent","params":{"ts":1789289114.10,"events":[{"component":"bthomedevice:202","id":202,"event":"single_push","idx":0,"channel":-1,"ts":1789289114.10,"sensors":{"1":[{"id":204,"value":100,"last_updated_ts":1789289114}]}}]}}
{"src":"shellyplugsg3-d0cf13d85610","dst":"shellyplugsg3-d0cf13d85610/events","method":"NotifyStatus","params":{"ts":1789289114.02,"bthomedevice:202":{"last_updated_ts":1789289113,"packet_id":139,"rssi":-57}}}
Die Richtung ist die richtige, es geht Guybrush aber um den "discovery"-Topic, der aber wohl nur bedient wird, wenn man die discovery Message anfordert.
da müssts mir dann wirklich sagen, wie ich das mache. ich hab zwar geschaut, aber lesen von irgendwas mit discovery tu ich da mal nicht.
dieses tool kann ja ned mal die history durchsuchen. da freu ich mich jetzt schon drauf, die meldungen meines fenstersensors wieder zu finden. der hängt an der 4fach steckdose. und die ist extrem gesprächig.
gut, ich hab jetzt danke eines tipps eines bekannten, folgendes probiert:
curl -X POST -d '{"id":1, "method":"Shelly.GetConfig"}' http://192.168.178.22/rpc
{"id":1,"src":"shellypstripg4-206ef10295f4","result":{"ble":{"rpc":{"enable":false}},"bthome":{},"cloud":{"enable":false,"server":"shelly-290-eu.shelly.cloud:6022/jrpc"},"knx":{"enable":false,"ia":"15.15.255","routing":{"addr":"224.0.23.12:3671"}},"matter":{"enable":false},"mqtt":{"enable":true,"server":"192.168.178.3:1883","client_id":"shellypstripg4-206ef10295f4","user":null,"ssl_ca":null,"topic_prefix":"shellypstripg4-206ef10295f4","rpc_ntf":true,"status_ntf":false,"use_client_cert":false,"enable_rpc":true,"enable_control":true},"powerstrip_ui":{"leds":{"mode":"power","colors":{"switch:0":{"on":{"rgb":[0.000,100.000,0.000],"brightness":10.000},"off":{"rgb":[100.000,0.000,0.000],"brightness":10.000}},"power":{"brightness":10.000}},"night_mode":{"enable":true,"brightness":2.000,"active_between":["22:00","08:00"]}},"controls":{"switch:0":{"in_mode":"momentary"},"switch:1":{"in_mode":"momentary"},"switch:2":{"in_mode":"momentary"},"switch:3":{"in_mode":"momentary"}}},"switch:0":{"id":0, "name":"little bastard","initial_state":"on", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay":60.00,"power_limit":3360,"voltage_limit":280,"autorecover_voltage_errors":false,"current_limit":12.000,"reverse":false,"counts":{"enable":true,"power_thr":100}},"switch:1":{"id":1, "name":"dose 01","initial_state":"off", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay":60.00,"power_limit":3360,"voltage_limit":280,"autorecover_voltage_errors":false,"current_limit":12.000,"reverse":false,"counts":{"enable":true,"power_thr":100}},"switch:2":{"id":2, "name":"dose 02","initial_state":"off", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay":60.00,"power_limit":3360,"voltage_limit":280,"autorecover_voltage_errors":false,"current_limit":12.000,"reverse":false,"counts":{"enable":true,"power_thr":100}},"switch:3":{"id":3, "name":"dose 03","initial_state":"off", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay":60.00,"power_limit":3360,"voltage_limit":280,"autorecover_voltage_errors":false,"current_limit":12.000,"reverse":false,"counts":{"enable":true,"power_thr":100}},"sys":{"device":{"name":"shelly-4-fachsteckdose","mac":"206EF10295F4","fw_id":"20260710-101151/2.0.0-g87fbfa4","discoverable":true,"eco_mode":false,"tls_check_cert_validity_time":true,"enhanced_security":false},"location":{"tz":"Europe/Berlin","lat":48.285800,"lon":8.172400},"debug":{"level":2,"file_level":null,"mqtt":{"enable":false},"websocket":{"enable":false},"file_log":{"enable":false},"udp":{"addr":null}},"ui_data":{"device_revision":"1-58","tf":24,"df":"DD/MM/YYYY"},"rpc_udp":{"dst_addr":null,"listen_port":null},"sntp":{"server":"192.168.178.1"},"cfg_rev":111},"wifi":{"ap":{"ssid":"shelly-4-fachsteckdose","is_open":false, "enable":false, "range_extender": {"enable":false}},"sta":{"ssid":"Goldstaender","is_open":false, "enable":true, "ipv4mode":"dhcp","ip":null,"netmask":null,"gw":null,"nameserver":null},"sta1":{"ssid":null,"is_open":true, "enable":false, "ipv4mode":"dhcp","ip":null,"netmask":null,"gw":null,"nameserver":null},"roam":{"rssi_thr":-80,"interval":60}},"ws":{"enable":false,"server":null,"ssl_ca":"ca.pem"}}}
das wäre meine 4fach steckdose mit blu devices: zwei 4fach tastern, zwei ht sensoren und einem fenstersensor
(Diese Firmware ist die Pest, ich frag mich jedes Mal, warum man da nicht zu Tasmota wechselt)
Vermutlich eher"status_update" wie hier am Ende beschrieben: https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Mqtt/#configuration
leider nein ....
in beiden fällen:
status_update
status.update
{"id":1,"src":"shellypstripg4-206ef10295f4","error":{"code":404,"message":"No handler for status_update"}}
und BITTE!
schreibts mir immer vollständige befehlszeilen oder so - ich weiß ja ned, wo und wie ich was einfügen muss.
Das musst du als MQTT-Kommando selbst zusammenbasteln, Topic-Endpunkt (payload im Klartext, kein JSON), wie es in der verlinkten Anleitung steht: command.
Und nein, ich habe wenig Neigung, mir irgendeinen Shelly zu beschaffen, um sowas nicht nur per Theorie-Trockenübung durchzuexerzieren.
dachte, die ganzen bastelübungen hier machen wir, weil ich die devices hab, und ihr das wissen dazu.
lieg' ich da falsch?
weil ich kann keine kommandos zusammenbasteln. die info brauch ich dann schon von jemanden, ders weiß. ich lasse mich gerne "fernsteuern" von euch, aber mehr hab' ich halt nicht drauf.
fazit: ich wart jetzt amal darauf, das mir wer sagt, was ich wo eingeben soll, dann gibts infos, was dabei raus kommt.
auf sinnlos rumprobieren und dieses forum dann mit ergebnissen, die keiner braucht, voll zu müllen, hab ich nämlich auch keine lust.
Ohne mich selbst damit zu beschäftigen, hier die Essenz meines Agenten:
Was du brauchst, ist genau eine Kette: der Plug muss homeassistant/<component>/<object_id>/config in den Broker legen, dann greift MQTT2_Discovery von allein.
1. Im Shelly (Settings → MQTT)
Notiere dir den topic_prefix, brauchst du gleich zum Mitlesen.
Nichts weiter umstellen: enable_control, rpc_ntf und enable_rpc stehen ab Werk richtig. status_ntf (Generic status update over MQTT) schaltest du an, damit die State-Topics existieren, auf die die Discovery-Configs später zeigen.
2. Skript auf dem Gerät
Das ist der eigentliche fehlende Baustein, die Firmware bringt den Zweig nicht mit
(im Gen2+-Changelog kommt "Home Assistant" kein einziges Mal vor).
Abhilfe: das Skript michal-bartak/shelly-scripts (https://github.com/michal-bartak/shelly-scripts),
davon konkret mqtt-discovery-self. Im Shelly unter Scripts anlegen, starten,
Autostart an. Es publiziert beim Start, bei MQTT-Reconnect und bei Config-Aenderungen.
Wichtig vorher in den MQTT-Einstellungen des Shelly:
Generic status update over MQTT einschalten. Das Skript traegt als state_topic
<topic_prefix>/status/<component:id> ein - ohne diesen Schalter entstehen die Entities
zwar, bleiben aber dauerhaft leer.
Kontrolle, bevor du FHEM anfasst:
mosquitto_sub -h <ip_MQTT2_SERVER> -u <user> -P <pw> -t 'homeassistant/#' -v
Kommt hier nichts, ist alles Weitere sinnlos.
Retained sind die Discovery-Nachrichten uebrigens nicht (qos 1, retain=false).
Das ist hier aber unkritisch: Beim FHEM-Neustart geht der Broker mit, alle Shellys
verbinden neu, und das Skript schickt die Discovery automatisch erneut.
3. In FHEM
define mqttDiscovery MQTT2_DISCOVERY
attr mqttDiscovery IODev MQTT2_Server
Der Default discoveryPrefixes = homeassistant,tasmota/discovery,sonos2mqtt passt, da ist nichts zu setzen.
Stolpersteine
- autocreate im MQTT2_SERVER. Der legt dir aus den homeassistant/...-Topics womöglich selbst ein Müll-Device an, parallel zu dem, das MQTT2_Discovery baut. Vor Schritt 2 kurz schauen, ob autocreate am MQTT2_Server auf simple/complex steht, und ggf. die Discovery-Topics per ignoreRegexp ausnehmen.
- Erst testen, dann scharf schalten. autoDelete erst aktivieren, wenn die Erkennung sauber läuft.
- Der Plug S G3 steht nicht auf der getesteten Liste des Skripts. Wenn Schritt 2 nichts liefert, liegt es wahrscheinlich daran, und dann lohnt der ganze Weg für eine Steckdose nicht.
Ob sich der Aufwand rechnet, hängt daran, ob noch mehr Gen3-Geräte kommen. Für den einen Plug bleibt das attrTemplate die kürzere Strecke
Das sollte u.A. mit einem einfachen "publish" am io gehen - ganz ohne Script -Workaround...
Discovery ist nicht meine eigene Baustelle...
Hab mal selbst kurz in der Doku gesucht. Vlt. kein externes Script, aber ohne? Da steht noch ein Fragezeichen bei mir.
https://shelly-api-docs.shelly.cloud/gen2/Scripts/Overview
https://shelly-api-docs.shelly.cloud/gen2/Scripts/Overview#mqtt-and-home-assistant
Ohne Script. Die von mir verlinkte Doku meint:
export MQTT_SERVER="broker.hivemq.com"
export MQTT_PORT=1883
export SHELLY_ID="shellyplus1-a8032abe54dc" # The <shelly-id> of your device
mosquitto_pub -h ${MQTT_SERVER} -p ${MQTT_PORT} -t ${SHELLY_ID}/command -m status_updateDas in eine publish-Anweisung am fhem mqtt io umzusetzen ist doch keine überirdische Erwartung, oder?
Und was soll da deiner Meinung nach dann zurückkommen?
Ein discovery Zweig? Oder nur die Informationen um im MQTT2_Discovery Modul einen "Adapter" zu bauen.
Ich bleib dabei, es gibt default keinen discovery Zweig bei den Shellys.
Wegen Dir/euch hab ich jetzt den Mini Gen3 ausgekramt den ich vor ein paar Monaten gekauft und doch nicht zurückgegeben hatte.
set <MQTT2_SERVERNAME> publish shelly1minig3-e4b3231cf8a8/command status_update
shelly1minig3-e4b3231cf8a8/command status_update
shelly1minig3-e4b3231cf8a8/status {"ble":{},"bthome":{},"cloud":{"connected":false},"input:0":{"id":0,"state":null},"knx":{},"matter":{"num_fabrics":0,"commissionable":false},"mqtt":{"connected":true},"script:1":{"id":1,"running":true,"mem_used":1092,"mem_peak":2366,"mem_free":24094,"cpu":0},"switch:0":{"id":0,"source":"init","tag":null, "output":false,"counts":{"on_time":0,"on_time_rst_ts":0,"switch_on":0,"switch_on_rst_ts":0},"temperature":{"tC":58.5, "tF":137.4}},"sys":{"mac":"E4B3231CF8A8","restart_required":false,"time":"14:49","unixtime":1789303753,"last_sync_ts":1789302751,"uptime":4778,"ram_size":276136,"ram_free":148244,"ram_min_free":123776,"fs_size":917504,"fs_free":446464,"cfg_rev":68,"kvs_rev":0,"schedule_rev":0,"webhook_rev":0,"btrelay_rev":0,"bthc_rev":2,"available_updates":{"beta":{"version":"2.0.1-beta2"}},"reset_reason":3,"utc_offset":7200},"wifi":{"sta_ip":"192.168.188.238","status":"got ip","ssid":"bli","channel":6,"rssi":-61,"bssid":"x:ec:da:fd:26:x","sta_ip6":["fe80::e6b3:23ff:fe1c:x","2003:cd:1737:d800:e6b3:23ff:fe1c:x"]},"ws":{"connected":false}}
shelly1minig3-e4b3231cf8a8/status/ble {}
shelly1minig3-e4b3231cf8a8/status/bthome {}
shelly1minig3-e4b3231cf8a8/status/cloud {"connected":false}
shelly1minig3-e4b3231cf8a8/status/input:0 {"id":0,"state":null}
shelly1minig3-e4b3231cf8a8/status/knx {}
shelly1minig3-e4b3231cf8a8/status/matter {"num_fabrics":0,"commissionable":false}
shelly1minig3-e4b3231cf8a8/status/mqtt {"connected":true}
shelly1minig3-e4b3231cf8a8/status/script:1 {"id":1,"running":true,"mem_used":1092,"mem_peak":2366,"mem_free":24094,"cpu":0}
shelly1minig3-e4b3231cf8a8/status/switch:0 {"id":0,"source":"init","tag":null, "output":false,"counts":{"on_time":0,"on_time_rst_ts":0,"switch_on":0,"switch_on_rst_ts":0},"temperature":{"tC":58.5, "tF":137.4}}
shelly1minig3-e4b3231cf8a8/status/sys {"mac":"E4B3231CF8A8","restart_required":false,"time":"14:49","unixtime":1789303753,"last_sync_ts":1789302751,"uptime":4778,"ram_size":276020,"ram_free":145900,"ram_min_free":123776,"fs_size":917504,"fs_free":446464,"cfg_rev":68,"kvs_rev":0,"schedule_rev":0,"webhook_rev":0,"btrelay_rev":0,"bthc_rev":2,"available_updates":{"beta":{"version":"2.0.1-beta2"}},"reset_reason":3,"utc_offset":7200}
shelly1minig3-e4b3231cf8a8/status/wifi {"sta_ip":"192.168.188.238","status":"got ip","ssid":"bli","channel":6,"rssi":-61,"bssid":"x:ec:da:fd:26:x","sta_ip6":["fe80::e6b3:23ff:fe1c:x","2003:cd:1737:d800:e6b3:23ff:fe1c:x"]}
shelly1minig3-e4b3231cf8a8/status/ws {"connected":false}
nur damit ichs versteh: is das nicht so ungefähr das selbe wie der curl?
https://forum.fhem.de/index.php?topic=145402.msg1368914#msg1368914
shellies haben kein klassisches discovery, was man passiv aus dem mqtt broker bekommen kann. man muss das aktiv abfragen. das macht MQTT2_DISCOVERY schon. Shelly ist da neben Homeassistant, Sonos usw ein eigenes backend. In der nächsten Version sind auch die Blu Devices drin. Dann kann ratman testen...
Zitatnur damit ichs versteh: is das nicht so ungefähr das selbe wie der curl?
Nee.
Zitatcurl -X POST -d '{"id":1, "method":"Shelly.GetConfig"}' http://192.168.178.22/rpc
liefert Konfiguration
Zitatcurl -X POST -d '{"id":1,"method":"Shelly.GetStatus"}' http://192.168.178.22/rpc
liefert Status
Guck dir die Rückmeldungen bei mir an:
set <MQTT2_SERVERNAME> publish shelly1minig3-e4b3231cf8a8/rpc {"id":1,"src":"fhem","method":"Shelly.GetConfig"}shelly1minig3-e4b3231cf8a8/rpc {"id":1,"src":"fhem","method":"Shelly.GetConfig"}
fhem/rpc {"id":1,"src":"shelly1minig3-e4b3231cf8a8","dst":"fhem","result":{"ble":{"rpc":{"enable":false}},"bthome":{},"cloud":{"enable":false,"server":"iot.shelly.cloud:6012/jrpc"},"input:0":{"id":0,"name":null,"type":"button","enable":true,"invert":false,"factory_reset":true},"knx":{"enable":false,"ia":"15.15.255","routing":{"addr":"224.0.23.12:3671"}},"matter":{"enable":false},"mqtt":{"enable":true,"server":"192.168.188.26:1883","client_id":"shelly1minig3-e4b3231cf8a8","user":"bla","ssl_ca":null,"topic_prefix":"shelly1minig3-e4b3231cf8a8","rpc_ntf":true,"status_ntf":true,"use_client_cert":false,"enable_rpc":true,"enable_control":true},"script:1":{"id":1, "name":"script_1", "enable":false},"switch:0":{"id":0, "name":null,"in_mode":"detached","in_locked":false,"initial_state":"restore_last", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay":60.00,"counts":{"enable":true}},"sys":{"device":{"name":null,"mac":"E4B3231CF8A8","fw_id":"20260710-101122/2.0.0-g87fbfa4","discoverable":true,"eco_mode":false,"tls_check_cert_validity_time":true,"enhanced_security":false},"location":{"tz":"Europe/Berlin","lat":49.484100,"lon":8.374000},"debug":{"level":2,"file_level":null,"mqtt":{"enable":false},"websocket":{"enable":true},"file_log":{"enable":false},"udp":{"addr":null}},"ui_data":{"device_revision":"0-65"},"rpc_udp":{"dst_addr":null,"listen_port":null},"sntp":{"server":"time.cloudflare.com"},"cfg_rev":68},"wifi":{"ap":{"ssid":"Shelly1MiniG3-E4B3231CF8A8","is_open":false, "enable":false, "range_extender": {"enable":false}},"sta":{"ssid":"bli","is_open":false, "enable":true, "ipv4mode":"dhcp","ip":null,"netmask":null,"gw":null,"nameserver":null},"sta1":{"ssid":null,"is_open":true, "enable":false, "ipv4mode":"dhcp","ip":null,"netmask":null,"gw":null,"nameserver":null},"roam":{"rssi_thr":-80,"interval":60}},"ws":{"enable":false,"server":null,"ssl_ca":"ca.pem"}}}set <MQTT2_SERVERNAME> publish shelly1minig3-e4b3231cf8a8/rpc {"id":1,"src":"fhem","method":"Shelly.GetStatus"}shelly1minig3-e4b3231cf8a8/rpc {"id":1,"src":"fhem","method":"Shelly.GetStatus"}
fhem/rpc {"id":1,"src":"shelly1minig3-e4b3231cf8a8","dst":"fhem","result":{"ble":{},"bthome":{},"cloud":{"connected":false},"input:0":{"id":0,"state":null},"knx":{},"matter":{"num_fabrics":0,"commissionable":false},"mqtt":{"connected":true},"script:1":{"id":1,"running":true,"mem_used":1092,"mem_peak":2366,"mem_free":24094,"cpu":0},"switch:0":{"id":0,"source":"init","tag":null, "output":false,"counts":{"on_time":0,"on_time_rst_ts":0,"switch_on":0,"switch_on_rst_ts":0},"temperature":{"tC":58.4, "tF":137.1}},"sys":{"mac":"E4B3231CF8A8","restart_required":false,"time":"17:47","unixtime":1789314437,"last_sync_ts":1789313197,"uptime":15462,"ram_size":276124,"ram_free":147832,"ram_min_free":123372,"fs_size":917504,"fs_free":446464,"cfg_rev":68,"kvs_rev":0,"schedule_rev":0,"webhook_rev":0,"btrelay_rev":0,"bthc_rev":2,"available_updates":{"beta":{"version":"2.0.1-beta2"}},"reset_reason":3,"utc_offset":7200},"wifi":{"sta_ip":"192.168.188.238","status":"got ip","ssid":"bli","channel":6,"rssi":-64,"bssid":"x:ec:da:fd:26:x","sta_ip6":["fe80::e6b3:23ff:fe1c:x","2003:cd:1737:d800:e6b3:23ff:fe1c:x"]},"ws":{"connected":false}}}
Es hat unnötig viel Zeit verplempert, aber es hat mich heute gepackt mal wieder mit FHEM (und diesem Thema) zu beschäftigen, nachdem ich den Mini schon rausgeholt hatte.
Der input ist die Tage dran, für heute reichts mir:
define shelly1minig3_e4b3231cf8a8 MQTT2_DEVICE shelly1minig3_e4b3231cf8a8
attr shelly1minig3_e4b3231cf8a8 readingList shelly1minig3_e4b3231cf8a8:shelly1minig3-e4b3231cf8a8/online:.* { my %map=(true=>"online",false=>"offline");;return { lwt=>$map{$EVENT}||$EVENT } }\
shelly1minig3_e4b3231cf8a8:shelly1minig3-e4b3231cf8a8/status/input_0:.* { }\
shelly1minig3_e4b3231cf8a8:shelly1minig3-e4b3231cf8a8/status/switch_0:.* { my $ret=json2nameValue($EVENT, '', $JSONMAP, 'output');;my $value = delete $ret->{output};;$ret->{state} = $value eq 'true' ? 'on' : 'off';; return $ret;;}\
shelly1minig3_e4b3231cf8a8:shelly1minig3-e4b3231cf8a8/status/(ble|bthome|cloud|knx|matter|ws|sys|wifi|mqtt):.* {}
attr shelly1minig3_e4b3231cf8a8 room MQTT2_DEVICE
attr shelly1minig3_e4b3231cf8a8 setList on:noArg shelly1minig3-e4b3231cf8a8/command/switch:0 on\
off:noArg shelly1minig3-e4b3231cf8a8/command/switch:0 off\
toggle:noArg shelly1minig3-e4b3231cf8a8/command/switch:0 toggle
# CFGFN
# CID shelly1minig3_e4b3231cf8a8
# DEF shelly1minig3_e4b3231cf8a8
# FUUID 6aa6dc2b-f33f-c86b-28ac-560fde13b034937b
# IODev MQTT2_Server
# LASTInputDev MQTT2_Server
# MQTT2_Server_CONN MQTT2_Server_192.168.188.238_51700
# MQTT2_Server_MSGCNT 338
# MQTT2_Server_TIME 2026-09-13 21:47:00
# MSGCNT 338
# NAME shelly1minig3_e4b3231cf8a8
# NR 838
# STATE off
# TYPE MQTT2_DEVICE
# eventCount 229
# .DT:
# DEVICETOPIC shelly1minig3_e4b3231cf8a8
# .attraggr:
# .attrminint:
# OLDREADINGS:
# READINGS:
# 2026-09-13 21:14:36 lwt online
# 2026-09-13 21:47:00 state off
#
setstate shelly1minig3_e4b3231cf8a8 off
setstate shelly1minig3_e4b3231cf8a8 2026-09-13 21:14:36 lwt online
setstate shelly1minig3_e4b3231cf8a8 2026-09-13 21:47:00 state off
Ekelhaft ist weiterhin dieses minütliche update des "switch_0" Zweig.
Weiß wer wie man das unterbinden kann?
Verrückt, das ich nach so langer Zeit heute erst verstanden habe was die CID in der DEF bewirkt.
Auslöser war, das ich mir über die Definition (https://forum.fhem.de/index.php?msg=1347295) nochmal Gedanken gemacht hatte, weil ich nicht verstand, warum dort keine Topics ignoriert werden müssen und nicht automatisch angelegt werden.
Die in dem Link gezeigte Einstellung Generic status update over MQTT ist übrigens verantwortlich für das minütliche update, dem unnötigen .../status/switch_0 Zweig und braucht man gar nicht.
Mein gezeigter ReadingList Eintrag zum Topic .../status/switch_0 ist Käse, wenn man verstanden hat, das der Status über den .../command/switch_0 Zweig kommt.
Der Status des input wird im detached Mode auch mit 20260710-101122/2.0.0-g87fbfa4 nicht übertragen, was mir wichtig gewesen wäre.
defmod shelly1minig3_e4b3231cf8a8 MQTT2_DEVICE
attr shelly1minig3_e4b3231cf8a8 IODev MQTT2_Server
attr shelly1minig3_e4b3231cf8a8 readingList shelly1minig3_e4b3231cf8a8:shelly1minig3-e4b3231cf8a8/online:.* { my %map=(true=>"online",false=>"offline");;return { lwt=>$map{$EVENT}||$EVENT } }\
shelly1minig3-e4b3231cf8a8/command/switch_0.(on|off) state
attr shelly1minig3_e4b3231cf8a8 room MQTT2_DEVICE
attr shelly1minig3_e4b3231cf8a8 setList on:noArg shelly1minig3-e4b3231cf8a8/command/switch:0 on\
off:noArg shelly1minig3-e4b3231cf8a8/command/switch:0 off
setstate shelly1minig3_e4b3231cf8a8 on
setstate shelly1minig3_e4b3231cf8a8 2026-09-14 14:04:35 lwt online
setstate shelly1minig3_e4b3231cf8a8 2026-09-14 14:10:14 state on
ZitatDie in dem Link gezeigte Einstellung Generic status update over MQTT ist übrigens verantwortlich für das minütliche update, dem unnötigen .../status/switch_0 Zweig und braucht man gar nicht.
Mein gezeigter ReadingList Eintrag zum Topic .../status/switch_0 ist Käse, wenn man verstanden hat, das der Status über den .../command/switch_0 Zweig kommt.
Falsch. Die in dem Link gezeigte ReadingList ist Käse, dort wird der Kommando Zweig ausgewertet, also das was aus FHEM geschickt wird.
Man braucht schon
Generic status update over MQTT, nur dort steht drin was vom Shelly zurückkommt.
Mein gezeigter ReadingList Eintrag mit .../status/switch_0 war schon richtig:
defmod shelly1minig3_e4b3231cf8a8 MQTT2_DEVICE
attr shelly1minig3_e4b3231cf8a8 IODev MQTT2_Server
attr shelly1minig3_e4b3231cf8a8 readingList shelly1minig3_e4b3231cf8a8:shelly1minig3-e4b3231cf8a8/online:.* { my %map=(true=>"online",false=>"offline");;return { lwt=>$map{$EVENT}||$EVENT } }\
shelly1minig3-e4b3231cf8a8/status/switch_0:.* { my $ret=json2nameValue($EVENT, '', $JSONMAP, 'output');;my $value = delete $ret->{output};;$ret->{state} = $value eq 'true' ? 'on' : 'off';; return $ret;;}
attr shelly1minig3_e4b3231cf8a8 room MQTT2_DEVICE
attr shelly1minig3_e4b3231cf8a8 setList on:noArg shelly1minig3-e4b3231cf8a8/command/switch:0 on\
off:noArg shelly1minig3-e4b3231cf8a8/command/switch:0 off
setstate shelly1minig3_e4b3231cf8a8 off
setstate shelly1minig3_e4b3231cf8a8 2026-09-14 14:29:04 lwt online
setstate shelly1minig3_e4b3231cf8a8 2026-09-14 14:37:34 state off
ich hab den shelly blu support und erweiterung der shelly befehle nun in dev eingecheckt. du kannst das jetzt updaten und gerne testen
ich hab mal upgedatet, ohne grad viel zeit zu haben. rennen tut mal alles, fehler gabs beim restart von fhem:
2026.09.15 10:03:26 1: PERL WARNING: Prototype mismatch: sub main::decode_json ($) vs none at /usr/lib/x86_64-linux-gnu/perl-base/Exporter.pm line 63, <$fh> line 2808.
diese fehler kommt jetzt übrigens nach jedem restart von fhem.
mein bekannter meint dazu, das in 3 modulen von fhem 3 verschiedene json module verwendet werden, aber alle 3 die gleiche funktion "decode_json" aufrufen.
er meint, das wird nicht lange gut gehen ...
Zu decode_json() ein paar Anmerkungen (ohne den Code dieses Moduls angesehen zu haben):
- es unterstellt impliziert utf8. Gut, wenn sich der json auch an die spec hält. Tut er nur manchmal nicht. Imo sollte man besser json->new->decode() verwenden.
- einpacken in ein block eval ist ein muss, falls noch nicht implementiert.
Insgesamt wäre zu überlegen, ob man das ganze nicht in ein package überführt.
Und wie manche Module versuchen, bestimmte json-libs in main zu ziehen, wäre allgemein überdenkenswert.
danke für den hinweis. das ist noch ein altes relikt, was ich scheinbar aus tippfaulheit verwendet hab. ist in der neuen dev version korrigiert.
flott ...
2026.09.15 11:52:17 1: update finished, "shutdown restart" is needed to activate the changes.
2026.09.15 11:52:21 0: Server shutdown
2026.09.15 11:52:22 1: Including fhem.cfg
2026.09.15 11:52:23 1: Including ./log/fhem.save
2026.09.15 11:52:26 0: Featurelevel: 6.4
2026.09.15 11:52:26 0: Server started with 158 defined entities (fhem.pl:31607/2026-08-29 perl:5.040001 os:linux user:fhem pid:1630)fhem spricht wieder fehlerfrei - thx
wenn ich mal direkt an der anlage bin, dann schalt ich dein modul wieder ein und schau, was so passiert ...
also ein 2. mal ... weil den ersten beitrag hat mir das forum nicht schreiben wollen:
neue birne einbinden wollen. ergebnis:
ein 2. mqtt server, eine nicht funzende neue birne, eine verschwunden alte birne.
backup fhem.cfg zurück, alles geht wieder zum glück.
was muss ich nun bitte genau tun, waas muß ich abschalten, einschalten, tun oder lassen, damit meine neue birne mit ct und pct geht, und alles alte in ruhe gelassen wird?
die mqttdiscovery versuche ich im anschluß einzutragen, bevor wieder alles verschwindet
auch das (Copy for forum.fhem.de) geht leider nicht wegen forumsrestriktionen
dann zumindest folgende conflicts:
bthomedevice_200_event,bthomedevice_200_idx,bthomedevice_200_channel,bthomedevice_200_ts,bthomedevice_201_event,bthomedevice_201_idx,bthomedevice_201_channel,bthomedevice_201_ts,bthomedevice_202_event,bthomedevice_202_idx,bthomedevice_202_channel,bthomedevice_202_ts,bthomedevice_203_event,bthomedevice_203_idx,bthomedevice_203_channel,bthomedevice_203_ts,bthomedevice_204_event,bthomedevice_204_idx,bthomedevice_204_channel,bthomedevice_204_ts,bthomesensor_200_event,bthomesensor_200_idx,bthomesensor_200_channel,bthomesensor_200_ts,bthomesensor_201_event,bthomesensor_201_idx,bthomesensor_201_channel,bthomesensor_201_ts,bthomesensor_202_event,bthomesensor_202_idx,bthomesensor_202_channel,bthomesensor_202_ts,bthomesensor_203_event,bthomesensor_203_idx,bthomesensor_203_channel,bthomesensor_203_ts,bthomesensor_204_event,bthomesensor_204_idx,bthomesensor_204_channel,bthomesensor_204_ts,bthomesensor_205_event,bthomesensor_205_idx,bthomesensor_205_channel,bthomesensor_205_ts,bthomesensor_206_event,bthomesensor_206_idx,bthomesensor_206_channel,bthomesensor_206_ts,bthomesensor_207_event,bthomesensor_207_idx,bthomesensor_207_channel,bthomesensor_207_ts,bthomesensor_208_event,bthomesensor_208_idx,bthomesensor_208_channel,bthomesensor_208_ts,bthomesensor_209_event,bthomesensor_209_idx,bthomesensor_209_channel,bthomesensor_209_ts,bthomesensor_210_event,bthomesensor_210_idx,bthomesensor_210_channel,bthomesensor_210_ts,bthomesensor_211_event,bthomesensor_211_idx,bthomesensor_211_channel,bthomesensor_211_ts,sys_uptime,wifi_rssiund lastWarningTopic
mqtt2_discovery/mqttDiscovery/shelly/8cb4fef0195f727a/status/rpc
gut, das ganze halt zip gepackt, vielleicht hilfts ja:
Ich bin gerade unterwegs, aber soviel vorab- wenn MQTT2_DISCOVERY aktiviert ist musst du garnichts weiter machen außer dein neues Gerät anzuschalten und dort die ip deines MQTT Servers einzutragen. Der steht sollte automatisch dann passieren
mehr hab ich auch ned getan.
btw ... alle blu-geräte in allen devices hab nun doppelte readings. doppelt batterie, doppelt alles.
ich mach nun folgendes, nachdem ich mir hier nochmal ein bissi sicherheit hole.
ich werd alles zu shelly löschen. ausgenommen meinen mqtt2 server und dein discoverymodul.
dazu würde ich gerne die einstellungen zu den beiden modulen wissen, um am ende meine devices + blu zu erhalten und was zu tun ist, um schalter, pct, ct, ... zu erhalten.
und, was ich bei neuen, zusätzlichen devices und /oder blu geräten zu tun habe.
und ja. wirds dein modul dann über fhem, oder immer nur von nem fremden server geben? weil dann wart ich das ab, bevor dann wieder was nicht passt.
dann haben ma wenigstens eine grundlage.
nachtrag:
seh ich das richtig im anderen beitrag, dass es eventuell intelligenter wäre, ich warte gleich, bis ihr eure "utils" soweit fertig habts, bevor ich dann wieder probleme krieg, bei einem eventuellen umstieg?
Die Diskussion zu den Utils ist losgelöst von Discovery. Das ist keine Voraussetzung von Discovery. Wegen Discovery musst du ansich nur deinen MQTT2_SERVER und MQTT2_DISCOVERY laufen haben. Rein vorsorglich würde ich die config sichern, damit du wieder zurückkehren kannst. Wenn du deine devices gelöscht hast, dann speichere die config und restarte am besten einmal fhem. Das genügt. Doppelte Devices darf es jedenfalls nicht geben. Da müssen sich identifier geändert haben, dass das quasi wie ein neues Gerät erscheint. Anders kann ich mir das gerade nicht erklären.
doppelte devices gabs ja nicht. nur für jedes blu gerät je 2 leicht unterschiedliche readings, obwohl dein modul konservativ eingestellt war.
und eben eine von deinem modul vollständig neue bulb (fhem hatte ich die vorher noch nie gezeigt), die nix schalten konnte. kein on/off, kein pct, kein ct.
nur zur sicherheit:
beim server stell ich autocreate auf "no"
Zitat von: the ratman am 25 September 2026, 22:25:07nur zur sicherheit:
beim server stell ich autocreate auf "no"
unbedingt. sonst hast du überall den datenmüll drin, den autocreate erzeugt. wenn man autocreate nutzt, braucht man vernünftige regexfilter um das zu verhindern. das ist aber total unnötig und sogar kontraproduktiv wenn man MQTT2_DISCOVERY nutzt
damits mal was positives gibt *g* ...
heute mal testweise ein paar devices probiert.
lernerfolg:
wenn mans device vorher löscht, ist das alles kein problem mehr. ich werd also in zukunft auf "ergänzende aktualisierungen" verzichten, und gleich bei 0 anfangen.
bisher getestet:
1) eine shelly bulb duo ohne blu-zeugs ... läuft vollständig
2) eine 4-fach-steckdose mit 2 x blu h&t, 1 x blu fenstersensor, 2 x blu 4-fach taster ... ebenfalls problemlos.
somit: schaun ma mal, ist noch viel zu tun ... aber derzeit durchaus glücklich bin *g*
ein bissi motzen muss auch sein ...
den bulbs würde ein dimUp xx, dimDown xx und toggle ganz gut tun
und wenn i nomal nerven darf ... sowohl für die lampen als auch steckdosen wäre natürlich ein "on-for-timer" und ähnliches auch super.
ansonsten bin ich sehr glücklich ... alles rennt, alles is übersichtlicher ... passt!
also danke fürs modul! ist genau das richtige für programmiertechnische nulpen wie mich.
@Guybrush
kannst du mir ne ganz kurze info liefern, wegen "toggle, on-for-timer, ..."? ein "ja/nein, mach ich (nicht)" würd' schon reichen.
solltest du da nix machen wollen/können, könnte ich mir andere lösungen überlegen.
wieder mal ne frage @Guybrush ... ja, die übliche obere, wäre immer noch interessant, aber ich frage mich grade, ob ich auch das richtige discovery in fhem lade.
du hast mir ja folgenden link damals gegeben:
https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
in deinem github scheint aber der main-zweig empfohlen zu werden:
https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/main/controls_MQTT2_DISCOVERY.txt
was ist den nun wirklich relevant?