Updating the coordinator firmware to the latest November developer firmware and updating to zigpy 0.6.3 at the same time appears to have fixed the ability to add devices. I was able to pair 2 devices that previously were not pairing. Time will tell as to whether it also solves the battery drainage issue on the Ikea buttons.
I managed to flash the latest KoenKK router image to the sonoff sticks I have, and they seem to work well as routers. However in deconz I notice the name of the device is set to the MAC address and is not changeable like other devices (including the tradfri repeaters I have).
Is there a way to change this, as labelling it by deployed location makes it easy to remember where I put these things.
Using a couple of RPI4 4GB with these Drive Enclosures and 120 GB Kingston SSDs, ZigStar or Slaesh sticks connected to the Pi’s through 1.5m USB extension cables together with the original RPI4 PSUs and never ever experienced a single failure/freeze on even one of those combos a year or so!
1 Like
Never said the failure was due to the psu. I said it was more likely a defective usb sata adapter or a power/voltage change. then said the plug was large. Glad you like yours. Also even without knowing what ZigBee USB adapter your using I can easily tell it probably uses a little less power than this one that we are actually discussing.
First of all, should really make sure have a backup before firmware upgrade of a Zigbee Coordinator.
You should not have to pair any devices again, however, if end up having to restore backup then could take up to 24-hours before all devices have connected (especially battery-operated devices like sensors which usually only connect upon sensor changes).
If any device that was connected before is still not connecting after firmware upgrade then should be enough to power-cycle those devices (e.g. unplug and replug mains-power, remove and replace battery).
Naming in an application depends on software implementation so you would really have to ask such questions deCONZ community / Phoscon community forum → https://forum.phoscon.de and/or Home Assistant’s deCONZ thread → https://community.home-assistant.io/t/deconz-official-thread/100504
That sounds promising! Can you check and verify the exact product description they choose to go with?
Also, can you test the changes from this pull request:
https://github.com/home-assistant/core/pull/58166
It uses wildcards I think it will work as long as the product description contains “sonoff” somewhere(?).
Looks like usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_201e5if00-port0
I assume that is just the assigned serial port in Linux and not the product description value that was written to the product description field in the EEPROM of the CP2102N USB-to-UART chip by ITead.
Not sure on Linux but on Windows can use tools like ex. NirSoft USBDeview or Sieber USBTreeView:
https://www.nirsoft.net/utils/usb_devices_view.html
http://www.uwe-sieber.de/usbtreeview_e.html
Note! Sometimes it’s call it “Product Description”, other times “Device Description” or just “Description”.
Previous batches the description show as “Silicon Labs CP210x USB to UART Bridge” in those tools:
Old ID
/dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_a4766cbfb593eb11b7611b4f3d98b6d1-if00-port0
New ID
/dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_201e5if00-port0
1 Like
Would having 2 of these as routers and 1 as the coordinator cause interference between them? And would other repeaters and end devices latch on to these routers given their better signal because of their antenna?
Using same type of hardware will not cause interference. Compatibility should even be better on paper.
Yes.
1 Like
OK, serial path adds “usb-” as prefix and some ID and port-number as suffix, plus added underscores.
So assume new product description is “ITead Sonoff Zigbee 3.0 USB Dongle Plus” without underscores.
Can you test discovery with changes from PR? → https://github.com/home-assistant/core/pull/58166
I have no test environment for ZHA, nor want to pursue one.
Best if you setup one and test.
I do not own a dongle from the new batch with the new product description so can not test it myself.
Oh well, closed that PR as I can not test, but it is still there as a reference for others to test and do PR:
https://github.com/home-assistant/core/pull/58166
Alternative I will not pursue myself is to write same description to CP210x EEPROM, but others see:
https://github.com/VCTLabs/cp210x-program
I hope that ITead of someone will release a script to write description in dongle from previous batches.
FYI, new Z-Stack 3.x.0 20211207 firmware in develop branch is based on SimpleLink SDK 5.30.01.01
https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin
Those willing to test that newer pre-release firmware version from the develop branch can find it here:
Links to the two related changelogs (for SimpleLink SDK changelog see sections about “TI Z-Stack”):
Mostly bug-fixes to TI Z-Stack + increased memory heap, LED on join, and a fix for Xiaomi E1 devices.
I have the previous Sonoff ZigBee 3.0 Dongle plus running the new development branch firmware. I was having problems that seemed to come from inadequate power supply on my USB hub, so I replaced it. Everything started working again, but only for a couple days. While I was re-pairing one of my endpoints, another device of unknown_manufacturer joined the network somehow. It claims that it is a coordinator, and slowly started taking over the network. I think it is my HUSBZB stick that I still have to run my Zwave network! It is metastasizing and destroying my mesh. It has something to do with backing up my HUSBZB and restoring it to my Sonoff stick.
What I saw when I upgraded my CC2530+CC2591, that the new stick somehow got the IEEE-address of the old one (after searching a week why the re-flashed as a router CC2530+CC2591 would not join the mesh)
Maybe that is the case here too.
I just checked and they have different addresses. But the old one does have the same NWK. could that be the problem? Is there a way to erase it? Found it: use zha.remove service. It seems likely that a rogue coordinator could cause lots of problems with pairing and messages.