Hallo zusammen,
ich habe heute erfolgreich 4 Gosund SP112 Steckdosen mit Tasmota geflashed und den MQTT Teil in FHEM eingerichtet.
Über ein Device "Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.socket" kann ich soweit auch problemlos die Steckdose Ein- und Ausschalten. Jetzt würde ich gerne die USB-Ports, die auch schaltbar sind, separat steuern wollen (auch damit ich die noch via Alexa verfügbar machen kann).
Soweit habe ich den Weg gewählt, ein Dummy Device einzurichten und habe mal zusammenkopiert, was ich so gefunden habe:
define Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.usb dummy
attr Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.usb readingList Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.socket
attr Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.usb webCmd on:off
attr Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.usb setList on Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.socket:cmnd/TASMOTA_xxxxxx_fb/POWER2 on\
off Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.socket:cmnd/TASMOTA_xxxxxx_fb/POWER2 off
attr Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.usb devStateIcon ON:ios-on-green:off OFF:ios-off:on
Funktionieren tut das aktuell nicht. Was mach ich denn hier falsch?
Dummy.... (Ist nicht optimal).
Nimm lieber ein 2. MQTT(2)-Device oder readingsProxy. 2. device ist m.E. die beste Variante.
Oder auch: ein Befehl aus der dummy setList loest nichts aus, insb. sendet es keine MQTT Nachricht.
Die Punkte im NAME sind auch nicht optimal (auch wenn man sie nutzen darf, nur nicht an erster Stelle), irgendwann wird das hinderlich sein in Perl (FHEM).
Gruß
Thomas
Zitat von: Beta-User am 02 Januar 2020, 16:14:09
Dummy.... (Ist nicht optimal).
Nimm lieber ein 2. MQTT(2)-Device oder readingsProxy. 2. device ist m.E. die beste Variante.
Ich habe das so funktionierend umgesetzt bekommen:
defmod test1 readingsProxy Wohnung3.Unzugeordnet.Device.Tasmota.xxxxxx.socket:POWER2
attr test1 setFn {fhem ("set mqttBroker publish cmnd/TASMOTA_xxxxxx_fb/POWER2 $CMD");;}
attr test1 webCmd on:off
attr test1 setList on off
attr test1 valueFn {lc($VALUE)}
attr test1 icon message_socket
attr test1 devStateIcon on:ios-on-green:off off:ios-off:on
Ist das so gut oder geht das eleganter/besser?
Zitat von: TomLee am 02 Januar 2020, 16:47:55
Die Punkte im NAME sind auch nicht optimal (auch wenn man sie nutzen darf, nur nicht an erster Stelle), irgendwann wird das hinderlich sein in Perl (FHEM).
Historisch gewachsen habe ich den Syntax bei fast allen Geräten usw. so verwendet. Ja, wegen RegEx könnte das vielleicht unerwartet mal krachen. Gibt es einen einfachen Weg, das umzustellen? Der Aufbau der Gerätenamen ist eigentlich immer im gleichen Muster, von daher könnte ich mit Suchen & Ersetzen das umstellen in der Konfig, wenn es da keine Knackpunkte gibt.
Kommt drauf an, welche MQTT-Implementierug Du nutzt. Mit MQTT2_DEVICE ginge es eleganter... Mit expandJSON o. Tasmota_device eher nicht.
Zitat von: Beta-User am 02 Januar 2020, 18:48:44
Kommt drauf an, welche MQTT-Implementierug Du nutzt. Mit MQTT2_DEVICE ginge es eleganter... Mit expandJSON o. Tasmota_device eher nicht.
Habe die FHEM eigene Implementierung (die du vermutlich meinst?) verwendet. Wie würde denn der elegantere Weg aussehen? Also es funktioniert ja schon wie es ist, aber lerne gerne dazu :)
Es gibt 2 FHEM-eigene, deswegen frage ich...TYPE vom IO-Modul?
Zitat von: Beta-User am 02 Januar 2020, 20:24:13
Es gibt 2 FHEM-eigene, deswegen frage ich...TYPE vom IO-Modul?
Das wäre MQTT2_SERVER
ZitatJetzt würde ich gerne die USB-Ports, die auch schaltbar sind, separat steuern wollen (auch damit ich die noch via Alexa verfügbar machen kann).
Jetzt lese und ich verstehe das erst, sind die Ports jeder einzeln schaltbar oder ist der Gosund praktisch ein 2-Fach-Aktor der mit POWER2 praktisch das Netzteil schaltet oder gibts noch ein POWER3 um den zweiten Port zu schalten.
Egal wie, so was such ich als UP-Variante, passend zu verwendeten Schalterserie ;D
Gruß
Thomas
Zitat von: TomLee am 02 Januar 2020, 21:36:22
Jetzt lese und ich verstehe das erst, sind die Ports jeder einzeln schaltbar oder ist der Gosund praktisch ein 2-Fach-Aktor der mit POWER2 praktisch das Netzteil schaltet oder gibts noch ein POWER3 um den zweiten Port zu schalten.
Egal wie, so was such ich als UP-Variante, passend zu verwendeten Schalterserie ;D
Die USB-Ports und Steckdose lassen sich jeweils einzeln schalten (wobei die USB-Ports nur zusammen). Der gemessene Strom ist jeweils die Summe von USB-Ports (POWER2) und Steckdose (POWER1), man kann also z.B. nicht ermitteln, wie der Verbrauch an einem USB-Port ist während an der Steckdose etwas angeschlossen ist.
Um nur die Ports zu schalten, find ich die ReadingsProxy-Lösung dann sehr elegant, wozu brauch ich hier dann die ganzen anderen Readings. :P
Dafür sollte es sogar ein attrTemplate geben, es gab nur im Ausgamgsthread dazu keine Rückmeldung, ob das tut was es soll...Also: bitte suchen und testen :D .
Zitat von: TomLee am 02 Januar 2020, 21:46:47
Um nur die Ports zu schalten, find ich die ReadingsProxy-Lösung dann sehr elegant, wozu brauch ich hier dann die ganzen anderen Readings. :P
Thx. auch nochmal für den Hinweis; tendenziell hast du recht, man sollte die den weiteren Kanälen subscribierten Topics begrenzen, RESULT sollte reichen, oder?
Und dann mit jsonMap auch noch die unnötigen Readings aus dieser json-Quelle rausflitern, die man für den jeweiligen Kanal nicht braucht ;) .
Werde mir das in Richtung json-Mapping überarbeitete template-file (https://forum.fhem.de/index.php/topic,94494.msg1006836.html#msg1006836) vor dem Schubsen ins svn nochmal dahingehend ansehen...
Du bist ja schon wieder bei MQTT2_Device. Elegant ist das readingsProxy, kurz und knapp, in jeder Hinsicht.
Mit MQTT2_Device erstmal wieder alles verstecken ist doch dagegen -auch wenn man nur ein Template anwendet- ein riesen Aufwand, mehr Code, für das gleiche Ergebnis.
Gruß
Thomas
Aber dann hat man auch nur die relevanten Events... :) Direkt im richtigen Modul, wenn auch mit etwas mehr code (vielleicht...?). ReadingsProxy ist an sich OK, hat aber auch ein paar Ecken und Kanten, was die weitere Event-Verarbeitung anging.
Bin nicht soo tief da drin, kann also auch falsch sein...