Thanks.
All my batteries where reporting 80% and up. I change them and haven't had any dropouts yet.
I spent 100's on repeaters and just needed a few cheep batteries. 
.
Thanks again.
2 Likes
Id change the zigbee channel too
1 Like
I have also had wifi / zigbee interference issues in the past from 2 sources:
- internal: I had the wifi router set to automatically find a 2.4 band. This is a mistake, because it can choose (unbeknowest to you) your exisiting zigbee channel.
- external: Not too much you can do about this, but sometimes your neighbours can drown out your zigbee channel. Use the app called "wifi analyzer" to determine which channels your neighbours are using.
1 Like
@jtmpush18 - You just need to install some Ubiquiti Wifi 6 LR APs around your house..
Open up the wideband and blast everyone in your neighborhood!
Yeah. I need that for zigbee though.
1 Like
Use an XBEE...
1 Like
Convert a Sonoff USB zigbee 3.0 dongle into a zigbee repeater. They are fantastic, much cheaper than an xbee3, and have excellent range.
I have a couple, @Ken_Fraleigh has some, and I know there are others here using them as well.
Here’s the link:
Takes about 5 minutes to flash one to work as a repeater/router.
2 Likes
That is a cool idea! I guess I didn't realize you could do that but sure, different firmware. 
1 Like
Real easy to convert. Flashing is very simple. There are command line tools (my preference) and GUI tools for windows/mac/Linux.
2 Likes
Can it pair without a computer? I mean just stick it in a USB power supply?
1 Like
Yup. That’s how mine are.
I even use them outdoors. Here’s one I’ve plugged into an outdoor zwave outlet (that’s used as a repeater). The Sonoff repeats for my mailbox, and some outdoor sensors.
3 Likes
@aaiyar I find that to be very clever! I never knew that you could flash them to be repeaters! (I bought one a short while ago for use in HA).
I found the following document that should serve as a guide for flashing:
2 Likes
Here are my instructions on how to configure a Sonoff zigbee 3.0 USB dongle as a repeater (router) for use with Hubitat. My instructions use the command-line Python script cc2538-bsl
- Download/install Jelmer Tibet's
cc2538-bsltool from here. I just downloaded the repository as a zip and installed it in its own directory. - Install the two Python packages that
cc2538-bslneeds, namely,pyserialandintelhex. (pip install pyserial and pip install intelhex). - Download the router (repeater) firmware from here and keep it in the same directory as
cc2538-bsl. The file you need is CC1352P2_CC2652P_launchpad_router_20220125.zip. Unzip this file to createCC1352P2_CC2652P_launchpad_router_20220125.hex. - Plug the Sonoff zigbee 3.0 dongle into a USB port on the same computer. On Linux, you can find out the port that the dongle is on by doing
ls -l /dev/serial/by-id. It'll be something like/dev/ttyUSB0or/dev/ttyUSB1etc. depending on how many other USB peripherals you have plugged in. - Flash with this command (replace ttyUSB1 with whatever is appropriate for your system):
./cc2538-bsl.py -ewv -p /dev/ttyUSB1 --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_router_20220125.hex
This command erases the existing firmware, writes the new firmware, and then verifies it. I think it is checksum verification.
That's it - now you're ready to pair it to Hubitat.
For some of us (me and @Ken_Fraleigh), the USB dongle went into pairing mode as soon as it was plugged into a USB power supply. For others (@Rxich and @danabw), the cover had to be unscrewed, and either one of the buttons on the USB board pressed to put the dongle into pairing mode. I don't know why there's a difference in experience - but either way it is simple. Anyway, here are the pairing instructions:
- Screw the antenna to the dongle
- Put your hub into Zigbee pairing mode.
- Plug in the USB dongle into a USB outlet and be patient. A device will be discovered pretty quickly, but it takes about 3-5 minutes to fully initialize with the hub. Just leave it alone until you get an option to name the device.
- You can either leave it using the "Device" driver, or change it to "Ikea Tradfri Repeater". If you use the Tradfri repeater driver, then the "Get Link Quality" button works, but the "Get Route Table" button doesn't work.
If a device isn't discovered during pairing, then remove the dongle from its housing (two little screws), put your Hubitat into pairing mode, plug the dongle into the USB outlet and push one of the buttons on the dongle. It'll be discovered. The rest of the instructions are the same as above.
5 Likes
My sonoff router still never paired. It's sitting on my desk mocking me. My zigbee network never recovered from the multi hub channel swap 20<->25 between a C4 and a C7. Months later I can only pair on my C7 if I shutdown the C4 hub. Existing devices will sometimes re-pair to the C7 without shutting down the C4. I did a foolish thing a few days back, I paired a Hue can light to my C7 mesh, about 2 days later my Hue dimmer V2 and my Opple 6 button both fell off the mesh. The Hue light is now removed and getting those 2 button devices to re-pair took several hours, even with the C4 shutdown
1 Like
Keep up the fight!
Don't let a ZigBee dongle win!
1 Like
Well the resident expert on dongles, my wife, says my dongle is fine.
Actually I finally got it to pair to my empty C7 hub. The sonoff is the only device on the hub and it took its sweet time to pair, about 3-4 minutes!.
Too bad there isn't a way to transfer the pairing to my production C7 
2 Likes
Yup - that is exactly why I emphasized patience in my point 3. 
2 Likes
Still puzzled about this one... I wonder if your C7 and C4 wound up with the same short PAN ID; since they're randomly generated, it's assumed there will be conflicts so there's a detection/resolution process built into the protocol.
Speculating here... with the coordinators initially running on separate channels maybe the conflict never got detected/resolved. Or maybe a conflict was detected but the resolution process somehow didn't complete during the dual coordinator channel swap (the devices all have to catch up with the coordinators). It might some of the weird behavior you're seeing-- joining devices would scan all channels and have a chance of encountering a matching PAN ID on the wrong hub...
1 Like
Hi Tony, Thank you. The PAN ID on both hubs have been the same for the last 2 years, even after the channel swap. I watch them like a hawk, since when they change, havoc ensues.
That seems a possibility. Also I have 2 xbees on each hub, and maybe those are causing issues? I say this because they have their own binding table and maybe it never got erased or reset, although then shutting down the C4 wouldn't be helping pairing, if the xbee was the cause. I just live with it and shutdown the C4 when pairing on the C7
FWIW, you can tell if a PAN ID conflict was ever detected by looking at the short PAN ID's on each coordinator (shown in Zigbee details above the extended PAN ID). They'll differ by 1 (the conflicting short ID gets incremented rather than being regenerated).
I guess the conflict detection (if there ever was one) happens any time a device sends a beacon frame (at which point it sends both the 64-bit PAN ID along with the 16-bit short PAN ID; if the short ID's match but the extended ID doesn't, that flags the conflict). So conflicting short ID's shouldn't persist in a half-baked state... so no idea how/why your scenario should be happening. Only one of the networks should be in the 'permit join' state by default.
I don't know if this is feasible (or if you have done this already) but one thing I'd try is resetting (not just power cycling) and rejoining every router in the networks (try it first with both coordinators up and running). Supposedly the router's rejoin behavior on subsequent power cycles differs based on some retained parameters from the initial join (silent rejoin which doesn't do some device announce broadcasts that might aid in a conflict detection).
5 Likes
