Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

Begonnen von supernova1963, 23 September 2018, 19:17:21

Vorheriges Thema - Nächstes Thema

TomLee

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

Zitat...
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  8)


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):

zigbee2mqtt/bridge/response/networkmap:.* networkmap

Beta-User

Zitat von: TomLee am 16 März 2022, 16:19:43
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.
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

TomLee

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

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:

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

Beta-User

Zitat von: TomLee am 16 März 2022, 17:32:38
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:

$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?
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

TomLee

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

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:

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)

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

Zitat von: OdfFhem am 19 Februar 2022, 10:30:12
@Beta-User
Bzgl. devices steht bei mir autom. in der readingList:

$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?
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

TomLee

ZitatKlingt 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

Zitat von: TomLee am 16 März 2022, 19:54:31
die ist doch eh schon vorbereitet, oder nicht !?.
Nein. Bisher existiert nur eine Idee dazu, und die habe ich ja beschrieben...
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

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
Zitat von: TomLee am 21 Juni 2022, 20:59:33
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...
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

SamNitro

Hey, leider funktioniert dieses Topic auch nicht:
$DEVICETOPIC:.* { my $ret=json2nameValue($EVENT); $ret->{state}=lc($ret->{state}) if defined $ret->{state}; return $ret }

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 }
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)