Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

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

Vorheriges Thema - Nächstes Thema

TomLee

isy, ich versteh es so das du einfach in der Bridge diese drei RL-Einträge ergänzt:

zigbee2mqtt/bridge/response/networkmap:.* { json2nameValue($EVENT) }
zigbee2mqtt/bridge/groups:.* { json2nameValue($EVENT) }
zigbee2mqtt/bridge/extensions:.* extensions


Das zigbee_bridge-Device kannst du löschen und sollte nicht mehr automatisch angelegt werden.



OdfFhem

@isy

Ich habe mir mal Deine angehängten Dateien angeschaut. Irgendwie fehlt mir noch Dein FHEM-Device MyMQTT - wäre gut, wenn Du dies auch noch einstellst. Wenn Du in der FHEM-Oberfläche auf der Detailseite von MyMQTT stehst, schau doch mal unter "Probably associated with", was dort aufgelistet wird ...


OdfFhem

@TomLee

Bei Dir bin noch ein wenig verwirrt:

MyMQTT ... MQTT2_zigbee_pi ... MQTT2_zigbee_bridge hängen auf den ersten Blick zusammen.
Aber wofür ist das FHEM-Device MQTT2_zigbee_Bridge ? (Ersatz für MQTT2_zigbee_bridge, ...)

Du solltest auch mal in der FHEM-Oberfläche auf der Detailseite von MyMQTT ermitteln, was unter "Probably associated with" aufgelistet wird ...

TomLee

Komm nicht ganz mit, die Definition dich ich gezeigt habe ist die "zweite" Definition der "Bridge" die isy angehängt hatte.
Die Frage :

ZitatDu solltest auch mal in der FHEM-Oberfläche auf der Detailseite von MyMQTT ermitteln, was unter "Probably associated with" aufgelistet wird ...

musst du isy stellen, ich frage mich aber mit welchem Device der MQTT2_Server jetzt in diesem Fall deiner Meinung nach "Probably associated with" sein soll.

Beta-User

Zitat von: TomLee am 06 Januar 2022, 17:10:26
isy, ich versteh es so das du einfach in der Bridge diese drei RL-Einträge ergänzt:

zigbee2mqtt/bridge/response/networkmap:.* { json2nameValue($EVENT) }
zigbee2mqtt/bridge/groups:.* { json2nameValue($EVENT) }
zigbee2mqtt/bridge/extensions:.* extensions


Das zigbee_bridge-Device kannst du löschen und sollte nicht mehr automatisch angelegt werden.
Sehe ich im Moment auch so.

Prinzipiell muss man halt immer mal wieder nachziehen, was sich so an Änderungen bei zigbee2mqtt ergeben hat.

Man könnte  vielleicht auch überlegen, einen (ReadingVal-basierten) setter zu generieren, mit dem man "unbekannte" Geräte schalten kann, damit das mit dem autocreate klappt.



Zu dem Leuchten-Thema noch (im "Anregungs"-Thread): Der ursprüngliche Satz beinhaltet evtl. keine Leuchte mit HUE-Setter. Das sollte man nachholen, die Farbwiedergabe von farbigen Leuchten kann sehr unterscheidlich - und auch "falsch" sein, wenn man rgb-Leuchten mit HUE "füttert" - und umgekehrt...

Bräuchte dazu aber die Endpunkte bei zigbee2mqtt und fände es besser, wenn sich das jemand ansieht, der die Dinger hat und in der Wirklichkeit spielen kann...
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

OdfFhem

@TomLee

Das ist dann wohl doch nicht ganz so leicht zu durchschauen.

Zitat von: TomLee am 06 Januar 2022, 16:08:06
Und ja, das zweite Bridge-Device ignorierte ich bis jetzt auch, aus diesem Grund hab ich mich jetzt auch gemeldet, evtl. können wir es ja klären warum und wieso.

Solltest Du an einer Lösung interessiert sein, wäre es gut, wenn Du Deine Definitionen vom MQTT-Server oder MQTT-Client sowie die beiden Bridge-Devices in einem Beitrag einstellst.

Zusätzlich wäre es gut, wenn Du auf der Detailseite von MQTT-Server oder MQTT-Client schaust, ob und was unter "Probably associated with" aufgelistet wird ...

TomLee

ZitatSolltest Du an einer Lösung interessiert sein, wäre es gut, wenn Du Deine Definitionen vom MQTT-Server oder MQTT-Client sowie die beiden Bridge-Devices in einem Beitrag einstellst.
Mein Bridge-Device hab ich in #487 gezeigt.

Meine MQTT2_SERVER Definition ist:

defmod MQTT2_Server MQTT2_SERVER 1883 global
attr MQTT2_Server room MQTT2_DEVICE


Bin ich selbst gerade erstaunt, weil nicht auf complex, wegen ebus.

"Probably associated with" ist der mit einem alten AT und global, daher komm ich nicht mit auf was du hinaus willst.

Das zusätzliche "Bridge"-Device welches bei mir automatisch erstellt wird (weil die Topics nicht in der Bridge definiert sind bzw. die Frage ist warum der info-Topic da nochmal auftaucht obwohl in der rL der Bridge schon vorhanden):

defmod MQTT2_zigbee_bridge MQTT2_DEVICE zigbee_bridge
attr MQTT2_zigbee_bridge readingList zigbee2mqtt/bridge/event:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/info:.* info
attr MQTT2_zigbee_bridge room MQTT2_DEVICE





OdfFhem

@TomLee

*** mein Testsystem ***
- [1.Ebene] FHEM-Device myMqttServer vom Typ MQTT2_SERVER. Auf dessen Detailseite sehe ich unter "Probably associated with" ein FHEM-Device namens MQTT2_myMqttServer vom Typ MQTT2_DEVICE.
- [2.Ebene] Das FHEM-Device MQTT2_myMqttServer wurde automatisch erstellt und dient bei mir als zentraler Verteiler. Im Grunde verfügt es nur über ein "einziges" Attribut namens bridgeRegexp. Auf der Detailseite steht unter "Probably associated with" das FHEM-Device myMqttServer.
- [3.Ebene] Hier liegen alle möglichen FHEM-Devices vom Typ MQTT2_DEVICE, die durch den bridgeRegexp der 2.Ebene angelegt wurden und auf deren Detailseite sieht man unter "Probably associated with" das FHEM-Device MQTT2_myMqttServer.

*** mein Produktivsystem ***
- [1.Ebene] FHEM-Device myMqttClient vom Typ MQTT2_CLIENT. Auf dessen Detailseite sehe ich unter "Probably associated with" ein FHEM-Device namens MQTT2_myMqttClient vom Typ MQTT2_DEVICE.
- [2.Ebene] FHEM-Device MQTT2_myMqttClient wurde automatisch erstellt und dient bei mir als zentraler Verteiler. Im Grunde verfügt es nur über ein "einziges" Attribut namens bridgeRegexp. Auf der Detailseite steht unter "Probably associated with" das FHEM-Device myMqttClient.
- [3.Ebene] Hier liegen alle möglichen FHEM-Devices vom Typ MQTT2_DEVICE, die durch den bridgeRegexp der 2.Ebene angelegt wurden und auf deren Detailseite sieht man unter "Probably associated with" das FHEM-Device MQTT2_myMqttClient.


Heisst zusammengefasst beim SERVER bzw. Client: 3.Ebene hängt (nur) von 2.Ebene ab; 2.Ebene hängt (nur) von 1.Ebene ab.


Ich vermute mal, dass Dein automatisch erzeugtes FHEM-Device die 2.Ebene repräsentieren könnte; mehr Auskunft dazu sollte man unter "Probably associated with" finden ...

TomLee

Sry, ist mir immer noch zu hoch auf was du aus bist.

Wenn ich auf einem Test-System einen MQTT2_Server definiere ist der "Probably associated with" mit global und fertig.

Da gibts kein MQTT2_<MQTT2_SERVERNAME> in der zweiten Ebene und mir stellt sich jetzt die Frage ob ich irgendwas verpasst habe das ich irgendwie ein zweites Device würde benötigen welches dieses bridgeRegexp-Attribut gesetzt hat, iVm. dem MQTT2_Server, was man benötigt mit MQTT2_CLIENT ist ein anderes Thema für mich ?

OdfFhem

@TomLee

Die beiden von mir beschriebenen Systeme sind so im Einsatz, einmal als MQTT2_SERVER und einmal als MQTT2_CLIENT - die Struktur sieht doch ziemlich "identisch" aus. Alle Geräte der 3.Ebene haben ein Reading namens associatedWith; das Gerät der 2.Ebene nicht, da schon die Pflege des bridgeRegexp-Attributes dazu führt, dass alle Readings gelöscht werden ... readingList sollte es (zumindest bei mir) in der 2.Ebene nur temporär geben, wenn ein völlig neues/unbekanntes "Haupttopic" auftaucht ... Anpassung des bridgeRegexp-Attributs sorgt rasch für Bereinigung und eigentlich gewünschtes Verhalten.

Du schreibst, dass Du auf einem Testsystem einen MQTT2_Server definiert hast ... hast Du anschließend auch Daten empfangen ... denn erst dann würde ich mit der 2.Ebene rechnen ...

Haben Deine Geräte vom Typ MQTT2_.* ein Attribut namens associatedWith ? Wenn ja, welchen Wert ?

list TYPE=MQTT2_.* TYPE associatedWith


TomLee

Nochmal, sry, es fuchst mich das ich nicht verstehe auf was du aus bist, vlt. bringt mir auch einmal drüber schlafen was.
Bin und bleib für Heute der Meinung das mein genannter event-Topic und die drei von isy gezeigten Topics einfach nur im Bridge Template ergänzt gehören und gut ist.

Es bleibt für mich nur die Frage, zum wiederholten mal jetzt, warum bei mir immer wieder das  MQTT2_zigbee_bridge-Devcie mit dem info-Topic erstellt wird, obwohl dieser Topic schon im Bridge-Device vorhanden ist.

isy

War den ganzen Abend erfolglos mit Bullseye beschäftigt.
Melde mich am Vormittag
Ein Weg wird erst zu einem Weg, wenn man ihn geht

TomLee

Zitat von: OdfFhem am 06 Januar 2022, 19:41:32
@TomLee

*** mein Testsystem ***
- [1.Ebene] FHEM-Device myMqttServer vom Typ MQTT2_SERVER. Auf dessen Detailseite sehe ich unter "Probably associated with" ein FHEM-Device namens MQTT2_myMqttServer vom Typ MQTT2_DEVICE.

Moin,

#499 ging gestern Abend irgendwie an mir vorbei, scheinbar hat mich doch jemand verstanden.

Aus Interesse, weil ich bei OdFhem immer noch nicht mitkomme auf was er aus ist, würd ich gerne mal ein List von diesem MQTT2_myMqttServer-Device sehen wollen.


isy

#508
Als erstes ein List von meinem (Testsystem) MyMQTT Server
Siehe Anlage.
Der ist mit nichts verbunden, "STATE=Initialized"

Der aktuell verbundene MyMQTT Server (Siehe Rudis Beitrag) ist im WEB auf "state=connected" (Kleinbuchstaben!), List hier:
   AuthenticatedBy allowed
   AuthenticatedUser XXXXXX
   BUF       
   FD         4
   NAME       MyMQTT_127.0.0.1_38008
   NR         22
   PEER       127.0.0.1
   PORT       38008
   SNAME      MyMQTT
   SSL       
   STATE      Connected
   TEMPORARY  1
   TYPE       MQTT2_SERVER
   WBCallback
   cflags     238
   cid        zigbee_pi
   keepalive  60
   lastMsgTime 1641547791.78555
   lwt        zigbee2mqtt/bridge/state:offline
   protoNum   4
   protoTxt   MQTT
   usr        is
   READINGS:
     2022-01-07 09:42:51   state           Connected
   subscriptions:
     zigbee2mqtt/# 1641544971.15986
Attributes:
   room       hidden


VG Helmut
Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

Zitat von: TomLee am 06 Januar 2022, 15:45:20

defmod MQTT2_zigbee_bridge MQTT2_DEVICE zigbee_bridge
attr MQTT2_zigbee_bridge readingList zigbee2mqtt/bridge/event:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/info:.* info
attr MQTT2_zigbee_bridge room MQTT2_DEVICE


Der Befehl geht bei mir nicht!
FM wrong syntax for MQTT2_zigbee_bridge: define <name> MQTT2_DEVICE [clientid]
Das gleiche funktionierte auch schon nicht mit dem Eintrag auf https://wiki.fhem.de/wiki/Zigbee2mqtt unter Define eines MQTT2-Devices als "Bridge"

Zeile define MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi funktionert
Zeile attr MQTT2_zigbee_pi IODev MyMQTT funktioniert

Zeile attr MQTT2_zigbee_pi readingList zigbee_pi:zigbee2mqtt/bridge/state:.* state\ bricht ab mit FM
MQTT2_zigbee_pi: bad reading name state\ zigbee_pi:zigbee2mqtt/0x90fd9ffffe65db16:.* { json2nameValue($EVENT, ) }\ zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT, ) }\ zigbee_pi:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT, 'log_') } (contains not A-Za-z/\d_\.- or is too long)

Liegt der ganze Fehler evtl. dort?

Beste Grüße, Helmut
Ein Weg wird erst zu einem Weg, wenn man ihn geht