Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[TomLee]

Bei @TomLee heisst es (vermutlich) MQTT2_zigbee_Bridge mit großem B, bei @isy heisst es lt. der angehängten Dateien MQTT2_zigbee_pi.

Oh man, ich hab eben erst verstanden, warum bei mir die zweiten Bridge-Devices angelegt werden 

Ich hab bei mir das Bridge-Device vor langer Zeit umbenannt in MQTT2_zigbee_Bridge (mit großem B), natürlich landen dann die Topics die nicht im Template enthalten in dem MQTT2_zigbee_bridge-Device.

...
Sollte man auf die Idee kommen, das "Einstiegsgerät" direkt MQTT2_zigbee_bridge zu nennen, könnte das der Beginn einer Endlosschleife sein oder vielleicht sogar die Lösung ...

Denke da ist jemand schon vor langer Zeit auf die Idee gekommen das Device so zu benennen und das ist bisher auch die Lösung/so umgesetzt, sry ab und an brauch ich etwas 

[TomLee]

Hi,

ich weiß nicht was der Auslöser dafür war, denke irgendetwas hab ich im GUI gemacht gehabt, und es kam bis jetzt nur einmal vor einem Monat vor.

Dieser Pfad müsste auch in der Bridge aufgenommen werden (und am besten gleich verworfen):

Code: [Auswählen]

zigbee2mqtt/bridge/response/networkmap:.* networkmap

[Beta-User]

Dieser Pfad müsste auch in der Bridge aufgenommen werden (und am besten gleich verworfen):

Der ist im aktuellen attrTemplate bereits drin, wenn mich nicht alles täuscht, allerdings mit einer speziellen Behandlung... Die (im Moment: graphviz-) Daten braucht man, wenn man die Karte zeichnen lassen will.

[TomLee]

Upps, sry, war irgendwie der Meinung das ich eine aktuelle Bridge habe, ist aber gar nicht so 

[TomLee]

Jeder sieht das wsl. wieder anders aber bei mir sind die zwei devices-Pfade und der info-Pfad "ausgeknipst" und ich hab/sehe keine Nachteile:

Code: [Auswählen]

$DEVICETOPIC/bridge/config/devices:.* {}
$DEVICETOPIC/bridge/devices:.* {}
$DEVICETOPIC/bridge/info:.* {}

[Beta-User]

Jeder sieht das wsl. wieder anders aber bei mir sind die zwei devices-Pfade und der info-Pfad "ausgeknipst" und ich hab/sehe keine Nachteile:

Code: [Auswählen]

$DEVICETOPIC/bridge/config/devices:.* {}
$DEVICETOPIC/bridge/devices:.* {}
$DEVICETOPIC/bridge/info:.* {}

Ich bitte (auch im Hinblick auf diesen Thread... https://forum.fhem.de/index.php/topic,126790.msg1213807.html#msg1213807) um weitere Rückmeldungen sowie um Info, ob der erste der drei Pfade aktuell überhaupt noch "beliefert" wird. (wenn nein, kann der raus).

Wie ist es mit den weiteren "bridge/config/"-Topics?

[TomLee]

Wenn ich einen restart von z2m mache kommt folgendes über diesen Pfad :

Code: [Auswählen]

2022-03-16 17:53:37 MQTT2_SERVER MQTT2_Server zigbee2mqtt/bridge/config:{"commit":"7a2ddf24","coordinator":{"meta":{"maintrel":0,"majorrel":38,"minorrel":88,"product":0,"revision":"0x26580700","transportrev":0},"type":"ConBee2/RaspBee2"},"log_level":"info","network":{"channel":11,"extendedPanID":"0xdddddddddddddddd","panID":6754},"permit_join":false,"version":"1.24.0"}
Wie man sieht kommen keine Devices mit, ich weiß aber nicht ob sie, durch was auch immer ausgelöst, doch irgendwann mitkommen.

Ich mag/kann das nicht beurteilen was man braucht und was nicht, für mich sind die Daten in meta nutzlos:

Code: [Auswählen]

setstate MQTT2_zigbee_bridge 2022-03-16 17:53:37 coordinator_meta_maintrel 0
setstate MQTT2_zigbee_bridge 2022-03-16 17:53:37 coordinator_meta_majorrel 38
setstate MQTT2_zigbee_bridge 2022-03-16 17:53:37 coordinator_meta_minorrel 88
setstate MQTT2_zigbee_bridge 2022-03-16 17:53:37 coordinator_meta_product 0
setstate MQTT2_zigbee_bridge 2022-03-16 17:53:37 coordinator_meta_revision 0x26580700
setstate MQTT2_zigbee_bridge 2022-03-16 17:53:37 coordinator_meta_transportrev 0

[TomLee]

Zum besseren Verständnis, auch wenn ich denke das du das gar nicht brauchst:
(ohne graphiz-Reading)

Code: [Auswählen]

setstate MQTT2_zigbee_bridge online\
Version: 1.24.0
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 commit 7a2ddf24
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 coordinator_meta_maintrel 0
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 coordinator_meta_majorrel 38
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 coordinator_meta_minorrel 88
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 coordinator_meta_product 0
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 coordinator_meta_revision 0x26580700
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 coordinator_meta_transportrev 0
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 coordinator_type ConBee2/RaspBee2
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 extensions []
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 groups []
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:15 log_level info
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:15 log_message MQTT publish: topic 'zigbee2mqtt/0x00158d000411c41c', payload '{"battery":100,"illuminance":7,"illuminance_lux":7,"occupancy":false,"temperature":25,"voltage":3005}'
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 network_channel 11
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 network_extendedPanID 0xdddddddddddddddd
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 network_panID 6754
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 permit_join false
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:11 state online
setstate MQTT2_zigbee_bridge 2022-03-16 18:10:13 version 1.24.0

[OdfFhem]

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

[Beta-User]

@OdfFhem: Das hatte ich insoweit berücksichtigt, als das attrTemplate das aktuell ja so macht.

@TomLee: nur "meta" rauszufischen macht m.E. keinen so großen Unterschied, als dass man sich den Aufwand machen müßte. Sieht aber so aus, als wären die "alten" Topics auf dem einen vereint und der Rest "kann weg".

Klingt danach, als müßte "jemand" entscheiden, wie das im Detail jetzt sein soll. Neige dazu, die "Großreadings" nur dann zu füllen, wenn der User das will; vermutlich ist es das einfachste, ein Reading auszulesen, mit dem der User das einschalten  kann => (setreading erforderlich, sonst wird das ignoriert).

Meinungen?

[TomLee]

Klingt danach, als müßte "jemand" entscheiden, wie das im Detail jetzt sein soll. Neige dazu, die "Großreadings" nur dann zu füllen, wenn der User das will; vermutlich ist es das einfachste, ein Reading auszulesen, mit dem der User das einschalten  kann => (setreading erforderlich, sonst wird das ignoriert).

Meinungen?

Noch keine Meinung, weil ich nicht ganz mitkomme, zeig halt mal die Entscheidung die dir vorschwebt, die ist doch eh schon vorbereitet, oder nicht !?.

[Beta-User]

die ist doch eh schon vorbereitet, oder nicht !?.

Nein. Bisher existiert nur eine Idee dazu, und die habe ich ja beschrieben...

[TomLee]

Alles gut, ich hab Zeit und lasse mich dann einfach von den Rückmeldungen anderer die deiner Beschreibung folgen konnten oder einem der folgenden nächsten updates des Template, erhellen.

[Beta-User]

Nachdem wir jüngst großes Interesse an kleingeschriebenen state-Readings hatten

Ich wäre dafür das du das bitte gleich, wenn mal Zeit ist, "vertemplatest".

Ist im svn, für Tests und Rückmeldung wäre ich dankbar, war nämlich zum Teil "ins Blaue" hinein.

Achtung: einige Attribute sind uU. nicht mehr nötig, da gab es früher einige eventMap und stateFormat-Varianten...