Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[akr1983]

@akr1983:
kannst du bitte noch fuer RGB Input und gewuenschtes Output beschreiben?
Und ich meine devStateIcon255 laesst sich auch etwas kompakter schreiben:

Code Auswählen Erweitern

sub
devStateIcon255($)
{
  my ($name) = @_;
  return ".*:off:toggle" if(lc(ReadingsVal($name,"state","ON")) eq "off" );
  my $pct = ReadingsVal($name,"brightness","255");
  my $s = $pct > 253 ? "on" : sprintf("dim%02d%%",int((1+int($pct/18))*6.25));
  return ".*:$s:off";
}Kannst du das bitte testen?


Edit: bugfix, dim% hinzugefuegt.

Also Code ist getestet und funktioniert!

Ich weiß allerdings nicht, was du mit gewünschten Input und Output meinst... Meinst du, wie die json Payload aussehen sollte?

Lg

[Ralf W.]

Hallo,

hier noch ein Beispiel für OSRAM SMART+ Plug:

Code Auswählen Erweitern

defmod Osram_Plug MQTT2_DEVICE
attr Osram_Plug IODev SE_MQTT2_SERVER
attr Osram_Plug event-on-change-reading .*
attr Osram_Plug eventMap { dev=>{ON=>'on',OFF=>'off'} }
attr Osram_Plug readingList zigbee2mqtt/0x84182600000ec127:.* { json2nameValue($EVENT) }
attr Osram_Plug room MQTT2_DEVICE
attr Osram_Plug setList off zigbee2mqtt/0x84182600000ec127/set OFF\
on zigbee2mqtt/0x84182600000ec127/set ON

MfG
Ralf

EDIT:
Das ist noch Murks. Liefert beim schalten zwei Events. Zu dem Problem habe ich hier vor einigen Tagen etwas gelesen. Schaue ich mir nächste Woche an ...

[schneckchen4711]

Code Auswählen Erweitern


attr Osram_Plug readingList zigbee2mqtt/0x84182600000ec127:.* { json2nameValue($EVENT) }

[...]
Das ist noch Murks. Liefert beim schalten zwei Events.
[...]

Guten Abend,

ich experimentiere auch noch mit dem Osram Stecker. Das Problem ist aus meiner Sicht, dass ReadingList bei dem MQTT Befehl ...0x84182600000ec127/set ausgeführt wird und bei der Rückmeldung des Steckers noch einmal. Hat auch den Nachteil, dass sich der Status beim Schalten ändert, ohne dass das Gerät eingesteckt ist. Bisher bin ich gescheitert das /set in der ReadingList zu filtern.

Viele Grüße,

  Georg

[Beta-User]

So, jetzt wollte ich mal das Wiki auf den aktuellen Stand bringen, hat sich ja einiges geändert seit den Anfangstagen .

Also FHEM aktualisiert (Stand aller Module also 01.12.).

Jetzt bin ich aber über ein paar Dinge gestolpert, die mir klärungsbedürftig erscheinen bzw. eventuell noch nicht optimal sind. Daher erst mal dieser write-up hier .

Was habe ich gemacht bzw. zum Umfeld:

- Traffic wurde mit mosquitto_sub mitgelesen (mosquitto_sub -d -h <server-hostname> -t zigbee2mqtt/#)
- die configuration.yaml ist unverändert, insbesondere ist/war eine clientID vergeben
- alle zigbee2mqtt-Devices erst versucht zu entpairen (das scheint nicht so einfach zu sein, die haben sich direkt neu gepairt und sind direkt wieder in der zigbee2mqtt-Liste aufgetaucht...), dann gelöscht
- MQTT2_SERVER gelöscht und neu definiert, auf autocreate gestellt und mal die Lampen "neu gestartet" (also ans Stromnetz angeschlossen) => da kommt zwar jeweils "received PUBLISH (d0, q0, r0, m0, 'zigbee2mqtt/bridge/log', ... (46 bytes)) {"type":"pairing","message":"device incoming"}", aber es wird kein MQTT2_DEVICE angelegt.
- save ausgeführt und dann mal FHEM und den zigbee_pi (der Dienst läuft auf einem anderen Rechner) neu gestartet. Ich sehe, dass am MQTT2-Server ein "state"-"online" ankommt (RETAIN{"ir_blaster/status":"true","zigbee2mqtt/bridge/state":"online"}), aber sonst passiert nichts. Dann habe ich mal die device-Liste mit dem publish-Command aus dem MQTT2-Server angefordert. Die Rückmeldung kommt, aber weder ein MQTT2-DEVICE wird angelegt noch ist in MQTT2-SERVER was zu sehen? Mag FHEM evtl. keine eckigen Klammern? Payload: {"type":"devices","message":[{"ieeeAddr":"0x90fd9ffffe65db16","type":"Router","model":"LED1650R5","friendly_name":"0x90fd9ffffe65db16"},{"ieeeAddr":"0x90fd9ffffe0bcd51","type":"Router","model":"LED1650R5","friendly_name":"0x90fd9ffffe0bcd51"}]})
- publish am MQTT2-SERVER genutzt, um die Lampe auszuschalten => MQTT2-DEVICE wird endlich angelegt....
Leider habe ich auch wiederholtes Neuanlegen des zugehörigen fileLog-Devices (?!? eigentlich ist mir hier eines schon zu viel...)
- Das Bridge-attrTemplate angewendet und die mittlere Angabe modifiziert (spontan: könnte man nicht gleich ein Textfeld vorsehen, in dem die zu ändernde Angabe eingegeben werden kann?)

Bis dahin also irgendwie nicht vollständig befriedigend. Wunschliste:
- STATE sollte aus zigbee2mqtt/bridge/state kommen (beim mit dem template zur Bridge deklarierten Device)
- die Readings sind unvollständig, wenigstens die Rückmeldung zu deviceList sollte ankommen (dann muß man nicht auf die Konsole mit  mosquitto_sub, wenn man einen publish-Befehl zusammenstricken muß.)
- fileLog ständig neu zu definieren, ist unnötig (optimal: wenn gelöscht, dann gelöscht!)

Jetzt mache ich mich mal an die eigentlichen Lampen, da kommt bestimmt noch was dazu...

Wie gesagt, das kann teilweise auch damit zusammenhängen, dass alles mal vorhanden war.

Gruß, Beta-User

[Beta-User]

So, jetzt habe ich also auch die eigentlichen Bulb-Devices hinbekommen.

Das erste war dann automatisch angelegt, nachdem ich wieder den passenden ON-Befehl gepublished hatte. Wieder das passende template angewendet. Sehr gut...

Unschön ist dann aber der Prefix für die Readings, der aus dem { json2nameValue($EVENT, xxx) } kommt, da ging erst mal die Anzeige für brightness nicht richtig. Das also rausgelöscht und nur noch { json2nameValue($EVENT) } dastehen lassen, dann paßt das.

Nächstes angelegt (wieder mit dem publish => autocreate). Gleich nach dem Anwenden des template das json2Value geändert => slider bleibt immer auch "0"...
Also erst das reading anlegen mit "setreading <bulbname> brightness 100", dann geht auch das.

Einfacher, aber auch m.E. nicht komplett selbsterklärend...
Hier sollte das template m.E. den json2nameValue gleich nicht so beschränken und das reading für brightness (bzw. für farbige Lampen dann auch die anderen) angelegt werden; von der Lampe kommt da nämlich scheinbar nichts zurück außer "on" bzw. "off"...).

Gruß, Beta-User

[Omega]

hier noch ein Beispiel für OSRAM SMART+ Plug:

Ich habe keine 2 Events beim Schalten.
Meine Definition:

Code Auswählen Erweitern

defmod mq2.osramPlug.01 MQTT2_DEVICE zigbee_0x7cb03eaa00ae6f09
attr mq2.osramPlug.01 IODev MQTT2_FHEM_Server
attr mq2.osramPlug.01 devStateIcon devStateIcon OFF:FS20.off:on ON:FS20.on:off
attr mq2.osramPlug.01 icon message_socket
attr mq2.osramPlug.01 readingList zigbee2mqtt/0x7cb03eaa00ae6f09:.* { json2nameValue($EVENT) }
attr mq2.osramPlug.01 room MQTT
attr mq2.osramPlug.01 setList on zigbee2mqtt/0x7cb03eaa00ae6f09/set {"state":"ON"}\
off zigbee2mqtt/0x7cb03eaa00ae6f09/set {"state":"OFF"}

Kann man bei den Osram Plugs eigentlich das Verhalten nach Stromausfall einstellen wie bei Tasmota?

LG
Holger

[Papaloewe]

Jetzt brauche ich doch noch eure Unterstützung:
Im meinem generellen MQTT2_DEVICE enpfange ich die log-Readings von meinen zwei Zigbee Devices:

Code Auswählen Erweitern

define MQTT2_zigbee_fhem MQTT2_DEVICE zigbee_fheD
attr MQTT2_zigbee_fhem IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_fhem comment 0x0017880100111162 "Philips_Hue_Iris" \
0x84182600000679de "OSRAM_LIGHTIFY_W23"
attr MQTT2_zigbee_fhem readingList zigbee_fhem:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT, 'log_') }
attr MQTT2_zigbee_fhem room MQTT2_DEVICE,ZigBee
attr MQTT2_zigbee_fhem setList permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1\
remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1\
log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1\
rename:textField zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
network_map:raw,graphviz zigbee2mqtt/bridge/networkmap $EVTPART1\
devicelist:noArg zigbee2mqtt/bridge/config/devices
attr MQTT2_zigbee_fhem verbose 3

setstate MQTT2_zigbee_fhem devicelist
setstate MQTT2_zigbee_fhem 2018-12-02 10:45:10 log_message device incoming
setstate MQTT2_zigbee_fhem 2018-12-02 10:42:47 log_message_1_friendly_name 0x0017880100111162
setstate MQTT2_zigbee_fhem 2018-12-02 10:42:47 log_message_1_ieeeAddr 0x0017880100111162
setstate MQTT2_zigbee_fhem 2018-12-02 10:42:47 log_message_1_model 7199960PH
setstate MQTT2_zigbee_fhem 2018-12-02 10:42:47 log_message_1_type Router
setstate MQTT2_zigbee_fhem 2018-12-02 10:42:47 log_message_2_friendly_name 0x84182600000679de
setstate MQTT2_zigbee_fhem 2018-12-02 10:42:47 log_message_2_ieeeAddr 0x84182600000679de
setstate MQTT2_zigbee_fhem 2018-12-02 10:42:47 log_message_2_model 4052899926158
setstate MQTT2_zigbee_fhem 2018-12-02 10:42:47 log_message_2_type Router
setstate MQTT2_zigbee_fhem 2018-12-02 10:45:10 log_type pairing
setstate MQTT2_zigbee_fhem 2018-12-02 10:42:47 state devicelist

Jetzt frage ich mich, wo kann ich nachschauen, welche json-Strings meine beiden Geräte zum Ansteuern benötigen, bzw. akzeptieren?
Ich habe diese im Einsatz:

Code Auswählen Erweitern

zigbee2mqtt:info
2018-12-1 15:43:57 0x0017880100111162 (0x0017880100111162): 7199960PH - Philips Hue Iris (Router)
zigbee2mqtt:info
2018-12-1 15:43:57 0x84182600000679de (0x84182600000679de): 4052899926158 - OSRAM LIGHTIFY Surface Light TW (Router)


Dann habe ich mal versucht ein paar Befehle über den MQTT2-Server zu senden, z.b.:

Code Auswählen Erweitern

zigbee2mqtt/0x0017880100111162/set {"state":"off"}

und erhalte auf der Konsole, wo die zigbee2mqtt-Intsanz läuft diese Ausgabe:

Code Auswählen Erweitern

zigbee2mqtt:error 2018-12-2 10:53:04 Zigbee publish to '0x0017880100111162', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error
Error: AF data request fails, status code: 233. MAC no ack.

Der Abstand zwischen Stick und Gerät ist unter einem Meter.
Hat jemand eine Idee?

Danke & Gruß
Thomas

[rudolfkoenig]

Achtung, hier sind Antworten auf Fragen aus vier Beitraegen.

https://forum.fhem.de/index.php/topic,91394.150.html

Habs eingefuegt, unter dem Namen zigbee2mqtt_smart+plug

Das ist noch Murks. Liefert beim schalten zwei Events.

Ja, weil eventMap "zu einfach" ist, siehe z.Bsp. den aktuellen Eintrag fuer tasmota_basic.
Achtung: json2nameValue in readingList wird seit neuerem mit zwei Parameter generiert (Daten und Praefix), damit bei Geraeten mit mehreren Schaltern/Sensoren die Readings nicht ueberschrieben werden. Ich kann versuchen ein eventMap zu bauen, falls ich ein "attr verbose 5" Log der IODevice bekomme. Testen kann ich es aber nicht.

Traffic wurde mit mosquitto_sub mitgelesen (mosquitto_sub -d -h <server-hostname> -t zigbee2mqtt/#)

Sehr loeblich, ich vermisse aber die Logs

...aber es wird kein MQTT2_DEVICE angelegt.

Stimmt, Bug: es wird per autocreate kein neues Geraet angelegt, wenn man das Alte geloescht hat, und FHEM nicht neugestartet hat.
Habs gefixt. Workaround: FHEM neu starten.

Dann habe ich mal die device-Liste mit dem publish-Command aus dem MQTT2-Server angefordert.

Das habe ich nicht verstanden, vmtl. weil ich zigbee2mqtt nicht kenne.

Leider habe ich auch wiederholtes Neuanlegen des zugehörigen fileLog-Devices (?!? eigentlich ist mir hier eines schon zu viel...)

Dann entferne doch das filelog Attribut bei autocreate.
autocreate legt das FileLog nur beim Anlegen des eigentlichen Geraetes an.

Das Bridge-attrTemplate angewendet und die mittlere Angabe modifiziert (spontan: könnte man nicht gleich ein Textfeld vorsehen, in dem die zu ändernde Angabe eingegeben werden kann?)

Du hast doch schon ein Textfeld im Dialog, wo du die Angabe aendern kannst.
Potentiell koennen beliebig viele Attribute definiert werden, und ich wollte den Code einfach halten.

STATE sollte aus zigbee2mqtt/bridge/state kommen (beim mit dem template zur Bridge deklarierten Device)

Gerne, aber mangels bridge kann ich kein stateFormat aus dem Aermel schuetteln, und bin auf euch angewiesen.
Entweder liefert ihr mir stateFormat, oder ein komplettes Protokoll.

die Readings sind unvollständig, wenigstens die Rückmeldung zu deviceList sollte ankommen

Meines Wissens legt MQTT2_DEVICE fuer alle empfangenen Meldungen ein Reading an.
S.o.: ich brauche Logs.

Unschön ist dann aber der Prefix für die Readings, der aus dem { json2nameValue($EVENT, xxx) } kommt, da ging erst mal die Anzeige für brightness nicht richtig. Das also rausgelöscht und nur noch { json2nameValue($EVENT) } dastehen lassen, dann paßt das.

Falsche Loesung, Praefix in json2nameValue bleibt, s.o.
Bitte zeig mir lieber, wie das Template dafuer geaendert werden muss, oder gib mir die Rohdaten, und was gesendet werden soll.

Jetzt frage ich mich, wo kann ich nachschauen, welche json-Strings meine beiden Geräte zum Ansteuern benötigen, bzw. akzeptieren?

Generell: in der Doku des angeschlossenen MQTT Geraetes (zigbee2mqtt?).
Evtl. hilft es ein attrTemplate zu setzen, und setList zu modifizieren.
Als Hinweis kann man die Subscription-Liste anschauen mit:

Code Auswählen Erweitern

fhem> list TYPE=MQTT2_SERVER subscriptions
m2s_192.168.178.33_27572     cmnd/DVES_581F3E/#=1543757724.23146 cmnd/sonoff/#=1543757724.18537 cmnd/sonoffs/#=1543757724.19269
m2s_192.168.178.96_53168     #=1543778497.1181

Da sind zwei Geraete verbunden:
Nr1 ist ein Tasmota, der hoert auf alles, was mit cmnd/DVES_581F3E/, cmnd/sonoff/ oder cmnd/sonoffs/ anfaengt.
Nr2 ist ein mosquitto_sub, der auf alles hoert (#).

Zu zigbee2mqtt Problemen kann ich nichts sagen.

[rudolfkoenig]

ReadingList bei dem MQTT Befehl ...0x84182600000ec127/set ausgeführt wird und bei der Rückmeldung des Steckers noch einmal.

Kannst du bitte dafuer Logs liefern? Am besten zusammen mit der "Raw definition" der Bridge.
Ist dein Geraet via MQTT2_SERVER oder MQTT2_CLIENT angebunden?

[Beta-User]

Sehr loeblich, ich vermisse aber die Logs

Ist dann halt komplett (Namen geändert und timouts und reconnects rausgeschmissen) angefügt.

Stimmt, Bug: es wird per autocreate kein neues Geraet angelegt, wenn man das Alte geloescht hat, und FHEM nicht neugestartet hat.

Danke, Test folgt.

"Dann habe ich mal die device-Liste mit dem publish-Command aus dem MQTT2-Server angefordert. "
Das habe ich nicht verstanden, vmtl. weil ich zigbee2mqtt nicht kenne.

Sorry, dachte das sei mit der im template hinterlegten setList und der angegebenen Reaktion von zigbee2mqtt ausreichend erläutert.

Kurzfassung des Problems: Egal, was vom zigbee2mqtt-Dienst kommt, es wird mit gesetztem brigdeRegexp _nur noch das_ verarbeitet, was zum Attribut paßt, alles andere scheint verworfen zu werden. Das ist m.E. nicht so toll, weil man damit weder state-Meldungen noch sonst irgendwas an Infos am "Bridge-Device" mehr hat. Gerade dafür sollte es aber m.E. auch da sein...

lists des Servers und des Bridge-Devices sind beigefügt.

Dann entferne doch das filelog Attribut bei autocreate.autocreate legt das FileLog nur beim Anlegen des eigentlichen Geraetes an.

Das mit dem Attribut kann ich schon machen, ist aber keine Lösung des eigentlichen Problems, dass das FileLog-Gerät eben _mehrfach_ angelegt wird. Scheinbar erkennt die Funktion nicht, dass es eben schon ein Gerät gibt...
Anders gesagt: heute morgen war alles im "save"-Zustand. Dann habe ich beide Lampen geschaltet, es ercheint ein "rotes Fragezeichen" im Menü, geändert sind (zwei Einträge):

Code Auswählen Erweitern

  define FileLog_MQTT2_zigbee_pi FileLog ./log/MQ...Jetzt habe ich eben ein update gemacht, FHEM neu gestartet und direkt 5 dieser Meldungen beim roten Fragezeichen.

Du hast doch schon ein Textfeld im Dialog, wo du die Angabe aendern kannst.

...dachte eigentlich nicht, dass ich da in dem Dialogfeld was übersehen habe... Teste das nochmal...

Falsche Loesung, Praefix in json2nameValue bleibt, s.o.
Bitte zeig mir lieber, wie das Template dafuer geaendert werden muss, oder gib mir die Rohdaten, und was gesendet werden soll.

Generell der Hinweis: eine ID steht für jeweils eine Bulb (bei dem zigbee2mqtt-Dienst). Die haben alle nur einen on/off/brightness...-Wert. Bei dieser Art ist daher das Auftrennen in potentiell mehrere gleichnamige Readings m.E. nicht erforderlich. Alternativ müßte man sonst "vorne" in der setList auch die Readings entsprechend mit den Präfixen benennen, dann würde das auch wieder gehen (nehme ich an).

Zu state usw. melde ich mich gerne wieder, aber ich bräuchte erst mal die passenden readings (s.o.) .

Die lists (Stand vor dem update):

Code Auswählen Erweitern

Internals:
   CONNECTS   9
   DEF        1883 global
   FD         39
   NAME       MQTT2_FHEM_Server
   NR         395
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   READINGS:
     2018-12-01 15:21:01   RETAIN          {"ir_blaster/status":"true","zigbee2mqtt/bridge/state":"online"}
     2018-12-03 07:30:51   nrclients       4
     2018-12-01 15:19:33   state           Initialized
   clients:
     MQTT2_FHEM_Server_192.168.2.23_34062 1
     MQTT2_FHEM_Server_192.168.2.42_50050 1
     MQTT2_FHEM_Server_192.168.2.51_28944 1
     MQTT2_FHEM_Server_192.168.2.52_47246 1
   retain:
     ir_blaster/status:
       ts         1543673986.97655
       val        true
     zigbee2mqtt/bridge/state:
       ts         1543674061.36098
       val        online
Attributes:
   autocreate 1
   group      Interfaces
   icon       mqtt
   room       Steuerung

Code Auswählen Erweitern

Internals:
   CID        zigbee_fe65db16
   DEF        zigbee_fe65db16
   DEVICETOPIC MQTT2_zigbee_pi
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 1
   MQTT2_FHEM_Server_TIME 2018-12-01 15:21:01
   MSGCNT     1
   NAME       MQTT2_zigbee_pi
   NR         396
   STATE      devicelist
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
Attributes:
   IODev      MQTT2_FHEM_Server
   bridgeRegexp zigbee2mqtt/0x90fd9ffff([^:]*):.* "zigbee_$1"
   icon       mqtt
   room       Steuerung
   setList    permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1
remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1
log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1
rename:textField zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}
network_map:raw,graphviz zigbee2mqtt/bridge/networkmap  $EVTPART1
devicelist:noArg zigbee2mqtt/bridge/config/devices

[Omega]

Nach einem "shutdown restart" habe ich derzeit immer folgende Meldungen im Log (mal nur einfach, manchmal auch mehrfach):

Code Auswählen Erweitern

2018.12.03 08:25:02 2: autocreate: define MQTT2_zigbee_bridge/log MQTT2_DEVICE zigbee_bridge/log
2018.12.03 08:25:02 1: ERROR: Invalid characters in name (not A-Za-z0-9._): MQTT2_zigbee_bridge/log

Ich habe in der fhem.cfg kein "MQTT2_zigbee_bridge" definiert und weiß momentan nicht, wo ich den Fehler suchen soll.

[OdfFhem]

Vermutlich (bzw. ziemlich sicher) ist der bridgeRegexp im MQTT2_DEVICE, das vom z.B. MQTT2_CLIENT angelegt wurde, fehlerhaft.

Mit aktiviertem autocreate wird versucht, das MQTT2_DEVICE MQTT2_zigbee_bridge/log anzulegen; korrekt müsste es aber MQTT2_zigbee_bridge lauten. Dieses MQTT2_DEVICE dient anschließend als "Bridge" zur zigbee2mqtt-Instanz und spiegelt dessen Zustand wider bzw. darüber kann man Verwaltungskommandos absetzen (s.a. https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Define_eines_MQTT2-Devices_als_.22Bridge.22).

[rudolfkoenig]

(OdfFhem war schneller, bzw. ich habe fuer die Antwort lange gebraucht)

Nach einem "shutdown restart" habe ich derzeit immer folgende Meldungen im Log (mal nur einfach, manchmal auch mehrfach):

Ich koennte bei solchen Raetseln Zeit sparen, wenn ich mehr Hinweise (vulgo "Raw definition"/list -r der betroffenen Geraete) kriegen wuerde.
Z.Zt. tippe ich auf ein bridgeRegexp der Sorte:

attr MQTT2_bridge bridgeRegexp (.*):.* "$1"

Ich finde so eine Befuellung zwar nicht sinnvoll, aber einen Fehler sollte es nicht verursachen.
=> Ich habe entsprechenden Code eingebaut, um dieses Problem zu verhindern. Es sei denn, ich habe falsch geraten.

Egal, was vom zigbee2mqtt-Dienst kommt, es wird mit gesetztem brigdeRegexp _nur noch das_ verarbeitet, was zum Attribut paßt, alles andere scheint verworfen zu werden

Das ist nicht mein Stand. Meines Wissens ist der Ablauf wie folgt:
- falls mindestens ein Geraet existiert, dessen readingList anwendbar ist, dann wird dessen/deren Reading gesetzt, und nicht weitergemacht.
- falls einer der Regexps aus einer der bridgeRegexps passt, dann wird das dazugehoerige Perl-Code evaluiert, und damit das alte CID ueberschrieben.
- falls CID gesetzt ist, aber noch kein Geraet mit diesem CID existiert, dann wird eine neues Geraet mit dem Namen MQTT2_CID angelegt.
Ich habe das gerade mit deiner bridge definition nachgestellt: ein zigbee2mqtt/0x90fd9ffffe65db16 Topic legt ein neues Geraet an, ein zigbee2mqtt/bridge/log Topic erweitert das MQTT2_zigbee_pi readingList.
Es ist mir dabei ein Problem aufgefallen: bei der Aenderung der bridgeRegexps wurden die alten Werte erst nach einem FHEM-Neustart "ungueltig", das habe ich jetzt gefixt.

lists des Servers und des Bridge-Devices sind beigefügt.

Bitte demnaechst list -r <devicename>/ "Raw definition".

Jetzt habe ich eben ein update gemacht, FHEM neu gestartet und direkt 5 dieser Meldungen beim roten Fragezeichen.

Kann ich leider weder nachstellen, noch laut Code vorstellen.
Ein FileLog wird nur zusammen mit dem MQTT2_DEVICE angelegt. Vermutlich uebersehe ich etwas.

Bei dieser Art ist daher das Auftrennen in potentiell mehrere gleichnamige Readings m.E. nicht erforderlich.

Ich habe das Topic aus deinem Log nachgespielt und verstehe jetzt das Problem,  weiss nur nicht, woran ich festmachen soll, dass man ein Praefix braucht oder nicht.
Ich habe jetzt ein Hack fuer zigbee2mqtt eingebaut: falls Praefix der Form 0xHEX ist, dann wird kein Praefix gesetzt. Falls jemand eine bessere Idee hat, bitte melden.

[OdfFhem]

"Problem" ist, dass bei der zigbee2mqtt-Instanz die MQTT-Informationen via Subtopics - relativ zum Topic bridge - ausgetauscht werden:

Code Auswählen Erweitern


zigbee2mqtt/bridge/state
zigbee2mqtt/bridge/log
zigbee2mqtt/bridge/config/permit_join
zigbee2mqtt/bridge/config/log_level
zigbee2mqtt/bridge/config/remove
zigbee2mqtt/bridge/config/rename
zigbee2mqtt/bridge/networkmap


Die MQTT-Informationen zu den eigentlichen Geräten haben keine direkten Subtopics, sondern sämtliche Informationen werden als JSON-Daten übermittelt:

Code Auswählen Erweitern


zigbee2mqtt/<DEVICE_ID>


Mit dem weit verbreiteten bridgeRegexp

Code Auswählen Erweitern


attr <mqtt2-device> bridgeRegexp zigbee2mqtt/([^:]*):.* "zigbee_$1"

führt dies dann u.a. zu folgenden MQTT2_DEVICE-Namen:

Code Auswählen Erweitern


bridge/state
bridge/log
bridge/config/permit_join
bridge/config/log_level
bridge/config/remove
bridge/config/rename
bridge/networkmap

<DEVICE_ID>


Nur Ergebnisse der letzten Art sind valide, alle anderen führen zum besagten Fehler aus Antwort #160.



Aus diesem Grunde verwende ich derzeit

Code Auswählen Erweitern


attr <mqtt2-device> bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"


Damit wird bridge bzw. <DEVICE_ID> als Ergebnis geliefert und das entsprechende MQTT2_DEVICE wird ohne Fehlermeldung angelegt.

[rudolfkoenig]

attr <mqtt2-device> bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"

Diese Version erzeugt ein weiteres Device fuer den Bridge, und dann jeweils eins fuer die Endgeraete.

Code Auswählen Erweitern

fhem> { "zigbee2mqtt/bridge/state:bla" =~ m,zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.*, ? "$1":"N" }
bridge
fhem> { "zigbee2mqtt/0x90fd9ffffe65db16:bla" =~ m,zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.*, ? "$1":"N" }
0x90fd9ffffe65db16



Mir ist die Version aus commandref sympatischer, da sie keine extre MQTT2_bridge Instanz erzeugt:

Code Auswählen Erweitern

attr zigbee2mqtt bridgeRegexp zigbee2mqtt/0x00158d0001([^:]*):.* "zigbee_$1"Ist leider nicht ganz generisch.

Folgendes sollte generischer sein, und auch weniger schreckliche Geraete erzeugen:

Code Auswählen Erweitern

fhem> attr zigbee2mqtt bridgeRegexp zigbee2mqtt/0x........([^/]+):.* "zigbee_$1"
fhem> { "zigbee2mqtt/bridge/state:bla" =~ m,zigbee2mqtt/0x........([^/]+):.*, ? "$1":"N" }
N
fhem> { "zigbee2mqtt/0x90fd9ffffe65db16:bla" =~ m,zigbee2mqtt/0x........([^/]+):.*, ? "$1":"N" }
fe65db16

Die erste Version mit extra bridge ist aber vermutlich besser, wenn man die Geraete per MQTT2_CLIENT/mosquitto angebunden hat.

Ich habe commandref angepasst, und den Vorschlag von OdfFhem uebernommen.