Closed Hedda closed 3 years ago
The CC1352P-2 (make sure it's the -2
, the other ones perform worse at 2.4GHz) seems like the most powerful radio. I don't own anything but the CC26X2R1 but the added amplifier may be worth the extra $10
Range-wise, my CC26X2R1 can simultaneously control 20 individual bulbs within a second or two and has a LQI of 42 when communicating with a porch light 40 feet away from the radio. The CC1352P should perform better.
The Electrolama Zig-a-zig-ah prototype seems to be in postal limbo right now but I'll post a range comparison once it arrives.
@puddly What are the RSSI (and LQI) values reported by your different CCxxxx devices and sensors?
FYI, I read that OmerK has been or is looking after manufacturing partner(s) for the Electrolama Zig-a-zig-ah (zzh) adapter for a production version. Read that he was/is considering both crowdfunding sites, such as Crowd Supply and Tindie, as well as companies with already established supply-chains, like ITead (of Sonoff fame).
Anyway, current Zig-a-zig-ah prototype is also lacking PA (Power Amplifier) as it doesn't use CC2652P
https://electrolama.com/projects/zig-a-zig-ah/
"Also thinking of a second variant that uses CC2652P, sadly not pin compatible with CC2652R (or CC2652RB) so this will have be a new board spin. "P" part has a built-in PA (but no LNA) and should provide better range."
https://www.ti.com/product/CC2652P
C2652R look to have practically the same spec as CC2652P but without integrated PA (Power Amplifier)
My only TI devices right now are the CC26X2R1 and the zzh adapter, both utilizing the same chip. I'll try migrating my network to the zzh and testing it in the next couple of days.
What's you plan for migration? Re-pair all devices?
I've tried migrating to ConBee by cloning pan id, ext pan id, network key and Mac address. Killed my ConBee II but it actually worked on ConBee I.
Without cloning the Mac address we would need to crawl all devices, delete old bindings to coordinator and bind new ones. Could skip xiaomi since those don't respond and send all report to 0x0000 anyways
I'm just thinking of blindly copying every single NVID from one controller to the other. It didn't work last I tried it but that's probably because some failed to write due to them not being initialized.
ah, you are migrating from another TI chip. I was thinking migrating from EZSP HUSBZB-1. I think in the grand schema of things, just need PAN ID, Ext PAN ID, network key, network key seq # and Network update id. And then have to re-do all the bindings. But need to test IAS sensor migration. probably would need to to update CIEEE address. gonna be fun if I ever pull it.
Yeah. It's a little rough but this works for me:
import asyncio
import logging
import coloredlogs
import zigpy_znp.types as t
import zigpy_znp.commands as c
from zigpy_znp.api import ZNP
from zigpy_znp.exceptions import InvalidCommandResponse
from zigpy_znp.types.nvids import NwkNvIds, OsalExNvIds
from zigpy_znp.config import CONFIG_SCHEMA
coloredlogs.install(level=logging.DEBUG)
logging.getLogger('zigpy_znp').setLevel(logging.DEBUG)
LOGGER = logging.getLogger(__name__)
async def main():
new = ZNP(CONFIG_SCHEMA({
'device': {
'path': '/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0',
}
}))
await new.connect()
old = ZNP(CONFIG_SCHEMA({
'device': {
'path': '/dev/serial/by-id/usb-Texas_Instruments_XDS110__03.00.00.12__Embed_with_CMSIS-DAP_L1100H86-if00',
}
}))
await old.connect()
for nvid in NwkNvIds:
LOGGER.info('Trying %s', nvid)
try:
value = await old.nvram_read(nvid)
LOGGER.info('Value is %s', value)
except InvalidCommandResponse:
LOGGER.warning('Read failed %s', nvid)
continue
# XXX: are any NVIDs not filled all the way?
init_rsp = await new.request(c.Sys.OSALNVItemInit.Req(Id=nvid, ItemLen=len(value), Value=value))
assert init_rsp.Status in (t.Status.Success, t.Status.ItemCreated)
try:
await new.nvram_write(nvid, value)
LOGGER.info('Write succeeded')
except InvalidCommandResponse:
LOGGER.warning('Write failed')
for nvid in OsalExNvIds:
LOGGER.info("Trying %s", nvid)
length_rsp = await old.request(c.Sys.NVLength.Req(SysId=1, ItemId=nvid, SubId=0))
length = length_rsp.Length
if length == 0:
LOGGER.warning("Read failed %s", nvid)
continue
value = (await old.request(c.Sys.NVRead.Req(SysId=1, ItemId=nvid, SubId=0, Offset=0, Length=length), RspStatus=t.Status.Success)).Value
LOGGER.info("Value is %s", value)
try:
await old.request(c.Sys.NVWrite.Req(SysId=1, ItemId=nvid, SubId=0, Offset=0, Value=value), RspStatus=t.Status.Success)
LOGGER.info('Write succeeded')
except InvalidCommandResponse:
LOGGER.warning('Write failed')
pass
if __name__ == '__main__':
try:
get_ipython()
await main()
except NameError:
await asyncio.run(main())
🎉 My network started back up without any issues after doing the NVRAM migration between the TI dev kit running Z-Stack 3.30.00.03 and the ZZH running 4.10.00.78! 🎉
Both coordinators are able to control my network (obviously with only one plugged in at any given time).
Here's a not-very-rigorous comparison of the LQIs reported by bulbs and switches controlled by both boards:
Device | LAUNCHXL-CC26X2R1 | ZZH | % Change |
---|---|---|---|
0xB933 | 60 | 87 | +45.00% |
0x1B30 | 63 | 91 | +44.44% |
0xFBA4 | 70 | 84 | +20.00% |
0x83FE | 72 | 79 | +9.72% |
0x9E5C | 72 | 123 | +70.83% |
0xA2B9 | 77 | 103 | +33.77% |
0x43FD | 87 | 87 | +0.00% |
0xEC9B | 106 | 149 | +40.57% |
🎉 For me, the ZZH has an average improvement in LQI of about 33% over the LAUNCHXL-CC26X2R1! 🎉
Some details:
+19
.@omerk: Thanks for the awesome kit. Some suggestions for future revisions of the board:
4.14.176
on my ODROID XU4 and the zzh stick needs to be re-plugged a few times in a row to respond to any serial communications, unless it's plugged into a USB extender (!?). I have half a dozen other USB devices plugged in at any given time and have never had this problem except with devices using the CH340.@puddly did the MAC address of coordinator changed? Or did you reconfigure the devices? The reason I'm asking: zigpy binds clusters using IEEE address, so if the IEEE address of coordinator changes, we're not supposed to see attribute updates unless you reconfigure/create bindings with the new IEEE addr.
@Adminiuga
I can check with a sniffer but I don't think so, I believe it was cloned via the NwkNvIds.EXTADDR
NVID. Other than sending a bunch of messages and waiting for the ZNP stack to re-discover the routes, I didn't do anything to get my my end devices working again, including Xiaomi sensors connected directly to the coordinator.
If you're interesting in trying, you might be able to migrate by writing the right stuff to non-volatile memory. Here are the only NVIDs that change after forming a network on a freshly flashed board:
{
NwkNvIds.NIB: b"I\x05\x023\x143\x00\x1e\x00\x00\x00\x01\x05\x01\x8f\x00\x07\x00\x02\x05\x1e\x00\x00\x00\x0f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00X\x82\x08\x00\x00\x80\x00\x00\x0f\x0f\x04\x00\x01\x00\x00\x00\x01\x00\x00\x00\x00z\xb2\x1eY\x19UF'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0f\x03\x00\x01x\n\x01\x00\x00\x00/2\x00\x00",
NwkNvIds.EXTENDED_PAN_ID: b"z\xb2\x1eY\x19UF'",
NwkNvIds.NWK_ACTIVE_KEY_INFO: b'\x00j\x8f\xbbu\xb2\xe8\xd9m\xe5\xc5-\x9d\x18VA\x1d',
NwkNvIds.NWK_ALTERN_KEY_INFO: b'\x00j\x8f\xbbu\xb2\xe8\xd9m\xe5\xc5-\x9d\x18VA\x1d',
NwkNvIds.GROUP_TABLE: b'\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff',
NwkNvIds.APS_LINK_KEY_TABLE: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',
NwkNvIds.BDBNODEISONANETWORK: b'\x01',
NwkNvIds.HAS_CONFIGURED_ZSTACK3: b'U',
NwkNvIds.PRECFGKEY: b'j\x8f\xbbu\xb2\xe8\xd9m\xe5\xc5-\x9d\x18VA\x1d',
NwkNvIds.NWKKEY: b'\x00j\x8f\xbbu\xb2\xe8\xd9m\xe5\xc5-\x9d\x18VA\x1d\x88\x00 V\x0f\r\x00',
NwkNvIds.PANID: b'X\x82',
NwkNvIds.CHANLIST: b'\x00\x80\x00\x00',
NwkNvIds.LEAVE_CTRL: b'\x00',
NwkNvIds.TCLK_SEED: b'\x03wv6\xf2\xa4~\xcc\xf8\xa9\xa7\xc3\x92\xad\xb9$'
}
I'll have to also check out the eight OsalExNvIds
NVIDs as well, as they seem to be what I was missing when I tried migrating last time.
Now that I think about it, the only IAS sensor I have is on a separate network controlled by bellows. I'll let you know if it migrates as well using this approach when I get some time to implement the ZDO binding commands and test it out.
Thanks, I'll check the EXTADDR, although this is more out of curiosity for a drop-in replacement. I probably not going to clone the address, as not sure if would run into any issues if I'll run the old HUSBZB on a separate network.
@omerk is it possible to customize the USB-Serial chip, so it provides a more specific description for serial port device? Currently I"m getting generic:
usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
@puddly Congrats on getting things up and running and thanks for your suggestions, addressed them on https://github.com/electrolama/zig-a-zig-ah/issues/12
@Adminiuga Unfortunately CH340E does not have an EEPROM so strings/VID/PID can not be customized.
ah, you are migrating from another TI chip. I was thinking migrating from EZSP HUSBZB-1. I think in the grand schema of things, just need PAN ID, Ext PAN ID, network key, network key seq # and Network update id. And then have to re-do all the bindings. But need to test IAS sensor migration. probably would need to to update CIEEE address. gonna be fun if I ever pull it.
@Adminiuga @puddly Are you guys suggesting that it would be possible to script a migration feature/function built into zigpy that allow users to relatively easily migrate from one Zigbee coordinator hardware adapter to a other type of Zigbee coordinator hardware adapter even if they are not using the same radio library?
Migrations such as these could become common as new more powerful adapters become available:
Would still be an awesome feature even if it was only possible to migrate within the same radio type:
Would really be an awesome feature to have if could be made user-friendly for integration like ZHA!
@Hedda So to answer your original question:
I would recommend the zzh over the CC26X2R1. They cost about the same for me with shipping (though the zzh is itself cheaper) and the zzh has better range, is much more compact, has a shell for the exposed PCB, and you'd be supporting the open source Zigbee community by purchasing it.
Until the zzh-p comes out, I think the most powerful radio is still the CC1352P-2. It's a bit more expensive but has a built-in RF power amplifier. I don't have any way to give you an objective LQI comparison between the three because I don't have a CC1352P-2.
@puddly Thanks! If I buy the CC2652R based zzh now what do you think about a possible migration feature for upgrading to a newer adapter later like CC2652P based zzh-p as per the request in https://github.com/zha-ng/zigpy-znp/issues/19 ?
I'd expect it work. I don't have the hardware so no guarantees.
I think enough external documentation exists comparing the benefits and drawbacks of each TI radio on the Zigbee2MQTT documentation site and in other places so I'm going to close this issue.
What hardware would you recommend someone to buy for Z-Stack 3.x Zigbee coordinator firmware?
Personally I am low on funds right now so thinking of just waiting for someone like Electrolama to start mass-producing and selling plug-and-play CC2652-based adapters such as their Zig-a-zig-ah ("ZZH") USB-stick at a lower price, but what hardware would you recommend today to someone who has enough funds now and is not willing to wait?
There are quite a few to choose from in Texas Instruments current SimpleLink multi-standard family:
http://www.ti.com/wireless-connectivity/simplelink-solutions/multi-standard/products.html
It looks like most people in the Zigbee2mqtt community who has made the lead is currently recommending the slightly more expensive CC13x2 based LAUNCHXL-CC1352P-2 development kit over the CC26x2 based LAUNCHXL-CC26X2R1 development kit for a number of reasons, though mainly because CC1352P-2 has a built-in RF-amplifier (PA/LNA) frontend as well as an SMA-connector for an external antenna and therefore has a much better link quality (people are even complaining that LAUNCHXL-CC26X2R1 has worse link quality than a CC2531 with an external antenna).
LAUNCHXL-CC1352P-2
LAUNCHXL-CC26X2R1
Other notes: