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 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!

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

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.

So, es wird:
Alle Räume haben einen HT+ , es gibt eine einstellbare Solltemperatur. Wenn die unterschritten wird, Ventil auf, ansonsten zu.
Da der Raum im Keller dazu neigt, seine Warmluft nach oben Richtung Wohnzimmer abzugeben, bräuche man da so gut wie nie einen Einsatz der Heizung, weil immer über den gewünschten 20.5 Grad. Dadurch wird der Keramikfussboden unangenehm kalt. Darum hab ich noch was dazuprogrammiert, was morgens von 6-8 Uhr die Fussbodenheizung im Wohnzimmer angeht, die im Kinderzimmer von 10-12 Uhr. Mal beobachten, wie sich das dann über eine Woche macht, auch im Verhältnis zur Aussentemperatur.
Was ich letztes Jahr schon gemacht habe: Der Aussentemperatursensor ist abgeklemmt, und durch einen Arduino ersetzt. Damit kann ich der Wärmepume eine beliebige Aussentemperatur vorgaukeln. Da das Ding SO träge ist, dass man eigentlich immer die Temperatur von übermorgen zum regeln bräuchte, mache ich genau das. Die WP bekommt die Temperatur, die laut Wettervorhersage übermorgen kommen wird. Das ist natürlich nicht perfekt, aber Welten besser als die aktuelle Temperatur.

@dreistein Ich habe mich ja schon damit abgefunden, da eine Regelung nachzurüsten, auf eigene Kosten, und halt auch danach mitnehmbar.
Keine TVRs zu brauchen, sondern nur mit Wachstellern und Shellies zu arbeiten, käme mir da schon mächtig entgegen, weil die Wachsdinger und die Shellies habe ich schon, inklusive einem gedruckten Gehäuse für drei von denen. Das hatte ich nur fallenlassen, weil mir nicht klar war, dass man mit den Durchfluss-Anzeigen auch den Durchfluss einstellen kann, und nicht die Kappendinger dafür nehmen muss. Wenn der Durchfluss schonmal grob mit den Messteilen eingestellt ist (im Sinne von: Alle Räume bekommen was ab, ein Kellerraum frisst nicht alles weg, wenn er aufgeht), dann ist das schonmal eine Riesenhilfe. Dann ordere ich mal einen Eimer voller HT Plus, verteile die in allen Räumen, und baue eine simple Steuerung im iobroker, die einfach bei erreichen der Solltemperatur den Steller dicht macht. Das hilft sicher schonmal gewaltig!

Die Wärmepumpe ist eine Elco Aquatop T08C, und was noch so draufsteht:
Normbetriebspunkt: B0/W35
Heizleistung 8.2kW
Durchfluss Anlagenseitig: 1008l/h
Erdsondenseitig: 1992l/h

Whow, danke für die Infos!
Man sollte also die blauen Kappen alle wegnehmen (=voll offen), und dann mit dem Vierkant auf dem Plexi-Röhrchen die Durchflussmenge einstellen? Alle auf einen brauchbaren, ähnlichen Wert irgendwo in der Mitte, sagen wir mal 1.5-2, und dann per Thermostat (HT Plus) einfach den Kreis via Wachs-Steller zudrücken, wenn warm genug?
Das klingt ja schonmal erheblich besser, mir war nicht bewusst, dass man durch drehen der PlexiDinger auch was einstellen kann

Ja, hängt an der Decke. Der für den Keller hängt 3m entfernt an der Wand, allerdings bekomme ich dank der doofen Verrohrung da wohl keine TVRs drauf, höchstens die Wachsdinger.
Kann man an den Plexiglas-Röhrchen auch was zudrehen? Okay, also besser erst mal abwarten, ein Ausfall wäre bei dem Wetter blöd
Das Haus ist Baujahr 2011, und nur gemietet. Sonst hätte ich da längst was gescheites verbaut, aber so soll es ja einfach rückrüstbar sein. Darum HT+ in jeden Raum.
Letzten Winter hatte ich entdeckt, dass da zusätzlich zur WP noch eine elektrische Zusatzheizung verbaut ist, und dass diese schon bei lauen 2 Grad Aussentemperaturen oft mitläuft. Und das einfach so, ohne Beachtung vom Niedertarif. Wie stark die ist, weiss ich nicht - abgesichert ist sie aber mit 3x16. Man fasst es nicht…

Das sieht ziemlich unspektakulär aus:

Die Durchfluss-Dinger sind innen total verschmoddert, man sieht den Stempel kaum noch. Wenn ich Vor- und Rücklauf absperre, und dann den Druck aus dem Wasserhähnchen rechts ablasse, kann man die Plexiglas-Dinger dann ohne Auslösung eines Tsunamis abschrauben und reinigen?
Der Abgleich mit den blauen Schraubdingern ging - bis auf die üble Rückmeldung der Messteile - halbwegs gut. Ich hatte alle auf 1.5L eingestellt, halt so lange bis es auf allen gestimmt hat. Dann ne Woche beobachtet, und die zu warmen Räume runtergeregelt, und die zu kalten hochgestellt. Dabei aber drauf geachtet, dass die guten Räume vom Durchfluss auch so geblieben sind. Hatte was von Klavierstimmen, wenn man links dreht, und rechts was wegdriftet.
Das stimmt dann aber für eine Aussentemperatur. Wenn es draussen 15 Grad kälter wird, stimmt es wieder nicht. Hat halt null Regelung (ausser Vorlauf zu Aussentemperatur), aber im Haus selbst sonst nichts.

Ich hatte es vorher mit den FBH-Aktoren versucht, in denen ein Wachs heiss gemacht wird, und dann das Ventil zudrückt. Immer zwei Stück angetrieben von einem Shelly2.5 Das war aber uncool, wegen besagtem Verhalten der Heizung. Darum wollte ich dann was Servoartiges, was auch Zwischenstellungen kennt.
Gefunden:
curl -u admin:passwd http://192.168.1.xx/thermostats/0?pos=5
Stellt das Ventil auf den gewünschten Wert, hier 5%. Per mqtt wäre das zwar hübscher, aber damit kann ich erst mal leben.
Uncool hier: 10 Kreisläufe (x 70Eur TVR) in 8 Räumen (x 40Eur Shelly HT+). Da klingelt die Kasse bei Shelly...

Die Fussbodenheizung bei mir ist relativ dämlich. Es gibt pro Kreislauf ein Ventil, mit blauer Schraubkappe zum einstellen, dazu ein Durchflussmesser. Das Haus hat 3 Etagen, zwei Zimmer im Keller, plus EG, plus OG.
Wenn ich nun ein simples Auf/Zu-Ventil verbaue, und dieses macht einen Kellerkreislauf auf, dann kommt im restlichen Haus genau nichts mehr an. "Auf" darf also nicht Auf sein, sondern nur so weit, dass eine bestimmte Durchflussmenge nicht überschritten wird. Es fehlt also eine Instanz im System, welches einen richtign Abgleich ermöglicht. Optimalerweise ein An/Aus-Ventil in Reihe mit was manuell einstellbarem.
Da das aber nicht existiert, will ich die TVRs manuell (Ventilposition) so einstellen, dass alle Zimmmer eine brauchbare Durchflussmenge haben, und die Zimmer, die zu warm werden, dann abstelle. Wenn die Temperatur wieder sinkt, dann wieder auf diesen experientell gefundenen Wert öffnen.
Daher die Frage: Wie teile ich dem TVR am geschicktesten eine gewünschte Ventilstellung mit?