mqtt2.template: bugs, Fragen, Anregungen

Begonnen von Beta-User, 15 Dezember 2018, 11:44:43

Vorheriges Thema - Nächstes Thema

aperoap

Hi Beta, Danke erstmal für den Tipp mit dem timeout. Hab jetzt in /opt/zigbee2mqtt/data/configuration.yaml mit availability_timeout: 60 timeout definiert. Dadurch bekomme ich folgende readings
defmod MQTT2_zigbee_0x00124b000be88fe7 MQTT2_DEVICE zigbee_0x00124b000be88fe7
attr MQTT2_zigbee_0x00124b000be88fe7 IODev MQTT2_SERVER
attr MQTT2_zigbee_0x00124b000be88fe7 alias Router_CC2531_EG_WC
attr MQTT2_zigbee_0x00124b000be88fe7 group Bridge
attr MQTT2_zigbee_0x00124b000be88fe7 icon mqtt_device
attr MQTT2_zigbee_0x00124b000be88fe7 imageLink /fhem/deviceimages/mqtt2/CC2530.ROUTER.jpg
attr MQTT2_zigbee_0x00124b000be88fe7 readingList zigbee2mqtt/0x00124b000be88fe7:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00124b000be88fe7/availability:.* availability
attr MQTT2_zigbee_0x00124b000be88fe7 room MQTT2_DEVICE

setstate MQTT2_zigbee_0x00124b000be88fe7 true
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 19:20:40 associatedWith MQTT2_mqttjs_f6b1e812
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 20:16:46 availability online
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 20:17:19 led_state true
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 20:17:19 linkquality 0
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-11 20:17:19 state true

Ist der Router aus, bekommt availability offline state bleibt weiterhin auf true.
"devStateIcon" bezieht sich doch immer auf "state" oder kann man das auf availability beziehen und virsualisieren mit grüne und rote punkte?

Das mit "linkquality" verstehe ich auch nicht. Die Geräte sind meistens auf 0.


Beta-User

...wenn wir beide linkquality nicht verstehen, lassen wir es erst mal weg...

Was devStateIcon angeht, solltest du dich erst mal noch etwas einlesen, wobei das Attribut selbst nicht völlig isoliert im Raum steht ;) . Startpunkte vielleicht: https://wiki.fhem.de/wiki/DeviceOverview_anpassen und https://wiki.fhem.de/wiki/DevStateIcon

Im file mqtt2.template sind auch einige Variante vorhanden, für online/offline z.B. auch für die zigbee2mqtt-bridge, wenn ich das richtig im Kopf habe.
Würde vorschlagen, du schaust dich ein wenig um und versuchst zunmindest eine erste Version, dann können wir das ggf. erforderlichenfalls weiter optimieren?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

aperoap

Sie sieht das mittlerweile bei mir aus
defmod MQTT2_zigbee_0x00124b000be88fe7 MQTT2_DEVICE zigbee_0x00124b000be88fe7
attr MQTT2_zigbee_0x00124b000be88fe7 IODev MQTT2_SERVER
attr MQTT2_zigbee_0x00124b000be88fe7 alias Router_CC2531_EG_WC
attr MQTT2_zigbee_0x00124b000be88fe7 devStateIcon online:rc_GREEN offline:rc_RED
attr MQTT2_zigbee_0x00124b000be88fe7 group Bridge
attr MQTT2_zigbee_0x00124b000be88fe7 icon mqtt_device
attr MQTT2_zigbee_0x00124b000be88fe7 imageLink /fhem/deviceimages/mqtt2/CC2530.ROUTER.jpg
attr MQTT2_zigbee_0x00124b000be88fe7 readingList zigbee2mqtt/0x00124b000be88fe7/availability:.* availability\
zigbee2mqtt/0x00124b000be88fe7:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0x00124b000be88fe7 room MQTT2_DEVICE
attr MQTT2_zigbee_0x00124b000be88fe7 stateFormat availability

setstate MQTT2_zigbee_0x00124b000be88fe7 online
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:01:24 associatedWith MQTT2_mqttjs_f6b1e812
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:34:25 availability online
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:38:24 led_state true
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:38:24 linkquality 0
setstate MQTT2_zigbee_0x00124b000be88fe7 2019-11-12 20:38:24 state true


Ist sehr einfach gehalten. Zeigt jedoch wenn der Router offline oder online ist mit rc_GREN und rc_RED.

Was hältst du davon, kann man das besser machen? :-)

Beta-User

Besser ist immer relativ.

Habe das availability jetzt direkt zu state gemacht, weiß aber noch nicht, ob das soooo toll ist. Bei "normalen" routern, z.B. Leuchten ist das nicht so toll, und dann hat man unterschiedliche Readingnamen für dieselbe Sache (=> Rückmeldung erbeten!)...

Wenn man weitere Dinge hat zum Anzeigen, finde ich die kleinen Punkte eigentlich ganz nett (10px-Icons), die bei den Shelly-templates für on-/offline verwendet werden. Aber für die Anzeige "solo" sind die eben auch sehr klein...

Wie dem auch sei, Vorschlag mdB. um Test:
#A pure router device, e.g. a CC2531 flashed with router firmware
#Contributed by aperoap, https://forum.fhem.de/index.php/topic,94494.msg992467.html#msg992467
name:zigbee2mqtt_router_only_device
desc: For zigbee2mqtt pure router devices, e.g. a CC2531 flashed with router firmware. To get information on device going offline, set "availability_timeout" to a reasonable value in zigbee2mqtt's configruation.yaml.
filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
order:L_02a1
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
par:ICON;ICON as set, defaults to light_control;{ AttrVal("DEVICE","icon","mqtt_device") }
attr DEVICE icon ICON
attr DEVICE devStateIcon online:rc_GREEN offline:rc_RED
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }\
  BASE_TOPIC/DEV_ID/availability:.* state
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE comment To get also information on device going offline, set "availability_timeout" to a reasonable value in configruation.yaml.
farewell:template has been applied successfully. Please check configuration.yaml to get regular updates on availability.
attr DEVICE model zigbee2mqtt_router_only_device
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

aperoap

#139
hallo,
availability jetzt direkt zu state habe ich auch schon ausprobiert gehabt.zigbee2mqtt/xxxxxxx/availability:.* state
Problem: availability und state werten in unterschiedlichen Zeitpunkten aktualisiert ist STATE nicht mit stateFormat in attr. definiert, bekommt STATE automatisch den Wert von state sobald state aktualisiert, somit wechselt STATE zwischen online und true. Daher habe ich in meinem Beispiel mit stateFormat mit availability in attr. gesetzt.

ulli

Hallo zusammen,
ich nutze schon erfolgreich einige xiaomi Sensoren.
Bei anderen Komponenenten Werte ich über das Monitoring Modul den Batterie Status erfolgreich aus.
Leider stellt das mqtt template kein reading mit batteriestatus bereit, daher geht mein monitoring Modul nicht mit den Xiaomis.

Wie macht ihr das? Könnte man das Batterie reading ggf umbenennen in batterie_pct und ändert das Batterie reading in einen Status ok,low

Was denkt ihr?

rudolfkoenig

Ich weiss nicht wie die Readings in deinem Fall angelegt sind, es gibt aber mehrere Moeglichkeiten diese umzubennen.

Beta-User

Zitat von: ulli am 17 November 2019, 17:02:55
Leider stellt das mqtt template kein reading mit batteriestatus bereit, daher geht mein monitoring Modul nicht mit den Xiaomis.

Wie macht ihr das? Könnte man das Batterie reading ggf umbenennen in batterie_pct und ändert das Batterie reading in einen Status ok,low

Was denkt ihr?
batterie_pct finde ich nicht gut, wir sollten uns entweder an dem rrientieren, was der Autor von zigbee2mqtt sich gedacht hatte ("battery"), oder diesen Wert in eine Reading-Nomenklatur überführen, der "FHEM-konform" ist, siehe dazu auch diese Diskussion. Danach wäre es batteryPercent, am einfachsten für die zigbee2mqtt-Batterie-Geräte wohl zu realisieren über ein JSONMAP.

Tendenziell würde ich mich dagegen aussprechen, hier weitere Auswertungen via template dazu zu basteln, das will am Ende jeder anders haben bzw. die Grenzwerte anders setzen usw., jedenfalls besteht die Gefahr, dass das nicht mehr als "ermittelter Wert" für jeden erkennbar ist. Wenn jemand einen Vorschlag macht, kann ich das gerne entweder als eine Art "add-on" versuchen mit reinzubasteln, oder wir übernehmen das als erweiterte Nutzerkonfigurations-Option in die "Praxisbeispiele".

Wer dazu was liefern will: Erweiterte Funktion json2nameValue verwenden ("json2nameValue($EVENT,'',$JSONMAP)") und ein passendes Attribut ("attr <device> jsonMap battery:batteryPercent").
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Via pm hat jemand angemerkt, dass für den shellydimmer pct versendet, aber brightness (im JSON) zurückgemeldet wird, damit scheint der "Rückweg" nicht ganz geschlossen zu sein. Da aber der Wertebereich lt. https://shelly-api-docs.shelly.cloud/#dimmer-sl-settings nur bis 100 geht, erscheint mir der Name "pct" logischer, als es nach brightness umzubenennen (so wird es im JSON übertragen).

Daher die allgemeine Frage an die Gemeinde: ich würde dazu tendieren, Helligkeitswerte von 0-255 in das "brightness"-Reading zu schieben, und solche im Bereich 0-100 nach "pct".

Frage: Gibt es dazu Einwände?
(Im Moment scheint das nur die Shelly-Nutzer (shellydimmer, shelly2rgbw_4w_split, shelly2rgbw_color) zu betreffen, die wären also vorrangig aufgefordert, ihre Meinung abzugeben... Das wirkt sich übrigens auch nur aus, wenn man das template nochmal anwendet, vorhandene Konfigurationen werden - wie immer bei attrTemplate - nicht automatisch angetastet!).

Das fragliche template für den shellydimmer sähe dann so aus, bitte testen:

#shellydimmer
# contributed by zeppelin, https://forum.fhem.de/index.php/topic,94495.msg994764.html#msg994764
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}\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
deletereading -q DEVICE status_.*
attr DEVICE readingList \
  shellies/DEVNAME/light/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
  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 jsonMap brightness:pct
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


Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

Hallo zusammen,

ich selber habe keinen Shelly Dimmer. Allerdings habe ich den RGBW2. Bei dem sehe ich keine Probleme. Außer, das ich diesen nicht sauber über Alexa steuern kann. Bei rot oder weiß macht er nicht ganz mit. Aber das ist wohl nur eine Kleinigkeit in der Umrechnung der von Alexa gewollten Werte... Habe ich mich aber auch nicht weiter mit beschäftigt, da aktuell wenig Zeit.

Was den Dimmer angeht - Macht es in meinen Augen schon Sinn über PCT zu arbeiten. Alleine wegen der Alexa Steuerung. Geht bei Rollos, geht bei anderen Lampen und sollte einheitlich sein.

Gruß,
Kai / jemand :-P

Beta-User

@87insane:
Ist die Rückmeldung so zu verstehen, dass du das mit der jsonMap im RGBW2 ausgetestet hattest?
(@all: Das sollte da bzw. auch bei dem dritten) genauso funktionieren, wenn die erste Zeile der readingList geändert und das attr jsonMap (ggf. auch bei den weiteren Kanälen) auf "brightness:pct" gesetzt wird).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

#146
Hi nochmal,

jsonMap: Nein. Ich hatte nur mal ein wenig quer gelesen. Was will Alexa, was machen/geben die Geräte und was geht direkt, bei welchen Werten, mit welchen Readings. Da blau und grün z.B. super geht und auch Mix Farben, in denen Rot mit drin ist, kann ich auch nicht alle Geräte falsch verkabelt haben ;)
Müsste das bei mir genutzte Template zum RGBW2 auch mal gegen das aktuelle im SVN legen. Ich weiß nicht ob Du/Ihr ggf. noch was geändert hattet, nachdem ich das nutzte... Prüfe das mal eben...

EDIT: Habe mal drüber gesehen. Scheint keine Änderungen mehr gegeben zu haben, die hier relevant wären. Nutze die rgb_on usw Setter. Finde das mit Alexa besser, da diese dann auch direkt das Licht an macht und nicht nur die Modi einstellt.

Nochmal EDIT: Da wir aber schon dabei sind.. Ich habe an dem RGBW2 Template nicht mit gewirkt und ggf. liegt es daran, dass ich das nicht ganz checke. Es gibt ein Userreading, welches rgb ein wenig anders darstellt.
   
rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}

Kann mir das einer kurz erklären? Ich sehe es soll auf rot.* Änderungen reagieren. Danach wird die Mode abgefragt und die Werte der Farben eingesetzt. Wen die Mode nicht Color ist, wird $a definiert. In $a wird die Helligkeit rein geschrieben wenn keine Farbe aktiv..
Warum bzw wofür das ganze genau?

Beta-User

Zu dem RGBW2:
Der Shelly braucht als Input getrennte Angaben für die drei Farben (als JSON) und liefert das auch so zurück. Ist die Farbe weiß, sind alle drei Kanäle gleich. Lesend findest du das z.B. im userReadings als "$a$a$a", schreibend, indem "plötzlich" brightness+white gesendet wird. Da der Hex-Wert (hier: $a) sich aber mit der Helligkeit ändert, wird eben bei der Auswertung eine Variable verwendet und kein fester Wert, wobei zwischendurch noch eine Umrechnung von pct (0-100) nach hex (00-ff=255) sein muß...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Hallo zusammen,

Frage/Anregung allgemein zu Tasmota, nachdem ich so langsam aber sicher auch verstanden habe, wie das mit dem JSONMAPing funktioniert und das Thema hier hochkam:

Die Tasmota-Geräte verwenden in der Regel POWER1 für die Rückmeldung zum ersten Kanal. Häufig gibt der das Hauptreading wieder, sollte also optimalerweise nach "state" (entsprechend bei den mehrkanaligen "split"-Versionen dann für POWER2 usw.). Das wäre recht einfach mit JSONMAP zu machen, allerdings wäre das ein breaking change.
In der readingList wäre der Eintrag für RESULT zu ändern in
stat/sonoff3/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
und statt der stateFormat-Sache würde man
attr DEVICE jsonMap POWER1:statesetzen.
Wer es weiter wie bisher haben will, müßte dann stateFormat beibehalten und das jsonMap-Attribut löschen.

Ich tendiere dazu, das bei allen Tasmotas dann bei Gelegenheit so umzusetzen (evtl. mit zwei Converter-templates zum vereinfachten Umstellen), aber wenn es große Einwände gibt, gilt wie immer: Ihr bekommt, was ihr bestellt...

Grüße, Beta-User


Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

Hey und guten Morgen,

anbei mal die kompletten Infos zum ShellyDimmer. Hab mir diese von einem anderen Kollegen mit einem solchen besorgt. Ggf. klärt es das noch offene Thema mit den pct.

shellies/shellydimmer-bla/light/0/set {"turn": "on","brightness": 35}
shellies/shellydimmer-bla/light/0 on
shellies/shellydimmer-bla/light/0/status {"ison":true,"mode":"white","brightness":35}
shellies/shellydimmer-bla/temperature 43.74
shellies/shellydimmer-bla/temperature_f 110.74
shellies/shellydimmer-bla/overtemperature 0
shellies/shellydimmer-bla/overload 0
shellies/shellydimmer-bla/loaderror 0
shellies/shellydimmer-bla/light/0/power 9.56
shellies/shellydimmer-bla/online true


Gruß,
Kai