MQTT2 Aqara Vibrationssensor - Werte an der Bridge statt an neuem Gerät

[masterpete23]

Hmm, irgendwie paßt diese Aussage nach meinem Weltbild nicht zu der Info von neulich, dass du auf eine der networkmap-Anfragen ein neues Gerät angelegt bekommen hast mit dieser readingList:

Code: [Auswählen]

readingList zigbee2mqtt/bridge/response/networkmap:.* networkmapDanach war ich davon ausgegangen, dass eine Anfrage rausgeht, die Antwort aber auf einem anderen Pfad kommt als bisher bekannt.
Aber da es anscheinend keine weiteren Betroffenen gibt oder das Thema auch nicht so wichtig zu sein scheint, sollten wir es erst mal dabei belassen.

Ah njein. Ich hatte es händisch über das zigbee2mqtt frontend ausgelöst. Dabei wurde die Antwort dann als neues Device angelegt

[Beta-User]

...diese Bruchstücke helfen nur bedingt weiter, daher hatte ich versucht, das unter Berücksichtigung der Infos von @OdfFhem in meinem letzten Post zu konsolidieren.
Ist es denn so schwierig, das auf das eigene Umfeld anzupassen und dann eine Rückmeldung zu geben, ob das so klappt bzw. wie es klappt und anzupassen ist?

[masterpete23]

...
ich hatte die Antwort von OdfFhem überlesen - sorry.

Also wenn ich nun über mein Bridge die  getlist auf

Code: [Auswählen]

devicelist:noArg log $DEVICETOPIC/bridge/devices
  networkmap_raw:noArg raw $DEVICETOPIC/bridge/request/networkmap raw
  networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/request/networkmap graphvizangepasst habe, wird bei networkmap der Scan korrekt ausgelöst
die Antwort kommt über zigbee2mqtt/bridge/response/networkmap leider wieder bei dem falschen Device an.
Dann habe ich die Readinglist Einträge von dem "falschen" Device auf meins übersetzt:

Code: [Auswählen]

$DEVICETOPIC/bridge/response/networkmap:.* networkmap
$DEVICETOPIC/bridge/response/options:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/response/device/rename:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/response/device/ota_update/check:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/response/device/ota_update/update:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/response/group/remove:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/response/group/add:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/response/group/members/add:.* { json2nameValue($EVENT) }
Der Timeoutfehler kommt trotzdem nach kurzer Zeit
request:  11:15:51
response: 11:16:53

Das Reading ist nun korrekt am richtigen Device.
bei Graphwiz das gleiche.

Devicelist will leider nicht funktionieren.

[Beta-User]

Hmmm, wie nach der etwas zögerlichen Info von OdfFhem eigentlich nicht anders zu erwarten war, scheint es keine getrennten Topics mehr zu geben für Antworten auf Anfragen für "raw"- und "graphviz"-maps. Soweit so unklar...
Bedeutet...? Neues Reading? Oder eines der beiden bestehenden hernehmen? Braucht es Änderungen wegen der Map-Erstellung in FHEMWEB?

Werde jetzt erst mal bei Gelegenheit eine Zwischenlösung ins svn schubsen.

Was "devicelist" angeht: von der zigbee2mqtt-UI aus die Anfrage anschubsen, um den neuen Topic zu ermitteln, und schauen, wohin die Antwort kommt. getList und readingList entsprechend ändern und hier das Ergebnis zeigen.

[OdfFhem]

Ich selbst verwende produktiv kein allerneuestes zigbee2mqtt ... daher nur Doku "gelesen" ...

Ich kann aber heute Abend mal das Testsystem "analysieren" - sofern noch Infos fehlen ...

[Beta-User]

  Danke für die Erhellung des Hintergrunds des etwas kryptischen Hinweises .
Das Ganze eilt ja nicht, allerdings versuche ich bekanntermaßen, die attrTemplate jeweils auf den gerade aktuellen Stand der firmware/Software-Version der Gegenseite anzupassen, so dass derjenige, der irgendwas updated dann eben auch auf derm FHEM-Seite einen funktionsfähigen Stand hat. Von daher wäre es natürlich schön, wenn ich den Punkt hier irgendwann wieder für mich (bzw. für die davon profitierenden User) schließen könnte, ohne tiefer Nachgrübeln zu müssen .

[masterpete23]

devicelist kann wohl erstmal raus: https://github.com/Koenkk/zigbee2mqtt/discussions/11294

ist die Zwischenlösung zum Test schon im SVN? Dann könnte ich deine Idee mal bei mir testen:
Ob der Timeout noch kommt und ob eine Visualiserung zu sehen ist.

[Beta-User]

devicelist kann wohl erstmal raus: https://github.com/Koenkk/zigbee2mqtt/discussions/11294

OK, dann werfe ich das mal aus der getList.

ist die Zwischenlösung zum Test schon im SVN? Dann könnte ich deine Idee mal bei mir testen:
Ob der Timeout noch kommt und ob eine Visualiserung zu sehen ist.

Nein, damit wollte ich warten, bis weitere Rückmeldung kam. Die "Vertemplatung" ist ja kein Hexenwerk.

Jetzt geht es eigentlich nur darum, ob mit der neuen getList dann die Daten an denselben Topic gesendet werden oder ob das nach wie vor zwei Topics sind (und welcher Typ nach bisherigen Maßsstäben jetzt ggf. unter der Bezeichnung networkmap geliefert wird, falls es verschiedene sind).
Bei der Visualisierung ist mir grade nicht gegenwärtig, wie Rudi das gebastelt hatte, also ob eine bestimmte Datenstruktur unter einem bestimmten Readingnamen erwartet wird (ich meine, es müßte die graphviz-Variante gewesen sein).

[OdfFhem]

Auszug aus getList:

Code: [Auswählen]

networkmap_raw:noArg raw $DEVICETOPIC/bridge/request/networkmap raw
networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/request/networkmap graphviz

Auszug aus readingList:

Code: [Auswählen]

$DEVICETOPIC/bridge/response/networkmap:.* { my $type = $EVENT =~ m/.*,"type":"(raw|graphviz)",.*/ ? $1 : 'networkmap'; $EVENT =~ m/{"data":\{.*"value":"?(.*[^"])"?\},"status":"ok"\}/ ? { $type=>$1 } : {} }
$DEVICETOPIC/bridge/request/networkmap:.* {}
- ermittelt den type der Antwort und speichert diesen in $type
- extrahiert den Wert von value
- ist ein passender value vorhanden, dann Speicherung unter $type

* networkmap_raw funktioniert

* networkmap_graphviz funktioniert im Grunde auch, jedoch ist der hinterlegte Wert im Reading nicht nutzbar.
- bekommt man keinen Timeout, dann sieht man im aufgeblendeten Dialog:

Code: [Auswählen]

digraph G { node[shape=record]; "0x00124b00258 ...
Kopiert man den gesamten Inhalt ohne das führende graphviz, dann kann man die Geräte visualisieren.

- Im Reading steht Folgendes:

Code: [Auswählen]

digraph G {\nnode[shape=record];\n \"0x00124b00258 ...
Zeilenumbrüche und Anführungszeichen sind maskiert - man kann nicht (einfach) die Geräte visualisieren.

- wie wird man auf einfach(st)e Art die Maskierung los ?

[Beta-User]

...unschön....

Wenn ich Rudi noch richtig in Erinnerung habe, war damals die Reaktion auf das irgendwann aufgetauchte "raw": "wenn ich das früher gewußt hätte..." Ergo ist es vermutlich einfacher, den Grafikerstellungscode mal anzusehen und zu versuchen, den auf raw umzubiegen. Dann wären wir vermutlich weniger abhängig von dem, was irgendjemand meint "verbessern" zu müssen...

Werde halt bei Gelegenheit mal den "ist"-Stand einpflegen, mal schauen, ob sich jemand findet, der sich das antut...

[Beta-User]

- wie wird man auf einfach(st)e Art die Maskierung los ?

Hmm, der Code für die Visualisierung ist in MQTT2_DEVICE zu finden: MQTT2_DEVICE_nlData(). Vielleicht kann man da am Anfang eine Säuberungsfunktion einbauen?
Ansonsten wäre es wie gesagt vermutlich zielführender, den Teil so umzubauen, dass er mit "raw"-Input klarkommt.

Für die Anzeige der Images ist übrigens auch "devices" erforderlich; falls nicht nur die Abfrageoption entfallen ist, sondern der ganze Inhalt, klappt der Teil schon mal nicht mehr...

[rudolfkoenig]

- wie wird man auf einfach(st)e Art die Maskierung los ?

Alle Daten zum Reproduzieren hier anhaengen, und nett fragen, ob die Funktion fuer diese Variante gefixt werden koennte.

[OdfFhem]

type und value ermittle ich aktuell über einen regulären Ausdruck - werden also nur "ausgeschnitten" und nicht konvertiert.
Für  type egal, da nur 1 Wort; bei value führt dies nicht immer zum gewünschten Format.

- graphviz liefert als value einen für JSON konvertierten String, daher die Maskierungen

Code: [Auswählen]

$DEVICETOPIC/bridge/response/networkmap {"data":{"routes":false,"type":"graphviz","value":"digraph G {\nnode[shape=record];\n  \"0x00124b0025e70bd8\" [style=\"bold, filled\", fillcolor=\"#e04e5d\", fontcolor=\"#ffffff\", label=\"{Coordinator|0x00124b0025e70bd8 (0x0000)|0 seconds ago}\"];\n  \"0x0017880103abf482\" [style=\"rounded, dashed, filled\", fillcolor=\"#fff8ce\", fontcolor=\"#000000\", label=\"{motionSensor2|0x0017880103abf482 (0x1b0b)|Philips Hue motion sensor (9290012607)|1 minute, 8 seconds ago}\"];\n  \"0x0017880103abf482\" -> \"0x00124b0025e70bd8\" [penwidth=1, weight=0, color=\"#994444\", label=\"143\"]\n}"},"status":"ok"}

- raw liefert als value ein JSON-Objekt

Code: [Auswählen]

$DEVICETOPIC/bridge/response/networkmap {"data":{"routes":false,"type":"raw","value":{"links":[{"depth":1,"linkquality":135,"lqi":135,"relationship":1,"routes":[],"source":{"ieeeAddr":"0x0017880103abf482","networkAddress":6923},"sourceIeeeAddr":"0x0017880103abf482","sourceNwkAddr":6923,"target":{"ieeeAddr":"0x00124b0025e70bd8","networkAddress":0},"targetIeeeAddr":"0x00124b0025e70bd8"}],"nodes":[{"definition":null,"failed":[],"friendlyName":"Coordinator","ieeeAddr":"0x00124b0025e70bd8","lastSeen":null,"networkAddress":0,"type":"Coordinator"},{"definition":{"description":"Hue motion sensor","model":"9290012607","supports":"temperature, occupancy, battery, illuminance_lux, illuminance, motion_sensitivity, led_indication, occupancy_timeout, linkquality","vendor":"Philips"},"friendlyName":"motionSensor2","ieeeAddr":"0x0017880103abf482","lastSeen":1645255436416,"manufacturerName":"Philips","modelID":"SML001","networkAddress":6923,"type":"EndDevice"}]}},"status":"ok"}

Um anzutesten, ob ich die Werte nicht besser von json2nameValue ermitteln lassen kann, habe ich Folgendes ausprobiert:

Code: [Auswählen]

  zigbee4mqtt/bridge/response/networkmap:.* { my %j2v = %{json2nameValue($EVENT,"",{"data_type"=>"type","data_value"=>"value"},".*(type|value).*")}; return { $j2v{'type'}=>$j2v{'value'} }; }
Ergebnis war, dass für graphviz tatsächlich der bereinigte Wert im Reading landete und somit auch die neighbor map angezeigt werden konnte. Wert vom Reading kann in dieser Form auch für externe "Apps" genutzt werden.

Für raw kam es zu einem Fehler, da in der Antwort zwar ein value vorhanden ist, aber dessen Wert wiederum ein eigenes JSON-Objekt darstellt - folglich existiert value bei Anwendung von json2nameValue nicht wirklich ...


@rudolfkoenig
Gibt es bereits bzw. besteht die Chance auf eine Möglichkeit, die Tiefe der "Auflösung" zu begrenzen (value also nicht mehr weiter aufbröseln) ?


@Beta-User
Bzgl. devices steht bei mir autom. in der readingList:

Code: [Auswählen]

$DEVICETOPIC/bridge/devices:.* devices
Information steht lt. Doku ständig auf dem MQTT-Server bereit und wird beim MQTT-Anmelden bzw. bei jeder Änderung von Gerätedefinitionen veröffentlicht

Code: [Auswählen]

$DEVICETOPIC/bridge/devices [{"definition":null,"endpoints":{"1":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"10":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"11":{"bindings":[],"clusters":{"input":["ssIasAce"],"output":["ssIasZone","ssIasWd"]},"configured_reportings":[],"scenes":[]},"110":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"12":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"13":{"bindings":[],"clusters":{"input":["genOta"],"output":[]},"configured_reportings":[],"scenes":[]},"2":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"242":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"3":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"4":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"47":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"5":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"6":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]},"8":{"bindings":[],"clusters":{"input":[],"output":[]},"configured_reportings":[],"scenes":[]}},"friendly_name":"Coordinator","ieee_address":"0x00124b0025e70bd8","interview_completed":true,"interviewing":false,"network_address":0,"supported":false,"type":"Coordinator"},{"date_code":"20190219","definition":{"description":"Hue motion sensor","exposes":[{"access":1,"description":"Measured temperature value","name":"temperature","property":"temperature","type":"numeric","unit":"°C"},{"access":1,"description":"Indicates whether the device detected occupancy","name":"occupancy","property":"occupancy","type":"binary","value_off":false,"value_on":true},{"access":1,"description":"Remaining battery in %","name":"battery","property":"battery","type":"numeric","unit":"%","value_max":100,"value_min":0},{"access":1,"description":"Measured illuminance in lux","name":"illuminance_lux","property":"illuminance_lux","type":"numeric","unit":"lx"},{"access":1,"description":"Raw measured illuminance","name":"illuminance","property":"illuminance","type":"numeric"},{"access":7,"name":"motion_sensitivity","property":"motion_sensitivity","type":"enum","values":["low","medium","high"]},{"access":7,"description":"Blink green LED on motion detection","name":"led_indication","property":"led_indication","type":"binary","value_off":false,"value_on":true},{"access":7,"name":"occupancy_timeout","property":"occupancy_timeout","type":"numeric","unit":"second","value_max":65535,"value_min":0},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"9290012607","options":[{"access":2,"description":"Number of digits after decimal point for temperature, takes into effect on next report of device.","name":"temperature_precision","property":"temperature_precision","type":"numeric","value_max":3,"value_min":0},{"access":2,"description":"Calibrates the temperature value (absolute offset), takes into effect on next report of device.","name":"temperature_calibration","property":"temperature_calibration","type":"numeric"},{"access":2,"description":"Number of digits after decimal point for illuminance, takes into effect on next report of device.","name":"illuminance_precision","property":"illuminance_precision","type":"numeric","value_max":3,"value_min":0},{"access":2,"description":"Calibrates the illuminance value (percentual offset), takes into effect on next report of device.","name":"illuminance_calibration","property":"illuminance_calibration","type":"numeric"},{"access":2,"description":"Number of digits after decimal point for illuminance_lux, takes into effect on next report of device.","name":"illuminance_lux_precision","property":"illuminance_lux_precision","type":"numeric","value_max":3,"value_min":0},{"access":2,"description":"Calibrates the illuminance_lux value (percentual offset), takes into effect on next report of device.","name":"illuminance_lux_calibration","property":"illuminance_lux_calibration","type":"numeric"}],"supports_ota":true,"vendor":"Philips"},"endpoints":{"1":{"bindings":[],"clusters":{"input":["genBasic"],"output":["genBasic","genIdentify","genGroups","genOnOff","genLevelCtrl","lightingColorCtrl","genScenes"]},"configured_reportings":[],"scenes":[]},"2":{"bindings":[{"cluster":"genPowerCfg","target":{"endpoint":1,"ieee_address":"0x00124b0025e70bd8","type":"endpoint"}},{"cluster":"msIlluminanceMeasurement","target":{"endpoint":1,"ieee_address":"0x00124b0025e70bd8","type":"endpoint"}},{"cluster":"msTemperatureMeasurement","target":{"endpoint":1,"ieee_address":"0x00124b0025e70bd8","type":"endpoint"}},{"cluster":"msOccupancySensing","target":{"endpoint":1,"ieee_address":"0x00124b0025e70bd8","type":"endpoint"}}],"clusters":{"input":["genBasic","genPowerCfg","genIdentify","msOccupancySensing","msIlluminanceMeasurement","msTemperatureMeasurement"],"output":["genOta"]},"configured_reportings":[{"attribute":"batteryPercentageRemaining","cluster":"genPowerCfg","maximum_report_interval":62000,"minimum_report_interval":3600,"reportable_change":0},{"attribute":"occupancy","cluster":"msOccupancySensing","maximum_report_interval":3600,"minimum_report_interval":0,"reportable_change":0},{"attribute":"measuredValue","cluster":"msTemperatureMeasurement","maximum_report_interval":3600,"minimum_report_interval":10,"reportable_change":100},{"attribute":"measuredValue","cluster":"msIlluminanceMeasurement","maximum_report_interval":3600,"minimum_report_interval":10,"reportable_change":5}],"scenes":[]}},"friendly_name":"motionSensor2","ieee_address":"0x0017880103abf482","interview_completed":true,"interviewing":false,"manufacturer":"Philips","model_id":"SML001","network_address":6923,"power_source":"Battery","software_build_id":"6.1.1.27575","supported":true,"type":"EndDevice"}]


[Beta-User]

...demnach sollte man unterschiedlich vorgehen können, wenn 
- nicht ok => nichts machen;
- wenn raw => der code lt. aktuellem attrTemplate
- wenn graphviz => die Bereinigungslogik
- sonst: "Ersatzreading"
Fisch geputzt?

Solche Konstruktionen gibt es schon ein paar, das könnte schon klappen, sprengt halt aber fast den Rahmen "des Üblichen".