shelly duo bulb gen3 über mqtt schalten

[the ratman]

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 ...

[TomLee]

Selbst mit Rechtschreibfehlern in den Suchwörtern zeigt mir die KI Übersicht bei Google die Antwort auf deine Frage:

diycovery request mqtt shell gen4

[Guybrush]

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

[Guybrush]

Selbst mit Rechtschreibfehlern in den Suchwörtern zeigt mir die KI Übersicht bei Google die Antwort auf deine Frage:

diycovery request mqtt shell gen4

Code Auswählen Erweitern

update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
update
save
shutdown restart

nach neustart:

Code Auswählen Erweitern

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..)

[the ratman]

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 ...

Code Auswählen Erweitern

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}}

[the ratman]

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?

Code Auswählen Erweitern

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

[Guybrush]

templates sind nichts anderes als vorkonfiguierte topic/list verknüpfungen. Nimm MQTT2_DISCOVERY .. mach dir doch das Leben nicht so schwer

[the ratman]

@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 ...

[Guybrush]

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

[the ratman]

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 ...

Code Auswählen Erweitern

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 ...

[Guybrush]

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!

 

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)

[the ratman]

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.

[Guybrush]

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.