search

zigpy / zigpy-znp

TI CC2531, CC13x2, CC26x2 radio support for Zigpy and ZHA
GNU General Public License v3.0
145 stars 40 forks source link

[HW RECOMMENDATIONS] CC1352P-2 verses CC26X2R1 (CC2652/CC2652P) verses CC2652R/CC2652RB-based Zig-a-zig-ah? #10

Closed Hedda closed 3 years ago

Hedda commented 4 years ago

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:

puddly commented 4 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.

Hedda commented 4 years ago

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

https://www.ti.com/product/CC2652R

puddly commented 4 years ago

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.

Adminiuga commented 4 years ago

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

puddly commented 4 years ago

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.

Adminiuga commented 4 years ago

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.

puddly commented 4 years ago

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())
puddly commented 4 years ago

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

  1. I don't know if a different channel is in use now. There's no way (as far as I can tell) to see what specific channel from the mask is actually in use but since my Xiaomi sensors seemed to start reporting instantly after the network started back up, I believe it didn't change.
  2. The ZZH is positioned in the exact same place as the LAUNCHXL-CC26X2R1. The TI dev kit was laying flat on a table so maybe it should have been mounted vertically for optimal range.
  3. Both were running with the TX power set to +19.

@omerk: Thanks for the awesome kit. Some suggestions for future revisions of the board:

  1. Would you consider using a USB-serial chip by FTDI or Silicon Labs? The CH340 is the only USB-serial chip that consistently causes a kernel panic on my MacBook and is overall unreliable in my experiences with random dev kits. I'm running kernel 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.
  2. While a minor detail, holding down the flash button while inserting the stick is difficult with the button mounted horizontally and near the male USB-A connector. It would be a bit easier to flash if the button was mounted near the rear of the board next to the antenna.
  3. I'm not sure if there's a huge price difference for you but including one of those bendable and rotatable 2.4Ghz antennas would make it easier to mount. Most of my USB devices are plugged into a powered hub with the ports sticking straight up and the fixed right-angle antenna connector makes mounting a little difficult.
Adminiuga commented 4 years ago

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

puddly commented 4 years ago

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

puddly commented 4 years ago

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.

Adminiuga commented 4 years ago

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

omerk commented 4 years ago

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

Hedda commented 4 years ago

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!

puddly commented 4 years ago

@Hedda So to answer your original question:

Hedda commented 4 years ago

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

puddly commented 4 years ago

I'd expect it work. I don't have the hardware so no guarantees.

puddly commented 3 years ago

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.