Sonoff Zigbee Brige Pro - Verzweiflung...

[FPVZaphod]

Hallo Zusammen,

nach gefühlt 500 Tutorials und ebensovielen Versuchen bin ich nun kurz davor, aufzugeben.
Ausgangssituation:
iobroker läuft auf einer Debian-VM unter FreeBSD/Bhyve, seit Jahren stabil und problemlos. Aktuell hängen ausschliesslich Shellies dran, da die Türsensoren aber etwas batteriehungrig sind, sollen nun ein paar Zigbee-Devices dazu.
Daher eine Sonoff Zigbee Bridge Pro gekauft, Tasmota draufgeflashed. 15.0.1, völlig problemlose installation. Dazu per Berry-Console SonoffZBPro_coord_20220219.hex geflashed, auch das ging ohne Zwischenfälle.
Nun kann ich mit der Auto-Conf Funktion ja zwei Configs auswählen. Die normale (Sonoff ZBPro), und eine andere (Sonoff ZBPro TCP). Soweit ich verstanden habe, verwendet man die erste Variante via mqtt zum Adapter Zigbee2mqtt. Dort bindet man Zigbee-Devices direkt auf der Bridge, und kann sich auch dort die Mesh-Map anzeigen lassen.
Zweite Variante (TCP) öffnet auf der Bridge den Port 8888, iobroker greift dann aus dem Zigbee-Adapter direkt darauf zu. Binding und Map sieht man im Adapter, nicht auf der Bridge.
Welche Variante nun die bessere ist, ist mir noch nicht ganz klar. Die Instanz, für die ich das ganze gerade ausprobiere, steht im sonnigen Paraguay, ich habe dort ein Haus für die Ferien und zur Vermietung. Kann also nicht einfach mal schnell hin, und ein Ausfall würde auch potentielle Mieter betreffen. Darum habe ich dort zwei FreeBSD-Rechner stehen, beide getrennt über je einen Shelly steuerbar, und die sind auch meine einzigen, die an der Shelly-Cloud hängen. Beide Rechner haben einen Hypervisor, und einmal pro Woche wird der zweite Rechner angeschaltet, die VM auf dem ersten angehalten, auf den zweiten rüberkopiert und der zweite Rechner wieder abgeschaltet. Darum auch Zigbee per Ethernet, und nicht per USB. Auch weil USB-Forwarding in einen Bhyve-Hypervisor etwas übel ist.

Bei der Variante 1 (ohne TCP8888) würde das Binding der Zigbee-Geräte in der Bridge passieren, und auch dort erhalten bleiben, egal was man im iobroker macht. Variante 2 (TCP8888) sollte aber auch gehen, da die VM ja eh "mit Haut, Haaren und IP" verschoben wird.
Nun zu den Problemen:
Variante 1 (zigbee2mqtt):

• Via Websocket, keine Ahung was das macht, und wie es funktionieren könnte.
• Interner mqtt-Server:
  Alles ist default, im der Bridge ist nur die IP vom iobroker und Port 1885 (default mqtt vom Adapter) hinterlegt. Das Log der Brige sieht happy aus:

00:00:00.003 HDW: ESP32-D0WD-V3 v3.1 (PSRAM)
00:00:00.060 UFS: FlashFS mounted with 804 kB free
00:00:00.073 CFG: Loaded from File, Count 115
00:00:00.083 QPC: Count 1
00:00:00.088 I2C: Bus1 using GPIO26(SCL) and GPIO25(SDA)
00:00:00.133 BRY: Berry initialized, RAM used 3189 bytes
00:00:00.166 Project tasmota - Tasmota-ZBB Version 15.0.1(release-zbbrdgpro)-3_1_3(2025-06-14T10:36:42)
00:00:00.167 ZIG: Loading Zigbee data
00:00:00.192 ZIG: Zigbee device information found in File System (1 devices - 44 bytes)
00:00:00.201 ZIG: Zigbee device data in File System (30 bytes)
00:00:00.205 ZIG: ZbLoad '<internal_plugin>' loaded successfully
00:00:01.117 WIF: Connecting to AP1 shellynet Channel 1 BSSId 74:83:C2:84:08:20 in mode HT40 as ZigbeeBridge...
00:00:03.797 WIF: Connected
08:23:39.035 HTP: Web server active on ZigbeeBridge with IP address 192.168.1.26
08:23:40.028 MQT: Attempting connection...
08:23:40.075 MQT: Connected
08:23:40.080 MQT: tele/tasmota_F3D648/LWT = Online (retained)
08:23:40.082 MQT: cmnd/tasmota_F3D648/POWER = 
08:23:40.086 MQT: tele/tasmota_F3D648/INFO1 = {"Info1":{"Module":"Sonoff Zigbee Pro","Version":"15.0.1(release-zbbrdgpro)","FallbackTopic":"cmnd/DVES_F3D648_fb/","GroupTopic":"cmnd/tasmotas/"}}
08:23:40.102 MQT: tele/tasmota_F3D648/INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"ZigbeeBridge","IPAddress":"192.168.1.26","IP6Global":"","IP6Local":"fe80::ea6b:eaff:fef3:d648%st1"}}
08:23:40.117 MQT: tele/tasmota_F3D648/INFO3 = {"Info3":{"RestartReason":"Software reset CPU","BootCount":58}}
08:23:40.152 RUL: SYSTEM#BOOT performs 'TCPStart 8888'
08:23:40.163 MQT: stat/tasmota_F3D648/RESULT = {"Command":"Unknown","Input":"TCPSTART 8888"}
08:23:43.970 QPC: Reset
08:23:45.904 MQT: tele/tasmota_F3D648/STATE = {"Time":"2025-08-22T08:23:45","Uptime":"0T00:00:11","UptimeSec":11,"Heap":182,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":48,"MqttCount":1,"Berry":{"HeapUsed":3,"Objects":34},"Wifi":{"AP":1,"SSId":"shellynet","BSSId":"74:83:C2:84:08:20","Channel":1,"Mode":"HT40","RSSI":72,"Signal":-64,"LinkCount":1,"Downtime":"0T00:00:03"}}
08:23:50.620 ZIG: rebooting ZNP device
08:23:52.862 MQT: tele/tasmota_F3D648/RESULT = {"ZbState":{"Status":1,"Message":"CCxxxx ZNP booted","RestartReason":"Power-up","MajorRel":2,"MinorRel":7}}
08:23:53.054 MQT: tele/tasmota_F3D648/RESULT = {"ZbState":{"Status":50,"MajorRel":2,"MinorRel":7,"MaintRel":1,"Revision":20240710}}
08:23:53.402 MQT: tele/tasmota_F3D648/RESULT = {"ZbState":{"Status":3,"Message":"Configured, starting coordinator"}}
08:23:56.468 MQT: tele/tasmota_F3D648/RESULT = {"ZbState":{"Status":40,"NewState":9,"Message":"Started as coordinator"}}
08:23:56.622 MQT: tele/tasmota_F3D648/RESULT = {"ZbState":{"Status":51,"IEEEAddr":"0x00124B0030CA200D","ShortAddr":"0x0000","DeviceType":7,"DeviceState":9,"NumAssocDevices":0}}
08:23:58.262 MQT: tele/tasmota_F3D648/RESULT = {"ZbState":{"Status":0,"Message":"Started"}}
08:23:58.267 ZIG: Zigbee started

Das Log vom iobroker bleibt dabei leer, es wird beim Brigdge-Reboot nichts gelogged. Auch unter den Objects unter zigbee2mqtt erscheint das verbundene Termometer nicht.

Mit einem externen MQTT-Server (der vom mqtt-Adapter) erscheint mein Thermometer zwar, aber schön in einzelne Werte aufgeteilt im zigbee2mqtt-Adaper kommen sie nicht. Hier ist vielleicht das Base-Topic anzupassen, weil er es ggf. nicht findet? Was müsste man da eintragen?

Stelle ich nur auch die TCP-Config um, deaktiviere den zigbee2mqtt-Adapter, und aktiviere den Zigbee-Adapter, passiert folgendes:
Bridge-Log:

00:00:00.003 HDW: ESP32-D0WD-V3 v3.1 (PSRAM)
00:00:00.119 UFS: FlashFS mounted with 804 kB free
00:00:00.142 CFG: Loaded from File, Count 117
00:00:00.144 FRC: Some settings have been reset (2)
00:00:00.149 I2C: Bus1 using GPIO26(SCL) and GPIO25(SDA)
00:00:00.227 BRY: Berry initialized, RAM used 3193 bytes
00:00:00.276 Project tasmota - Tasmota-ZBB Version 15.0.1(release-zbbrdgpro)-3_1_3(2025-06-14T10:36:42)
00:00:01.068 WIF: Connecting to AP1 shellynet Channel 1 BSSId 74:83:C2:84:08:20 in mode HT40 as ZigbeeBridge...
00:00:03.719 WIF: Connected
08:34:46.019 HTP: Web server active on ZigbeeBridge with IP address 192.168.1.26
08:34:48.802 MQT: Attempting connection...
08:34:48.826 MQT: Connected
08:34:48.830 MQT: tele/tasmota_F3D648/LWT = Online (retained)
08:34:48.833 MQT: cmnd/tasmota_F3D648/POWER = 
08:34:48.837 MQT: tele/tasmota_F3D648/INFO1 = {"Info1":{"Module":"TCP ZBBridge Pro","Version":"15.0.1(release-zbbrdgpro)","FallbackTopic":"cmnd/DVES_F3D648_fb/","GroupTopic":"cmnd/tasmotas/"}}
08:34:48.853 MQT: tele/tasmota_F3D648/INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"ZigbeeBridge","IPAddress":"192.168.1.26","IP6Global":"","IP6Local":"fe80::ea6b:eaff:fef3:d648%st1"}}
08:34:48.868 MQT: tele/tasmota_F3D648/INFO3 = {"Info3":{"RestartReason":"Software reset CPU","BootCount":59}}
08:34:48.904 RUL: SYSTEM#BOOT performs 'TCPStart 8888'
08:34:48.906 TCP: Starting TCP server on port 8888
08:34:48.913 MQT: stat/tasmota_F3D648/RESULT = {"TCPStart":"Done"}
08:34:50.862 QPC: Reset
08:34:52.865 MQT: tele/tasmota_F3D648/STATE = {"Time":"2025-08-22T08:34:52","Uptime":"0T00:00:10","UptimeSec":10,"Heap":182,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":50,"MqttCount":1,"Berry":{"HeapUsed":3,"Objects":43},"Wifi":{"AP":1,"SSId":"shellynet","BSSId":"74:83:C2:84:08:20","Channel":1,"Mode":"HT40","RSSI":70,"Signal":-65,"LinkCount":1,"Downtime":"0T00:00:03"}}

Zigbee-Adapter:
Com Port: tcp://192.168.1.26:8888
Type: SL EFR32 (EZSP)
Extended PAN-ID: 16 Zeichen (0-9/a-f)
PAN-ID: (4-stellige Zahl)
Channel: 18

Iobroker-Log beim Adapter-Start:

2025-08-22 09:39:44.776 - info: host.iobroker "system.adapter.zigbee.0" enabled
2025-08-22 09:39:45.019 - info: host.iobroker instance system.adapter.zigbee.0 in version "2.0.5" started with pid 321304
2025-08-22 09:39:46.110 - info: zigbee.0 (321304) starting. Version 2.0.5 in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.19.1, js-controller: 7.0.6
2025-08-22 09:39:46.120 - info: zigbee.0 (321304) init localConfig
2025-08-22 09:39:46.123 - info: zigbee.0 (321304) --> transmitPower : normal
2025-08-22 09:39:46.129 - info: zigbee.0 (321304) delete old Backup files. keep only last 10
2025-08-22 09:39:46.130 - info: zigbee.0 (321304) --- creating device debug ---
2025-08-22 09:39:46.131 - info: zigbee.0 (321304) Starting Adapter npm ...
2025-08-22 09:39:46.156 - info: zigbee.0 (321304) Installed Version: iobroker.zigbee@2.0.5 (Converters 23.6.0 Herdsman 3.5.2)
2025-08-22 09:39:46.156 - info: zigbee.0 (321304) Starting Zigbee-Herdsman
2025-08-22 09:39:56.333 - error: zigbee.0 (321304) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2025-08-22 09:39:56.334 - error: zigbee.0 (321304) unhandled promise rejection: Failure to connect
2025-08-22 09:39:56.360 - error: zigbee.0 (321304) Error: Failure to connect
at SerialDriver.resetForReconnect (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:341:19)
at SerialDriver.emit (node:events:524:28)
at SerialDriver.emit (node:domain:489:12)
at /opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:340:22
at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20)
at SerialDriver.reset (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:325:16)
at Socket. (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:148:17)
2025-08-22 09:39:56.360 - error: zigbee.0 (321304) Failure to connect
2025-08-22 09:39:56.372 - info: zigbee.0 (321304) cleaned everything up...
2025-08-22 09:39:56.372 - info: zigbee.0 (321304) local config saved
2025-08-22 09:39:56.372 - info: zigbee.0 (321304) Saved local configuration data
2025-08-22 09:39:56.373 - info: zigbee.0 (321304) terminating
2025-08-22 09:39:56.373 - warn: zigbee.0 (321304) Terminated (UNCAUGHT_EXCEPTION): Without reason
2025-08-22 09:39:56.384 - error: zigbee.0 (321304) Failed to open the network: TypeError: Cannot read properties of undefined (reading 'permitJoin')
at Controller.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/controller.ts:315:35)
at ZigbeeController.permitJoin (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:659:33)
at ZigbeeController.stop (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:634:24)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at Zigbee.onUnload (/opt/iobroker/node_modules/iobroker.zigbee/main.js:1037:17)
2025-08-22 09:39:56.387 - info: zigbee.0 (321304) terminating
2025-08-22 09:39:56.878 - info: zigbee.0 (321304) terminating
2025-08-22 09:39:56.911 - error: host.iobroker Caught by controller[0]: [2025-08-22T07:39:46.211Z] zh:ezsp: 'ezsp' driver is deprecated and will only remain to provide support for older firmware (pre 7.4.x). Migration to 'ember' is recommended. If using Zigbee2MQTT see https://github.com/Koenkk/zigbee2mqtt/discussions/21462
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[1]: [2025-08-22T07:39:56.330Z] zh:ezsp:uart: --> Error: Error: {"sequence":-1} after 10000ms
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[2]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[3]: Error: Failure to connect
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[3]: at SerialDriver.resetForReconnect (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:341:19)
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[3]: at SerialDriver.emit (node:events:524:28)
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[3]: at SerialDriver.emit (node:domain:489:12)
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[3]: at /opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:340:22
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[3]: at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20)
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[3]: at SerialDriver.reset (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:325:16)
2025-08-22 09:39:56.912 - error: host.iobroker Caught by controller[3]: at Socket. (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:148:17)
2025-08-22 09:39:56.912 - error: host.iobroker instance system.adapter.zigbee.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2025-08-22 09:39:56.912 - info: host.iobroker Restart adapter system.adapter.zigbee.0 because enabled

Ändere ich den Type nun auf EFR32 (EMBER), sieht es so aus:

2025-08-22 09:42:27.213 - info: host.iobroker "system.adapter.zigbee.0" enabled
2025-08-22 09:42:27.504 - info: host.iobroker instance system.adapter.zigbee.0 in version "2.0.5" started with pid 321389
2025-08-22 09:42:28.636 - info: zigbee.0 (321389) starting. Version 2.0.5 in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.19.1, js-controller: 7.0.6
2025-08-22 09:42:28.645 - info: zigbee.0 (321389) init localConfig
2025-08-22 09:42:28.649 - info: zigbee.0 (321389) --> transmitPower : normal
2025-08-22 09:42:28.655 - info: zigbee.0 (321389) delete old Backup files. keep only last 10
2025-08-22 09:42:28.656 - info: zigbee.0 (321389) --- creating device debug ---
2025-08-22 09:42:28.657 - info: zigbee.0 (321389) Starting Adapter npm ...
2025-08-22 09:42:28.680 - info: zigbee.0 (321389) Installed Version: iobroker.zigbee@2.0.5 (Converters 23.6.0 Herdsman 3.5.2)
2025-08-22 09:42:28.681 - info: zigbee.0 (321389) Starting Zigbee-Herdsman
2025-08-22 09:42:41.728 - info: zigbee.0 (321389) Unable to obtain herdsman settings
2025-08-22 09:42:41.789 - error: zigbee.0 (321389) Starting zigbee-herdsman problem : Failed to start EZSP layer with status=HOST_FATAL_ERROR.
2025-08-22 09:42:41.790 - error: zigbee.0 (321389) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2025-08-22 09:42:41.790 - error: zigbee.0 (321389) unhandled promise rejection: undefined
2025-08-22 09:42:41.790 - error: zigbee.0 (321389) undefined
2025-08-22 09:42:41.807 - info: zigbee.0 (321389) cleaned everything up...
2025-08-22 09:42:41.808 - info: zigbee.0 (321389) local config saved
2025-08-22 09:42:41.808 - info: zigbee.0 (321389) Saved local configuration data
2025-08-22 09:42:41.808 - info: zigbee.0 (321389) terminating
2025-08-22 09:42:41.809 - warn: zigbee.0 (321389) Terminated (UNCAUGHT_EXCEPTION): Without reason
2025-08-22 09:42:41.810 - error: zigbee.0 (321389) Failed to open the network: TypeError: Cannot read properties of undefined (reading 'permitJoin')
at Controller.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/controller.ts:315:35)
at ZigbeeController.permitJoin (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:659:33)
at ZigbeeController.stop (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:634:24)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at Zigbee.onUnload (/opt/iobroker/node_modules/iobroker.zigbee/main.js:1037:17)
2025-08-22 09:42:41.812 - info: zigbee.0 (321389) terminating
2025-08-22 09:42:42.314 - info: zigbee.0 (321389) terminating
2025-08-22 09:42:42.343 - error: host.iobroker Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
2025-08-22 09:42:42.344 - error: host.iobroker Caught by controller[1]: Error herdsman start
2025-08-22 09:42:42.344 - error: host.iobroker instance system.adapter.zigbee.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2025-08-22 09:42:42.344 - info: host.iobroker Restart adapter system.adapter.zigbee.0 because enabled

Versuchsweise noch TI-ZStack:

2025-08-22 09:43:52.705 - info: host.iobroker "system.adapter.zigbee.0" enabled
2025-08-22 09:43:52.979 - info: host.iobroker instance system.adapter.zigbee.0 in version "2.0.5" started with pid 321432
2025-08-22 09:43:54.004 - info: zigbee.0 (321432) starting. Version 2.0.5 in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.19.1, js-controller: 7.0.6
2025-08-22 09:43:54.019 - info: zigbee.0 (321432) init localConfig
2025-08-22 09:43:54.023 - info: zigbee.0 (321432) --> transmitPower : normal
2025-08-22 09:43:54.030 - info: zigbee.0 (321432) delete old Backup files. keep only last 10
2025-08-22 09:43:54.031 - info: zigbee.0 (321432) --- creating device debug ---
2025-08-22 09:43:54.031 - info: zigbee.0 (321432) Starting Adapter npm ...
2025-08-22 09:43:54.051 - info: zigbee.0 (321432) Installed Version: iobroker.zigbee@2.0.5 (Converters 23.6.0 Herdsman 3.5.2)
2025-08-22 09:43:54.051 - info: zigbee.0 (321432) Starting Zigbee-Herdsman
2025-08-22 09:43:57.203 - info: zigbee.0 (321432) Zigbee-Herdsman started successfully with Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20240710}}
2025-08-22 09:43:57.205 - info: zigbee.0 (321432) Unable to disable LED, unsupported function.
2025-08-22 09:43:57.238 - info: zigbee.0 (321432) Currently no devices.
2025-08-22 09:43:57.240 - info: zigbee.0 (321432) Zigbee started
2025-08-22 09:44:39.738 - info: admin.0 (464) ==> Connected system.user.admin from ::ffff:192.168.7.5
2025-08-22 09:44:40.321 - info: zigbee.0 (321432) debug devices set to []
2025-08-22 09:44:40.341 - info: zigbee.0 (321432) List of port: [{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS3"}]

Ich brech ab . Auf einmal geht es. Der Adaper ist grün.

Okay, ich habe die letzten 3 Tage stundenlang damit verbracht, all das auszuprobieren. Genau so. Jetzt wollte ich heute dafür mal Hilfe suchen, und hab alles nochmal nachgespielt und Screenshots gemacht, um das Scheitern zu dokumentieren. Da es jetzt mehr oder weniger durch Zufall EINE Variante geht, hab ich beschlossen, das ganze doch zu posten. Vielleicht hat jemand die Zeit, mal zu erklären, ob die Gedankengänge soweit richtig waren. Ob diese Variante okay ist und stabil laufen sollte. Warum Ti-ZStack, obwohl eigentlich kein Tutorial dies erwähnt, sondern immer nur EZSP oder EMBER. Ob es damit zusammenhängen könnte, dass ich zum Schluss anstelle des bei Tasmota mitgelieferten SonoffZBPro_coord_20220219.hex versuchsweise die 20240710.hex geflasht habe. Ob zigbee2mqtt vielleicht Vorteile hat, oder ob die Nachteile (funktioniert jede Hardware?) überwiegen?
Ich mag solche Glückstreffer nicht sonderlich, speziell wenn sie 11.000km entfernt laufen sollen. Weil genauso wie man es durch Glück zum laufen bekommt, kann man es durch Glück wieder zerlegen. Ist die Sonoff-Bridge der richtige Weg, oder sollte man besser ein paar Taler in die Hand nehmen, und eine SLZB-06 kaufen? Per POE am Unifi-Switch betrieben, könnte ich die dann auch aus der Ferne kurz stromlos machen, wenn was klemmt. Okay, der Sonoff-Bridge einen Shelly zu spendieren, wäre auch nicht der Aufwand.

Danke für die Geduld, und sorry für das längliche Frustposting.

[Asgothian]

@fpvzaphod sagte in Sonoff Zigbee Brige Pro - Verzweiflung...:

Okay, ich habe die letzten 3 Tage stundenlang damit verbracht, all das auszuprobieren. Genau so. Jetzt wollte ich heute dafür mal Hilfe suchen, und hab alles nochmal nachgespielt und Screenshots gemacht, um das Scheitern zu dokumentieren. Da es jetzt mehr oder weniger durch Zufall EINE Variante geht, hab ich beschlossen, das ganze doch zu posten. Vielleicht hat jemand die Zeit, mal zu erklären, ob die Gedankengänge soweit richtig waren. Ob diese Variante okay ist und stabil laufen sollte. Warum Ti-ZStack, obwohl eigentlich kein Tutorial dies erwähnt, sondern immer nur EZSP oder EMBER. Ob es damit zusammenhängen könnte, dass ich zum Schluss anstelle des bei Tasmota mitgelieferten SonoffZBPro_coord_20220219.hex versuchsweise die 20240710.hex geflasht habe. Ob zigbee2mqtt vielleicht Vorteile hat, oder ob die Nachteile (funktioniert jede Hardware?) überwiegen?
Ich mag solche Glückstreffer nicht sonderlich, speziell wenn sie 11.000km entfernt laufen sollen. Weil genauso wie man es durch Glück zum laufen bekommt, kann man es durch Glück wieder zerlegen. Ist die Sonoff-Bridge der richtige Weg, oder sollte man besser ein paar Taler in die Hand nehmen, und eine SLZB-06 kaufen? Per POE am Unifi-Switch betrieben, könnte ich die dann auch aus der Ferne kurz stromlos machen, wenn was klemmt. Okay, der Sonoff-Bridge einen Shelly zu spendieren, wäre auch nicht der Aufwand.
Danke für die Geduld, und sorry für das längliche Frustposting.

Zerlegen wir das ganze mal systematisch:

Sonoff hat mehrere zigbee Bridges heraus gebracht. Mehrere davon als Zigbee-Bridge Pro. Die die du gekauft hast (Zigbee-Bridge Pro P) nutzt einen TI Chipsatz, während ältere Zigbee-Bridges den EZSP Chipsatz nutzen.

Daher ist es korrekt das in der von Dir gewählten Variante (Bridge ist 'dumm', Geräte werden via externer Software angelernt) Du auch mit dem entsprechenden Adapter (TI, nicht Ember/EZSP) arbeiten musst.

Generell rare ich eigentlich immer davon ab direkt mit einem auf der Bridge laufenden MQTT Server Client zu arbeiten. In diesem Fall bist du darauf angewiesen das die Firmware der Bridge alle Deine Zigbee-Geräte erkennt und unterstützt - viel Glück damit. Besser ist die jetzt bei Dir laufende Variante wo die Bridge selber 'dumm' ist, und letztendlich nur eine Umsetzung Wifi - Seriell macht, damit der verbaute Zigbee-Chip mit deinem Rechner kommunizieren kann.

Zum Thema SLZB06 oder ähnliches - ich persönlich ziehe diese Variante vor, da sie nicht via WLan kommuniziert, und es damit keine Kollision im 2.4 GHz Funknetz gibt (die Sonoff Bridge macht nur 2.4 GHz WLan, und erzeugt damit direkt am Koordinator Signale die je nach Kanalwahl das Zigbee Netz stören können. Ansonsten sollte das was Du jetzt hast durchaus laufen.

A.
Fehlerbehebung - MQTT Client auf Sonoff gibts, nicht MQTT Server

[FPVZaphod]

@asgothian Cool, danke - das ist die beste Erklärung: Es gibt nicht nur eine Zigbee Pro Bridge. Im Web geistern so viele Bilder und Anleitungen herum...
Was meist Du mit "auf der Bridge laufendem MQTT-Server" ? Gibt's das auch? Bisher dachte ich, die Bridge verbindet sich zu einem MQTT-Server (iobroker-mqtt , dem internen vom zigbee2mqtt-Adapter, oder einem komplett anderen) und der zigbee2mqtt-Adapter macht das dann hübsch als einzelne Items im iobroker? Das wäre dann eine vierte Variante, der Adapter subscibed Topics vom Server, der auf der Bridge läuft?
Fein, aber gut zu Wissen, dass der Weg wie es jetzt läuft der zu bevorzugende ist, auch wenn die Hardware noch Verbesserungspotential hat.
Wie wäre das eigentlich, wenn ich das so einrichte, und später den Ethernet-Adaper rüberschicke. Wenn im Adapter die PAN gleich bleibt, müssten die Bindung der Sensoren beim Wechsel der Zigbee-Bridge erhalten bleiben?

[Asgothian]

@fpvzaphod sagte in Sonoff Zigbee Brige Pro - Verzweiflung...:

"auf der Bridge laufendem MQTT-Server"

Nein, das war ein Typo: "auf der Bridge laufendem MQTT client"

Ist oben auch behoben.

@fpvzaphod sagte in Sonoff Zigbee Brige Pro - Verzweiflung...:

Wie wäre das eigentlich, wenn ich das so einrichte, und später den Ethernet-Adaper rüberschicke. Wenn im Adapter die PAN gleich bleibt, müssten die Bindung der Sensoren beim Wechsel der Zigbee-Bridge erhalten bleiben?

Da du einen TI basierten Koordinator hast - ja.

Bei einem Umzug von Koordinator mit Chipsatz A zu einem mit Chipsatz B geht das so nicht. (TI-> EZSP oder umgekehrt, oder Conbee -> irgendwas nicht Conbee)

[FPVZaphod]

@asgothian Danke für die ausführliche Erklärung, langsam gewinne ich wieder Vertrauen in das ganze
Rätselhaft bleibt weiterhin, warum es vorher nicht ging. Ich hatte ALLE Varianten durchprobiert, auch Ti. Ob es jetzt an der 2024er Coordinator-Version liegt dass es geht, bleibt eine Vermutung, da ich die voherige 2022 nicht mehr testen werde. Nun geht's, und ein POE-Adapter wird demnächst bestellt!