Zigbee Sonoff ZBBridge todo/wishlist

[s-hadinger]

Have you looked for this feature in other issues and in the docs?
Yes

Is your feature request related to a problem? Please describe.
This is a general Feature Request for short and mid-term features for Sonoff ZBBridge and Zigbee support.

Describe the solution you'd like
List below

Describe alternatives you've considered
See below

Additional context
This is a follow-up for #8583 and #9009

(Please, remember to close the issue when the problem has been addressed)

Here is a list of short-term and mid-term features for the Sonoff ZBBridge. I don't guarantee that they will be all implemented.

Short term:

• Fix device 0x0000 showing up in the WebGui and list of devices
• Set Extended Timeout for better reachability of sleepy devices (polling)
• Make the Green LED brighter
• Implement Identify cluster
• Sort devices in the Web UI
• Improve user feedback on EFR32 flashing

Mid Term:

• What should we do with the button on Sonoff ZBBridge? As the button is not easy to press, this should be handled via Rules
• Make the blue LED glow when permit join is active
• Use the I2C EEPROM to save device configuration, and make back-ups
• Auto-bind devices to the coordinator and usual clusters (zigbee2mqtt is already doing it)
• Auto-configure attribute reporting on usual attributes (zigbee2mqtt is already doing it)
• Include TLS/AWS IoT in the tasmota-zbbridge (because we have more than enough space for it)
• Automatically transform IAS (Intruder Alarm System) cluster to a more user-friendly type: ex: Occupancy instead of ZoneStatus
• Add option for some device to not be queried for state change (could create a network storm)
• Customize the timeout for Occupancy sensor Disarm Zigbee timer for Occupancy:0 #8202

Longer Term:

• Support for Green Power = battery-less devices that use the press on a button create enough energy to send a message (I'm not sure what EZSP is capable of doing)

Features we will not support

Because they would waste a lot of flash space and are niche features.

• TouchLink
• Zigbee device OTA upgrade

[MattWestb]

Here we go !!

First my comments for Short terms:

If fixing the device 0x0000 I can not longer using “ZbName 1 IKEA_BILLY_EZSP” for getting a nice list on the main menu. (better taking the Coordinator away as you have proposal).
For the LEDs and the EFR32 flash I think its possible doing more user friendly thing. More later under My Mid Terms.

My Short term suggestions:
It looks the pairing of Ikea bulbs is not complete paired (still slowly dimming until time out) and EZSP have al done and looks OK.
Is looks like some parameters missed that is needed for the bulb going from pairing mode to normal paired mode. Perhaps only cosmetic.

Battery status for Ikea devices, Both new and old motion sensor and the On/Off Switch don’t getting any battery status and very likely for the other devices in the “FAMELY” (“E1766” open/close remote, “E1524/E1810” remote control, “ICTC-G-1“ wireless dimmer and “E1744” SYMFONISK sound controller).

Saving “ZB Listen” for new created groups that being executed after the NCP is starting so not need running commands for getting messages from groups after restart.

Comments on Mid Term:
Using the EEPROM as backup of configuration its great but do it as no braking thing if not being presents like on Elelabs Zigbee adapters and so on.

Auto binding to default group and also for “remotes” to the default group then the device don’t have doing it self (the old Ikea MS is making one grope and the new don’t) and if there do then configuring “ZB Listen” for the group (or sniffing groups and auto configuring “ZB Listen”).
Attributes reporting and / or pulling status after restart of the NCP so getting a view of the system status and also then the system is running (periodical?).

The “Occupancy” thing. Don’t mix the “motion sensors” that sending light command “on with time off” an the real “Occupancy sensors” that sending “ True / false”. It have being more or less a ware in the deCONZ git then light steering is used and alarm and opposite and is miss implanted in the system (3 minutes auto reset of status then the (LL) sensor sending “on with time off 60 seconds) and the devs is only contra productive.

IAS I have not looking at but shod being my aria from my professional experience, but for the moment I living it for other to explore.

My Mid Term suggestions:
I have seeing that the Tasmota detecting that the NCP is coming on line (normally VCC was disconnected after ESP flashing and configuring for not interfering with the serial flashing) but only reporting it and do not trying to stating it. I think its also pretty easy detecting the bootloader status and if the bootloader is in downloading mode then the NCP is of line so way not using that ?
Then the EZSP its not started its good showing that status on the status LED. And also trying start / restart the NCP if not stopped by user wold being god (perhaps watchdog?)

12:07:44 MQT: tele/tasmota_B3C82A/RESULT = {"ZbState":{"Status":99,"Message":"Failed state","Error":"Unknown","Code":139}}

NCP online after tasmota is started and timed out (the NCP was unpowered).

LED / bottom / EZSP status.
The LED can having different pattern for different modes like EZSP in bootloader mode (Slowly long on short off), Flash download in progress (fast blinking), NCP fatal error / offline (SOS = - - - -- -- -- - - -), pairing is enabled and so on.
The bottom can also have mullite purposes like 2 seconds = paring mode for 2 minutes, 1 fast = ending pairing mode (if is in pairing mode), 5 seconds toggle EZSP bootloader mode and NCP mode, 3 fast = sending 1 to bootloader then being in bootloader mode (Starting XModem server for download) and so on.

Its possible making very nice and good combinations that the user can using if making it good.
Look wat functions and feedback the user normally needs and making priority from that.

My Longer Term suggestions:
Try holding the system clean and not making one mess of it.
Don’t close doors then not necessarily from the tactical point.
The first priority is to working on the Sonoff bridge and then its possible leaving the door open for other hardware like Elelabs and other module by making no braking things for them then its possible.
For doing that you need thinking more global and trying keeping perspective and then diving in the details with the global perspective in mind.

One very good example of doing things wrong in the past is deCONZ.
They was starting as very good light steering system (LL) and then trying converting it to one universal ZB3 HA system and have messing things up.
One new bad example: deCONZ was more or less implanting the new “Opple switches” as HA and was making it more or less unusable for lights (Its ZB3 and can do both as Z2M have done). That is for my braking thing then its rear finding dissent light switches that also is working offline, and its gets many “HA” switches on the market that working well).
IAS and GP sounds great in the long run and opening many doors for the future!!
For IAS and Lights (x LL) profiles in ZB3 is autonomy A and O so try not braking that.
Many users have not experience coming home in late night in the winter then its dark outside and the light is not working at all because of corrupted database (deCONZ / HA) or SD-card is broken. I have getting both but have building all autonomy for not being left in the dark.

I have 3 large things but they need more time for writing so they is coming later and you is not liking 2 of them.

Sorry for not having time for doing more nice text formatting.

Edit: Added NCP Online message.

[MattWestb]

Then building larger systems it can being good implanting node identifying funktion command in the NCP (node cluster 0x0003 = Identify) so its being easier finding the right bulb in the mesh.
My suggested priority is between short and medium.

Implanted and merged in #9080

[duczz]

SONOFF SNZB-02 - ZigBee temperature and humidity sensor not integrated?

17:51:42 CMD: ZbPermitJoin 1 17:51:42 SRC: WebConsole from 192.168.178.21 17:51:42 CMD: Group 0, Index 1, Command "ZBPERMITJOIN", Data "1" 17:51:42 ZIG: ZbEZSPSend 22003C 17:51:42 ZIG: ZbEZSPSend 3600FCFF00003600000000000000021E0103023C01 17:51:42 MQT: stat/tasmota_05DF17/RESULT = {"ZbPermitJoin":"Done"} 17:51:42 ZIG: {"ZbEZSPReceived":"220000"} 17:51:42 MQT: tele/tasmota_05DF17/RESULT = {"ZbState":{"Status":21,"Message":"Pairing mode enabled"}} 17:51:42 ZIG: NAK, resending packet 0 17:51:42 ZIG: {"ZbEZSPReceived":"3600008F"} 17:51:42 ZIG: {"ZbEZSPReceived":"450005000036000000000000008FFF000000FFFF03023C01"} 17:51:42 ZIG: Internal ZDO message 0x0036 sent from 0x0000 (broadcast) 17:51:43 ZIG: {"ZbEZSPReceived":"3F0006FCFF000036000000000000008F010000"} 17:51:44 ZIG: {"ZbEZSPReceived":"2300000111745195D51C004B120004"} 17:51:44 ZIG: {"ZbEZSPReceived":"240011745195D51C004B120001000000"} 17:51:45 MQT: tele/tasmota_05DF17/RESULT = {"ZbState":{"Status":34,"IEEEAddr":"0x00124B001CD59551","ShortAddr":"0x7411","ParentNetwork":"0x0000","Status":1,"Decision":0}} 17:51:45 ZIG: {"ZbEZSPReceived":"450004000013000000000000000084BD1174FFFF0C0011745195D51C004B12008002"} 17:51:45 MQT: tele/tasmota_05DF17/RESULT = {"ZbState":{"Status":30,"IEEEAddr":"0x00124B001CD59551","ShortAddr":"0x7411","PowerSource":false,"ReceiveWhenIdle":false,"Security":false}} 17:51:45 ZIG: ZbEZSPSend 340000117400000500000040010000030103031174 17:51:45 ZIG: {"ZbEZSPReceived":"34000092"} 17:51:46 ZIG: {"ZbEZSPReceived":"3F0006FDFF0000130000000000000000000000"} 17:51:46 ZIG: {"ZbEZSPReceived":"3F000011740000050000004001000092010000"} 17:51:46 ZIG: {"ZbEZSPReceived":"450000000005800000000100000184BD1174FFFF0603001174010102"} 17:51:46 MQT: tele/tasmota_05DF17/RESULT = {"ZbState":{"Status":32,"ActiveEndpoints":["0x01"]}} 17:51:46 ZIG: ZbEZSPSend 34000011740401000001014001000001010700010004000500 17:51:46 ZIG: {"ZbEZSPReceived":"34000093"} 17:51:47 ZIG: {"ZbEZSPReceived":"3F000011740401000001014001000093010000"} 17:51:47 ZIG: {"ZbEZSPReceived":"450000040100000101000100000288BE1174FFFF1818010104000042076557654C696E6B05000042045448303102"} 17:51:47 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":0,"srcaddr":"0x7411","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":55,"securityuse":0,"seqnumber":2,"fc":"0x18","manuf":"0x0000","transact":1,"cmdid":"0x01","payload":"04000042076557654C696E6B050000420454483031"}} 17:51:47 ZIG: ZbZCLRawReceived: {"0x7411":{"0000/0004":"eWeLink","0000/0005":"TH01"}} 17:51:47 MQT: tele/tasmota_05DF17/SENSOR = {"ZbReceived":{"0x7411":{"Device":"0x7411","Manufacturer":"eWeLink","ModelId":"TH01","Endpoint":1,"LinkQuality":55}}} 17:51:49 ZIG: ZbFlashStore 012011745195D51C004B120001010000FFFF54483031006557654C696E6B0000FF 17:51:49 ZIG: Zigbee Devices Data store in Flash (0x402FF800 - 33 bytes)

[s-hadinger]

I don't have a SONOFF SNZB-02, I guess you need to both Bind and ask for Attribute Reporting.

Try:

ZbBind {"Device":"0x7411","Cluster":"Temperature"}
ZbBind {"Device":"0x7411","Cluster":"Humidity"}

Then:

ZbSend {"Device":"0x7411","Config":{"Temperature":{"MinInterval":60,"MaxInterval":600,"ReportableChange":1}}}
ZbSend {"Device":"0x7411","Config":{"Humidity":{"MinInterval":60,"MaxInterval":600,"ReportableChange":5}}}

[duczz]

Thanks for your fast reply, following error on the first two commands: ZbBind":"Unknown source device"

[s-hadinger]

Sorry for the typo. It's "Device"

[duczz]

Following Output in the Console:
18:34:58 CMD: .ZbBind {"Device":"0x7411","Cluster":"Temperature"} 18:34:58 SRC: WebConsole from 192.168.178.21 18:35:02 CMD: ZbBind {"Device":"0x7411","Cluster":"Humidity"} 18:35:02 SRC: WebConsole from 192.168.178.21 18:35:02 CMD: Group 0, Index 1, Command "ZBBIND", Data "{"Device":"0x7411","Cluster":"Humidity"}" 18:35:02 ZIG: ZbEZSPSend 3400001174000021000000400100000D01160D5195D51C004B120001050403AFA342FEFF23A46001 18:35:02 MQT: stat/tasmota_05DF17/RESULT = {"ZbBind":"Done"} 18:35:02 ZIG: {"ZbEZSPReceived":"340000A2"} 18:35:07 CMD: ZbSend {"Device":"0x7411","Config":{"Temperature":{"MinInterval":60,"MaxInterval":600,"ReportableChange":1}}} 18:35:07 SRC: WebConsole from 192.168.178.21 18:35:07 CMD: Group 0, Index 1, Command "ZBSEND", Data "{"Device":"0x7411","Config":{"Temperature":{"MinInterval":60,"MaxInterval":600,"ReportableChange":1}}}" 18:35:07 ZIG: guessing endpoint 1 18:35:07 ZIG: ZbEZSPSend 34000011740401020401014001000005010D100506000000293C0058026400 18:35:07 MQT: stat/tasmota_05DF17/RESULT = {"ZbSend":"Done"} 18:35:07 ZIG: {"ZbEZSPReceived":"340000A3"} 18:35:10 ZIG: {"ZbEZSPReceived":"8000421174"} 18:35:10 MQT: tele/tasmota_05DF17/RESULT = {"ZbRouteError":{"ShortAddr":"0x7411","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}} 18:35:12 CMD: ZbSend {"Device":"0x7411","Config":{"Humidity":{"MinInterval":60,"MaxInterval":600,"ReportableChange":5}}} 18:35:12 SRC: WebConsole from 192.168.178.21 18:35:12 CMD: Group 0, Index 1, Command "ZBSEND", Data "{"Device":"0x7411","Config":{"Humidity":{"MinInterval":60,"MaxInterval":600,"ReportableChange":5}}}" 18:35:12 ZIG: guessing endpoint 1 18:35:12 ZIG: ZbEZSPSend 34000011740401050401014001000006010D100606000000213C005802F401 18:35:12 MQT: stat/tasmota_05DF17/RESULT = {"ZbSend":"Done"} 18:35:12 ZIG: {"ZbEZSPReceived":"340000A4"} 18:35:15 ZIG: {"ZbEZSPReceived":"8000421174"} 18:35:15 MQT: tele/tasmota_05DF17/RESULT = {"ZbRouteError":{"ShortAddr":"0x7411","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}

[MattWestb]

I dont being good in reading logs but the last 18:35:15 MQT: tele/tasmota_05DF17/RESULT = {"ZbRouteError {"ShortAddr":"0x7411","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}
is normally then its end device that is sleeping (like my Ikea motion sensors).
Try waking the device up before you is sending the command so its not is in sleep mode and can receive it.

[duczz]

That's it, Thanks, no Errors now.
But no Informations

[MattWestb]

You getting the "extended" infos in the console or if you have configured MQTT.
Like this for Aqara weather: 18:00:48 RSL: SENSOR = {"ZbReceived":{"0xD991":{"Device":"0xD991","Name":"LUMI_THP","Temperature":27.84,"Humidity":59.47,"PressureUnit":"hPa","Pressure":996,"PressureScale":-1,"PressureScaledValue":9960,"Endpoint":1,"LinkQuality":150}}}

You can naming the device with ZbName <Device>, Name

[duczz]

i have nothing like this in the console and on MQTT are only the Bridge states
I can show it via Teamviewer?

[MattWestb]

Then its best waiting until s-hadinger coming back after his dinnering.

[s-hadinger]

I need to look at the logs for the 4 commands to make sure they were taken into account. Use weblog 3 and paste the logs. Press the button to wake up the device before each command.
Thx

[duczz]

20:27:46 CMD: weblog 3 20:27:46 SRC: WebConsole from 192.168.178.21 20:27:46 CMD: Group 0, Index 1, Command "WEBLOG", Data "3" 20:27:46 MQT: stat/tasmota_05DF17/RESULT = {"WebLog":3} 20:27:52 ZIG: {"ZbEZSPReceived":"3F0000117404010504010140000000B0016600"} 20:27:58 CMD: ZbBind {"Device":"0x7411","Cluster":"Temperature"} 20:27:58 SRC: WebConsole from 192.168.178.21 20:27:58 CMD: Group 0, Index 1, Command "ZBBIND", Data "{"Device":"0x7411","Cluster":"Temperature"}" 20:27:58 ZIG: ZbEZSPSend 340000117400002100000040010000140116145195D51C004B120001020403AFA342FEFF23A46001 20:27:58 MQT: stat/tasmota_05DF17/RESULT = {"ZbBind":"Done"} 20:27:58 ZIG: {"ZbEZSPReceived":"340000B1"} 20:28:03 CMD: ZbBind {"Device":"0x7411","Cluster":"Humidity"} 20:28:03 SRC: WebConsole from 192.168.178.21 20:28:03 CMD: Group 0, Index 1, Command "ZBBIND", Data "{"Device":"0x7411","Cluster":"Humidity"}" 20:28:03 ZIG: ZbEZSPSend 340000117400002100000040010000150116155195D51C004B120001050403AFA342FEFF23A46001 20:28:03 MQT: stat/tasmota_05DF17/RESULT = {"ZbBind":"Done"} 20:28:03 ZIG: {"ZbEZSPReceived":"340000B2"} 20:28:08 CMD: ZbSend {"Device":"0x7411","Config":{"Temperature":{"MinInterval":60,"MaxInterval":600,"ReportableChange":1}}} 20:28:08 SRC: WebConsole from 192.168.178.21 20:28:08 CMD: Group 0, Index 1, Command "ZBSEND", Data "{"Device":"0x7411","Config":{"Temperature":{"MinInterval":60,"MaxInterval":600,"ReportableChange":1}}}" 20:28:08 ZIG: guessing endpoint 1 20:28:08 ZIG: ZbEZSPSend 3400001174040102040101400100000D010D100D06000000293C0058026400 20:28:08 MQT: stat/tasmota_05DF17/RESULT = {"ZbSend":"Done"} 20:28:08 ZIG: {"ZbEZSPReceived":"340000B3"} 20:28:13 CMD: ZbSend {"Device":"0x7411","Config":{"Humidity":{"MinInterval":60,"MaxInterval":600,"ReportableChange":5}}} 20:28:13 SRC: WebConsole from 192.168.178.21 20:28:13 CMD: Group 0, Index 1, Command "ZBSEND", Data "{"Device":"0x7411","Config":{"Humidity":{"MinInterval":60,"MaxInterval":600,"ReportableChange":5}}}" 20:28:13 ZIG: guessing endpoint 1 20:28:13 ZIG: ZbEZSPSend 3400001174040105040101400100000E010D100E06000000213C005802F401 20:28:13 MQT: stat/tasmota_05DF17/RESULT = {"ZbSend":"Done"} 20:28:13 ZIG: {"ZbEZSPReceived":"340000B4"} 20:28:26 ZIG: {"ZbEZSPReceived":"3F0000117400002100000040000000B1016600"} 20:28:31 ZIG: {"ZbEZSPReceived":"3F0000117400002100000040000000B2016600"} 20:28:36 ZIG: {"ZbEZSPReceived":"3F0000117404010204010140000000B3016600"} 20:28:40 ZIG: {"ZbEZSPReceived":"3F0000117404010504010140000000B4016600"}

[s-hadinger]

Your device didn't receive the commands. You should have received acknowledgement for the commands. I suppose it was sleeping

[duczz]

Some tries later and an iobroker script for pairing and zbbind Commands it works fine, perhaps i was sometime to fast/slow.
Is it possible to add the Battery, Temp and Humidity states in the Tasmota Overview? (For Battery i currently not have an Command)

[techman83]

Thanks for the instructions @s-hadinger, took a long press (until the LED flashed) for the commands to be sent to my already paired SNZB-02. Guessing it goes into a config mode of sorts after initial pairing.

Update: Had to set ZbPermitJoin 1, press button and then send the commands before it decided to actually start sending the data. Works now though!

[s-hadinger]

@MattWestb I actually added the Identify cluster because it was very easy :) #9080

[MattWestb]

I was thinking that and i'm not disappointed :-)))
Thanks very much !!
Now our Master firmware maker @grobasoz can installing his 30 IKEA lights (upside down as normal for the Aussie from our point of view) and identifying them easy.

I cant testing for the moment then I is looking on the bellows ZB3 connecting problems.

Keep coding hard ;-)

[duczz]

Is this for Batterie not possible? He dont knows "battery"

ZbBind {"Device":"0x7411","Cluster":"battery"}

Then:

ZbSend {"Device":"0x7411","Config":{"battery":{"MinInterval":60,"MaxInterval":600,"ReportableChange":1}}}

[s-hadinger]

It's BatteryVoltage

[duczz]

Thanks works, but Battery will not send via MQTT

[s-hadinger]

You can also try BatteryPercentage

[duczz]

On Tasmota it works, but he dont send it to my MQTT Broker

[tric111]

Currently, when using the Philips outdoor motion sensor SML002 in the same way as described in #8192, the internal red LED flashes when motion is detected. Apparently this is a "fault code" that occurs because the sensor does not receive a response to the occupancy message: Koenkk/zigbee2mqtt#897
This issue seems to be related: Koenkk/zigbee-herdsman#10

20:43:17 ZIG: {"ZbEZSPReceived2":"37E6900145000004010604020100010000A4A4C58EE2FFFF0708A40A0000180102"}
20:43:17 ZIG: ZbEZSPSentRaw 84
20:43:17 ZIG: {"ZbEZSPReceived":"45000004010604020100010000A4A4C58EE2FFFF0708A40A0000180102"}
20:43:17 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xE28E","srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":74,"securityuse":0,"seqnumber":164,"fc":"0x08","manuf":"0x0000","transact":164,"cmdid":"0x0A","payload":"00001801"}}
20:43:17 ZIG: ZbZCLRawReceived: {"0xE28E":{"0406/0000":1}}
20:43:17 RSL: SENSOR = {"ZbReceived":{"0xE28E":{"Device":"0xE28E","Name":"HueMotion1","Occupancy":1,"Endpoint":2,"LinkQuality":74}}}
20:43:18 ZIG: {"ZbEZSPReceived2":"47E690014500040401060402FF00000000A580BC8EE2FFFF0718A50A0000180102"}
20:43:18 ZIG: ZbEZSPSentRaw 85
20:43:18 ZIG: {"ZbEZSPReceived":"4500040401060402FF00000000A580BC8EE2FFFF0718A50A0000180102"}
20:43:18 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xE28E","srcendpoint":2,"dstendpoint":255,"wasbroadcast":1,"LinkQuality":50,"securityuse":0,"seqnumber":165,"fc":"0x18","manuf":"0x0000","transact":165,"cmdid":"0x0A","payload":"00001801"}}
20:43:18 ZIG: ZbZCLRawReceived: {"0xE28E":{"0406/0000":1}}
20:43:19 RSL: SENSOR = {"ZbReceived":{"0xE28E":{"Device":"0xE28E","Name":"HueMotion1","Occupancy":1,"Endpoint":2,"LinkQuality":50}}}
20:43:19 ZIG: {"ZbEZSPReceived2":"57E690013F0006FCFF0401060402FF00000000A5000000"}
20:43:19 ZIG: ZbEZSPSentRaw 86
20:43:19 ZIG: {"ZbEZSPReceived":"3F0006FCFF0401060402FF00000000A5000000"}
20:43:20 WIF: Checking connection...
20:43:27 ZIG: {"ZbEZSPReceived2":"67E6900145000004010604020100010000A678BA8EE2FFFF0708A60A0000180002"}
20:43:27 ZIG: ZbEZSPSentRaw 87
20:43:27 ZIG: {"ZbEZSPReceived":"45000004010604020100010000A678BA8EE2FFFF0708A60A0000180002"}
20:43:27 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xE28E","srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":45,"securityuse":0,"seqnumber":166,"fc":"0x08","manuf":"0x0000","transact":166,"cmdid":"0x0A","payload":"00001800"}}
20:43:27 ZIG: ZbZCLRawReceived: {"0xE28E":{"0406/0000":0}}
20:43:27 RSL: SENSOR = {"ZbReceived":{"0xE28E":{"Device":"0xE28E","Name":"HueMotion1","Occupancy":0,"Endpoint":2,"LinkQuality":45}}}
20:43:28 ZIG: {"ZbEZSPReceived2":"77E690014500040401060402FF00000000A77CBB8EE2FFFF0718A70A0000180002"}
20:43:28 ZIG: ZbEZSPSentRaw 80
20:43:28 ZIG: {"ZbEZSPReceived":"4500040401060402FF00000000A77CBB8EE2FFFF0718A70A0000180002"}
20:43:28 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xE28E","srcendpoint":2,"dstendpoint":255,"wasbroadcast":1,"LinkQuality":47,"securityuse":0,"seqnumber":167,"fc":"0x18","manuf":"0x0000","transact":167,"cmdid":"0x0A","payload":"00001800"}}
20:43:28 ZIG: ZbZCLRawReceived: {"0xE28E":{"0406/0000":0}}
20:43:29 RSL: SENSOR = {"ZbReceived":{"0xE28E":{"Device":"0xE28E","Name":"HueMotion1","Occupancy":0,"Endpoint":2,"LinkQuality":47}}}
20:43:29 ZIG: {"ZbEZSPReceived2":"07E690013F0006FCFF0401060402FF00000000A7000000"}
20:43:29 ZIG: ZbEZSPSentRaw 81
20:43:29 ZIG: {"ZbEZSPReceived":"3F0006FCFF0401060402FF00000000A7000000"}

[duczz]

any news for my issue?

[s-hadinger]

@duczz You stated earlier that it worked on Tasmota. There's not much more I can do.

Btw this Github issue is not meant to solve individual issues, please connect to Discord or open a specific Github issue.

[MattWestb]

For your 2 points in the to do list:

• Automatically transform IAS (Intruder Alarm System) cluster to a more user-friendly type: ex: Occupancy instead of ZoneStatus
• Customize the timeout for Occupancy sensor Disarm Zigbee timer for Occupancy:0 #8202

The newes document i have finding on the team "Occupancy".

ZigBee Lighting & Occupancy
Device Specification
Version 1.0
ZigBee Document 15-0014-05
February 24th, 2016

I don't knowing if its older the the latest ZCL that you have getting, if then its the newer ZCL that is the master and if not this is the converting document for Light Link to Zigbee PRO = ZB3.

The #8202 is it one light controlling device, HA sensor or one IAS device ?
Keep the device types apart and don't messing it up mixing the functions between the types and making all confusing for the users (typical users is complaining about Ikeas motion sensor is not reporting light level and occupancy false then its not one light/occupancy sensor its one "On/off sensor" for lights).

I don't have reading the IAS but the name "Occupancy " is reserved for lights components in Zigbee and "Zone" or "Area" is the real terminology then working with intruder alarm systems.

The interesting thing is the definition of "26 On/off sensor" In that category is both Ikeas Motion sensors and also is you have one light sensor that is turning the light on then its dark.

The "13 Occupancy sensor" is (normally) not direkt controlling lights and not sending any commands only possible reporting attribute "Occupancy" true / false.

For my the most interesting is the "25 Control bridge" that can being used as one universal transmitter of commands to lights in one Zigbee networks as one router.

Also attribute reporting of status (on/off Light level and so on) is mandatory for all types of lights and plugs but not for controlling devices.
So its make sense that the Ikeas ZB3 lights and plugs devices is reporting status and not the controllers. And then the coordinator is listen on the group commands its being sended to the groups from the controllers its getting all status from the devices in the zigbee mesh.
So in ZB3 lights is reporting there status and not being pulled for not flooding the zigbee mesh.
And the controlling devices do not reporting attribute or being pulled for there status (only "operating" status like battery level is normally reported).
I wonder how Philips have getting there ZB3 certificate for there bulbs (The HUE bridge is still LL certified as Ikea) .
I have not reading the HA and IAS part of the ZB3 / ZCL so i don't knowing if its reporting attributes or pulling for getting status of HA and IAS devices in ZB3.

[MattWestb]

I have finding one "equivalent" ZNCP by LIDL as in SonOff Zigbee Bridge !!

But I think its not for Stephan then its needs soldering of the SWD. SWO. RX and TX on the small pads.
Plus is its possible modding for external antenna if needed.

By the way you is getting 2 meters RGBCT silicon tube LED strip in the package then bying the christmas ham :-)))

[s-hadinger]

Nice design. There is no plan to port Tasmota to Cortex-M33, anyways 768kb of flash for both Tasmota and EZSP is too small.

I'm afraid it's only good for a router, zigbee device or maybe a tcp bridge.

[bogorad]

Not sure where to keep posting zigbee-specific problems, so forgive me if it's the wrong place. Here's how sensors are dying off. Sometimes they work for days/weeks, then boom. This is an Aqara motion sensor:

Same thing happened to a door sensor, a day later:

Using version 9.1.0

I realize I'll probably have to keep mqttlog 3 for a couple of days.

[bogorad]

Got the logs: https://pastebin.com/Ncs6qKsT

Both sensors sent something that made the controller to output "Xiaomi_64" and that was it.

[s-hadinger]

This means that Tasmota doesn't know the modelid of the device which doesn't make sense. Is the gui working fine?

[bogorad]

Everything including the GUI is working great. But the sensors suddenly stop working. I've got several controllers, tried this on each one - it's always the same story. Sometimes it works great for days, but then boom - no signal from sensors. This time I was ready with mqttlog 3

[s-hadinger]

Maybe you can try getting back to weblog 2 and type zbmap. Be aware that there are many lines in the output. Please share the result

[bogorad]

@s-hadinger here goes:

20:45:11 SRC: Backlog
20:45:11 CMD: Group 0, Index 1, Command "ZBSTATUS", Data ""
20:45:11 MQT: housematix/zigbee/A4CF12D7FBDA/RESULT = {"ZbStatus1":[{"Device":"0xC4D7","Name":"00158D0004ABC815"},{"Device":"0xE5BD","Name":"00158D0005474AD6"}]}
20:45:41 SRC: MQTT
20:45:41 CMD: Group 0, Index 1, Command "BACKLOG", Data "zbmap 0xc4d7"
20:45:41 SRC: Backlog
20:45:41 CMD: Group 0, Index 1, Command "ZBMAP", Data "0xc4d7"
20:45:41 ZIG: ZbEZSPSend 340000D7C4000031000000400100001001021000
20:45:41 MQT: housematix/zigbee/A4CF12D7FBDA/RESULT = {"ZbMap":"Done"}
20:45:41 ZIG: {"ZbEZSPReceived":"340000C8"}
20:45:49 ZIG: {"ZbEZSPReceived":"800042D7C4"}
20:45:49 MQT: housematix/zigbee/A4CF12D7FBDA/RESULT = {"ZbRouteError":{"ShortAddr":"0xC4D7","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}
20:45:58 ZIG: {"ZbEZSPReceived":"800042D7C4"}
20:45:58 MQT: housematix/zigbee/A4CF12D7FBDA/RESULT = {"ZbRouteError":{"ShortAddr":"0xC4D7","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}
20:46:08 ZIG: {"ZbEZSPReceived":"800042D7C4"}
20:46:08 MQT: housematix/zigbee/A4CF12D7FBDA/RESULT = {"ZbRouteError":{"ShortAddr":"0xC4D7","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}
20:46:08 ZIG: {"ZbEZSPReceived":"45000000003880000040010000C9FF000000FFFF1B000000F8FF071B00070010C1C6C8CCC5D3BCBFDAACC0CDBAB7C7C6"}
20:46:08 ZIG: Internal ZDO message 0x8038 sent from 0x0000
20:46:09 ZIG: {"ZbEZSPReceived":"3F0000D7C400003100000040010000C8016600"}

[bogorad]

BTW I get a lot of MAC_INDIRECT_TIMEOUT when paring and re-pairing Aqara devices. But then they work fine.

[bogorad]

@s-hadinger

This means that Tasmota doesn't know the modelid of the device which doesn't make sense. Is the gui working fine?

I think I localized the issue. I took two controllers, set up in the exact same way (except for PANid of course). Paired each one with two sensors: Aqara door & Aqara motion.

The only difference was the SetOption112 and SetOption100. The controller with SetOption112 1 and SetOption100 1 loses the sensors. The controller with SetOption112 0 and SetOption100 0 does not.

So it looks like the problem is in the specific code dealing with incoming ZigBee messages when 100/112 is on.

[s-hadinger]

@bogorad Please use the latest Tasmota version and check the Zigbee map - you can paste them here or on Discord.

SO112 and SO100 only change the formatting of the MQTT messages, and has nothing to do with zigbee internals.

[bogorad]

@s-hadinger I did

#9051 (comment)

[s-hadinger]

I mean the diagram, not the logs.

[bogorad]

I mean the diagram, not the logs.

Sorry, misunderstood. Will do and ping you on Discord.

[Bibinsa]

Strange behaviour (9.2.0 and older), don't know if it's like @bogorad comment.

With SetOption112 1 Sensor MQTT fulltopic is lost.
We cannot use friendly_name in MQTT topic :

11:17:31 CMD: so112
11:17:31 MQT: home/tasmota/zbbridge-1/stat/RESULT = {"SetOption112":"OFF"}
11:18:25 CMD: so112 1
11:18:25 MQT: home/tasmota/zbbridge-1/stat/RESULT = {"SetOption112":"ON"}
11:18:30 MQT: tele/aq_cube/SENSOR = {"aq_cube":{"Device":"0x4A7F","Name":"aq_cube","MultiInValue":2,"Endpoint":2,"LinkQuality":79}}
11:18:30 MQT: tele/aq_cube/SENSOR = {"aq_cube":{"Device":"0x4A7F","Name":"aq_cube","MultiInValue":108,"Endpoint":2,"LinkQuality":79}}
11:18:35 MQT: tele/aq_cube/SENSOR = {"aq_cube":{"Device":"0x4A7F","Name":"aq_cube","Aqara_FF05":280,"AnalogValue":-14.16,"Endpoint":3,"LinkQuality":81}}
11:18:35 MQT: tele/aq_cube/SENSOR = {"aq_cube":{"Device":"0x4A7F","Name":"aq_cube","Aqara_FF05":500,"AnalogValue":-77.86,"Endpoint":3,"LinkQuality":81}}
11:18:58 CMD: so112 0
11:18:58 MQT: home/tasmota/zbbridge-1/stat/RESULT = {"SetOption112":"OFF"}
11:21:36 MQT: home/tasmota/zbbridge-1/tele/4A7F/SENSOR = {"aq_cube":{"Device":"0x4A7F","Name":"aq_cube","MultiInValue":2,"Endpoint":2,"LinkQuality":47}}
11:21:36 MQT: home/tasmota/zbbridge-1/tele/4A7F/SENSOR = {"aq_cube":{"Device":"0x4A7F","Name":"aq_cube","MultiInValue":96,"Endpoint":2,"LinkQuality":47}}
11:21:44 CMD: so112 1
11:21:44 MQT: home/tasmota/zbbridge-1/stat/RESULT = {"SetOption112":"ON"}
11:21:50 MQT: tele/aq_cube/SENSOR = {"aq_cube":{"Device":"0x4A7F","Name":"aq_cube","MultiInValue":65,"Endpoint":2,"LinkQuality":84}}
11:21:55 CMD: so112 0
11:21:55 MQT: home/tasmota/zbbridge-1/stat/RESULT = {"SetOption112":"OFF"}
11:22:00 MQT: home/tasmota/zbbridge-1/tele/4A7F/SENSOR = {"aq_cube":{"Device":"0x4A7F","Name":"aq_cube","MultiInValue":75,"Endpoint":2,"LinkQuality":68}}

[bogorad]

With SetOption112 1 Sensor MQTT fulltopic is lost.
We cannot use friendly_name in MQTT topic :

Yes, the same. I just worked around it.

[arendst]

Pls report the output of commands fulltopic, topic and grouptopic.

From what I see above I expect this:

{"FullTopic":"%topic%/%prefix%/"}
{"Topic":"home/tasmota/zbbridge-1"}

So the SO112 0 implementation regards fulltopic and constructs a fixed topic as

home/tasmota/zbbridge-1/tele/4A7F/SENSOR

by adding the zigbee shortaddress (4A7F) between fulltopic and RESULT/SENSOR.

The current SO112 1 implementation disregards fulltopic and constructs a fixed topic as

%prefix%/zigbeefriendlyname/SENSOR

[bogorad]

The current SO112 1 implementation disregards fulltopic and constructs a fixed topic as

Yes, this is the observed behavior. But is this right? Shouldn't it follow the global rules?

[arendst]

Shouldn't it follow the global rules?

What are in your eyes the global rules? Pls provide a result you would expect.

[bogorad]

What are in your eyes the global rules? Pls provide a result you would expect.

Same as with SO112 0. Consider:

topic=%012X
fulltopic=zig/%topic%/

SO112 0 I'm getting:

12:28:59 MQT: zig/A4CF12D7F8BA/EB3F/SENSOR = {"ZbReceived":{"0xEB3F":{"Device":"0xEB3F","Name":"office_motion_main","Occupancy":0}}}

SO112 1 I'd expect to get:

12:28:59 MQT: zig/office_motion_main/SENSOR = {"ZbReceived":{"0xEB3F":{"Device":"0xEB3F","Name":"office_motion_main","Occupancy":0}}}

[Bibinsa]

Pls report the output of commands fulltopic, topic and grouptopic.

12:36:57 MQT: home/tasmota/zbbridge-1/stat/RESULT = {"FullTopic":"home/tasmota/%topic%/%prefix%/"}
12:36:57 MQT: home/tasmota/zbbridge-1/stat/RESULT = {"Topic":"zbbridge-1"}
12:36:58 MQT: home/tasmota/zbbridge-1/stat/RESULT = {"GroupTopic1":"tasmotas","GroupTopic2":"","GroupTopic3":"","GroupTopic4":""}

[arendst]

Your fulltopic is wrong as it ALWAYS needs %prefix% to distinguish commands from status messages.

If SO112 0 results in zig/A4CF12D7F8BA/EB3F/SENSOR then SO112 1 would result in zig/A4CF12D7F8BA/EB3F/office_motion_main/SENSOR which makes sense.

Anyway. I have a solution which does indeed the above:

12:38:38.689 CMD: fulltopic
12:38:38.696 MQT: zbbridge1/stat/RESULT = {"FullTopic":"%topic%/%prefix%/"}
12:38:49.739 CMD: so112 0
12:38:49.745 MQT: zbbridge1/stat/RESULT = {"SetOption112":"OFF"}
12:38:51.609 MQT: zbbridge1/508B/tele/SENSOR = {"ZbReceived":{"Tradfri4":{"Device":"0x508B","Name":"Tradfri4","0006!02":"","Power":2,"Endpoint":1,"LinkQuality":94}}}
12:38:57.588 CMD: so112 1
12:38:57.595 MQT: zbbridge1/stat/RESULT = {"SetOption112":"ON"}
12:39:18.984 MQT: zbbridge1/Tradfri4/tele/SENSOR = {"ZbReceived":{"Tradfri4":{"Device":"0x508B","Name":"Tradfri4","0006!02":"","Power":2,"Endpoint":1,"LinkQuality":76}}}

[arendst]

And with @Bibinsa fulltopic:

12:44:54.070 CMD: fulltopic
12:44:54.077 MQT: home/tasmota/zbbridge1/stat/RESULT = {"FullTopic":"home/tasmota/%topic%/%prefix%/"}
12:44:58.719 CMD: so112
12:44:58.726 MQT: home/tasmota/zbbridge1/stat/RESULT = {"SetOption112":"ON"}
12:45:00.896 MQT: home/tasmota/zbbridge1/Tradfri4/tele/SENSOR = {"ZbReceived":{"Tradfri4":{"Device":"0x508B","Name":"Tradfri4","0006!02":"","Power":2,"Endpoint":1,"LinkQuality":84}}}
12:45:07.308 CMD: so112 0
12:45:07.315 MQT: home/tasmota/zbbridge1/stat/RESULT = {"SetOption112":"OFF"}
12:45:09.001 MQT: home/tasmota/zbbridge1/508B/tele/SENSOR = {"ZbReceived":{"Tradfri4":{"Device":"0x508B","Name":"Tradfri4","0006!02":"","Power":2,"Endpoint":1,"LinkQuality":79}}}

[bogorad]

Your fulltopic is wrong as it ALWAYS needs %prefix% to distinguish commands from status messages.

Well, I don't really care about the tele/stat distinction, I pay attention to the RESULT/SENSOR part, and it works just fine. In my configuration the commands still work - zig/A4CF12D7F8BA/cmnd/backlog etc.

But I get your solution and thank you!