Hallo zusammen!
Vorab: Dieser Thread betrifft (bislang) ausschließlich MQTT2_DEVICE, nicht MQTT_DEVICE. Beachte dazu z.B. diesen Wiki-Beitrag (https://wiki.fhem.de/wiki/MQTT#MQTT2).
Bitte nutzt möglichst diesen Thread, wenn ihr neue (im Prinzip ausentwickelte) templates für mqtt2.template vorschlagen wollt.
Für Fehlermeldungen, Diskussionen zu Verbesserungsvorschlägen zu vorhandenen und zum Anfragen von support für neue Devices ist ein weiterer Thread (https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200) gedacht, dieser hier sollte möglichst übersichtlich bleiben und sich auf das Wesentliche beschränken.
Generelle Anmerkungen zur attrTemplate-Funktion bitte hier (https://forum.fhem.de/index.php/topic,93370.msg860045.html#msg860045) posten.
Folgende Wünsche hätte ich:
Parameter verwenden
Ein template unterscheidet sich von einem list insbesondere dadurch, dass es ggf. benötigte Parameter aus den vorhandenen Informationen extrahiert, so dass es nicht nur auf ein konkretes Gerät (z.B. mit einer Seriennummer) paßt, sondern auf - prinzipiell - alle Geräte eines Typs oder sogar mehrerer Typen.
Wer Hilfestellung braucht, um aus einem konkret konfigurierten Gerät (=list) ein template zu machen: Es ist ok, hier einen Link auf den Beitrag mit dem list oder einen neuen Thread zu posten und um Hilfe zu bitten. Danach sollte sich hier aber wieder nur das Ergebnis finden.
Schaut euch die vorhandenen templates an, da ist schon einiges an Beispielen zu finden, auch wie man mehrere Parameter rausfindet, v.a. bei mqtt2zigbee (BASE_TOPIC und DEV_ID) und MiLight.
Eine Sonderform der Parametrierung ist die interne Weiterleitung auf bereits vorhandenen templates: Wenn es "nur" darum geht, ein bestimmtes Gerät anders oder erweitert zu konfigurieren, als ein bereits vorhandenes, kann man erst das vorhandene anwenden und dann einfach (nur) die abweichenden Attribute etc. setzen. Beispiel: A_10a_shellyplug. Dabei gilt die Regel, dass die letzte attr-Anweisung für ein bestimmtes Attribut sich am Ende tatsächlich auch im Device wiederfindet.
Defaults in der MQTT-Konfiguration der Geräte nutzen
Bitte laßt die MQTT-Einstellungen möglichst dort unverändert, wo sie sich auf den Empfang und die Auswertung in FHEM auswirken. Das betrifft z.B. den Namen des Geräts in den topics oder den Aufbau der topic-Struktur. Danach kann und darf man alles ändern, aber erst mal sollte es für andere in derselben Ausgangslage klappen!
Das gilt entsprechend für Modifikationen der firmware selbst.
Beschreibung hinzufügen
Andere freuen sich darüber, wenn ihr schreibt, für welches Gerät ihr das konkret verwendet habt und was der Zweck ist. Das muß im template einzeilig sein, längere Beschreibungen lassen sich mit "<br>" dann in der "?"-Ansicht formatieren.
Testen
Ein template kann man am z.B. testen, indem man in eine eigene template-file (idR. in /opt/fhem/FHEM/lib/AttrTemplate) anlegt (Endung: .template, Linux-konforme Zeilenumbrüche). Dann nach jeder Änderung mit "{ AttrTemplate_Initialize() }" neu einlesen, was voraussetzt, dass der user fhem die Rechte hat, die Datei auch zu lesen.
Vorschläge möglichst als diff
Ist alles fertig, könnt ihr eine Kopie der vorhandenen mqtt2.template-Datei anlegen, und euer template in die bisherige einfügen. Ein diff -u <original> <eure Kopie> > ~/mqtt2.template.<hinweis>.patch ausführen, dann liegt im home-Verzeichnis eures users die neue Datei, die ihr nach Durchsicht dann hier anfügen könnt.
Wäre dabei schön, wenn gleich eine sinnvolle Einordnung in das Nummernsystem drin wäre.
(EDIT: Die Sortierung erfolgt neurdings über "order:", nicht mehr über den template-Namen)
Der erste Buchstabe steht für eine Hauptgruppe.
- A ist reserviert für ESP-Derivate (aktuell Shelly und Tasmota),
- B-M für Kaufgeräte, die nativ MQTT sprechen
- L-Z für eher seltene Geräte oder auch ESP-firmwares, z.B. X90_esp_milight_hub_bridge
Die zweite Angabe wäre dann ein bestimmter Grundtyp ggf. mit einer oder mehreren Varianten. Orientiert euch einfach an dem, was da ist und macht einen Vorschlag.
Aber selbstredend ist es auch ok, wenn ihr nur eine Datei liefert, die ausschließlich euer Device enthält.
Viel Spaß beim Entwickeln und Anwenden!
Beta-User
EDIT:
links zu diversen template-Threads
- zigbee2mqtt: https://forum.fhem.de/index.php/topic,91394.0.html (https://forum.fhem.de/index.php/topic,91394.0.html)
- tasmota: https://forum.fhem.de/index.php/topic,94434.0.html (https://forum.fhem.de/index.php/topic,94434.0.html)
- tasmota-shutter: https://forum.fhem.de/index.php/topic,98366.0.html (https://forum.fhem.de/index.php/topic,98366.0.html)
- shelly: https://forum.fhem.de/index.php/topic,94060.0.html (https://forum.fhem.de/index.php/topic,94060.0.html)
- eBus: https://forum.fhem.de/index.php/topic,97989.0.html (https://forum.fhem.de/index.php/topic,97989.0.html)
- MiLight@sidoh-Bridge: https://forum.fhem.de/index.php/topic,86932.0.html (https://forum.fhem.de/index.php/topic,86932.0.html)
Nochmal der Link zum Bugs und Anregungen-Thread (https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200).
Hallo zusammen
für den Shelly2 als Rolladen Schalter habe ich dieses Template erzeugt
# shelly2 using original firmware.
name:A_11b_shelly2_roller
filter:TYPE=MQTT2_DEVICE
desc:shelly2 using original firmware. <br>NOTE: shelly2 roller operated
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE comment shelly2 roller operated
attr DEVICE setList \
open:noArg shellies/DEVNAME/roller/0/command open\
close:noArg shellies/DEVNAME/roller/0/command close\
stop:noArg shellies/DEVNAME/roller/0/command stop\
pos:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1
attr DEVICE readingList shellies/DEVNAME/roller/0/pos:.* state\
shellies/DEVNAME/status/0/rollers:.* power
attr DEVICE devStateIcon 0:fts_shutter_100@green 100:fts_shutter_10@white 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
attr DEVICE model A_11b_shelly2
Bin mir aber nicht sicher bei dem Namen den ich ausgesucht habe und ob das attr für devStateIcon reinkommen darf.
Gleichzeitig habe ich einen Slider eingerichtet für die Position des Rollos in Prozent, weiß nicht ob das nötig ist, ich find es ganz praktisch.
Hoffe das auch sonst alles richtig ist, bei meinen shellys ist jedenfalls okay so.
Grüße
Torte
Danke, hab's eingecheckt!
Anmerkungen:
- Den Namen fand ich ok. Dieser sollte halt aussagefähig sein und sich irgendwie sinnvoll ins Umfeld einfügen. Allerdings sollte "model" dem Namen entsprechen: damit soll es leichter sein festzustellen, welches template angewandt wurde, falls jemand mal Probleme hat.
- Das devStateIcon ist im Prinzip auch völlig ok, allerdings macht eine Farbgebung je nach gewähltem Hintergrund mal mehr, mal weniger Freude (so jedenfalls mein bisheriger Eindruck); die Farbangaben habe ich daher rausgemacht, lasse mich da aber gerne auch vom Gegenteil überzeugen.
- die Descr. darf gerne auch kurze Hinweise zum "doing" enthalten. Ich habe jetzt mal präventiv einen kurzen Hinweis eingebaut, dass (irgendwelche ?) settings zuerst anzupassen seien. Bitte um Rückmeldung, ob dem so ist bzw. wie/wo man dazu eingreifen sollte (wenn es nicht "selbsterklärend" ist).
@torte:
Habe eben noch ein paar kleine Änderungen vorgenommen, die m.E. zur besseren Kompabilität mit AutoShuttersControl zweckmäßig sind. Für den Fall, dass du das auch nutzt, wäre es nett, du würdest dir das kurz ansehen. Weitere Diskussion dann ggf. separat bzw. im "Anregungen..."-Thread.
Hallo,
ich hätte ein Template für die Xiaomi Zigbee Tür/Fenster Sensoren. getestet mit den Aquara und den Mijia Sensoren. Solange das reading "contact" ist müssten aber auch Sensoren von anderen Herstellern funktionieren
name:L_06_zigbee2mqtt_XiaomiContactSensor
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/](.*):, ? $1 : undef }
attr DEVICE stateFormat contact
attr DEVICE devStateIcon open:fts_window_1w_open@red close:fts_window_1w@green
attr DEVICE genericDeviceType contact
attr DEVICE eventMap true:close false:open
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
attr DEVICE model L_06_zigbee2mqtt_XiaomiContactSensor
Viel Spass damit
@luke666s: Danke, hab's mit kleinen Änderungen eingecheckt:
- Xiaomi raus, ich gehe auch davon aus, dass die Abstraktion bereits auf der zigbee2mqtt-Ebene erfolgt und daher auch andere Hersteller/Modelle passen würden=> findet sich jetzt in der desc, mit welchen Modellen getestet- genricDeviceType ist homekit-spezifisch und würde bei Leuten (wie mir), die das nicht haben zu Fehlern führen (ich sollte das wohl in den ersten Beitrag als Hinweis aufnehmen...).
hier noch der Xiaomi Aquara Temp/Hum/Hpa sensor... ich hoffe mal der ist generisch, von den Readings sieht es gut aus.... das Template ist es auf jeden Fall :)
name:L_07_zigbee2mqtt_TempHumHpaSensor
desc: Temp/hum/hpa sensor via zigbee2mqtt <br>Tested with: Xiaomi Aquara WSDCGQ11LM Temperature Humidity Sensor
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/](.*):, ? $1 : undef }
attr DEVICE stateFormat {sprintf ("Temperature: %.1f°C Humidity: %.1f%% Pressure: %.1fhpa", ReadingsVal($name,"temperature",0), ReadingsVal($name,"humidity",0), ReadingsVal($name,"pressure",0)) }
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
attr DEVICE model L_07_TempHumHpa_TempSensor
cheers
....und eingecheckt, Danke!
Hallo,
kann es sein, das das Template L_01_zigbee2mqtt_bridge einen Fehler hat.
z.b. folgende Zeile
zigbee2mqtt/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
Ich frage deshalb weil nach dem
igbee2mqtt/bridge/log:.*\ im Editor fhem.cfg oder beim editieren von attr readinglist, alles in grün angezeigt wird.
Gruß Werner
Da die Einträge in der readingList wie gewünscht ihren Dienst verrichten, vermute ich, dass es "lediglich" Interpretationsprobleme mit den maskierten Hochkommata im Editor gibt.
Vorab @Intruder1956: das ist m.E. der falsche Ort für diese Frage!
Zitat von: Beta-User am 15 Dezember 2018, 11:45:40
Für Fehlermeldungen, Diskussionen zu Verbesserungsvorschlägen zu vorhandenen ist ein weiterer Thread (https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200) gedacht, dieser hier sollte möglichst übersichtlich bleiben und sich auf das Wesentliche beschränken.
Und da es bei deiner Frage auch "nur" darum geht, dass ein _verändertes_ Attribut irgendwie im Editor "komisch" aussieht, ist es eigentlich m.E. gar keine Frage zu den templates, sondern gehört in einen separaten Thread.
Wen es interessiert: Die templates bearbeite ich vor dem Hochladen ins svn ausschließlich mit Kate unter einem Linux-System, fürs Testen kopiere ich das meistens blockweise auf der Konsole auf meinen FHEM-Server, das ganze mit ssh und mc als Editor.... Wer da Verbesserungsvorschläge hat, darf die gerne in dem anderen Thread loswerden.
soll ich es hier löschen ??
hab hier noch ne Kleinigkeit....
name:L_08_zigbee2mqtt_Human_Motion_Sensor
desc: Temp/hum/hpa sensor via zigbee2mqtt <br>Tested with: Xiaomi Aquara RTCGQ11LM Human Motion Sensor
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/](.*):, ? $1 : undef }
attr DEVICE stateFormat Motion: occupancy Luminance: illuminance
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
attr DEVICE model L_08_Human_Motion_TempSensor
name:L_09_zigbee2mqtt_Motion_Sensor
desc: Temp/hum/hpa sensor via zigbee2mqtt <br>Tested with: Xiaomi Aquara DJT11LM Smart Motion Sensor
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/](.*):, ? $1 : undef }
attr DEVICE stateFormat Motion: action X: angle_x Y: angle_y Z: angle_z
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
attr DEVICE model L_09_Motion_Sensor
name:L_10_zigbee2mqtt_Water_Leak_Sensor
desc: Temp/hum/hpa sensor via zigbee2mqtt <br>Tested with: Xiaomi Aquara SJCGQ11LM Water Leak Sensor
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/](.*):, ? $1 : undef }
attr DEVICE stateFormat Leak: water_leak
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
attr DEVICE model L_10_Water_Leak_Sensor
name:L_11_zigbee2mqtt_Light_Switch
desc: Temp/hum/hpa sensor via zigbee2mqtt <br>Tested with: Xiaomi Aquara WXKG02LM 2btn Smart Light Switch
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/](.*):, ? $1 : undef }
attr DEVICE stateFormat click
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
attr DEVICE model L_11_Light_Switch
cheers....
Zitat von: luke666s am 30 Januar 2019, 17:23:09
hab hier noch ne Kleinigkeit....
:)
Sehen mustergültig aus & sind eingecheckt, viel Spaß allen damit!
Hier mal ein Template für den Magichome RGB(W) Controller -> https://github.com/arendst/Sonoff-Tasmota/wiki/MagicHome-LED-strip-controller
Zumindest bei den von mir verwendeten LED strips musste ich im Tasmota "Arilux LC-01" als Gerät auswählen...
DISCLAIMER: es existieren mindestens 2 Varianten vom RGB controller! Ich habe beide getestet, hatte aber mit der alten Variante (mit aufgelöteten ESP) das Problem, dass sie sich (nacht dem ersten umflashen auf tasmota 6.4.1) zwar wie die neue über POWER steuern liess aber mir nur ein POWER1 reading zurück gab und kein POWER reading, sich aber im Gegenzug auch nicht über POWER1 steuern ließ... Ein zusätzlicher factory reset hatte geholfen.... Die neue mit integriertem ESP hatte dieses Problem nicht. Hier war cmnd und reading gleich (POWER). Evt war das nur ein Einzelfall ich wollte es aber erwähnen...
Weiterhin habe ich es statt A_05 A_05a genannt, falls noch jemand den passenden RGBW also A_05b hinzufügen will :)
name:A_05a_tasmota_rgb_led_controller
filter:TYPE=MQTT2_DEVICE
desc:Tasmota RGB controller tested with RGB variant of Magichome, arilux LC-01 ,etc... -> https://github.com/arendst/Sonoff-Tasmota/wiki/MagicHome-LED-strip-controller
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
off:noArg cmnd/DEVNAME/POWER 0\
on:noArg cmnd/DEVNAME/POWER 1\
toggle:noArg cmnd/DEVNAME/POWER 2\
rgb:colorpicker,RGB cmnd/DEVNAME/COLOR
attr DEVICE readingList \
tele/DEVNAME/LWT:.* LWT\
stat/DEVNAME/POWER:.* POWER\
tele/DEVNAME/STATE:.* { json2nameValue($EVENT) }\
stat/DEVNAME/RESULT:.* { json2nameValue($EVENT) }\
tele/DEVNAME/INFO.:.* { json2nameValue($EVENT) }
attr DEVICE userReadings rgb /stat/DEVNAME/COLOR
deletereading DEVICE .*
attr DEVICE autocreate 0
attr DEVICE devStateIcon {Color::devStateIcon($name,"rgb","rgb","state")}
attr DEVICE stateFormat POWER
attr DEVICE webCmd on:off:rgb
attr DEVICE icon light_control
attr DEVICE userReadings rgb {ReadingsVal($name,'Color','0')}
attr DEVICE webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:toggle:on:off
attr DEVICE model A_05a_tasmota_rgb_led_controller
sollte jemand das hombridgeMapping brauchen....
attr DEVICE homebridgeMapping Hue=Color,max=100,factor=3.6,cmd=color,cmds=0:color+100,On=POWER
cheers
Zu dem Magichome RGBW-Controller:
- So ganz will mir das mit den userreadings-Anweisungen nicht einleuchten. Es ist doppelt (im Ergebnis also nur das letzte maßgebend, und dann wird eigentlich nur das Reading "Color" nach "rgb" gedoppelt; soweit erkennbar, gibt es kein Reading für die Helligheit. Müßte ganz ohne userreadings doch eigentlich auch so gehen:attr DEVICE devStateIcon {Color::devStateIcon($name,"color","color","state")}
- Was das mit POWER, POWER1 usw. angeht, haben wir für andere Tasmota-Varianten da vorab eine Umstellung (mit einem innerhalb des templates zuerst angewendeten anderen template) vorgenommen, dass immer POWER1 verwendet wird und der Status klein geschrieben zurückkommt usw.. Würde das hier auch Sinn machen, v.a. um die beschriebenen Probleme mit unterschiedlichen ESP's zu vermeiden?
Udate:
habe das als template ins svn geladen mit den genannten Änderungen. Wäre nett, wenn du das kurz testen könntest :) .
Hallo,
hab die letzten etlichen Stunden mit einem Shelly RGBW2 gespielt und dabei auch erste Gehversuche mit den MQTT-Templates gemacht. Hier das Ergebnis.
Bitteschön aber nicht in die Liste integrieren. Das war nur so ein Versuch. Ich lasse den einfach hier stehen, falls jemand (oder ich) damit weitertun möchte.
Shelly ist auf "weiß" konfiguriert (spricht die vier Kanäle als weiße Leuchten an), das "Template" gilt nur für Kanal 0.
# shellyrgbw2 white-channel 0 only using original firmware
name:A_16_shellyrgbw2_white_c0
filter:TYPE=MQTT2_DEVICE
desc:shellyrgbw2 using white-channel 0 only with original firmware
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE setList\
on:noArg shellies/DEVNAME/white/0/command on\
off:noArg shellies/DEVNAME/white/0/command off\
brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/0/set {"$EVTPART0":"$EVTPART1"}
deletereading DEVICE status_.*
attr DEVICE readingList\
shellies/DEVNAME/white/0:.* { state=>$EVTPART0 }\
shellies/DEVNAME/white/0/status:.* {json2nameValue($EVENT)}
attr DEVICE webCmd toggle:on:off:brightness
attr DEVICE genericDeviceType light
attr DEVICE model A_16_shellyrgbw2_white_c0
So... Nachdem das Brett vor dem Kopf weg ist ;)
WXKG12LM - Xiaomi Aqara wireless switch (with gyroscope)
name:L_12_zigbee2mqtt_Wireless_Button
desc: Wireless button via zigbee2mqtt <br>Tested with: Xiaomi Aqara WXKG12LM wireless switch with gyroscope
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
attr DEVICE stateFormat Click: click Action: action
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
attr DEVICE model L_12_Wireless_Button
@luke666s, @Beta-User
Das "Aqara" ohne "u" ;)
Hallo,
stehe gerade etwas auf dem Schlauch, wo steht/sieht man denn die Beschreibung/Description/desc: die man im Template angibt.
War der Meinung der Inhalt steht später dann über Replace, ist aber nicht so.
Gruß
Thomas
Zitat von: TomLee am 11 März 2019, 12:57:39
stehe gerade etwas auf dem Schlauch, wo steht/sieht man denn die Beschreibung/Description/desc: die man im Template angibt.
War der Meinung der Inhalt steht später dann über Replace, ist aber nicht so.
Die Frage wäre m.E. besser hier aufgehoben gewesen: https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200 (bzw. es handelt sich ggf. sogar um eine ganz allgemeine Frage zum ganzen...)
Grundsätzlich gehört immer zusammen, was ab "name:" bis vor das nächste "name:" steht.
"desc:" ist das, was als Beschreibung bei Aufruf von ? erscheint.
Was mit Replace gemeint ist, kann ich nur raten:
Wenn man irgendeine Variable vorab mit Inhalt füllen will, der dann in den nachfolgenden Zeilen statt der Variable eingesetzt werden soll, macht man das mit "par: ...". Dabei ist die Syntax: VARIABLENNAME;Hinweistext, der in einem Dialogfeld zur Erstetzen im Aufruf erscheint, wenn die hinter dem nächsten Trenner (";") stehende Perl-Funktion "undef" zurückgibt. Wird was anderes als undef (oder vielleicht ""?) zurüchgeliefert, wird das direkt und ohne weitere Rückfrage übernommen.
Wenn das in der Form noch nicht weiterhilft, bitte in den anderen Thread ausweichen!
Mahlzeit... Hätte da noch zwei Aqaras
Xiaomi Aqara WXKG11LM wireless button (older, without gyro | single, double, triple, quadruple click)
name:L_13_zigbee2mqtt_wireless_button_old
desc: Wireless button without gyro via zigbee2mqtt <br>Tested with: Xiaomi Aqara WXKG11LM wireless button
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
attr DEVICE stateFormat Click: click
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
attr DEVICE model L_13_wireless_button_old
Xiaomi Mi/Aqara MFKZQ01LM smart home cube (shake, wakeup, slide, flip180, flip90, rotate_left and rotate_right)
name:L_14_zigbee2mqtt_aqara_cube
desc: Aqara smarthome cube via zigbee2mqtt <br>Tested with: Xiaomi Aqara MFKZQ01LM smarthome cube
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
attr DEVICE stateFormat Action: action
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
attr DEVICE model L_14_aqara_cube
Guten Morgen zusammen,
hab speziell für die Müller Licht/MLI/Aldi "tint" Leuchten noch ein Template erstellt. RGBW Leuchte mit Farbauswahl und Farbtemperaturauswahl bei weißem Licht.
name:L_02d_zigbee2mqtt_light_MLItint
filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
desc: MuellerLight/MLI/Aldi tint RGBW bulb connected via zigbee2mqtt <br>tested with Mueller Light tint RGBW bulb
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
attr DEVICE icon hue_filled_white_and_color_e27_b22
attr DEVICE stateFormat {lc ReadingsVal("$name","state",0)}
attr DEVICE devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr DEVICE webCmd toggle:on:off:brightness:color_temp:white:bright:color
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
attr DEVICE setList \
on:noArg BASE_TOPIC/DEV_ID/set {"state":"ON"}\
off:noArg BASE_TOPIC/DEV_ID/set {"state":"OFF"}\
white:noArg BASE_TOPIC/DEV_ID/set {"brightness": 200 , "color_temp": 320}\
bright:noArg BASE_TOPIC/DEV_ID/set {"brightness": 254, "color_temp": 250}\
color_temp:colorpicker,CT,250,1,454 BASE_TOPIC/DEV_ID/set {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,5,255 BASE_TOPIC/DEV_ID/set {"state":"on","$EVTPART0":"$EVTPART1"}\
color:colorpicker,HEX,0,15,255 BASE_TOPIC/DEV_ID/set {"color":{"$EVTPART0":"#$EVTPART1"}}
attr DEVICE model L_02d_zigbee2mqtt_light_MLItint
Vielleicht kann das ja noch jemand gebrauchen ;)
Viel Spaß damit!
Danke auch an Nenno für die initialen Logs :)
UPDATE:
Sorry, grad gemerkt das ich die falsche (Test-)Version eingestellt hab! :(
DAS ist die Richtige!
name:L_02d_zigbee2mqtt_light_MLItint
filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
desc: MuellerLight/MLI/Aldi tint RGBW bulb connected via zigbee2mqtt <br>tested with Mueller Light tint RGBW bulb
par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
attr DEVICE icon hue_filled_white_and_color_e27_b22
attr DEVICE stateFormat {lc ReadingsVal("$name","state",0)}
attr DEVICE devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr DEVICE webCmd toggle:on:off:brightness:color_temp:warm:white:hex
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
attr DEVICE setList \
on:noArg BASE_TOPIC/DEV_ID/set {"state":"ON"}\
off:noArg BASE_TOPIC/DEV_ID/set {"state":"OFF"}\
warm:noArg BASE_TOPIC/DEV_ID/set {"brightness": 200 , "color_temp": 360}\
white:noArg BASE_TOPIC/DEV_ID/set {"brightness": 254, "color_temp": 250}\
color_temp:colorpicker,CT,250,1,454 BASE_TOPIC/DEV_ID/set {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,5,255 BASE_TOPIC/DEV_ID/set {"state":"on","$EVTPART0":"$EVTPART1"}\
hex:colorpicker,HEX,0,15,255 BASE_TOPIC/DEV_ID/set {"color":{"$EVTPART0":"#$EVTPART1"}}
attr DEVICE model L_02d_zigbee2mqtt_light_MLItint
Nachtrag 21.03.2019: Nochmal leicht abgeändert das Template, so werden die beiden "presets" vielleicht deutlicher vom Verständnis.
So,
jetzt habe ich die tint nochmal ausgepackt und ein wenig am Testsystem rumgebastelt.
Das "Müller"-template ist nach unserer Nomenklatur eigentlich ein verbessertes rgbw-hex, als solches ist es jetzt mit den Presets zu finden; leider war bei meinem Testsystem Color nicht geladen, aber bei den Systemen, bei denen das irgendwo schon läuft, sollte auch die hex-Rückwärtsauswertung einigermaßen passen...
Dazu gibt's auch zwei neue tastmota-templates für einen Rollladenmodus von 87insane.
Hi Beta-User,
wenn du es auch sinnvoll findest: würdest du evtl. die bridgeRegexp von "L_01_zigbee2mqtt_bridge" um den Unterstrich (und evtl. andere Trenner erweitern):
attr env_zigbee bridgeRegexp zigbee2mqtt/([A-Za-z0-9_]*)[/]?.*:.* "zigbee_$1"
Quelle:
https://forum.fhem.de/index.php/topic,99800.0.html
Es wäre sinnvoll im tasmota_rgb_led_controller-Template die setList noch um die Möglichkeit den Dimmer-Wert einzustellen zu ergänzen:
attr DEVICE setList\
off:noArg CMNDTOPIC/POWER1 0\
on:noArg CMNDTOPIC/POWER1 1\
toggle:noArg CMNDTOPIC/POWER1 2\
Color:colorpicker,RGB CMNDTOPIC/COLOR\
Dimmer:colorpicker,BRI,0,5,100 CMNDTOPIC/DIMMER
Ich vermisse außerdem Templates für mit Espurna (https://github.com/xoseperez/espurna) angebundene LEDs. Arbeitet da schon jemand dran? Ansonsten würde ich mir das vielleicht mal bei Gelegenheit anschauen.
Thx, die Dimmer-Option ist im svn. Bei der Gelegenheit: das Color-devStateIcon kennt doch auch ein Brightness-Reading, wenn ich das richtig im Kopf habe. Entsprechend noch anpassen?
Espurna hatte ich bisher nicht auf dem Radar, können wir aber gerne aufnehmen. Wenn möglich bitte bei der Gelegenheit auch um Info, wie die bridgeRegexp im General-Bridge-template zu erweitern wäre (auf die Schnelle scheint es aber keinen eindeutigen "Espurna-Kenner" zu geben => geht nicht). Wenn es dazu was zu diskutieren gibt, bitte einen separaten Thread aufmachen :) . Dieser hier soll "schlank" bleiben...
Zitat von: Beta-User am 09 Mai 2019, 07:24:11
Thx, die Dimmer-Option ist im svn. Bei der Gelegenheit: das Color-devStateIcon kennt doch auch ein Brightness-Reading, wenn ich das richtig im Kopf habe. Entsprechend noch anpassen?
Stimmt, das sollte man wie folgt ändern:
attr DEVICE devStateIcon {Color::devStateIcon($name,"rgb","Color","Dimmer","POWER")}Zur Zeit bekomme ich beim Versuch das Template zu aktivieren übrigens folgende Fehlermeldung:
Unknown template_entry_name A_01z_tasmota_set_lowercase_texts_and_state1_nF
Danke für den Hinweis zum kaputten internen Verweis, habe ich gefixt. Dadurch dürfte auch das Reading POWER1 relevant werden, hab's gleich entsprechend angepaßt und bitte ggf. um Rückmeldung, wenn es nicht funktioniert.
Im Template für die zigbee2mqtt-Bridge ist in der setList bei y_device_setting eine Klammer zu viel, wodurch das Template nicht komplett angewendet wird.
Thx, update folgt (vermutlich vor morgen früh!)
Ja eigentlich gehört Tasmota Pow (r2?) Template vorschlag (https://forum.fhem.de/index.php/topic,100484.msg939131.html#msg939131) ja auch hier reich
Zitat von: DasQ am 15 Mai 2019, 16:07:14
Ja eigentlich gehört Tasmota Pow (r2?) Template vorschlag (https://forum.fhem.de/index.php/topic,100484.msg939131.html#msg939131) ja auch hier reich
War das eine positive Rückmeldung zu dem vertemplateten Vorschlag in meiner Antwort? Da waren in meiner Wahrnehmung noch ein paar Fragen offen...
Dann: Soll das den vorhandenen POW ersetzen oder zusätzlich ins file?
Wenn ich dazu klare Antworten erhalte, mach ich das selbstredend direkt mit rein :) .
Zitat von: Beta-User am 14 Mai 2019, 07:32:12
Das relay in state schaltbar zu machen, hat den Vorteil, dass man on-for-timer etc. verwenden kann, macht es aber erforderlich, das devStateIcon mit Perl zusammenzubasteln. Außerdem sollte das online/offline-Symbol direkt zum WEB-IF führen, ohne dass extra die IP angezeigt wird; ich finde das eine elegante Lösung, die auch bei einigen anderen Devices so umgesetzt ist (die MiLight-Bridge, z.B.), ist aber natürlich Geschmackssache.
hab ich mir zu herzen genommen und noch den punkt klickbar gemacht schaus dir an. von mr aus ists ok
Ich versuche gerade, eine Sonoff_B1 in MQTT2 einzubinden. Ich scheitere schon an elementaren Dingen. Zwar kann ich on-off einstellen, aber B1 hat auch Farbe und das geht nicht.
Bisher habe ich:
Internals:
CFGFN
CID DVES_86B762
DEF DVES_86B762
DEVICETOPIC Sonoff_B1
FUUID 5d1898ab-f33f-1115-3fa4-34d2a547e3cf09be
IODev Mosquitto
LASTInputDev Mosquitto
MSGCNT 80
Mosquitto_MSGCNT 80
Mosquitto_TIME 2019-06-30 14:53:50
NAME Sonoff_B1
NR 19352
STATE off
TYPE MQTT2_DEVICE
OLDREADINGS:
READINGS:
2019-06-30 14:50:07 CT 495
2019-06-30 14:50:07 Channel_1 100
2019-06-30 14:50:07 Channel_2 0
2019-06-30 14:50:07 Channel_3 0
2019-06-30 14:50:07 Channel_4 1
2019-06-30 14:50:07 Channel_5 98
2019-06-30 14:50:07 Color FF000003FB
2019-06-30 14:50:07 Dimmer 100
2019-06-30 14:50:07 Fade off
2019-06-30 14:50:07 HSBColor 0,100,100
2019-06-30 14:50:07 LedTable off
2019-06-30 14:50:07 LoadAvg 269
2019-06-30 14:53:50 POWER1 off
2019-06-30 14:32:12 SaveData on
2019-06-30 14:50:07 Scheme 0
2019-06-30 14:32:12 SetOption26 on
2019-06-30 14:50:07 Sleep 0
2019-06-30 14:50:07 SleepMode Dynamic
2019-06-30 14:50:07 Speed 1
2019-06-30 14:32:12 StateText1 off
2019-06-30 14:32:12 StateText2 on
2019-06-30 14:32:12 StateText3 toggle
2019-06-30 14:32:12 StateText4 hold
2019-06-30 14:50:07 Time 2019-06-30T14:50:06
2019-06-30 14:50:07 Uptime 0T00:34:56
2019-06-30 14:50:07 Vcc 3.374
2019-06-30 14:50:07 Wifi_AP 1
2019-06-30 14:50:07 Wifi_BSSId F0:9F:C2:A7:4D:00
2019-06-30 14:50:07 Wifi_Channel 1
2019-06-30 14:50:07 Wifi_Downtime 0T00:00:04
2019-06-30 14:50:07 Wifi_LinkCount 1
2019-06-30 14:50:07 Wifi_RSSI 100
2019-06-30 14:50:07 Wifi_SSId WLAN-120954
2019-06-30 14:53:49 state set_off
Attributes:
IODev Mosquitto
autocreate 0
devStateIcon on:ios-on-green:off off:ios-off:on offline:ios_setoff_fill:
group Schalter
model A_01a_tasmota_basic_state_power1
readingList tele/sonoff_b1/LWT:.* LWT
tele/sonoff_b1/STATE:.* { json2nameValue($EVENT) }
tele/sonoff_b1/SENSOR:.* { json2nameValue($EVENT) }
tele/sonoff_b1/INFO.:.* { json2nameValue($EVENT) }
stat/sonoff_b1/RESULT:.* { json2nameValue($EVENT) }
setList off:noArg cmnd/sonoff_b1/POWER1 0
on:noArg cmnd/sonoff_b1/POWER1 1
toggle:noArg cmnd/sonoff_b1/POWER1 2
setStateList on off toggle
stateFormat POWER1
Nach der commandref schreibe ich den MQTT-topic dahinter
color:rgb /cmnd/sonoff_b1/color
Mir ist nur nicht klar, wie ich vorab ein Farbauswahlfeld erzeugen kann, so dass die Farbe aus dem Farbauswahlfeld dann in das MQTT-topic kommt. Ob meine MQTT-Syntax richtig ist, konnte ich auch nicht prüfen.
Das Attribut "setStateList" regelt nach der englischen commandref nur, dass zwischen Ausführung und Feedback unterschieden wird; da könnte also Color hinzugefügt werden.
Hmm, also vorab: da das vermutlich eine etwas längere Sache wird, bitte entweder einen neuen Thread anfangen und hier ggf. verlinken, oder häng' dich an einen der Threads zu Tasmota, die sich (auch) mit RGB-Devices befassen.
Du mußt den $EVENT (oder nachbearbeitete Teile davon) versenden. Es gibt auch schon mind. ein Tasmota-RGB-Template; das könntest du evtl. mal testen, ob das nicht ootb geht, ansonsten bitte mal die entsprechenden Templates durchsehen (gibt auch ein oder 2 Shelly-templates in der File).
(Und laß Color aus der setStateList raus; da gehören nur Dinge rein, die mit on und off zu tun haben).
läuft:
ttributes:
IODev Mosquitto
autocreate 0
devStateIcon on:ios-on-green:off off:ios-off:on offline:ios_setoff_fill:
group Schalter
model A_01a_tasmota_basic_state_power1
readingList tele/sonoff_b1/LWT:.* LWT
tele/sonoff_b1/STATE:.* { json2nameValue($EVENT) }
tele/sonoff_b1/SENSOR:.* { json2nameValue($EVENT) }
tele/sonoff_b1/INFO.:.* { json2nameValue($EVENT) }
stat/sonoff_b1/RESULT:.* { json2nameValue($EVENT) }
setList off:noArg cmnd/sonoff_b1/POWER1 0
on:noArg cmnd/sonoff_b1/POWER1 1
toggle:noArg cmnd/sonoff_b1/POWER1 2
rgb:colorpicker,RGB cmnd/sonoff_b1/COLOR
setStateList on off toggle
stateFormat POWER1
userReadings rgb {ReadingsVal($name,'Color','0')}
webCmd on:off:rgb
Gesendet von iPad mit Tapatalk Pro
Zitat von: andies am 30 Juni 2019, 16:16:51
läuft:
Bin nicht sicher, ob da ein neues template Sinn macht. M.E. müßte A_05a_tasmota_rgb_led_controller auch zu diesem Device passen? Das bietet noch einen Dimmer. Geht das hier nicht?
Ansonsten: userReadings ohne Trigger kommen mir nicht mehr in die templates :) . Welchen Zweck verfolgt das Umpacken?
Wenn es sein muß, sollte die Langform von json2nameValue($EVENT,'',$JSONMAP) genutzt werden und ein passendes JSONMAP-Attribut, das Color nach rgb mappt ;) .
OK, dann probiere ich das template mal aus. Bin nicht vor ort, aber auf FHEMWeb sieht das erstmal gut aus.
Ich habe mal den Bewegungsmelder von Osram (Lightify bzw. Smart+) und den Temperatur-/Luftfeuchte-Sensor ohne Luftdruck von Xiaomi ergänzt:
Index: mqtt2.template
===================================================================
--- mqtt2.template (Revision 20188)
+++ mqtt2.template (Arbeitskopie)
@@ -378,7 +378,26 @@
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model L_14_aqara_cube
+# Osram Lightify, Smart+ Motion Sensor
+name:L_15_zigbee2mqtt_osram_motion_sensor
+desc: Osram motion sensor via zigbee2mqtt <br>Tested with: Osram Lightify Motion Sensor
+filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
+par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
+par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
+attr DEVICE stateFormat Motion: occupancy T: temperature
+attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
+deletereading -q DEVICE (?!associatedWith).*
+attr DEVICE model L_15_osram_motion_sensor
+name:L_16_zigbee2mqtt_TempHumSensor
+desc: Temp/hum sensor via zigbee2mqtt <br>Tested with: Xiaomi MiJia WSDCGQ01LM Temperature Humidity Sensor
+filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
+par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
+par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
+attr DEVICE stateFormat T: temperature H: humidity
+attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
+deletereading -q DEVICE (?!associatedWith).*
+attr DEVICE model L_16_TempHumSensor
###########################################
# TASMOTA
Thx, hab's eben eingecheckt, allerdings etwas anders einsortiert (sind eigentlich nahe Verwandte von bestehenden Devices) und benannt (die Namen sind eher funktions-/reading-Typ-bezogen, und eher nicht herstellerspezifisch).
Ich wollte nicht alles neu nummerieren. ;)
Ist die Nummerierung eigentlich notwendig? Ohne wäre es einfacher, Devices mittendrin hinzuzufügen.
"Notwendig" nicht, aber die Sortierung, wie man es bei "?" angezeigt bekommt, richtet sich nicht nach "order of appearance" in der file, sondern alphanummerisch nach den Namen.
Es ist daher für die user mMn. einfacher, wenn Dinge, die ähnlich sind, auch nahe beieinander auftauchen (es gab dazu mal einen Thread (-teil), in dem ich das versucht hatte, vorab mal zur Diskussion zu stellen, auch, was die Einordnung der ersten templates in ein späteres, viel größeres Gesamtbild anging, ich weiß nur nicht mehr wo... Mit der Filter-Option, die Rudi dann dankenswerterweise später irgendwann mal eingebaut hat, ist das mit der Übersichtlichkeit aber sowieso etwas entschärft).
Das mit "dazwischen" geht ja, man muß dann halt mit den "Indexbuchstaben" etwas tricksen, dass das am Ende paßt ;) .
Zitat"Notwendig" nicht, aber die Sortierung, wie man es bei "?" angezeigt bekommt, richtet sich nicht nach "order of appearance" in der file, sondern alphanummerisch nach den Namen.
Das kann (auf Wunsch) aber leicht geaendert werden.
Ich denke auch ueber eine bessere Hilfe nach (neben attrTemplate ?), bisher noch ohne Ergebnis :)
Moin Rudi,
(die Antwort gehört eigentlich nach https://forum.fhem.de/index.php/topic,93370.0.html, aber da kann ich nicht antworten...? Oder gibt es einen allg. Thread zu dem Thema, damit auch andere (potentiell) "Betroffene" was dazu sagen könnten?)
Bzgl. des Sortierens: Danke für's Angebot. Auf "order of appearance" umzustellen, fände ich spontan nicht zielführend, weil dann "externe" templates nicht mehr "richtig" einsortiert würden (Bsp. ebusd.template, zukünftig evtl. Sprachsteuerungs-add-ins usw.).
Andererseits wäre es vermutlich für die Anwender "angenehmer", wenn nicht erst der Kenner für die Sortierung in den Namen gecoded wäre.
Eventuell wäre es eine Idee, dazu ein neues, optionales "sort:" einzuführen (ebenfalls alphanummerisch, damit erst mal das bestehende System auf einfache Weise transferiert werden könnte)? Also erst alles anzeigen, was ausdrücklich sortiert werden soll, dann die ohne "sort" (dann gerne nach "order of appearance"? Dann könnte man auch die Namen wieder vereinfachen, was aber Nacharbeitsbedarf bei der Doku nach sich zieht).
Hätte allerdings den (großen?) Vorteil, dass man es nachträglich noch ändern könnte, ohne dass die User das wissen müßten, und notfalls halt immer längere Subindizes verwenden könnte, wenn irgendwas neues um's Eck kommt.
Zur Hilfe fällt mir spontan leider nichchts ein, wenn ja, melde ich mich. Einfach nur ein "help" "help <devspec>" einzuführen, das dann ggf. nur den Hinweistext zum aktuellen/den ausgewählten templates anzeigt bzw. einen allgemeinen Hilfetext zu attrTemplate, wenn kein model gesetzt ist, hilft vermutlich nicht wirklich?
Nur die Ankündigung, dass die Entwicklung eines neuen templates für Ecovacs Deebot Saugroboter, die mqtt sprechen, hier (https://forum.fhem.de/index.php/topic,103842.0.html) stattfindet .
Als Bezeichnung hab ich mir B_01_deebot_bridge vorgestellt. Diskussion kann im Entwicklungsthread geführt werden.
Grüße Markus
Guten Morgen,
als Ergebnis meiner Migration von MQTT nach MQTT2 https://forum.fhem.de/index.php/topic,103762.0.html (https://forum.fhem.de/index.php/topic,103762.0.html)
ist nun für die Sonoff-4CH mit Tasmota dieses template entstanden, das jeden Kanal in ein eigenes Geräte legt.
# sonoff 4 channel device flashed with Tasmota.
name:A_04_tasmota_4channel_split
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:sonoff 4 channel device flashed with Tasmota. <br>NOTE: a second, third and fourth device will be created for each additional channel
set DEVICE attrTemplate A_01a_tasmota_basic_state_power1
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
#create device for CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 stateFormat POWER2
attr DEVICE_CH2 comment Channel 2 for DEVICE
setreading DEVICE_CH2 associatedWith DEVICE
attr DEVICE_CH2 setList \
off:noArg CMNDTOPIC/POWER2 0\
on:noArg CMNDTOPIC/POWER2 1\
toggle:noArg CMNDTOPIC/POWER2 2
attr DEVICE_CH2 setStateList on off toggle
#create device for CH3
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 stateFormat POWER3
attr DEVICE_CH3 comment Channel 3 for DEVICE
setreading DEVICE_CH3 associatedWith DEVICE
attr DEVICE_CH3 setList \
off:noArg CMNDTOPIC/POWER3 0\
on:noArg CMNDTOPIC/POWER3 1\
toggle:noArg CMNDTOPIC/POWER3 2
attr DEVICE_CH3 setStateList on off toggle
#create device for CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 stateFormat POWER4
attr DEVICE_CH4 comment Channel 4 for DEVICE
setreading DEVICE_CH4 associatedWith DEVICE
attr DEVICE_CH4 setList \
off:noArg CMNDTOPIC/POWER4 0\
on:noArg CMNDTOPIC/POWER4 1\
toggle:noArg CMNDTOPIC/POWER4 2
attr DEVICE_CH4 setStateList on off toggle
#set the model attr for all new devices
attr DEVICE model A_04_tasmota_4channel_split
attr DEVICE_CH2 model A_04_tasmota_4channel_split
attr DEVICE_CH3 model A_04_tasmota_4channel_split
attr DEVICE_CH4 model A_04_tasmota_4channel_split
Gruß vom Blauhorn
:)
Du lernst ja fix...!
Thx, u.a. das habe ich eben (mit kleinen Modifikationen) eingecheckt. Danke auch für die Anregung, bei den "Kindern" auch immer das Modell zu setzen, das fehlt(e) bei dem einen oder anderen auch noch...
ZitatEventuell wäre es eine Idee, dazu ein neues, optionales "sort:" einzuführen (ebenfalls alphanummerisch, damit erst mal das bestehende System auf einfache Weise transferiert werden könnte)?
Ich habe order: (optional) implementiert.
Achtung: der Vergleich ist _nicht_ numerisch, sondern alphanumerisch!
Weiterhin erscheint ab sofort beim Auswahl eines attrTemplate Wertes die Beschreibung und die Liste der Befehle.
Zitat von: rudolfkoenig am 20 September 2019, 12:54:22
Ich habe order: (optional) implementiert.
Achtung: der Vergleich ist _nicht_ numerisch, sondern alphanumerisch!
Weiterhin erscheint ab sofort beim Auswahl eines attrTemplate Wertes die Beschreibung und die Liste der Befehle.
Habe eben eine aktualisierte Version von mqtt2.template ins svn geschoben, hatte zwar auf dem Testsystem keine große Auswahl an angezeigten Devices, aber das so gut aus :) .
Gefällt mir sehr gut mit den kürzeren Namen und dem Umstand, dass das sortieren jetzt im Hintergrund abläuft und auch nicht mehr im "model" hinterlegt ist (die sind auch alle geändert...). Wird zwar vermutlich ewig dauern, bis alle model-Angaben in der Statistik wieder passen, aber das können wir verschmerzen, oder?
Kann nicht garantieren, dass ich alles "erwischt" habe und nicht irgendwelche Querbezüge kaputt gegangen sind (interne Aufrufe auf andere templates). Wer was findet, bitte im "bugs"-Thread melden.
Wenn das hier keine größeren Probleme aufwerfen sollte, ziehe ich bei Gelegenheit "meine" beiden anderen files nach.
Vielleicht wäre es eine Überlegung, die setlist der SonOff-Templates folgendermaßen zu ergänzen:
setOtaUrl:textField CMNDTOPIC/OtaUrl $EVTPART1\
upgrade:noArg CMNDTOPIC/upgrade 1\
Somit lässt sich die OTA-Url setzen und danach ein Firmware-Update für alle Geräte im Netz gleichzeitig anstoßen.
lg, Stefan
Thx, hab's mal beim "Basistemplate" dazugefügt, damit sollte es sich an (fast?) alle einkanaligen vererben.
Wenn es sich bewährt, schaue ich mir bei Gelegenheit noch die an, die fehlen.
@all: Seit gestern abend bzw. heute morgen werkelt bei mir testweise ein OpenMQTTGateway auf einem ESP32, siehe https://github.com/1technophile/OpenMQTTGateway/wiki, nachdem hier ein User Fragen (https://forum.fhem.de/index.php/topic,103737.0.html) im Zusammenhang mit 433HMz-Rolling Codes dazu hatte. Für 433MHz finde ich das vorläufig gar nicht sooo spannend, aber das kann scheinbar einige/alle (?) BT-Devices von Xiaomi und taugt evtl. auch als BT-Scanner.
Werde damit wohl meinen IR-ESP8266 (360°-GW, geflasht mit Tasmota) ersetzen (der ESP32 sollte alle drei Funktionen parallel können und sich noch z.B. mit einem BME280 ergänzen lassen, wer das will).
Wie dem auch sei, den Tag über hat das hier in der eher funkarmen Gegend ca. 25 BT-Devices "eingefangen" (bisher keinen Xiaomi, oh Wunder...). Wenn also jemand Lust hat, da mitzuüberlegen, wie man das @MQTT2-Device sinnvoll ausgestalten kann: feel free, entweder einen separaten Thread aufzumachen oder sich einzuklinken :) .
Ein schon ganz passables Template für die ESP-Brücke und einen speziellen RF-Anwendungsfall sind vorhanden, ansonsten scheint der Sketch intern auch nur "die üblichen Verdächtigen" zu nutzen, was libs angeht.
Guten Abend.
Ich versuche meine Jarolift Rolläden mit MQTT2 zu verwenden.
(Liefen bisher mit dem mosquitto broker)
Dafür habe ich ein frisches FHEM aufgesetzt und wollte es entsprechend Anleitung betreiben. (Mit ioDEV
MQTT2_FHEM_Server, sonst wie in der Anleitung https://github.com/madmartin/Jarolift_MQTT/wiki/Usage-with-FHEM-&-MQTT)
Mein Problem: das attribut publishSet gibt es nicht für das ioDEV.
Wie gehe ich richtigerweise vor?
Falscher Thread. Der hier ist für fertige Templates...
OT-Tipp: Wenn du irgendwo einen ESP8266 rumliegen hast, mach da mal ein Tasmota drauf und wende das basic-Template darauf an. Dann hast du schon mal ein Beispiel, wie eine setList aufzubauen ist. Das erfüllt die Funktion, die die publishSet-Attribute aus MQTT_DEVICE hatten. Vermutlich wäre sowas sinnvoll:
attr DEVICE setList \
close:noArg cmd/jarolift/shutter/1 DOWN\
open:noArg cmd/jarolift/shutter/1 UP\[....]
Weitere Diskussion - sofern noch erforderlich - bitte in gesondertem Thread in diesem Forumsbereich, ich sehe das dann in der Regel schon, sonst in dem "Anregungen"-Thread kurz dahin verlinken.
Hallo Zusammen,
betreibe seit paar Wochen auch zigbee Komponente bei mir. Bis vor eine Woche habe ich MQTT(mosquitto) und zigbee2mqtt von Koenkk mit cc3251 als Controller und ein cc3251 Router betrieben. Seit eine Woche bin ich auf mqtt2 Server umgestigen un mosquitto gelöscht.
Soweit läuft alles und kann betrieben werden. Die integrierten Templates sind hervorragend.
Problem:
-Der Router wurde erkannt und als mqtt2 device angelegt.
meldet sich minütlich bei Controller und setzt folgende readings.
Readings
associatedWith MQTT2_zigbee_0x00Xxxxxxxxx 2019-11-09 08:18:50
led_state true 2019-11-09 08:35:50
linkquality 0 2019-11-09 08:35:50
state true 2019-11-09 08:35:50
ich habe leider kein template gefunden (online / offline) Anzeige wie mqtt.
Hat vielleicht jemand schon was in der Richtung gemacht?
Zitat von: Beta-User am 30 Oktober 2019, 20:54:01
Falscher Thread. Der hier ist für fertige Templates...
>:( Warum wird das überlesen? Kann ich da was machen, dass das nicht übersehen wird?
Aber der Vorschlag ist gut :) .
Bitte in dem anderen Thread (Bugs, Fragen...) ein vollständiges list einstellen und Infos liefern, was du wie (in etwa) angezeigt bekommen willst bzw. wie die Werte dazu sind (state true/false mit einem grünen und roten Punkt wäre kein Problem). Vermutlich würde es Sinn machen, in dem Fall auch die Verbindungsqualität irgendwie zu visualisieren (farbig?).
Kann man die LED via MQTT ein- und ausschalten? (bitte das passende Kommando mitteilen, dann kann man auch dazu einen setter basteln...).
Zitat von: Beta-User am 15 Mai 2019, 16:12:35
War das eine positive Rückmeldung zu dem vertemplateten Vorschlag in meiner Antwort? Da waren in meiner Wahrnehmung noch ein paar Fragen offen...
Dann: Soll das den vorhandenen POW ersetzen oder zusätzlich ins file?
Wenn ich dazu klare Antworten erhalte, mach ich das selbstredend direkt mit rein :) .
Hallo Beta-User,
ich sehe immer noch kein (für mich) nutzbares Template für den Tasmota POW2.
Ich habe diverse Tasmotas in meine Systeme eingebunden
aber mit den (neueren) POW2 gibt es Probleme.
Wenn ich das Template POW nehme, wird eigentlich viel Ausgelesen und Angezeigt.
Ein einfaches "On" oder "Off" schaltet zwar den Pow, aber der Status wird nicht nachgezogen.
Bin nur zu blöd das Ding zu integrieren - oder gibt es hier doch noch ein Problem?
Gruß Wolfdieter
(Für die Statistik: Falscher Thread #3...)
Der Hinweis, dass der state nicht paßt, hätte besser in den verlinkten Thread gepaßt und betrifft mMn. auch den "normalen" POW. Meine persönliche Tendenz wäre, in die generelle Tasmota-Struktur einzugreifen und die erweiterte json2nameValue()-Variante zu nutzen und POWER1 darüber via JSONMAP nach state zu schreiben. Ist aber uU. nicht (für die anderen Tasmota-templates) nebenwirkungsfrei, muß ich mir ansehen und ggf. in dem allg. Tasmota-Thread mal nachhaken, wie da die Temperatur dazu ist.
Für einen schnellen Fix kannst du einen userReadings-Eintrag machen, der auf POWER1 triggert und das Ergebnis nach state schreibt. In etwa so:
attr DEVICE userReadings state:POWER1:.* { ReadingsVal($name,"POWER1","") }
Habe jetzt aber nicht nachgesehen, ob man z.B. auch $EVTPART1 nutzen kann, wenn, ist das der direktere Weg.
Weitere Diskussion dazu bitte in dem passenden Thread: https://forum.fhem.de/index.php/topic,100484.0.html
ZitatHabe jetzt aber nicht nachgesehen, ob man z.B. auch $EVTPART1 nutzen kann, wenn, ist das der direktere Weg.
userReadings kennt kein EVTPART*, weil es im readingsEndUpdate berechnet wird, wenn eine (zusammengehoerige) Menge von Events fuer die notifies vorbereitet werden.
Beispielweise alles, was in einem JSON kommt, wird mit userReadings nur einmal "bearbeitet".
Eine moegliche Alternative ist "attr DEVICE stateFormat POWER1".
Danke für die Klarstellung betr. $EVTPARTx.
stateFormat ist hier schon gesetzt, beeinflußt aber nur STATE. Ob es Sinn macht, statt ReadingsVal->state auf IntenalVal->STATE umzubiegen, war auch eine Überlegung. Dabei hab ich aber die Befürchtung, dass das an einer Stelle ist, die gerne auch mal vom Benutzer geändert wird (grade bei dem POW), und dann funktioniert das wieder nicht.
Im Moment denke ich, es ist das einfachste, das globale Tasmota-template dahingehend zu ändern, dass json2nameValue in der vollen Form (für Result) genutzt wird und dann (erst mal nur für den POW) das jsonMap POWER1:state zu verwenden; dazu muß wohl auch im POW-template stateFormat (kommend aus dem globalen template) gleich wieder gelöscht werden...
Auch wenn es unschön ist, Attribute evtl. unnötig zu löschen, ist das m.E. jedenfalls für den Einstieg in eine eventuelle Umstellung ein gangbarer Weg; auch das allg. template ignoriert ja grade evtl. andere Vorgaben des Users.
Hallo zusammen,
hätte einen ersten Vorschlag für den ShellyDimmer:
--- mqtt2.template 2019-11-19 23:02:57.134372779 +0100
+++ mqtt2.template.new 2019-11-19 23:01:39.041573002 +0100
@@ -1499,6 +1499,34 @@
setreading DEVICE_CH4 associatedWith DEVICE,DEVICE_CH2,DEVICE_CH3
attr DEVICE_CH4 setStateList on off
+#shellydimmer
+# contributed by zeppelin
+name:shellydimmer
+filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
+desc:shellydimmer <br>Tested with 20191119-085746/master@e3a747f5
+order:A_18
+par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
+par:ICON;ICON as set, defaults to light_control;{ AttrVal("DEVICE","icon","light_control") }
+attr DEVICE icon ICON
+attr DEVICE setList\
+ off:noArg shellies/DEVNAME/light/0/command off\
+ on:noArg shellies/DEVNAME/light/0/command on\
+ pct:slider,0,1,100 shellies/DEVNAME/light/0/set {"turn": "on","brightness": $EVTPART1}
+deletereading -q DEVICE status_.*
+attr DEVICE readingList \
+ shellies/DEVNAME/light/0/status:.* {json2nameValue($EVENT)}\
+ shellies/DEVNAME/temperature:.* temperature\
+ shellies/DEVNAME/temperature_f:.* temperature_f\
+ shellies/DEVNAME/overtemperature:.* overtemperature\
+ shellies/DEVNAME/overload:.* overload\
+ shellies/DEVNAME/loaderror:.* loaderror\
+ shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : undef }
+attr DEVICE webCmd pct:on:off
+attr DEVICE devStateIcon {my $lderr = ReadingsVal($name,"loaderror","true") eq "true"?"10px-kreis-rot":"10px-kreis-gruen";; my $light = ReadingsVal($name,"ison","false") eq "true"?"on":"off";; my $cons = ReadingsVal($name,"light_0_power","unknown");; FW_makeImage($lderr)."<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Leistung: $cons</div>"}
+set DEVICE x_mqttcom announce
+attr DEVICE model shellydimmer
+
+
###############
#ebusd
#
Thx, ist eingecheckt.
Und: Willkommen im Forum @Zeppelin, starker Aufschlag ;D .
on-for-timer bei Tasmota habe ich bei der Gelegenheit auf SetExtensions zurückgestellt und den betreffenden Kommentar erweitert...
Hallo Beta-User,
danke für das einchecken. Beim Test hat sich bei mir ergeben, dass ich einen Fehler erhalte, wenn die Zeile
set DEVICE x_mqttcom announce
aktiv ist.
Sobald ich diese auskommentiere funktioniert alles. Ich habe die Zeile von den anderen Tamplates nur übernommen. Eventuell liegt es auch an meiner Installation.
Wäre super, wenn sich das ein andere auch noch mal anschauen könnte.
Es liegt am fehlenden "setter" in der setList. Ich bau's da noch ein, Danke für den Hinweis.
Habe ich jetzt auch gesehen, da war ich etwas blind. Danke.
(Ist zwar hier OT, aber um sicherzugehen, dass @Zeppelin das sieht; das shellydimmer-template hat Klärungsbedarf verursacht, was pct/brightness angeht):
https://forum.fhem.de/index.php/topic,94494.msg996478.html#msg996478
Hallo Beta-User,
mit der Brightness bin ich bis jetzt beim Shelly-Dimmer auch noch nicht zu Frieden. Diese bleibt leider immer auf den letzten gedimmten Wert stehen, wenn man den Dimmer ausschaltet. Normalerweise geht man davon aus, dass Dimmer aus auch brightness/pct 0 bedeutet. Pct ist aus meiner Sicht hier auch die bessere Einheit, da ja wie bereits erwähnt der Wert von 0 bis 100 geht.
Das Mapping habe ich getestet und es funktioniert.
Gruß
Zeppelin
Bezüglich pct / brightness just my 2 cents:
Das machen viele Lampenhersteller unterschiedlich - wenn eine Normierung dessn innerhalb FHEM angestrebt wird, geht das vermmutlich in eine ähnliche Richtung wie seinerzeit beim Battery (+ Derivate) Reading... Meines Wissens ist diese Normierung auch auf halbem Wege stecken geblieben.
Ich habe hir Lampen, die anstelle von "ct" zum Beispiel "cct" als Reading und Setter haben, dito mit pct und brightness. Bei den Yeelights zB heißt das entsprechende Reading "bright", geht von 0-100 und bleibt beim "off" der Lampe ebenfalls unverändert.
Daher die Frage: Muss / soll sowas in den templates geändert werden oder wie wollen wir das künftig handhaben? Generell fände ich eine übergreifend stimmige Nomeklatur mit entsprechender Definition sehr sinnvoll...
Habe auch noch eine Änderung ;-)
###########################################
# zigbee2mqtt
# The zigbee2mqtt bridge device (entire hex id of devices as bridgeRegexp)
name:zigbee2mqtt_bridge
desc:The zigbee2mqtt bridge device
filter:TYPE=MQTT2_DEVICE
order:L_01
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)[/].*:, ? $1 : undef }
attr DEVICE bridgeRegexp\
BASE_TOPIC/([A-Za-z0-9._]*)[/]?.*:.* "zigbee_$1"
attr DEVICE getList\
devicelist:noArg log BASE_TOPIC/bridge/config/devices\
networkmap_raw:noArg raw BASE_TOPIC/bridge/networkmap raw\
networkmap_graphviz:noArg graphviz BASE_TOPIC/bridge/networkmap graphviz
attr DEVICE readingList\
BASE_TOPIC/bridge/state:.* state\
BASE_TOPIC/bridge/config/devices:.* {}\
BASE_TOPIC/bridge/config/log_level:.* log_level\
BASE_TOPIC/bridge/config/permit_join:.* permit_join\
BASE_TOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
BASE_TOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
BASE_TOPIC/bridge/log:.* log\
BASE_TOPIC/bridge/networkmap:.* {}\
BASE_TOPIC/bridge/networkmap/graphviz:.* graphviz\
BASE_TOPIC/bridge/networkmap/raw:.* raw\
BASE_TOPIC/bridge/config:.* { json2nameValue($EVENT) }
attr DEVICE setList\
log_level:debug,info,warn,error BASE_TOPIC/bridge/config/log_level $EVTPART1\
permit_join:true,false BASE_TOPIC/bridge/config/permit_join $EVTPART1\
remove:textField BASE_TOPIC/bridge/config/remove $EVTPART1\
y_device_setting:textField BASE_TOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
x_bind:textField BASE_TOPIC/bridge/bind/$EVTPART1 $EVTPART2\
x_bind_unbind:textField BASE_TOPIC/bridge/unbind/$EVTPART1 $EVTPART2\
x_device_options:textField BASE_TOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}\
x_group_add_to:textField BASE_TOPIC/bridge/group/$EVTPART1/add $EVTPART2\
x_group_rm_from:textField BASE_TOPIC/bridge/group/$EVTPART1/remove $EVTPART2\
x_group_rm_from_all:textField BASE_TOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2\
x_group_add_group:textField BASE_TOPIC/bridge/config/add_group $EVTPART1\
x_group_rm_group:textField BASE_TOPIC/bridge/config/remove_group $EVTPART1\
z_elapsed:textField BASE_TOPIC/bridge/config/elapsed $EVTPART1\
z_last_seen:disable,ISO_8601,epoch,ISO_8601_local BASE_TOPIC/bridge/config/last_seen $EVTPART1\
z_ban:textField BASE_TOPIC/bridge/config/ban $EVTPART1\
z_rename:textField BASE_TOPIC/bridge/config/rename {"old":"$EVTPART1","new":"$EVTPART2"}\
z_reset_CC:noArg BASE_TOPIC/bridge/config/reset
attr DEVICE setStateList on off
attr DEVICE model zigbee2mqtt_bridge
# Based on https://forum.fhem.de/index.php/topic,94060.msg872371.html#msg872371
der SETter für LastSeen
Leute, ihr seid praktisch alle hier OT, aber:
- LastSeen ist geändert
- bei den Shellys habe ich (hoffentlich bei allen relevanten+korrekt) JSONMAP eingebaut, dass der 0-100-Wertebereich als Reading pct läuft.
(Sofern ich das nicht zwischendurch vergesse), gedenke ich, das bei mqtt2-attrTemplate weiter so zu halten, so dass es jedenfalls in diesem Modul durchgängig bleibt; für andere Module muß das der jeweilige Autor entscheiden, wie bei battery.* wird/kann es da Gründe für und gegen die "Einheitlichkeit" geben....
Was das "0"-Stellen angeht, halte ich das nicht für zweifelsfrei, bei off auch "0" anzuzeigen: Zum einen wird das device vermutlich den letzten Dimm-Wert annehmen, wenn man on schaltet (also ist der Wert weiter interessant), und zum anderen kann man das beim devStateIcon noch "verwursten" bzw. hat darüber eine Visualisierung.
MMn. also "no action required"... (Aber bitte: Das ist meine persönliche Meinung, wenn sich eine Mehrheit dafür findet und jemand, der Code/patches liefert...: Ich bin nur der, der es einpflegt. Letztlich entscheiden darf es die community).
(Und bitte weitere Diskussion zu pct etc. in dem Shelly-Thread, den Link und die Sachstandsddarstellung habe ich ja nicht ganz ohne Hintergedanken da reingenommen...)
Ich hätte den Vorschlag das als Template mit aufzunehmen.
https://github.com/weetmuts/wmbusmeters
Gerne teste ich ausgiebig, richte die Tage das für einen orts entfernten iperl Wasserzähler ein. Das JSON wird dann in mein MQTT zuhause gespült.
Grüße Dirk
...ich muß wohl meinen Einleitungstext nochmal ergänzen...
Gemeint ist: hier in diesem Thread soll es um fertige Template-Vorschläge gehen, die ich (mehr oder weniger) "einfach so" übernehmen kann.
Das mit dem WMBUSMETER mache ich gerne, es ist aber eher eine Anregung und gehört daher in den anderen (bugs, Fragen usw.) Thread....
Vorgehen im Allgemeinen:
- RAW-Definition von dem, was du hast in einen komplett neuen Thread im MQTT-Bereich packen (das sieht auf den ersten Blick so aus, als müßte man da irgendwie Daten nachbearbeiten, für einfache Devices kann man das direkt im "Fragen"-Thread machen);
- Da (wenn vorhanden) noch etwas mehr Hintergrundinfo verlinken, insbesondere zur MQTT-Topic (und ggf. JSON/Payload-) Struktur
- Einen Link in "Fragen"-Thread dahin legen, sollte ich das nicht nach einer gewissen Zeit sowieso gesehen haben...
Danke!
Ah ok, dann war ich zu vorschnell. Ich kann mich am Wochenende mal mit der Template Erstellung einlesen. Dann sollte das Beispiel auch schon laufen zum testen. Vielleicht ist es ja gar nicht so schwer wie ich grade danke :)
Hi Beta-User,
im Beitrag #0 hat sich ein Fehler eingeschlichen:
ZitatVorschläge möglichst als diff
Ist alles fertig, könnt ihr eine Kopie dr vorhandenen mqtt2.template-Datei anlegen, und euer template in die bisherge einfügen. Ein diff -u <original> <eure Kopie> ~/mqtt2.template.<hinweis>.patch ausführen, dann liegt im home-Verzeichnis eures users die neue Datei, die ihr nach Durchsicht dann hier anfügen könnt.
abgesehen vom "der ... bisherige" ist die Befehlszeile unvollständig - oder? :
diff -u <original> <eure Kopie> > ~/mqtt2.template.<hinweis>.patch Gruß Otto
Thx für die Hinweise, ist gefixt...
(Und auch das update zu devStateIcon aus dem anderen Post kommt bei nächster Gelegenheit :) ).
Zitat von: Beta-User am 19 November 2019, 10:28:37
Im Moment denke ich, es ist das einfachste, das globale Tasmota-template dahingehend zu ändern, dass json2nameValue in der vollen Form (für Result) genutzt wird und dann [...] das jsonMap POWER1:state zu verwenden [...]
Zur Info, damit eventuelle Mitleser aus diesem Thread hier das auch mitbekommen:
Es gibt hier (https://forum.fhem.de/index.php/topic,94494.msg1006836.html#msg1006836) eine Fassung mit (fast) kompletter jsonMap-Nutzung @Tasmota und der Bitte um Test und Rückmeldung dort.
Hi Beta-User,
ich weiß nicht, ob es bereits zwischenzeitlich geändert wurde, daher zur Sicherheit:
Meine Shelly2.5 wurden mit folgendem devStateIcon angelegt (nur my "$onl"Teil"):
{my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");;
Damit wird das Icon nicht gelb angezeigt, wenn ein Firmware-Update verfügbar ist. Ich selbst habe bei mir folgenden Part ergänzt:
{my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";;
Dabei habe ich aber auch folgendes geändert (so ist es identisch zum Template für die Shelly1):
{my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";;
Viele Grüße
Sascha
Hi Sascha_F,
Danke für die Rückmeldung.
Ist zwar hier auch falsch (gehört in den "Anregungen"-Thread), aber seit eben ist ein update für den 2.5 und den pm-Shelly im svn, die den "gelben Punkt" bisher nicht hatten. Du kannst übrigens selbst prüfen, was "zwischenzeitlich geändert" wurde, indem du nach einem update in den Quellcode schaust, das erleichtert mir die Arbeit ;) ...
Gruß, Beta-User
Hi Beta-User,
alles klar, dann Danke und Sorry! :-)
Werde ich zukünftig versuchen, so weit ich es schaffe und verstehe^^ ;D
Viele Grüße
Sascha
Hatten wir nicht genau das in einem anderen Thread schon fertig? Ich hatte den gelben Punkt vorgestern bei neuer Firmware. Hmmm....ich werd alt.
Edit: ahhh...licht an.... Hatte das nur für das Rollo gepostet. Für den 2.5er split, habe ich mir das auch gebaut. Wird das noch benötigt?
Gesendet von meinem LM-G810 mit Tapatalk
Zitat von: 87insane am 24 Januar 2020, 07:57:13
[...] Wird das noch benötigt?
Auch für Dich gilt 1:1 das hier :( :
Zitat von: Beta-User am 23 Januar 2020, 10:34:24
Ist [...] hier [...] falsch (gehört in den "Anregungen"-Thread), [...]. Du kannst übrigens selbst prüfen, was "zwischenzeitlich geändert" wurde, indem du nach einem update in den Quellcode schaust, das erleichtert mir die Arbeit ;) ...
Meine ernsthafte Bitte wäre wirklich, selbst im sourcecode zu schauen, was da (ggf. indirekt ;) ) aktuell steht (oder es mit einem Testgerät auszuprobieren...) und dann im "Anregungen"- oder "Shelly"-Thread einfach die zu ändernden Zeilen konkret (z.B. mit einer Zeilennummer bezogen auf eine Version) zu nennen und den neuen Code zu posten.
Übrigens: vermutlich hat es länger gedauert, das hier zu schreiben, wie selbst in den Code zu sehen. Dass ich das so herum mache, hat zwei Gründe:
1. Ich habe selbst fast keine der Hardwares, die sich in den templates tummeln, und kann daher nicht so gut testen.
2. Es ist mir wichtig, nicht "Fisch (http://www.konfuzius-weisheiten.de/konfuzius-heute/konfuzius-heute-gib-einem-mann-einen-fisch-und-du-ern%C3%A4hrst-ihn)" für alle anderen User selbst fangen zu müssen, sondern jeder, der erfolgreich geangelt hat, darf teilen. Es wäre mir daher viel lieber, wenn jeder wenigstens soviel Ahnung vom "Fischen" hätte, dass ich zielgerichtet nur wenige Handgriffe ausführen muß, um das "Netz", mit dem wir hier "fischen", schnell für alle "flicken" zu können.
Dieser Thread dient daher NUR dazu, das Netz mit fertigen Teilen zu vergößern, und wer hier mitliest, (z.B. weil er mal was gepostet hat,) will keine länglichen Diskussionen über Details, sondern - wenn überhaupt - nur die Info, was es neues gibt. Sei also so nett zu den anderen und mir und berücksichtige deren und meine Erwartungshaltung :) .
Gruß, Beta-User
Hallo,
im aktuellen Template für den Shelly2.5 scheint ein Fehler zu sein.
Wenn ich das Template auswähle wird in der Status-Übersicht ein Fehler bei der Power abgezeigt: "Aktuell: unknown W / Temp.: 64.74 °C"
Im Template sind die beiden Werte für "relay_X_power" im devStateIcon vertauscht; im Kanal 0 steht "relay_1_power" und im Kanal 1 "relay_0_power".
Als ich dann folgende Änderung für den Kanal 0 gemacht habe, funktionierte es (gleiches gilt entsprechen für den Kanal):
attr MQTT2_shellyswitch25_68D980 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";;;; my $light = ReadingsVal($name,"state","off");;;; my $cons = ReadingsVal($name,"relay_0_power","unknown");;;; my $temp = ReadingsVal($name,"temperature","-100");;;;"<div><a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C</div>"}
lg, Gerhard
Hallo zusammen,
Danke für's Melden von dem Bug in shelly 2.5 (wenn auch in falschen Thread...!), ist seit einiger Zeit schon gefixt.
Owntracks habe ich erst mal wie vorgeschlagen samt bridgeRegexp übernommen (k.A., warum das mit autocreate nicht klappen sollte, können wir gerne - wie ggf. weitere Fragen, die mit dem template zusammenhängen - hier weiterdiskutieren (https://forum.fhem.de/index.php/topic,99666.msg1019884.html#msg1019884)...).
Gruß, Beta-User
Zur Info:
Es gibt mit dem morgigen Update einige wichtige Änderungen, Details hier, (https://forum.fhem.de/index.php/topic,94494.msg1020582.html#msg1020582) in dem dortigen Thread bitte dann auch die Rückmeldungen dazu.
Heute möchte ich auch etwas beitragen.
Ich verwende einen NodeMCU mit 8 Ausgängen um Ventie zu schalten. Natürlich kann man auch die geläufige 8-Fach Relaiskarte für Arduino verwenden.
Gefläscht ist das aktuelle Tasmota.
Für Hier das von mir geänderte Template A_04b.
# tasmota 8ch as one FHEM device.
name:tasmota_8ch_unified_icon
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:Configures a single device including all readings <br>NOTE: Clicking on icons will issue a corresponding toggle command
order:A_04c
set DEVICE attrTemplate tasmota_basic_state_power1
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
attr DEVICE setList \
POWER1:on,off,toggle CMNDTOPIC/POWER1 $EVTPART1\
POWER2:on,off,toggle CMNDTOPIC/POWER2 $EVTPART1\
POWER3:on,off,toggle CMNDTOPIC/POWER3 $EVTPART1\
POWER4:on,off,toggle CMNDTOPIC/POWER4 $EVTPART1\
POWER1:on,off,toggle CMNDTOPIC/POWER5 $EVTPART1\
POWER2:on,off,toggle CMNDTOPIC/POWER6 $EVTPART1\
POWER3:on,off,toggle CMNDTOPIC/POWER7 $EVTPART1\
POWER4:on,off,toggle CMNDTOPIC/POWER8 $EVTPART1
attr DEVICE devStateIcon Online:10px-kreis-gruen@green Offline:10px-kreis-rot@red 1.on:on:POWER1+off 1.off:off:POWER1+on 2.on:on:POWER2+off 2.off:off:POWER2+on 3.on:on:POWER3+off 3.off:off:POWER3+on 4.on:on:POWER4+off 4.off:off:POWER4+on 5.on:on:POWER5+off 5.off:off:POWER5+on 6.on:on:POWER6+off 6.off:off:POWER6+on 7.on:on:POWER7+off 7.off:off:POWER7+on 8.on:on:POWER8+off 8.off:off:POWER8+on
attr DEVICE readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER1:.* POWER1\
STATTOPIC/POWER2:.* POWER2\
STATTOPIC/POWER3:.* POWER3\
STATTOPIC/POWER4:.* POWER4\
STATTOPIC/POWER5:.* POWER5\
STATTOPIC/POWER6:.* POWER6\
STATTOPIC/POWER7:.* POWER7\
STATTOPIC/POWER8:.* POWER8
attr DEVICE stateFormat LWT\
<a href="http://IPAddress" target="_blank">Hostname</a>\
<a href="http://IPAddress" target="_blank">IPAddress</a>\
<br>\
1:POWER1\
2:POWER2\
3:POWER3\
4:POWER4\
5:POWER5\
6:POWER6\
7:POWER7\
8:POWER8
attr DEVICE webCmd POWER1:POWER2:POWER3:POWER4:POWER5:POWER6:POWER7:POWER8
attr DEVICE model tasmota_8ch_unified_icon
Würde mich sehr auf die Integration freuen.
Gruß
Uli
Thx @Uli, ist seit eben (leicht angepaßt) im svn.
Hallo zusammen,
Ich habe mal ein MQTT2 Device zur Kopplung mit der WeeWX Wetterstation angefangen. Im Prinzip ist das fertig. Jetzt bräuchte noch ein paar Tipps zur Erstellung eines Templates dafür. Der Thread dazu ist hier: https://forum.fhem.de/index.php/topic,108815.0.html (https://forum.fhem.de/index.php/topic,108815.0.html)
Es muss auch was bei WeeWX selbst eingerichtet werden. Siehe ebenfalls den erwähnten Thread.
Grüße Martin
Hallo zusammen,
Ich habe heute gelernt, dass der Xiaomi Aqara Motion Sensor ein attr <device> event-on-change-reading .* braucht um nicht wunderliche Effekte zu bekommen. Siehe https://forum.fhem.de/index.php/topic,109133.msg1030833.html#msg1030833 (https://forum.fhem.de/index.php/topic,109133.msg1030833.html#msg1030833). Im Template F_01a_Xiaomi_Aqara_RTCGQ11LM_Motion_Sensor fehlt das aber.
Grüße Martin
Sorry, aber du bist mit dem Hinweis hier doppelt falsch:
1. Ist dieser Thread weiter nicht für Verbesserungsvorschläge gedacht (siehe 1. Post dieses Threads...) und
2. regst du eine Änderung eines attrTemplate für HUEDevice an. Das gehört gar nicht zu MQTT2, sondern dafür gibt es einen anderen Thread, in den ich das jetzt ausnahmsweise weitergegeben habe, weil sowieso ein paar andere Punkte erwähnenswert waren: https://forum.fhem.de/index.php/topic,101829.0.html
Hallo zusammen,
ich möchte ein neues Template für 4 Kanal Mehrfach Steckdosen vorstellen.
Getestet wurde mit einer 3AC+4USB Mehrfach Steckdose von Hyleton (HLT-333).
<a href="https://templates.blakadder.com/hyleton_333.html">Tasmota Template Repository</a>
Eigenschaften:
- Das automatisch angelegte MQTT2_DEVICE wird als Stamm Gerät verwendet
- Das Stamm Gerät steuert den ersten Kanal und bietet Tasmota typische Verwaltungs Funktionen
- Jeder weitere Kanal wird als einzelnes, untergeordnetes Gerät angelegt. (Split Devices)
- In den Split Geräten werden die meisten Readings entfernt (Konzentration auf reine Aktoren Steuerung)
- Netzsteckdosen erhalten das Icon hue_filled_outlet.
- Der schaltbare 4-fach USB Teil erhält das Icon rc_USB
- Online/Offline Verfügbarkeit wird angezeigt
- Die IP Adresse des Tasmota Web GUI wird angezeigt
Am Stamm Gerät werden ein aktuell folgende Verwaltungs Funktionen angeboten
- x_Reboot - Löst einen Neustart des Tasmota Gerätes aus. Hilfreich zum Füllen aller Readings.
- x_Status - Fragt Tasmota nach weiteren Status Informationen. So werden die in Tasmota eventuell gesetzten Alexa Namen sichtbar (FriendlyName)
- x_setOtaUrl - Bietet die URL für ein deutsches Tasmota an.
- x_upgrade - Führt einen Tasmota Firmware upgrade mit der aktuell gesetzten OtaUrl aus
- x_RuleButton und x_RuleEnable - Es wird eine Regel für die eingebaute Taste zur Schaltung aller Steckdosen angeboten.
- Kurzer Druck -> alles an
- Langer Druck -> alles aus
- x_DisableBlinkLED - unterdrückt das Blinken der Status LED bei fehlendem WLAN oder MQTT Verbindungs Abbruch. Erhöht den WAF wenns Nachts nicht störend blinkt :)
- x_Location - Die Werte für den Standort (Longitude, Latitude, Altitude) werden aus FHEM global übernommen und als Setting für Tasmota angeboten
- x_NTPServer - Bietet eine lokale fritz box als Quelle für NTP an
- x_ShowHostname - Setzt im Tasmota GUI die Anzeige des Host Namens
- x_SaveData - 0 = kehrt beim Einschalten in einen vordefinierten Zustand zurück, 1 = beim Einschalten wird der zuletzt eingenomme Zustand wiederhergestellt
Bemerkungen:
- Zur VervollständÄigung aller Readings wird ein Reboot ausgelöst. Damit wird auch LWT (online/offline) sofort verfügbar
- Mehrfache Anwendung am Stamm Gerät ist möglich. Vorher bitte die untergeordneten 'Split' Geräte mit delete device_.* löschen. Meldungen das der Copy der Split Geräte fehlschlägt werden damit vermieden.
- Tasmota's regelmäßige Rückmeldungen aus dem STATE Zweig erhalten einen state_ Präfix. Dies dient zur Erhaltung der Zeitstempel der POWERx Readings. Damit kann der Zeitpunkt des zuletzt erkannten Schaltvorganges abgelesen werden.
- Tasmota's Meldungen werden nach Kleinschreibung umgestellt. ON wird on, OFF wird off, TOGGLE wird toggle und HOLD wird hold
- Zur besseren Erkennung der Fähigkeiten des Gerätes in den FHEM Spracherkennungs Modulen wird der generische Typ auf Switch gesetzt.
Mit freundlichen Grüßen
Jörg
# 4-way multi socket 3AC+USB device flashed with Tasmota.
# Tested with Power Strip Hyleton 333, please see <a href="https://templates.blakadder.com/hyleton_333.html">Tasmota Template Repository</a>
name:tasmota_3socketUSB_split
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:4 channel device flashed with Tasmota. <br>NOTE: Tested with 4-way Power Strip Hyleton 333, please see <a href="https://templates.blakadder.com/hyleton_333.html">Tasmota Template Repository</a><br>NOTE: a second, third and fourth device will be created for each additional channel.<br>NOTE: Please wait some seconds to allow Tasmota Device to complete reboot.
order:A_04_4base
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
par:ICON;ICON as set, defaults to hue_filled_outlet;{ AttrVal("DEVICE","icon","hue_filled_outlet") }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev",undef)}
par:LONGITUDE;Read longitude set in FHEM;{ AttrVal("global","longitude","8.686")}
par:LATITUDE;Read latitude set in FHEM;{ AttrVal("global","latitude","50.112")}
par:ALTITUDE;Read altitude set in FHEM;{ AttrVal("global","altitude","0")}
par:BUTTONRULE;Suggest Tasmota Button Rule for Power Strip;{ q/rule on button1#state=3 do backlog power1 2; power2 2; power3 2; power4 2 endon on button1#state=2 do backlog power1 1; power2 1; power3; power4 1 endon/ }
par:JSONSUPPRESS;Tasmota reading pairs to suppress;"LedTable:0 SaveData:0 Scheme:0 SetOption26:0 ANALOG_A0:0 Speed:0 StateText1:0 StateText2:0 StateText3:0 StateText4:0 Module:0 Version:0 FallbackTopic:0 GroupTopic:0 WebServerMode:0 Hostname:Hostname RestartReason:0 Time:0 Uptime:0 UptimeSec:0 Heap:0 SleepMode:0 Sleep:0 LoadAvg:0 MqttCount:0 Wifi_AP:0 Wifi_SSId:0 Wifi_BSSId:0 Wifi_Channel:0 Wifi_RSSI:0 Wifi_Signal:0 Wifi_LinkCount:0 Wifi_Downtime:0 subscriptions:0 Status_ButtonRetain:0 Status_ButtonTopic:0 Status_LedMask:0 Status_LedState:0 Status_Module:0 Status_Power:0 Status_PowerOnState:0 Status_PowerRetain:0 Status_SaveData:0 Status_SaveState:0 Status_SensorRetain:0 Status_SwitchMode_1:0 Status_SwitchMode_2:0 Status_SwitchMode_3:0 Status_SwitchMode_4:0 Status_SwitchMode_5:0 Status_SwitchMode_6:0 Status_SwitchMode_7:0 Status_SwitchRetain:0 Status_SwitchTopic:0 Status_Topic:0"
farewell:Template has been applied successfully. Wait some seconds for reboot to complete and watch readings get populated.
# Do some cleanup to eventually rerun apply template process
deletereading -q DEVICE (?!associatedWith).*
# delete DEVICE_CH2
# delete DEVICE_CH3
# delete DEVICE_USB
# prime Tasmota device
set DEVICE attrTemplate tasmota_set_lowercase_texts_and_state1
# additional settings to aid speech recognition to detect capabilities properly
set DEVICE attrTemplate speech_recognition_type_switch
# add some attributes to make your new device looking great
attr DEVICE icon ICON
attr DEVICE comment Admin Info and Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3, and DEVICE_USB
attr DEVICE devStateIcon Online:10px-kreis-gruen Offline:10px-kreis-rot
attr DEVICE event-on-change-reading .*
attr DEVICE stateFormat LWT\
state\
<a href="http://IPAddress" target="_blank">IPAddress</a>
attr DEVICE readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'state_',$JSONMAP) }\
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/STATUS:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER1:.* state\
STATTOPIC/POWER2:.* POWER2\
STATTOPIC/POWER3:.* POWER3\
STATTOPIC/POWER4:.* POWER4\
CMNDTOPIC/POWER:.* POWER
attr DEVICE setList\
off:noArg CMNDTOPIC/POWER1 0\
on:noArg CMNDTOPIC/POWER1 1\
toggle:noArg CMNDTOPIC/POWER1 2\
x_Reboot:noArg CMNDTOPIC/restart 1\
x_Status:noArg CMNDTOPIC/Status\
x_setOtaUrl:http://thehackbox.org/tasmota/release/tasmota-DE.bin CMNDTOPIC/OtaUrl $EVTPART1\
x_upgrade:noArg CMNDTOPIC/upgrade 1\
x_ShowHostname:noArg CMNDTOPIC/Backlog setoption53 1; Status;\
x_DisableBlinkLED:noArg CMNDTOPIC/Backlog LEDPower 0; setoption31 1; Status;\
x_SaveData:0,1 CMNDTOPIC/savedata $EVTPART1\
x_Configuration CMNDTOPIC/$EVTPART1 $EVTPART2\
x_RuleButton:noArg CMNDTOPIC/BUTTONRULE\
x_RuleEnable:noArg CMNDTOPIC/Backlog setoption1 1; setoption32 15; rule1 1\
x_Location:noArg CMNDTOPIC/Backlog Latitude LATITUDE; Longitude LONGITUDE; Altitude ALTITUDE\
x_NTPServer:fritz.box CMNDTOPIC/ntpserver $EVTPART1
# we want state to represent 1st channel.
attr DEVICE jsonMap POWER1:state Dimmer:pct
attr DEVICE userReadings formatedUptime:state_UptimeSec.* { my $m = ReadingsVal($name,"state_UptimeSec",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m }
setreading DEVICE associatedWith DEVICE_CH2,DEVICE_CH3,DEVICE_USB
#
# create devices for 2nd, 3rd and 4th channel
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 setStateList on off toggle
copy DEVICE_CH2 DEVICE_CH3
copy DEVICE_CH2 DEVICE_USB
#
setreading DEVICE_CH2 associatedWith DEVICE,DEVICE_CH3,DEVICE_USB
setreading DEVICE_CH3 associatedWith DEVICE,DEVICE_CH2,DEVICE_USB
setreading DEVICE_USB associatedWith DEVICE,DEVICE_CH2,DEVICE_CH3
# set attributes specific for 3rd channel
attr DEVICE_CH2 comment Channel 2 for DEVICE, see also DEVICE_CH3 and DEVICE_USB
attr DEVICE_CH3 comment Channel 3 for DEVICE, see also DEVICE_CH2 and DEVICE_USB
attr DEVICE_USB comment Channel 4 (USB) for DEVICE, see also DEVICE_CH2 and DEVICE_CH3
#
attr DEVICE_CH2 setList \
off:noArg CMNDTOPIC/POWER2 0\
on:noArg CMNDTOPIC/POWER2 1\
toggle:noArg CMNDTOPIC/POWER2 2
attr DEVICE_CH3 setList \
off:noArg CMNDTOPIC/POWER3 0\
on:noArg CMNDTOPIC/POWER3 1\
toggle:noArg CMNDTOPIC/POWER3 2
attr DEVICE_USB setList \
off:noArg CMNDTOPIC/POWER4 0\
on:noArg CMNDTOPIC/POWER4 1\
toggle:noArg CMNDTOPIC/POWER4 2
#
attr DEVICE_CH2 readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'state_',$JSONMAP) }\
STATTOPIC/STATUS:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER2:.* state
attr DEVICE_CH3 readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'state_',$JSONMAP) }\
STATTOPIC/STATUS:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER3:.* state
attr DEVICE_USB readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'state_',$JSONMAP) }\
STATTOPIC/STATUS:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER4:.* state
#
# we want state to represent 2nd channel.
# keep all POWERx readings to allow period tele/STATE messages to update relay state reading
# Suppress all other readings on split device. These readings are visible on first device only.
# Tasmota version upgrades are likely to add/remove readings. So some unwanted ones may appear on second device after such upgrade
attr DEVICE_CH2 jsonMap POWER2:state POWER1:0 POWER3:0 POWER4:0 POWER5:0 JSONSUPPRESS
#
# we want state to represent 3rd channel.
attr DEVICE_CH3 jsonMap POWER3:state POWER1:0 POWER2:0 POWER4:0 POWER5:0 JSONSUPPRESS
#
# we want state to represent 4th (USB) channel.
attr DEVICE_USB jsonMap POWER4:state POWER1:0 POWER2:0 POWER3:0 POWER5:0 JSONSUPPRESS
# USB channel gets a unique icon
attr DEVICE_USB icon rc_USB
#finally set the model attr for all new devices and do a reboot of device
attr DEVICE,DEVICE_CH2,DEVICE_CH3,DEVICE_USB model tasmota_3socketUSB_channel_split
set IO_DEV publish CMNDTOPIC/status
set IO_DEV publish CMNDTOPIC/restart 1
#
Sehr cool! Kommt auf jeden Fall mit dem nächsten update :) !
Gedanken muß ich mir noch machen zu
- der Einbindung in die Sprachsteuerungstemplates. Die Namensvergabe (betr. alexa) ist sehr neu und muß wohl pro Kanal gemacht werden, siehe dieser Thread (https://forum.fhem.de/index.php/topic,108999.0/topicseen.html); da müssen wir vermutlich insgesamt bei allen mehrkanaligen Devices nochmal nacharbeiten;
- dem widget für x_NTPServer. Tendiere zu "x_NTPServer:multiple,fritz.box"
- dem weiteren reboot am Ende. Eigentlich wäre das wohl eine Sache, die für alle Tasmota-(End-)Templates Sinn macht, wenn man erst die readings gelöscht hatte. Oder reicht da das mit der status-Anforderung...? (Muß wohl mal testen).
Zitat von: Beta-User am 11 März 2020, 15:02:56
- dem widget für x_NTPServer. Tendiere zu "x_NTPServer:multiple,fritz.box"
- dem weiteren reboot am Ende. Eigentlich wäre das wohl eine Sache, die für alle Tasmota-(End-)Templates Sinn macht, wenn man erst die readings gelöscht hatte. Oder reicht da das mit der status-Anforderung...? (Muß wohl mal testen).
Danke für deine konstruktive Rückmeldung.
Das mit der multiple Angabe in einem Widget kannte ich bisher noch nicht. Ist definitiv zielführender und passt auch zu x_SetOtaUrl.
Die Anwendung des Templates ruft zwar zwei weitere Templates auf, aber es sollte genau nur ein reboot am Ende ausgelöst werden.
Nur der reboot füllt das reading LWT, daher ist die status Anforderung alleine nicht ausreichend.
Bei dieser Gelegenheit möchte ich ein weiteres Template für 5 Kanal Mehrfach Steckdosenleisten vorstellen.
Es baut auf das tasmota_3socketUSB_split Template auf.
# 5-way multi socket 4AC+USB device flashed with Tasmota.
# Tested with Koogeek KLOE4 Power Strip, please see <a href="https://templates.blakadder.com/koogeek_kloe4.html">Tasmota Template Repository</a>
name:tasmota_4socketUSB_split
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:5 channel device flashed with Tasmota. <br>NOTE: Tested with 5-way Koogeek KLOE4 Power Strip, please see <a href="https://templates.blakadder.com/koogeek_kloe4.html">Tasmota Template Repository</a><br>NOTE: a second, third, fourth and fifth device will be created for each additional channel.<br>NOTE: Please wait some seconds after apply to have Tasmota device to complete restart.
order:A_01_5base
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
par:ICON;ICON as set, defaults to hue_filled_outlet;{ AttrVal("DEVICE","icon","hue_filled_outlet") }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev",undef)}
par:LONGITUDE;Read longitude set in FHEM;{ AttrVal("global","longitude","8.686")}
par:LATITUDE;Read latitude set in FHEM;{ AttrVal("global","latitude","50.112")}
par:ALTITUDE;Read altitude set in FHEM;{ AttrVal("global","altitude","0")}
par:BUTTONRULE;Suggest Tasmota Button Rule for Power Strip;{ q/rule on button1#state=3 do backlog power1 2; power2 2; power3 2; power4 2; power5 2 endon on button1#state=2 do backlog power1 1; power2 1; power3 1; power4 1; power5 1 endon/ }
par:JSONSUPPRESS;Tasmota reading pairs to suppress;"LedTable:0 SaveData:0 Scheme:0 SetOption26:0 ANALOG_A0:0 Speed:0 StateText1:0 StateText2:0 StateText3:0 StateText4:0 Module:0 Version:0 FallbackTopic:0 GroupTopic:0 WebServerMode:0 Hostname:0 RestartReason:0 Time:0 Uptime:0 UptimeSec:0 Heap:0 SleepMode:0 Sleep:0 LoadAvg:0 MqttCount:0 Wifi_AP:0 Wifi_SSId:0 Wifi_BSSId:0 Wifi_Channel:0 Wifi_RSSI:0 Wifi_Signal:0 Wifi_LinkCount:0 Wifi_Downtime:0 subscriptions:0 Status_ButtonRetain:0 Status_ButtonTopic:0 Status_LedMask:0 Status_LedState:0 Status_Module:0 Status_Power:0 Status_PowerOnState:0 Status_PowerRetain:0 Status_SaveData:0 Status_SaveState:0 Status_SensorRetain:0 Status_SwitchMode_1:0 Status_SwitchMode_2:0 Status_SwitchMode_3:0 Status_SwitchMode_4:0 Status_SwitchMode_5:0 Status_SwitchMode_6:0 Status_SwitchMode_7:0 Status_SwitchRetain:0 Status_SwitchTopic:0 Status_Topic:0"
farewell:Template has been applied successfully. Wait some seconds for reboot to complete and watch readings get populated.
# Do some cleanup to eventually rerun apply template process
deletereading -q DEVICE (?!associatedWith).*
delete DEVICE_CH4
# reuse 3socketUSB template to create 4 out of 5 devices ...
set DEVICE attrTemplate tasmota_3socketUSB_split
# ... and add a 5th device, USB socket moves from channel 4 to channel 5
copy DEVICE_CH2 DEVICE_CH4
#
# re-arrange DEVICE, DEVICE_CH2, DEVICE_CH3, DEVICE_USB from 3socket template
setreading DEVICE associatedWith DEVICE_CH2,DEVICE_CH3,DEVICE_CH4,DEVICE_USB
setreading DEVICE_CH2 associatedWith DEVICE,DEVICE_CH3,DEVICE_CH4,DEVICE_USB
setreading DEVICE_CH3 associatedWith DEVICE,DEVICE_CH2,DEVICE_CH4,DEVICE_USB
setreading DEVICE_CH4 associatedWith DEVICE,DEVICE_CH2,DEVICE_CH3,DEVICE_USB
setreading DEVICE_USB associatedWith DEVICE,DEVICE_CH2,DEVICE_CH3,DEVICE_CH4
#
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3, DEVICE_CH4 and DEVICE_USB
attr DEVICE_CH2 comment Channel 2 for DEVICE, see also DEVICE_CH3, DEVICE_CH4 and DEVICE_USB
attr DEVICE_CH3 comment Channel 3 for DEVICE, see also DEVICE_CH2, DEVICE_CH4 and DEVICE_USB
attr DEVICE_CH4 comment Channel 4 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_USB
attr DEVICE_USB comment Channel 5 (USB) for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
# setlist looks the same for 3socketUSB and 4socketUSB but differs in PARameter BUTTONRULE
attr DEVICE setList\
off:noArg CMNDTOPIC/POWER1 0\
on:noArg CMNDTOPIC/POWER1 1\
toggle:noArg CMNDTOPIC/POWER1 2\
x_Reboot:noArg CMNDTOPIC/restart 1\
x_Status:noArg CMNDTOPIC/Status\
x_setOtaUrl:multiple,http://thehackbox.org/tasmota/release/tasmota-DE.bin CMNDTOPIC/OtaUrl $EVTPART1\
x_upgrade:noArg CMNDTOPIC/upgrade 1\
x_ShowHostname:noArg CMNDTOPIC/Backlog setoption53 1; Status;\
x_DisableBlinkLED:noArg CMNDTOPIC/Backlog LEDPower 0; setoption31 1; Status;\
x_SaveData:0,1 CMNDTOPIC/savedata $EVTPART1\
x_Configuration CMNDTOPIC/$EVTPART1 $EVTPART2\
x_RuleButton:noArg CMNDTOPIC/BUTTONRULE\
x_RuleEnable:noArg CMNDTOPIC/backlog setoption1 1; setoption32 15; rule1 1\
x_Location:noArg CMNDTOPIC/Backlog Latitude LATITUDE; Longitude LONGITUDE; Altitude ALTITUDE\
x_NTPServer:multiple,fritz.box CMNDTOPIC/ntpserver $EVTPART1
#
# move DEVICE_USB from channel 4 to channel 5
attr DEVICE_CH4 setList \
off:noArg CMNDTOPIC/POWER4 0\
on:noArg CMNDTOPIC/POWER4 1\
toggle:noArg CMNDTOPIC/POWER4 2
attr DEVICE_USB setList \
off:noArg CMNDTOPIC/POWER5 0\
on:noArg CMNDTOPIC/POWER5 1\
toggle:noArg CMNDTOPIC/POWER5 2
attr DEVICE readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'state_',$JSONMAP) }\
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/STATUS:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER1:.* state\
STATTOPIC/POWER2:.* POWER2\
STATTOPIC/POWER3:.* POWER3\
STATTOPIC/POWER4:.* POWER4\
STATTOPIC/POWER5:.* POWER5\
CMNDTOPIC/POWER:.* POWER
attr DEVICE_CH4 readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'state_',$JSONMAP) }\
STATTOPIC/STATUS:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER4:.* state
attr DEVICE_USB readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'state_',$JSONMAP) }\
STATTOPIC/STATUS:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER5:.* state
attr DEVICE_CH4 jsonMap POWER4:state POWER1:0 POWER2:0 POWER3:0 POWER5:0 JSONSUPPRESS
attr DEVICE_USB jsonMap POWER5:state POWER1:0 POWER2:0 POWER3:0 POWER4:0 JSONSUPPRESS
attr DEVICE_CH4 userReadings formatedUptime:state_UptimeSec.* { my $m = ReadingsVal($name,"state_UptimeSec",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m }
attr DEVICE_USB userReadings formatedUptime:state_UptimeSec.* { my $m = ReadingsVal($name,"state_UptimeSec",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m }
#
#finally set the model attr for all new devices and do a reboot of device
attr DEVICE,DEVICE_CH2,DEVICE_CH3,DEVICE_CH4,DEVICE_USB model tasmota_4socketUSB_split
set IO_DEV publish CMNDTOPIC/status
set IO_DEV publish CMNDTOPIC/restart 1
#
Wow!
Ähm, eigentlich bin ich zu müde, um da intensiv genug nachzudenken, daher kurz und evtl. fehlerhaft:
- multiple kannte ich vorher auch nicht bzw. habe das nicht bewußt wahrgenommen ;D ...
- bin irgendwie geneigt, aus diesen beiden templates (und dem "alten" 4-channel) dann 3 bzw 4 templates zu generieren bzw. das ganze (alle Tasmota-templates) irgendwie so aufzudröseln, dass es einen "allgemeinen Tasmota-Start" gibt (as is, aber eventuell dann etwas anders), einen Mittelteil, in dem sich die betreffenden templates teils wechselseitig aufrufen können, aber ohne dass jedesmal ein farewell gezeigt wird bzw. ein reboot ausgelöst, und einen "allgemeinen Tasmota-Ende-Teil", der den reboot anschubst und das farewell zeigt (das kam bisher nur, wenn es weitere Hinweise an den Nutzer gab, aber eigentlich ist es ganz nett, wenn man die Rückmeldung bekommt, dass alles "normal durchgelaufen" ist.
(Falls du das verstehen solltest und Vorschläge hast: gerne - dann aber besser in dem Tasmota-Thead oder ganz gesondert.)
Hallo zusammen
Ich bin kein Entwickler, aber überlege von mqtt auf mqtt2 umzustellen.
Gibt es schon ein template fur den 3EM? Kann dazu nichts finden.
Danke und Entschuldigung wenn es hier falsch eingestellt ist
Ist hier in der Tat falsch:
Zitat von: Beta-User am 15 Dezember 2018, 11:45:40
Für Fehlermeldungen, Diskussionen zu Verbesserungsvorschlägen zu vorhandenen und zum Anfragen von support für neue Devices ist ein weiterer Thread (https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200) gedacht, dieser hier sollte möglichst übersichtlich bleiben und sich auf das Wesentliche beschränken.
Ich habe hier (https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200) noch ein paar Hinweise reingebastelt, was ggf. hilfreich wäre; wenn du das gleich als separaten Post hier im Forumsbereich MQTT mit deisen Infos aufmachst, werde ich es sehen, du brauchst es nicht nochmal im anderen Thread (oder hier) verlinken.
Habe für den Shelly Door/Window Sensor das folgende Template erzeugt:
# shellydoorwindow using original firmware
name:shellydoorwindow
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:Shelly Door Window sensor using original firmware <br>Tested with firmware 20200408-085810/v1.6.5@b075f0bf
order:A_19
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE readingList \
shellies/DEVNAME/sensor/state:.* state\
shellies/DEVNAME/sensor/tilt:.* tilt\
shellies/DEVNAME/sensor/vibration:.* vibration\
shellies/DEVNAME/sensor/battery:.* battery\
shellies/DEVNAME/sensor/lux:.* lux\
shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : return }
attr DEVICE devStateIcon open:fts_door_open@red close:fts_door@green
Hallo KurtK,
Danke für den Vorschlag, das hat sich etwas überschnitten: just vorgestern hatte majestro84 hier was unter dem Kürzel "dw" geliefert: https://forum.fhem.de/index.php/topic,94060.msg1054466.html#msg1054466
Das wertet dann tilt+state (umgeleitet zu doorWindow) insgesamt aus und ist seit gestern bereits via update verfügbar.
Evtl. wäre aber die Frage, ob der immer als three-state genutzt wird, sonst könnten/sollten ggf. zwei templates dafür aufgenommen werden?
Anwort dazu bitte im anderen Thread.
Für die Shelly Duo habe ich folgendes Template erzeugt:
# shellyduo using original firmware
name:shellyduo
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:Shelly Duo using original firmware <br>Tested with firmware 20200320-123338/v1.6.2@514044b4 <br> based on shellybulb and shelliergbw2 template
order:A_15a
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
par:ICON;ICON as set, defaults to light_control;{ AttrVal("DEVICE","icon","light_control") }
attr DEVICE icon ICON
attr DEVICE setList\
off:noArg shellies/DEVNAME/light/0/command off\
on:noArg shellies/DEVNAME/light/0/command on\
pct:colorpicker,BRI,0,1,100 shellies/DEVNAME/light/0/set {"gain":"$EVTPART1","brightness":"$EVTPART1"}\
pct_on:colorpicker,BRI,0,1,100 shellies/DEVNAME/light/0/set {"turn":"on","gain":"$EVTPART1","brightness":"$EVTPART1"}\
ct:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);"shellies/DEVNAME/light/0/set {\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}\
ct_on:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);"shellies/DEVNAME/light/0/set {\"turn\":\"on\",\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}\
x_update:noArg shellies/DEVNAME/command update_fw\
x_mqttcom shellies/DEVNAME/command $EVTPART1
deletereading -q DEVICE status_.*
attr DEVICE readingList\
shellies/DEVNAME/light/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
shellies/DEVNAME/light/0/power:.* power\
shellies/DEVNAME/light/0/energy:.* energy\
shellies/DEVNAME/light/0:.* state\
shellies/DEVNAME/online:.* online\
shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : return }
attr DEVICE userReadings ct:temp.* {ReadingsVal($name,"temp",3000)}
attr DEVICE webCmd on:off:pct:ct
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"power","unknown");; "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch: $cons</div>"}
#attr DEVICE genericDeviceType light
attr DEVICE jsonMap brightness:pct
set DEVICE x_mqttcom announce
set DEVICE attrTemplate speechcontrol_type_light
attr DEVICE model shellyduo
Thx, hab's eben eingecheckt und auch einen kurzen Kommentar in die desc. zu dem two/three-State-Thema reingenommen.
Habe für den IKEA SYMFONSIK sound controller folgendes Template erstellt
# SYMFONSIK sound controller
name:zigbee2mqtt_symfonsik_sound_controller
desc: IKEA SYMFONSIK sound controller via zigbee2mqtt <br>Tested with: IKEA E1744 SYMFONSIK sound controller
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_16
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).+, ? $1 : undef }
par:ICON;ICON as set, defaults to it_remote;{ AttrVal("DEVICE","icon","it_remote") }
attr DEVICE icon ICON
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE stateFormat Action: action Volume: volume Batterie: battery %
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT) }
attr DEVICE model SYMFONISK sound controller
attr DEVICE userReadings volume:brightness.* {int(ReadingsVal($name,"brightness",10)/2.55)}
deletereading -q DEVICE (?!associatedWith).*
Ist der wie der licht kontroler, auch Batterie betrieben? Wie kommen deine events sauber rein? Auf den Bildern sieht der aus als würde er genauso funktionieren... Wenn ja würde ich dein template auf meinen umbauen ... Bei mir sind die events nur noch nicht sauber. Ab und an reagiert er, ab und an nicht usw. Das sogar direkt am conbee2. Der BWM zb reagiert mir eigentlich auch zu träge. Hab das Gefühl er liefert sauber Bewegung true/false aber nicht direkt sondern im Intervall. Das finde ich echt bescheiden.
Gesendet von meinem LM-G810 mit Tapatalk
Ähm, bitte keine Fachsimpeleien zu speziellen Device hier in diesem Thread! (Ich finde das auch interessant und würde mich für ein list interessieren bzw. was das Ding sonst an Events bringt; evtl. kann man da auch "Remote-Code" anflanschen, der etwas weniger "speziell" ist wie das MiLight-Ding: https://forum.fhem.de/index.php/topic,103493.0.html; aber bitte ggf. einfach einen separaten Thread aufmachen!)
Zur Sache an sich:
@KurtK: Was volume angeht, gehe ich mal davon aus, dass es die übliche Hex (=255) zu 100%-Umrechnung ist. Dann wäre vermutlich das hier passender:
int(ReadingsVal($name,"brightness",10)/2.55)
Sorry aber es passte so gut. Ich verstehe nicht warum man das Gespräch nicht hier führen kann, es passt hier hin... Und am Ende einfach in einen anderen Thread mit Link verschoben werden kann. Oder an OP muss das übernehmen. Normal würde ich auf deiner seite sein aber man findet hier bald nichts mehr wenn man nicht genau weiß wo man genau was hin geschrieben hat. Ich hangel mich ab und an über Profil>eigene Beiträge>scrolle ewig bis ich gefunden habey was ich wollte.... Weil es über die Suche nicht findbar ist. Ich finde die Funktionen des Forums sind wie Lotus Notes. Viele große Firmen nutzen es, 90% der Mitarbeiter wünschen sich ein anderes Mail Programm :-P
Spaß bei seite und auch das genörgel :)
Die Umrechnung "int" zu machen und nicht in einem extra reading, kannte ich auch noch nicht. Danke! Hab sowas bisher immer in ein anderes gesetzt aber genau wie du umgerechnet. Bei den meisten Geräten war es aber gut diesen Wert sowohl als pct als auch als helligkeitswert zu haben.
Gesendet von meinem LM-G810 mit Tapatalk
Zitat von: 87insane am 22 Mai 2020, 16:05:43
Ich verstehe nicht warum man das Gespräch nicht hier führen kann, es passt hier hin...
Weil dieser Thread
a) meiner ist (es ergo einfach höflich ist, meinen klar geäußerten Wunsch auch zu beherzigen) und
b) ausdrücklich einen anderen Zweck hat wie (längere) Diskussionen (siehe ersten Post!).
ZitatDie Umrechnung "int" zu machen und nicht in einem extra reading, kannte ich auch noch nicht. Danke! Hab sowas bisher immer in ein anderes gesetzt aber genau wie du umgerechnet. Bei den meisten Geräten war es aber gut diesen Wert sowohl als pct als auch als helligkeitswert zu haben.
Das wird schon ein anderes (user-) Reading namens volume, es wird halt auf andere Art gerundet (int statt sprintf). Aber falls ich da was neues lernen kann: nur zu).
HIER aber bitte direkt in funktionierender attrTemplate-Form ;) !
@ Beta-User:
Da hast du Recht, sollte die normale Umwandlung sein. Habe es in meinem Template mal angepasst. Kannte ich vorher auch nicht.
Den List zum Controller und ne Liste mit den möglichen Actions stell ich in das zigbee2mqtt-template Thema, sobald ich ein bisschen mehr Zeit hab.
...und damit ist dieses template das erste, das eine "richtige Version" bekommt :) :
setreading DEVICE attrTemplateVersion 20200522
(siehe https://forum.fhem.de/index.php/topic,98880.msg1056499.html#msg1056499; Rückmeldungen dazu ggf. bitte in dem "Anregungen"-Thread)
Hier mal was für die Helligkeit :) Xiaomi MiJia light intensity sensor GZCGQ01LM
name:zigbee2mqtt_Light_Intensity_Sensor
desc: Light Intensity Sensor via zigbee2mqtt <br>Tested with: Xiaomi MiJia light intensity sensor GZCGQ01LM
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_08
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).+, ? $1 : undef }
par:ICON;ICON as set, defaults to weather_sun;{ AttrVal("DEVICE","icon","weather_sun") }
attr DEVICE icon ICON
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE stateFormat Lux: illuminance_lux Luminance: illuminance
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT) }
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model zigbee2mqtt_Light_Intensity_Sensor
setreading DEVICE attrTemplateVersion 20200522 or prior
:) ...und drin, THX!
Ich habe mal ein funktionales Template für sonos2mqtt gemacht.
Es ist sind soweit die wichtigsten Steuerbefehle drin, die drin sind habe ich alle getestet.
Damit man die anderen Befehle einfach testen kann, habe ich set payload eingebaut. Da kommt einfach der komplette Json rein den man übertragen will.
Es wirklich so getestet, die Anzahl der ; stimmt :)
Du musst nur attrTemplateVersion anpassen :)
name:sonos2mqtt_speaker
desc:A sonos2mqtt speaker device
filter:TYPE=MQTT2_DEVICE
order:M_05a
par:BASE_TOPIC;base topic set in configuration.yaml of the sonos2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^\/:]+)[\/].+, ? $1 : undef }
par:DEV_ID;techname of the device ;{ AttrVal("DEVICE","readingList","") =~ m,[^\/]+[\/](RINCON_[0-9A-Z]+):.*, ? $1 : undef }
par:ALIAS;friendly name as set in sonos gadget itself;{ ReadingsVal("DEVICE","name","unknown") }
par:DEVNAME;friendly name, used for topic in lowercase;{ lc(ReadingsVal("DEVICE","name","unknown")) }
par:ICON;ICON as set, defaults to audio_volume_low;{ AttrVal("DEVICE","icon","audio_volume_low") }
attr DEVICE icon ICON
attr DEVICE jsonMap volume_Master:volume mute_Master:mute transportState:state
attr DEVICE readingList\
BASE_TOPIC/status/DEVNAME/avtransport:.* { json2nameValue($EVENT,'AV_',$JSONMAP) }\
BASE_TOPIC/status/DEVNAME/renderingcontrol:.* { json2nameValue($EVENT,'REND_',$JSONMAP) }\
BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE setList\
stop:noArg BASE_TOPIC/DEV_ID/control { "command": "stop" }\
play:noArg BASE_TOPIC/DEV_ID/control { "command": "play" }\
pause:noArg BASE_TOPIC/DEV_ID/control { "command": "pause" }\
toggle:noArg BASE_TOPIC/DEV_ID/control { "command": "toggle" }\
volumeup:noArg BASE_TOPIC/DEV_ID/control { "command": "volumeup" }\
volumedown:noArg BASE_TOPIC/DEV_ID/control { "command": "volumedown" }\
switchToQueue:noArg BASE_TOPIC/DEV_ID/control { "command": "switchtoqueue" }\
switchToTv:noArg BASE_TOPIC/DEV_ID/control { "command": "switchtotv" }\
switchToLine:noArg BASE_TOPIC/DEV_ID/control { "command": "switchtoline" }\
volume:slider,0,1,100 BASE_TOPIC/DEV_ID/control { "command": "volume", "input": $EVTPART1 }\
mute:on,off { my $value = $EVTPART1 eq "on" ? "mute" : "unmute"; qq(BASE_TOPIC/DEV_ID/control { "command": "$value" } ) }\
next:noArg BASE_TOPIC/DEV_ID/control { "command": "next" }\
previous:noArg BASE_TOPIC/DEV_ID/control { "command": "previous" }\
payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //g; qq(BASE_TOPIC/DEV_ID/control $payload)}\
joinGroup:textField BASE_TOPIC/DEV_ID/control { "command": "joingroup", "input": "$EVTPART1"}\
leaveGroup:noArg { my $value = ReadingsVal("DEV_ID","groupName","all"); qq(BASE_TOPIC/DEV_ID/control { "command": "leavegroup", "input": "$value" } ) }\
setAVTUri:textField BASE_TOPIC/DEV_ID/control { "command": "setavtransporturi", "input": "$EVTPART1"}\
notify:textField BASE_TOPIC/DEV_ID/control { "command":"notify","input":{"trackUri":"$EVTPART2","onlyWhenPlaying":false,"timeout":10,"volume":$EVTPART1,"delayMs":700}}
attr DEVICE model sonos2mqtt_speaker
attr DEVICE alias ALIAS
setreading DEVICE attrTemplateVersion 20200606
Gruß Otto
Aus diesem Thread (https://forum.fhem.de/index.php/topic,99343.msg1038229.html#msg1038229) heraus ist mal noch ein Template entstanden.
Hier wird die worx landroid cloud direkt per MQTT2_CLIENT angebunden. Dieses Template konfiguriert das Mower Device.
Ich mach später noch einen separaten Thread im MQTT Board.
name:worx_landroid
desc:a Worx Landroid mower
filter:TYPE=MQTT2_DEVICE
order:M_05c
par:BASE_TOPIC;base topic: the Mower BoardID (2019: PRM100);{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^\/:]+)[\/].+, ? $1 : undef }
par:DEV_ID;the MAC of the Mower (Device Info);{ AttrVal("DEVICE","readingList","") =~ m,[^\/]+[\/]([0-9A-Z]+)[\/]commandOut:.*, ? $1 : undef }
par:ICON;ICON as set, defaults to audio_volume_low;{ AttrVal("DEVICE","icon","scene_robo_lawnmower") }
attr DEVICE icon ICON
attr DEVICE readingList BASE_TOPIC/DEV_ID/commandOut:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE model worx_landroid_mover
attr DEVICE jsonMap dat_rsi:wifiQuality dat_fw:firmware cfg_sn:SerialNumber\
dat_le:mowerErrorIndex dat_ls:mowerStatusIndex\
cfg_rd:mowerRainDelay cfg_sc_m:mowerActiveIndex cfg_sc_p:mowerTimeCorrection\
dat_bt_t:batteryTemperature dat_bt_v:batteryVoltage dat_bt_p:batteryLevel dat_bt_nr:batteryChargeCycle dat_bt_c:batteryCharging\
dat_st_b:bladeTimeCounter dat_st_d:totalDistance dat_st_wt:totalTime\
dat_dmp_1:directionPitch dat_dmp_2:directionRoll dat_dmp_3:directionYaw
attr DEVICE setList mowerRainDelay:slider,0,30,1440 BASE_TOPIC/DEV_ID/commandIn {"rd":$EVTPART1}\
mowerTimeCorrection:slider,-100,1,100 BASE_TOPIC/DEV_ID/commandIn {"sc":{"p":$EVTPART1}}\
startMower:noArg BASE_TOPIC/DEV_ID/commandIn {"cmd":1}\
pauseMower:noArg BASE_TOPIC/DEV_ID/commandIn {"cmd":2}\
stopMower:noArg BASE_TOPIC/DEV_ID/commandIn {"cmd":3}
attr DEVICE userReadings mowerActive {ReadingsVal($name,"mowerActiveIndex","0") ? "true" : "false"},\
mowerStatusTxt {my %stateCodes = (\
0 => "Idle",\
1 => "Home",\
2 => "Start sequence",\
3 => "Leaving home",\
4 => "Follow wire",\
5 => "Searching home",\
6 => "Searching wire",\
7 => "Mowing",\
8 => "Lifted",\
9 => "Trapped",\
10 => "Blade blocked",\
11 => "Debug",\
12 => "Remote control",\
30 => "Going home",\
31 => "Zone Training",\
32 => "Edge cutting",\
33 => "Searching zone",\
34 => "Pause"\
); $stateCodes{ReadingsVal($name,"mowerStatusIndex","0")}},\
mowerErrorTxt { my %errorCodes = (\
0 => "No error",\
1 => "Trapped",\
2 => "Lifted",\
3 => "Wire missing",\
4 => "Outside wire",\
5 => "Raining",\
6 => "Close door to mow",\
7 => "Close door to go home",\
8 => "Blade motor blocked",\
9 => "Wheel motor blocked",\
10 => "Trapped timeout",\
11 => "Upside down",\
12 => "Battery low",\
13 => "Reverse wire",\
14 => "Charge error",\
15 => "Timeout finding home",\
16 => "Mower locked",\
17 => "Battery temp out of range"\
); $errorCodes{ReadingsVal($name,"mowerErrorIndex","0")}}
setreading DEVICE attrTemplateVersion 20200607
Hi Otto,
vorab mal Danke!
Ein paar Kleinigkeiten habe ich jeweils noch geändert. Kann's grade nicht im Detail erläutern, falls Fragen sind oder was nicht funktioniert, bitte melden.
(Den sonos dann noch für Spracherkennung zu erweitern, wäre evtl. noch so eine Sache von allg. Relevanz)...
Ja! Damit würde ich sogar das Modul ablösen. Ich brauche zu 99% nur speak. Okay usw mache ich so gut wie nie über das Modul weil die App einfach schneller ist. Oder gar in den Sonos one die integrierte alexa. Im sonos2mqtt Thread hatte ich das schon mal erwähnt. Was mir nicht ganz klar ist wo wir die sprach Synthese am besten her nehmen. Ich würde gut im Sonos Modul abgucken. Denn die attr die man dazu setzen muss kommen mir schon verdächtig gleich vor.
Gesendet von meinem LM-G810 mit Tapatalk
Sorry, war ungenau: Sprachsteuerung, nicht Sprachausgabe (was aber auch ein interessanter Aspekt wäre).
Details dazu bitte aber NICHT HIER, sondern in dem Sonos-Thread!
Eine logistische Frage: War ist richtig so die Templates hier einzureichen? Oder besser: wenn es schon einen "Entwicklungsthread" gibt es einfach dort zu belassen (damit die Diskussion nicht gesplittet werden)?
Gruß Otto
Ich persönlich finde das übergreifen nicht schlecht. So kam die Vereinheitlichung ja eigentlich zu Stande.
Anders rum genügt wohl meist auch ein link mit kleiner Info.
Gesendet von meinem LM-G810 mit Tapatalk
Zitat von: Beta-User am 15 Dezember 2018, 11:45:40
Bitte nutzt möglichst diesen Thread, wenn ihr neue (im Prinzip ausentwickelte) templates für mqtt2.template vorschlagen wollt.
Für Fehlermeldungen, Diskussionen zu Verbesserungsvorschlägen zu vorhandenen und zum Anfragen von support für neue Devices [...]
Ergo paßte das mit dem landroiden auf alle Fälle hierher;
bei dem Sonos kann man streiten, aber das ist auch schon recht weit gediehen. Da du sowieso hier gepostet hattest, was es völlig ok, es wäre aber genausogut in dem anderen Thread aufgehoben gewesen (ich lese da ja auch mit, s.u.).
Mit der einleitenden Bemerkung ist es so:
1. Wer hier postet oder mitliest, will evtl. nicht mit allen Details (und irgendwelchen Meinungen zu diesem und jenem :P ) behelligt werden, sondern einfach wissen, was es neues gibt - eine Art "announcement"-Thread eben.
2. Ansonsten will ich möglichst nicht alles irgendwo mühsam zusammensuchen/erraten müssen, sondern einen Ort haben, wo man mich gezielt dazu erreicht. Gibt's bereits anderweitig eine Diskussion bzw. noch offene Punkte, ist es meistens dort besser aufgehoben, weil es dann auch die anderen beteiligten User leichter finden.
(Deswegen beschränke ich meine eigenen Anmerkungen meistens hier auch auf das nötigste, gebe Hinweise+Links, wo ggf. weiter verfeinert werden wird und "verhaue" User, die die Eingangsbemerkung nicht beachten und dazwischenquatschen...)
Hallo Beta-User,
Betrifft worx.landroid Template
Kannst Du bitte noch die Zeile "Entwicklungshilfe" ins Template einbauen:
x_raw_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //g; qq(BASE_TOPIC/DEV_ID/commandIn $payload)}
Gruß Otto
Wird gemacht (ist hier aber genauso OT wie meine Rückfrage, ob es vor deinem Urlaub noch einen Zwischenstand zum sonos-Speaker gibt...? Ggf. würde ich TomLee's devStateIcon ohne slider mal einbauen...? Antwort bitte dort ;) )
Hallo Zusammen,
anbei ein erstes Template für die Instar Kameras (getestet mit der Instar 8015 HD).
Ich weiß nicht ob es sinnvoll ist, ein Template für Instar allgemein zu machen oder für die einzelnen Modeltypen.
Was hier noch nicht funktioniert, ist "alarmsignal" ein/ausschalten. Die Message an sich funktioniert und die Kamera liefert per MQTT auch den korrekten Wert zurück, jedoch schaltet sie nicht. Führe ich den gleichen Befehl per MQTT.fx oder per MQTT2_SERVER aus, klappt es prima.
# Instar 8015HD.
name:InstarCam
filter:TYPE=MQTT2_DEVICE
desc:for Instar Camera
par:DEVNAME;MAC address in the topic;{ AttrVal("DEVICE","readingList","") =~ m,instar/([^/]*)/, ? $1 : undef }
attr DEVICE eventMap 0:off 1:on
attr DEVICE jsonMap area1val:area1\
area1sensitivityval:area1sensitivity\
area2val:area2\
area2sensitivityval:area2sensitivity\
area3val:area3\
area3sensitivityval:area3sensitivity\
area4val:area4\
area4sensitivityval:area4sensitivity\
pirval:pir\
alarmserverval:alarmserver\
alarmserveraddressval:alarmserveraddress\
alarmserverportval:alarmserverport\
alarmserverpathval:alarmserverpath\
alarmsignalval:alarmsignal\
audioalarmval:audioalarm\
audioalarmsensitivityval:audioalarmsensitivity\
power_ledval:power_led\
wifi_ledval:wifi_led
attr DEVICE readingList instar/DEVNAME/status/alarm/actions/pir/enable:.* { json2nameValue($EVENT, 'pir', $JSONMAP) }\
instar/DEVNAME/status/alarm/area1/enable:.* { json2nameValue($EVENT, 'area1', $JSONMAP) }\
instar/DEVNAME/status/alarm/area1/sensitivity:.* { json2nameValue($EVENT, 'area1sensitivity', $JSONMAP) }\
instar/DEVNAME/status/alarm/area2/enable:.* { json2nameValue($EVENT, 'area2', $JSONMAP) }\
instar/DEVNAME/status/alarm/area2/sensitivity:.* { json2nameValue($EVENT, 'area2sensitivity', $JSONMAP) }\
instar/DEVNAME/status/alarm/area3/enable:.* { json2nameValue($EVENT, 'area3', $JSONMAP) }\
instar/DEVNAME/status/alarm/area3/sensitivity:.* { json2nameValue($EVENT, 'area3sensitivity', $JSONMAP) }\
instar/DEVNAME/status/alarm/area4/enable:.* { json2nameValue($EVENT, 'area4', $JSONMAP) }\
instar/DEVNAME/status/alarm/area4/sensitivity:.* { json2nameValue($EVENT, 'area4sensitivity', $JSONMAP) }\
instar/DEVNAME/status/alarm/alarmserver/enable:.* { json2nameValue($EVENT, 'alarmserver', $JSONMAP) }\
instar/DEVNAME/status/alarm/alarmserver/address:.* { json2nameValue($EVENT, 'alarmserveraddress', $JSONMAP) }\
instar/DEVNAME/status/alarm/alarmserver/port:.* { json2nameValue($EVENT, 'alarmserverport', $JSONMAP) }\
instar/DEVNAME/status/alarm/alarmserver/path:.* { json2nameValue($EVENT, 'alarmserverpath', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/alarmsignal:.* { json2nameValue($EVENT, 'alarmsignal', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/audioalarm:.* { json2nameValue($EVENT, 'audioalarm', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/audioalarmsensitivity:.* { json2nameValue($EVENT, 'audioalarmsensitivity', $JSONMAP) }\
instar/DEVNAME/status/features/indicator/power:.* { json2nameValue($EVENT, 'power_led', $JSONMAP) }\
instar/DEVNAME/status/features/indicator/wifi:.* { json2nameValue($EVENT, 'wifi_led', $JSONMAP) }
attr DEVICE setList pir:on,off instar/DEVNAME/alarm/actions/pir/enable/raw $EVTPART1\
area1:on,off instar/DEVNAME/alarm/area1/enable/raw $EVTPART1\
area1sensitivity:slider,1,1,100 instar/DEVNAME/alarm/area1/sensitivity/raw $EVTPART1\
area2:on,off instar/DEVNAME/alarm/area2/enable/raw $EVTPART1\
area2sensitivity:slider,1,1,100 instar/DEVNAME/alarm/area2/sensitivity/raw $EVTPART1\
area3:on,off instar/DEVNAME/alarm/area3/enable/raw $EVTPART1\
area3sensitivity:slider,1,1,100 instar/DEVNAME/alarm/area3/sensitivity/raw $EVTPART1\
area4:on,off instar/DEVNAME/alarm/area4/enable/raw $EVTPART1\
area4sensitivity:slider,1,1,100 instar/DEVNAME/alarm/area4/sensitivity/raw $EVTPART1\
alarmserver:on,off instar/DEVNAME/alarm/alarmserver/enable/raw $EVTPART1\
alarmsignal:on,off instar/DEVNAME/alarm/actions/alarmsignal/raw $EVTPART1\
audioalarm:on,off instar/DEVNAME/alarm/actions/audioalarm/raw $EVTPART1\
audioalarmsensitivity:slider,10,10,100 instar/DEVNAME/alarm/actions/audioalarmsensitivity/raw $EVTPART1\
power_led:on,off instar/DEVNAME/features/indicator/power/raw $EVTPART1\
wifi_led:on,off instar/DEVNAME/features/indicator/wifi/raw $EVTPART1
attr DEVICE model InstarCam#
setreading DEVICE attrTemplateVersion 20200619
Viele Grüße
Thomas
Vorab mal Danke für das Template.
Kann nicht beurteilen, ob "eines für alle" ausreichend ist, werden wir sehen...
Werd's auch mal mit den langen Präfixen eingecheckt, aber wenn man hinterher sowieso via $JSONMAP wieder umbenennt, ginge es evtl auch kürzer oder wenigstens optisch prägnanter?
Dafür, dass der command nicht effektiv ankommt, gibt es m.E. keine wirklich gute Erklärung; MQTT2_DEVICE macht im Prinzip auch nichts anderes als ein publish über das IO, und wenn man da von extern keinen Unterschied sieht, wird es schwierig (Vertiefung dazu aber bitte bei Bedarf in separatem Thread!). Sieht mir eher wie ein "Hau" in der firmware aus?
Das ist auch die normale firmware des Herstellers, oder? (Wg. der Sortierung)
ZitatWerd's auch mal mit den langen Präfixen eingecheckt, aber wenn man hinterher sowieso via $JSONMAP wieder umbenennt, ginge es evtl auch kürzer oder wenigstens optisch prägnanter?
Wenn du eine Idee hast, wie... An den normalen Werten hängt sonst immer "val" am Ende dran was ich nicht so schön finde. Deshalb habe ich jsonmap verwendet.
ZitatDas ist auch die normale firmware des Herstellers, oder? (Wg. der Sortierung)
Ja, das ist die Original Firmware. Die hat zwar aktuell noch wifi led und power led per mqtt vertauscht, aber das habe ich bereits an Instar gemeldet.
Vorab: wir sollten die Diskussion zu Instar bitte dann ab jetzt auslagern, einfach neuen Post in diesem Forenbereich aufmachen.
Zitat von: ToM_ToM am 22 Juni 2020, 08:48:12
Wenn du eine Idee hast, wie... An den normalen Werten hängt sonst immer "val" am Ende dran was ich nicht so schön finde. Deshalb habe ich jsonmap verwendet.
Habe hier mal ein kleines Beispiel gepostet, wie man jsonMap nutzen kann, um "sinnvolle" (?) Readingnamen zu generieren: https://forum.fhem.de/index.php/topic,112246.msg1066633.html#msg1066633. Mit ":0" kann man auch unnützes Zeug ignorieren lassen.
ZitatJa, das ist die Original Firmware. Die hat zwar aktuell noch wifi led und power led per mqtt vertauscht, aber das habe ich bereits an Instar gemeldet.
OK, dann muß ich die Sortierung noch anfassen (Quellenangabe fehlt auch noch).
Hallo Beta-User,
anbei das aktualisierte Template. Es gibt ein paar neue Funktionen. Außerdem habe ich das Attribut eventMap entfernt da es nicht ganz sauber funktioniert hat.
Instar ist sich leider über boolesche Werte nicht einig, ob sie 0/1 oder off/on verwenden.
Hier mal ein Beispiel aus dem Instar MQTT-Wiki von Instar:
alarm/actions/alarmout {"val":"off"}, {"val":"on"}
alarm/actions/alarmin {"val":"0"}, {"val":"1"}
Quelle: https://wiki.instar.de/Erweitert/INSTAR_MQTT_Broker/MQTT_API/ (https://wiki.instar.de/Erweitert/INSTAR_MQTT_Broker/MQTT_API/)
###########################################
# Instar 8015HD.
# contributed by ToM_ToM
#source post: https://forum.fhem.de/index.php/topic,94495.msg1065779.html#msg1065779
name:InstarCam
filter:TYPE=MQTT2_DEVICE
desc:for Instar Camera, source post: https://forum.fhem.de/index.php/topic,94495.msg1065779.html#msg1065779.<br>NOTE: This is an early version, developed for Instar 8015 HD. Other models may need different settings.
order:M_10
par:DEVNAME;MAC address in the topic;{ AttrVal("DEVICE","readingList","") =~ m,instar/([^/]*)/, ? $1 : undef }
attr DEVICE jsonMap area1val:area1 area1sensitivityval:area1sensitivity area2val:area2 area2sensitivityval:area2sensitivity area3val:area3 area3sensitivityval:area3sensitivity area4val:area4 area4sensitivityval:area4sensitivity pirval:pir alarmserverval:alarmserver alarmserver_ipval:alarmserver_ip alarmserver_portval:alarmserver_port alarmserver_pathval:alarmserver_path camera_ipval:camera_ip alarmsignalval:alarmsignal audioalarmval:audioalarm audioalarmsensitivityval:audioalarmsensitivity power_ledval:power_led wifi_ledval:wifi_led alarminval:alarmin alarminmodeval:alarminmode alarmoutval:alarmout emailval:email snapshot2sdval:snapshot2sd snapshot2ftpval:snapshot2ftp alarmsnapshots2emailval:alarmsnapshots2email alarmsnapshots2email_qtyval:alarmsnapshots2email_qty snapshot2sdval:snapshot2sd alarmsnapshots2sd_qtyval:alarmsnapshots2sd_qty snapshot2ftpval:snapshot2ftp alarmsnapshots2ftp_qtyval:alarmsnapshots2ftp_qty video2sdval:video2sd video2ftpval:video2ftp videolengthval:videolength
attr DEVICE readingList instar/DEVNAME/status/alarm/actions/pir/enable:.* { json2nameValue($EVENT, 'pir', $JSONMAP) }\
instar/DEVNAME/status/alarm/area1/enable:.* { json2nameValue($EVENT, 'area1', $JSONMAP) }\
instar/DEVNAME/status/alarm/area1/sensitivity:.* { json2nameValue($EVENT, 'area1sensitivity', $JSONMAP) }\
instar/DEVNAME/status/alarm/area2/enable:.* { json2nameValue($EVENT, 'area2', $JSONMAP) }\
instar/DEVNAME/status/alarm/area2/sensitivity:.* { json2nameValue($EVENT, 'area2sensitivity', $JSONMAP) }\
instar/DEVNAME/status/alarm/area3/enable:.* { json2nameValue($EVENT, 'area3', $JSONMAP) }\
instar/DEVNAME/status/alarm/area3/sensitivity:.* { json2nameValue($EVENT, 'area3sensitivity', $JSONMAP) }\
instar/DEVNAME/status/alarm/area4/enable:.* { json2nameValue($EVENT, 'area4', $JSONMAP) }\
instar/DEVNAME/status/alarm/area4/sensitivity:.* { json2nameValue($EVENT, 'area4sensitivity', $JSONMAP) }\
instar/DEVNAME/status/alarm/alarmserver/enable:.* { json2nameValue($EVENT, 'alarmserver', $JSONMAP) }\
instar/DEVNAME/status/alarm/alarmserver/address:.* { json2nameValue($EVENT, 'alarmserver_ip', $JSONMAP) }\
instar/DEVNAME/status/alarm/alarmserver/port:.* { json2nameValue($EVENT, 'alarmserver_port', $JSONMAP) }\
instar/DEVNAME/status/alarm/alarmserver/path:.* { json2nameValue($EVENT, 'alarmserver_path', $JSONMAP) }\
instar/DEVNAME/status/network/config/ipaddr:.* { json2nameValue($EVENT, 'camera_ip', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/alarmsignal:.* { json2nameValue($EVENT, 'alarmsignal', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/audioalarm:.* { json2nameValue($EVENT, 'audioalarm', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/audioalarmsensitivity:.* { json2nameValue($EVENT, 'audioalarmsensitivity', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/alarmin:.* { json2nameValue($EVENT, 'alarmin', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/alarminmode:.* { json2nameValue($EVENT, 'alarmin', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/alarmout:.* { json2nameValue($EVENT, 'alarmout', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/email:.* { json2nameValue($EVENT, 'alarmsnapshots2email', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/alarmsnapshots/email:.* { json2nameValue($EVENT, 'alarmsnapshots2email_qty', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/snapshot2sd:.* { json2nameValue($EVENT, 'snapshot2sd', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/alarmsnapshots/sd:.* { json2nameValue($EVENT, 'alarmsnapshots2sd_qty', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/snapshot2ftp:.* { json2nameValue($EVENT, 'snapshot2ftp', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/alarmsnapshots/ftp:.* { json2nameValue($EVENT, 'alarmsnapshots2ftp_qty', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/video2sd:.* { json2nameValue($EVENT, 'video2sd', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/alarm/actions/video2ftp:.* { json2nameValue($EVENT, 'video2ftp', $JSONMAP) }\
instar/DEVNAME/status/alarm/actions/videolength:.* { json2nameValue($EVENT, 'videolength', $JSONMAP) }\
instar/DEVNAME/status/features/indicator/power:.* { json2nameValue($EVENT, 'power_led', $JSONMAP) }\
instar/DEVNAME/status/features/indicator/wifi:.* { json2nameValue($EVENT, 'wifi_led', $JSONMAP) }
attr DEVICE setList pir:0,1 instar/DEVNAME/alarm/actions/pir/enable/raw $EVTPART1\
area1:0,1 instar/DEVNAME/alarm/area1/enable/raw $EVTPART1\
area1sensitivity:slider,1,1,100 instar/DEVNAME/alarm/area1/sensitivity/raw $EVTPART1\
area2:0,1 instar/DEVNAME/alarm/area2/enable/raw $EVTPART1\
area2sensitivity:slider,1,1,100 instar/DEVNAME/alarm/area2/sensitivity/raw $EVTPART1\
area3:0,1 instar/DEVNAME/alarm/area3/enable/raw $EVTPART1\
area3sensitivity:slider,1,1,100 instar/DEVNAME/alarm/area3/sensitivity/raw $EVTPART1\
area4:0,1 instar/DEVNAME/alarm/area4/enable/raw $EVTPART1\
area4sensitivity:slider,1,1,100 instar/DEVNAME/alarm/area4/sensitivity/raw $EVTPART1\
alarmserver:on,off instar/DEVNAME/alarm/alarmserver/enable/raw $EVTPART1\
alarmsignal:on,off instar/DEVNAME/alarm/actions/alarmsignal/raw $EVTPART1\
audioalarm:0,1 instar/DEVNAME/alarm/actions/audioalarm/raw $EVTPART1\
audioalarmsensitivity:slider,10,10,100 instar/DEVNAME/alarm/actions/audioalarmsensitivity/raw $EVTPART1\
alarmin:0,1 instar/DEVNAME/alarm/actions/alarmin/raw $EVTPART1\
alarminmode:0,1 instar/DEVNAME/alarm/actions/alarminmode/raw $EVTPART1\
alarmout:on,off instar/DEVNAME/alarm/actions/alarmout/raw $EVTPART1\
email:on,off instar/DEVNAME/alarm/actions/email/raw $EVTPART1\
alarmsnapshots2email_qty:slider,0,1,15 instar/DEVNAME/alarm/actions/alarmsnapshots/email/raw $EVTPART1\
snapshot2sd:on,off instar/DEVNAME/alarm/actions/snapshot2sd/raw $EVTPART1\
alarmsnapshots2sd_qty:slider,0,1,15 instar/DEVNAME/alarm/actions/alarmsnapshots/sd/raw $EVTPART1\
snapshot2ftp:on,off instar/DEVNAME/alarm/actions/snapshot2ftp/raw $EVTPART1\
alarmsnapshots2ftp_qty:slider,0,1,15 instar/DEVNAME/alarm/actions/alarmsnapshots/ftp/raw $EVTPART1\
video2sd:on,off instar/DEVNAME/alarm/actions/video2sd/raw $EVTPART1\
videolength:slider,15,15,60 instar/DEVNAME/alarm/actions/videolength/raw $EVTPART1\
power_led:on,off instar/DEVNAME/features/indicator/power/raw $EVTPART1\
wifi_led:on,off instar/DEVNAME/features/indicator/wifi/raw $EVTPART1
attr DEVICE model InstarCam
setreading DEVICE attrTemplateVersion 20200628
Hi,
ich habe mal das Worx Landroid Template neu gemacht.
desc wie gewünscht gemacht ;)
Neue Features eingebaut die bei den 2019 Modellen und der aktuellen Firmware 3.13 greifen:
- ad Hoc Kantenschnitt
- ad Hoc Rasenmähen für xx minuten
- Party modus für xx minuten
name:worx_landroid
desc:Template for a Worx Landroid mower.<br>The complete Setup is described in this <a href="https://forum.fhem.de/index.php/topic,111959.0.html">Forum Thread</a><br>Some Features requires support by model and firmware!
filter:TYPE=MQTT2_DEVICE
order:X_05
par:BASE_TOPIC;base topic: the Mower BoardID (2019: PRM100);{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^\/:]+)[\/].+, ? $1 : undef }
par:DEV_ID;the MAC of the Mower (Device Info);{ AttrVal("DEVICE","readingList","") =~ m,[^\/]+[\/]([0-9A-Z]+)[\/]commandOut:.*, ? $1 : undef }
par:ICON;ICON as set, defaults to audio_volume_low;{ AttrVal("DEVICE","icon","scene_robo_lawnmower") }
attr DEVICE icon ICON
attr DEVICE readingList BASE_TOPIC/DEV_ID/commandOut:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap dat_rsi:wifiQuality dat_fw:firmware cfg_sn:SerialNumber\
dat_le:mowerErrorIndex dat_ls:mowerStatusIndex\
cfg_rd:mowerRainDelay cfg_sc_m:mowerActiveIndex cfg_sc_p:mowerTimeCorrection\
dat_bt_t:batteryTemperature dat_bt_v:batteryVoltage dat_bt_p:batteryPercent dat_bt_nr:batteryChargeCycle dat_bt_c:batteryCharging\
dat_st_b:bladeTimeCounter dat_st_d:totalDistance dat_st_wt:totalTime\
dat_dmp_1:directionPitch dat_dmp_2:directionRoll dat_dmp_3:directionYaw
attr DEVICE setList mowerRainDelay:slider,0,30,1440 BASE_TOPIC/DEV_ID/commandIn {"rd":$EVTPART1}\
mowerTimeCorrection:slider,-100,1,100 BASE_TOPIC/DEV_ID/commandIn {"sc":{"p":$EVTPART1}}\
startBorderCut:noArg BASE_TOPIC/DEV_ID/commandIn {"sc":{"ots":{"bc":1,"wtm":0}}}\
startOneTime:slider,10,10,720 BASE_TOPIC/DEV_ID/commandIn {"sc":{"ots":{"bc":0,"wtm":$EVTPART1}}}\
startParty:slider,60,60,2880 BASE_TOPIC/DEV_ID/commandIn {"sc":{"distm":$EVTPART1}}\
startMower:noArg BASE_TOPIC/DEV_ID/commandIn {"cmd":1}\
pauseMower:noArg BASE_TOPIC/DEV_ID/commandIn {"cmd":2}\
stopMower:noArg BASE_TOPIC/DEV_ID/commandIn {"cmd":3}\
x_raw_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //g; qq(BASE_TOPIC/DEV_ID/commandIn $payload)}
attr DEVICE userReadings mowerActive:mowerActiveIndex.* {ReadingsVal($name,"mowerActiveIndex","0") ? "true" : "false"},\
mowerStatusTxt:mowerStatusIndex.* {my %stateCodes = (\
0 => "Idle",\
1 => "Home",\
2 => "Start sequence",\
3 => "Leaving home",\
4 => "Follow wire",\
5 => "Searching home",\
6 => "Searching wire",\
7 => "Mowing",\
8 => "Lifted",\
9 => "Trapped",\
10 => "Blade blocked",\
11 => "Debug",\
12 => "Remote control",\
30 => "Going home",\
31 => "Zone Training",\
32 => "Edge cutting",\
33 => "Searching zone",\
34 => "Pause"\
); $stateCodes{ReadingsVal($name,"mowerStatusIndex","0")}},\
mowerErrorTxt:mowerErrorIndex.* { my %errorCodes = (\
0 => "No error",\
1 => "Trapped",\
2 => "Lifted",\
3 => "Wire missing",\
4 => "Outside wire",\
5 => "Raining",\
6 => "Close door to mow",\
7 => "Close door to go home",\
8 => "Blade motor blocked",\
9 => "Wheel motor blocked",\
10 => "Trapped timeout",\
11 => "Upside down",\
12 => "Battery low",\
13 => "Reverse wire",\
14 => "Charge error",\
15 => "Timeout finding home",\
16 => "Mower locked",\
17 => "Battery temp out of range"\
); $errorCodes{ReadingsVal($name,"mowerErrorIndex","0")}}
attr DEVICE model worx_landroid_mover
setreading DEVICE attrTemplateVersion 20200701
ich hoffe das passt so :)
Gruß Otto
...ist drin; die desc: habe ich geringfügig überarbeitet, hoffe, das paßt so ;) ?
@ToM_ToM: dein Vorschlag ist schon länger drin, auch wenn das mapping vermutlich noch knapper gehalten werden könnte, ist aber nicht tragisch...
Falls du das mit 0/1 zu on/off vereinheitlichen wolltest: das 6-fach-Ethernet-board hat da was im Angebot für true/false, das sich leicht übertragen lassen sollte ;) .
Zitat von: Beta-User am 01 Juli 2020, 16:49:13
...ist drin; die desc: habe ich geringfügig überarbeitet, hoffe, das paßt so ;) ?
Ach man ich wollte ein Lob das ich das so schön gemacht habe. Naja kleine Kritik ist Lob genug ;)
Nein nur Spaß - hast Du gut überarbeitet. Danke :)
Hi,
Ich hab mich mal an einem Template für einen Tasmota Tür/Fensterkontakt versucht (https://templates.blakadder.com/TYMC-1.html (https://templates.blakadder.com/TYMC-1.html)).
# tasmota battery powered window sensor MC400A
name:tasmota_window_MC400A
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:Configures a MC400A windows sensor
order:A_05c
attr DEVICE icon tuer_fenster_kontakt
attr DEVICE jsonMap TuyaReceived_Cmnd:0 TuyaReceived_CmndData:0 TuyaReceived_Data:0
attr DEVICE autocreate 0
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev",undef)}
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
set IO_DEV publish CMNDTOPIC/Backlog Template {"NAME":"MC400A","GPIO":[0,107,0,108,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":54}; Module 0; SetOption1 1; SetOption65 1; SetOption66 1; SwitchMode 1; TuyaMCU 51,21; StateText1 closed; StateText2 open; Timezone 99; SaveData 1
set IO_DEV publish CMNDTOPIC/Backlog Rule1 ON TuyaReceived#Data=55AA00050005030400010213 DO Backlog publish stat/%topic%/batteryState ok; publish stat/%topic%/batteryPercent 100 ENDON ON TuyaReceived#Data=55AA00050005030400010112 DO Backlog publish stat/%topic%/batteryState ok; publish stat/%topic%/batteryPercent 50 ENDON ON TuyaReceived#Data=55AA00050005030400010011 DO Backlog publish stat/%topic%/batteryState low; publish stat/%topic%/batteryPercent 5 ENDON; Rule1 1; SaveData 1
attr DEVICE setList \
nosleep:noArg CMNDTOPIC/SerialSend5 55AA000200010002\
setOtaUrl:textField CMNDTOPIC/OtaUrl $EVTPART1\
upgrade:noArg CMNDTOPIC/upgrade 1
attr DEVICE devStateIcon Online:10px-kreis-gruen Offline:10px-kreis-rot
attr DEVICE readingList \
TELETOPIC/LWT:.* LWT\
CMNDTOPIC/POWER:.* POWER\
TELETOPIC/INFO1:.* { json2nameValue($EVENT) }\
TELETOPIC/INFO2:.* { json2nameValue($EVENT) }\
TELETOPIC/INFO3:.* { json2nameValue($EVENT) }\
STATTOPIC/RESULT:.* { json2nameValue($EVENT) }\
STATTOPIC/POWER:.* state\
TELETOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT) }\
STATTOPIC/batteryState:.* batteryState\
STATTOPIC/batteryPercent:.* batteryPercent
attr DEVICE stateFormat LWT\
state
attr DEVICE model tasmota_windows_sensor_MC400A
setreading DEVICE attrTemplateVersion 20200522 or prior
So weit funktionieren der Sensor und das Template, nur die Rule zum Senden der Batterie-Informationen bekomme ich nicht hin. Tasmota übernimmt nur den Teil bis zum 1. Semikolon in der Rule.
10:29:36 MQT: stat/tasmota_37367A/RESULT = {"Rule1":"open","Once":"closed","StopOnError":"closed","Length":93,"Free":418,"Rules":"ON TuyaReceived#Data=55AA00050005030400010213 DO Backlog publish stat/%topic%/batteryState ok"}
10:29:36 MQT: stat/%topic%/batteryPercent = 100 ENDON ON TuyaReceived#Data=55AA00050005030400010112 DO Backlog publish stat/%topic%/batteryState ok
10:29:36 MQT: stat/%topic%/batteryPercent = 50 ENDON ON TuyaReceived#Data=55AA00050005030400010011 DO Backlog publish stat/%topic%/batteryState low
10:29:36 MQT: stat/%topic%/batteryPercent = 5 ENDON
10:29:36 MQT: stat/tasmota_37367A/RESULT = {"Rule1":"open","Once":"closed","StopOnError":"closed","Length":93,"Free":418,"Rules":"ON TuyaReceived#Data=55AA00050005030400010213 DO Backlog publish stat/%topic%/batteryState ok"}
Scheinbar wird alles nach dem Semikolon als neuer Befehl interpretiert, nicht als weiterer Teil der Rule. Geb ich die Rule auf direkt auf dem Sensor ein, übernimmt er die ganze Rule:
Rule1 ON TuyaReceived#Data=55AA00050005030400010213 DO Backlog publish stat/%topic%/batteryState ok; publish stat/%topic%/batteryPercent 100 ENDON ON TuyaReceived#Data=55AA00050005030400010112 DO Backlog publish stat/%topic%/batteryState ok; publish stat/%topic%/batteryPercent 50 ENDON ON TuyaReceived#Data=55AA00050005030400010011 DO Backlog publish stat/%topic%/batteryState low; publish stat/%topic%/batteryPercent 5 ENDON
Mit dem "nosleep" Befehl geht der Sensor für ca. 1 Minute nicht direkt wieder in den Schlafmodus, wodurch mal ihn dann konfigurieren kann. Sonst muss man ihn immer über den Reedkontakt beschäftigen..
Gruß,
Michael
:) Sieht ziemlich gut aus.
Das mit dem Backlog-Rule-Ding könnte joelinux mal gelöst haben, indem er das in eine par-Anweisung verpackt hat (siehe tasmota_3socketUSB_split):
par:BUTTONRULE;Suggest Tasmota Button Rule for Power Strip;{ q/rule on button1#state=3 do backlog power1 2; power2 2; power3 2; power4 2 endon on button1#state=2 do backlog power1 1; power2 1; power3; power4 1 endon/ }
In die desc. sollte dann vermutlich noch ein Link auf die blakadder-Seite rein, damit man das wiederfindet; scheint ja ein - für Tasmota - spezielles Ding zu sein (TuyaMCU). Von daher bin ich auch unsicher, ob ich das hier und das tasmota_TuyaMCU_dimmer nicht irgendwie in eine andere Untergruppe verschieben sollte (also via order: irgendwie zusammensortieren). Da fehlt mir aber ggf. etwas Einblick, wie das denn jetzt genau funktioniert (mit TuyaMCU).
Hi,
Das mit der par-Anweisung hatte ich mal versucht, bin da aber an den %-Zeichen gescheitert, die perl interpretieren will. Hast du eine Idee, wie man die maskieren muss? \% und %% geht nicht...
ERROR executing perl-code { q/rule on TuyaReceived#Data=55AA00050005030400010213 DO Backlog publish stat/%topic%/batteryState ok; publish stat/%topic%/batteryPercent 100 endon/ } for param BATTERYRULE: Illegal modulus zero at (eval 803) line 1.Was TuyaMCU angeht, da gibt es schon einige Geräte, die das nutzen (siehe https://tasmota.github.io/docs/TuyaMCU/ (https://tasmota.github.io/docs/TuyaMCU/)):
- Switches or Plugs/Power Strips
- Aromatherapy Machine (Oil Diffuser)
- Curtain Motor
- Power Monitoring Plug
- Dehumidifier
- Lighting
- Contact Sensor
- Air purifier
- Heater
- Smart fan
- Kettle
- BecaThermostat
- Inkbird ITC-308-Wifi
Gruß,
Michael
Puh, müßte ich auch irgendwie mal austesten...
Eine ungetestete Idee hätte ich noch, nämlich das in single quotes zu packen:
set IO_DEV publish 'CMNDTOPIC/Backlog Rule1 ON TuyaReceived#Data=55AA00050005030400010213 DO Backlog publish stat/%topic%/batteryState ok; publish stat/%topic%/batteryPercent 100 ENDON ON TuyaReceived#Data=55AA00050005030400010112 DO Backlog publish stat/%topic%/batteryState ok; publish stat/%topic%/batteryPercent 50 ENDON ON TuyaReceived#Data=55AA00050005030400010011 DO Backlog publish stat/%topic%/batteryState low; publish stat/%topic%/batteryPercent 5 ENDON; Rule1 1; SaveData 1'
Ansonsten wäre nochmal nachzusehen, was wo und wie interpoliert wird, aber vermutlich sind die Chancen umso höher, je "näher" das am IO ist...
Hi,
das hat auch nicht funktioniert, aber ich hab jetzt einen Weg gefunden.
# tasmota battery powered window sensor MC400A
name:tasmota_window_MC400A
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:Configures a MC400A windows sensor
order:A_05c
attr DEVICE icon tuer_fenster_kontakt
attr DEVICE jsonMap TuyaReceived_Cmnd:0 TuyaReceived_CmndData:0 TuyaReceived_Data:0
attr DEVICE autocreate 0
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev",undef)}
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
set IO_DEV publish CMNDTOPIC/Rule1 ON TuyaReceived#Data=55AA00050005030400010213 DO publish stat/%topic%/batteryState ok; publish stat/%topic%/batteryPercent 100 ENDON ON TuyaReceived#Data=55AA00050005030400010112 DO publish stat/%topic%/batteryState ok; publish stat/%topic%/batteryPercent 50 ENDON ON TuyaReceived#Data=55AA00050005030400010011 DO publish stat/%topic%/batteryState low; publish stat/%topic%/batteryPercent 5 ENDON
set IO_DEV publish CMNDTOPIC/Backlog Template {"NAME":"MC400A","GPIO":[0,107,0,108,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":54}; Module 0; SetOption1 1; SetOption65 1; SetOption66 1; SwitchMode 1; TuyaMCU 51,21; StateText1 closed; StateText2 open; Timezone 99; Rule1 1;SaveData 1; Reboot 1
attr DEVICE setList \
nosleep:noArg CMNDTOPIC/SerialSend5 55AA000200010002\
setOtaUrl:textField CMNDTOPIC/OtaUrl $EVTPART1\
upgrade:noArg CMNDTOPIC/upgrade 1
attr DEVICE devStateIcon Online:10px-kreis-gruen Offline:10px-kreis-rot
attr DEVICE readingList \
TELETOPIC/LWT:.* LWT\
CMNDTOPIC/POWER:.* POWER\
TELETOPIC/INFO1:.* { json2nameValue($EVENT) }\
TELETOPIC/INFO2:.* { json2nameValue($EVENT) }\
TELETOPIC/INFO3:.* { json2nameValue($EVENT) }\
STATTOPIC/RESULT:.* { json2nameValue($EVENT) }\
STATTOPIC/POWER:.* state\
TELETOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT) }\
STATTOPIC/batteryState:.* batteryState\
STATTOPIC/batteryPercent:.* batteryPercent
attr DEVICE stateFormat LWT\
state
attr DEVICE model tasmota_windows_sensor_MC400A
setreading DEVICE attrTemplateVersion 20200522 or prior
Der Trick ist, zuerst nur die Rule (ohne Backlog) zu senden und dann im 2. Schritt die restlichen Parameter zu setzten und die Rule zu aktivieren.
Gruß,
Michael
Hab's eben eingecheckt, allerdings dann doch noch ein paar Kleinigkeiten geändert (CMD-Topic in readingList ist mAn. nie gewollt, sowas gehört mit einiger Sicherheit in die ignoreRegexp beim IO).
Und eine generelle Frage: Ist in dem template jetzt eigentlich eine Art Seriennummer oder so hart verdrahtet? Wenn ja, müßten wir das ggf. nacharbeiten, dazu bitte dann einfach einen neuen Thread aufmachen, das wird vermutlich insgesamt was größeres mit diesen TuyaMCU-Dingern...
Versteh' ich nicht: ???
Ich lege meine devices gerne selber an. Eigentlich komplett, aber hier gibt es ja templates. Also gehen wir mal den Weg und ich möchte ein Shelly 2.5 anlegen:
define MQTT2_lustigerShelly25 MQTT2_DEVICE shellyswitch25-38C52BD8EF7AIm erstellten device angekommen, kommt da noch nicht so viel. Also denn ein Template auswählen, aber da gibt es nur den Shelly 1. Nach langem Suchen stoße ich dann mal auf den code im github:
https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/lib/AttrTemplate/mqtt2.template
Zitat# shelly2.5 using original firmware.
# Based on user 87insane contribution in https://forum.fhem.de/index.php/topic,94060.msg962167.html#msg962167
# NOTE: a second device will be created for the second channel
name:shelly25_split
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shelly2.5 using original firmware. <br>NOTE: a second device will be created for the second channel
order:A_11a1
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
par:CALLSPEECHRECOGN;Set this to 0 to not set any speech recogn. related attributes;{ 1 }
set DEVICE attrTemplate shelly1_w_energy_measuring \CALLSPEECHRECOGN=0
set DEVICE attrTemplate set_associatedWith \CHANNELS=2 \MAKECOPIES=1
attr DEVICE_CH2 readingList shellies/DEVNAME/relay/1:.* state\
shellies/DEVNAME/relay/1:.* relay1\
shellies/DEVNAME/input/1:.* input1\
shellies/DEVNAME/online:.* online\
shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : return }\
shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
shellies/DEVNAME/relay/1/power:.* relay_1_power\
shellies/DEVNAME/relay/1/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : return }\
shellies/DEVNAME/temperature:.* temperature\
shellies/DEVNAME/overtemperature:.* overtemperature\
shellies/DEVNAME/temperature_f:.* temperature_f\
shellies/DEVNAME/relay/1/energy:.* relay_1_energy\
shellies/DEVNAME/relay/1/energy:.* {'relay_1_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
shellies/DEVNAME/longpush/1:.* longpush_1\
shellies/DEVNAME/input_event/1:.* { json2nameValue($EVENT) }
attr DEVICE_CH2 setList \
off:noArg shellies/DEVNAME/relay/1/command off\
on:noArg shellies/DEVNAME/relay/1/command on
attr DEVICE_CH2 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen"; my $light = ReadingsVal($name,"state","off"); my $cons = ReadingsVal($name,"relay_1_power","unknown"); my $temp = ReadingsVal($name,"temperature","-100");"<div><a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C<b></b>"}
attr DEVICE,DEVICE_CH2 model shelly25_split
setreading DEVICE,DEVICE_CH2 attrTemplateVersion 20200831
option:{ CALLSPEECHRECOGN }
set DEVICE,DEVICE_CH2 attrTemplate speechcontrol_type_switch
Genau genommen diese Zeile hier:
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.* :o
Warum? Ich mein, klar, damit kann man die Auswahlliste einschränken, aber wenn ich das MQTT device selbst anlege, komme ich nie zu dem template, weil das attribut
readingListeinfach nicht übers kurze define (siehe oben) befüllt ist.
Auch weiß ich nicht, wie mir hier
set MQTT2_lustigerShelly25 attrTemplate ?mit
shelly25_split
shelly2.5 using original firmware.
NOTE: a second device will be created for the second channelda weiterhelfen soll. Wie/wo kann ich das anwenden? ???
Ich mein, übers contribution post
https://forum.fhem.de/index.php/topic,94060.msg962167.html#msg962167
weiß ich ja nun wie das funktionieren soll und kann es einfach nachbauen, aber der Einfachheit halber (mit den templates):
Könnte man das nicht irgendwie so machen, dass man halt beispielsweise ein "model"-Attribut setzt und dann darf man das template auswählen? :-\
Oder gibt es da schon ein "super easy way", der einfach super gut versteckt ist? :o
Zitat von: Brot am 20 September 2020, 17:11:10
Versteh' ich nicht: ???
Du bist hier falsch :)
Zitat von: Beta-User am 15 Dezember 2018, 11:45:40
Bitte nutzt möglichst diesen Thread, wenn ihr neue (im Prinzip ausentwickelte) templates für mqtt2.template vorschlagen wollt.
Für Fehlermeldungen, Diskussionen zu Verbesserungsvorschlägen zu vorhandenen und zum Anfragen von support für neue Devices ist ein weiterer Thread (https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200) gedacht, dieser hier sollte möglichst übersichtlich bleiben und sich auf das Wesentliche beschränken.
Generelle Anmerkungen zur attrTemplate-Funktion bitte hier (https://forum.fhem.de/index.php/topic,93370.msg860045.html#msg860045) posten.
Du hast Fragen zu der Funktion und willst kein neues Template abliefern ;)
Gruß Otto
Zitat von: Brot am 20 September 2020, 17:11:10
Könnte man das nicht irgendwie so machen, dass man halt beispielsweise ein "model"-Attribut setzt und dann darf man das template auswählen? :-\
Oder gibt es da schon ein "super easy way", der einfach super gut versteckt ist? :o
Obwohl es hier OT ist und dann bitte bei BEDARF an anderer Stelle fortgeführt werden sollte:
Also: der "super easy way" ist schlicht und ergreifend autocreate zu verwenden (und das betreffende Gadget nicht vorher allzusehr zu "verkonfigurieren"). Dann hat das Ergebnis in der Regel typische readingList-Einträge...
Man kann auch weggefilterte templates ohne weiteres aufrufen. Wie es geht, steht z.B. auch im Wiki: https://wiki.fhem.de/wiki/MQTT2_DEVICE#attrTemplate. Man hat dann allerdings eventuell das "kleine Problem", dass das betreffende template intern bestimmte Parameter nicht aufdröseln kann (die ergeben sich nämlich - oha, Überraschung - aus der readingList) und man dann Rückfragen (via Dialogfeld) erhält, deren Sinn sich in der Regel gerade denjenigen nicht erschließt, die die Gesamtzusammenhänge nicht verstanden haben und daher auch nicht in der Lage sind, die passenden Angaben zu machen...
Die Filterei an sich ist auch im Wiki erklärt: https://wiki.fhem.de/wiki/AttrTemplate#Warum_finde_ich_das_Template_xyz_nicht.3F
Kurz: Wer meint, manuell anlegen zu müssen, kann das tun, sollte dann aber dafür sorgen, dass die vom betreffenden Template selbst ermittelten Parameter (idR. die aus der filter-Angabe...) vorhanden sind und passen ;) .
[OT] Was mich wundert: wie kommt es, dass grade dieses Repo in der Suchmaschinen-Trefferliste viel weiter oben steht wie insbesondere das svn? Unter https://svn.fhem.de/trac/browser/trunk/fhem sitzt man nämlich ziemlich nahe an der eigentlichen Quelle...[/OT]
Persönliche Anmerkung:
Vieles, was man in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate?order=name und im Wiki zu MQTT-Themen findet, ist "irgendwie so nebenbei" entstanden. Es mag durchaus sein, dass da an vielen Ecken noch Verbesserungsmöglichkeiten bestehen und auch manche Fehler drin sind (ich entdecke auch immer mal wieder was...), wer also die Zusammenhänge kennt, darf auch gerne (im richtigen Thread) Vorschläge machen, wie es evtl. besser geht.
Die Filterei via readingList kommt mir aber nach wie vor im Prinzip "richtig" vor, das würde ich eher ungern ändern. Was ggf. irritiert: Mal wird es gemacht, mal nicht, die Logik dahinter ist zugegebenermaßen nicht ganz digital. Das hat schlicht damit zu tun, dass es m.E. ganz gut ist zu sehen, dass es schon zu sehr vielen verschiedenen Dingen "Materialien" und Lösungsansätze gibt, und wenn man konsequent alles wegfiltert, was (vermutlich!) nichts mit dem aktuellen Device zu tun hat, dann nimmt man das als User ggf. gar nicht wahr. Den "Königsweg" dazu kenne ich nicht, wie gesagt, das ist alles "nebenbei" und jetzt auch schon über einen längeren Zeitraum entstanden, manches bzgl. der filter würde ich heute evtl. auch anders machen.
Falls also hierzu jemand Diskussionsbedarf hat oder konstruktive Vorschläge liefern möchte: nur zu, aber bitte dann in einem separaten Thread ;) .
AttrTemplate-Vorschlag für Shelly-Gas-Sensor (angelehnt an Shelly-Flood)
Hallo,
anbei ein funktionierender Vorschlag für ein Template für Shelly-Gas-Sensoren:
# shellygas using original firmware
name:shellygas
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shellygas using original firmware <br>Just adds stateFormat, setlist, icon, devStateIcon
order:A_16b
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE icon feinstaub
attr DEVICE devStateIcon none:ampel_gruen mild:ampel_gelb heavy:ampel_rot test:ampel_gruen
attr DEVICE setList \
start_self_test:noArg shellies/DEVNAME/sensor/start_self_test\
mute:noArg shellies/DEVNAME/sensor/mute\
unmute:noArg shellies/DEVNAME/sensor/unmute\
x_update:noArg shellies/DEVNAME/command update_fw\
x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE stateFormat gas
deletereading -q DEVICE (?!associatedWith).*
set DEVICE x_mqttcom announce
attr DEVICE model shellygas
setreading DEVICE attrTemplateVersion 20201102 or prior
Anregungen, Verbesserung nehme ich gerne entgegen.
Vielen Dank.
LuckyApo
PS: Muss man eigentlich FHEM immer komplett neu starten, wenn man die Datei mqtt2.template anpasst?
Zitat von: LuckyLuis am 02 November 2020, 13:34:06
PS: Muss man eigentlich FHEM immer komplett neu starten, wenn man die Datei mqtt2.template anpasst?
Nein :)
https://forum.fhem.de/index.php/topic,111711.msg1097486.html#msg1097486
bzw. nur
{ AttrTemplate_Initialize() }
Zitat von: Otto123 am 02 November 2020, 14:01:08
Nein :)
https://forum.fhem.de/index.php/topic,111711.msg1097486.html#msg1097486
bzw. nur { AttrTemplate_Initialize() }
Danke, Otto123! Da mache ich mir doch gleich mal einen Menueintrag :D
Zitat von: LuckyLuis am 02 November 2020, 13:34:06
AttrTemplate-Vorschlag für Shelly-Gas-Sensor (angelehnt an Shelly-Flood)
Danke, ist eingecheckt :) .
Hallo Beta-User,
auch Dir vielen Dank für das Einchecken!
Hallo
Ich habe wiedermal eine Frage.
Ich habe ein LSC LED-Stripe mit Tasmota geflasht und per MQTT2 mit FHEM gekoppelt.
Mit FHEM kann ich auch alle Farben wählen und die weißen LED´s Steuern.
Nun möchte ich gerne das die weißen LED´s und die farbigen LED´s zusammen leuchten lassen.
Irgendwie geht das nicht. Wenn ich die Farben einstelle schalten sich die weißen LED´s ab.
Umgekehrt ist es auch so.
Ist das Hardware mäßig so geschalten, oder kann ich das per Software ändern ?
Einen schönen 2. Advent.
André
Zitat von: rieders am 05 Dezember 2020, 18:03:56
Hallo
>:(
Falscher Thread!
Mach doch bitte einfach einen eigenen Thread für das Thema auf, ist m.E. was Tasmota-spezifisches und falls es dann daraus einen FERTIGEN Vorschlag für attrTemplate-svn-Aktionen gibt, darfst du auch gerne wieder hier posten. (Will sagen: vorher NICHT!)
@all FYI: Habe eben ein neues attrTemplate eingecheckt für 4-channel-tasmota als Doppelrolladenaktor. Rückmeldungen dazu bitte im im template verlinkten Thread.
Hallo an Alle hier,
ich habe für das GoSound SP112 ab Juli 2020 ein Template erstellt und erfolgreich im Einsatz.
Verbesserungen immer gerne ;) ich hoffe es hilft jemanden noch was.
name:tasmota_Test_SP112_USB
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:2 channel device flashed with Tasmota. <br>NOTE: Tested with 2-way Power GoSund, please see <a href="https://templates.blakadder.com/gosund_SP112_v3_4.html">Tasmota Template Repository</a><br>NOTE: a second, device will be created for each additional channel.<br>NOTE: Please wait some seconds to allow Tasmota Device to complete reboot.
order:A_02_4base
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
par:ICON;ICON as set, defaults to hue_filled_outlet;{ AttrVal("DEVICE","icon","hue_filled_outlet") }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev",undef)}
par:LONGITUDE;Read longitude set in FHEM;{ AttrVal("global","longitude","8.686")}
par:LATITUDE;Read latitude set in FHEM;{ AttrVal("global","latitude","50.112")}
par:ALTITUDE;Read altitude set in FHEM;{ AttrVal("global","altitude","0")}
#par:BUTTONRULE;Suggest Tasmota Button Rule for Power Strip;{ q/rule on button1#state=3 do backlog power1 2; power2 2; power3 2; power4 2 endon on button1#state=2 do backlog power1 1; power2 1; power3; power4 1 endon/ }
#par:JSONSUPPRESS;Tasmota reading pairs to suppress;"LedTable:0 SaveData:0 Scheme:0 SetOption26:0 ANALOG_A0:0 Speed:0 StateText1:0 StateText2:0 StateText3:0 StateText4:0 Module:0 Version:0 FallbackTopic:0 GroupTopic:0 WebServerMode:0 Hostname:Hostname RestartReason:0 Time:0 Uptime:0 UptimeSec:0 Heap:0 SleepMode:0 Sleep:0 LoadAvg:0 MqttCount:0 Wifi_AP:0 Wifi_SSId:0 Wifi_BSSId:0 Wifi_Channel:0 Wifi_RSSI:0 Wifi_Signal:0 Wifi_LinkCount:0 Wifi_Downtime:0 subscriptions:0 Status_ButtonRetain:0 Status_ButtonTopic:0 Status_LedMask:0 Status_LedState:0 Status_Module:0 Status_Power:0 Status_PowerOnState:0 Status_PowerRetain:0 Status_SaveData:0 Status_SaveState:0 Status_SensorRetain:0 Status_SwitchMode_1:0 Status_SwitchMode_2:0 Status_SwitchMode_3:0 Status_SwitchMode_4:0 Status_SwitchMode_5:0 Status_SwitchMode_6:0 Status_SwitchMode_7:0 Status_SwitchRetain:0 Status_SwitchTopic:0 Status_Topic:0"
# Do some cleanup to eventually rerun apply template process
deletereading -q DEVICE (?!associatedWith).*
# delete DEVICE_USB
# prime Tasmota device
set DEVICE attrTemplate tasmota_set_lowercase_texts_and_state1
# additional settings to aid speech recognition to detect capabilities properly
set DEVICE attrTemplate speechcontrol_type_switch
# add some attributes to make your new device looking great
attr DEVICE icon ICON
attr DEVICE comment Admin Info and Channel 1 for DEVICE, see also DEVICE_USB
attr DEVICE devStateIcon {my $text = ' uptime: '.ReadingsVal($name,"state_Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1")); my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot"; my $light = ReadingsVal($name,"state","off");"<div><a href=\"http://".ReadingsVal($name,"IPAddress","none")." \"target=\"_blank\">".FW_makeImage($onl).'</a> <a href="/fhem?cmd.dummy=set '.$name.' toggle&XHR=1">'.FW_makeImage($light)."</a>$text<b></b>"}
attr DEVICE event-on-change-reading .*
attr DEVICE stateFormat {sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
attr DEVICE webCmd :
state\
<a href="http://IPAddress" target="_blank">IPAddress</a>
attr DEVICE readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'state_',$JSONMAP) }\
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/STATUS:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER1:.* state\
STATTOPIC/POWER2:.* POWER2\
CMNDTOPIC/POWER1:.* POWER
attr DEVICE setList\
off:noArg CMNDTOPIC/POWER1 0\
on:noArg CMNDTOPIC/POWER1 1\
toggle:noArg CMNDTOPIC/POWER1 2\
x_Reboot:noArg CMNDTOPIC/restart 1\
x_Status:noArg CMNDTOPIC/Status\
x_setOtaUrl:multiple,http://thehackbox.org/tasmota/release/tasmota-DE.bin CMNDTOPIC/OtaUrl $EVTPART1\
x_upgrade:noArg CMNDTOPIC/upgrade 1\
x_ShowHostname:noArg CMNDTOPIC/Backlog setoption53 1; Status;\
x_DisableBlinkLED:noArg CMNDTOPIC/Backlog LEDPower 0; setoption31 1; Status;\
x_SaveData:0,1 CMNDTOPIC/savedata $EVTPART1\
x_Configuration CMNDTOPIC/$EVTPART1 $EVTPART2\
x_RuleEnable:noArg CMNDTOPIC/Backlog setoption1 1; setoption32 15; rule1 1\
x_Location:noArg CMNDTOPIC/Backlog Latitude LATITUDE; Longitude LONGITUDE; Altitude ALTITUDE\
x_NTPServer:multiple,fritz.box CMNDTOPIC/ntpserver $EVTPART1
# we want state to represent 1st channel.
attr DEVICE jsonMap POWER1:state Dimmer:pct
attr DEVICE userReadings formatedUptime:state_UptimeSec.* { my $m = ReadingsVal($name,"state_UptimeSec",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m }
setreading DEVICE associatedWith DEVICE_USB
#
# create devices for 2nd channel
copy DEVICE DEVICE_USB
attr DEVICE_USB setStateList on off toggle
#
setreading DEVICE_USB associatedWith DEVICE
# set attributes specific for 2nd channel USB
attr DEVICE_USB comment Channel 2 (USB) for DEVICE_USB, see also DEVICE
#
attr DEVICE_USB setList \
off:noArg CMNDTOPIC/POWER2 0\
on:noArg CMNDTOPIC/POWER2 1\
toggle:noArg CMNDTOPIC/POWER2 2
#
attr DEVICE_USB readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'state_',$JSONMAP) }\
STATTOPIC/STATUS:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER2:.* state
# we want state to represent 4th (USB) channel.
attr DEVICE_USB jsonMap POWER2:state POWER2:0 JSONSUPPRESS
# USB channel gets a unique icon
attr DEVICE_USB icon rc_USB
#finally set the model attr for all new devices and do a reboot of device
set IO_DEV publish CMNDTOPIC/status
set IO_DEV publish CMNDTOPIC/restart 1
farewell:Template has been applied successfully. Wait some seconds for reboot to complete and watch readings get populated.
attr DEVICE,DEVICE_USB model tasmota_SP112_split_USB
setreading DEVICE,DEVICE_USB attrTemplateVersion 20200522 or prior
Ich hätte da eine überarbeitete Version für sonos2mqtt_speaker
name:sonos2mqtt_speaker
desc:A basic sonos2mqtt speaker device
filter:TYPE=MQTT2_DEVICE
order:M_05b
par:BASE_TOPIC;base topic set in configuration.yaml of the sonos2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^\/:]+)[\/].+, ? $1 : undef }
par:DEV_ID;techname of the device ;{ AttrVal("DEVICE","readingList","") =~ m,[^\/]+[\/](RINCON_[0-9A-Z]+):.*, ? $1 : undef }
par:ALIAS;friendly name as set in sonos gadget itself;{ ReadingsVal("DEVICE","name","unknown") }
par:DEVNAME;friendly name, used for topic in lowercase;{ lc(ReadingsVal("DEVICE","name","unknown")) }
par:ICON;ICON as set, defaults to audio_volume_low;{ AttrVal("DEVICE","icon","audio_volume_low") }
attr DEVICE icon ICON
attr DEVICE jsonMap volume_Master:volume mute_Master:mute
attr DEVICE stateFormat transportState
attr DEVICE readingList\
BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE setList\
stop:noArg BASE_TOPIC/DEV_ID/control { "command": "stop" }\
play:noArg BASE_TOPIC/DEV_ID/control { "command": "play" }\
pause:noArg BASE_TOPIC/DEV_ID/control { "command": "pause" }\
toggle:noArg BASE_TOPIC/DEV_ID/control { "command": "toggle" }\
volumeUp:noArg BASE_TOPIC/DEV_ID/control { "command": "volumeup" }\
volumeDown:noArg BASE_TOPIC/DEV_ID/control { "command": "volumedown" }\
volume:slider,0,1,100 BASE_TOPIC/DEV_ID/control { "command": "volume", "input": $EVTPART1 }\
mute:true,false { my $value = $EVTPART1 eq "true" ? "mute" : "unmute"; qq(BASE_TOPIC/DEV_ID/control { "command": "$value" } ) }\
next:noArg BASE_TOPIC/DEV_ID/control { "command": "next" }\
previous:noArg BASE_TOPIC/DEV_ID/control { "command": "previous" }\
joinGroup:textField BASE_TOPIC/DEV_ID/control { "command": "joingroup", "input": "$EVTPART1"}\
leaveGroup:noArg { my $value = ReadingsVal("DEV_ID","groupName","all"); qq(BASE_TOPIC/DEV_ID/control { "command": "leavegroup", "input": "$value" } ) }\
setAVTUri:textField BASE_TOPIC/DEV_ID/control { "command": "setavtransporturi", "input": "$EVTPART1"}\
playUri:textField {fhem("set $NAME setAVTUri $EVTPART1; sleep 1; set $NAME play")}\
input:Queue { my $value = $EVTPART1 eq "TV" ? "tv" : $EVTPART1 eq "Line_In" ? "line" : "queue"; qq(BASE_TOPIC/DEV_ID/control { "command": "switchto$value" } ) }\
notify:textField BASE_TOPIC/DEV_ID/control { "command":"notify","input":{"trackUri":"$EVTPART2","onlyWhenPlaying":false,"timeout":10,"volume":$EVTPART1,"delayMs":700}}\
x_raw_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //g; qq(BASE_TOPIC/DEV_ID/control $payload)}
attr DEVICE devStateIcon (STOPPED|PAUSED_PLAYBACK):rc_PLAY:toggle PLAYING:rc_PAUSE:pause .*:refresh:play
attr DEVICE alias ALIAS
attr DEVICE model sonos2mqtt_speaker
attr DEVICE userReadings Master:groupName.* {(split(' +',ReadingsVal($name,'groupName','')))[0]},\
isMaster:coordinatorUuid.* {ReadingsVal($name,'coordinatorUuid','') eq ReadingsVal($name,'uuid','')?1:0},\
inGroup:groupName.* {ReadingsVal($name,'groupName','') =~ / \+ /?1:0},\
inCouple:coordinatorUuid.* {(ReadingsVal($name,'coordinatorUuid','') ne ReadingsVal($name,'uuid','') and (index(ReadingsVal($name,'groupName',''), ReadingsVal($name,'name','')) != -1))?1:0},\
Input:currentTrack_TrackUri.* {my $currentTrack_TrackUri = ReadingsVal($name,'currentTrack_TrackUri','');\
$currentTrack_TrackUri =~ 'x-rincon-stream'\
? 'LineIn': $currentTrack_TrackUri =~ 'spdif'\
? 'TV' : ReadingsVal($name,'enqueuedMetadata_UpnpClass','') eq 'object.item.audioItem.audioBroadcast'\
? 'Radio' : 'Playlist'}
# to initiate setting the userReadings
set DEVICE volume {(ReadingsVal($DEV,'volume',''))}
setreading DEVICE attrTemplateVersion 20210218
Grüße Otto
Hallo,
Ich hab mal ein Template für eine Zigbee Rolladensteuerung für solche Geräte erstellt https://de.aliexpress.com/item/1005001804667020.html?spm=a2g0o.productlist.0.0.13847374Vsm0Ug&algo_pvid=9d995982-037c-404a-813e-1e99e9780f50&algo_expid=9d995982-037c-404a-813e-1e99e9780f50-16&btsid=0b0a0ae216138134418094780e99be&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_ (https://de.aliexpress.com/item/1005001804667020.html?spm=a2g0o.productlist.0.0.13847374Vsm0Ug&algo_pvid=9d995982-037c-404a-813e-1e99e9780f50&algo_expid=9d995982-037c-404a-813e-1e99e9780f50-16&btsid=0b0a0ae216138134418094780e99be&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_).
# A blind drive motor TS0601_cover connected via zigbee2mqtt
name:zigbee2mqtt_blind_drive
desc: A blind drive motor connected via zigbee2mqtt <br>Tested with: Tuya AM43 TS0601_cover
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_17b
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
par:ICON;ICON as set, defaults to fts_shutter_100;{ AttrVal("DEVICE","icon","fts_shutter_100") }
attr DEVICE icon ICON
attr DEVICE devStateIcon 0:fts_shutter_100@green 100:fts_shutter_10@white 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
attr DEVICE webCmd open:close:position
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT) }
attr DEVICE setList \
open:noArg $\DEVICETOPIC/set {"state":"OPEN"}\
close:noArg $\DEVICETOPIC/set {"state":"CLOSE"}\
position:slider,0,1,100 $\DEVICETOPIC/set {"position":"$EVTPART1"}
attr DEVICE stateFormat position
set DEVICE attrTemplate speechcontrol_gdt_and_mapping GENERICDEVTYPE=blind HOMEBRIDGEMAPPING="CurrentPosition=position,minValue=0,maxValue=100,minStep=100;TargetPosition=position,minValue=0,maxValue=100,minStep=100,cmds=0:close;;/.*/:open"
attr DEVICE model zigbee2mqtt_blind_drive
setreading DEVICE attrTemplateVersion 2021020200
Viel Spaß damit, wenn jemand die Geräte im Einsatz haben sollte.
Danke euch beiden, ist eingecheckt.
@barneybear:
Habe position nach pct gemappt, damit das eher im "fhem-üblichen" Sprachgebrauch bleibt (und entfärbt). Da wäre zum einen interessant, ob das noch klappt, und zum anderen, ob man dann nicht ein einfaches Sprachsteuerungs-mapping machen kann. Wäre nett, wenn du dazu Rückmeldung geben könntest.
(zum "Sprachgebrauch" auch: Standardisierung FHEM, wo wollen wir hin (https://forum.fhem.de/index.php/topic,118927.0.html) bzw. auch der dort verlinkte Thread von mir).
ZitatDanke euch beiden, ist eingecheckt.
Danke auch.
ZitatHabe position nach pct gemappt, damit das eher im "fhem-üblichen" Sprachgebrauch bleibt (und entfärbt).
Gute Idee, wenn man mit Werten zwischen 0-100 arbeitet den Standard beizubehalten. Ich weis zwar nicht woher das pct kommt, aber anscheinend wird es wohl auch für andere Shutter verwendet, was ich aber übersehen habe.
ZitatDa wäre zum einen interessant, ob das noch klappt, und zum anderen, ob man dann nicht ein einfaches Sprachsteuerungs-mapping machen kann
Klappen tut es und was meinst du mit ein einfaches Sprachsteuerungs-mapping?
Kleine Änderung noch am Code es heißt "blinds" und nicht "blind" ;D
Hab's jetzt erst mal radikal verkürzt:
set DEVICE attrTemplate speechcontrol_type_blind(Das war mit "einfachem mapping" gemeint).
Wäre nett, wenn du rückmelden könntest, ob das so auch ok ist (bei diesen Sprachsteuerungs-Themen gilt nach meiner bisherigen Erfahrung: "Weniger ist mehr"...)
Zitat von: barneybaer am 20 Februar 2021, 18:41:06
Gute Idee, wenn man mit Werten zwischen 0-100 arbeitet den Standard beizubehalten. Ich weis zwar nicht woher das pct kommt, aber anscheinend wird es wohl auch für andere Shutter verwendet, was ich aber übersehen habe.
"pct" kommt u.a. aus CUL_HM und hat sich bisher als unproblematisch erwiesen (und verständlich); sowas muss man nicht wissen, deswegen gibt es ja "Maintainer", die "blöde" Rückfragen dazu stellen ;D (oder andere (z.B. Otto123) mit dem Hinweis nerven, dass es für bestimmte Dinge "Vorgaben" gibt mit der Bitte, die zu beachten...).
ZitatWäre nett, wenn du Rückmelden könntest, ob das so auch ok ist (bei diesen Sprachsteuerungs-Themen gilt nach meiner bisherigen Erfahrung: "Weniger ist mehr"...)
Funktioniert super, ohne Homebridgemappings. Jedoch muss das Attribut genericDeviceType auf "blind" gesetzt werden, sonst wird das Gerät in Alexa nur als Lampe erkannt.
Dazu habe ich noch die Geschwindigkeit des Motors mit eingefügt (siehe Diff)
Edit: jsonMap angepasst in V2
Zitat von: jkleiner am 12 Januar 2021, 16:17:12
Hallo an Alle hier,
ich habe für das GoSound SP112 ab Juli 2020 ein Template erstellt und erfolgreich im Einsatz.
Verbesserungen immer gerne ;) ich hoffe es hilft jemanden noch was.
Hi, danke erstmal für das Template, funktioniert scheinbar schon besser als das tasmota_pow_usb_split, allerdings lassen sich weder channel1 noch channel2 über FHEM schalten, die readings aktualisieren
korrekt wenn man über das webinterface der "dose" selber schaltet, aber von der FHEM oberfläche aus geht schalten nicht.
EDIT: Läuft, das problem sitzt ja meist vor dem PC .... :)
Danke für das Template und sorry für das Threadnapping
fIRE
Zitat von: fire3k am 03 März 2021, 09:07:06
funktioniert scheinbar schon besser als das tasmota_pow_usb_split,
Wenn du Probleme mit dem tasmota_POW_USB_split hast, bitte entweder einen separaten Thread dazu aufmachen oder eine Meldung in https://forum.fhem.de/index.php/topic,94494.0.html absetzen.
Falls ihr den etwas speziellen Template-Vorschlag tasmota_Test_SP112_USB besprechen wollt, bitte ich das auch in einem separaten Thread zu machen (Link darf gerne von hier aus gesetzt werden).
Hallo zusammen!
Für den Shelly i3 mit Tasmota Firmware schreibe ich hier mein MQTT Template für die Einbindung in FHEM. Es ist an "tasmota_2channel_spit" angelehnt. Getestet mit Tasmota 9.2.0.
# shelly i3 3 channel input switches
name:tasmota_3channel_split
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:shelly i3 3 channel device flashed with Tasmota. <br>NOTE: a second and third device will be created for the second and third channel
order:A_03
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
par:CALLSPEECHRECOGN;Set this to 0 to not set any speech recogn. related attributes;{ 1 }
par:SETCHANNELINFO;Set this to 0 to not set any speech recogn. related attributes;{ 1 }
set DEVICE attrTemplate tasmota_basic_state_power1 \CALLSPEECHRECOGN=0
copy DEVICE DEVICE_CH2
deleteattr DEVICE_CH2 alias
attr DEVICE_CH2 readingList \
STATTOPIC/POWER2:.* state
attr DEVICE_CH2 jsonMap POWER1:0 POWER2:0 POWER3:0
attr DEVICE_CH2 setList \
off:noArg CMNDTOPIC/POWER2 0\
on:noArg CMNDTOPIC/POWER2 1\
toggle:noArg CMNDTOPIC/POWER2 2
attr DEVICE_CH2 setStateList on off toggle
copy DEVICE_CH2 DEVICE_CH3
attr DEVICE_CH3 readingList \
STATTOPIC/POWER3:.* state
attr DEVICE_CH3 setList \
off:noArg CMNDTOPIC/POWER3 0\
on:noArg CMNDTOPIC/POWER3 1\
toggle:noArg CMNDTOPIC/POWER3 2
attr DEVICE,DEVICE_CH2,DEVICE_CH3 model tasmota_3channel_split
setreading DEVICE,DEVICE_CH2,DEVICE_CH3 attrTemplateVersion 20210305
option:{SETCHANNELINFO}
set DEVICE attrTemplate set_associatedWith \CHANNELS=3
option:{ CALLSPEECHRECOGN }
set DEVICE,DEVICE_CH2,DEVICE_CH3 attrTemplate speechcontrol_type_switch
In der Tasmota Config für den i3 musste ich allerdings drei GPIO Pins als Pseudo-Relais setzen, da sonst alle Eingänge über MQTT immer nur als "POWER" gesendet werden.
Meine GPIO Config ist:
template {"NAME":"Shelly i3","GPIO":[224,0,0,0,0,0,0,0,193,194,192,225,226,4736],"FLAG":0,"BASE":18}
Hi @twdotnet,
vorab mal willkommen im Forum, starker "Aufschlag"!
Hab's eben in etwas veränderter Form eingeheckt (=> aus dem svn verfügbar oder ab morgen per update), wäre nett, wenn du Rückmeldung geben könntest, ob das so paßt oder ob was wichtiges verloren gegangen ist...
Danke für die Übernahme. Habe FHEM heute aktualisiert und das Template ausprobiert. Läuft!
Hallo,
leider bin ich nicht so fit, wie TWDOTNET. Bin eher nur Nutznießer der Arbeit, die hier im Forum geleistet wird. Ich wollte noch nachfragen, ob die Shelly Templates um den Shelly Motion erweitert werden, wenn er dann mal etwas breiter verwendet wird. Man kann ihn zwar in MQTT2 einbinden, aber es kommen natürlich nicht alle möglichen Readings.
LG Peter
Es gibt seit 26.02. ein shellymotion-Template, vlt. seit dem noch kein update gemacht ?
Neben dem Hinweis von TomLee noch:
Zitat von: Beta-User am 15 Dezember 2018, 11:45:40
Bitte nutzt möglichst diesen Thread, wenn ihr neue (im Prinzip ausentwickelte) templates für mqtt2.template vorschlagen wollt.
Für Fehlermeldungen, Diskussionen zu Verbesserungsvorschlägen zu vorhandenen und zum Anfragen von support für neue Devices ist ein weiterer Thread (https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200) gedacht, dieser hier sollte möglichst übersichtlich bleiben und sich auf das Wesentliche beschränken.
Zitat von: elektrikpe2 am 16 März 2021, 10:24:47
Ich wollte noch nachfragen, ob die Shelly Templates um den Shelly Motion erweitert werden, wenn er dann mal etwas breiter verwendet wird. Man kann ihn zwar in MQTT2 einbinden, aber es kommen natürlich nicht alle möglichen Readings.
=> Falscher Thread....
...und dann wäre da noch: https://forum.fhem.de/index.php/topic,112327.msg1066615.html#msg1066615
=> keine Infos...
Aber grundsätzlich: MQTT2_DEVICE generiert keine Readings, wenn die Hardware keine Daten liefert, und per default wird alles, was geliefert wird auch in Readings verwandelt...
ZitatBin eher nur Nutznießer der Arbeit, die hier im Forum geleistet wird.
Falls das ein Dankeschön gewesen sein sollte: :) .
Hallo,
a) richtig, hab es gelesen und doch nicht richtig interpretiert, mache im "richtigen Thread" weiter, mit den Ergebnissen, die sich hier schon ergeben haben und den Infos, die noch zu liefern wären
b) das war aber so was von einem Dankeschön. Bin seit 2018 dabei und inzwischen soweit, dass ich eine (von Frau bewilligte) FTUI habe mit der ich diverse Aktoren von diversen Firmen steuere. Die ist aber auch von einem User aus derm Forum "geklaut" . Also ohne Forum ginge bei mir garnix. Hab mich aber überall, wo mir geholfen wurde, artig bedankt
LG Peter
Hallo zusammen,
ich habe mich nun etwas mehr mit den Templates beschäftigt und für den Shelly i3 ein neues geschrieben.
Darin habe ich aus meiner Sicht unnötiges entfernt und um eine Auswahl mit Templates für die GPIOs und den SwitchModes als Parameter erweitert.
Wird Tasmota 9.1+ verwendet, kann die SetOption114 (https://tasmota.github.io/docs/Buttons-and-Switches/#setoption114) genutzt werden, um Switches von Relays zu trennen und auf die Pseudo-Relays zu verzichten.
Da dieser Shelly nur Inputs besitzt, macht aus meiner Sicht eine Vererbung von den bekannten Switches sowie eine Spracherkennung keinen Sinn.
Als Icon habe ich hier "taster" verwendet und für "order" würde ich "A_03i" vorschlagen.
Hier das AttrTemplate:
# shelly i3 3 channel input switches with device configuration
name:tasmota_3channel_input_shelly_i3
filter:TYPE=MQTT2_DEVICE
desc:Shelly i3 device flashed with Tasmota, provides three input only channels. <p>Device will be configured with selectable SwitchMode and optional GPIO Template. <br>Recommended SwitchModes 1=FollowMode (normally open switches> or 2=InvertedFollowMode (normally closed switches) </p><p>Tasmota 9.1+ is required for <a href=https://tasmota.github.io/docs/Buttons-and-Switches/#setoption114>SetOption114</a> to detach switches from relays. <br>For Tasmota <9.1 fake relays on GPIO2,GPIO3,GPIO4 will be used. In case of ghost switching try using SwitchMode=2 with normally closed switches on inputs. <p>NOTE: <br>A second and third device will be created for the second and third input with suffixes *_CH2 and *_CH3</p>
order:A_03i
par:RADIO_TEMPLATE;Configure device and GPIO with SetOption114 (for Tasmota 9.1+);{ undef }
par:RADIO_TEMPLATE_PRE91;Configure device and GPIO with fake relays (for Tasmota <9.1);{ undef }
par:RADIO_NO_TEMPLATE;Configure device without GPIO template;{ undef }
par:SWITCHMODE1;SwitchMode for Input 1;{ undef }
par:SWITCHMODE2;SwitchMode for Input 2;{ undef }
par:SWITCHMODE3;SwitchMode for Input 3;{ undef }
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
par:SETCHANNELINFO;Set this to 0 to not set channelinfo;{ 1 }
par:ICON;ICON as set, defaults to taster;{ AttrVal("DEVICE","icon","taster") }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev",undef)}
# autoconfigure device
option:{RADIO_NO_TEMPLATE}
set IO_DEV publish CMNDTOPIC/Backlog StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SwitchMode1 SWITCHMODE1; SwitchMode2 SWITCHMODE2; SwitchMode3 SWITCHMODE3; SetOption26 1; SetOption114 1; SaveData 1
option:{RADIO_TEMPLATE}
set IO_DEV publish CMNDTOPIC/Backlog StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SwitchMode1 SWITCHMODE1; SwitchMode2 SWITCHMODE2; SwitchMode3 SWITCHMODE3; SetOption26 1; SetOption114 1; SaveData 1; template {"NAME":"Shelly i3","GPIO":[0,0,0,0,0,0,0,0,193,194,192,0,0,4736],"FLAG":0,"BASE":18}; module 0
option:{RADIO_TEMPLATE_PRE91}
set IO_DEV publish CMNDTOPIC/Backlog StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SwitchMode1 SWITCHMODE1; SwitchMode2 SWITCHMODE2; SwitchMode3 SWITCHMODE3; SetOption26 1; SaveData 1; template {"NAME":"Shelly i3","GPIO":[0,0,224,225,226,0,0,0,193,194,192,0,0,4736],"FLAG":0,"BASE":18}; module 0
option:global
# setup main device channel 1
attr DEVICE icon ICON
attr DEVICE jsonMap Switch1_Action:state
attr DEVICE setList \
off:noArg STATTOPIC/Switch1 0\
on:noArg STATTOPIC/Switch1 1\
toggle:noArg STATTOPIC/Switch1 2
attr DEVICE readingList \
TELETOPIC/LWT:.* LWT\
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE setStateList on off toggle
attr DEVICE autocreate 0
attr DEVICE model tasmota_shelly_i3
# channel 2
copy DEVICE DEVICE_CH2
deleteattr DEVICE_CH2 alias
attr DEVICE_CH2 readingList \
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE_CH2 jsonMap Switch2_Action:state
attr DEVICE_CH2 setList \
off:noArg STATTOPIC/Switch2 0\
on:noArg STATTOPIC/Switch2 1\
toggle:noArg STATTOPIC/Switch2 2
# channel 3
copy DEVICE_CH2 DEVICE_CH3
deleteattr DEVICE_CH3 alias
attr DEVICE_CH3 jsonMap Switch3_Action:state
attr DEVICE_CH3 setList \
off:noArg STATTOPIC/Switch3 0\
on:noArg STATTOPIC/Switch3 1\
toggle:noArg STATTOPIC/Switch3 2
# associations
option:{SETCHANNELINFO}
set DEVICE attrTemplate set_associatedWith \CHANNELS=3
Noch ein allgemeiner Hinweis zu dem Device, was mir aufgefallen ist:
Nach einigen Tagen Betrieb ist ein sog. "Ghost Switching" aufgetreten. D.h. es werden Schaltimpulse erkannt, ohne das ein Schalter/Taster gedrückt wurde. In anderen Foren wurde das auch schon berichtet. Eine mögliche Ursache scheint das Design der Inputs zu sein, welche wohl über kein pull-up/down verfügen. Ich konnte für mich das einfach lösen, in dem ich die Taster von "Schließer" auf "Öffner" umgestellt habe. Damit liegt im Ruhezustand ein definiertes Potential an. In der Config muss dann für SwitchMode "2" verwendet werden.
Viele Grüße
Oliver
Hallöchen und einen guten Abend.
Ich hab mal wieder ein neues Template für ein Zigbee Thermostad.
https://www.zigbee2mqtt.io/devices/SEA801-Zigbee_SEA802-Zigbee.html#saswell-sea801-zigbee%252Fsea802-zigbee
Die "get" Befehle funktionieren nicht immer, nur selten. Temperatur und desired-temp werden sowieso bei Änderungen vom Thermostad gesendet.
name:zigbee2mqtt_thermostat_without_weekprofile
desc: Developed for <a href="https://www.zigbee2mqtt.io/devices/SEA801-Zigbee_SEA802-Zigbee.html#saswell-sea801-zigbee%252Fsea802-zigbee">Model Saswell SEA801-Zigbee/SEA802-Zigbee manufactured by Saswell</a> via zigbee2mqtt <br>
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_17b
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
par:ICON;ICON as set, defaults to temp_control;{ AttrVal("DEVICE","icon","temp_control") }
attr DEVICE icon ICON
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE setList \
desired-temp:slider,5.0,0.5,30.0,1 $\DEVICETOPIC/set {"current_heating_setpoint": "$EVTPART1"}\
btnLock:LOCK,UNLOCK $\DEVICETOPIC/set {"child_lock": "$EVTPART1"}\
mode:heat,auto,off $\DEVICETOPIC/set {"system_mode": "$EVTPART1"}\
away:ON,OFF $\DEVICETOPIC/set {"away_mode": "$EVTPART1"}\
window_detection:ON,OFF,TOOGLE $\DEVICETOPIC/set {"window_detection": "$EVTPART1"}
attr DEVICE periodicCmd temperature:55
attr DEVICE devStateIcon LOCKED:secur_lock:btnLock+UNLOCK UNLOCKED:secur_open:btnLock+LOCK
attr DEVICE webCmd desired-temp
attr DEVICE jsonMap current_heating_setpoint:desired-temp local_temperature:temperature Battery:batteryPercent system_mode:mode
attr DEVICE userReadings batteryState:battery_low.* {ReadingsVal($name,'battery_low','false') eq 'false'?'ok':'low'},\
state {ReadingsVal($name,'temperature','0')},
attr DEVICE model zigbee2mqtt_thermostat_without_weekrofile
set DEVICE attrTemplate speechcontrol_type_thermostat
deletereading -q DEVICE (?!associatedWith).*
setreading DEVICE attrTemplateVersion 20210401
Thx, hab's eingecheckt.
Zwei Anmerkungen:
- userReadings bitte immer mit trigger
- state sollte mAn. bei solchen Devices "frei" bleiben, das ist UU. eher für eine Art "Mode" geeignet, daher habe ich die gemessene Temperatur analog dem "with weekprofile" "nur" in den STATE (via stateFormat) befördert.
Hallo zusammen,
ich habe für die Steuerung eines Roon Core ein Template entwickelt.
Die Anbindung von Roon muss über die mqtt Extension eingerichtet sein https://github.com/fjgalesloot/roon-extension-mqtt (https://github.com/fjgalesloot/roon-extension-mqtt)
Enthalten ist auch die Sprachsteuerung über das Alexa Modul.
Folgendes geht zur einfachen Steuerung der Wiedergabe: an, aus, next, lauter, leiser, Laustärke X
Die Steuerung des Inhalts habe ich nur für Internetradios eingerichtet. Die Sendernamen sind konfigurierbar und werden in einem userattr abgelegt.
Das könnte man alternativ auch für Playlists einrichten.
Hier der Code:
#####
### roon via mqtt extension
###
name:roon
filter:TYPE=MQTT2_DEVICE
desc:See doku for roon mqtt extension https://github.com/fjgalesloot/roon-extension-mqttf
# first set the ZONE
par:ZONENAME;ZONENAME is the roon zone you want to control
attr DEVICE devicetopic ZONENAME
# define up to ten internet radio stations
attr DEVICE userattr radios
attr DEVICE radios BR-KLASSIK, MDR Klassik, Klassik Radio: Barock
# set readings
attr DEVICE readingList .*roon.*/$\DEVICETOPIC/state:.* state\
.*roon.*/$\DEVICETOPIC/seek_position:.* track_position\
.*roon.*/$\DEVICETOPIC/now_playing/three_line/line1:.* track_name\
.*roon.*/$\DEVICETOPIC/now_playing/three_line/line2:.* track_artist\
.*roon.*/$\DEVICETOPIC/now_playing/three_line/line3:.* track_album\
.*roon.*/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/value:.* volume\
.*roon.*/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/is_muted:.* muted\
.*roon.*/$\DEVICETOPIC/settings/loop:.* loop\
.*roon.*/$\DEVICETOPIC/settings/shuffle:.* shuffle
# setlist
# Commands to use in FHEM are with capital first letter ; the "mute" setting is for alexa only
attr DEVICE setList Play roon/$\DEVICETOPIC/command play\
Pause roon/$\DEVICETOPIC/command pause\
Stop roon/$\DEVICETOPIC/command stop\
Next roon/$\DEVICETOPIC/command next\
Previous roon/$\DEVICETOPIC/command previous\
mute:0,1 { if ($EVTPART1 == 1){"roon/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/set mute" ;;} else {"roon/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/set unmute" ;;}}\
volume:slider,0,1,100 roon/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/set $EVTPART1\
Mute roon/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/set mute\
Unmute roon/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/set unmute\
Radio:uzsuSelectRadio,1,2,3,4,5,6,7,8,9,10 { my @radios = split(/,/,AttrVal($NAME,"radios","BR-KLASSIK")) ;; "roon/$\DEVICETOPIC/browse/internet_radio ".$radios[$EVTPART1-1];; }
# some Web commands
attr DEVICE webCmd Play:Pause:Stop:Next:Previous:Mute:Unmute:volume:Radio
# optinal speech control with alexa
option:{my @devices=devspec2array("TYPE=(alexa)");;return 1 if $devices[0];;return 0}
attr DEVICE genericDeviceType media
set DEVICE attrTemplate speechcontrol_general_naming_master_template
# mapping for alexa
attr DEVICE homebridgeMapping\
On:cmdOn=Play,cmdOff=Stop\
PlaybackController:playback,values=Play;Pause;Stop;Previous;Next\
ChannelController:reading=radio,cmd=Radio\
Volume=volume,maxValue=60,minStep=3,delay=true\
Mute:reading=muted,cmd=mute
Starker Aufschlag!
Würde es in der folgenden Form einchecken, habe aber noch ein paar Fragen und Anmerkungen:
#####
### roon via mqtt extension
###
#contributed by mferstl, https://forum.fhem.de/index.php/topic,94495.msg1149947.html#msg1149947
name:roon
filter:TYPE=MQTT2_DEVICE
desc:See doku for roon mqtt extension https://github.com/fjgalesloot/roon-extension-mqttf
# first set the ZONE
par:ZONENAME;ZONENAME is the roon zone you want to control
attr DEVICE devicetopic ZONENAME
# define up to ten internet radio stations
attr DEVICE userattr radios
attr DEVICE radios BR-KLASSIK, MDR Klassik, Klassik Radio: Barock
# set readings
attr DEVICE readingList .*roon.*/$\DEVICETOPIC/state:.* state\
.*roon.*/$\DEVICETOPIC/seek_position:.* track_position\
.*roon.*/$\DEVICETOPIC/now_playing/three_line/line1:.* track_name\
.*roon.*/$\DEVICETOPIC/now_playing/three_line/line2:.* track_artist\
.*roon.*/$\DEVICETOPIC/now_playing/three_line/line3:.* track_album\
.*roon.*/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/value:.* volume\
.*roon.*/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/is_muted:.* muted\
.*roon.*/$\DEVICETOPIC/settings/loop:.* loop\
.*roon.*/$\DEVICETOPIC/settings/shuffle:.* shuffle
# setlist
# Commands to use in FHEM are with capital first letter ; the "mute" setting is for alexa only
attr DEVICE setList play roon/$\DEVICETOPIC/command play\
pause roon/$\DEVICETOPIC/command pause\
stop roon/$\DEVICETOPIC/command stop\
next roon/$\DEVICETOPIC/command next\
previous roon/$\DEVICETOPIC/command previous\
mute:on,off { my $mute = $EVTPART1 eq 'on' ? 'mute' : 'unmute';; "roon/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/set $mute"}\
volume:slider,0,1,100 roon/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/set $EVTPART1\
mute roon/$\DEVICETOPIC/outputs/$\DEVICETOPIC/volume/set mute\
channel:uzsuSelectRadio,1,2,3,4,5,6,7,8,9,10 { my @radios = split(/,/,AttrVal($NAME,"radios","BR-KLASSIK")) ;; "roon/$\DEVICETOPIC/browse/internet_radio ".$radios[$EVTPART1-1];; }
# some Web commands
attr DEVICE webCmd play:pause:stop:next:previous:mute:volume:radio
set DEVICE attrTemplate speechcontrol_gdt_and_mapping GENERICDEVTYPE=media HOMEBRIDGEMAPPING="On:cmdOn=play,cmdOff=stop PlaybackController:playback,values=play;pause;stop;previous;next ChannelController:reading=radio,cmd=radio Volume=volume,maxValue=60,minStep=3,delay=true Mute:reading=muted,cmd=mute"
- Die Kommandos sind klein, damit es zu https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV (https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV) paßt. Kann sein, dass damit das homebridgeMapping in Teilen nicht mehr erforderlich ist;
- mit "mute" ist es ähnlich, da ist die Vorgabe "mute" mit "on" bzw. "off". Eventuell wäre es möglich, den Inhalt aus dem Topic "is_muted" gleich so umzuwandeln, dass auch das ohne weiteres paßt (es müsste vermutlich ein Hash zurückgegeben werden wie z.B. { mute => 'off' })
Im Ergebnis sollte dann alles aus dem HomebridgeMapping raus, was nicht zwingend erforderlich ist.
- das homebridgeMapping ist jetzt "einzeilig"; kann sein, dass das eine der Sprachsteuerungslösungen nicht mag... Dann müßte man eventuell mal mit \n rumexperimentieren, sonst habe ich grade keine Idee, wie man das sauber in der Parameter-Form übergeben kann...
- Super wäre, $DEVICETOPIC gleich mit automatisch auswerten zu können. Da müßte ich aber wissen, wie so ein Topic im Original aussieht bzw. aussehen kann.
Hallo,
ich habe eine OBI-Steckdose mit ESPEasy geflashed und sehe im MQTT2 client das device, nur kann ich das Relais zum Schalten der Dose nicht ansteuern.
Ich finde auch kein Template für ESPEasy. Liegt das daran, dass es mit ESPEasy generell nicht funktioniert?
Ich schaffe es bislang nicht, dass das Relais geschalten wird.
setList cmd [topic|perl-Expression],
Hier das List:
Internals:
CFGFN
CID Steckdose_OBI_1
DEF Steckdose_OBI_1
DEVICETOPIC MQTT2_Steckdose_OBI_1
FUUID 607f35c5-f33f-6b52-c8ce-3277d017c72e29ed
IODev myMQTTBroker
LASTInputDev myMQTTBroker
MSGCNT 558
NAME MQTT2_Steckdose_OBI_1
NR 296838
STATE on
TYPE MQTT2_DEVICE
myMQTTBroker_MSGCNT 558
myMQTTBroker_TIME 2021-04-20 22:30:27
.attraggr:
.attrminint:
READINGS:
2021-04-20 22:13:06 LWT ontrack
2021-04-20 22:30:25 Relais 1
2021-04-20 22:13:48 Taster 0
2021-04-20 22:30:27 rssi -63.00
2021-04-20 22:30:15 state on
2021-04-20 22:30:27 uptime 17.00
Attributes:
DbLogExclude .*
IODev myMQTTBroker
readingList Steckdose_OBI_1:/Steckdose-OBI/Relais/Relais:.* Relais
Steckdose_OBI_1:/Steckdose-OBI/status/LWT:.* LWT
Steckdose_OBI_1:/Steckdose-OBI/WIFI/uptime:.* uptime
Steckdose_OBI_1:/Steckdose-OBI/WIFI/rssi:.* rssi
Steckdose_OBI_1:/Steckdose-OBI/Taster/Taster:.* Taster
room MQTT2_DEVICE
setList on /Steckdose-OBI/Relais/Relais 1
off /Steckdose-OBI/Relais/Relais 0
Gruß
Alex
Hi Homalix99,
deine Frage ist im falschen Thread gelandet, hier geht es um "fertige" attrTemplate, siehe 1. Beitrag hier.
ESPEasy war bisher hier nicht so das Thema (es gibt aber afaik einen Thread oder so), von daher:
Mach bitte einen neuen Thread auf, stelle da am besten ein "raw"-list ein und verlinke auf die Doku bzw. am besten auf die Detailseite darin, wo was dazu zu finden ist, wohin die Kommandos gesendet werden müssen. Es kann jedenfalls kaum richtig sein, dass die Topics in der setList dieselben sind wie die in der readingList. Das wäre m.E. ein schwerer Designfehler in der firmware.
Aus dem anderen Thread habe ich noch vage im Kopf, dass da als Payload die Nummer des Relays+gewünschter Schaltzustand zu senden sein sollten, also eher so in der Art:
on /Steckdose-OBI/Relais 1,1
(kann aber auch ganz falsch sein).
Zitat
- das homebridgeMapping ist jetzt "einzeilig"; kann sein, dass das eine der Sprachsteuerungslösungen nicht mag... Dann müsste man eventuell mal mit \n rumexperimentieren, sonst habe ich grade keine Idee, wie man das sauber in der Parameter-Form übergeben kann...
Ich glaube nicht, dass das so funktionieren kann. Das Attribut homebridgeMapping besteht i.A. aus mehreren Strings (die durch Leerzeichen getrennt werden).
Wenn man das als par HOMEBRIDGEMAPPING an das Sprachsteuerungs-Template übergibt, dann wird nur der erste String übernommen.
Ich habe schon etwas rumprobiert aber keine Lösung gefunden.
Das Problem besteht mWn. häufiger bzw. allgemein, wenn man mehr Infos hat. Ich hatte eigentlich gedacht, das mal während der Entwicklung des Konzepts ausgetestet zu haben, und dass es funktionieren sollte, wenn man den Gesamtstring in Anführungszeichen packt (und erforderlichenfalls andere nimmt als die, die man intern braucht).
Schade, dass es wohl nicht wie vorgeschlagen funktioniert.
(Muss mir dann dazu was überlegen, es müßte eigentlich irgendeinen Weg geben, das über den internen attrTemplate-Aufruf zu machen, denn das homebrideMapping-Thema will ich ungern in die mqtt2-File mit allen Verästelungen integrieren...)
Hi,
es gibt ein Template für den Xiaomi RoboRock mit valetudo. https://forum.fhem.de/index.php/topic,104804.0.html
Ich habe meinen Gen 1 mit valetudo RE ausgestattet, die topics und Features sind etwas anders, deswegen erstmal ein neues Template dafür.
Beim ersteren Template wurde Wert auf die Karte gelegt, die habe ich hier weggelassen.
# The rockrobo device for valetudo RE
name:roborockRE
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*valetudo[/].*
desc:use this for a rooted Xiamoni Vacuum / Roborock with valetudo RE installed. For details visit https://github.com/rand256/valetudo/wiki<br>NOTE: Only tested with Gen1, Forum Board MQTT<br>
order:X_04
par:BASE_TOPIC; is typically valetudo; {(split '/',ReadingsVal("DEVICE",'subscriptions','valetudo/rockrobo'))[0]}
par:DEV_ID; is typically rockrobo; {(split '/',ReadingsVal("DEVICE",'subscriptions','valetudo/rockrobo'))[1]}
par:ICON;ICON as set defaults to vacuum_top;{ AttrVal("DEVICE","icon","vacuum_top") }
{ Svn_GetFile("contrib/AttrTemplate/99_roborockUtils.pm", "FHEM/99_roborockUtils.pm", sub(){CommandReload(undef, "99_roborockUtils")}) }
defmod DEVICE MQTT2_\DEVICE DEV_ID
attr DEVICE icon ICON
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE alias DEV_ID
attr DEVICE readingList\
homeassistant/vacuum/BASE_TOPIC_DEV_ID/config:.* {}\
$\DEVICETOPIC/state:.* { json2nameValue($EVENT) }\
$\DEVICETOPIC/attributes:.* { json2nameValue($EVENT) }\
$\DEVICETOPIC/map_data:.* {}\
$\DEVICETOPIC/command_status:.* { json2nameValue($EVENT) }\
$\DEVICETOPIC/destinations:.* { valetudoREdest($EVENT) }
attr DEVICE setList\
charge:noArg $\DEVICETOPIC/command return_to_base\
fan_power:whisper,min,medium,high,max,mop $\DEVICETOPIC/set_fan_speed $EVTPART1\
locate:noArg $\DEVICETOPIC/command locate\
pause:noArg $\DEVICETOPIC/command pause\
spot:noArg $\DEVICETOPIC/command clean_spot\
start:noArg $\DEVICETOPIC/command start\
stop:noArg $\DEVICETOPIC/command stop\
get_dest:noArg { $\DEVICETOPIC.valetudoRE($EVENT) }\
goto:textField { $\DEVICETOPIC.valetudoRE($EVENT) }\
map:textField { $\DEVICETOPIC.valetudoRE($EVENT) }\
reset_consumable:main,side,filter,sensor { $\DEVICETOPIC.valetudoRE($EVENT) }\
zone:textField { $\DEVICETOPIC.valetudoRE($EVENT) }\
x_raw_payload:textField { $\DEVICETOPIC.valetudoRE($EVENT) }
attr DEVICE userReadings autoReturn:valetudo_state_name:.Idle {fhem("sleep $name:bin_in_time:.0 waitbin;set $name charge");return 'return'}
attr DEVICE setStateList charge fan_power get_dest goto locate map pause reset_consumable spot start stop zone x_raw_payload
attr DEVICE event-on-change-reading .*
attr DEVICE model roborockRE
setreading DEVICE attrTemplateVersion 20210510
Es gibt ein paar nette Feature gegenüber der bisherigen FHEM Modul Lösung durch valetudo RE:
Aktuelle Karte speichern (auf dem Gerät) und falls die Karte "weg" ist wieder laden.
Verwendung der Zielpunkte und Zonen aus der Valetudo RE App. Beides lässt sich als Liste einlesen.
Man könnte die auch komplett mit json2nameValue einlesen, das waren mir aber zu viele Readings ohne wirklichen Nutzen, deswegen die eigene Routine, die nur die Namen aus dem json extrahiert. Vielleicht geht die eleganter?
Das Rausnehmen des dustbin wird registriert und gemeldet. Das userReading verwendet dies und fährt den Sauger vom Mülleimer in die Station nachdem der dustbin geleert wurde. Vielleicht ist das aus der Kategorie: das tut man nicht? Find ich aber viel eleganter als zwei extra notify 😄
Ich bitte um eine kleine um Qualitätskontrolle.
Ich war mir unsicher bei der Verwendung der Platzhalter BASE_TOPIC DEV_ID - welche sind zu bevorzugen? In den Templates werden unterschiedliche verwendet. Bei der Verwendung der Sortierung war ich auch unsicher -> order:X_04
Es wird eine 99_Utils Datei verwendet / nachgeladen:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/AttrTemplate/99_roborockUtils.pm
Ich würde das Template als zweites zu RockRobo nach dem Ok einchecken?
Ich würde die Verwendung und Einrichtung dann mal noch separat vorstellen.
Gruß Otto
Zitat von: Otto123 am 10 Mai 2021, 23:35:28
[...]
deswegen die eigene Routine, die nur die Namen aus dem json extrahiert. Vielleicht geht die eleganter?
Die Routine schau ich mir bei Gelegenheit an.
ZitatDas Rausnehmen des dustbin wird registriert und gemeldet. Das userReading verwendet dies und fährt den Sauger vom Mülleimer in die Station nachdem der dustbin geleert wurde. Vielleicht ist das aus der Kategorie: das tut man nicht? Find ich aber viel eleganter als zwei extra notify 😄
Separate Devices anlegen finde ich auch die schlechtere Lösung für unseren speziellen Anwendungsfall.
Spontaner Eindruck (=muss nicht zielführend oder richtig sein): Der Reading-Name ist ziemlich "verschachtelt".
- Eventuell wäre es eine Idee, die Readings auch in einer eigenen Routine auszupacken (neben den Namen: eocr-Vorbehandlung?)
- die Routine zur Rückkehr könnte dort besser "versteckt" werden?
- Ob dann der Weg in die Ladestation angetreten werden soll, könnte ggf. der User (per userattr) entscheiden?
Zitat
Ich bitte um eine kleine um Qualitätskontrolle.
(Das übernehmen in der Regel dann schon auch die User ;) )
ZitatIch war mir unsicher bei der Verwendung der Platzhalter BASE_TOPIC DEV_ID - welche sind zu bevorzugen? In den Templates werden unterschiedliche verwendet.
Ist teilweise historisch gewachsen. Tendenz: BASE_TOPIC kann mehrere Elemente des Topic-Trees umfassen, (die Benennung ist häufig in der jeweiligen firmware etc. auch "base" oder ähnlich), DEV_ID ist eigentlich immer nur ein "Zweig" (zwischen "/"), der das jeweilige Gerät eindeutig bezeichnet.
Zitat
Ich würde das Template als zweites zu RockRobo nach dem Ok einchecken?
Bei der Verwendung der Sortierung war ich auch unsicher -> order:X_04
Wenn es schon was (ähnliches) gibt, am besten "irgendwie" dazusortieren. Ich habe da keine zwingende Logik; das ursprüngliche Nummernsystem hatte ich irgendwo mal erläutert, aber wenn es z.B. ein Kaufsystem mit MQTT(-Erweiterung) und eine freie firmware-Variante gibt, würde ich eher dazu tendieren, das untereinander zu bringen (mit einem "a" Index oä.; ggf. etwas "Platz" lassen, damit man erforderlichenfalls Varianten noch dazwischensortieren kann. Notfalls kann man aber einfach auch die Nummern ändern, falls sich dazu eine Notwendigkeit ergibt, die man nicht anders in den Griff bekommt).
Wichtiger finde ich, dass man das als User irgendwie (wieder-) findet, wenn man einfach so (in FHEMWEB) mal schaut, was es so alles gibt...
Zitat von: Beta-User am 11 Mai 2021, 07:53:55
Die Routine schau ich mir bei Gelegenheit an.
da war mein erster Versuch und die Messlatte die leicht abgeänderte Routine von Rudi. Die extrahiert immerhin von innen die interessanten json Objekte nach außen.
{ my (%h,$cnt); $EVENT=~ s/(\{[^{]*?})/$h{"SpotZone_".++$cnt}=$1/ge; \%h }Aber dann hab ich es anders gemacht. :)
Zitat von: Beta-User am 11 Mai 2021, 07:53:55
Spontaner Eindruck (=muss nicht zielführend oder richtig sein): Der Reading-Name ist ziemlich "verschachtelt".
- Eventuell wäre es eine Idee, die Readings auch in einer eigenen Routine auszupacken (neben den Namen: eocr-Vorbehandlung?)
Die Original payloads sind schon so
valetudo_state das ist dann wieder ein json und json2nameValue macht das draus
valetudo_state_nameDa habe ich dann das mentale Problem: Packt man das json Objekt formatiert in ein Reading - oder lässt man es lieber den Sack mit Readings?
Insgesamt finde ich die Readings in dem Device noch übersichtlich.
eocr .* habe ich schon drin!
Wenn einer das userReading mit Rückkehr nicht haben will, kann er es ja einfach löschen? Ich kann den Code auch inaktiv in den Kommentar packen?
Hast Du an andere Stelle schon mal was eingebaut um die Utils Datei (aus dem contrib) zu aktualisieren? Quasi ein update des Device Codes? Sollte man das machen?
Ich sortiere das Template als X_03a ein :) -
Edit: eingecheckt
Zitat von: Otto123 am 11 Mai 2021, 13:00:32
Da habe ich dann das mentale Problem: Packt man das json Objekt formatiert in ein Reading - oder lässt man es lieber den Sack mit Readings?
Insgesamt finde ich die Readings in dem Device noch übersichtlich.
eocr .* habe ich schon drin!
Ging eher darum, das ggf. samt "Umbenennung" in der myUtils unterzubringen; es gibt dazu einen "Master" mit diesem go-echarger, zu finden über https://forum.fhem.de/index.php/topic,116162.msg1109103.html#msg1109103.
Zitat
Wenn einer das userReading mit Rückkehr nicht haben will, kann er es ja einfach löschen? Ich kann den Code auch inaktiv in den Kommentar packen?
Ist m.E. kein echtes Problem, das so zu lösen.
Zitat
Hast Du an andere Stelle schon mal was eingebaut um die Utils Datei (aus dem contrib) zu aktualisieren? Quasi ein update des Device Codes? Sollte man das machen?
Einen "update-Buttom"? Nicht, soweit ich mich spontan entsinne.
Wer ein update haben will, kann ja das attrTemplate nochmal anwenden, das ist das einfachste...
Für alle anderen könnte man was in comment (z.B.) einbauen, damit die den Befehl c&p finden können? Und/oder Wiki/erster Beitrag im "Hauptthread"?...
(oder über die cref von der myUtils!)
Hallo zusammen
Gibt es irgendwo eine Übersicht welches Template für welche Hardware verwendet werden kann?
Ich habe folgendes Problem: wir haben meinen Kindern ein billiges LED-Strip Set in China gekauft, da sind die einfachen Magic-Home mit dem ESP8266 drin. Nun habe ich da ein aktuelles Tasmota (2.7.4.9) drauf gespielt, bis hierhin alles ok. Über die Web-Seite direkt auf dem Controller läuft alles ok. Welches Template muss ich nun verwenden (ich denke irgend eines mit dem "tasmota_.......)?
Das mit dem "tasmota_rgbw...." macht bei mir nicht das was es eigentlich sollte: zb. "on" -> setzt auf rot, "off" -> blau.
da ich mich mit json überhaupt nicht auskenne, kann ich auch nicht einfach ein eigenes Template erstellen.
Ach ja: auf dem Magic-Home (tasmota) habe ich natürlich auf "Magic-Home(34)" eingestellt.
was mache ich falsch
1. Im falschen Thread fragen!
2. (vermutlich) das falsche Tasmota-Template zur (ESP-) Konfiguration nutzen.
Bitte erst mal checken, ob der ESP über das Webinterface zu bedienen ist, und wenn ja, einen eigenen Thread dafür aufmachen. Wenn nein: blakadder konsultieren.
danke für die überaus hilfreiche Antwort, es ist mir absolut bewusst das ich nicht die teuerste Hardware und die beste Software nutze
Zitat von: Haus-Andi am 14 Mai 2021, 12:51:22
danke für die überaus hilfreiche Antwort, es ist mir absolut bewusst das ich nicht die teuerste Hardware und die beste Software nutze
Den ersten Beitrag in diesem Thread hier kann man ganz kostenlos lesen; dauert auch nicht lange...
nur einfach zur Info: genau das habe ich gemacht und genau darum habe ich hier versucht zu erfragen ob es im ganzen System irgendwo irgend eine Tabelle oder übersicht über die template gibt.
Ist ja auch egal die Tage mit fhem sind bei mir eh angezählt, werde die Sache halt mal etwas zur Seite legen und zuerst das neue System aufbauen müssen.
Gruss
Zitat von: Beta-User am 15 Dezember 2018, 11:45:40
[...] Bitte nutzt möglichst diesen Thread, wenn ihr neue (im Prinzip ausentwickelte) templates für mqtt2.template vorschlagen wollt.
Für Fehlermeldungen, Diskussionen zu Verbesserungsvorschlägen zu vorhandenen und zum Anfragen von support für neue Devices ist ein weiterer Thread (https://forum.fhem.de/index.php/topic,94494.msg872200.html#msg872200) gedacht, dieser hier sollte möglichst übersichtlich bleiben und sich auf das Wesentliche beschränken.
[...]
- tasmota: https://forum.fhem.de/index.php/topic,94434.0.html (https://forum.fhem.de/index.php/topic,94434.0.html)
Wenn du das _genau_ gemacht hättest, dann wäre diese Frage _nicht hier_ gelandet, sondern entweder bei "tasmota" oder bei "Fragen/bugs...".
Jedenfalls enthält dein Beitrag KEINEN attrTemplate-Vorschlag, oder?
Ansonsten: Wenn das rgbw-template nicht passt, müsste das Teil entweder einen Kanal mehr oder weniger haben. Dann ist es entweder das rgb-led-controller Teil, oder eben mit cct-Anteil. Mehr wie die 4 bzw. 5 light-Varianten, die direkt untereinder gelistet sind, gibt es afaik derzeit nicht, und wenn der Controller die Befehle missinterpretiert, dann liegt das entweder an der Zahl der Kanäle oder es ist ein genereller Bug, evtl., weil sich bei Tasmota was geändert hat (meine laufen seit neuestem auf 9.irgendwas, btw.).
Hallo Beta-User,
bezüglich den Posts #32 (https://forum.fhem.de/index.php/topic,70273.msg1155276.html#msg1155276), #33 (https://forum.fhem.de/index.php/topic,70273.msg1155519.html#msg1155519) und #36 (https://forum.fhem.de/index.php/topic,70273.msg1155702.html#msg1155702)
habe ich das
mqtt2_siedle.template (siehe Anhang) noch einmal etwas angepasst.
Das Template ist soweit funktionstüchtig.
Deine Änderungen
Zitat von: Beta-User am 11 Mai 2021, 12:34:20
... mit denselben Reading-Namen wie aus dem Modul bekannt ...
habe ich mir erlaubt zu übernehmen.
Könntest du bitte noch einmal kurz drüber schauen, ob man es so verteilen kann?
Dankeschön
Gruß, Karsten
thx, hab's eingecheckt, passt; (jedenfalls, soweit ich das im Moment beurteilen kann).
Habe dann noch den logging-Pfad bei der zigbee2mqtt-Bridge (siehe hier (https://forum.fhem.de/index.php/topic,94494.msg1156128.html#msg1156128)) ergänzt (mit Prefix) und bei Tasmota dieses "Info-feature" über den regex-Weg (https://forum.fhem.de/index.php/topic,94494.msg1155541.html#msg1155541) auf einen einheitlichen Stand gebracht (jedenfalls hoffe ich, alle relevanten Stellen erwischt zu haben).
Bitte (im "bugs-" Thread) melden, wenn jemand das nicht gut findet bzw. bessere oder ergänzende Vorschläge hat.
Zitat von: Beta-User am 15 Mai 2021, 15:44:59
thx, hab's eingecheckt, passt; (jedenfalls, soweit ich das im Moment beurteilen kann).
Erste Tests sind positiv :)
Was noch nicht gehtZitat von: Beta-User am 10 Mai 2021, 13:38:50
Zitat
- Aktualisierung des Readings result (geöffnetet Device in der WEB-Oberfläche)
Wenn an der Gegensprechanlage/Türklingel ein cmnd gesendet wird, aktualisieren sich die Readings bezüglich result sofort.
Wenn mit "set <DEVICE> light/open" ein Kommando an die Anlage gesendet wird,
funktioniert es zwar das light/open ausgeführt werden, doch die Readings bezüglich result aktualisieren sich nicht.
Erst wenn das Device erneut in der WEB-Oberfläche geöffnet wird.
In MQTT.fx werden die Topics in der richtigen Reihenfolge sauber erkannt.
Ist eventuell die Zeit zwischen den Topics zu kurz?
An ein Zeitproblem glaube ich nicht, da müßte man mal den MQTT-Verkehr auswerten. Seltsam ist, dass scheinbar die Werte ankommen, (sonst wären sie beim Neu laden der Detailansicht nicht da) aber nicht triggern. Sowas passiert eigentlich afaik nur dann, wenn man am Dispatch-Mechanismus vorbei was aktualisiert. (Musst du nicht verstehen, ich habe aber auch im Moment keine Erklärung, wo das herkommen könnte).
ist in dem Fall nicht weiter schlimm, wer hat schon die Detailansicht dauerhaft offen ;)
Edit 2021_05_16:
Geht doch, Thema erledigt.
Zitat
... Habe dann noch den logging-Pfad bei der zigbee2mqtt-Bridge (siehe hier (https://forum.fhem.de/index.php/topic,94494.msg1156128.html#msg1156128)) ergänzt (mit Prefix) ...
Funktioniert jetzt auch, ohne das ein weiteres Device angelegt wird.
Jeder Erstling wird es dir danken :)
Dankeschön für deine Unterstützung
Schönen Sonntag noch 8)
Gruß, Karsten
Zitatdoch die Readings bezüglich result aktualisieren sich nicht.
Erst wenn das Device erneut in der WEB-Oberfläche geöffnet wird.
Vielleicht liegt es daran, dass das JavaScript-Programm im Browser nur vorhandene Elemente (vulgo Readings-Zeilen) aktualisiert, aber keine neuen dazubaut.
Zitat
... nur vorhandene Elemente (vulgo Readings-Zeilen) aktualisiert, aber keine neuen dazubaut.
Die Readings sind schon vorhanden gewesen.
Jetzt hab ich mir gedacht, ok, versuchst es mal mit dem Edge.
Funktioniert wie es soll, Readings werden sofort aktuallisiert.
Wieder zurück zum Firefox, kontrolliert ob NoScript mir dazwischenfunkt, aber die Seite ist freigegeben.
Und was soll ich sagen, es werden die Readings sofort aktuallisiert. :o
Keine Ahnung mit was das zusammengewirkt hat das es vorher nicht funktioniert hatte.
Entschuldigung wenn ich hier Pferde scheu gemacht habe. :-[
Für mich ist das Thema erledigt.
Dankeschön für die Unterstützung.
Schönen Sonntag noch
Gruß, Karsten
Hallo, hier wieder ein Patch für den "blind drive motor TS0601_cover" bei welchem die Stop-Funktion eingefügt wird.
--- mqtt2.template 2021-08-17 20:02:31.333269762 +0200
+++ mqtt2.template_neu 2021-08-31 23:28:39.000000000 +0200
@@ -544,13 +544,14 @@
par:ICON;ICON as set, defaults to fts_shutter_100;{ AttrVal("DEVICE","icon","fts_shutter_100") }
attr DEVICE icon ICON
attr DEVICE devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
-attr DEVICE webCmd open:close:pct:speed
+attr DEVICE webCmd open:close:stop:pct:speed
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE jsonMap position:pct motor_speed:speed
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE setList \
open:noArg $\DEVICETOPIC/set {"state":"OPEN"}\
close:noArg $\DEVICETOPIC/set {"state":"CLOSE"}\
+ stop:noArg $\DEVICETOPIC/set {"state":"STOP"}\
pct:slider,0,1,100 $\DEVICETOPIC/set {"position":"$EVTPART1"}\
speed:colorpicker,BRI,0,1,255 $\DEVICETOPIC/set {"options": {"motor_speed":"$EVTPART1"}}
attr DEVICE stateFormat pct
Danke für den Patch, ist schon ein paar Tage im svn verarbeitet (neben ein paar anderen "Kleinigkeiten").
Allgemeiner Hinweis: Generell ist für sowas der mqtt2.template: bugs, Fragen, Anregungen -Thread gedacht, hier soll eigentlich nicht groß diskutiert werden (was vorliegend auch keinen großen Sinn hätte).
Hallo,
ich habe ein paar "Moes 3 Channel Schalter" und das zigbee2mqtt_3channel_split Template benutzt. Um es korrekt nutzen zu können musste ich etwas ergänzen, welches ich mir beim 2 Kanal schalter abgeguckt habe. Bei Bedarf bitte gerne im Git anpassen. Danke
For zigbee2mqtt 3 channel device like Silvercrest Steckerleiste »Zigbee Smart Home«.
NOTE: Two additional devices will be created for further channels.
NOTE: Untested updated version
attr DEVICE icon ICON
attr DEVICE eventMap { dev=>{ON=>'on',OFF=>'off'} }
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap state:availability state_l1:state state_l2:0 state_l3:0
attr DEVICE setList \
on:noArg $\DEVICETOPIC/1/set {"state_l1":"ON"}\
off:noArg $\DEVICETOPIC/1/set {"state_l1":"OFF"}\
toggle:noArg $\DEVICETOPIC/1/set {"state_l1":"TOGGLE"}
attr DEVICE setStateList on off toggle
deletereading -q DEVICE (?!associatedWith|IODev).*
set DEVICE attrTemplate set_associatedWith \CHANNELS=3 \MAKECOPIES=1
attr DEVICE_CH2 setList \
on:noArg $\DEVICETOPIC/2/set {"state_l2":"ON"}\
off:noArg $\DEVICETOPIC/2/set {"state_l2":"OFF"}\
toggle:noArg $\DEVICETOPIC/2/set {"state_l2":"TOGGLE"}
attr DEVICE_CH2 jsonMap state_l2:state state_l1:0 state_l3:0 state:0 consumption:0 linkquality:0 power:0 temperature:0
attr DEVICE_CH3 setList \
on:noArg $\DEVICETOPIC/3/set {"state_l3":"ON"}\
off:noArg $\DEVICETOPIC/3/set {"state_l3":"OFF"}\
toggle:noArg $\DEVICETOPIC/3/set {"state_l3":"TOGGLE"}
attr DEVICE_CH2 jsonMap state_l3:state state_l1:0 state_l2:0 state:0 consumption:0 linkquality:0 power:0 temperature:0
set DEVICE,DEVICE_CH2,DEVICE_CH3 attrTemplate speechcontrol_type_switch
attr DEVICE,DEVICE_CH2,DEVICE_CH3 model zigbee2mqtt_3channel_split
setreading DEVICE,DEVICE_CH2,DEVICE_CH3 attrTemplateVersion 20211030
ändern in:
on:noArg $\DEVICETOPIC/l2/set {"state_l2":"ON"}\
off:noArg $\DEVICETOPIC/l2/set {"state_l2":"OFF"}\
toggle:noArg $\DEVICETOPIC/l2/set {"state_l2":"TOGGLE"}
.....
on:noArg $\DEVICETOPIC/l3/set {"state_l3":"ON"}\
off:noArg $\DEVICETOPIC/l3/set {"state_l3":"OFF"}\
toggle:noArg $\DEVICETOPIC/l3/set {"state_l3":"TOGGLE"}
[/code]
Das "l" fehlte bei state_l2 und l3.
Danke für den Hinweis, hab's gefixt (frage mich aber, warum das bei dem ersten Kanal anders ist).
Kleine Anmerkung: für sowas gibt es eigentlich den "bugs, ..."-Thread (siehe link im eresten Beitrag hier).
Wenn sich Software komplett ändert...
Wie handhaben wir das dann?
Template aufblasen mit Versionserkennung?
Davon ausgehen: ab "heute" ist alles neu - die Templates für alte Versionen sind ja längst angewendet - und die alten Templates neumachen?
Ich habe das Gefühl das trifft uns stückweise bei tasmota, bei shelly sind es neue Geräte, ok dann neue Templates - aber...
Ganz konkret habe ich das bei valetudo, die haben eine völlig neue MQTT Struktur gemacht.
Mach ich jetzt das dritte valetudo Template oder das Alte neu? Die mqtt2.template Datei im SVN hat jetzt schon 5000+ Zeilen :'(
Gliedern wir die mqtt2.template thematisch weiter in Dateien?
Meine bisherige "Leitlinie" war:
Das aktuell verfügbare Haupt-Template sollte zum "stable"-Stand der firmware passen, und FHEM selbst muss auch auf dem aktuellen Stand sein (Rudi hat ja immer mal wieder ein neues feature möglich gemacht :) ).
In einigen Fällen ist dann das "alte" template noch eine Weile verfügbar gewesen, bis es dann irgendwann entsorgt wurde (müßte checken, ob das Sinn macht, mal wieder aufzuräumen).
Komplizierte Unterscheidungen würde ich nicht machen, andererseits: mit "option" kann man ggf. übergangsweise auch arbeiten - was halt am wenigsten Aufwand macht...
Wegen der Zeilenzahl: ...einerseits ja sehr erfreulich, weil "einiges geboten" ist, andererseits "frißt" es (etwas) Speicher. Rudi hatte mich deswegen erst mal beruhigt, als ich diesbezüglich auch Bedenken geäußert hatte.
Aufsplitten in mehrere Files wäre denkbar, allerdings sollten es dann schon "signifikante Brocken" sein, und ob das die Übersichtlichkeit erhöht? (Ich "klaue" gern bei mir selbst, und dann ist es einfacher, die Einheitsfile zu durchsuchen).
Wegen valetudo: Die alte Implementierung war doch sowieso mehr oder weniger "kaputt", da sollten wir schlicht "nur noch neu" fahren (weil auch aus User-Sicht ein firmware-update dringend zu empfehlen ist, oder?).
Hallo Beta-User,
nach viel probieren und langem Suchen habe ich gerade festgestellt, dass die Template Files nur geladen werden wenn in der Datei das UNIX Zeilenende (LF) verwendet wird. Mit dem Windows (CR/LF) oder Mac (CR) Zeilenende werden die entsprechenden Dateien nicht geladen. Falls das kein Fehler ist wäre es sehr hilfreich wenn du es im ersten Post des Threads und im Wiki als Voraussetzung für die Erstellung von eigenen Template Files festhalten könntest.
Gruß Reinhard
ZitatMit dem Windows (CR/LF) oder Mac (CR) Zeilenende werden die entsprechenden Dateien nicht geladen.
Geladen werden sie, aber vmtl. nicht so verarbeitet, wie gewuenscht.
Nur aus Interesse: Wie kommt man zu "Mac"-Zeilenenden?
Zitat von: Reinhard.M am 22 Januar 2022, 15:08:17
Falls das kein Fehler ist wäre es sehr hilfreich wenn du es im ersten Post des Threads und im Wiki als Voraussetzung für die Erstellung von eigenen Template Files festhalten könntest.
Danke für den Hinweis, hab's reingeknödelt...
Hallo,
ich beschäftige mich grade auch mit dem mqtt2.template.
Auf https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/lib/AttrTemplate/mqtt2.template (https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/lib/AttrTemplate/mqtt2.template)
sieht der Bereich für den Shelly 1PM Plus anderst aus wie das Template das sich auf meinem Rapsberry befindet.
Mit stellt sich die Frage wie ich dieses den aktualisiere?
Einfach den Text von Git Hub in die Datei des Pi kopieren (alte Datei vorher sichern und dann neue anlegen)?
Wie läuft das generel mit dem Updaten der templates?
Geht das aus der FHEM GUI?
Gruß
Christian
Per regulärem update-Befehl werden auch die attrTemplate-files aktualisiert.
Btw:
- die Frage ist in diesem Thread OT
- ich verstehe nicht so recht, wieso du nicht auf das FHEM-svn verlinkt hast. Da wäre die Datei noch aktueller...
Hey, habe auch ein kleines problem mit dem Template zigbee2mqtt_light_dimmer (auch bei der Fernbedienung). Vorher hatte ich folgendes readingList:
$DEVICETOPIC:.* { json2nameValue($EVENT) }
das neue lautet jetzt:
$DEVICETOPIC:.* { my $ret=json2nameValue($EVENT); $ret->{state}=lc($ret->{state}); return $ret }
und ich bekomme im log folgendes angezeigt
2022.09.09 16:10:25 1: PERL WARNING: Use of uninitialized value in lc at (eval 225048) line 1.
2022.09.09 16:10:25 3: eval: my $CID= $evalSpecials->{'%CID'};my $DEVICETOPIC= $evalSpecials->{'%DEVICETOPIC'};my $EVENT= $evalSpecials->{'%EVENT'};my $EVTPART0= $evalSpecials->{'%EVTPART0'};my $JSONMAP= $evalSpecials->{'%JSONMAP'};my $NAME= $evalSpecials->{'%NAME'};my $TOPIC= $evalSpecials->{'%TOPIC'};{ my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=lc($ret->{state});; return $ret }
Ist da ein Fehler drin, oder fehlt was bei mir?
LG Patrick
Eigentlich ist das der falsche Thread, siehe den ersten Beitrag hier und die Links dort.
Es scheint also Fälle zu geben, in denen wider Erwarten (neuerdings?) auch andere JSON-Blobs kommen. Bitte mal so ändern:
$DEVICETOPIC:.* { my $ret=json2nameValue($EVENT); $ret->{state}=lc($ret->{state}) if defined $ret->{state}; return $ret }
Zitat von: Beta-User link=topic=code][/code]94495.msg1234300#msg1234300 date=1662734436]
Eigentlich ist das der falsche Thread, siehe den ersten Beitrag hier und die Links dort.
Sorry dafür.
Aber mit dem neuen Topic funktioniert es.
Danke
Edit: Doch leider nicht.
2022.09.09 17:10:22 1: PERL WARNING: Use of uninitialized value in lc at (eval 230682) line 1.
2022.09.09 17:10:22 3: eval: my $CID= $evalSpecials->{'%CID'};my $DEVICETOPIC= $evalSpecials->{'%DEVICETOPIC'};my $EVENT= $evalSpecials->{'%EVENT'};my $EVTPART0= $evalSpecials->{'%EVTPART0'};my $JSONMAP= $evalSpecials->{'%JSONMAP'};my $NAME= $evalSpecials->{'%NAME'};my $TOPIC= $evalSpecials->{'%TOPIC'};{ my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=lc($ret->{state});; return $ret }
Zitat von: MiKn am 13 November 2021, 00:01:42
Hallo,
ich habe ein paar "Moes 3 Channel Schalter" und das zigbee2mqtt_3channel_split Template benutzt. Um es korrekt nutzen zu können musste ich etwas ergänzen, welches ich mir beim 2 Kanal schalter abgeguckt habe. Bei Bedarf bitte gerne im Git anpassen. Danke
For zigbee2mqtt 3 channel device like Silvercrest Steckerleiste »Zigbee Smart Home«.
NOTE: Two additional devices will be created for further channels.
NOTE: Untested updated version
attr DEVICE icon ICON
attr DEVICE eventMap { dev=>{ON=>'on',OFF=>'off'} }
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap state:availability state_l1:state state_l2:0 state_l3:0
attr DEVICE setList \
on:noArg $\DEVICETOPIC/1/set {"state_l1":"ON"}\
off:noArg $\DEVICETOPIC/1/set {"state_l1":"OFF"}\
toggle:noArg $\DEVICETOPIC/1/set {"state_l1":"TOGGLE"}
attr DEVICE setStateList on off toggle
deletereading -q DEVICE (?!associatedWith|IODev).*
set DEVICE attrTemplate set_associatedWith \CHANNELS=3 \MAKECOPIES=1
attr DEVICE_CH2 setList \
on:noArg $\DEVICETOPIC/2/set {"state_l2":"ON"}\
off:noArg $\DEVICETOPIC/2/set {"state_l2":"OFF"}\
toggle:noArg $\DEVICETOPIC/2/set {"state_l2":"TOGGLE"}
attr DEVICE_CH2 jsonMap state_l2:state state_l1:0 state_l3:0 state:0 consumption:0 linkquality:0 power:0 temperature:0
attr DEVICE_CH3 setList \
on:noArg $\DEVICETOPIC/3/set {"state_l3":"ON"}\
off:noArg $\DEVICETOPIC/3/set {"state_l3":"OFF"}\
toggle:noArg $\DEVICETOPIC/3/set {"state_l3":"TOGGLE"}
attr DEVICE_CH2 jsonMap state_l3:state state_l1:0 state_l2:0 state:0 consumption:0 linkquality:0 power:0 temperature:0
set DEVICE,DEVICE_CH2,DEVICE_CH3 attrTemplate speechcontrol_type_switch
attr DEVICE,DEVICE_CH2,DEVICE_CH3 model zigbee2mqtt_3channel_split
setreading DEVICE,DEVICE_CH2,DEVICE_CH3 attrTemplateVersion 20211030
ändern in:
on:noArg $\DEVICETOPIC/l2/set {"state_l2":"ON"}\
off:noArg $\DEVICETOPIC/l2/set {"state_l2":"OFF"}\
toggle:noArg $\DEVICETOPIC/l2/set {"state_l2":"TOGGLE"}
.....
on:noArg $\DEVICETOPIC/l3/set {"state_l3":"ON"}\
off:noArg $\DEVICETOPIC/l3/set {"state_l3":"OFF"}\
toggle:noArg $\DEVICETOPIC/l3/set {"state_l3":"TOGGLE"}
[/code]
Das "l" fehlte bei state_l2 und l3.
Ich habe daraus einen 5er-Split gebaut (getestet):
!Ich musste danach FHEM neu starten, damit die Dinger schalten; davor konnte nur das original Device schalten. Jetzt klappts.
# zigbee2mqtt 5 channel device
name:zigbee2mqtt_5channel_split
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
desc:For zigbee2mqtt 5 channel device like UseeLink Steckerleiste SM-0306E-2W. <br>NOTE: Four additional devices will be created for further channels.<br>NOTE: Untested updated version
order:L_05g
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
par:ICON;ICON as set, defaults to message_socket;{ AttrVal('DEVICE','icon','message_socket') }
attr DEVICE icon ICON
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP); $ret->{state}=lc($ret->{state}); return $ret }
attr DEVICE jsonMap state:availability state_l1:state state_l2:0 state_l3:0 state_l4:0 state_l5:0
attr DEVICE setList \
on:noArg $\DEVICETOPIC/set {"state_l1":"ON"}\
off:noArg $\DEVICETOPIC/set {"state_l1":"OFF"}\
toggle:noArg $\DEVICETOPIC/set {"state_l1":"TOGGLE"}
attr DEVICE setStateList on off toggle
deletereading -q DEVICE (?!associatedWith|IODev).*
set DEVICE attrTemplate set_associatedWith \CHANNELS=5 \MAKECOPIES=1
loop:#:2:3:4:5
defmod DEVICE_CH# MQTT2_\DEVICE
attr DEVICE_CH# setList \
on:noArg $\DEVICETOPIC/set {"state_l#":"ON"}\
off:noArg $\DEVICETOPIC/set {"state_l#":"OFF"}\
toggle:noArg $\DEVICETOPIC/set {"state_l#":"TOGGLE"}
loop:END
attr DEVICE_CH2 jsonMap state_l2:state state_l1:0 state_l3:0 state_l4:0 state_l5:0 state:0
attr DEVICE_CH3 jsonMap state_l3:state state_l1:0 state_l2:0 state_l4:0 state_l5:0 state:0
attr DEVICE_CH4 jsonMap state_l4:state state_l1:0 state_l2:0 state_l3:0 state_l5:0 state:0
attr DEVICE_CH5 jsonMap state_l5:state state_l1:0 state_l2:0 state_l3:0 state_l4:0 state:0
set DEVICE,DEVICE_CH2,DEVICE_CH3,DEVICE_CH4,DEVICE_CH5 attrTemplate speechcontrol_type_switch
attr DEVICE,DEVICE_CH2,DEVICE_CH3,DEVICE_CH4,DEVICE_CH5 model zigbee2mqtt_5channel_split
setreading DEVICE,DEVICE_CH2,DEVICE_CH3,DEVICE_CH4,DEVICE_CH5 attrTemplateVersion 20221007
Für z.B. das hier:
https://smile.amazon.de/UseeLink-Steckdosenleiste-erforderlich-Einzelschalter-USB-Verl%C3%A4ngerungskabel-Wei%C3%9F/dp/B093HG7LTB/
Funktioniert mit zigbee2mqtt (evtl. vorher updaten); USB schaltbar; leider keine Schalter an der Leiste selbst.
Endlich die ganzen Zwischenstecker weg.
Ich hätte da ein Template für den Aqara Curtain Driver E1
Index: mqtt2.template
===================================================================
--- mqtt2.template (revision 26604)
+++ mqtt2.template (working copy)
@@ -912,6 +912,28 @@
attr DEVICE model zigbee2mqtt_aqara_cube
setreading DEVICE attrTemplateVersion 20210226
+# Aqara Curtain Driver E1
+name:zigbee2mqtt_aqara_curtain_driver
+desc:Aqara curtain driver E1 via zigbee2mqtt.<br>Tested with: <a href="https://www.zigbee2mqtt.io/devices/ZNCLBL01LM.html">ZNCLBL01LM</a>.
+filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
+order:L_18
+par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
+par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
+attr DEVICE devicetopic BASE_TOPIC/DEV_ID
+attr DEVICE readingList $\DEVICETOPIC/availability:.* availability\
+ $\DEVICETOPIC:.* { json2nameValue($EVENT) }
+attr DEVICE event-on-change-reading .*
+attr DEVICE setList open:noArg $\DEVICETOPIC/set {"state": "OPEN"}\
+ close:noArg $\DEVICETOPIC/set {"state": "CLOSE"}\
+ stop:noArg $\DEVICETOPIC/set {"state": "STOP"}\
+ position:slider,0,1,100 $\DEVICETOPIC/set {"position": "$EVTPART1"}
+attr DEVICE stateFormat position
+attr DEVICE devStateIcon 0:fts_shutter_100 (\d|1\d):fts_shutter_90 2\d:fts_shutter_80 3\d:fts_shutter_70 4\d:fts_shutter_60 5\d:fts_shutter_50 6\d:fts_shutter_40 7\d:fts_shutter:30 8\d:fts_shutter_20 9\d:fts_shutter_10 100:fts_window_2w
+attr DEVICE webCmd open:close:stop
+deletereading -q DEVICE (?!associatedWith|IODev).*
+attr DEVICE model zigbee2mqtt_aqara_curtain_driver
+setreading DEVICE attrTemplateVersion 20221028
+
#source post: https://forum.fhem.de/index.php/topic,94494.msg983905.html#msg983905
name:zigbee2mqtt_AlarmSensor
desc: Alarm sensor via zigbee2mqtt <br>Can report actions drop, tilt or vibration as well as x,y,z coordinates of its movement.<br>Sensitivity can be set to low, medium or high.<br>Tested with: Xiaomi DJT11LM Vibration Sensor
THX. Hab's etwas verändert eingecheckt.
Vielleicht sollte man die Namen der beiden "Brüder" überdenken, es gab schon ein "blind"-template, das sehr ähnlich ist, bis auf die Option, die Laufgeschwindigkeit einzustellen.
Klar. Warum nicht. Spart ein paar Zeilen Code.
Zeile 698 hat sich leider ein Fehler eingeschlichen:
$\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP)) }
Das ist eine schließende Klammer zu viel
Ich habe einen Neo AB02B2 "Alarm-Gong" https://www.zigbee2mqtt.io/devices/NAS-AB02B2.html (https://www.zigbee2mqtt.io/devices/NAS-AB02B2.html) angebunden.
Habe dafür folgendes Template genutzt:
# NEO AB02B2 Alarm Sound
name:zigbee2mqtt_alarm_sound
desc: Alarm sound controller via zigbee2mqtt <br>Tested with: Tuya Neo NAS-AB02B2 sound device
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
par:ICON;ICON as set, defaults to it_remote;{ AttrVal("DEVICE","icon","audio_volume_mid") }
attr DEVICE icon ICON
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE stateFormat Alarm: alarm Volume: volume Duration: duration Melody: melody Batterie: battpercentage % Linkquality: linkquality
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT) }
attr DEVICE setList \
alarm:true,false $\DEVICETOPIC/set {"alarm": "$EVTPART1"}\
volume:low,medium,high $\DEVICETOPIC/set {"volume": "$EVTPART1"}\
duration:slider,0,1,1800 $\DEVICETOPIC/set {"duration": "$EVTPART1"}\
melody:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18 $\DEVICETOPIC/set {"melody": "$EVTPART1"}
attr DEVICE model zigbee2mqtt_alarm_sound
deletereading -q DEVICE (?!associatedWith|IODev).*
setreading DEVICE attrTemplateVersion 20200904
Wenigstens noch kurz die Warnung, dass das Gerät wohl nicht immer zuverlässig ist: https://github.com/Koenkk/zigbee2mqtt/issues/12542 (https://github.com/Koenkk/zigbee2mqtt/issues/12542)
THX, hab's eingecheckt.
(Das andere mit der Klammer ist schon länger gefixt)
Hallo,
ich habe für die Hoymiles Wechselrichter analog zu den zwei vorhandenen Templates für AhoyDTU zwei Templates für das Schwesterprojekt OpenDTU ( https://github.com/tbnobody/OpenDTU (https://github.com/tbnobody/OpenDTU) erstellt.
OpenDTU Hub Bridge:
name:hoymiles_opendtu_hub_bridge
filter:TYPE=MQTT2_DEVICE
desc:Early version! Use this with "openDTU" firmware for ESP8266+nRF24L01+. For further details visit https://github.com/tbnobody/OpenDTU and https://www.mikrocontroller.net/topic/525778. Resulting <b>device represents the interfacing ESP-MCU</b>, all inverters will be forwarded into own MQTT2_DEVICE instances.
order:W_06
farewell:template has been applied successfully. <br>Note: In case you use an external MQTT server or not exclusively use FHEM to send MQTT commands to your devices, it's highly recommended to extend the ignoreRegexp of your IO device! Could be something like <i>|devcontrol/[0-8]+/[0-8]+</i>. For the single microinverters, please be patient, until the Readings concerning the AC will have been sent in.
par:BASE_ID;Base topic as set in OpenDTU MQTT settings;{ AttrVal('DEVICE','readingList','') =~ m,([^:]+)/([^:]+)/name:, ? $1 : undef }
par:ICON;ICON as set, defaults to solar;{ AttrVal('DEVICE','icon','solar') }
par:BR_REG_NAME;Bridge RegEx Name for target inverter device;{ my $r1 = AttrVal('DEVICE','readingList','') =~ m,([^:]+)/([^:]+)/name:, ? $1 : "xxx";; my $r2 = AttrVal('DEVICE','readingList','') =~ m,([^:]+)/([^:]+)/name:, ? $2 : "yyy";; my $rn = $r1 . "_" . $r2 ."_name";; return ReadingsVal('DEVICE',"$rn",undef) }
attr DEVICE icon ICON
#attr DEVICE bridgeRegexp BASE_ID/[0-9]+/.*/.*:.* "BASE_ID_$1"
attr DEVICE bridgeRegexp BASE_ID/[0-9]+/.*/.*:.* "BR_REG_NAME"
attr DEVICE autocreate 1
attr DEVICE readingList BASE_ID/dtu/uptime:.* uptime\
BASE_ID/dtu/status:.* status\
BASE_ID/dtu/ip:.* ip\
BASE_ID/dtu/rssi:.' rssi\
BASE_ID/dtu/hostname:.* hostname
attr DEVICE setStateList on off
attr DEVICE model hoymiles_opendtu_hub_bridge
setreading DEVICE attrTemplateVersion 20221203
{ AttrTemplate_Initialize() }
Beim bridgeRegexp Attribut verstehe ich in der AhoyDTU Vorlage nicht vollständig, was $1 referenziert. Mag sein, daß die Ermittlung des Target Device Namens für die Inverter MQTT Devices bei meiner Fassung etwas umständlich ist...
OpenDTU microinverter device template:
name:hoymiles_opendtu_microinverter
prereq:{my @devices=devspec2array('model=hoymiles_opendtu_hub_bridge');return 1 if $devices[0];return 0}
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*/0/voltage:.*
desc:Early version, device represents a single microinverter. Use this with "opendtu" firmware for ESP8266+nRF24L01+. Wait some time until the target device got <b>readings for channel 0</b> (AC part, refreshing your browser window may help to get them visible)!
order:W_061
par:INVERTERLONG_ID;INVERTERLONG_ID Serieal Id of inverter as set in webinterface;{ AttrVal('DEVICE','readingList','') =~ m,^\s*([^:]+/[^/]+)/0/voltage:,m ? $1 : undef }
par:RADIO_SINGLE;inverter has just one channel;{ undef }
par:RADIO_DOUBLE;inverter has two channels;{ undef }
par:RADIO_QUATTRO;inverter has four channels;{ undef }
par:ICON;ICON as set, defaults to solar;{ AttrVal('DEVICE','icon','solar') }
attr DEVICE icon ICON
deletereading -q DEVICE .*_.*
option:{ RADIO_SINGLE }
attr DEVICE readingList \
INVERTERLONG_ID/0/powerdc:.* powerdc\
INVERTERLONG_ID/0/yieldday:.* {}\
INVERTERLONG_ID/0/yieldtotal:.* {}\
INVERTERLONG_ID/0/voltage:.* voltage\
INVERTERLONG_ID/0/current:.* current\
INVERTERLONG_ID/0/power:.* power\
INVERTERLONG_ID/0/frequency:.* frequency\
INVERTERLONG_ID/0/temperature:.* temperature\
INVERTERLONG_ID/0/powerfactor:.* powerfactor\
INVERTERLONG_ID/0/efficiency:.* efficiency\
INVERTERLONG_ID/0/reactivepower:.* reactivepower\
INVERTERLONG_ID/1/voltage:.* voltage1\
INVERTERLONG_ID/1/current:.* current1\
INVERTERLONG_ID/1/power:.* power1\
INVERTERLONG_ID/1/irradiation:.* irradiation1\
INVERTERLONG_ID/1/yieldday:.* yieldday\
INVERTERLONG_ID/1/yieldtotal:.* yieldtotal
option:{ RADIO_DOUBLE }
attr DEVICE readingList \
INVERTERLONG_ID/0/powerdc:.* powerdc\
INVERTERLONG_ID/0/yieldday:.* yieldday\
INVERTERLONG_ID/0/yieldtotal:.* yieldtotal\
INVERTERLONG_ID/0/voltage:.* voltage\
INVERTERLONG_ID/0/current:.* current\
INVERTERLONG_ID/0/power:.* power\
INVERTERLONG_ID/0/frequency:.* frequency\
INVERTERLONG_ID/0/temperature:.* temperature\
INVERTERLONG_ID/0/powerfactor:.* powerfactor\
INVERTERLONG_ID/0/efficiency:.* efficiency\
INVERTERLONG_ID/0/reactivepower:.* reactivepower\
INVERTERLONG_ID/1/voltage:.* voltage1\
INVERTERLONG_ID/1/current:.* current1\
INVERTERLONG_ID/1/power:.* power1\
INVERTERLONG_ID/1/irradiation:.* irradiation1\
INVERTERLONG_ID/1/yieldday:.* yieldday1\
INVERTERLONG_ID/1/yieldtotal:.* yieldtotal1\
INVERTERLONG_ID/2/voltage:.* voltage2\
INVERTERLONG_ID/2/current:.* current2\
INVERTERLONG_ID/2/power:.* power2\
INVERTERLONG_ID/2/irradiation:.* irradiation2\
INVERTERLONG_ID/2/yieldday:.* yieldday2\
INVERTERLONG_ID/2/yieldtotal:.* yieldtotal2
option:{ RADIO_QUATTRO }
attr DEVICE readingList \
INVERTERLONG_ID/0/powerdc:.* powerdc\
INVERTERLONG_ID/0/yieldday:.* yieldday\
INVERTERLONG_ID/0/yieldtotal:.* yieldtotal\
INVERTERLONG_ID/0/voltage:.* voltage\
INVERTERLONG_ID/0/current:.* current\
INVERTERLONG_ID/0/power:.* power\
INVERTERLONG_ID/0/frequency:.* frequency\
INVERTERLONG_ID/0/temperature:.* temperature\
INVERTERLONG_ID/0/powerfactor:.* powerfactor\
INVERTERLONG_ID/0/efficiency:.* efficiency\
INVERTERLONG_ID/0/reactivepower:.* reactivepower\
INVERTERLONG_ID/1/voltage:.* voltage1\
INVERTERLONG_ID/1/current:.* current1\
INVERTERLONG_ID/1/power:.* power1\
INVERTERLONG_ID/1/irradiation:.* irradiation1\
INVERTERLONG_ID/1/yieldday:.* yieldday1\
INVERTERLONG_ID/2/yieldtotal:.* yieldtotal2\
INVERTERLONG_ID/3/voltage:.* voltage3\
INVERTERLONG_ID/3/current:.* current3\
INVERTERLONG_ID/3/power:.* power3\
INVERTERLONG_ID/3/irradiation:.* irradiation3\
INVERTERLONG_ID/3/yieldday:.* yieldday3\
INVERTERLONG_ID/3/yieldtotal:.* yieldtotal3\
INVERTERLONG_ID/4/voltage:.* voltage4\
INVERTERLONG_ID/4/current:.* current4\
INVERTERLONG_ID/4/power:.* power4\
INVERTERLONG_ID/4/irradiation:.* irradiation4\
INVERTERLONG_ID/4/yieldday:.* yieldday4\
INVERTERLONG_ID/4/yieldtotal:.* yieldtotal4
option:global
attr DEVICE setList \
on:noArg INVERTERLONG_ID/cmd/power 1\
off:noArg INVERTERLONG_ID/cmd/power 0\
reboot:noArg INVERTERLONG_ID/cmd/restart 1\
limit_non_persistent_abs INVERTERLONG_ID/cmd/limit_persistent_absolute $EVTPART1\
limit_non_persistent_pct:slider,2,1,100 INVERTERLONG_ID/cmd/limit_persistent_relative $EVTPART1\
limit_persistent_abs INVERTERLONG_ID/cmd/limit_nonpersistent_absolute $EVTPART1\
limit_persistent_pct:slider,2,1,100 INVERTERLONG_ID/cmd/limit_nonpersistent_relative $EVTPART1
attr DEVICE setStateList on off
attr DEVICE model hoymiles_opendtu_microinverter
setreading DEVICE attrTemplateVersion 20221204
Getestet habe ich nur die Version für den Hoymiles 600 mit zwei Eingängen.
Ich bitte um ein Review, bei Bedarf kann ich auch ein passendes Log vor Anwendung der Templates liefern.
Gruß, Tobias
Moin,
da ich zwischenzeitlich auch mit openDTU rumteste (hoffentlich ab Jan. dann 6xMI-1500 3.Gen) habe ich deinen Vorschlag noch etwas modifiziert und eingecheckt (kommt mit dem morgigen update).
Allerdings kommt mir die Art und Weise noch etwas verbesserungsfähig vor, was da wann wie gesendet wird (Name alle 5 Sekunden? Kein JSON?). Werde das mal bei Gelegenheit addressieren...
Hallöchen,
ich habe mir mal über Aliexpress den Xiaomi Aqara presence detector FP1 bestellt, da ich einige meiner Bewegungsmelder ablösen wollte. Leider benötigt das Gerät auch Sichtkontakt, was in Räumen mit einigen Ecken z.B. Schornsteinen etwas schlecht ist. Jedoch muss man sich, wenn das Gerät in der richtigen Position ist, nicht mehr bewegen und nen Hampelmann machen. Er erkennt einen auch liegend in der Badewanne.
Dazu hier mal mein Patch.
--- mqtt2.template 2023-01-11 16:38:23.000000000 +0100
+++ mqtt2.template_neu 2023-01-11 16:28:54.000000000 +0100
@@ -787,6 +787,25 @@
attr DEVICE model zigbee2mqtt_human_body_movement_illuminance
setreading DEVICE attrTemplateVersion 20201208
+name:zigbee2mqtt_human_body_presence_detector
+desc: Human body presence detector via zigbee2mqtt <br>Tested with: Xiaomi Aqara RTCZCGQ11LM Presence Detector FP1
+filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
+order:L_08b
+par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
+par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
+par:ICON;ICON as set, defaults to people_sensor;{ AttrVal("DEVICE","icon","people_sensor") }
+attr DEVICE icon ICON
+attr DEVICE devStateIcon Motion..true:people_sensor Motion..false:motion_detector
+attr DEVICE devicetopic BASE_TOPIC/DEV_ID
+attr DEVICE stateFormat Motion: presence
+attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
+attr DEVICE setList \
+ mode:undirected,left_right $\DEVICETOPIC/set {"monitoring_mode":"$EVTPART1"}\
+ distance:far,medium,near $\DEVICETOPIC/set {"approach_distance":"$EVTPART1"}\
+ sensitivity:low,medium,high $\DEVICETOPIC/set {"motion_sensitivity":"$EVTPART1"}
+attr DEVICE model zigbee2mqtt_human_body_presence_detector
+setreading DEVICE attrTemplateVersion 20230111
+
name:zigbee2mqtt_Light_Intensity_Sensor
desc: Light Intensity Sensor via zigbee2mqtt <br>Tested with: Xiaomi MiJia light intensity sensor GZCGQ01LM
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
List:
READINGS:
2023-01-11 16:30:24 IODev MQTT2_FHEM_Server
2023-01-11 19:35:13 approach_distance far
2023-01-10 10:31:00 associatedWith MQTT2_zigbee_bridge
2023-01-11 16:30:34 attrTemplateVersion 20230111
2023-01-11 19:35:13 device_temperature 23
2023-01-11 19:35:13 last_seen 2023-01-11T19:35:13+01:00
2023-01-11 19:35:13 linkquality 255
2023-01-11 19:35:13 monitoring_mode left_right
2023-01-11 19:35:13 motion_sensitivity high
2023-01-11 19:35:13 power_outage_count 3
2023-01-11 19:35:13 presence true
2023-01-11 19:35:13 presence_event approach
2023-01-11 16:31:25 state sensitivity
2023-01-11 19:35:13 update_available false
2023-01-11 19:35:13 update_installed_version 54
2023-01-11 19:35:13 update_latest_version 54
2023-01-11 19:35:13 update_state idle
Danke, hab's eingecheckt.
Bin irgendwie am Rätseln, ob es nicht an der Zeit wäre, diese "true/false"-Readinginhalte in present/absent oä. umzuwandeln (das gilt ähnlich auch für die motion-Sensoren), aber wenn sich sonst niemand an sowas "stört", sehe ich da wenig Handlungsdruck ::) .
Zitat... sehe ich da wenig Handlungsdruck ::)
jetzt schon ::), nach dem Hieb, du verteilst doch die Templates, Handlungsdruck hast du dir doch jetzt mit der Aussage selbst aufgebürdet, wenn du die Templates so wie sie jetzt sind nicht selbst nutzt.
OT
ZitatLeider benötigt das Gerät auch Sichtkontakt, was in Räumen mit einigen Ecken z.B. Schornsteinen etwas schlecht ist.
In dem Teil ist doch ein LD2410 verbaut oder lieg ich falsch ?
Auch wenn das die Firmware eines
Xiaomi Aqara presence detector FP1 vermutlich nicht hergibt, ich sag man kann grundsätzlich die Sensivität des Sensors so einstellen/programmieren das er auch in den Ecken/an den Schornsteinen in 6-7 Meter Entfernung auf nur die Atmung (ohne Bewegung) reagiert.
Zitat von: TomLee am 11 Januar 2023, 22:14:51
jetzt schon ::) , nach dem Hieb, du verteilst doch die Templates, Handlungsdruck hast du dir doch jetzt mit der Aussage selbst aufgebürdet, wenn du die Templates so wie sie jetzt sind nicht selbst nutzt.
Sehe ich anders. Ich "kuratiere" die Dinger und bin gerne bereit, Anregungen zur Verbesserung zu geben und das dann wieder zu "verwursten" etc.. Aber wenn alle User mit dem "glücklich und zufrieden" sind, wie es ist, soll mir das recht sein.
Den Job, ggf. mal zu schauen, ob es nicht im Interesse von vielen Usern wäre, die zigbee2mqtt-Templates zu überarbeiten (im Hinblick auf das, was wir seit dieser "ersten Generation" so alles an Neuerungen und Lösungsansätzen gesammelt haben), den ziehe ich mir nicht rein...
Bitte dann aber wieder beim Prinzip bleiben, dass das hier einfach der "fertige Templates"-Thread ist! Anmerkungen zu meiner Meinung wären bitte im zigbee2mqtt-attrTemplate-Thread ("läuft") zu machen.
Hallo,
ich habe mir einen Temperatursensor mit Messsonde zugelegt: https://www.domadoo.fr/fr/peripheriques/5998-owon-sonde-de-temperature-deportee-sur-cable-zigbee.html (https://www.domadoo.fr/fr/peripheriques/5998-owon-sonde-de-temperature-deportee-sur-cable-zigbee.html)
Hier das passende Template (ist mit geringen Änderungen aus zigbee2mqtt_TempHumSensor entstanden)
Vielleicht hilfreich für den einen oder anderen.
--- mqtt2.template_alt 2023-01-26 15:09:44.839717956 +0100
+++ mqtt2.template 2023-01-26 15:12:15.394743350 +0100
@@ -755,6 +755,21 @@
attr DEVICE model zigbee2mqtt_TempHumSensor
setreading DEVICE attrTemplateVersion 20200904
+name:zigbee2mqtt_TempSensor
+desc: Temp sensor via zigbee2mqtt <br>Tested with: OWON THS317-ET Temperature Sensor
+filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
+order:L_07b
+par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
+par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
+par:ICON;ICON as set, defaults to temp_temperature;{ AttrVal("DEVICE","icon","temp_temperature") }
+attr DEVICE icon ICON
+attr DEVICE stateFormat {sprintf ("Temperature: %.1f°C", ReadingsVal($name,"temperature",0)) }
+attr DEVICE devicetopic BASE_TOPIC/DEV_ID
+attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
+deletereading -q DEVICE (?!associatedWith|IODev).*
+attr DEVICE model zigbee2mqtt_TempSensor
+setreading DEVICE attrTemplateVersion 20220126
+
#by TomLee, https://forum.fhem.de/index.php/topic,116310.msg1105927.html#msg1105927
name:zigbee2mqtt_human_body_movement
desc: Human motion sensor via zigbee2mqtt <br>Tested with: Xiaomi MiJia human RTCGQ01LM body movement sensor (occupancy)
Thx, ist seit eben eingecheckt.
Hallo und erstmal danke für die Templates für MQTT.
Zur meiner HW: Habe eine openDTU(DX-DTU), ein Hoymiles HM-300 und 48V Batterie um 24/7 eine Nulleinspeisung für den Grundbedarf (wenn genug Sonne vorhanden ist) zu ermöglichen.
Der HM-300 ist über die DX-DTU angebunden und im device hm300 "abgebildet":
Internals:
CID 192.168.178.105
DEF 192.168.178.105
FUUID 649c6c9d-f33f-39c2-cb5a-ce7d555d4c3658ee
IODev mqtt_client
LASTInputDev mqtt_client
MSGCNT 11121
NAME hm300
NR 316
STATE 133.1
TYPE MQTT2_DEVICE
eventCount 12560
mqtt_client_MSGCNT 11121
mqtt_client_TIME 2023-07-03 19:54:38
READINGS:
2023-07-03 17:03:02 IODev mqtt_client
2023-07-03 19:54:38 battery_current 2.57
2023-07-03 19:54:38 battery_voltage 54.3
2023-07-03 19:54:34 change_limit 44
2023-07-03 19:49:36 increment 1
2023-07-03 19:54:38 limit_absolute 132.00
2023-07-03 19:54:38 limit_relative 44.00
2023-06-30 15:43:43 nominal_power 300
2023-07-03 19:54:38 state 133.1
2023-07-03 19:54:38 version 02.00
Attributes:
autocreate 1
bridgeRegexp solar/hm300/([^/]+)/ch[0-9]+/.*:.* "solar/hm300_$1"
icon inverter
model hoymiles_microinverter_hub_bridge
mqttName hm300
mqttRoom solar
readingList solar/hm300/112183835921/device/hwversion:.* version
solar/hm300/hm-id/status/limit_relative:.* limit_relative
solar/hm300/hm-id/status/limit_absolute:.* limit_absolute
solar/hm300/hm-id/1/voltage:.* battery_voltage
solar/hm300/hm-id/1/current:.* battery_current
solar/hm300/ac/power:.* state
room 1_Überwachung
Dank des DTU Templates konnte ich die Readings ermitteln und einbringen. Ich habe allerdings nur die eingebracht, die mir informativ sind.
Das Auslesen funktioniert soweit, top!
Um die Grundlast auf Nulleinspeisung zu bringen, ist es notwendig den HM-300 anzusteuern. Dazu setze ich das Reading change_limit auf den gewünschten Wert. Irgendwo fand ich, dass die Leistung des WR mit folgendem MQTT Befehl funktioniert:
setList change_limit solar/hm300/hm-id/ctrl/limit_nonpersistent_relative/0:Das hat auch dann tatsächlich geklappt, allerdings nur eine Nacht lang. Am nächsten Tag war es vorbei. Auch der MQTT-Explorer bewirkte hier nichts.
Weitere Recherche ergab dass dieser Befehl funktioniert:
change_limit solar/hm300/hm-id/cmd/limit_nonpersistent_relative/0:allerdings nur im MQTT-Explorer.
Bisher habe ich allerdings die Funktion nicht im hm300 device hinbekommen:
setList change_limit solar/hm300/hm-id/cmd/limit_nonpersistent_relative/0:
Was mache ich hier falsch?
Falscher Thread, du stellst eine Frage....
Bitte den "hoymiles"-Thread nutzen, da lesen ggf. die wenigen openDTU-user mit (ich bin auf ahoy). Generell: die mcu auf dem Inverter startet neu, wenn DC weg war, daher auch " non persistent ". Ggf. müßtest du die Logik dahinter anpassen, damit das Limit mit einer gewissen Regelmäßigkeit neu gesetzt wird.
Hallo Zusammen,
für den Shelly Plus i4 mit Tasmota Firmware habe ich ein neues MQTT Template. Als Grundlage hab ich mein Template zum Shelly i3 mit Tasmota genommen, und es um den 4. Kanal erweitert.
Getestet mit Tasmota 13.0.0 und Device Config von https://templates.blakadder.com/shelly_plus_i4.html
# shelly plus i4 4 channel input switches with device configuration
name:tasmota_4channel_input_shelly_i4
filter:TYPE=MQTT2_DEVICE
desc:Shelly i4 device flashed with Tasmota, provides four input only channels. <p>Device will be configured with selectable SwitchMode and optional GPIO Template. <br>Recommended SwitchModes 1=FollowMode (normally open switches> or 2=InvertedFollowMode (normally closed switches) </p><p>Tasmota 9.1+ is required for <a href=https://tasmota.github.io/docs/Buttons-and-Switches/#setoption114>SetOption114</a> to detach switches from relays.<p>NOTE: <br>A second, third and fourth device will be created for the second, third and fourth input with suffixes *_CH2, *_CH3 and *_CH4</p>
order:A_04
par:RADIO_TEMPLATE;Configure device and GPIO;{ undef }
par:RADIO_NO_TEMPLATE;Configure device without GPIO template;{ undef }
par:SWITCHMODE1;SwitchMode for Input 1;{ undef }
par:SWITCHMODE2;SwitchMode for Input 2;{ undef }
par:SWITCHMODE3;SwitchMode for Input 3;{ undef }
par:SWITCHMODE3;SwitchMode for Input 4;{ undef }
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
par:SETCHANNELINFO;Set this to 0 to not set channelinfo;{ 1 }
par:ICON;ICON as set, defaults to taster;{ AttrVal("DEVICE","icon","taster") }
par:IO_DEV;Currently used IO;{ AttrVal('DEVICE','IODev',InternalVal('DEVICE','IODev',undef)->{NAME}) }
# autoconfigure device
option:{RADIO_NO_TEMPLATE}
set IO_DEV publish CMNDTOPIC/Backlog StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SwitchMode1 SWITCHMODE1; SwitchMode2 SWITCHMODE2; SwitchMode3 SWITCHMODE3; SwitchMode4 SWITCHMODE4; SetOption26 1; SetOption114 1; SaveData 1
option:{RADIO_TEMPLATE}
set IO_DEV publish CMNDTOPIC/Backlog StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SwitchMode1 SWITCHMODE1; SwitchMode2 SWITCHMODE2; SwitchMode3 SWITCHMODE3; SwitchMode4 SWITCHMODE4; SetOption26 1; SetOption114 1; SaveData 1; template {"NAME":"Shelly Plus i4","GPIO":[0,0,0,0,0,0,0,0,192,0,193,0,0,0,0,0,0,0,0,0,0,0,195,194,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":1,"CMND":"SwitchMode1 1 | SwitchMode2 1 | SwitchMode3 1 | SwitchMode4 1 | SwitchTopic 0 | SetOption114 1"}; module 0
option:global
# setup main device channel 1
attr DEVICE icon ICON
attr DEVICE jsonMap Switch1_Action:state
attr DEVICE setList \
off:noArg STATTOPIC/Switch1 0\
on:noArg STATTOPIC/Switch1 1\
toggle:noArg STATTOPIC/Switch1 2
attr DEVICE readingList \
TELETOPIC/LWT:.* LWT\
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
deletereading -q DEVICE (?!associatedWith|IODev).*
attr DEVICE setStateList on off toggle
attr DEVICE autocreate 0
# channel 2
copy DEVICE DEVICE_CH2
deleteattr DEVICE_CH2 alias
attr DEVICE_CH2 readingList \
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE_CH2 jsonMap Switch2_Action:state
attr DEVICE_CH2 setList \
off:noArg STATTOPIC/Switch2 0\
on:noArg STATTOPIC/Switch2 1\
toggle:noArg STATTOPIC/Switch2 2
# channel 3
copy DEVICE_CH2 DEVICE_CH3
deleteattr DEVICE_CH3 alias
attr DEVICE_CH3 jsonMap Switch3_Action:state
attr DEVICE_CH3 setList \
off:noArg STATTOPIC/Switch3 0\
on:noArg STATTOPIC/Switch3 1\
toggle:noArg STATTOPIC/Switch3 2
# channel 4
copy DEVICE_CH3 DEVICE_CH4
deleteattr DEVICE_CH4 alias
attr DEVICE_CH4 jsonMap Switch4_Action:state
attr DEVICE_CH4 setList \
off:noArg STATTOPIC/Switch4 0\
on:noArg STATTOPIC/Switch4 1\
toggle:noArg STATTOPIC/Switch4 2
# associations
option:{SETCHANNELINFO}
set DEVICE attrTemplate set_associatedWith \CHANNELS=4
attr DEVICE,DEVICE_CH2,DEVICE_CH3,DEVICE_CH4 model tasmota_shelly_i4
setreading DEVICE,DEVICE_CH2,DEVICE_CH3,DEVICE_CH4 attrTemplateVersion 20210729
Viele Grüße
Oliver
Zitat von: twdotnet am 30 Juli 2023, 00:39:51Hallo Zusammen,
für den Shelly Plus i4 mit Tasmota Firmware habe ich ein neues MQTT Template. Als Grundlage hab ich mein Template zum Shelly i3 mit Tasmota genommen, und es um den 4. Kanal erweitert.
Moin, habe eben eine etwas modifizierte Fassung eingecheckt.
Dabei ist mir aufgefallen, dass da (wie im i3) die setList auf STATTOPIC publisht. Kommt mir komisch (im Sinne von unüblich für Tasmota) vor, mag das jemand bitte bestätigen, dass das so korrekt ist?
Moin Leute,
ich habe mich mal mit dem Eqiva eq-3 Heizkörperthermostat und Tasmota beschäftigt. Ein ESP32 dient dabei als eine Art Gateway (Dokumentation (https://tasmota.github.io/docs/EQ3-TRV/)). Ich habe dazu mal ein Template gebastelt:
name:tasmota_tasmota32bt_EQ3BT
filter:TYPE=MQTT2_DEVICE
desc:Applies to Eqiva Bluetooth® Smart Radiator thermostat with tasmota32 bluetooth
order:A_06t02
par:TOPIC;tasmota device topic (..../tasmota_123456/....)
par:MAC;MAC-address of the thermostat (aabbccddeeff)
par:ICON;ICON as set, defaults to hm-cc-rt-dn;{ AttrVal('DEVICE','icon','hm-cc-rt-dn') }
attr DEVICE devStateIcon 1.Online:WLAN_Status.1 1.Offline:WLAN_Status.0\
2.ok:bluetooth@lightgreen 2.fail:bluetooth@red\
3.GOOD:batterie@lightgreen 3.LOW:batterie@red
attr DEVICE getList Status:noArg result cmnd/TOPIC/EQ3/MAC/state\
Tagesprofil0_Samstag:noArg result cmnd/TOPIC/EQ3/MAC/reqprofile 0\
Tagesprofil1_Sonntag:noArg result cmnd/TOPIC/EQ3/MAC/reqprofile 1\
Tagesprofil2_Montag:noArg result cmnd/TOPIC/EQ3/MAC/reqprofile 2\
Tagesprofil3_Dienstag:noArg result cmnd/TOPIC/EQ3/MAC/reqprofile 3\
Tagesprofil4_Mittwoch:noArg result cmnd/TOPIC/EQ3/MAC/reqprofile 4\
Tagesprofil5_Donnerstag:noArg result cmnd/TOPIC/EQ3/MAC/reqprofile 5\
Tagesprofil6_Freitag:noArg result cmnd/TOPIC/EQ3/MAC/reqprofile 6
attr DEVICE icon ICON
attr DEVICE jsonMap profileday0:profile0_Samstag\
profileday1:profile1_Sonntag\
profileday2:profile2_Montag\
profileday3:profile3_Dienstag\
profileday4:profile4_Mittwoch\
profileday5:profile5_Donnerstag\
profileday6:profile6_Freitag\
posn:valve
attr DEVICE readingList \
tele/TOPIC/LWT:.* LWT\
stat/EQ3/MAC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE setList temp cmnd/TOPIC/EQ3/MAC/settemp\
mode cmnd/TOPIC/EQ3/MAC/mode\
holiday:textField cmnd/TOPIC/EQ3/MAC/setholiday\
setvalvetime:noArg cmnd/TOPIC/EQ3/MAC/settime\
profile0_Samstag cmnd/TOPIC/EQ3/MAC/setprofile 0\
profile1_Sonntag cmnd/TOPIC/EQ3/MAC/setprofile 1\
profile2_Montag cmnd/TOPIC/EQ3/MAC/setprofile 2\
profile3_Dienstag cmnd/TOPIC/EQ3/MAC/setprofile 3\
profile4_Mittwoch cmnd/TOPIC/EQ3/MAC/setprofile 4\
profile5_Donnerstag cmnd/TOPIC/EQ3/MAC/setprofile 5\
profile6_Freitag cmnd/TOPIC/EQ3/MAC/setprofile 6
attr DEVICE periodicCmd setvalvetime:1440
attr DEVICE stateFormat 1:LWT\
2:result\
3:battery
attr DEVICE userReadings valveTime {FmtDateTime(ReadingsNum($name,"stattime",0))}
attr DEVICE webCmd mode:temp
attr DEVICE widgetOverride mode:select,auto,manual,on,off temp:slider,4.5,0.5,30.0,1
attr DEVICE autocreate 0
Es ist mein erstes Template und sicher verbesserungswürdig.
Eine Sache gefällt mir noch nicht, allerdings habe ich noch nicht geschafft, es zu ändern. Wenn man ein neues Tagesprofil an das Thermostat schickt, bekommt man nur eine Erfolgsmeldung aber nicht das geänderte Profil zurück. Man müsste nach dem Senden noch einen zweiten Befehl zum Lesen des geänderten Profils schicken. Für einen Experten sicher kein Problem, das noch zu ergänzen. Danke!
Moin,
ich hätte da mal eine Ergänzung anzumerken für das Shelly_TRV Template.
Die SetList habe ich noch erweitert um:
window:open,close {my $val=$EVTPART1 eq 'open'?1:0; qq($DEVICETOPIC/thermostat/0/command/window_open $val)}
Hintergrund: Ich habe einen Raum mit einem Heizkörper, aber mehreren Fenstern. Somit wollte ich mittels DOIF den Status im TRV setzen lassen; aber die Methode mit GetHttpFile habe ich nicht zum Laufen bekommen ("unauthorized", da passwortgeschützt). Habe dann mal ganz frech obiges Command ausprobiert, das in der Shelly-API-Doku nicht steht, und siehe da, das geht. 8)
Hallo, hab grad ein Shelly PM MINI eingebunden als Template hab ich tasmota POW genommen und es dementsprechend angepasst
name:tasmota_PM_MINI
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd).*
desc:Applies to Shelly PM MINI devices with power measuring abilities.<br>NOTE:; the format the device is sending data will also be changed to lowercase!
order:A_ ????
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:CALLSPEECHRECOGN;Set this to 0 to not set any speech recogn. related attributes;{ 1 }
set DEVICE attrTemplate tasmota_PM_MINI \CALLSPEECHRECOGN=CALLSPEECHRECOG
attr DEVICE devStateIcon {my $text = ' uptime: '.ReadingsVal($name,"Uptime","unknown").sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"));; my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";;}
attr DEVICE stateFormat {sprintf("aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power","-1"), ReadingsVal($name,"ENERGY_Today","-1"), ReadingsVal($name,"ENERGY_Yesterday","-1"), ReadingsVal($name,"ENERGY_Total","-1"))}
deletereading -q DEVICE (?!associatedWith|IODev).*
attr DEVICE model tasmota_PM-MINI
setreading DEVICE attrTemplateVersion 20231202
ich bin nicht so bewandert und würde mich freuen wenn da noch mal wer drüber schaut und wenn es ok ist kann es ja eingefügt werden.
Habe es selber in meine Template kopiert und einen zweiten PM_MINI integriert, Ergebnis FHEM ist eingefroren.
hier mein RAW Device für eine Aubess Steckdose 20A (LSPA9 clone).
Das Teil habe ich vorher mit tuya-cloudcutter mit openbeken geflashed und dann fuktioniert das Teil mit mqtt.
defmod MQTT2_obkFFC5CF49 MQTT2_DEVICE obkFFC5CF49
attr MQTT2_obkFFC5CF49 alias SchreibtischlampeJannik
attr MQTT2_obkFFC5CF49 icon hue_filled_outlet
attr MQTT2_obkFFC5CF49 readingList obkFFC5CF49:obkFFC5CF49/connected:.* connected\
obkFFC5CF49:obkFFC5CF49/host:.* host\
obkFFC5CF49:obkFFC5CF49/build:.* build\
obkFFC5CF49:obkFFC5CF49/mac:.* mac\
obkFFC5CF49:obkFFC5CF49/ssid:.* ssid\
obkFFC5CF49:obkFFC5CF49/sockets:.* sockets\
obkFFC5CF49:obkFFC5CF49/rssi:.* rssi\
obkFFC5CF49:obkFFC5CF49/uptime:.* uptime\
obkFFC5CF49:obkFFC5CF49/freeheap:.* freeheap\
obkFFC5CF49:obkFFC5CF49/ip:.* ip\
obkFFC5CF49:obkFFC5CF49/1/get:.* obkFFC5CF49_1_get\
obkFFC5CF49:stat/obkFFC5CF49/RESULT:.* { json2nameValue($EVENT) }\
obkFFC5CF49:obkFFC5CF49/voltage/get:.* ENERGY_Voltage\
obkFFC5CF49:obkFFC5CF49/current/get:.* ENERGY_Current\
obkFFC5CF49:obkFFC5CF49/power/get:.* ENERGY_Power\
obkFFC5CF49:obkFFC5CF49/energycounter/get:.* ENERGY_Total\
obkFFC5CF49:obkFFC5CF49/energycounter_last_hour/get:.* ENERGY_LastHour\
obkFFC5CF49:tele/obkFFC5CF49/STATE:.* { json2nameValue($EVENT) }\
obkFFC5CF49:tele/obkFFC5CF49/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_obkFFC5CF49 room MQTT2_DEVICE
attr MQTT2_obkFFC5CF49 setList off:noArg cmnd/obkFFC5CF49/POWER1 0\
on:noArg cmnd/obkFFC5CF49/POWER1 1\
Ich habe ein Tuya IR-Gateway mit Hilfe des tuya-cloudcutter mit openbeken versehen.
IR-Gateway (https://www.elektroda.com/rtvforum/topic3940178.html)
Senden und Empfangen funktionieren. Das Senden funktioniert mit der setList.
defmod MQTT2_obk1F39E4A3 MQTT2_DEVICE obk1F39E4A3
attr MQTT2_obk1F39E4A3 autocreate 1
attr MQTT2_obk1F39E4A3 readingList obk1F39E4A3:obk1F39E4A3/connected:.* connected\
obk1F39E4A3:obk1F39E4A3/sockets:.* sockets\
obk1F39E4A3:obk1F39E4A3/rssi:.* rssi\
obk1F39E4A3:obk1F39E4A3/uptime:.* uptime\
obk1F39E4A3:obk1F39E4A3/freeheap:.* freeheap\
obk1F39E4A3:obk1F39E4A3/ip:.* ip\
obk1F39E4A3:obk1F39E4A3/ir/get:.* get\
obk1F39E4A3:obk1F39E4A3/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_obk1F39E4A3 room MQTT2_DEVICE
attr MQTT2_obk1F39E4A3 setList jedi_on:noArg cmnd/obk1F39E4A3/IRSend NEC 0xFE02 0x1 1\
jedi_off:noArg cmnd/obk1F39E4A3/IRSend NEC 0xFE02 0x2 0 1\
jedi_fackel:noArg cmnd/obk1F39E4A3/IRSend NEC 0xFE02 0xD 1
setstate MQTT2_obk1F39E4A3 jedi_on
setstate MQTT2_obk1F39E4A3 2023-12-03 09:13:07 IODev myBroker
setstate MQTT2_obk1F39E4A3 2023-12-03 19:05:04 IrReceived_Bits 32
setstate MQTT2_obk1F39E4A3 2023-12-03 19:05:04 IrReceived_Data 0xFD02FE02
setstate MQTT2_obk1F39E4A3 2023-12-03 19:05:04 IrReceived_Protocol NEC
setstate MQTT2_obk1F39E4A3 2023-12-03 09:13:07 connected online
setstate MQTT2_obk1F39E4A3 2023-12-03 09:13:10 freeheap 88432
setstate MQTT2_obk1F39E4A3 2023-12-03 19:05:04 get IR_NEC 0xFE02 0x2 0
setstate MQTT2_obk1F39E4A3 2023-12-03 09:13:11 ip 192.168.179.246
setstate MQTT2_obk1F39E4A3 2023-12-03 09:13:09 rssi -55
setstate MQTT2_obk1F39E4A3 2023-12-03 09:13:08 sockets 2
setstate MQTT2_obk1F39E4A3 2023-12-03 19:05:54 state jedi_on
setstate MQTT2_obk1F39E4A3 2023-12-03 09:13:54 subscriptions cmnd/obk1F39E4A3/+ obk1F39E4A3/+/set
setstate MQTT2_obk1F39E4A3 2023-12-03 09:13:09 uptime 35087
Zitat von: Beta-User am 17 August 2023, 07:21:54Zitat von: twdotnet am 30 Juli 2023, 00:39:51Hallo Zusammen,
für den Shelly Plus i4 mit Tasmota Firmware habe ich ein neues MQTT Template. Als Grundlage hab ich mein Template zum Shelly i3 mit Tasmota genommen, und es um den 4. Kanal erweitert.
Moin, habe eben eine etwas modifizierte Fassung eingecheckt.
Dabei ist mir aufgefallen, dass da (wie im i3) die setList auf STATTOPIC publisht. Kommt mir komisch (im Sinne von unüblich für Tasmota) vor, mag das jemand bitte bestätigen, dass das so korrekt ist?
Hallo, wenn ich versuche das Template anzuwenden erhalte ich folgende Fehlermeldung:
ERROR executing perl-code { AttrVal('MQTT2_Shellyi4_Garage','icon",'taster') } for param ICON: Bad name after taster' at (eval 131) line 1.
Ich habe mir das in der mqtt2.template Datei angeschaut und da ist in folgender Zeile ein Fehler (Rot markiert) " statt ':
par:ICON;ICON as set, defaults to taster;{ AttrVal('DEVICE','icon",'taster') }
#contributed by twdotnet, https://forum.fhem.de/index.php?msg=1282883
# shelly plus i4 4 channel input switches with device configuration
name:tasmota_4channel_input_shelly_i4
filter:TYPE=MQTT2_DEVICE
desc:Shelly i4 device flashed with Tasmota, provides four input only channels. <p>Device will be configured with selectable SwitchMode and optional GPIO Template. <br>Recommended SwitchModes 1=FollowMode (normally open switches> or 2=InvertedFollowMode (normally closed switches) </p><p>Tasmota 9.1+ is required for <a href=https://tasmota.github.io/docs/Buttons-and-Switches/#setoption114>SetOption114</a> to detach switches from relays.<p>NOTE: <br>A second, third and fourth device will be created for the second, third and fourth input with suffixes *_CH2, *_CH3 and *_CH4</p>
order:A_03a
par:RADIO_TEMPLATE;Configure device and GPIO;{ undef }
par:RADIO_NO_TEMPLATE;Configure device without GPIO template;{ undef }
par:SWITCHMODE1;SwitchMode for Input 1;{ undef }
par:SWITCHMODE2;SwitchMode for Input 2;{ undef }
par:SWITCHMODE3;SwitchMode for Input 3;{ undef }
par:SWITCHMODE3;SwitchMode for Input 4;{ undef }
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal('DEVICE','readingList','') =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal('DEVICE','readingList','') =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}tele$3" : undef }
par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal('DEVICE','readingList','') =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }
par:SETCHANNELINFO;Set this to 0 to not set channelinfo;{ 1 }
par:ICON;ICON as set, defaults to taster;{ AttrVal('DEVICE','icon",'taster') }
par:IO_DEV;Currently used IO;{ AttrVal('DEVICE','IODev',InternalVal('DEVICE','IODev',undef)->{NAME}) }
Kann das vielleicht jemand korrigieren? Ich weiß leider nicht wie das geht.
Zitat von: Django.Edwards am 07 Dezember 2023, 13:45:05Kann das vielleicht jemand korrigieren? Ich weiß leider nicht wie das geht.
Thx für den Hinweis, Korrektur ist seit eben im svn und kann ab morgen per update bezogen werden.
(Korrigieren kann das theoretisch jeder, der svn-Schreibrechte hat, und es ist m.E. ganz sinnvolle Praxis, dass da nicht jeder drin schreiben kann...).
Zitat von: denis.robel am 03 Dezember 2023, 19:26:27Ich habe ein Tuya IR-Gateway mit Hilfe des tuya-cloudcutter mit openbeken versehen.
IR-Gateway (https://www.elektroda.com/rtvforum/topic3940178.html)
Senden und Empfangen funktionieren. Das Senden funktioniert mit der setList.
Ich habe jetzt versucht ein Template zu bauen. Es klappt aber nicht so richtig. Könnte hier bitte mal jemand drüber schauen?
###########################################
# $Id: mqtt2.template 23288 2020-12-04 06:11:47Z Beta-User $
#
# Comments start with #. Empty lines are ignored.
# Syntax of one entry: name: line, one optional filter: line, zero or more par: lines, FHEM-Commands
# filter:INTERNAL=VALUE (optional)
# par: name of the parameter; comment; perl_code (optional)
# perl_code returns a value for the parameter, or undef.
# If undef, the user has to specify them (the comment is shown to the user)
###########################################
# OpenBeken
name:OPNBEKEN_SmartPlug
filter:TYPE=MQTT2_DEVICE
desc:Applies to OpenBeken SmartPlug like Tuya LSPA9 clones
par:ICON;ICON as set, defaults to hue_filled_outlet;{ AttrVal("DEVICE","icon","hue_filled_gu10") }
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE setList \
off:noArg cmnd/DEVICE/Power1 0\
on:noArg cmnd/DEVICE/Power1 1\
toggle:noArg cmnd/DEVICE/Power1 2\
reboot:noArg cmnd/DEVICE/Restart 1
attr DEVICE webCmd on:off:toggle:reboot
attr DEVICE event-on-change-reading .*
attr DEVICE icon ICON
attr DEVICE room MQTT2_DEVICE
attr DEVICE devStateIcon ON:rc_GREEN:off OFF:rc_RED:on offline:rc_BLUE:off
attr DEVICE stateFormat { if(ReadingsVal("DEVICE","POWER",0) eq "ON") {return "on";;} else {return "off";;} }
attr DEVICE readingList \
DEVICE/connected:.* connected\
DEVICE/host:.* host\
DEVICE/build:.* build\
DEVICE/mac:.* mac\
DEVICE/sockets:.* sockets\
DEVICE/rssi:.* rssi\
DEVICE/uptime:.* uptime\
DEVICE/freeheap:.* freeheap\
DEVICE/ip:.* ip\
DEVICE//1/get:.* obkFFC5CF49_1_get\
stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }\
tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
DEVICE/voltage/get:.* ENERGY_Voltage\
DEVICE/current/get:.* ENERGY_Current\
DEVICE/power/get:.* ENERGY_Power\
DEVICE/energycounter/get:.* ENERGY_Total\
DEVICE/energycounter_last_hour/get:.* ENERGY_LastHour
attr DEVICE model OpnBeken_SmartPlug
setreading DEVICE attrTemplateVersion 20231202 or prior
Zitat von: denis.robel am 15 Dezember 2023, 23:09:51Ich habe jetzt versucht ein Template zu bauen. Es klappt aber nicht so richtig. Könnte hier bitte mal jemand drüber schauen?
Magst du zu openbeken bitte einen gesonderten Thread aufmachen? Das fällt nach meinem Eindruck noch nicht unter "fertiges template" (dieser Thread), sondern unter "support für neue templates".
Dort bitte links zur Doku des Projekts und ein _ganzes_ raw-list. Vielleicht auch noch etwas MQTT-Traffic, mal sehen. Aber an sich sieht das erst mal aus wie ein etwas angepaßtes Tasmota, so dass diese template-Familie eigentlich eine gute Basis sein könnte (ggf. auch, was das Umkonfigurieren des "on/off"-Werts angeht)?
Zitat von: Beta-User am 18 Dezember 2023, 08:05:16Magst du zu openbeken bitte einen gesonderten Thread aufmachen? Das fällt nach meinem Eindruck noch nicht unter "fertiges template" (dieser Thread), sondern unter "support für neue templates".
Dort bitte links zur Doku des Projekts und ein _ganzes_ raw-list. Vielleicht auch noch etwas MQTT-Traffic, mal sehen. Aber an sich sieht das erst mal aus wie ein etwas angepaßtes Tasmota, so dass diese template-Familie eigentlich eine gute Basis sein könnte (ggf. auch, was das Umkonfigurieren des "on/off"-Werts angeht)?
ist hiermit geschehen: https://forum.fhem.de/index.php?topic=136291.0
Hallo zusammen,
für den Shelly 2pm habe ich das bereits vorhandene Template namens shellyPlus_2pm_roller_invert_0 kopiert und unter dem Namen shellyPlus_2pm_roller_invert_1 angepasst. Bei dem neuen Template ist 0=opened / 100=closed, während bei dem alten 100=opened / 0=closed darstellt. Gleiches gibt es auch schon für den Shelly 2.5 mit den Templates shelly25_roller_invert_0 bzw. shelly25_roller_invert_1. Im Anhang ist die Diff Datei mit der Bitte um Prüfung und Übernahme in das Template.
Vielen Dank
Mein erstes Template. Im Gegensatz zu zigbee2mqtt_blind_drive ohne die MotorSpeed-Option und ohne die Anführungszeichen um den pct-Wert - letzterer wurde mit Anführungszeichen seit z2m v. 1.3x nicht mehr numerisch, sondern als String ausgewertet und funktionierte daher nicht mehr:
# Blind controller Lonsonho QS-Zigbee-C01 and QS-Zigbee-C03 connected via zigbee2mqtt
#contributed by dadoc based on zigbee2mqtt_blind_drive by barneybaer
name:zigbee2mqtt_blind_controller
desc: A blind controller connected via zigbee2mqtt <br>Tested with: Lonsonho QS-Zigbee-C01 and QS-Zigbee-C03
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_05f0
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
par:ICON;ICON as set, defaults to fts_shutter_100;{ AttrVal("DEVICE","icon","fts_shutter_100") }
attr DEVICE icon ICON
attr DEVICE devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
attr DEVICE webCmd open:close:stop:pct
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE jsonMap position:pct
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE setList \
open:noArg $\DEVICETOPIC/set {"state":"OPEN"}\
close:noArg $\DEVICETOPIC/set {"state":"CLOSE"}\
stop:noArg $\DEVICETOPIC/set {"state":"STOP"}\
pct:slider,0,1,100 $\DEVICETOPIC/set {"position":$EVTPART1}
motor_reversal:ON,OFF $\DEVICETOPIC/set {"motor_reversal": "$EVTPART1"}
calibration:ON,OFF $\DEVICETOPIC/set {"calibration": "$EVTPART1"}
attr DEVICE stateFormat pct
set DEVICE attrTemplate speechcontrol_type_blind
attr DEVICE model zigbee2mqtt_blind_controller
setreading DEVICE attrTemplateVersion 20240104Grüße
Martin
Hallo,
gibt es einen Grund das du nicht gleich setter für Moving (https://www.zigbee2mqtt.io/devices/QS-Zigbee-C03.html#moving-enum), Calibration (https://www.zigbee2mqtt.io/devices/QS-Zigbee-C01.html#calibration-binary) und Motor reversal (https://www.zigbee2mqtt.io/devices/QS-Zigbee-C01.html#motor-reversal-binary) vorgesehen hast ?
Ja, hamwa noch nicht durchgenommen bzw. da war ich krank...
Nee, ich konnte mich heute nur oberflächlich in das Thema einlesen, habe ab morgen früh eine 2.000 km lange Heimfahrt vor mir und war froh, dass ich das nach einem entnervenden z2m-Update-Chaos gestern überhaupt wieder nutzbar machen konnte.
Wenn ich wieder in der Homebase bin, werde ich mir das genauer anschauen.
Zitat von: TomLee am 04 Januar 2024, 13:10:04gibt es einen Grund das du nicht gleich setter für Moving (https://www.zigbee2mqtt.io/devices/QS-Zigbee-C03.html#moving-enum), Calibration (https://www.zigbee2mqtt.io/devices/QS-Zigbee-C01.html#calibration-binary) und Motor reversal (https://www.zigbee2mqtt.io/devices/QS-Zigbee-C01.html#motor-reversal-binary) vorgesehen hast ?
Motor_reversal und calibration habe ich gerade im obigen Code eingebaut; moving ist m.W. nicht beschreibbar (auch nicht im zigbee2mqtt-UI).
Grüße
Martin
ZitatMotor_reversal und calibration habe ich gerade im obigen Code eingebaut; moving ist m.W. nicht beschreibbar (auch nicht im zigbee2mqtt-UI).
Danke.
Dann hoffe ich das alles passt und die Teile was taugen, mich machen die an, darum hab ich mir eben welche bestellt :)
darum hab ich mir eben welche bestellt
Schade, hätte ich das gewusst - ich habe 4 Stück übrig
ZitatSchade, hätte ich das gewusst - ich habe 4 Stück übrig
Und warum hast du vier übrig ?
Weil du nicht überzeugt bist und die vermutlich kacke sind ?
Oder waren die im XXL-Pack so günstig ?
Hey Tom, warum so garstig?
Ich habe vier übrig, weil ich zunächst welche in Deutschland geordert habe, bei Kaufland. Die wurden auch anstandslos geliefert, und ich habe sie sodann per Paket an den Bestimmungsstandort Spanien geschickt. Als das Paket nach vier Wochen immer noch nicht angekommen war, habe ich es als verloren betrachtet (nicht das erste Mal) und neu bestellt, diesmal bei Ali. Ungefähr zeitgleich mit der Ali-Lieferung ist dann das verloren geglaubte Paket doch noch in Spanien aufgeschlagen. Eigentlich habe ich sogar fünf übrig, aber ich habe mir eines mitgenommen, einzig und allein um Deine ,,Reklamation" wegen Calibration und Motor Reversal bearbeiten zu können. Das hätte ich übrigens kaum gemacht, wenn die Teile ,,vermutlich kacke" wären, oder?
Hoffe, ich habe mich ausgiebig genug gerechtfertigt...?
Hallo, ich mach mal hier (https://forum.fhem.de/index.php?msg=1302529) weiter.