Updated EM357 NCP firmware "IKEA battery draining fix"

[MattWestb]

ZHA is having problems with IKEA controllers is draining there batteries and wasn't finding the problem for that but its looks being Sonoff Zigbee bridge that is triggering it most (EFR32 second gen).
Tasmoat devs have disabled attribute reporting for all IKEA controllers for trying going around the problems. Last week is also reported that Philips HUE dimmer switch is making the same => disabling attribute reporting in tasmota.
Also deCOZ is having problems with Samsung and IKEA controllers is draining batteries and have pinpointing that the pull control is not being setted up OK and making the devices staying in short pull mode for infinity so they is redoing the pull control for this devises.

Then having finding the silabs NCP bug in the 6.7.8.0 release i have getting one firmware update for Sonoff zigbee bridge (unsigned then the we dont thwe the cert for signing it) and my "IKEA Billy EZSP". Both firmware is tested by our cooker but not verified to working from the user base but should being OK.

Then its one ZHA user with EM357 stick that is also having the battery draining problems that we cant explaining :-((

So i have asking the cooker if hi can doing one new firmware for that chip also and hi have done it.
Its not tested on the specific hardware then hi dont have time for doing it for the moment.

So i asking can some of the experien EM3XX user trying it out if its working and if OK adding it in this repro and if not then we is deleting the files then its bad if they is circulating and crashing / making problems for users.

Link to the firmware: https://github.com/grobasoz/zigbee-firmware/tree/master/EM357

2 things: USB serial was disabled by Silabs in app bilder but is still in the code base so little tricky to get it working. Its one EZSP protocol version 8 and not backward compatible with lower protocols !!

Pleas informing us if its working or not !!

Mvh Mattias

[walthowd]

Do you know off hand if the legacy bootloader on the EM3581 accepts s37 xmodem transfers? Verified the pinout looks good, and tried to transfer the file via ncp.py but it wasn't happy -- Looks like I can convert the s37 format to ebl but need the windows toolkit side of Simplicity Commander to do so.

[MattWestb]

My experience from EFR32 first generation is no :-((
I have only getting GBL files flashed thru bootloader on my IKEA Billy EZSP with gecko bootloader.
I have converting s37 files to bin files and it was working OK.
And if I dot remember wrong its possible converting s37 to GBL files but i don't knowing if it possible to EBL.

I pinging gary hi have little more experience of EM35X chips.

@grobasoz Wath files can the old Ember bootloader flashing ??

[MattWestb]

If the S37 file is OK then the command 6.6.3 EBL File Creation should working to creating one EBL file for bootloader flashing.
ug162-simplicity-commander-reference-guide.pdf

Simplicity commander you can download for different platforms at https://www.silabs.com/mcu/programming-options

Edit: And for converting to one GBL file: 6.7.1 GBL File Creation

[MattWestb]

Was testing converting and its looks working but i cant testing the file then i dont have the hardware.

PS C:\Users\Mattias\Documents\ICCA1\Simplicity Commander> .\commander.exe ebl create NCP_USW_ETRX3_USB_678-115k2.ebl --app NCP_USW_ETRX3_USB_678-115k2.s37 --device em357
QCommandLineParser: option not defined: "certificate"
Parsing file NCP_USW_ETRX3_USB_678-115k2.s37...
QObject::connect: No such signal EblHandler::warning(QString)
Parse .s37 format for flash

Approximate Usage Information:
RAM Usage:
  APPLICATION_CONFIGURATION_HEADER usage: 0x20000000-0x2000148f (5264 bytes)
  Available for future use:               0x20001490-0x200019e7 (1368 bytes)
  Call Stack:                             0x200019e8-0x20002347 (2400 bytes)
  Globals and Statics:                    0x20002348-0x20002fef (3240 bytes)
  NO_INIT and Debug Channel:              0x20002ff0-0x20002fff (16 bytes)
Flash Usage:
  Reserved for Bootloader:                0x08000000-0x08001fff (8192 bytes)
  CODE and Tables:                        0x08002000-0x0802654f (148816 bytes)
  CONST and INITC:                        0x08026550-0x08026cd2 (1923 bytes)
  Available for future use:               0x08026cd3-0x08026fff (813 bytes)
  Reserved for SIMEE:                     0x08027000-0x0802ffff (36864 bytes)

Usage Summary:
  12288 total bytes RAM, 10920 used, 1368 available
  196608 total bytes Flash, 195795 used, 813 available

Setting AAT timestamp to current time: 0x6001f0f6
Create ebl image file
Wrote image stamp into AAT.
DONE

EM357test.zip

Attached the 2 converted file in one zip file.

[grobasoz]

@MattWestb - I have put the ebl files into my repository. Unfortunately I couldn't get your ebl to flash correctly on my test system :(
@walthowd - The EM357 files won't work on EM3581 - I only have EM3555, EM3585, EM3587 and EM3588 to test with, no EM3581 - though I seem to recall EM358x being semi-compatible... If I get some time today I will check and create NCP for EM358x.
Regards,
Gary.

[MattWestb]

Thanks Gary and as you knowing Cimplicity Commander is not one friend of my but i think its little bad its was writing the operation was OK.

I keeping one eye on the progress and reporting back the the original ZHA EM357 user if all is going well.

And I also hoping walthhowd is getting one working 6.7.8.0 update for his EM3581 stick :-))

As normal one big thanks for sharing your knowledge and efforts to the community ! !

Mvh Mattias

Edit: Was not silabs putting the EM35X USB-serial support out of app builder (but living the code tree) in some earlier 6.7.X release ?

[walthowd]

No dice.

root@85d4811845a1:/tmp/silabs# ./ncp.py flash -p /dev/ttyUSB1 -f /data/NCP_USW_ETRX3_USB_678-57k6.ebl 
Restarting NCP into Bootloader mode...
CEL stick
EM3581 Serial Bootloader v5.4.1.0 b962

Successfully restarted into bootloader mode! Starting upload of NCP image... 
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\r' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\n' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'S' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'e' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'r' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'i' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'a' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'l' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got ' ' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'u' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'p' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'l' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'o' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'a' for block 2
ERROR:xmodem.XMODEM:send error: NAK received 17 times, aborting.
NCP upload failed. Please reload a correct NCP image to recover.
Rebooting NCP...

Regular upload works fine --

root@85d4811845a1:/tmp/silabs# ./ncp.py flash -p /dev/ttyUSB1 -f ncp-uart-sw-6.6.5.ebl
Restarting NCP into Bootloader mode...
CEL stick
EM3581 Serial Bootloader v5.4.1.0 b962

Successfully restarted into bootloader mode! Starting upload of NCP image... 
Finished!
Rebooting NCP...

[MattWestb]

So EM357 firmware not working on EM3581(from bootloader version). :-(

The bootloader is sending back its menu then it have backing out the x-modem download.

Have you trying with terminal like minicom ?

[walthowd]

Yeah, minicom didn't like it either:

But once again regular image transfers via minicom and xmodem without issues:

[MattWestb]

Perhaps its one bootloader problem (I dont have reading the release notes of the EBL) that is not compatible.
I think its better waiting for Gary getting time for cooking one EM3581 firmware and getting the right EBL file for EM3581 device.

Do you think this firmware its working for users that is having real EM357 devices ?
Perhaps Gary also have time testing it on one EM357 device
(I dont have any experience of EM35Xx devices)

And is it mutch users having the EM357 or is all having the newer EM3581 ?

[walthowd]

I pinged my one EM357 tester to see if he's willing to try it out. . .

[grobasoz]

I have added EM358x NCP firmware to my repository.
I have tested both EM357 and EM358x on standard Zigbee Z3GatewayHost from Silicon Labs.
Have fun, Gary.

[MattWestb]

Great thanks for getting updated firmware for our device !!!

Hope you get time to sleep little between your deep diving in the hard and software jungle.

Mvh Mattias

[grobasoz]

No time for sleep - @Hedda keeps me busy ;) - have to work on Zigbee2MQTT for EFR32! Now need to upgrade my to new stack (I have found bugs in new stack though :( )

[macfly92]

I've succesfully upload NCP_USW_ETRX3_USB_678-57k6.ebl firmware on my Telegesis ETRX357USB adapter.
$ python ncp.py scan
Connecting to.. /dev/ttyUSB0 57600 True False
{"ports": [{"stackVersion": "6.7.8-373", "deviceType": "zigbee", "pid": "8293", "port": "/dev/ttyUSB0", "vid": "10C4"}]}
(Previously 6.6.5)

I've also pairing again my Ikea ON/OFF switch to test battery draining.
I will report back if I found any problem.
Thanks you very much for your hard work !

[MattWestb]

@macfly92 Great work done !!!

After adding and changing binding of your IKEA E1743 do one "reconfigure this device" from the device card so its being sure the pull control setting is being OK in the remote (dont forgetting waking it up before executing the command).

If its not helping the battery draining you have getting one newest possible firmware with many bad bugs fixed and i think you is getting one more stabile system.

You is one of our most brave users trying one nearly untested (not recommended) firmware on you adapter but i like it !!!

Report back if its going well or getting problem here so the devs can putting the firmware on the recommended list or if its bad on the blacklist.

Mvh Mattias W

[MattWestb]

@grobasoz Im vers sorry that my former countryman @Hedda is keeping you busy and i was thinking hi was busy by hunting ice beers in the north !!

And one more time thanks for the great cooking of firmwares for our adapters. 3 is up and running (Tasmota, IKEA Billy and EM357) on one more need being confirmed :-))

And I hope you getting enough time for getting Z2M working with EZSP compatible adapters (i think only protocol version 8 is enough then nearly all adapters is getting new updated firmware) so the users can have more choices on the host system side and its good for the development of the HA community (but bad for commercial deCONZ).

Now is only waiting for good or bad new for the EM358X firmware and then its up to the devs to recommending the 6.7.8.0 or not.

Have one great time and grating to the tequila drunk penguins on the beach !

Mvh Mattias

[macfly92]

@macfly92 Great work done !!!

After adding and changing binding of your IKEA E1743 do one "reconfigure this device" from the device card so its being sure the pull control setting is being OK in the remote (dont forgetting waking it up before executing the command).

If its not helping the battery draining you have getting one newest possible firmware with many bad bugs fixed and i think you is getting one more stabile system.

You is one of our most brave users trying one nearly untested (not recommended) firmware on you adapter but i like it !!!

Report back if its going well or getting problem here so the devs can putting the firmware on the recommended list or if its bad on the blacklist.

Mvh Mattias W

Ok I will do reconfigure right now. Can I somewhere check if it is correctly configured ?
No problem for the test, someone must do it and I hesitated to buy another Zigbee dongle so this test was the last hope of my ETRX357USB and I'm happy to contribute.
All seem to be good, so I can stick with my Telegesis a little bit more.

Again thanks a lot.

[MattWestb]

If you was waking it up shor before sending the commands you dont getting any warning / errors in the log = OK. If its was sleeping you getting errors / warning in the logs (if i remember right !!).

Its great to knowing its working with the upgrade so can recommending to other users and not braking their favorite hardware and making the user very sad !

So you is being the only one with one most up to date EM357 around in the community :-)))

[macfly92]

If you was waking it up shor before sending the commands you dont getting any warning / errors in the log = OK. If its was sleeping you getting errors / warning in the logs (if i remember right !!).

Ok, I have done the reconfigure but without debug on the ZHA log. I will check the battery drain, and if it is not good, I will dig more.

Its great to knowing its working with the upgrade so can recommending to other users and not braking their favorite hardware and making the user very sad !

So you is being the only one with one most up to date EM357 around in the community :-)))

Ahah, great ! I hope I will not be the only one, but the first one for sure ;)

[igalarzab]

I just flashed the file NCP_USW_EM358x_678_57k6.ebl from here to my HUSBZB-1, thinking it was the same chip... and now I cannot access it anymore... did I just break my USB stick? :_D

[sreknob]

@igalarzab - if you're not getting a response from the stick, you could try recovery instructions in the readme.

[igalarzab]

@sreknob thanks! Yes, I saw the instructions but I don't think I have the right tools for it (also, they seem to be a bit out of my low-level knowledge :D)

Also, out of curiosity... what would have been the right firmware to patch?

[walthowd]

You can pop open the case and recover with just a paperclip shorting the two shown points or a set of tweezers.

Correct firmware is here:
https://github.com/walthowd/husbzb-firmware#selecting-the-correct-firmware-file

[igalarzab]

Thanks for the help @walthowd, I appreciate it

I used a paperclip to touch both TP17 and GND and I can see this in the dmesg output:

[182735.503101] usb 1-1.2: new full-speed USB device number 22 using xhci_hcd
[182735.610247] usb 1-1.2: New USB device found, idVendor=10c4, idProduct=8a2a, bcdDevice= 1.00
[182735.610268] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[182735.610280] usb 1-1.2: Product: HubZ Smart Home Controller
[182735.610292] usb 1-1.2: Manufacturer: Silicon Labs
[182735.610303] usb 1-1.2: SerialNumber: C1301256
[182735.623742] cp210x 1-1.2:1.0: cp210x converter detected
[182735.632709] usb 1-1.2: cp210x converter now attached to ttyUSB0
[182735.635440] cp210x 1-1.2:1.1: cp210x converter detected
[182735.644176] usb 1-1.2: cp210x converter now attached to ttyUSB1

Now the problem is that I'm not very sure how to follow... sorry if my questions seem a bit stupid :) I've tried using minicom to upload the ebl file but I must be doing something wrong as I can only see

Sending /tmp/silabs/ncp-uart-sw-6.6.5.ebl, 1167 blocks: Give your local XMODEM receive command now.
Xmodem sectors/kbytes sent:   0/ 0k
Retry 0: Timeout on sector ACK
...

What are exactly the steps after shorting TP17 and GND?

Again, thanks for the help, and sorry for hijacking this issue! 😓

[walthowd]

You should see a bootloader menu in minicom first -- Select upload ebl (option 1, I believe) and then send your file.

Connect minicom to the /dev/ttyUSB1 (115200 no flow, 8/n/1) -- pull stick, short TP17 to GND, plug stick back in, unshort TP17, hit enter a few times on keyboard, see if you get to the menu. If not, repeat.

[igalarzab]

amazing, it works... thank you very much, really!! 🎉 🎉

I created a PR with some detailed instructions just in case it's useful to someone in my same situation :)

Also, going back to the initial matter of this ticket... I flashed the wrong image (v6.7.8) trying to fix the battery drain of the Ikea lights. I guess there is no firmware with the fix for this specific device released yet, am I right?

[walthowd]

Here is the correct file for EM3581/Nortek GoControl users to test:

https://github.com/grobasoz/zigbee-firmware/blob/master/EM358x/NCP_USW_EM358x_678_57k6.ebl

Let me know your results -- You will need to reconfigure your end devices (ikea) after installing to reconfigure polling mode.

[MattWestb]

So it looks its one good and easy way changing the speed in ZHA without destroying the device stetted up then changing firmware.

@walthowd Shall we putting that in the Zigpy Wiki so user can using it and not doing bad things and loosing there devices ??

[sreknob]

@MattWestb thanks for pointing out that I can't read. I totally just skipped over the bellows options and just looked at the commands. Anyway, as you could see from my many edits, I eventually got there :-)

And back to the original issue point of WHY to upgrade (not just because we can -- thanks to @grobasoz), I just reconfigured all my Ikea remotes to see if batteries drain improves. Good timing as I'm down to just one spare CR2032 battery from my last pack of 8 I opened a couple weeks ago!

Thanks to everyone here for making this happen!

I will keep running my production HA with it at 115200 and let everyone here if any issues crop up. So far, so good, though.

[MattWestb]

Im very impressed of the users of EM35X devices that is helping the devs to moving things forward then most "normal" users is only sitting and dot do nothing (or perhaps complaining).

Gary is have doing all possible and impossible firmware for the Silabs community (the first and famous was the "free" Sonoff Zigbee Bridge) and hi is always helping then hi cam.

For the original problem (battery draining) I have not have time to do more tests (One very close friend of my was having on hart attack on Monday night. . .) but if you is doing the "reconfigure" trick the device is pulling its parent every 5 seconds and is reporting batteries (then sending commands) and getting the online status in ZHA updated every 60 minutes.
If repairing they its (if not ZHA is doing somthing or the device is changing parent) pulling its parent every 5 minutes and can being that the battery status is not reported and online status is updated around on time in 24 hours = flagged of line (My new pared remote have doing it for 6 days now).

I think the "hard draining" is only hitting EFR32 second gen (Sonoff ZBB) that the 6.7.8.0 shall fixing it but i cant verifying that then i dont have any Sonoff ZBB (Stephan H is saying its working OK in tasmota).

Its still some bugs in all devices that is running older Zigbee stacks then the 6.7.8.0 that must being fixed in there firmware (I need writing IKEA one more time) but i hope its being better but i do not expecting all problems i away but many other is fixed in the NCP firmware that is great that also the EM35X is having getting it for making ZHA more stable for all users.

I dont like hijacking this issue and shall continue trying getting one "new free" firmware on my tuya ZBGW.

Keep being brave and reporting back so our devs can getting our systems working better !!

[walthowd]

@grobasoz I've added your 6.7.8 firmware to this repository. Let me know if you'd like be credited it for it, or not, or keep it hosted just on your repo. I know it gets sticky with the Emberznet legal language, though it does not seem to be currently enforced as the images are all over github.

FWIW, I've been running 6.7.8 in test and a ZHA dev has been running it as well in production, all so far with good results.

[MattWestb]

Great that its working well !

Shall I putting it as recommended firmware version on the Zigpy Wiki ?
All EM35X adapters have 6.6.5.0 and the normal Telegesis looks also working OK.
But i think we dont have any user that have testing the Telegesis LRS and LRS+8M versions.

[sreknob]

Just to follow up, I've had no issues at all with the 115k2 version here! Thanks!

[MattWestb]

I updating the Zigpy Wiki with your latest status and closing this issue then its looks all "Gary" firmware is up and running on EM35X devices without any issues.

I think the one part or the "battery draining" is eliminated but its 2 more parts that is not related to the NCP firmware but its better having the discussion in the original ZHA issue.

@igalarzab Do you have trying if you can loading the updated version for your stick that the devs have getting up and running ??

@walthowd Do you like recommending 115k2 or 57k6 for using in ZHA ??
I think 115k2 its better (nearly 100% faster com speed) if the hardware is working OK with it.
And thanks for credit Gary in the instruction !!!!

Im sorry for i have abusing Gary (not the first time) but hi is one of the few that can cooking one working firmware for the EM35X devices with newer SDK then is officially supported by Silabs.

One more great thanks to all brave EM35X users, walthowd and @grobasoz for all time and knowledge spendeed on this issue and making it working.

All the best for all brave users !!

[igalarzab]

I patched the 57k6 (as I’m not very sure which is the correct 115k2) image and it works perfectly. Thanks a lot!! :)))

[MattWestb]

Great !!

The 115k2 shall being this one and 57k6 this one that is working.

If you is trying out the 115k2 you need "patching" you ZHA config with the new baudrate for getting it working. #12 (comment).

Thanks for testing it out !!

[walthowd]

@MattWestb I'd probably leave the recommendation for 57600 currently for the average user. ZHA only currently probes EZSP at 56K so users would have to manually enter serial path, radio type and baud rate.

Elelabs users already have to do that (as the EFR32 there only does 115200) but it does seem to trip a lot of people up and confuse them.

I'll include the 115200 fw image in the repository and add a note for advanced users.

[MattWestb]

I like getting all adapter working with the same speed if its possible so it working with the default in ZHA. If also EM357 is working OK I can doing one PR in ZHA for changing the default to 115k2 and its being less confusing for "normal users".
If only EByte is using 57k6 then 90 % dont need changing the default in ZHA = auto detect of EZSP adapter is working (today is lesser then 50%).
I have putting on request for one 115k2 firmware in the zha-ng repro for getting the last to support 115k2.

[walthowd]

@MattWestb The best approach would be to PR to ZHA to auto probe 115K in addition to 56K.

Currently it probes EZSP at 56k, then zigpy-znp, deconz, on all serial ports -- if all fail the user is thrown to the manual configuration mode.

If it auto probed EZSP at 56K and 115K it would work "out of the box" with non-upgraded HUSBZB-1 adapters and Elelab adapters and upgraded HUSBZB-1 adapters.

[MattWestb]

Should I putting one request in ZHA to adding 115k2 for probing or if they dont like doing it changing the default to 115k2 ?

You can also asking Alexei wot hi is thinking and in the end hi have the last word.

I like the approach to having the doors open and not closing them then its not nervelessly.

You is the person that getting the most problems if user having problems and im only on more crazy user.

PS: My "IKEA Billy EZSP" have never being auto probed of ZHA and its the same with most EFR32 adapters to day.

[Hedda]

@MattWestb The best approach would be to PR to ZHA to auto probe 115K in addition to 56K.

Should I putting one request in ZHA to adding 115k2 for probing or if they dont like doing it changing the default to 115k2 ?

+1 Great if first probe 115200 and then that fail salso try 57600, but believe it's bellows and not ZHA that contains the probe code:

https://github.com/zigpy/bellows/blob/dev/bellows/ezsp/__init__.py

https://github.com/zigpy/bellows/blob/dev/bellows/config/__init__.py

FYI, EZSP probe method was initially added as a feature to bellows by Adminiuga in pull request zigpy/bellows#223

By the way, bellows test code looks to use 115200 by default -> https://github.com/zigpy/bellows/blob/dev/tests/test_ezsp.py

[Hedda]

Currently it probes EZSP at 56k, then zigpy-znp, deconz, on all serial ports -- if all fail the user is thrown to the manual configuration mode.

ZHA automaticly probing all serial ports could make initial installation config flow super user-friendly if a smart implementation could be coded for it to check if any adapter is not already in use by other applications/integrations running on the same computer. One possible issue of conclict I could otherwise see with ZHA automatically probing all serial ports is if the user already have a other more than one Zigbee coordinator adapter installed and one of them is already used by a other application or integration such as deCONZ, or XBee, Zigbee2MQTT, or ZiGate (now obsolete custom component but could still be in use):

https://www.home-assistant.io/integrations/deconz/
https://www.home-assistant.io/integrations/xbee/
https://www.zigbee2mqtt.io/integration/home_assistant.html
https://github.com/doudz/homeassistant-zigate

[MattWestb]

I finding implanting one config parameter that defining network ports that ZHA is using then probing like in config: 127.127.0.1:8989 and ZHA is treating it like one normal port then searching for radios. Can also being used for other integrations so perhaps being pre/postfixed with integration 172.127.0.1:8989:ZHA or the radio it shall being used for like Zigate, X-Bee and so on.

[Hedda]

I finding implanting one config parameter that defining network ports that ZHA is using then probing like in config: 127.127.0.1:8989 and ZHA is treating it like one normal port then searching for radios. Can also being used for other integrations so perhaps being pre/postfixed with integration 172.127.0.1:8989:ZHA or the radio it shall being used for like Zigate, X-Bee and so on.

Automatically discovering of network-attatched Zigbee bridge devices is something that belongs in ZHA / Home Assistant Core.

I think optimally would be if both the ZHA integration and Zigbee bridge firmware could use SSDP automatic discovery method:

https://www.home-assistant.io/integrations/discovery/

https://www.home-assistant.io/integrations/ssdp/

https://www.home-assistant.io/integrations/zeroconf/

ZiGate Gateway firmware feature it and old ZiGate integration supported Zeroconf SSDP (Simple Service Discovery Protocol):

https://github.com/doudz/zigate/blob/master/zigate/transport.py#L385

zigpy/zigpy-zigate#36

The only thing that needs discovering is IP, port, and the radio type in the case of the ZHA integration and Zigbee bridge firmware.

[MattWestb]

If parsing the parameters to bellows environment then pyserial is handle it like one "normal local com port" and ist working without the serial host have some special configuration only the right network port is open.
Auto discovery is also nice but its not so high priority for my better having possibility defining some default network ports then adding and deleting integrations oft in my test setup.
I was thinking implanting network port for NCP.PY used for most updating utility programs but i not so good in python programming :-((

[Hedda]

My coding sucks too so posted seperate requests/discussion for those ideas here zigpy/bellows#396 and here zigpy/zigpy#667

[MattWestb]

@Hedda

Automatically discovering of network-attatched Zigbee bridge devices is something that belongs in ZHA / Home Assistant Core.

Not completely true then some users is using the bellows CLI for doing things like rebooting in bootloadermode and so on, then its good its working / reading the same "settings" and if its coming from HA. ZHA, Zigpy or Bellows is one more architecture dials that i letting "some" more competent person to take the decision how it shall being implanted.

If its going well it can being possible doing NCP upgrading true bellows CLI with only adding xmodem from pip and some command line parameters. (like is being done in the Linux terminal on tuya ZBGW).

Edit:
Thanks for the hint @walthowd for getting the tuya ZBGW rebooting in bootlooadre it was helping !!

[yieldhog]

@sreknob -- I upgraded to the latest firmware and my 5 button Ikea remote still died in 2 days. I had forgotten to reconfigure the remote, is it as simple as hitting reconfigure on the device in GUI? Has the Ikea issue been fixed on your end? Thanks

[juched78]

@sreknob -- I upgraded to the latest firmware and my 5 button Ikea remote still died in 2 days. I had forgotten to reconfigure the remote, is it as simple as hitting reconfigure on the device in GUI? Has the Ikea issue been fixed on your end? Thanks

Did you hit re-configure in HA UI? Did the next battery last longer?

I just updated to 6.7.8 and reconfigured my two Ikea On/Off Switches and my Philipps dimmer switch. I just hit reconfigure in the UI while turning the switch on and off, to keep it awake. But not sure how to validate this is correct.

Is it better to drop and re-pair after going to 6.7.8?

[MattWestb]

ZHA is still setting up the long pull interval to 6 seconds but you can patching that to the default 4.88 minutes zigpy/zigpy#604 (comment) you dont need reconfigure then you end device is OK reconfigured and its only updating the long pull interval after check in is made (every 55 minutes).

If you is repairing or doing one new binding the attribute reporting is being broken and is only reporting one time in 24 hour and is most time flagged off line, reconfigured is reporting every 3 hour and last seen is updated every hour = online.

Also good if the end device is connected to routers and and not direct to the coordinator.

[juched78]

Decided to do the zhaquirk tweak of line 93. I know you mention there is some Zigbee 3 disadvantages but i like that it only impacts the Ikea 2 button switch.

[sreknob]

@sreknob -- I upgraded to the latest firmware and my 5 button Ikea remote still died in 2 days. I had forgotten to reconfigure the remote, is it as simple as hitting reconfigure on the device in GUI? Has the Ikea issue been fixed on your end? Thanks

Did you hit re-configure in HA UI? Did the next battery last longer?

So, it didn’t help.... and I actually ran out of batteries and haven’t had time to grab more yet. So they have been shelved for the moment. Looks like there are some other good ideas here to change the polling, which, when I have some fresh batteries, I will try out!

[MattWestb]

Only for reference the old EM35X-Ref-Des-SE2432L is the reference design with PA on EM35X chips.
EM35X-Ref-Des-SE2432L.zip

Can being good to have in the future if Silabs is taking it off line.