Zugriff auf externe zigbee2MQTT2 bzw MQTT2_device

[Beta-User]

Vielen Dank für die [...]

War auch von mir nicht böse gemeint .

Aber wie isses denn jetzt? Du machst es spannend. Ich meine einfach ein define für den Server. Das mit MQTT2_CLIENT macht es ja jetzt noch komplexer und dauert nochmal länger

Na ja, wenn man die Daten von zigbee2mqtt irgendwo anders her abholen will, braucht man eben einen Zugang zu dem MQTT-Server, an den die Daten geschickt werden - und das kann halt immer nur jeweils einer sein... Von daher ist es mit M2C zwar komplexer, aber wie sonst sollen die Daten vom M2S abgeholt werden (vom jeweils anderen FHEM)? (klar, 00_MQTT + eines der "alten" MQTT-Module ginge auch, aber das lassen wir jetzt besser mal außen vor...)

[Otto123]

Naja ich dachte erstmal dran das es überhaupt 1 zu 1 geht - rein protokollmäßig.
Ich hatte noch nicht verstanden, das es einen dauerhaften gemeinsamen Betrieb der gesamten Umgebung geben sollte. 2 x zigbee2mqtt und 2 x FHEM.
Wenn es prinzipiell funktioniert kann man ja die Kiste migrieren und gut. So einen 2 zu 2 Betrieb würde ich mir nicht unbedingt zumuten. Da verliert man schnell das eigentliche Ziel aus den Augen 

[flummy1978]

Moinsen,

oh man da muss ich ja einiges wieder gerade rücken ... ich sollte doch wieder mehr mit Smilies schreiben, da kommt Ironie und Spaß besser durch

nein -> verpeilt oder verpolt - beides kann man als Beleidigung verstehen. Wollte ich definitiv nicht. Manchmal wähle ich eben übertrieben Worte
Aber wie isses denn jetzt? Du machst es spannend. Ich meine einfach ein define für den Server. Das mit MQTT2_CLIENT macht es ja jetzt noch komplexer und dauert nochmal länger

Schön locker bleiben: WEDER hab ich das als Beleidigung aufgefasst, noch fühle ich mich durch sowas angegriffen. Ich bin Handwerker, arbeite in der Industerie UND komme aus dem Ruhrpott, wenn einer mit nem locker doofen Spruch aus der Hüfte klarkommt, dann sollte ich das sein Alles gut, hab da nichts böse aufgefasst. Du hilfst hier so vielen Menschen, da muss ein lustiger und netter Spruch eh mal drin sein.

Ehrlicherweise bin ich jetzt wirklich etwas verpeilt  Was meinst Du mit "Ich meine einfach ein define für den Server" ? Der Define für den Server den ich probiert habe, funktioniert(e) ja so nicht durch den externen Zugriff auf den Docker (wie rudolf ja gesagt hat, KANN es auch an der Abschottung und der Docker IP liegen). Deswegen werde ich wohl @Beta-Users Ansatz nehmen, weil es am einfachsten scheint, beide z2mqtt in Betrieb zu nehmen und dann nach und nach mit den Geräten einzeln umzuziehen.

@Beta-User

War auch von mir nicht böse gemeint

Siehe obere Erklärung habe ich überhaupt nicht so aufgefasst Ganz im Gegenteil. Ich bin bin MEGA -froh, dass ich hier so eine angeregte Unterhaltung habe und mir jemand bei meinem Problem helfen möchte. Ich war froh, dass Du dort eben kurz und präzise erwähnt hast was ich wo wie einbinden soll und welchen Vorteil das dann hat. Das wiederum ist eine perfekte Anweiseung (man könnte auch Anleitung / Hilfe etc) sagen... Deshalb danke dafür 


So nachdem alle Klarheiten beseitig sind, kann ich Euch auch sagen, dass ich erst heute Nacht dazu kommen werde, wieder n bisschen daran zu basteln und zu testen

Ich hatte noch nicht verstanden, das es einen dauerhaften gemeinsamen Betrieb der gesamten Umgebung geben sollte. 2 x zigbee2mqtt und 2 x FHEM.
Wenn es prinzipiell funktioniert kann man ja die Kiste migrieren und gut. So einen 2 zu 2 Betrieb würde ich mir nicht unbedingt zumuten. Da verliert man schnell das eigentliche Ziel aus den Augen 

Deswegen ja weiter oben die Auflistung. Vielleicht hattest Du da ja was übersehen

Um das Ganze  in der Übersicht besser stehen zu lassen noch mal die aktuelle Situation :
Oben gelistete Systeme -> Auf dem Raspi laufen auch ein paar Homematik und Tasmota Geräte. Altes System mit vielen Altlasten
und mein Wunsch:
Ich würde gern (langsam der Reihe nach) vom Raspi auf den Docker umziehen. Im Raspi-Zigbee sind aber viele Geräte die durchgehend und auch nach dem Umzug weiterhin erreichbar bleiben sollten. Ein erneutes Anlernen an (neuem) Zigbe2MQTT würde ich gern vermeiden (weil es eben doch ein "paar" sind)
Das Haus ist relativ verstreut und auch repeater kommen an ihre Grenzen. Abgesehen davon komme ich auch Gerätetechnisch langsam an die Grenzen komme, weil es wie gesagt viele sind.
Das neue System etwas aufteilen (damit nicht bei Ausfall eines Teils alles weg ist)
Zugriff auf externe Geräte lernen (Ser2Net oder MQTT GENERIC BRIDGE hab ich genauso schon mal gelesen wie Fhem2Fhem ... aber was macht wo am meisten Sinn?

Beim Umziehen möchte ich natürlich eben noch mehr (korrektes) Wissen aneignen, weil ich glaube dass das System vom Ursprung her zwar läuft, aber sicher nicht 1000%ig korrekt angelegt wurde.

Vielen Dank für Eure Hilfe bis hierher schon
VG
Andreas

[Beta-User]

Danke für die Rückmeldung.

Vielleicht noch eine Anmerkung zu dem hier:

Wenn es prinzipiell funktioniert kann man ja die Kiste migrieren und gut. So einen 2 zu 2 Betrieb würde ich mir nicht unbedingt zumuten. Da verliert man schnell das eigentliche Ziel aus den Augen 

Otto hat völlig recht, auch ich würde versuchen, direkt möglichst mit allem (!) umzuziehen und finde die "nach und nach"-Lösung eher schwierig. Vielleicht machst du dir erst mal ein "Abhängigkeitsbild" (https://forum.fhem.de/index.php/topic,114960.msg1125012.html#msg1125012), damit du einen Überblick bekommst, wie eigentlich die wechselseitigen Abhängigkeiten vieler Definitionen voneinander sind...

Falls es "nur" darum geht, erst mal zigbee2mqtt "verdockert" ans Laufen zu bekommen (und das Haupt-FHEM "komplett" zu belassen), würde ich das nach dem ersten Testen direkt so machen, dass ich den "Hauptstick" samt backup von zigbee2mqtt auf die docker-Umgebung umziehen würde und dann direkt ALLE zigbee2mqtt-Geräte auf dem "alten" System nur noch via M2C holen würde. Erfordert kein langwieriges Umlernen und Verteilen der bisherigen Logiken und müßte stressfrei innerhalb überschaubarer Frist laufen...

[Otto123]

Ergänzend zu Beta-Users Zusammenfassung meine Fragen - bitte einfach mit ja oder nein (ich versuche immer noch das Problem aus #1 zu verstehen) antworten:
Wenn Du von Zigbee2mqtt redest, meinst Du Dein MQTT2_Device in FHEM?
Sowohl das Live System und das Docker System, bestehend jeweils aus: FHEM (MQTT2_SERVER, MQTT2_DEVICE "Zigbee2mqtt") und dem zigbee Stick mit dem zigbee2mqtt Dienst, funktioniert jeweils in sich?

[flummy1978]

Mhmm da habt ihr wohl beide nicht unrecht. Mit einem Schlag umziehen hätte den Vorteil, dass ein "nicht funktionieren" auf dem Docker, wohl einfacher rückgängig zu machen wäre, als ein Teilumzug *grübel* .... das muss ich mir (nach den Tests) noch mal in Ruhe durch den Kopf gehen lassen.

Wenn Du von Zigbee2mqtt redest, meinst Du Dein MQTT2_Device in FHEM?
Sowohl das Live System und das Docker System, bestehend jeweils aus: FHEM (MQTT2_SERVER, MQTT2_DEVICE "Zigbee2mqtt") und dem zigbee Stick mit dem zigbee2mqtt Dienst, funktioniert jeweils in sich?

Wenn ich von Zigbee2mqtt rede, dann meine ich damit auch die Umgebung die hier beschrieben ist und entsprechend aufgebaut ist: https://www.zigbee2mqtt.io/

D.h. ja, wie ich schon mehrmals gesagt habe:

DASS es funktioniert hat @Beta-User ja korrekt erkannt, weil die Kommunikation von Docker-FHEM zu Docker-Zigbee genauso funktioniert wie von Raspi-Fhem zu Raspi-Zigbee.
Raspi-Fhem mit Zugriff auf Docker-Zigbee ist genauso das Problem wie Docker-Fhem auf Raspi-Zigbee (was ich gern hätte)

Also funktioniert jedes System für sich bereits.

Nochmal eine Frage bezüglich MQTT2_Client
Hab das jetzt mal auf die Schnelle auf beiden System eingebunden und getestet und es scheint einfacher zu sein, als gedacht bzw ich hab irgendwo vorher n Denkfehler gemacht. Die Testrichtung Docker ==> Raspi funktioniert, die Signale werden durch gegeben, aber erst nach manuellem Anlegen der readingList. Autocreate funktioniert auf beiden Systemen nicht. Es wird in beiden FHEMs jeweils kein Gerät angelegt auch wenn die Daten aus dem jeweiligen M2C kommen. (Wenn ich neue Geräte Manuell über das Zigbee2Mqtt anlege, wird normal ein Gerät angelegt) sprich:
Der Kontakt ist am Docker angelernt, schickt die Infos an RaspberryPi am Raspberry kommt aber nichts an, solange ich das attr readingList nicht um den entsprechenden Zigbeeeintrag aus dem Docker erweitere. (Ich hab zum Testen erstmal Dinge genommen, die am Hauptfhem angelernt waren, ich aber dort aktuell nicht dringend benötige) .... hat jemand nen Tipp wo ich da genauer nachschauen muss?
Raspilist:
readingList zigbee2mqtt/TK_OG_GZ_fenster:.* { json2nameValue($EVENT) } <<<<<<<<<======= Originaleintrag
zigbee2mqtt/0x00158d0002d72f41:.* { json2nameValue($EVENT) }             <<<<<<<<<<<<<<< Hinzugefügter Eintrag aus dem Docker (damit funktioniert dann auch das Schalten vom Docker -> M2C -> Raspi Fhem)

(Auf dem Docker wird auch kein Gerät angelegt (was bei der Menge der Geräte wohl auch erst mal besser so ist  ))

List:

Code Auswählen Erweitern

Internals:
   .attreocr-thresholdlinkquality 36
   CID        zigbee_TK_OG_GZ_fenster
   DEF        zigbee_TK_OG_GZ_fenster
   DEVICETOPIC TK_OG_GZ_fenster
   FUUID      5fabbb8d-f33f-6adc-2f4b-7e000c8afd75a9c3
   IODev      brok_MQTT2
   LASTInputDev MQTT2Client_docker
   MQTT2Client_docker_MSGCNT 9
   MQTT2Client_docker_TIME 2021-05-20 11:41:19
   MSGCNT     10
   NAME       TK_OG_GZ_fenster
   NR         288
   STATE      <pre>
open
</pre>
   TYPE       MQTT2_DEVICE
   brok_MQTT2_MSGCNT 1
   brok_MQTT2_TIME 2021-05-16 12:17:02
   .attraggr:
   .attreocr:
     state
     contact
     linkquality:10
   .attreour:
     state
   .attrminint:
   .userReadings:
     HASH(0x4a4a400)
   READINGS:
     2021-05-03 13:19:44   IODev           brok_MQTT2
     2020-11-11 11:23:09   associatedWith  dev_SYS_zigbee_bridge
     2021-05-20 11:41:19   battery         100
     2021-05-20 11:41:19   contact         false
     2020-11-11 11:28:19   delay           5
     2021-05-20 11:41:19   linkquality     39
     2021-05-20 11:41:24   state           open
     2021-05-20 11:41:24   timestamp       1621503684.54455
     2021-05-20 11:41:19   voltage         3025
Attributes:
   DbLogExclude .*
   IODev      brok_MQTT2
   TIMER_announce 7200
   TIMER_announcemsg Gästezimmerfenster ist seit 2 Std offen (Sollte geschlossen werden)
   TIMER_announcetarget home
   alias      GZ Fenster
   autocreate 1
   devStateIcon delay:own-window-delayed@blue closed:fts_window_2w@green open:fts_window_2w_open@red
   event-on-change-reading state,contact,linkquality:10
   event-on-update-reading state
   group      Fenster
   imageLink  /fhem/deviceimages/mqtt2/MCCGQ01LM.jpg
   readingList zigbee2mqtt/TK_OG_GZ_fenster:.* { json2nameValue($EVENT) }
zigbee2mqtt/0x00158d0002d72f41:.* { json2nameValue($EVENT) }
   room       Büro / Gäste
   sortby     90
   stateFormat <pre>
state
</pre>
   userReadings timestamp:.* { time() }

p.s. Kann den Rest aber erst heute Nacht testen ... Arbeit wartet da leider auf mich ;(

[Beta-User]

Zum einen sollte "irgendwo" was ankommen, wenn "autocreate" am M2C aktiv ist (und ein TYPE=autocreate). Vermutlich aber nicht da, wo du vermutest, denn
- das IODev-Attribut müßte geändert werden (sieht nach dem "alten" (internen) Server aus, nicht nach M2C; bitte auch am "bridge-Gerät" checken)
- und M2D-autocreate müßte wissen, dass die "umbenannte" und die "tech"-Id Identisch sind (das ist u.A. der Grund, warum ich "friendly names" für zigbee2mqtt _nicht empfehle_... Arbeitet man nur mit den tech-Names ("0xirgendwas") als "Pseudo-CID", sind die auch über verschiedene Installationen weg einheitlich und können für bridgeRegexp besser genutzt werden).

Ergänzend: Bitte den Wiki-Artikel zu M2C lesen, da steht noch drin, was man (mAn.) ergänzend tun sollte. (Feedback ist wie immer zu den Wiki-Themen ausdrücklich erbeten!)

[Otto123]

Ein wesentlicher Unterscheid in der default Einstellung

Attribute	MQTT2_SERVER	MQTT2_CLIENT
autocreate	simpel	no

[flummy1978]

Hey,

sorry dass ich mich jetzt erst melde, hatten privat viel um die Ohren und bin heute erst zum testen gekommen.

Zum einen sollte "irgendwo" was ankommen, wenn "autocreate" am M2C aktiv ist (und ein TYPE=autocreate). Vermutlich aber nicht da, wo du vermutest, denn
- das IODev-Attribut müßte geändert werden (sieht nach dem "alten" (internen) Server aus, nicht nach M2C; bitte auch am "bridge-Gerät" checken)
- und M2D-autocreate müßte wissen, dass die "umbenannte" und die "tech"-Id Identisch sind (das ist u.A. der Grund, warum ich "friendly names" für zigbee2mqtt _nicht empfehle_... Arbeitet man nur mit den tech-Names ("0xirgendwas") als "Pseudo-CID", sind die auch über verschiedene Installationen weg einheitlich und können für bridgeRegexp besser genutzt werden).

Das habe ich nun auch öfter gemerkt. Habe zum Glück die Pseudo CID nur bei einigen wenigen Teilen genommen und das ist auch gut so. So kann ich die Sachen auch direkt in der Installation zuordnen und auch in der Datenbank findet sich das Device schneller, wenn man die tech-ID behält. Das werde ich in Zukunft auch befolgen.

Ein wesentlicher Unterscheid in der default Einstellung

Kaum macht man es richtig, funktkioniert es auch. Hatte das schon getestet bevor ich hier alles gelesen hatte und genau das war es auch..... Hab im M2C Device auf Raspi autocreate simple eingeschaltet und schon werden die Geräte vom Docker auch auf dem Raspi angelegt. Andersrum hab ich mich nicht getraut, weil ich glaube dass ich den Radikalumstieg machen werde.

Ergänzend noch das List von einem angelegte Gerät, das auf dem Docker-Zigbee2MQTT angelernt ist und per M2C auf das Raspi -Fhem geschickt wird:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        zigbee_0x00158d00033a22bd
   DEF        zigbee_0x00158d00033a22bd
   DEVICETOPIC MQTT2_zigbee_0x00158d00033a22bd
   FUUID      60a6db8e-f33f-6adc-4e27-2ce5d22b66473acd
   IODev      MQTT2Client_docker
   LASTInputDev MQTT2Client_docker
   MQTT2Client_docker_MSGCNT 565
   MQTT2Client_docker_TIME 2021-05-24 14:44:31
   MSGCNT     565
   NAME       MQTT2_zigbee_0x00158d00033a22bd
   NR         498059
   STATE      ???
   TYPE       MQTT2_DEVICE
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2021-05-20 23:58:38   IODev           MQTT2Client_docker
     2021-05-20 23:58:38   associatedWith  dev_SYS_zigbee_bridge
     2021-05-24 14:44:31   battery         97
     2021-05-24 14:44:31   illuminance     25
     2021-05-24 14:44:31   illuminance_lux 25
     2021-05-24 14:44:31   linkquality     65
     2021-05-24 14:44:31   occupancy       false
     2021-05-24 14:44:31   voltage         2995
Attributes:
   DbLogExclude .*
   event-on-change-reading .*
   readingList zigbee2mqtt/0x00158d00033a22bd:.* { json2nameValue($EVENT) }
   room       Verbindungen->Zigbee->Docker


Es ist zwar keine MQTT Frage, aber vielleicht hat jemand von euch trotzdem eine Idee
Wie würdet Ihr vorgehen (bzw habt Ihr eine Idee) ob es möglich ist, die die Config vom Raspi (inkl entsprechendem Stick) auf den Docker zu übertragen ohne alles neu anzulernen? D.h. ich müsste dem Zigbee2MQTT auf dem Docker alle Einstellungen vom Raspi geben (ID, Geräte username passwort usw) ? Also eigentlich sollte es doch reichen die config.yaml und database.db rüber zu kopieren den Stick umzustecken und es sollte 1:1 übernommen werden oder ? *grübel*

VG
Andreas

[Otto123]

Hallo Andreas,

ich habe das noch nicht gemacht, aber hier ist doch ein backup und restore beschrieben? Punkt 6
https://www.zigbee2mqtt.io/getting_started/running_zigbee2mqtt.html

Gruß Otto