Ignore the fact that the relay still switches on/off - I still need to see the debug logs.
I see the reason for the TurboMode error, will be fixed in the next update The NetworkIndicator error means it is not supported in the R2 model (this makes some sense, the device is built in the wall junction box, so no need to disable LEDs that are not visible..).
2025-03-11 08:17:35.284infoTerrace Top Lights Terrace Top Lights is off [physical]
2025-03-11 08:17:35.260debugTerrace Top Lights switch state changed from on to off
2025-03-11 08:17:35.258debugTerrace Top Lights parse: descMap = [raw:464B0100060800001000, dni:464B, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0] description=read attr - raw: 464B0100060800001000, dni: 464B, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00
2025-03-11 08:17:30.416infoTerrace Top Lights Terrace Top Lights is on [physical]
2025-03-11 08:17:30.399debugTerrace Top Lights switch state changed from off to on
2025-03-11 08:17:30.392debugTerrace Top Lights parse: descMap = [raw:464B0100060800001001, dni:464B, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:01, clusterInt:6, attrInt:0] description=read attr - raw: 464B0100060800001001, dni: 464B, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 01
Yes, it seems that the wiring diagrams on most of the SONOFF selling pages are wrong! EDIT: incomplete.
See this video :
From the last logs you provided I see no difference in the DetachedRelay mode...
Update: when you re-wire your ZBMINIR2 to use S1 and S2 for the external switch, please send me the debug logs in both cases - when the DetachRelay mode is disabled (default) and when is enabled. The Enable command works OK for the DetachRelay parameter in the latest driver version.
I was doing that before reading your update 
Using S1/S2 there is a behavior change.
Sequence of actions:
S1/S2 connected -> light turns on
S1/S2 disconnected -> light turns off
2025-03-11 13:00:58.360infoTerrace Top Lights Terrace Top Lights is off [physical]
2025-03-11 13:00:58.349debugTerrace Top Lights switch state changed from on to off
2025-03-11 13:00:58.347debugTerrace Top Lights parse: descMap = [raw:464B0100060800001000, dni:464B, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0] description=read attr - raw: 464B0100060800001000, dni: 464B, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00
2025-03-11 13:00:54.116infoTerrace Top Lights Terrace Top Lights is on [physical]
2025-03-11 13:00:54.099debugTerrace Top Lights switch state changed from off to on
2025-03-11 13:00:54.096debugTerrace Top Lights parse: descMap = [raw:464B0100060800001001, dni:464B, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:01, clusterInt:6, attrInt:0] description=read attr - raw: 464B0100060800001001, dni: 464B, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 01
Sequence of actions:
2025-03-11 13:04:19.208debugTerrace Top Lights standardParseOnOffCluster: skipped processing OnOIff cluster (attrId is null)
2025-03-11 13:04:19.206debugTerrace Top Lights parse: descMap = [raw:catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00 , profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:464B, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:00, data:[]] description=catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00
2025-03-11 13:04:17.220debugTerrace Top Lights standardParseOnOffCluster: skipped processing OnOIff cluster (attrId is null)
2025-03-11 13:04:17.218debugTerrace Top Lights parse: descMap = [raw:catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00 , profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:464B, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:00, data:[]] description=catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00
2025-03-11 13:04:15.263debugTerrace Top Lights standardParseOnOffCluster: skipped processing OnOIff cluster (attrId is null)
2025-03-11 13:04:15.261debugTerrace Top Lights parse: descMap = [raw:catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00 , profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:464B, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:00, data:[]] description=catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00
2025-03-11 13:04:29.204warnTerrace Top Lights customParseFC11Cluster: received unknown 0xFC11 attribute 0x0016 (value 00)
2025-03-11 13:04:29.201debugTerrace Top Lights parse: descMap = [raw:464B01FC110816002000, dni:464B, endpoint:01, cluster:FC11, size:08, attrId:0016, encoding:20, command:0A, value:00, clusterInt:64529, attrInt:22] description=read attr - raw: 464B01FC110816002000, dni: 464B, endpoint: 01, cluster: FC11, size: 08, attrId: 0016, encoding: 20, command: 0A, value: 00
2025-03-11 13:04:29.164debugTerrace Top Lights Ignored duplicated switch event on
2025-03-11 13:04:29.162debugTerrace Top Lights parse: descMap = [raw:464B0100060800001001, dni:464B, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:01, clusterInt:6, attrInt:0] description=read attr - raw: 464B0100060800001001, dni: 464B, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 01
2025-03-11 13:04:29.126infoTerrace Top Lights Terrace Top Lights is on [physical]
2025-03-11 13:04:29.112debugTerrace Top Lights switch state changed from off to on
2025-03-11 13:04:29.110debugTerrace Top Lights parse: descMap = [raw:464B0100060800001001, dni:464B, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:01, clusterInt:6, attrInt:0] description=read attr - raw: 464B0100060800001001, dni: 464B, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 01
2025-03-11 13:10:20.319debugTerrace Top Lights standardParseOnOffCluster: skipped processing OnOIff cluster (attrId is null)
2025-03-11 13:10:20.317debugTerrace Top Lights parse: descMap = [raw:catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00 , profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:464B, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:00, data:[]] description=catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00
2025-03-11 13:10:18.333debugTerrace Top Lights standardParseOnOffCluster: skipped processing OnOIff cluster (attrId is null)
2025-03-11 13:10:18.331debugTerrace Top Lights parse: descMap = [raw:catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00 , profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:464B, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:00, data:[]] description=catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00
2025-03-11 13:10:16.374debugTerrace Top Lights standardParseOnOffCluster: skipped processing OnOIff cluster (attrId is null)
2025-03-11 13:10:16.372debugTerrace Top Lights parse: descMap = [raw:catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00 , profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:464B, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:00, data:[]] description=catchall: 0104 0006 01 01 0040 00 464B 01 00 0000 02 00
2025-03-11 13:10:36.831warnTerrace Top Lights customParseFC11Cluster: received unknown 0xFC11 attribute 0x0016 (value 00)
2025-03-11 13:10:36.829debugTerrace Top Lights parse: descMap = [raw:464B01FC110816002000, dni:464B, endpoint:01, cluster:FC11, size:08, attrId:0016, encoding:20, command:0A, value:00, clusterInt:64529, attrInt:22] description=read attr - raw: 464B01FC110816002000, dni: 464B, endpoint: 01, cluster: FC11, size: 08, attrId: 0016, encoding: 20, command: 0A, value: 00
2025-03-11 13:10:36.795debugTerrace Top Lights Ignored duplicated switch event off
2025-03-11 13:10:36.793debugTerrace Top Lights parse: descMap = [raw:464B0100060800001000, dni:464B, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0] description=read attr - raw: 464B0100060800001000, dni: 464B, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00
2025-03-11 13:10:36.742infoTerrace Top Lights Terrace Top Lights is off [physical]
2025-03-11 13:10:36.718debugTerrace Top Lights switch state changed from on to off
2025-03-11 13:10:36.716debugTerrace Top Lights parse: descMap = [raw:464B0100060800001000, dni:464B, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0] description=read attr - raw: 464B0100060800001000, dni: 464B, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00
I think that I understand what happens now.
After switching to Detach(ed) Relay Mode, and after closing or opening the external switch, Sonoff is sending a notification command, that expects an acknowledgment from the Zigbee coordinator (the hub). As HE is not sending an acknowledge, the device makes two retries and automatically switches into a fall-back mode. That's why on the next change of the switch status change, the relay toggles it's state - this is an emergency/fallback logic when the hub is not operational for some reason.
The bad news is that this command acknowledgment ( 'ZCL default response') must be sent on system level, not from a custom driver... This is currently a problem even at Home Asssistant ZHA and the Detached Relay mode doesn't work there also, only Z2M handles it properly (and Sonoff hubs, of course).
I will try one last workaround, and there is a 50/50 chance of success.
I don't know what is the expected behavior, but from my tests it seems that a momentary push button would work well on detach relay mode.
In the new dev. branch version 3.3.1 there is a new 'Advanced Option' for ZBMINIR2 - 'External Trigger Mode' :
Please test it if it has any effect.
I expect the Zigbee Radio Power Turbo Mode to be working after this update as well:
If the ZCL Default Response workaround is working, In Detach Relay Mode, flipping the switch should generate a button 'pushed' event - please check the events and the logs :
In your use case scenario, the Relay Detach Mode will not be effective - actually, you are using a form of a detached relay mode already.
yeah i know. my current setup is a workaround because there was no way to do it properly...until your awesome driver effort! 
so happy to test for you, but i will need to re-wire one of them which requires a gap in work and kids. i'm in Aust so will likely be tomorrow morning before i can get a crack at it. let me know if you have someone already lined to do this and i'll watch intently from the sidelines instead. 
in the meantime, in terms of the (far more impactful) issue of the ZBMINIR2 and ZBmicro just dropping off the mesh consistently, i can DM some logs if that helps...
Yes, send me in a DM the logs.
@eduardo did you have a chance to test this version (the 'Detach Relay Mode') ?
I was on a trip for the past few days. I'll try to test it today or tomorrow.
The turbo mode seems to be working now. It is hard to tell because the mesh is a 'live' thing. But here are the results for the first device I tested:
Connections on Zigbee Map app
Before turbo mode
11 green
07 blue
08 purple
26 total
After turbo mode
11 green
10 blue
04 purple
25 total
ZBMINIR2 firmware version 1.0.4 is now available for update in HE - thank you @mike.maxwell !
This version was released about 3 months ago.
To update the firmware, switch to HE inbuilt 'Device' driver and click on the 'Update Zigbee Firmware' button. The progress can be monitored in the live logs, filter 'Hub'.
thanks @mike.maxwell and @kkossev attempted however a failure first time around. the ZBMINIR2 stayed online overnight, the longest period yet!
i'll try again, in the meantime here's the logs during the attempted firmware update:
sys:12025-03-20 08:18:48.486 warn Firmware update for null failed due to a cancel request from the device.
sys:12025-03-20 08:14:38.387 trace Starting firmware update for Bed1-ZBminiR, SONOFF from 00001002 to 00001004.
sys:12025-03-20 08:14:38.166 trace Downloading firmware update for Bed1-ZBminiR, SONOFF.
sys:12025-03-20 08:14:37.910 info Firmware update for Bed1-ZBminiR, SONOFF 1286-0008-00001002 is not available.
sys:12025-03-20 08:14:37.907 trace Unable to download firmware update for Bed1-ZBminiR, SONOFF, please try again.
sys:12025-03-20 08:14:37.499 info Firmware update for Bed1-ZBminiR, SONOFF 1286-0008-00001002 is not available.
sys:12025-03-20 08:14:37.494 trace Unable to download firmware update for Bed1-ZBminiR, SONOFF, please try again.
UPDATE: firmware upgrade worked perfectly 2nd time round, device reporting newer code base, will re-initialise the device (configure DEFAULTS then Configure again for desired configs), then monitor for stability. Upgrade logs below.
sys:12025-03-20 08:56:38.614 info Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 100% complete.
sys:12025-03-20 08:55:42.662 trace Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 90% complete.
sys:12025-03-20 08:55:06.492 trace Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 80% complete.
sys:12025-03-20 08:54:32.528 trace Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 70% complete.
sys:12025-03-20 08:54:01.077 trace Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 60% complete.
sys:12025-03-20 08:53:28.381 trace Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 50% complete.
sys:12025-03-20 08:52:49.632 trace Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 40% complete.
sys:12025-03-20 08:52:17.853 trace Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 30% complete.
sys:12025-03-20 08:51:42.564 trace Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 20% complete.
sys:12025-03-20 08:51:08.669 trace Firmware update for Bed1-ZBminiR, manufacturer:SONOFF, fileVersion:00001004 is 10% complete.
sys:12025-03-20 08:50:33.590 trace Starting firmware update for Bed1-ZBminiR, SONOFF from 00001002 to 00001004.
OK @kkossev I have tested Detached Relay mode. Short answer: there's something not quite working right, at least in terms of how its operating.
I:
I have DM'd you some logs...I turned on trace level logging so its quite detailed.
OK so an update to the 'falling of the mesh' issue.
I was up late last night troubleshooting.
when i went to bed around 1am, all devices (ZBMINIR2's and the ZBmicro) had fallen off the mesh, I power cycled them before hitting the pillow, and rebooted the hub for good measure.
when i woke up the next morning around 7am, all the devices were still online and working. (!)
since then of course there has been lots of disruption - i upgraded the firmware of all the ZBMINIR2's to 1.0.4, and powered off the light circuit to re-wire Bed1 ZBMINIR2 for detached relay testing.
interestingly though, the ZBmicro is still connected and operating normally.
fingers crossed.
I have tested all trigger modes now.
There are 2 warnings on the logs whenever I hit save from the Preferences page:
zigbee read private cluster 0xFC11 attribute 0x0001 error: Unsupported Attribute
zigbee response write private cluster 0xFC11 attribute error: Unsupported Attribute
I turned the lights off before setting up each mode.
I'm sending you the logs in private.
to close this out for the broader community, it appears like we won't be getting Detached Relay mode on these devices anytime soon - maybe not ever.
After going thru the logs Krassimir has determined that the 'non-standard acknowledgement' mechanism Sonoff decided to use prevents him being able to implement this feature.
now that @kkossev has figured out how to implement Detach Relay feature, I revisited this post to prevent folks stumbling on it and not reading on and realising that it does in fact work.
thanks again to @kkossev for his work on this driver.
Query: 'Delay Power On Time' Feature
I see there is a current state called Delayed Power On Time, which in one of my device's case has a value of 78, in another's case it is 33.
cheers!
Download the Hubitat app
