Tasmota 🚀 - Zigbee Sonoff ZBBridge todo/wishlist

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 on 9 Aug 2020

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

MattWestb on 10 Aug 2020

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)

duczz on 11 Aug 2020

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

s-hadinger on 11 Aug 2020

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

duczz on 11 Aug 2020

Sorry for the typo. It's "Device"

s-hadinger on 11 Aug 2020

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"}}

duczz on 11 Aug 2020

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.

MattWestb on 11 Aug 2020

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

duczz on 11 Aug 2020

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

MattWestb on 11 Aug 2020

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

duczz on 11 Aug 2020

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

MattWestb on 11 Aug 2020

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

s-hadinger on 11 Aug 2020

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"}

duczz on 11 Aug 2020

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

s-hadinger on 11 Aug 2020

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)

duczz on 11 Aug 2020

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!

techman83 on 12 Aug 2020

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

s-hadinger on 13 Aug 2020

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 ;-)

MattWestb on 13 Aug 2020

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

duczz on 13 Aug 2020

It's BatteryVoltage

s-hadinger on 13 Aug 2020

Thanks works, but Battery will not send via MQTT

duczz on 13 Aug 2020

You can also try BatteryPercentage

s-hadinger on 13 Aug 2020

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

duczz on 13 Aug 2020

Currently, when using the Philips outdoor motion sensor SML002 in the same way as described in https://github.com/arendst/Tasmota/issues/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: https://github.com/Koenkk/zigbee2mqtt/issues/897
This issue seems to be related: https://github.com/Koenkk/zigbee-herdsman/pull/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"}

tric111 on 15 Aug 2020

any news for my issue?

duczz on 18 Aug 2020

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

s-hadinger on 18 Aug 2020

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 #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 on 18 Aug 2020

An ESP32 single and dual-core version of tasmota-zbbridge firmware would be on my own long-term wish-list, like example:

@grobasoz wrote in https://github.com/zigpy/bellows/issues/243 that he's working on an ESP32 + EFR32 based Zigbee bridge
@mtx512 also wrote in https://github.com/zigpy/bellows/issues/243 that he is as well working on an ESP32 + EFR32 bridge
DIY Zigbee gateway/bridge based on ex ESP32-DevKitC https://www.espressif.com/en/products/devkits/esp32-devkitc/
Wyze/Lockin lock gateway has an ESP32 with 8MB flash and EFR32MG21A020F1024 https://lockinsmarthome.com/pages/lockE

ESP32-DevKitC would probably make a good reference board https://www.espressif.com/en/products/devkits/esp32-devkitc/ or?

Zeroconf + mDNS as requested in https://github.com/arendst/Tasmota/issues/9081 (also on my wish-list) are for example best suited for ESP32 as more resource demanding?

Hedda on 19 Aug 2020

What should we do with the button on Sonoff ZBBridge?

I would like to suggest using the button on the Sonoff ZBBridge to put the bridge into pairing-mode for pairing Zigbee devices.

Scenario; Another reason why Sonoff ZBBridge being a USB-powered WiFi is great is because you can plug it into a USB battery/power-pack which makes it portable so that you can bring it to different rooms in your house when pairing permanently installed mains-powered Zigbee devices like example in-wall mounted switches.

Very concept convenient easy when migrating from another platform and you have lots of devices installed around your house.

This could also make it possible to initially pair new devices without a computer, though you will still need to configure them later.

Hedda on 19 Aug 2020

@Hedda I agree 100% on the bottom but i think feedback on the LED then pairing mode is enabled and ended world being good. I think its possible putting more (but not too much) functions for the user in the bottom perhaps EZSP in flash / NCP mode toggle and start xmodem download.

MattWestb on 19 Aug 2020

@s-hadinger Can you pick when the button on Sonoff ZBBridge is pressed down to count seconds until it released?

If so then the button could have many functions and if combined with the LED for feedback as suggested it would make it easier for the users to know if they have successfully entered the command for the function and Sonoff ZBBridge is doing what you want.

Example suggestions if possible to detect how long the button is hold down for:

Hold the button for 3-seconds to make it enter Zigbee pairing mode for 15-seconds= Fast pulse LED rapidly for 15-seconds.
- Then have LED flash/blink slowly 3-times to indicate a successful paring of a Zigbee device
Hold the button for 10-seconds to make EFR32 enter xmodem for 60-seconds= Slow pulse the LED rapidly for 60-seconds.
- Then have LED flash/blink slowly 5-times to indicate a successful flashing of the EFR32 application firmware

Otherwise, you could do something like:

Press the button 3-times to make it enter Zigbee pairing mode for 10-seconds= Fast pulse LED rapidly for 15-seconds.
- Then have LED flash/blink slowly 3-times to indicate a successful paring of a Zigbee device
Press the button 5 times to make EFR32 enter xmodem for 60-seconds= Slow pulse the LED rapidly for 60-seconds.
- Then have LED flash/blink slowly 5-times to indicate a successful flashing of the EFR32 application firmware

Hedda on 19 Aug 2020

@Hedda This will need to be done via Rules. Keep in mind that the button needs a thin tool to press it. It should be used as emergency button, not as a pairing button.

s-hadinger on 19 Aug 2020

@MattWestb Thanks for the document. It is more aimed at lights manufacturer but gave some good information. I am adding some of the extended ZCL attributes. However IAS is not part of this document, and some PIR don't follow the "Occupancy" profile. I will need to find something to emulate it.

s-hadinger on 19 Aug 2020

Maybe an integration into the scripting function would also be a good option that offers more possibilities than rules.

kugelkopf123 on 19 Aug 2020

@s-hadinger Yes i think it is one supplemental to the ZCL for ZB3. The ZCL "original" is based of the HA and suld being in the "normal" ZCL.
The Light Link was not implemented in the original ZCL then it was to much things interfere with the HA profile and its still problem with cluster compatibility between old LL and new ZB3 LO (silabs EZSP is still using cluster numbers that is not compatible with ZCL).
I don't knowing if IAS is part of the original ZCL or if Zigbee alliance have making one separate paper for the IAS.
And in the end your problem with #8202 is that its not one real ZB3 (Zigbee PRO variante with HA i think its more true) as normal with the not new Xaomi devices.
I think its best is to making one separate solution for this device and not destroying your clean implantation of the ZCL.

How is it going on your hardware front ? All equipment well burned and the supplier is not sending you new ones and you dont having trust in soldering iron ?

I'm waiting for you coming back on track and until i doing some deeeeeep diving in the (re)pairing problems of TB3 devices in the new belloes is having (first time pairing working well (no tokens is saved in the NCP for devices) but the rejoining / repairing one known device the TC-Link key is not updated in the NCP token = not actirusated devises).

MattWestb on 19 Aug 2020

Include TLS/AWS IoT in the tasmota-zbbridge (because we have more than enough space for it)

Maybe add support "Google Smart Home platform" as an alternative or as an option to use nstead of AWS IoT to the wish-list?

Google Smart Home platform lets users control their connected devices through the Google Home app and Google Assistant:

https://developers.google.com/assistant/smarthome/overview

Google's "Smart Home" platform is based on "Actions on Google":

https://developers.google.com/assistant/smarthome/develop/create

I think that very much of interest then would probably be Google's new "Local Home SDK" for local control, meaning fast response:

https://developers.google.com/assistant/smarthome/concepts/local

https://codelabs.developers.google.com/codelabs/smarthome-local/#0

https://developers.google.com/assistant/smarthome/reference/local

https://github.com/actions-on-google/smart-home-local

The Local Home SDK concept allows users to use smart actions fulfilment over local-WiFi/LAN, without a roundtrip to the cloud.

Hedda on 19 Aug 2020

Set Extended Timeout for better reachability of sleepy devices (polling)

I've noticed that my Aqara (Xiaomi) sensors will pair and work correctly for a few minutes and then no longer update (unless I press the physical button). Is this a timeout issue? I've heard that Xiaomi devices are non-standard.

roger- on 19 Aug 2020

@roger- I have the Aqara door & window contact sensor (MCCGQ11LM) and Aqara temperature, humidity and pressure sensor (WSDCGQ11LM). Its can taking little before they start reporting battery status but its always doing that. The MCCGQ11LM is not sending much then i not detecting changing status of the magneetcontact. The WSDCGQ11LM is reporting the attribute in the log more times in the hour (have not clocking the intervall) and i have seen both device status in the the MQTT broker.
I do testing for zigpy / belloes for the moment so don't having the Tasmota Zigbee Bridge setup active and cant providing data from logs at the moment.
Witch Aqara sensors do you have problem with ? Model and version is helping getting more information how they is working and can answer your question.

MattWestb on 19 Aug 2020

Then the "hidden" bottom is not good for everyday use its better using it for halting the EZSP starting the telnet server (if its not started) and rebooting the EZSP in bootloader mode and giving one 1 then the consolle then its sending one BL > so keeping the bootloader in xmodem upload mode until rebooting the box or long pressing the button > reboot EZSP.
If its easy using the LED for for status of the process status.
One question wat GPIO is the button connected ? Only wondering if it's interfering with the booting of the ESP.

MattWestb on 19 Aug 2020

@MattWestb The button is connected to GPIO16. Currently in Tasmota it is declared as Button1 and triggers Power On/off which has zero effect. You can easily set a Rule to trigger whatever you want from the button.

My ZBBridge is back online, and I have 2 more that just arrived in the mailbox. Back on track!

s-hadinger on 19 Aug 2020

🚀1 👍1

Thanks for answer.
I was thinking you was needing going to Ik.... ;-)
Take little care then J-tagging so not writing bad things at wrong location then tasting.
The good thing is that you now can testing the original firmware updating before you "customizing" it.
I was looking for IAS specifications and its looks its in integrated in the ZCL v7 (or v6).
No more Ruhetag until ZB3 is finished and then the R23 (Zigbee 4.0 ?) is in the pipeline ;-)))

MattWestb on 19 Aug 2020

@MattWestb

I also have a WSDCGQ11LM (connected via tasmota-zb to ZHA/home assistant).

The problem isn't just infrequent updates but my devices become "unknown" after rebooting home assistant (even though the "last seen" field gets updated).

roger- on 20 Aug 2020

@roger- Good that you is providing little more information about your setup.
Then using AHs ZHA for EZSP you is using the tasmota Zige bridge as serial over TCP.
So your problem is in HA / ZHA and you have doing right opening one issue in there git.
I think you is running the main branch of ZHA and its have getting support for the version 8 protocol framing but have not all futures implanted. In the ground is working in ZHA but they having problem with Zigbee 3 devices then they rejoining / repairing. Then (nearly) all Xaomi devices is not ZB3 they are working there. The ZHA supports for newer versions of EZSP is in alpha stage and need time to getting stabili.

Edit: You should putting channel 11 in your channels: list so the NCP also scanning it the pairing devices (important for for lights then its one of the default LL channels (11. 15. 20 and 25)).

MattWestb on 20 Aug 2020

@unscel Your first received message {"ZbReceived":{"home_theatre_door":{"Device":"0xA9A9","Name":"home_theatre_door","Power":0,"Endpoint":1,"LinkQuality":110}}}
Its reported then the contacts status have being changed.
The second message {"ZbReceived":{"home_theatre_door":{"Device":"0xA9A9","Name":"home_theatre_door","0000/FF02":"null","0000/E521":605268001,"DateCode":1,"StackVersion":"null","ZCLVersion":23,"Endpoint":1,"LinkQuality":110}}} its one status report that the device is sending on regular basis. Its dont have the "Power":0 in it then the status of the contact is not changed. Your extraction of messages is not correct made and triggering on status messages from the device that not having the correct syntax ("Power":).
Taking one more lock how your "extraction" is working and make its only triggering on messages with"Power" in and you is not getting any "false Power" tiggings.

MattWestb on 20 Aug 2020

I don't being one software more the hardware but i think you need one "if" some ware so its excluding all messages without your desired "Power". Use google and you finding it.

MattWestb on 20 Aug 2020

Undocumented future in funktion ZbForget and unsecure rejoining of devices.
Then removing one device with the funktion "ZbForget" is being erased in the Tasmotas database but no command is issued to the NCP to deleting the token for the device in the NCPs token store and no command is send to the device to leaving the network (and deleting the network credential).
The result is as soon the device is repowerd and sending one device announce the NCP is doing one secure rejoining (as zigbee standard) then the device EUI64 is still in the token store. Tasmota is very happy and if its one ZB3 device assigning one new ShortAddr forthe device and saving it in the database and the device is silent 110% in the network.
Its one generic future and working on TB3 and earlier versions.
This is one large security thing and both issues need high priority for being patched.
The right behaviour then "kicking" one devices is deleting the token in the NCP token store so its cant rejoining the network without opening it for joining and as standard saying also one leave command sud being issued for the device so its deleting the the network credentials (if possible as some devices is sleeping).

11:31:30 CMD: ZbForget 0xCD64
11:31:30 RSL: RESULT = {"ZbForget":"Done"}
11:31:32 ZIG: Zigbee Devices Data store in Flash (0x402FF800 - 235 bytes)
11:31:41 ZIG: {"ZbEZSPReceived":"4500040000130000000000000000B8CA64CDFFFF0C0064CD7663341A004B12008E04"}
11:31:41 RSL: RESULT = {"ZbState":{"Status":30,"IEEEAddr":"0x00124B001A346376","ShortAddr":"0xCD64","PowerSource":true,"ReceiveWhenIdle":true,"Security":false}}
11:31:42 ZIG: {"ZbEZSPReceived":"4500000000058000000000000001C4CD64CDFFFF07280064CD020B0D04"}
11:31:42 RSL: RESULT = {"ZbState":{"Status":32,"ActiveEndpoints":["0x0B","0x0D"]}}
11:31:42 ZIG: {"ZbEZSPReceived":"450000040100000B010001000002C4CD64CDFFFF22180101040000420D5368656E5A68656E5F486F6D610500004208484F4D413130303804"}
11:31:42 RSL: SENSOR = {"ZbReceived":{"0xCD64":{"Device":"0xCD64","Manufacturer":"ShenZhen_Homa","ModelId":"HOMA1008","Endpoint":11,"LinkQuality":95}}}
11:31:44 ZIG: Zigbee Devices Data store in Flash (0x402FF800 - 282 bytes)
11:39:51 CMD: ZbSend {"Device":"0xCD64","Send":{"Power":2}}
11:39:51 RSL: RESULT = {"ZbSend":"Done"}
11:39:52 ZIG: {"ZbEZSPReceived":"450000040106000B010001000003B8CA64CDFFFF0518020B020004"}
11:39:52 RSL: RESULT = {"ZbResponse":{"Device":"0xCD64","Command":"0006!02","Status":0,"StatusMessage":"SUCCESS","Endpoint":11,"LinkQuality":87}}
11:39:52 ZIG: {"ZbEZSPReceived":"450000040106000B010001000004B8CA64CDFFFF08180301000000100004"}
11:39:52 RSL: SENSOR = {"ZbReceived":{"0xCD64":{"Device":"0xCD64","Power":0,"Endpoint":11,"LinkQuality":87}}}

ZbForget. Repower device. Devices is doing one secure rejoined. Sending toggle and its working.
The network was NOT open for pairing !!

For the moment it's not possible for one normal user getting one by axident joined device blocked / erased in the system and its not helping rolling the network key in the NCP = compleet compromentatde system.

Edit:
Request implanting EZSP Security Frames: Name: eraseKeyTableEntry ID: 0x0076 then issuing tsmota command ZbForgetand Name: clearKeyTable ID: 0x00B1 then issuing tasmota reset command.

Edit 2020-08-27 Only for information in the future then having problem with pairing zigbee 3 devices.
Have paired my 9 test device in ZHA in full ZB3 mode. Then reflashing tasmota and paring all devices. All not ZB3 devices is going in as normal but the ZB3 is joining but leaving all the time until the device is timing out. The reason for this behavior is that the NCP have one old link key stored for the device in the key table from its "previous life" and the user can not doing anything for getting the ZB3 device paired until the obsolete key is deleted. I don't knowing if tasmotas original GW is using key table storage or not but if the user have trying pairing ZB3 devices in one system with the NCP in "real ZB3" mode and not have doing one "erase_internalflash" (that normal users cant do if not flashing with SWD) after that its never possible pairing this devices in tasmota zigbee bridge agen.

For getting the key table cleared the EZSP command Name: clearKeyTable ID: 0x00B1 need being implanted and runned before the NCP is forming the new network.
Then the user can using the NCP with other systems and never getting problems then going back to tasmota and forming one new network.
One side not: Silabs is strongly pointing out that then flashing one NCP firmware must the internal flash being erased before doing it (deleting the NVS3 storage in the internal flash where the key table is located).

MattWestb on 21 Aug 2020

I would like to add a request for support to force username and password requirement for connecting to the serial bridge.

The serial bridge does not have to have encrypted traffic but being able to optionally force users to enter a username and password would make it just a little bit more secure to connect to the serial bridge when using Sonoff ZBBridge with ZHA in Home Assistant.

Right now you only have to enter IP-address and port then anyone on the network can connect to this Tasmota serial bridge.

https://www.digiblur.com/2020/07/how-to-use-sonoff-zigbee-bridge-with.html

Hedda on 21 Aug 2020

❤1

@MattWestb The documentation is maybe unclear, but ZbForget is only to free up space in the Tasmota DB. It has nothing to do with unpairing the device. Actually removing a device is a non-trivial operation because the device could be registered by a router, that could be temporarily offline. I don't have an easy solution for that.

@Hedda This will not happen for two reasons: 1/ there is no standard protocol to put a password an a pure TCP connection, 2/ password protection is mostly futile unless you encrypt the traffic - which will not happen either because of limitations of the ESP8266.

s-hadinger on 21 Aug 2020

It was not in the todo list, but there will be a week-end bonus.

Coming soon:
weather

s-hadinger on 21 Aug 2020

🎉2 🚀1 👍1

One more "Undocumented future"
That's the way we like it GREAT !! :-)))

MattWestb on 21 Aug 2020

there is no standard protocol to put a password an a pure TCP connection,

OK, is it instead technically possible to set a username and password in the EmberZNet application firmware on the ERF32 chip?

That is, would it be possible to build a new EmberZNet application firmware in which you could set a username and password?

Thinking that encryption is not needed and just username and password should be enough since not it is not over the internet.

password protection is mostly futile unless you encrypt the traffic - which will not happen either because of limitations of the ESP8266.

OK, proper secure connection use server-side TLS/SSL encryption which is bad for ESP8266 because of low RAM + slow CPU.

Do you think that a DYI Zigbee-bridge with ESP32 instead of ESP8266 is powerful enough to encrypt a 115200 baud connection?

Not asking you to implement any of those yourself, just curious so asking if you think that it is technically even possible in theory.

Hedda on 24 Aug 2020

@Hedda You can doing one porting of the tasmota for the Secure EZSP Protocol Version 2 and you is getting good security from NCP to host. The version 1 Its well documented in "AN1125: Creating and Using a Secure EZSP Host-to-NCP Interface" and other slabs dokuments is being updated with the version 2 and the EZSP 6.8.x.x.

Edit: Also if you using tsmota as one serial bridge the right implantation is that you porting your host system (HA or what you are using) for using the SEZSP v2 and all is secure from end device in the zigbee net to your hopefully secure host system. Then tasmota is only one transport link and dont need being cryptated then the SEZSP is cryptatig the data to the host and taking care of the user credentials.
That would being one great secure solution as long you only using "reaal" zigbee 3 devices in your system !!!

PS: SEZSP its standard implanted in the "normal" silabs NCP firmware parallel with the normal EZSP if not have desabeling it then compiling and is by software command to enable.

MattWestb on 24 Aug 2020

Agreed, the issue is to implement the secure protocol on the Home Automation software, not in Tasmota. SEZSP does not make sense if it's only about securing the communication between ESP8266 and EFR32. It needs to be end-to-end.

Please revert this request to ZHA. This is off-topic for this GitHub issue.

s-hadinger on 25 Aug 2020

👍1

@tric111 thanks for reporting the issue with Philips outdoor motion sensor SML002.

I have implemented sending the default response required by this device. It will be available as soon as #9163 gets merged.

s-hadinger on 25 Aug 2020

👍1

Request of implanting battery status from IKEA controller devices.
IKEA controller devices is working well is my experience with the new and old motion sensor and the On/Off dimmer switch (E1743). Have 5 bottom remotes and wireless dimmer but its in produktion net for the moment so cant easy testing.
All devices is missing the new nice future of showing battery status in WEB UI ;-(
On/Off status is not needed / wished from controlling devices then its by ZB3 standard light that suld reporting that attribute to the coordinator but is possible "sniffing" groupe commands but its not 100% then the coordinator can sending unicast and steering devices 2 and then its not in sync.
If you need help with logs from some controlling devices i can doing it for you if you dont finding the reporting attributes online.

The off status and still light level is OK by TB3 standard and is the level the lights have then sending one on command so don't destroying that behaviour.

By the way is it possible getting one blitz for main powered device in the battery position for indicating its / was "online" ?

Z2T06
Nice work !!!!!

MattWestb on 26 Aug 2020

Request of encoding group address in group messages for easy to configuring device groupes to bounded controller devices. If its possible in dec and hex (42/0x2a).

MattWestb on 26 Aug 2020

I paired an Ikea Bulb and a Tradfri Remote Control Model E1810 with my ZbBridge!
Pairing was ok as far as I got.
Problem: Pushing any of the remote buttons do not show an activity on Tasmota Log.
Only the green LED of the ZbBridge shows that commands were send to the Bridge.

ZbStatus2 18:39:46 MQT: stat/zigbee_05697B/RESULT = {"ZbStatus2":[{"Device":"0x4CB8","Name":"IKEA-Bulb","IEEEAddr":"0x14B457FFFE4EBCB4","ModelId":"TRADFRI bulb E27 WS opal 1000lm","Manufacturer":"IKEA of Sweden","Endpoints":["0x01","0xF2"]},{"Device":"0x24E2","Name":"IKEA-Remote","IEEEAddr":"0x000D6FFFFE052760","ModelId":"TRADFRI remote control","Manufacturer":"IKEA of Sweden","Endpoints":["0x01"]}]}
The Bulb is working as expected!
What is wrong? Sorry I am a Zigbee Beginner.
Thanks in advance.

littlebilly on 26 Aug 2020

@littlebilly To getting the binding of your remote have its not so easy to getting from the gateway but it can being that is configured then paring to groupe 0. My On/Off dimmer switch is doing that and also the new motion sensor but not the old model.
Try adding grupe 0 to the light and testing if its working.
Groupe 0 its the "default" group for not configured device and it not good to using then its being one mess if you having more devices but for beginning its OK.
I have putting one request for getting that from the gateway then its seeing it being broadcasted from one controller device but it was 6 hours ago.
You can also deleting the binding in the remote and making one new to a new groupe but its not so easy to getting right.

Edit: I think you are capable to calculating the group from this post:
https://github.com/arendst/Tasmota/issues/8583#issuecomment-667045758 and putting the ligths in the group also doing the subscription for message with ZbListen so you getting the messages from the groupe.
Pushing one button sometimes so the switch so is sending messages and have the loglevel 3 for debug and you see the broadcasted group message in the console.

MattWestb on 26 Aug 2020

@MattWestb I didn't understand your request for group addresses. Can you please elaborate?

@littlebilly Indeed it is best to bind the remote to a group, not necessarily group 0 since you may want different groups.

See the example for IKEA remote and bulb here: https://tasmota.github.io/docs/Zigbee/#zigbee-binding

s-hadinger on 26 Aug 2020

@s-hadinger The IKEAs old motion sensor(LL) is making one LL grupe (bonded) and need "sniffing" and calculating it after pairing for adding lights to the groupe.
The new version and the E1743 (ZB3) don't making groupe and sending the command to the default groupe (0).
I don't have trying to binding them to other groups but i think its first need being unbounded before possible binding then to one new groupe.

MattWestb on 26 Aug 2020

Hi, thanks for the great work so far on this!

My main request would be to be able to assign a Domoticz device ID to each Zigbee device and send/receive commands/status on the domoticz/in and domoticz/out MQTT topics.

CKerswell on 27 Aug 2020

@s-hadinger @MattWestb
Thanks alot for your quick response.
When binding the remote to a group like:
ZbBind {"Device":"IKEA-Remote","ToGroup":100,"Endpoint":1,"Cluster":6} 08:05:08 MQT: stat/zigbee_05697B/RESULT = {"ZbBind":"Done"} 08:05:08 ZIG: {"ZbEZSPReceived":"450000000021800000400100005AFFE2E224FFFF021F0002"} 08:05:08 MQT: tele/zigbee_05697B/RESULT = {"ZbBind":{"Device":"0x24E2","Name":"IKEA-Remote","Status":0,"StatusMessage":"SUCCESS"}}
I got this.
What I'm missing as described in Zigbee documentation is:
Receiving Commands from the remote

If you pair devices such as switches or remotes, you will also receive commands from those devices.
When a command is received, attributes are published both in their low-level and high-level formats (if known).

What is going wrong?

littlebilly on 27 Aug 2020

Try subscribe listen the group with the command ZbListen1 100 then the first number is the "slott" (1-15 is free i think) and the last is the group number.

MattWestb on 27 Aug 2020

I did now: ZbListen1 100 --> ZbListen2 100 .......> ZbListen15 100 and push a button but I get nothing on the console.

littlebilly on 27 Aug 2020

May be this helps?
ZbSend {"device":"IKEA-Remote","Send":{"GetAllGroups":true}}
09:19:50 MQT: stat/zigbee_05697B/RESULT = {"ZbSend":"Done"} 09:19:51 ZIG: {"ZbEZSPReceived":"45000004010400010140010000DEFFE0E224FFFF0508080B02C302"} 09:19:51 MQT: tele/zigbee_05697B/RESULT = {"ZbResponse":{"Device":"0x24E2","Name":"IKEA-Remote","Command":"0004!02","Status":195,"StatusMessage":"UNSUPPORTED_CLUSTER","Endpoint":1,"LinkQuality":145}}

seems group is not recognized despite command "ZbBind {"Device":"IKEA-Remote","ToGroup":100,"Endpoint":1,"Cluster":6}"

littlebilly on 27 Aug 2020

@littlebilly It should be working. You can simply do ZbBind {"Device":"IKEA-remote","ToGroup":100,"Cluster":6} and don't forget to do ZbListen1 100 after each reboot! Put it in a rule like Rule1 on zbstate#status==0 do zblisten1 100 endon and Rule1 1 to enable the rule.

On the IKEA bulb side, do ZbSend {"device":"IKEA","Send":{"AddGroup":100}} to have the bulb listen to the group.

The remote does not support Group cluster because it does not need to. It only needs to bind to the group.

Pressing the button should show something like: {"Device":"0xC6EF","Name":"IKEA-Remote","0006!02":"","Power":2,"Endpoint":1,"Group":100,"LinkQuality":116}

@MattWestb Unfortunately it is not possible to sniff group numbers with EmberZNet. ZNP CC2530 can do it but for some reason EZ requires explicit ZbListen. So if you have an old IKEA device with unknown group number, you need to have a separate Zigbee sniffer.

s-hadinger on 27 Aug 2020

@s-hadinger
I did all what you suggest to do with no sucess.
Pressing the button shows nothing! strange?
I do have 5 buttons!

Sending commands from console to Bulb
like "ZbSend {"Device":IKEA-Bulb,"Send":{"CT":300}}"
works perfectly

littlebilly on 27 Aug 2020

@s-hadinger The problem for normal users is that you first must unbind the device before you can doing one new binding. If sending one new binding like this
12:46:22 CMD: ZbBind {"Device":"IKEA_MOTION_OLD","ToGroup":100,"Cluster":6} 12:46:22 SRC: WebConsole from 192.168.2.10 12:46:22 CMD: Group 0, Index 1, Command "ZBBIND", Data "{"Device":"IKEA_MOTION_OLD","ToGroup":100,"Cluster":6}" 12:46:22 ZIG: ZbEZSPSend 340000C8760000210000004001000011010F1173BB59FEFF9FFD90010600016400 12:46:22 RSL: RESULT = {"ZbBind":"Done"} 12:46:22 ZIG: {"ZbEZSPReceived":"34000054"} 12:46:23 ZIG: {"ZbEZSPReceived":"3F0003FDFF0401060001FF0001E9CDA8000000"} 12:46:24 ZIG: {"ZbEZSPReceived":"45000000002180000040010000A9CCCFC876FFFF02110002"} 12:46:24 RSL: RESULT = {"ZbBind":{"Device":"0x76C8","Name":"IKEA_MOTION_OLD","Status":0,"StatusMessage":"SUCCESS"}} 12:46:24 ZIG: {"ZbEZSPReceived":"3F0000C8760000210000004001000054010000"} 12:46:28 ZIG: {"ZbEZSPReceived":"3F0003FDFF0401060001FF0001E9CDAA000000"} 12:47:24 ZIG: {"ZbEZSPReceived":"3F0003FDFF0401060001FF0001E9CDAB000000"} ```` But the device is continuing sending command to groupe 52713 ``` as you can see.
And then user must do the e9cd = 0xcde9 = 527113.
So "sniffing" is still possible of the grupes for the user if knowing how.
Then it should being possible doing one unbind from the old group and one new bind to the new group or easier using the old grup and putting the lights in it without "rebinding".

MattWestb on 27 Aug 2020

That's interesting. You are actually seeing the group 0xCDE9 because the coordinator is relaying the message to routers. I never thought that it would be a way to sniff multicast traffic.

Normally you should see a response to ZbBind, either SUCCESS or an error. There is nothing in the log. Are you sure you pressed a button just before sending the ZbBind message?

You can also try the ZbUnbind command with the same parameters.
ZbUnbind {"Device":"IKEA_MOTION_OLD","ToGroup":100,"Cluster":6}

Edit: ZbUnbind {"Device":"IKEA_MOTION_OLD","ToGroup":52713,"Cluster":6}

s-hadinger on 27 Aug 2020

@littlebilly I have the exact same device, but maybe with a different firmware. Can you share the logs when you pair the device, and when you press the central button (before any binding). Please use weblog 3

s-hadinger on 27 Aug 2020

Herewith th e log.
17:38:29 CMD: ZbPermitJoin 1 17:38:29 SRC: WebConsole from 192.168.148.20 17:38:29 CMD: Group 0, Index 1, Command "ZBPERMITJOIN", Data "1" 17:38:29 ZIG: ZbEZSPSend 22003C 17:38:29 ZIG: ZbEZSPSend 3600FCFF00003600000000000000031E0103033C01 17:38:29 MQT: stat/zigbee_05697B/RESULT = {"ZbPermitJoin":"Done"} 17:38:29 ZIG: {"ZbEZSPReceived":"220000"} 17:38:29 MQT: tele/zigbee_05697B/RESULT = {"ZbState":{"Status":21,"Message":"Pairing mode enabled"}} 17:38:29 ZIG: NAK, resending packet 6 17:38:29 ZIG: {"ZbEZSPReceived":"3600004B"} 17:38:29 ZIG: {"ZbEZSPReceived":"450005000036000000000000004BFF000000FFFF03033C01"} 17:38:29 ZIG: Internal ZDO message 0x0036 sent from 0x0000 (broadcast) 17:38:30 ZIG: {"ZbEZSPReceived":"3F0006FCFF000036000000000000004B010000"} 17:38:51 ZIG: {"ZbEZSPReceived":"23000001E224602705FEFF6F0D0004"} 17:38:51 ZIG: {"ZbEZSPReceived":"2400E224602705FEFF6F0D0001000000"} 17:38:51 MQT: tele/zigbee_05697B/RESULT = {"ZbState":{"Status":34,"IEEEAddr":"0x000D6FFFFE052760","ShortAddr":"0x24E2","ParentNetwork":"0x0000","Status":1,"Decision":0}} 17:38:53 ZIG: ZbFlashStore 0350B84CB4BC4EFEFF57B41402010000FFFFF20000FFFF545241444652492062756C6220453237205753206F70616C20313030306C6D00494B4541206F662053776564656E00494B45412D42756C6200FF100000000000000000000000000000FF10E224602705FEFF6F0D0000000000FF 17:38:53 ZIG: Zigbee Devices Data store in Flash (0x402FF800 - 113 bytes) 17:38:55 ZIG: {"ZbEZSPReceived":"23000001E224602705FEFF6F0D0004"} 17:38:55 ZIG: {"ZbEZSPReceived":"2400E224602705FEFF6F0D0001000000"} 17:38:55 MQT: tele/zigbee_05697B/RESULT = {"ZbState":{"Status":34,"IEEEAddr":"0x000D6FFFFE052760","ShortAddr":"0x24E2","ParentNetwork":"0x0000","Status":1,"Decision":0}} 17:38:55 ZIG: {"ZbEZSPReceived":"6200602705FEFF6F0D00"} 17:38:55 ZIG: {"ZbEZSPReceived":"450004000013000000000400003FFFDCE224FFFF0C81E224602705FEFF6F0D008002"} 17:38:55 MQT: tele/zigbee_05697B/RESULT = {"ZbState":{"Status":30,"IEEEAddr":"0x000D6FFFFE052760","ShortAddr":"0x24E2","PowerSource":false,"ReceiveWhenIdle":false,"Security":false}} 17:38:55 ZIG: ZbEZSPSend 340000E2240000050000004001000004010304E224 17:38:55 ZIG: {"ZbEZSPReceived":"34000050"} 17:38:56 ZIG: {"ZbEZSPReceived":"3F0006FDFF000013000000000400003F000000"} 17:38:56 ZIG: {"ZbEZSPReceived":"4500000000058000004001000040FFDDE224FFFF060400E224010102"} 17:38:56 MQT: tele/zigbee_05697B/RESULT = {"ZbState":{"Status":32,"ActiveEndpoints":["0x01"]}} 17:38:56 ZIG: ZbEZSPSend 340000E2240401000001014001000001010700010004000500 17:38:56 ZIG: {"ZbEZSPReceived":"3F0000E2240000050000004001000050010000"} 17:38:56 ZIG: {"ZbEZSPReceived":"34000051"} 17:38:57 ZIG: {"ZbEZSPReceived":"4500000401000001014001000041FFDDE224FFFF31180101040000420E494B4541206F662053776564656E0500004216545241444652492072656D6F746520636F6E74726F6C02"} 17:38:57 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":0,"srcaddr":"0x24E2","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":137,"securityuse":0,"seqnumber":65,"fc":"0x18","manuf":"0x0000","transact":1,"cmdid":"0x01","payload":"040000420E494B4541206F662053776564656E0500004216545241444652492072656D6F746520636F6E74726F6C"}} 17:38:57 ZIG: ZbZCLRawReceived: {"0x24E2":{"0000/0004":"IKEA of Sweden","0000/0005":"TRADFRI remote control"}} 17:38:57 MQT: tele/zigbee_05697B/SENSOR = {"ZbReceived":{"0x24E2":{"Device":"0x24E2","Manufacturer":"IKEA of Sweden","ModelId":"TRADFRI remote control","Endpoint":1,"LinkQuality":137}}} 17:38:57 ZIG: {"ZbEZSPReceived":"3F0000E2240401000001014001000051010000"} 17:38:59 ZIG: ZbFlashStore 0350B84CB4BC4EFEFF57B41402010000FFFFF20000FFFF545241444652492062756C6220453237205753206F70616C20313030306C6D00494B4541206F662053776564656E00494B45412D42756C6200FF100000000000000000000000000000FF39E224602705FEFF6F0D0001010000FFFF545241444652492072656D6F746520636F6E74726F6C00494B4541206F662053776564656E0000FF 17:38:59 ZIG: Zigbee Devices Data store in Flash (0x402FF800 - 154 bytes) 17:39:12 ZIG: {"ZbEZSPReceived":"3F0003FDFF0401060001FF0001F7A042000000"}

Thanks in advance

After press the central button (before any binding)
{"ZbEZSPReceived":"3F0003FDFF0401060001FF0001F7A043000000"}

littlebilly on 27 Aug 2020

Again after press the central button (before any binding)

17:42:59 ZIG: {"ZbEZSPReceived":"4500040000060000000001000045FFDFE224FFFF0901FDFF04010119000002"}
17:42:59 ZIG: Internal ZDO message 0x0006 sent from 0x24E2 (broadcast)
17:43:00 ZIG: {"ZbEZSPReceived":"3F0006FDFF0000060000000001000045000000"}

Device 0x0000 shown?

littlebilly on 27 Aug 2020

@littlebilly The 0x0000 is the coordinator and its showing up and you can renaming it if you like ;-)

MattWestb on 27 Aug 2020

@littlebilly 0x0000 is a small bug, you can remove it with ZbForget 0x0000

Looking at the logs, your device is using group 0xA0F7. You can try ZbListen1 0xA0F7 and you should see the commands now.

If your bulb has only 2 channels (cold/warm white), you can set it with ZbLight IKEA-Bulb,2

s-hadinger on 27 Aug 2020

Thanks a lot!
I can see the commands now.
My bulb has (cold/warm white) and Dimmer! ZbLight IKEA-Bulb,2 should be okay according your documentation!
You did a great Job and the others too.

littlebilly on 27 Aug 2020

Testet remote bind to the bulb works nearly perfekt!
Power On off --> ok.
Dimmer up and down --> ok
cold/warm white --> no functionality
See above log for ArrowClick
18:39:47 MQT: tele/zigbee_05697B/SENSOR = {"ZbReceived":{"0x24E2":{"Device":"0x24E2","0005!07":"00010D00","ArrowClick":0,"Endpoint":1,"Group":41207,"LinkQuality":103}}} 18:39:56 ZIG: {"ZbEZSPReceived":"4500020401050001FF0001F7A0AFC4CDE224FFFF09057C116D0701010D0002"} 18:39:56 MQT: tele/zigbee_05697B/SENSOR = {"ZbReceived":{"0x24E2":{"Device":"0x24E2","0005!07":"01010D00","ArrowClick":1,"Endpoint":1,"Group":41207,"LinkQuality":95}}} 18:39:57 ZIG: {"ZbEZSPReceived":"4500020401050001FF0001F7A0B0C0CCE224FFFF09057C116E0701010D0002"}
Do you have an idea?

cold/warm white with command ZbSend {"Device":IKEA-Bulb,"Send":{"CT":300}} works as expected.

littlebilly on 27 Aug 2020

Yes I know the issue. The left/right arrows send Change Scenes commands. By default the IKEA bulb has no scenes set up.

I need to craft the command since it's not supported as a high level command in Z2T. It was on my todo list for a long time, let me look at it now.

s-hadinger on 27 Aug 2020

@s-hadinger
Again many thanks for helping me.
I learned a lot regarding tasmota-zigbee.

littlebilly on 27 Aug 2020

"Someone" was for some weeks ago posting the deep seceret on github https://github.com/arendst/Tasmota/issues/8583#issuecomment-667045758 and it have working good for my all the time after that ;-)) but DON'T TELL ANYONE OF IT !!!!
If tasmota was "translating" only the group part (and the rest as info string or vice versa) then its being very easy for the user to doing unbind, bind and adding lights to device default groups and also putting in the "ZbListen".

19:40:41 ZIG: {"ZbEZSPReceived":"3F0003FDFF0401060001FF0001B75D79000000"}
19:42:26 CMD:  ZbListen1 0x5db7
19:42:26 SRC: WebConsole from 192.168.2.10
19:42:26 CMD: Group 0, Index 1, Command "ZBLISTEN", Data "0x5db7"

So its looks like this and easy to using:

19:40:41 ZIG: {"ZbEZSPReceived":"groupid":23991,"3F0003FDFF0401060001FF0001B75D79000000"}
19:42:26 CMD:  ZbListen1 23991
19:42:26 SRC: WebConsole from 192.168.2.10
19:42:26 CMD: Group 0, Index 1, Command "ZBLISTEN", Data "23991"
19:42:26 ZIG: ZbEZSPSend 640001B75D0100
19:42:26 RSL: RESULT = {"ZbListen":"Done"}
19:42:26 ZIG: {"ZbEZSPReceived":"640000"}
19:42:34 ZIG: {"ZbEZSPReceived":"4500020401060001FF0001B75D7AF8DABF72FFFF08010442005802000002"}
19:42:34 ZIG: {"ZbZCLReceived":{"groupid":23991,"clusterid":6,"srcaddr":"0x72BF","srcendpoint":1,"dstendpoint":255,"wasbroadcast":1,"LinkQuality":129,"securityuse":0,"seqnumber":122,"fc":"0x01","manuf":"0x0000","transact":4,"cmdid":"0x42","payload":"0058020000"}}
19:42:34 ZIG: ZbZCLRawReceived: {"0x72BF":{"0006!42":"0058020000","Power":1,"PowerOnlyWhenOn":0,"PowerOnTime":60,"PowerOffWait":0}}
19:42:34 RSL: SENSOR = {"ZbReceived":{"0x72BF":{"Device":"0x72BF","Name":"IKEA_MS_OLD","0006!42":"0058020000","Power":1,"PowerOnlyWhenOn":0,"PowerOnTime":60,"PowerOffWait":0,"Endpoint":1,"Group":23991,"LinkQuality":129}}}

And all IKEA steering devices is normally allocating one random group and binding it for being backward compatible with LL standard and normally they only accepting on grupe (and not device binding) and must being unbounded before accepting on new binding.
As you see its being much easier explaining how to do and also documenting it if gan getting the broadcasted group.

Do you need more info or logs ? I have all new installed after having ZHA running.

PS: It is possible reading the manufacture and board name tokens from EZSP and easy using for auto naming our NCPs :-)))

Edit: Perhaps is it that you don't have so much routers or they is working different that is making you don't see the group broadcasts (perhaps the mesh is more like one star then one mesh).

MattWestb on 27 Aug 2020

@s-hadinger

I have implemented sending the default response required by this device. It will be available as soon as #9163 gets merged.

I have used the ZBOSS sniffer to have a look at the data. Currently, the sequence number does not seem to match. For example, Report Attributes 0x0a has a sequence number 193, the Default Response 0x0b to this command 0x0a has sequence number 34. I think that's why the motion sensor still flashes red. Thanks for your help.

tric111 on 28 Aug 2020

@MattWestb Sure, I will add this to the logs so you can easily extract the group number. Indeed I'm not sure whether this frame is sent if there are no routers - to be tested.

I will look a manufacturer board ID, but I'm not sure where to find it.

@tric111 Good catch! Indeed I didn't bother about sequence number. There are actually two sequence numbers, one t Zigbee frame and one in the ZCL header. Are you talking about the one in the ZCL header?

s-hadinger on 28 Aug 2020

@s-hadinger The "group sniffing" is 110% user friendly and making all much easier for all so it being great if you can make it !!!
Way not getting it if having only one end device and no routers is clear then the end device is making one broadcast to its parent (coordinator at 0x0000) and the coordinator is not forwarding it then its dont have any routers in the router table (is like don't having any default router record in your network router = unicast is working but not broadcasts). Its way IKEA is having the repeater for the blinds so getting the end device messages (the up/down controller) being broadcasted around the mesh and can "cashing" it for the end device (the blindes).

If the token is set in the userdata it can being readed from the EZSP.
The API for setting token in EZSP is : ezspSetMfgToken(tokenId, tokenDataLength, tokenData)
and offset in userdata is for TOKEN_MFG_CUSTOM_EUI_64 0x0002, TOKEN_MFG_STRING 0x001A TOKEN_MFG_MANUF_ID 0x003A and for TOKEN_MFG_BOARD_NAME 0x002A from the manuale

I was putting it in the user data by hand (hex editing) and flashing it back to the chip.
Its also possible doing with simplicity commander CLI or with EZSP API (if not being set).
In ZHA its showing after have putting the token in the flash:

2020-08-17 09:07:37 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer: IKEA of Sweden
2020-08-17 09:07:37 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name: Billy EZSP by MW
2020-08-17 09:07:37 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.6.4.0 build 180

From the EZSP its the same token name but is stored in different locations on gen 1 and 2 chips so reading its no problems but "manual" setting the token in the userdata need little more tricky but pretty easy.
Reading the token suld not being any large problem for you.

Edit: From bellows init:

        tokens = []
        for token in (t.EzspMfgTokenId.MFG_STRING, t.EzspMfgTokenId.MFG_BOARD_NAME):
            LOGGER.debug("getting " "%s" " token", token.name)
            (result,) = await ezsp.getMfgToken(token)
            try:
                result = result.split(b"\xFF")[0]
                result = result.decode()
            except UnicodeDecodeError:
                pass
            tokens.append(result)

        (status, ver_info_bytes) = await ezsp.getValue(
            ezsp.types.EzspValueId.VALUE_VERSION_INFO
        )
        LOGGER.info("EZSP Radio manufacturer: %s", tokens[0])
        LOGGER.info("EZSP Radio board name: %s", tokens[1])
        if status == t.EmberStatus.SUCCESS:
            build, ver_info_bytes = t.uint16_t.deserialize(ver_info_bytes)
            major, ver_info_bytes = t.uint8_t.deserialize(ver_info_bytes)
            minor, ver_info_bytes = t.uint8_t.deserialize(ver_info_bytes)
            patch, ver_info_bytes = t.uint8_t.deserialize(ver_info_bytes)
            special, ver_info_bytes = t.uint8_t.deserialize(ver_info_bytes)
            LOGGER.info(
                "EmberZNet version: %s.%s.%s.%s build %s",
                major,
                minor,
                patch,
                special,
                build,
            )

that is making the 3 line output in ZHA debug log.

MattWestb on 28 Aug 2020

👍1

hello,
after removing a zigbee switch out of necessity I can't get it to work with the Hub again. the device is added by the Hub but remains unsigned and does not respond to any commands. How would you solve it? is it a bug?

eltonnascimento on 28 Aug 2020

@MattWestb #9187 adds group sniffing as discussed (needs Weblog 3):

22:00:20 ZIG: {"ZbEZSPReceived":"3F0003FDFF0401050001FF0001640042000000"}
22:00:20 ZIG: Sniffing group 0x0064

For MFGTokens, since the values are not set in the firmware people are using with ZBBridge, I'm reluctant to spend flash code to retrieve these values.

s-hadinger on 28 Aug 2020

🎉1 👍1

@eltonnascimento Please reached out on Discord for debugging, and give more information about the device.

s-hadinger on 28 Aug 2020

@tric111 #9188 should fix the sequence number. I only changed the ZCL header, I hope it's enough. Can you please confirm?

s-hadinger on 28 Aug 2020

When I did the last OTA-update off tasmota-zbbridge I lost all my pairings.
How can I avoid this?
By the way I installed meanwhile a second pair of Ikea-Remote and Ikea Bulb.I got the remote-group in weblog 3.
I did it manually as group sniffing at this time was not yet available.
Bind Bulb to this group and everything except th left/right arrows worked well.

littlebilly on 29 Aug 2020

🚀1 👍1

@littlebilly There is no reason that you lost pairing during OTA, unless you did a complete Reset of Tasmota and it reverted to the default randomized network key. You can check this with ZbConfig

s-hadinger on 29 Aug 2020

@s-hadinger

9188 should fix the sequence number. I only changed the ZCL header, I hope it's enough. Can you please confirm?

It looks good now. But still, the red LED of the sensor is flashing. When using the ZBOSS sniffer with Wireshark, the Default Responses always occur with quite a long delay (~1.5 s).
grafik
compared to the following Philips Hue bridge log (~20 ms) here:
https://github.com/Koenkk/zigbee2mqtt/issues/897#issuecomment-536764802
I am unsure why this happens.

tric111 on 29 Aug 2020

@tric111 This is suprisingly long. I would be interested to see the Weblog 3 logs at the same moment to see where the packet is stuck.

One thing that could explain a late packet is route discovery, but I don't see any route discovery packet in your wireshark logs.

Is this delay consistent?

s-hadinger on 29 Aug 2020

For MFGTokens, since the values are not set in the firmware people are using with ZBBridge, I'm reluctant to spend flash code to retrieve these values.

The manufacturer tokens is normally not set in the firmware is stored in the memory airia 1 "user data" (internal flash is memory airia 0) that is used as token store and factory information storage and is set by the factory and normally not being erased / updated by firmware updates, like the manufacturer cryptation token. Then making one "chip erase" / debug unlock its gon but is still untouched with normal "erase internal flash".
Have you looking if its percents then updating the original firmware with the factory EZSP from sonoff and without J-Tagging ?
If it is then making one "user data" file with yout MFGTokens in and flashing it or append them to the original EZSP file with simplicity commander in CL mode.

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿIKEA of SwedenÿÿBilly EZSP by MW|ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿIKEA of SwedenÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿTRADFRI bulb E27 WW 806lmÿÿÿÿÿÿÿ20181203ÿÿÿÿÿÿÿÿÇ  LED1836G9ÿÿÿÿÿÿÿ     ÿÿ½   X  d2 è  F xŠŠŠÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

Dumped and patched user data for IKEA Billy EZSP (original dumped from LED1836G9 as you can see).

If not set in the original untouched sonoff token store its don't make much sense implanting it (but looks nice and ZHA / Bellows is reading it).

And large thanks for the "sniffing group" function !!!

MattWestb on 29 Aug 2020

Got it. I need to try on a new ZBBridge, the one I have was "device erased"

s-hadinger on 29 Aug 2020

@s-hadinger
The 1.5 s delay seems pretty consistent most of the time. But I have seen a delay of about 0.25 s once in the past. As far as I remember, even then the red LED of the motion sensor was flashing. There are no active routers, it's just a tiny test setup on my desk.
grafik

19:35:17 ZIG: {"ZbEZSPReceived":"45000004010604020100010000D1CCCF8EE2FFFF07085E0A0000180102"}
19:35:17 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xE28E","srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":100,"securityuse":0,"seqnumber":209,"fc":"0x08","manuf":"0x0000","transact":94,"cmdid":"0x0A","payload":"00001801"}}
19:35:17 ZIG: ZbEZSPSend 3400008EE2040100000102400100005E0105105E0B0A00
19:35:17 ZIG: ZbZCLRawReceived: {"0xE28E":{"0406/0000":1}}
19:35:17 ZIG: {"ZbEZSPReceived":"34000072"}
19:35:17 RSL: SENSOR = {"ZbReceived":{"0xE28E":{"Device":"0xE28E","Name":"HueMotion1","Occupancy":1,"Endpoint":2,"LinkQuality":100}}}
19:35:18 ZIG: {"ZbEZSPReceived":"3F00008EE20401000001024001000072010000"}
19:35:18 ZIG: {"ZbEZSPReceived":"4500040401060402FF00000000D2C4CD8EE2FFFF07185F0A0000180102"}
19:35:18 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xE28E","srcendpoint":2,"dstendpoint":255,"wasbroadcast":1,"LinkQuality":95,"securityuse":0,"seqnumber":210,"fc":"0x18","manuf":"0x0000","transact":95,"cmdid":"0x0A","payload":"00001801"}}
19:35:18 ZIG: ZbZCLRawReceived: {"0xE28E":{"0406/0000":1}}
19:35:19 RSL: SENSOR = {"ZbReceived":{"0xE28E":{"Device":"0xE28E","Name":"HueMotion1","Occupancy":1,"Endpoint":2,"LinkQuality":95}}}
19:35:19 ZIG: {"ZbEZSPReceived":"3F0006FCFF0401060402FF00000000D2000000"}
19:35:27 ZIG: {"ZbEZSPReceived":"45000004010604020100010000D3D0D08EE2FFFF0708600A0000180002"}
19:35:27 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xE28E","srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":103,"securityuse":0,"seqnumber":211,"fc":"0x08","manuf":"0x0000","transact":96,"cmdid":"0x0A","payload":"00001800"}}
19:35:27 ZIG: ZbEZSPSend 3400008EE20401000001024001000060010510600B0A00
19:35:27 ZIG: ZbZCLRawReceived: {"0xE28E":{"0406/0000":0}}
19:35:27 ZIG: {"ZbEZSPReceived":"34000073"}
19:35:27 RSL: SENSOR = {"ZbReceived":{"0xE28E":{"Device":"0xE28E","Name":"HueMotion1","Occupancy":0,"Endpoint":2,"LinkQuality":103}}}
19:35:28 ZIG: {"ZbEZSPReceived":"3F00008EE20401000001024001000073010000"}
19:35:28 ZIG: {"ZbEZSPReceived":"4500040401060402FF00000000D4C8CE8EE2FFFF0718610A0000180002"}
19:35:28 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1030,"srcaddr":"0xE28E","srcendpoint":2,"dstendpoint":255,"wasbroadcast":1,"LinkQuality":97,"securityuse":0,"seqnumber":212,"fc":"0x18","manuf":"0x0000","transact":97,"cmdid":"0x0A","payload":"00001800"}}
19:35:28 ZIG: ZbZCLRawReceived: {"0xE28E":{"0406/0000":0}}
19:35:29 RSL: SENSOR = {"ZbReceived":{"0xE28E":{"Device":"0xE28E","Name":"HueMotion1","Occupancy":0,"Endpoint":2,"LinkQuality":97}}}
19:35:29 ZIG: {"ZbEZSPReceived":"3F0006FCFF0401060402FF00000000D4000000"}

tric111 on 29 Aug 2020

@s-hadinger
As metioned I installed meanwhile a second pair of Ikea-Remote and Ikea Bulb.

In addition I expand the rule for ZbListen after each reboot to:
Rule1 on zbstate#status==0 do zblisten1 0xA0F7 endon on zbstate#status==0 do zblisten2 0x788C endon
Group for first remote is 0xA0F7 --> Group for second remote is 0x788C

I'am not sure if this rule is ok or should be
Rule1 on zbstate#status==0 do zblisten1 0xA0F7 endon on zbstate#status==0 do zblisten1 0x788C endon
Thanks in advance

littlebilly on 30 Aug 2020

The first one is the right one, otherwise you overwrite slot 1 of ZbListen.

You can use backlog to group rules:

Rule1 on zbstate#status==0 do backlog zblisten1 0xA0F7; zblisten2 0x788C endon

s-hadinger on 30 Aug 2020

😄1 👍1

This is the current MQT: message for a device
MQT: tele/DVES_05697B/SENSOR = {"ZbReceived":{"0x4CB8":{"Device":"0x4CB8","Name":"EZ-IKEA-Lampe","Power":0,"Endpoint":1,"LinkQuality":131}}}

Would it be possible to get this one related to every device?
MQT: tele/DVES_05697B/0x4CB8/SENSOR = {"ZbReceived":{"0x4CB8":{"Device":"0x4CB8","Name":"EZ-IKEA-Lampe","Power":0,"Endpoint":1,"LinkQuality":131}}}

This makes it easier to subscribe device related.

littlebilly on 31 Aug 2020

Yes: SetOption89 1

It will use tele/DVES_05697B/4CB8/SENSOR

s-hadinger on 31 Aug 2020

😄1 👍1

@s-hadinger
Thanks a lot for help in the past and may be in advance.
As I have a lot off mqtt devices which are communicating together it would be nice if it were possible to publish the Zigbee sensor value and power- on/off status via rule commands.
Like i did for example in Tasmota Scripting:
`>P
if pwr[1]==1
then
;->color 1
=>publish2 fhem/status/light/eg_wohnzimmer on
endif

if pwr[1]==0
then
=>publish2 fhem/status/light/eg_wohnzimmer off
endif`

littlebilly on 1 Sep 2020

@littlebilly I believe you can do that. Just capture the JSON events and publish the MQTT message you need.

s-hadinger on 2 Sep 2020

@s-hadinger
Thanks a lot for this hint. I found an example in the rules documentation I adjust it for my needs.
It works great.
ON ZBReceived#0x52D1#Power=1 DO publish fhem/status/light/og_wohnzimmer on endon ON ZBReceived#0x52D1#Power=0 DO publish fhem/status/light/og_wohnzimmer off endon

littlebilly on 3 Sep 2020

👍1

@s-hadinger I thinking you is having one OSRAM plug in your test environment.
Little interesting findings in the Netherlands (https://github.com/Koenkk/zigbee-herdsman/issues/204).
OSRAM have firmware updates but i don't knowing witch the IDs Put plug in the stretching.

MattWestb on 6 Sep 2020

@tric111 I think I finally found the issue of the default response. I had a similar issue with a Blitwolf plug sending multiple times the attribute and not receiving acknowledge. I forgot to set the cluster number in the default response. Now it sends the attribute only once. PR is coming shortly.

Edit: PR is merged now.

s-hadinger on 6 Sep 2020

👍1

I see TLS support in the mid-term section. Can someone suggest how to do it manually? I tried using TasmoCompiler (v2.4.5), selected ZigBee and MQTT-over-TLS, flashed it to zbbridge, but the zigbee part fails. I must be missing something (hopefully) obvious.

22:07:53 ZIG: rebooting CC2530 device
22:07:54 ZbInput discarding byte 1A
22:07:54 ZbInput discarding byte C1
22:07:54 ZbInput discarding byte 02
22:07:54 ZbInput discarding byte 02
22:07:54 ZbInput discarding byte 9B
22:07:54 ZbInput discarding byte 7B
22:07:54 ZbInput discarding byte 7E
22:07:58 ZIG: timeout, goto label 99

bogorad on 8 Sep 2020

@s-hadinger
I have just tested it with the Philips SML002 for a few minutes. It works perfectly so far. :) Thanks a lot for your support!

tric111 on 8 Sep 2020

👍1

@bogorad TLS already works. The mid-term proposal is to have it compiled by default in the pre-compiled binaries.

From your logs it looks that you compiled for ZNP (CC2530), not for EZSP (ZBBridge).

Comment out #define USE_ZIGBEE_ZNP and uncomment #define USE_ZIGBEE_EZSP

s-hadinger on 9 Sep 2020

Comment out #define USE_ZIGBEE_ZNP and uncomment #define USE_ZIGBEE_EZSP

Thank you @s-hadinger - everything works perfectly now!

bogorad on 9 Sep 2020

I'm using a Xiaomi button (WXKH01LM) - is press and hold supported?
My observation is single and hold look the same...

Single:
03:52:15 ZIG: {"ZbEZSPReceived":"450000040106000101000100009CFFDE2FD2FFFF0718D40A00001000"}
03:52:15 ZIG: {"ZbEZSPReceived":"450000040106000101000100009DFFDF2FD2FFFF0718D50A00001001"}
03:52:15 MQT: tele/zigbridge/D22F/SENSOR = {"ZbReceived":{"0xD22F":{"Device":"0xD22F","Power":0,"Endpoint":1,"LinkQuality":139}}}
03:52:15 MQT: tele/zigbridge/D22F/SENSOR = {"ZbReceived":{"0xD22F":{"Device":"0xD22F","Power":1,"Endpoint":1,"LinkQuality":142}}}

Long:
03:52:39 ZIG: {"ZbEZSPReceived":"450000040106000101000100009EF4D92FD2FFFF0718D60A00001000"}
03:52:39 MQT: tele/zigbridge/D22F/SENSOR = {"ZbReceived":{"0xD22F":{"Device":"0xD22F","Power":0,"Endpoint":1,"LinkQuality":126}}}
03:52:41 ZIG: {"ZbEZSPReceived":"450000040106000101000100009FFFDD2FD2FFFF0718D70A00001001"}
03:52:41 MQT: tele/zigbridge/D22F/SENSOR = {"ZbReceived":{"0xD22F":{"Device":"0xD22F","Power":1,"Endpoint":1,"LinkQuality":137}}}

Is this expected?

hkrob on 12 Sep 2020

To all, the Zigbee auto-config PR is out. It should solve lots of problems.

@hkrob The Button has no notion of short and long press. It just sends an event when you press and one when you release. It's up to the coordinator to measure time between two events and device whether it's short or long.

I plan to add this but not before some time.

s-hadinger on 12 Sep 2020

👍2 🎉1

Sounds good.. what should we expect from this auto-config to do exactly? Anywhere I can read more?

The timings for long hold,I guessed as much.. not a deal breaker
Very impressed with this little Bridge so far

hkrob on 12 Sep 2020

The detailed description of auto-config is here: https://github.com/arendst/Tasmota/pull/9288

s-hadinger on 12 Sep 2020

My sonoff zigbee bridge lost ability to pair new and existing devices... I use ZHA integration in HA, I see logs from mcu but nothing is discovered.

blackscreener on 13 Sep 2020

@blackscreener I have just recently got ZHA working with my zbbridge...

Flash the firmware again, I used ncp-uart-sw_6.7.6_115200.ota
At the tasmota console, remove all devices, just issue ZbForget until it says no more devices or something like that
issue the following commands on the console:
{"NAME":"ZHA ZBBridge","GPIO":[56,208,0,209,59,58,0,0,0,0,0,0,17],"FLAG":0,"BASE":18}
Rule1 ON System#Boot do TCPStart 8888 endon
Rule1 1
restart 1
Make sure the profile selected in Tasmota -> Configure Module is SonoffZHABridge(0)
remove the ZHA integration in HA
add the ZHA, socket://[zbbridge_ip]:8888

The above worked for me...
Unfortunately, ZHA assigns ridiculous names for entities, I don't understand why it doesn't include the IEEE address or some other unique ID per entity...

hkrob on 13 Sep 2020

@blackscreener Only Zigbee 3 devices that was paired before that's leaving all the time ?
If yes then its because the keystore is populated but not possible updating the new linkkeys.
Its fixed in HA 0.115.0 thats in in beta test for the moment.
Install the last beta ( 0.115.0b8) or waiting around one week for the 0.115.0 release of HA

MattWestb on 13 Sep 2020

@blackscreener Only Zigbee 3 devices that was paired before that's leaving all the time ?
If yes then its because the keystore is populated but not possible updating the new linkkeys.
Its fixed in HA 0.115.0 thats in in beta test for the moment.
Install the last beta ( 0.115.0b8) or waiting around one week for the 0.115.0 release of HA

I can't add even new ikea repeater and existing devices (aqara water and aqara contact sensor) to Zigbee2Tasmota.

blackscreener on 13 Sep 2020

All my old (LL) and new (TB3) IKEA devices and Aqara (magnet2 and weather) is working in Z2M without problems (for some week ago).
I ZHA with updated bellows 20.0 or newer its all working OK.
Is your problems in Z2T or in ZHA ?

MattWestb on 13 Sep 2020

Is there a way to backup and/or manually edit the ZHA integration settings?
I don't like the idea of nicely naming all my entities and losing all that at some point...

hkrob on 13 Sep 2020

All my old (LL) and new (TB3) IKEA devices and Aqara (magnet2 and weather) is working in Z2M without problems (for some week ago).
I ZHA with updated bellows 20.0 or newer its all working OK.
Is your problems in Z2T or in ZHA ?

In both cases.

blackscreener on 13 Sep 2020

Do you have flashing the tasmota bridge with SWD or the "factory upgrade" ?
If the first do one internal flash erase and load bootloaders and EZSP and you have erasing the key store.

MattWestb on 13 Sep 2020

Do you have flashing the tasmota bridge with SWD or the "factory upgrade" ?
If the first do one internal flash erase and load bootloaders and EZSP and you have erasing the key store.

I flashed it from Tasmota GUI. How to do internal flash erase?

blackscreener on 13 Sep 2020

Not possible if not having SWD or J-Tag flashing (not recommended).

For ZHA:
Edit: Not easy but installing ZHA_CUSTOM (https://community.home-assistant.io/t/zha-zigbee-tested-devices-please-add-your-device-results/17718/990 ) point 1, 2 and 4.
Then in HA Developer Tools. services zha_custom.execute with:
command: ezsp_clear_keys

For ZHA problems put on issue in the ZHA repro.

For Z2T put one issue in the Z2T repro.

MattWestb on 13 Sep 2020

This is the github repository for Tasmota. If you have an issue with ZHA please open it on their site. Not here. Thanks

s-hadinger on 13 Sep 2020

👍1

Not possible if not having SWD or J-Tag flashing (not recommended).

For ZHA:
Edit: Not easy but installing ZHA_CUSTOM (https://community.home-assistant.io/t/zha-zigbee-tested-devices-please-add-your-device-results/17718/990 ) point 1, 2 and 4.
Then in HA Developer Tools. services zha_custom.execute with:
command: ezsp_clear_keys

For ZHA problems put on issue in the ZHA repro.

For Z2T put one issue in the Z2T repro.

OK, thank you. Nothing works, I can't add any device in ZHA or Z2T. Maybe my Sonoff Zigbee Bridge is broken.

blackscreener on 13 Sep 2020

Can you try shutting down all your zigbee routers. I've seen a strange issue yesterday

s-hadinger on 13 Sep 2020

@s-hadinger

Can you try shutting down all your zigbee routers. I've seen a strange issue yesterday

Is this a message for all off us to power off Sonoff Zigbee Bridge or only a message for @blackscreener ?

littlebilly on 14 Sep 2020

The message about shutting down the routers was for @blackscreener

I've seen something strange two days ago. After a reboot, the EFR32 wouldn't send anything on the network. Looking with a sniffer, it didn't even send the Link Status beacon, whereas 3 zigbee routers were still sending their own LinkStatus. I reset the encryption key counter, but it didn't change anything. Then I shut down all routers until there was no more Link Status sent by anyone. And the EFR32 started to send again, then everything worked again.

Of course, the problem I had also prevented from any further pairing.

s-hadinger on 14 Sep 2020

@s-hadinger
I don't have got any online routers. Logs from Z2T:

21:43:18 CMD: ZbPermitJoin 1
21:43:18 SRC: WebConsole from 192.168.1.213
21:43:18 CMD: Group 0, Index 1, Command "ZBPERMITJOIN", Data "1"
21:43:18 ZIG: ZbEZSPSend 22003C
21:43:18 ZIG: adding packet to_send, to_ack:7, to_send:7, to_end:7
21:43:18 ZIG: ZbEZSPSend 3600FCFF00003600000000000000021E0103023C01
21:43:18 ZIG: adding packet to_send, to_ack:7, to_send:7, to_end:0
21:43:18 MQT: stat/ZHABridge/RESULT = {"ZbPermitJoin":"Done"}
21:43:18 ZIG: Something to_send, to_ack:7, to_send:7, to_end:1
21:43:18 ZIG: ZbEZSPSentRaw 721F000122003C
21:43:18 ZIG: {"ZbEZSPReceived2":"201F8001220000"}
21:43:18 ZIG: new ack/data received, was 7 now 0
21:43:18 ZIG: freeing packet 7 from memory
21:43:18 ZIG: ZbEZSPSentRaw 83
21:43:18 ZIG: {"ZbEZSPReceived":"220000"}
21:43:18 MQT: tele/ZHABridge/RESULT = {"ZbState":{"Status":21,"Message":"Pairing mode enabled"}}
21:43:18 ZIG: Something to_send, to_ack:0, to_send:0, to_end:1
21:43:18 ZIG: ZbEZSPSentRaw 032000013600FCFF00003600000000000000021E0103023C01
21:43:18 ZIG: {"ZbEZSPReceived2":"3120800136000016"}
21:43:18 ZIG: new ack/data received, was 0 now 1
21:43:18 ZIG: freeing packet 0 from memory
21:43:18 ZIG: ZbEZSPSentRaw 84
21:43:18 ZIG: {"ZbEZSPReceived":"36000016"}
21:43:18 ZIG: {"ZbEZSPReceived2":"412090014500050000360000000000000016FF000000FFFF03023C01"}
21:43:18 ZIG: ZbEZSPSentRaw 85
21:43:18 ZIG: {"ZbEZSPReceived":"4500050000360000000000000016FF000000FFFF03023C01"}
21:43:18 ZIG: Internal ZDO message 0x0036 sent from 0x0000 (broadcast)
21:43:19 ZIG: {"ZbEZSPReceived2":"512090013F0006FCFF0000360000000000000016016600"}
21:43:19 ZIG: ZbEZSPSentRaw 86
21:43:19 ZIG: {"ZbEZSPReceived":"3F0006FCFF0000360000000000000016016600"}

21:53:05 CMD: ZbPermitJoin 0
21:53:05 SRC: WebConsole from 192.168.1.213
21:53:05 CMD: Group 0, Index 1, Command "ZBPERMITJOIN", Data "0"
21:53:05 ZIG: ZbEZSPSend 220000
21:53:05 ZIG: adding packet to_send, to_ack:1, to_send:1, to_end:1
21:53:05 ZIG: ZbEZSPSend 3600FCFF00003600000000000000031E0103030001
21:53:05 ZIG: adding packet to_send, to_ack:1, to_send:1, to_end:2
21:53:05 MQT: stat/ZHABridge/RESULT = {"ZbPermitJoin":"Done"}
21:53:05 ZIG: Something to_send, to_ack:1, to_send:1, to_end:3
21:53:05 ZIG: ZbEZSPSentRaw 16210001220000
21:53:05 ZIG: {"ZbEZSPReceived2":"62218001220000"}
21:53:05 ZIG: new ack/data received, was 1 now 2
21:53:05 ZIG: freeing packet 1 from memory
21:53:05 ZIG: ZbEZSPSentRaw 87
21:53:05 ZIG: {"ZbEZSPReceived":"220000"}
21:53:05 MQT: tele/ZHABridge/RESULT = {"ZbState":{"Status":21,"Message":"Pairing mode enabled"}}
21:53:05 ZIG: Something to_send, to_ack:2, to_send:2, to_end:3
21:53:05 ZIG: ZbEZSPSentRaw 272200013600FCFF00003600000000000000031E0103030001
21:53:05 ZIG: {"ZbEZSPReceived2":"7322800136000077"}
21:53:05 ZIG: new ack/data received, was 2 now 3
21:53:05 ZIG: freeing packet 2 from memory
21:53:05 ZIG: ZbEZSPSentRaw 80
21:53:05 ZIG: {"ZbEZSPReceived":"36000077"}
21:53:05 ZIG: {"ZbEZSPReceived2":"032290014500050000360000000000000077FF000000FFFF03030001"}
21:53:05 ZIG: ZbEZSPSentRaw 81
21:53:05 ZIG: {"ZbEZSPReceived":"4500050000360000000000000077FF000000FFFF03030001"}
21:53:05 ZIG: Internal ZDO message 0x0036 sent from 0x0000 (broadcast)
21:53:06 ZIG: {"ZbEZSPReceived2":"132290013F0006FCFF0000360000000000000077016600"}
21:53:06 ZIG: ZbEZSPSentRaw 82
21:53:06 ZIG: {"ZbEZSPReceived":"3F0006FCFF0000360000000000000077016600"}

blackscreener on 14 Sep 2020

The log above just show that Permit Join command was successful, and the ZDO broadcast message ZDO_Mgmt_Permit_Joining_req was sent and received by the loopback. There's nothing more.

Unfortunately we'll don't know what happens without a Zigbee sniffer.

s-hadinger on 14 Sep 2020

The log above just show that Permit Join command was successful, and the ZDO broadcast message ZDO_Mgmt_Permit_Joining_req was sent and received by the loopback. There's nothing more.

Unfortunately we'll don't know what happens without a Zigbee sniffer.

I don't know what's going on, but it's working now... Thanks for helping!
obraz

blackscreener on 14 Sep 2020

🚀1 👍1

FYI, major new Zigbee feature in EmberZNet 6.8 and later is support for concurrent multiple PANs (multi-PAN) on one coordinator:

https://www.silabs.com/documents/public/application-notes/an724-multi-network.pdf

PS: Slightly off-topic but FYI posted a request for EmberZNet 6.8.0 (6.8 / 6.8.x / 6.8.x.x) NCP application firmware here -> https://github.com/arendst/Tasmota/issues/9316

Hedda on 15 Sep 2020

@Hedda please do spam. you have already opened a extra issue with a feature request for the same.

Jason2866 on 18 Sep 2020

In Home Assistant Aqara Wireless Remote Switch (Double Rocker "lumi.sensor_86sw2") show only battery power.

chex01 on 19 Sep 2020

In Home Assistant Aqara Wireless Remote Switch (Double Rocker "lumi.sensor_86sw2") show only battery power.

Use zha_event under development tools -> listen to events to capture clicks. You can do automation like this from that info:

`automation:

alias: 'Switch Bedroom Single Click'
trigger:
- event_data:
  
  device_ieee: 00:15:8d:00:03:7c:aa:aa
  
  unique_id: 00:15:8d:00:04:3c:59:0f:1:0x0012
  
  command: single
  
  args:
  
  value: 1
  
  event_type: zha_event
  
  platform: event
  
  action:
  
  service: light.toggle
  
  data:
  
  entity_id: light.bulb_bedroom
  
  transition: 1
  
  brightness: 255`

thehijacker on 22 Sep 2020

👍1

@MattWestb I checked the MfgTokens of a stock Sonoff ZBBridge, but no values are set for any of the parameters (manufacturing string nor board name). I will therefore not report MFGTokens in Tasmota.

s-hadinger on 30 Sep 2020

👍1

FYI @arendst

Zigbee friendly names are not triggering rules

Latest 8.5.1 & ncp-uart-sw_6.7.6_115200.ota

zbname 0x5903 myfriend
Works : Rule1 on zbreceived#0x5903#power=2 do … ENDON
Not works: Rule1 on zbreceived#myfriend#power=2 do … ENDON

outoforder20 on 10 Oct 2020

@outoforder20 No problem at all:

12:40:00 CMD: so100
12:40:00 MQT: stat/zbbridge1/RESULT = {"SetOption100":"ON"}
12:40:04 CMD: so112
12:40:04 MQT: stat/zbbridge1/RESULT = {"SetOption112":"OFF"}

12:40:17 CMD: zbstatus
12:40:17 MQT: stat/zbbridge1/RESULT = {"ZbStatus1":[{"Device":"0xCC49","Name":"Switch4"},{"Device":"0x508B","Name":"Tradfri4"},{"Device":"0x8AC9","Name":"Cube"},{"Device":"0x5CDC","Name":"Switch3"}]}

12:40:30 CMD: rule1
12:40:30 MQT: stat/zbbridge1/RESULT = {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Length":299,"Free":212,"Rules":"on tradfri4#power=2 do publish cmnd/midesk/power1 2 endon on tradfri4#dimmerup do publish cmnd/midesk/dimmer + endon on tradfri4#dimmerstepdown do publish cmnd/midesk/dimmer - endon on tradfri4#arrowclick=1 do publish cmnd/midesk/ct - endon on tradfri4#arrowclick=0 do publish cmnd/midesk/ct + endon"}

12:40:45 MQT: tele/zbbridge1/SENSOR = {"Tradfri4":{"Device":"0x508B","Name":"Tradfri4","0006!02":"","Power":2,"Endpoint":1,"LinkQuality":118}}
12:40:45 RUL: TRADFRI4#POWER=2 performs "publish cmnd/midesk/power1 2"
12:40:45 MQT: cmnd/midesk/power1 = 2
12:40:45 ZIG: Auto-responder: ZbSend {"Device":"0x0000","Cluster":"0x0006","Endpoint":1,"Response":"0006/0000":0}

arendst on 10 Oct 2020

so100

SetOption83 | Uses Zigbee device friendly name instead of 16 bits short addresses as JSON key when reporting values and commands0 = JSON key as short address1 = JSON key as friendly name
-- | --

SetOption83 1
solved
Thank you

outoforder20 on 10 Oct 2020

I'm not an expert in the field, but is it already possible to dump the topology of attached devices including routers and such?

Thanks!

AlessandroEmm on 21 Oct 2020

Not possible right now. I need to dive into the Zigbee standard, I don't know how to ask a router for the list of its children.

s-hadinger on 21 Oct 2020

Take one look on ZHA-MAP.
Its recently updated and looks working well with EZSP thru bellows and zigpy.

The bad thing its general for all zigpy radio so need tracing thru zigpy to bellows for getting the commands sended to the NCP.

MattWestb on 21 Oct 2020

Thanks @MattWestb
This is exactly what I was looking for. I will analyze how they are doing.

s-hadinger on 21 Oct 2020

That's great !!
Had being easier if it was only one lib and getting the commands for the EZSP without reading and analysing multi levels.

Keep coding strong !!!

MattWestb on 21 Oct 2020

By the way its also doing the same for the TI CC-2530 thru zigpy-znp and zigpy if you like testing doing the same with CC-2530 (if it have enough resources for doing that) :-))

MattWestb on 21 Oct 2020

Got it: https://github.com/zigpy/zigpy/blob/96c8d6a0c5ccd7f9b0e3654d553d736b49bc1967/zigpy/neighbor.py#L105

I need to use Mgmt_Lqi_req

s-hadinger on 21 Oct 2020

Refreshing the list:

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. _Working on it now_
~~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 and 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 #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

s-hadinger on 24 Oct 2020

👍1

@AlessandroEmm take a look at ZbMap new command described in #9651. This is the basic block to build the Zigbee topology.

s-hadinger on 28 Oct 2020

👍1

Thanks for the amazing work that makes our lifes a little better. I'll add a few comments but will spread them in different entries in case somebody wants to reply or comment.
Here comes the first: Any clue on ZB Bridge limit? IN my case it seems that above 20 devices weird things start to happen like bridge not registering (or fwd'ing to mqtt) some Zb packets. Devices are there, ZbPing sort of works but some sensors are not listened to for some time.
May be a limitation of the ESP8266 chip/memory ??

alsa-kode on 2 Nov 2020

Hi there; weird behaviour from Xiami/Aquara PIR. The 'Occupancy' 0/1 attribute name changes erratically to "Xiaomi_64" 0/1
Node-RED flows require to look into both keys because key name keeps switching between these two.
Has anyone experienced something similar?

alsa-kode on 2 Nov 2020

The 'Occupancy' 0/1 attribute name changes erratically to "Xiaomi_64" 0/1

Checked the logs for the past week. Indeed sometimes Aqara PIR/luminance sensor does report Xiaomi_64. However, it happens only when it reports "0" (no-motion). Sometimes it's Occupancy=0, sometimes it's Xiaomi_64=0. But never Xiaomi_64=1. Since I don't use no-motion, I just ignore it.

In any case, obviously a bug.

bogorad on 2 Nov 2020

The 'Occupancy' 0/1 attribute name changes erratically to "Xiaomi_64" 0/1

Checked the logs for the past week. Indeed sometimes Aqara PIR/luminance sensor does report Xiaomi_64. However, it happens only when it reports "0" (no-motion). Sometimes it's Occupancy=0, sometimes it's Xiaomi_64=0. But never Xiaomi_64=1. Since I don't use no-motion, I just ignore it.

In any case, obviously a bug.

Thanks! Interesting... I'll look into it; I did not realise that was happening only when Occupancy is false.

alsa-kode on 2 Nov 2020

Thanks! Interesting... I'll look into it; I did not realise that was happening only when Occupancy is false.

Actually, it's only instead of occupancy=0. Never occcupancy=0 _and_ xiaomi_64=0.

bogorad on 2 Nov 2020

@alsa-kode There is currently a limit in Tasmota of 32 zigbee devices in memory (i.e. displayed in the web UI), it will probably be raised to 48. On EFR32, there is a limit of 32 direct children, but I believe you can go beyond with zigbee routers.

I only have 16 devices in my network, so I can't confirm it works beyond 20 devices.

Xiaomi_64=1 is only displayed if Tasmota can't get the ModelId of the device. It's strange that this happens from time to time.

@bogorad This is weird, Xiaomi Aqara PIR sensor i supposed to never report Xiaomi_64=0.

Anyways, could you both upgrade to the latest 9.0.0.3 version. There has been some changes in the configuration storage of devices and some bug fixes that could be related to these issues.

s-hadinger on 2 Nov 2020

Anyways, could you both upgrade to the latest 9.0.0.3 version. There has been some changes in the configuration storage of devices and some bug fixes that could be related to these issues.

I'm building my own binaries, with TLS+TLS_CA_CERT+PING enabled, using docker (benzino77/tasmocompiler). I did 'refresh source' but it still offers only 8.5.1. Can you advise how to get the latest?

bogorad on 2 Nov 2020

Anyways, could you both upgrade to the latest 9.0.0.3 version. There has been some changes in the configuration storage of devices and some bug fixes that could be related to these issues.

Thanks; I've seen 9.0.0.3 on the dev branch. Silly question, though. I lost devices on last update and had to pair back everything. Will a conf backup and restore prevent from losing devices information?
Any difference from OTA upgrade vs file upgrade?

Thanks a lot!!

alsa-kode on 3 Nov 2020

I'm building my own binaries, with TLS+TLS_CA_CERT+PING enabled, using docker (benzino77/tasmocompiler). I did 'refresh source' but it still offers only 8.5.1. Can you advise how to get the latest?

hum... so.. I suppose that means you're not using the ZbBridge HW, are you? Have you built something with more memory or processing power DIY board?

alsa-kode on 3 Nov 2020

suppose that means you're not using the ZbBridge HW, are you

Of course, I am using the standard ZbBridge HW. As was discussed, the hardware has lots of free ROM/RAM space, and you can compile in whatever you need. I'm using an internet-based MQTT-broker for one of my projects, hence the TLS/PING additions.

bogorad on 3 Nov 2020

Features we will not support

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

TouchLink

Zigbee device OTA upgrade

Do you still think that Zigbee device OTA upgrade is really a niche feature? I would argue that it is a must-have feature.

Maybe don't need automatic download and update but need to somehow be able to force device OTA firmware image updates.

How else do you update the firmware on Zigbee devices?

The alternate is un-pair each device and re-pair it with Zigbee hub that does support OTA updates for device firmware upgrades.

Zigbee device Over-The-Air firmware updates is a feature that is available in both zigpy and Zigbee2MQTT/zigbee-herdsman.

Please see this reference with better arguments that I can provide myself -> - https://github.com/zigpy/zigpy/issues/154

Hedda on 3 Nov 2020

@alsa-kode You're not supposed to lose Zigbee devices configuration with any upgrade. But since you're not the first to report this, I will investigate.

s-hadinger on 3 Nov 2020

@alsa-kode You're not supposed to lose Zigbee devices configuration with any upgrade. But since you're not the first to report this, I will investigate.

Thanks. Upgraded. Smooth. So far so good. Will continue adding devices and will provide feedback.

alsa-kode on 3 Nov 2020

Hi there; not sure this is somehow related to the number of devices but.. #20, Sonoff zigbee door sensor reports:
MQT: tele/SonoffZBGW/RESULT = {"ZbRouteError": "ShortAddr":"0xEE4C","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}
and sensor works for a while and then stops working until reset button is pressed. Internal led seems to show normal behaviour.

alsa-kode on 3 Nov 2020

I was wrong, Xiaomi_64 happens even when Occupancy=1.

bogorad on 3 Nov 2020

MAC_INDIRECT_TIMEOUT

I only encounter this right after pairing a new device.

bogorad on 3 Nov 2020

I was wrong, Xiaomi_64 happens even when Occupancy=1.

urgg.. tx for the heads up; will have to bring 'Xiaomi_64' back to my flows :)

alsa-kode on 3 Nov 2020

@alsa-kode - When pairing a Sonoff Door Sensor, I trigger the sensor repeatedly until all messaging has been completed and ZoneStatusChange messages start...

grobasoz on 4 Nov 2020

@alsa-kode - When pairing a Sonoff Door Sensor, I trigger the sensor repeatedly until all messaging has been completed and ZoneStatusChange messages start...
I do that too and it works for some time. May be a couple of hours.. and then, eventually no response. Tried forgetting and pairing again several times. Same issue.
Now, another sensor (last addition) is having same issue. It is a temp sensor from Sonoff. Got 4 already working perfectly and now this:
13:02:58 ZIG: {"ZbEZSPReceived":"800042E7D4"}
13:02:58 MQT: tele/SonoffZBGW/RESULT = {"ZbRouteError":{"ShortAddr":"0xD4E7","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}
13:03:15 CMD: ZbPing 0xD4E7
13:03:15 MQT: stat/SonoffZBGW/RESULT = {"ZbPing":"Done"}
13:03:22 ZIG: {"ZbEZSPReceived":"800042E7D4"}
13:03:22 MQT: tele/SonoffZBGW/RESULT = {"ZbRouteError":{"ShortAddr":"0xD4E7","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}
13:03:32 ZIG: {"ZbEZSPReceived":"800042E7D4"}
13:03:32 MQT: tele/SonoffZBGW/RESULT = {"ZbRouteError":{"ShortAddr":"0xD4E7","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}
13:03:41 ZIG: {"ZbEZSPReceived":"800042E7D4"}
13:03:41 MQT: tele/SonoffZBGW/RESULT = {"ZbRouteError":{"ShortAddr":"0xD4E7","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}

alsa-kode on 4 Nov 2020

Paired an IKEA E1743 to zbbridge successfully. In less than a day the battery was dead. Put a new battery in. Same story, less than 24hrs later the battery is dead. Didn't have any problems with cc2531+zigbee2mqtt.

bogorad on 4 Nov 2020

@bogorad Thanks for the additional detail. The Mi-Door can report its status change via 2 different types of message.

Through a 0500<00 alarm message (compliant with standard ZCL). It is converted to Occupancy in Z2T although it should rather be an alarm instead - consider this as a bug
Through a 0000/FF01 or 0000/FF02 attribute and a proprietary encoding (not compliant with standard ZCL). In this case there needs to be device-specific decoding. Currently Mi-Door is not recognized.

What I propose is the following:

in case on Mi-Door, add a specific decoder to send "Alarm":0/1 instead of "Occupancy":0/1
add a decoder for the Mi-Door proprietary FF01-FF02 attributes.

@alsa-kode MAC_INDIRECT_TIMEOUT means that the device was unreachable. Most of the time you can ignore it.

@bogorad I'm afraid I just experienced the same issue with IKEA Remote. It seems the device drains the battery very quickly whenever Z2T asks for attribute reporting. For now use SetOption110 1 to disable auto-reporting and pair again the IKEA remote. You can then revert to SetOption110 0.

I will need to add IKEA specific code to NOT report battery status.

s-hadinger on 4 Nov 2020

@s-hadinger thank you so much! I'll try IKEA remote right away.

Here's something strange: the same door sensor reports both Power and Xiaomi_64:

bogorad on 4 Nov 2020

Interesting. Would you have weblog 3 level logs for these events?

s-hadinger on 4 Nov 2020

Interesting. Would you have weblog 3 level logs for these events?

No - I'm only logging the /SENSOR & /RESULT messages (via mqtt -> influxdb), sorry.

I just enabled logging, will report when data is available.

bogorad on 5 Nov 2020

Here goes. It's an Aqara Door sensor, it's mounted on a washing machine door, no one was in the room, so it's 100% false alarm:

2020-11-05 02:11:33 A4-CF-12-D7-F8-BA 02:11:33 ZIG: {"ZbEZSPReceived":"590038AFA301A004008D1500BCCB010000"} 2020-11-05 02:11:33 A4-CF-12-D7-F8-BA 02:11:33 ZIG: {"ZbEZSPReceived":"45000004010000010100010000D4BCCB38AFFFFF261C5F112D0A01FF421D0121C70B0328190421A81305212500062401000000000A21892864100104"} 2020-11-05 02:11:33 A4-CF-12-D7-F8-BA 02:11:33 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":0,"srcaddr":"0xAF38","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":89,"securityuse":0,"seqnumber":212,"fc":"0x1C","manuf":"0x115F","transact":45,"cmdid":"0x0A","payload":"01FF421D0121C70B0328190421A81305212500062401000000000A218928641001"}} 2020-11-05 02:11:33 A4-CF-12-D7-F8-BA 02:11:33 ZIG: ZbZCLRawReceived: {"0xAF38":{"0000/FF01":"0121C70B0328190421A81305212500062401000000000A218928641001","Endpoint":1,"LinkQuality":89}} 2020-11-05 02:11:33 A4-CF-12-D7-F8-BA 02:11:33 MQT: zig/A4-CF-12-D7-F8-BA/AF38/SENSOR = {"ZbReceived":{"0xAF38":{"Device":"0xAF38","BatteryVoltage":3.01,"BatteryPercentage":100,"Xiaomi_64":1,"Endpoint":1,"LinkQuality":89}}}

bogorad on 5 Nov 2020

Here's a proper triggering:

https://pastebin.com/nkSyJMGV

bogorad on 5 Nov 2020

@s-hadinger is there a way to make zbbridge use IEEEAddr in messages instead of "short" addresses? Like SetOption89 1 or SetOption83 1, but for IEEEAddr?

I can already 'send' to an IEEEAddr but would like to also receive something like:

prefix/AA-BB-CC-DD-EE-FF/IEEEAddr/SENSOR

This way I won't have to keep the correlation table (short <=> IEEEAddre) in case of re-pairing a sensor.

bogorad on 5 Nov 2020

@bogorad I will integrate the Door sensor shortly, thanks for the logs. This is exactly what I needed.

Currently you can't use the long address in the topic. The main reason is that Tasmota has no guarantee of knowning the IEEE address. For example, if you restart the device and wipe the flash, you will start receiving zigbee traffic with only a short address and no clue what the long addresses are. Additionally, probing for IEEE address is not always working.

As an alternative, I suggest you use FriendlyName instead. They are linked to both short and long addresses, and don't change if you re-pair the device.

s-hadinger on 6 Nov 2020

Setting the friendly name to the device IEEE and you can using it all over if tasmota is accepting that.

MattWestb on 6 Nov 2020

Setting the friendly name to the device IEEE and you can using it all over if tasmota is accepting that.

Great idea, thank you! I'll try that.

bogorad on 6 Nov 2020

👍1

@bogorad #9759 now contains support for Mi Door and for contacts in general.

Some devices may need ZbProbe <device> or re-pairing if you prefer.

Also please note that the attribute is now Contact instead of Occupancy. Occupancy is only for PIR sensors.

Edit: persistence of device type does not work, I need to add it. Mi door is still ok but the general support of alarms does not yet a survive a restart.

s-hadinger on 6 Nov 2020

Another Zigbee-related issue: when doing SetOption112 1 Tasmota ignores the topic setting. Is this by design?

Topics set:
RESULT = {"Topic":"A4-CF-12-D7-F9-67"}

RESULT = {"FullTopic":"housematix/zigbee/%topic%"}

Turning both 89 and 112 off:

15:01:27 CMD: backlog SetOption89 0; SetOption112 0;
15:01:27 MQT: housematix/zigbee/A4-CF-12-D7-F9-67/RESULT = {"SetOption89":"OFF"}
15:01:28 MQT: housematix/zigbee/A4-CF-12-D7-F9-67/RESULT = {"SetOption112":"OFF"}
15:01:33 MQT: housematix/zigbee/A4-CF-12-D7-F9-67/SENSOR = {"00158D00010B2FB5":{"Device":"0x82F2","Name":"00158D00010B2FB5","Power":0,"Endpoint":1,"LinkQuality":116}}
15:01:34 MQT: housematix/zigbee/A4-CF-12-D7-F9-67/SENSOR = {"00158D00010B2FB5":{"Device":"0x82F2","Name":"00158D00010B2FB5","Power":1,"Endpoint":1,"LinkQuality":118}}

Turning 89 on:
15:01:42 CMD: SetOption89 1
15:01:43 MQT: housematix/zigbee/A4-CF-12-D7-F9-67/RESULT = {"SetOption89":"ON"}
15:01:45 MQT: housematix/zigbee/A4-CF-12-D7-F9-67/82F2/SENSOR = {"00158D00010B2FB5":{"Device":"0x82F2","Name":"00158D00010B2FB5","Power":0,"Endpoint":1,"LinkQuality":131}}
15:01:46 MQT: housematix/zigbee/A4-CF-12-D7-F9-67/82F2/SENSOR = {"00158D00010B2FB5":{"Device":"0x82F2","Name":"00158D00010B2FB5","Power":1,"Endpoint":1,"LinkQuality":95}}

Turning 112 on:
15:01:51 CMD: SetOption112 1
15:01:51 MQT: housematix/zigbee/A4-CF-12-D7-F9-67/RESULT = {"SetOption112":"ON"}
15:01:54 MQT: tele/00158D00010B2FB5/SENSOR = {"00158D00010B2FB5":{"Device":"0x82F2","Name":"00158D00010B2FB5","Power":0,"Endpoint":1,"LinkQuality":105}}
15:01:55 MQT: tele/00158D00010B2FB5/SENSOR = {"00158D00010B2FB5":{"Device":"0x82F2","Name":"00158D00010B2FB5","Power":1,"Endpoint":1,"LinkQuality":129}}

bogorad on 8 Nov 2020

Zigbee Light improvement

Publish ZbLight JSON message on a per device topic like tele/Zigbee/5ADF/LIGHTSTATEor something else.

Home Assistant could subscribe to this topic for state/brightness/color as every keys are present (Power, Dimmer, X, Y, ColorMode, Hue)
Could be useful, no ?

Bibinsa on 10 Nov 2020

@Bibinsa the advice here will be to create rules to have it publish like that. Unfortunately, I haven't found a howto/guide to make it easier. So for myself I created home assistant automations to demultiplex sensors. I haven't implemented lights or switches, which is the last on my list but you can have a look here to see what I have done for sensors. The next step is to implement switches/lights then I think it will be mostly complete. I even implemented auto discovery for the sensors, you only need to set the names on the gateway using something like ZbName 0x4d67,Lounge

tinuva on 10 Nov 2020

@tinuva thanks !!

You did not try SetOption89 to have a unique device topic based on Zigbee device ShortAddr ?

Bibinsa on 10 Nov 2020

The doc has the following example for the Aqara Leak sensors:

In this example sensor reports on `0x099F` and sends an mqtt message to topic `stat/leak_sensor/LEAK`:

Rule
  on ZbReceived#0x099F#0500!00=010000FF0000 do publish stat/leak_sensor/LEAK ON endon 
  on ZbReceived#0x099F#0500!00=000000FF0000 do publish stat/leak_sensor/LEAK OFF endon

I simply couldn't get this to work.

The Aqara Leak sensors are reporting < instead of ! as in the example (0500<00=010000FF0000 instead of 0500!00=010000FF0000) but changing from ! to < in the rule also didn't make it work.

What worked at the end is the following:

ZbName 0xC6AC,AqaraLeak1
SetOption83 1
SetOption112 1
SetOption89 1

Rule1 
  on zbreceived#AqaraLeak1#ZoneStatusChange=1 do publish stat/AqaraLeak1/LEAK ON endon
  on zbreceived#AqaraLeak1#ZoneStatusChange=0 do publish stat/AqaraLeak1/LEAK OFF endon

Log:

17:23:32 MQT: stat/Sonoff-ZbBridge-1/RESULT = {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Length":347,"Free":164,"Rules":"on zbreceived#AqaraLeak1#ZoneStatusChange=1 do publish stat/AqaraLeak1/LEAK ON endon on zbreceived#AqaraLeak1#ZoneStatusChange=0 do publish stat/AqaraLeak1/LEAK OFF endon on zbreceived#AqaraLeak2#ZoneStatusChange=1 do publish stat/AqaraLeak2/LEAK ON endon on zbreceived#AqaraLeak2#ZoneStatusChange=0 do publish stat/AqaraLeak2/LEAK OFF endon"} 17:23:40 ZIG: {"ZbEZSPReceived":"45000004010005010100010000BBD0D0ACC6FFFF09196F00010000FF0000"} 17:23:40 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1280,"srcaddr":"0xC6AC","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":102,"securityuse":0,"seqnumber":187,"fc":"0x19","manuf":"0x0000","transact":111,"cmdid":"0x00","payload":"010000FF0000"}} 17:23:40 ZIG: ZbZCLRawReceived: {"0xC6AC":{"0500<00":"010000FF0000","ZoneStatusChange":1,"Endpoint":1,"LinkQuality":102}} 17:23:40 MQT: tele/AqaraLeak1/SENSOR = {"ZbReceived":{"AqaraLeak1":{"Device":"0xC6AC","Name":"AqaraLeak1","0500<00":"010000FF0000","ZoneStatusChange":1,"Endpoint":1,"LinkQuality":102}}} 17:23:40 RUL: ZBRECEIVED#AQARALEAK1#ZONESTATUSCHANGE=1 performs "publish stat/AqaraLeak1/LEAK ON" 17:23:40 SRC: Rule 17:23:40 CMD: Group 0, Index 1, Command "PUBLISH", Data "stat/AqaraLeak1/LEAK ON" 17:23:40 MQT: stat/AqaraLeak1/LEAK = ON

Interestingly, when I change from friendly name to shortaddr it also doesn't work (no MQTT message when the sensor reports a leak).

on zbreceived#**0xC6AC**#ZoneStatusChange=1 do publish stat/AqaraLeak1/LEAK ON endon
on zbreceived#**0xC6AC**#ZoneStatusChange=0 do publish stat/AqaraLeak1/LEAK OFF endon]

Log:

17:21:29 CMD: rule1 17:21:29 SRC: WebConsole from 192.168.2.133 17:21:29 CMD: Group 0, Index 1, Command "RULE", Data "" 17:21:29 MQT: stat/Sonoff-ZbBridge-1/RESULT = {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Length":339,"Free":172,"Rules":"on zbreceived#0xC6AC#ZoneStatusChange=1 do publish stat/AqaraLeak1/LEAK ON endon on zbreceived#0xC6AC#ZoneStatusChange=0 do publish stat/AqaraLeak1/LEAK OFF endon on zbreceived#AqaraLeak2#ZoneStatusChange=1 do publish stat/AqaraLeak2/LEAK ON endon on zbreceived#AqaraLeak2#ZoneStatusChange=0 do publish stat/AqaraLeak2/LEAK OFF endon"} 17:21:52 ZIG: {"ZbEZSPReceived":"45000004010005010100010000B9DCD3ACC6FFFF09196D00010000FF0000"} 17:21:52 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1280,"srcaddr":"0xC6AC","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":110,"securityuse":0,"seqnumber":185,"fc":"0x19","manuf":"0x0000","transact":109,"cmdid":"0x00","payload":"010000FF0000"}} 17:21:52 ZIG: ZbZCLRawReceived: {"0xC6AC":{"0500<00":"010000FF0000","ZoneStatusChange":1,"Endpoint":1,"LinkQuality":110}} 17:21:52 MQT: tele/AqaraLeak1/SENSOR = {"ZbReceived":{"AqaraLeak1":{"Device":"0xC6AC","Name":"AqaraLeak1","0500<00":"010000FF0000","ZoneStatusChange":1,"Endpoint":1,"LinkQuality":110}}} 17:22:17 ZIG: {"ZbEZSPReceived":"45000004010005010100010000BAE8D6ACC6FFFF09196E00000000FF0000"} 17:22:17 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":1280,"srcaddr":"0xC6AC","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":118,"securityuse":0,"seqnumber":186,"fc":"0x19","manuf":"0x0000","transact":110,"cmdid":"0x00","payload":"000000FF0000"}} 17:22:17 ZIG: ZbZCLRawReceived: {"0xC6AC":{"0500<00":"000000FF0000","ZoneStatusChange":0,"Endpoint":1,"LinkQuality":118}} 17:22:17 MQT: tele/AqaraLeak1/SENSOR = {"ZbReceived":{"AqaraLeak1":{"Device":"0xC6AC","Name":"AqaraLeak1","0500<00":"000000FF0000","ZoneStatusChange":0,"Endpoint":1,"LinkQuality":118}}}

Is the original example in the doc or using the shortaddr insteaed the friendly name somethign that should work on tasmota-zbbridge 9.1.0.1?

Apologies if this is the wrong place. I found my solution so don't really need help, I just wanted to see if there is an error in the doc or in the code or if I overlooked something.

alexhk on 12 Nov 2020

👍1

How do you pair a device via a router/repeater instead of on the coordinator/gateway?
Do you just use ZbPermitjoin 1 but then with the device you pairing have to be outside the range of the coordinator but in range of a router?

tinuva on 19 Nov 2020

With Sonoff zigbee bridge its opening the hole network for joining and the joining device is talking with the for the moment "best" router and connecting to it and joining thru it.
Routers is normally changing with its talkin to dynamic and end device is normally very unwilling changing its parent(router).
Best paring end device after adding all router device and putting it near the router you like it to using then pairing it and hope its working well.

In ZHA you can also pairing devices thru one router that you like ("Add devices via this device" in the device config) and its making much easier with Xiaomi devices :-))

MattWestb on 19 Nov 2020

Another Zigbee-related issue: when doing SetOption112 1 Tasmota ignores the topic setting. Is this by design?

No ideas? Sorry for repeating the question. Should I just work around this?

bogorad on 19 Nov 2020

Yes please.

s-hadinger on 19 Nov 2020

All the items for short and mid term are now complete.

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 #8202~~

Closing this issue.

s-hadinger on 22 Nov 2020

👍1

Well done !!!!
If you like having more to do then i have some ideas ;-)

MattWestb on 22 Nov 2020

You can always shoot new ideas.

I will probably add some items in the web UI.

s-hadinger on 22 Nov 2020

❤1 👍1

Features we will not support

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

TouchLink

Zigbee device OTA upgrade

Would like to bump the suggestion to reconsider support for "OTA upgrades" as I would argue that it is not really a niche feature.

Hedda on 24 Nov 2020

I like putting out some pro and cons for things to add or not and how.

Touchlink reset.

I like the touchlink funktionality for resetting devices that is not linking being requested to "factory new" sate. Its can happen that lights its timing out and starting one LL network of its own and is not so easy getting in pairing more (have using deCONZ old web app 3 time the last half year for doing that). Also many users cant triggering the reset on some IKEA bulbs that can being little "kinky" with the on/off timing.

Touchlink network parameter configuration.

In some cases it can being good to initiating the networks parameter on one device so it can joining the network in the network layer and sending one device announcement that the TC is getting and forcing doing one normal classical pairing. One example one user have many bild in lights that is very hard to getting physical resetted without destroying more or less the hole kitchen / bath.
If getting problem in the network and need resetting / rejoining some the lights its only to using the master power switch for the apartment / house for on/off if the devices is supporting that (many relays / dimmers is not) or liking that. Touch link resetting and hoping the lights like joining your network for the moment.
If can sending the network parameters to the device then its coming back to your network and can being configured of the NCP / TC.

Touchlink Groupe configuration.

More or less all IKEA controlling devices and some other have reduced functionality by not have inplantig all cluster they is using (tuya is doing the same new) that normally is being configured by the IKEA GW or other IKEA controlling devices with touchlink.
One example: The zigbee 3 firmware or the 5 button remote have next and previous scene on left and right button that is sending one special command (well known ones) to one groupe. The problem is that it have on/off, light level and groupe cluster that can being bounded and working OK but it does not having any scene cluster so not possible to binding where its sending the scenes command and falling back to its default groupe 0xff09.
The result is the On/Off and light levels is working with user configured groups but the sene commands is being sent to 0xff09. If adding the group 0xff09 in ikea bulbs and adding scene to the group the scene command remote is working 100%. The bad is all remotes if having more remotes the is all sending screen commands the the same group and On/off, light level commands is going the same or if having being bonded to other group they is going it it.

One more IKEA device that is having group problem is the signal repeater that also not having all the cluster exposed and need one groupe for acting as one relay for command sended from the open/close switch to the blinds.

Both devices is getting one group then being joined thru touchlink with one command that can only being sent thru touchlink (by Zigbee 3 standard / ZCL). Both devices is using the group for doing internal binding of all cluster and the magic is working.

By implanting adding groupe thru touchlink all IKEA devices can being configured so they is working fully with our open zigbee systems with out the limits we having to day (Screen commands from remote not working and one signal repeater that is only floating around and not acting a one command relay for the blinds)

deCONZ devs and some HUE fanaticer is saying its not possible using touchling in one zigbee 3 network with trust center but that is 110% wrong. Touchlink joining its the primary joining method for lights in the latest zigbee 3 papers but its not so easy to implanting in zigbee 3 system with TC (and definitely not easier in one LL system with zigbee 3 support as IKEAs GW).

Not implanting touchlink in tasmotas Sonoff TBBridge.

Enough with IKEA Touchlink things and looking little wider around.
As Stephan have saying Tasmota on ESP have limited RAM and flash and its useless putting in more things that is making all other things more or less impossible to working.

But in fact we is having one good working zigbee bridge and all other tasmota things so no reason to breaking them so better leaving it and adding support for more devices (yes pleas adding my new tuya TRVs !!).

OTA for all possible devices.

I like it but its one 90% no go in ZBBridge for my.

Other scenarios for Tasmota.

One of the best thing with the bridge is the serial over tcp/ip tunneling that is making it working great with ZHA and and also as one very good zigbee sniffer that i have suing for sniffing zigbee traffic then joining some IXX devices with TYY to one IXX gateway.

Tasmota is having a very powerful roulette system that i like very much. If it was one easy way sending zigbee commands from tasmota to one large zigbee network that is having one TC like deCONZ its opening many doors for getting very good functions that is autonom and working without extra computer, network and programs like MQTT, node red and so on. Then can still being there bit if they is lost the tasmota can still doing all the things and steering devices in the zigbee network. If tasmota its falling the zigbee network is still working with lights and so on but some goodis is not working.

I have looking and thinking if its possible doing that with one tasmota ZBBridge but its not working then its one coordinator with trust center and therefore it cant joining one network with trustcenter (lal zigbee standard).

Then I was reading more of how lights and controlling devices is working in zigbee 3 with the appendix to ZCL and was finding my dream device for tasmota !!!

In the zigbee world its being called one "Control Bridge" from ZigBee Lighting & Occupancy
Device Specification from chapter 25.

Basically is one normal dumb router with type idevice ID: 0x0840 and device class dynamic.
If making one firmware for our EFR32s with CLI it can doing all things on my wish list !!!

Basically is the same function that IKEAs GW is having but without the configuration of the network. Its is like one universal remote that can sending commands to all devices in the network and also getting feedback from then if the device is configured to doing that.

If having one large deCONZ with 198 devices (max is 200) and adding the controller bridge to it its joining the network as one normal router with zigbee 3 functionality (if being OK configured) and getting network and link key from the trust center and is being all in.
Now the fun starts !!! I have one motion sensor im my bath that is sending one on with off 60 then being triggered. Then taking one shower its very likely is putting the light of after 60 seconds. Now tasmota is on the first place and I lot pressing one switch and tasmota is starting sending on with off 60 every 25 seconds until i single pressing the same button. I can taking my shower and all is OK and if tasmota is down only the extra functions in my zigbee network is not working. And i dont need more Pies or mini linux devices with MQTT and node read that must having 24/7 network for working.
Its possible having all things with HA and so on but they is not critical for my light is working and the tasmota can do nearly all extra things like switching my black star with blue leds inside in my living room on 5° before the sun is going down and 5° after up (that ESPHome maks today).

I have not reading how to commpilling one "control bridge with CLI" and wath commands its possible using but i think its more for some devs to looking on if its possible but i think its much lesser work that writing one complete EZSP coordinator that is being done for tasmota.

Tasmota Zigbee Controller Bridge.

Then some sanctions is easy to implanting its bets making them as modules that can being compelled in the tasmota.
Sniffing and touchlink reset is working without touching the NCPs setting and not need being joined in one zigbee network so no large problems. The other parts is need one router joining one network and "getting all in". I think getting one firmware for our EFR32 that is not locked its not one big problems then we is having many great devs here that can doing that. The question is being if we can getting one for Sonoff that is signed ? Its also that users of the Tasmota zigbee control bridge is little higher then beginners so perhaps its enough with one open firmware.
But sa i was saying in the beginning of the ZBBridge saga if not asking you cant getting one yes and in the end we was getting one signed NCP firmware from the factory.

If getting one working firmware for the ZCB (Zigbee Controller Bridge) then its possible implanting all functions i have writing of above and much more. Starting in small scale and building more after demand and needed function in tasmota.

The the ZCB is in the network (also IKEA and HUE pf they is accepting it) can doing OTA updates for other manufacturers then the "host networks GW" like being in on one IKEA network and can then updating my HUE bulbs, dimmer switch and motion sensor thru the ZBC.

I think one "collection" with ZCB that can doing touchlink magic and also OTA for other then "host zigbee networks GW" and also sniffing zigbee traffic and so on is not one easy task to do but its lesser then the ZBBrige was and i can see many use cases then using one or more large zigbee networks simessly being integrated with all the benefits and power off tasmota is having and not needing a bunch of extra hard and software that can making all falling apart then somthing its being broken (I can see how much problem deCOZ. Tradfi, HA, ESPHome MQTT, InfluxDB RTL-433 was having the last week then i was putting in my new nighthawk router at home).

Large Zigbee networks.

Its not for ZBBridge as it always was intended but some concerns about them.
Most users is making one large mess off all things and mixing devices that having problems (all have more or less) that is not working together.
If using devices that is more neutral its possible building large tigbee networks that working very well. Some users having between 100 and 200 devices and still adding more devices.
The hard wall is normally coming then adding some odd devices that is not playing well, (only one example) old OSRAM outlet with Xiaomi sensors (old no ZB3 ones) and loosing the sensors all the time because the router is not keeping the children in its tabel or start using node-red for doing all crazy magic things. Today the ideal is building one zigbee network with only zigbee 3 certified devices and can having good security and stabile function all the time. But very near deCONZ and co its going in the wall 2 with demand over 200 devices at home.

I see ZCB can doing more or less all and more magic to this large systems and helping the users having one cleaner systems with less problem and getting the most out if it by adding one ZCB in them without losing autonomy reliability and very advance functions.

Santa Claus wish list

I only giving some in and output for the devs and some time its being good and some time is not so good but in the end the devs is the maker and have the last world !

If i having little luck and Stephan is having time my dreams can coming true with one Zigbee Controller bridge but not for this corona christmas :-)))

Perhaps we should buy one fake white beard to Stephan for inspiration ;-)

MattWestb on 24 Nov 2020

Thanks for sharing your suggestions.

Touchlink is probably not very difficult but I hardly see how it would be actually usable with ZBBridge. Being USB powered, it is difficult to be close to the bulb (less than 5 cm). Moreover, there is no usable button on the device, so it would mean getting the ZBBridge close to the bulb and sending a command from a computer at the same time. Not practical.

For OTA, this is way beyond ESP8266 reach. It would mean first uploading the firmware to the ESP and then orchestrating the transfer.

One way though would be to externalize the OTA orchestration outside of Tasmota using the MQTT interface. This is probably a more realistic solution. But clearly not on the top of my todo list...

s-hadinger on 25 Nov 2020

Support for the new IKEA and Xiaomi killer _Home Smart Home_

Lidl have start releasing their new Zigbee smart home products serie in europe and its tuya based.
Next is Austria 30/11 Germany 3/12

So now we is knowing way IKEA have putting down the price on ther GW with 1/4 for some months ago.

melinera-lichterkette-zigbee-smart-home-zoom--5
Zigbee christmas tree lights !!!!

Its only for info wat the next wave of requests is coming for: tuya zigbee protocol.

Home sweet home smart or not ;-))

MattWestb on 25 Nov 2020

Good to know. Tuya zigbee protocol is half implemented for now, only decoder when receiving messages. Adding the encoder to send commands shouldn't be too hard.

s-hadinger on 25 Nov 2020

Lidl have start releasing their new Zigbee smart home products serie in europe and its tuya based.

https://www.reddit.com/r/homeassistant/comments/k0qkr5/lidl_has_released_zigbee_30_certified_smart_home/

Lidl (the German international discount supermarket chain) has just released a Zigbee 3.0 certified smart home gateway/hub and many Zigbee 3.0 devices under their Silvercrest brand with low prices.

https://www.news1.news/2020/11/lidl-opens-the-attack-on-the-established-order-now-steps-into-smarthome.html

Looks like they might be OEM or rebranded versions of Tuya products but Lidl has still gone through the process to getting them certified under their own named brands.

https://zigbeealliance.org/zigbee_products/?product_type=certified_product&se=lidl

https://zigbeealliance.org/zigbee_products/page/1/?product_type=certified_product&se=lidl

https://zigbeealliance.org/zigbee_products/page/2/?product_type=certified_product&se=lidl

Sounds as if these will be sold in Lidl stores from next week in most countries in Europe if not sooner.

https://www.lidl.co.uk/our-products/smart-home

https://www.lidl.de/de/home-smart-home-ab-03-12/c29863

https://www.lidl.se/smart-home

https://www.lidl.dk/smart-home

https://www.lidl.nl/smart-home

Note! These Lidl sold devices are not the same as the Silvercrest Homematic IP branded devices:

https://www.silvercrest-smarthome.de/ 3

Gamester17 on 26 Nov 2020

I think some countries have getting started little before as device support requests have start dropping in.
The GW is pretty expensive in Sweden and the lightstrip is cheaper there then in Austria.

Don't forget the Livarno Lux branded products !!

But the best is the christmas tree lights but toooo expensive for this christmas ;-(

But little Ho Ho Ho Home Smart Home is coming under the tree here :-)

MattWestb on 26 Nov 2020

Lidl (the German international discount supermarket chain) has just released a Zigbee 3.0 certified smart home gateway/hub

By the way, someone from the Home Assistant community posted a picture of the board from that Lidl Smart Home Gateway:

https://community.home-assistant.io/t/silvercrest-lidl-smarthome/243561/80

Not sure yet if it is based on ESP8266 or ESP32 but it would be nice with a Sonoff ZBBridge alternative with wired Ethernet PHY.

lidl_gateway

Gamester17 on 26 Nov 2020

Its the standard tuya GW with ethernet and ist RTL8196E based.
I have one from my TRV and thinking puting in one ESP-02S for getting it working with ZHA and Tasmota.

The zigbe module is one pretty good EFR32. https://fccid.io/2ANDL-TYZS4

Perhaps some implanting serial over ethernet for it then its being great !!

Edit: FCC ID https://fccid.io/2ANDL-TYGWZ01 the same only different casing.

MattWestb on 26 Nov 2020

It's very good news to have more brands choosing zigbee.

s-hadinger on 26 Nov 2020

I have bought the Lidl Christmas tree lights (Silvercrest HG06467), I can successfully pair it with the Sonoff bridge. Not much works, except sending an Off command. The device uses different lighting modes that I cannot set through the standard commands, is there any way I can assist in having this device implemented?

CopyCat73 on 30 Nov 2020

@CopyCat73 They seem to use the new Tuya Zigbee protocol as shown here: https://github.com/Koenkk/zigbee-herdsman-converters/issues/1792 and https://github.com/Koenkk/zigbee-herdsman-converters/pull/1799

I will need to read further here as well: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_tuya_devices.html

Tuya Zigbee protocol seems increasingly used so it will get better support on Z2T :)

s-hadinger on 30 Nov 2020

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

IMG_20201204_140319

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 :-)))

MattWestb on 4 Dec 2020

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.

s-hadinger on 5 Dec 2020

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 on 6 Dec 2020

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

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

bogorad on 8 Dec 2020

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

s-hadinger on 8 Dec 2020

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

bogorad on 8 Dec 2020

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

s-hadinger on 8 Dec 2020

@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 on 8 Dec 2020

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

bogorad on 8 Dec 2020

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

bogorad on 13 Dec 2020

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

s-hadinger on 13 Dec 2020

@s-hadinger I did

https://github.com/arendst/Tasmota/issues/9051#issuecomment-740929103

bogorad on 13 Dec 2020

I mean the diagram, not the logs.

s-hadinger on 13 Dec 2020

I mean the diagram, not the logs.

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

bogorad on 13 Dec 2020

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

Bibinsa on 20 Dec 2020

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

Yes, the same. I just worked around it.

bogorad on 20 Dec 2020

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

arendst on 23 Dec 2020

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?

bogorad on 23 Dec 2020

Shouldn't it follow the global rules?

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

arendst on 23 Dec 2020

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

bogorad on 23 Dec 2020

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":""}

Bibinsa on 23 Dec 2020

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 on 23 Dec 2020

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

arendst on 23 Dec 2020

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!

bogorad on 23 Dec 2020

What is the workaround ?
I don't get it.

Bibinsa on 23 Dec 2020

Tasmota: Zigbee Sonoff ZBBridge todo/wishlist

Short term:

Mid Term:

Longer Term:

Features we will not support

Most helpful comment

All 226 comments

9188 should fix the sequence number. I only changed the ZCL header, I hope it's enough. Can you please confirm?

Short term:

Mid Term:

Longer Term:

Features we will not support

Features we will not support

Zigbee Light improvement

Short term:

Mid Term:

Closing this issue.

Features we will not support

I like putting out some pro and cons for things to add or not and how.

Touchlink reset.

Touchlink network parameter configuration.

Touchlink Groupe configuration.

Not implanting touchlink in tasmotas Sonoff TBBridge.

OTA for all possible devices.

Other scenarios for Tasmota.

Tasmota Zigbee Controller Bridge.

Large Zigbee networks.

Santa Claus wish list

Support for the new IKEA and Xiaomi killer _Home Smart Home_

Related issues