search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.2k stars 1.6k forks source link

Z-Stack 3 on CC2652R/CC1352P adventures #1429

Closed Koenkk closed 3 years ago

Koenkk commented 5 years ago

NOTE 2020-12-11 locked, please continue here: https://github.com/Koenkk/zigbee2mqtt/discussions/5266

Texas Instruments has recently released a new high performance Zigbee chip: the CC2652R. This chip is much faster and contains much more memory than the CC2530/CC2531.

This issue is created in order to gather feedback of users using the CC2652R AND Z-Stack 3.0 (= Zigbee 3.0)

Notes

lolorc commented 5 years ago

yes, a MCCGQ11LM

Koenkk commented 5 years ago

Was it awake when you did the network scan? Otherwise I expect it to be disconnected.

lolorc commented 5 years ago

My battery powered aqara devices have always been shown as connected whenever they were awake or not. The behaviour changes after replugging the coordinator.

antst commented 5 years ago

Mine almost always disconnected.

I didn't got down to the logic, but it seems that after every replug my coordinator (2530) draws map in one of 2 distinctively different ways. And on one of them battery-powered switches are always disconnected, but fully functional.

Koenkk commented 5 years ago

@lolorc based on my experience and @antst comment, I don't think this is an issue of the CC2652R, which means until now everything is working fine for both of us.

antst commented 5 years ago

So, 2652 is stable now?

Koenkk commented 5 years ago

@antst not yet, but will we know this in the coming days.

antst commented 5 years ago

Tomorrow I will receive one :)

tunip commented 5 years ago

Received the CC2652R today. Will report the next days how it runs with my spare devices.

brtwrs commented 5 years ago

Nice work @Koenkk! Did you test the CC2652R with lange networks? (50+ devices)

Koenkk commented 5 years ago

I don't have a network that large, my production network consists of +- 40 nodes.

brtwrs commented 5 years ago

My network has +-60 devices. I couldn't get it stable with one cc2531 as coordinator so I split my network. Its really really stable right now. But I rather have one network.. not sure what to do here;) Any real advantages that zigbee3.0 and the CC2652R offers?

Koenkk commented 5 years ago

The biggest advantage is that the CC2652R is a much more powerful device (faster chip and more memory). I would be very surprised if the CC2652R wouldn't be able to handle your 60 devices network.

brtwrs commented 5 years ago

I just ordered one! I'll let you know how it handles 60 devices;) Thanks again for all the time you put in this project

kirovilya commented 5 years ago

I also start adventures, but with cc2630 + cc2592 http://www.ebyte.com/en/product-view-news.aspx?id=291 I think it will be like cc2652, also on z-stack 3

ben423423n32j14e commented 5 years ago

Does anyone know of a case for the CC2652R? Retail or 3D printed.

lolorc commented 5 years ago

running 20190423 funny, I repaired some devices and routers to my cc2652r. after ~8h, cc2652r hasn't reported data from half of them, but the other half looks ok. I restart z2m and it fails to reconnect to the cc2652, I guess I'll have to replug it (but I'm not at home) since it was still reporting sensors data, I guess it was still reading from the serial port, but it looks like writting to it is not possible anymore. (cc2652 crashed ?)

will see how things are when the cc2652 is replugged, I've been repairing 20ish devices every day since I start using it, I'll do it again :-)

Koenkk commented 5 years ago

My firmware crashed again, latest status update can be found here: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/794106/2940412#2940412 (25 april).

Will publish this firmware once it is stable for a few days.

lolorc commented 5 years ago

@koenkk i'd be willing to test the firmware :-) I don't mind repairing, replugging every day :-)

Koenkk commented 5 years ago

Fingers crossed, but looks ok now, new firmware: 20190426 (https://github.com/Koenkk/Z-Stack-firmware/tree/dev/coordinator/Z-Stack_3.x.0/bin)

antst commented 5 years ago

How does it work with pairing? Still first 3 minutes only?

lolorc commented 5 years ago

@antst, https://www.ti.com/lit/an/swra615/swra615.pdf "Permit join can no longer be enabled forever as networks will automatically close joining after a maximum of 254 seconds." just resend permit_join true

lolorc commented 5 years ago

mine has crashed with CC2652R 20190426 firmware.

antst commented 5 years ago

I have a problem. I can pair only within first 3 minutes. But after I restart Z2M, some of devices are lost. So, it is infinite loop. I repair some devices, then in the effort to pair more, restart Z2M and some other devices are lost

antst commented 5 years ago

A I wrong, or it looks like channel set in config is ignored and it always assumes channel 11?

lolorc commented 5 years ago

@antst you don't have to restart z2m to be able to pair devices after the 254seconds. mine is supposed to be running on chan 18. and since I've been able to sniff and get data on chan 18 I assume it's correctly working.

antst commented 5 years ago

Interesting. Mine works on channel 11, sniffer confirms that. Same config I use for cc2530, where it is working on 15.

  baudrate: 115200
  report: true
  rtscts: false
  log_level: info
  availability_time: 0
  channel: 15

and without restarting I am unable to pair after some time.

homewsn commented 5 years ago

@kirovilya are you sure there is Z-Stack 3.0 for CC2630/CC2650? I couldn't find it. CC2652R1 and CC2630/CC2650 is very different. 352Kb Flash / 80Kb RAM vs. 128Kb / 20Kb. Cortex-M4 vs. M3.

lolorc commented 5 years ago

@antst after 254s you can't pair anymore, you just have to send the message "true" to the mqtt topic zigbee2mqtt/bridge/config/permit_join you can easily use a one liner while true; do mosquitto_pub -h localhost -t zigbee2mqtt/bridge/config/permit_join -m false; sleep 253; done to make it last :)

kirovilya commented 5 years ago

@homewsn You are right. I found mention about it in z-stack-archive http://www.ti.com/tool/z-stack-archive But do not known how to build it. yet...

homewsn commented 5 years ago

@kirovilya I'm not sure about versions 3.0.0 and 3.0.1. Version 3.0.2 contains ZNP projects only for CC2530/2531/2538. Z-Stack Home contains CC2630/2650 project. But it's not R21 spec stack.

antst commented 5 years ago

Did someone try to solder external antenna already?

antst commented 5 years ago

I still see in sniffer absolutely no traffic on the channel which 2652 is supposed to use (I tried 15 and 13, 20 out of curiosity) Traffic between 2652 and devices is still on the channel 11.

This is my config

homeassistant: false
permit_join: true
mqtt:
  base_topic: zigbee2mqtt1
  server: 'mqtt://192.168.2.12'
serial:
  port: /dev/tty.usbmodemL11008PV1
advanced:
  pan_id: 6755
  baudrate: 115200
  report: true
  rtscts: false
  log_level: info
  channel: 20

The only traffic I see on channel 20 (in case of this config) is when I reset device to pair and it performs initial broadcasts over all channels, but nothing else.

lolorc commented 5 years ago

with whsniff I don't see any traffic on chan 11 and I see traffic on the channel I've chosen from devices to the coordinator.

edit: is it possible the channel is read from coordinator_backup.json rather than from configuration.yaml ? looking at mine, I've just discoverd it wasn't using the network_key specified in configuration.yaml but the one in coordinator_backup.json

Koenkk commented 5 years ago

@antst I think this is a bug in the newer code which doesn't allow you to change the channel after the coordinator has been started once. To verify this, can you:

antst commented 5 years ago

And how is it with the PAN id now? still unchangeable?

Koenkk commented 5 years ago

@antst yes, still WIP

antst commented 5 years ago

Is it stable now? I want to try again today. But takes hell of a lot of the time to repair everything and to rename )

lolorc commented 5 years ago

nope, mine still crashes every 12-24h with CC2652R 20190426

Koenkk commented 5 years ago

Still crashes indeed, currently waiting for input from TI (https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/794106/2940412)

Koenkk commented 5 years ago

@antst can you check if the channel setting works now?

@lolorc the crashing may occur because we restore from a firmware with too large device tables. See https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/794106/2949103#2949103

Can you:

lolorc commented 5 years ago

@Koenkk done, it's still not using the network_key i've specified in configuration.yaml. despite removing data/coordinator_backup.json after reflashing and before starting z2m

antst commented 5 years ago

@Koenkk what do you mean by "now"? By using procedure you described? I don't see new commits in firmware.

Reflashing and removing backup - works.

lolorc commented 5 years ago

@antst, are you using a specific network key ? Would you mind checking with your sniffer if it's really using it ?

Koenkk commented 5 years ago

@antst forgot to commit, done now.

lolorc commented 5 years ago

mine has crashed

Koenkk commented 5 years ago

@lolorc mine also https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/794106/2951499#2951499

fredrikgk commented 5 years ago

@antst If you want to use an external antenna, you should build the firmware for CC1352R and use a CC1352R LaunchPad instead. This board has a proper SMA connector, you only need to resolver one component to change from the onboard PCB antenna to the connector.

That being said, the PCB antenna on both the CC2652R and the CC1352R LaunchPads are very good, and comparable to external dipoles as long as they are placed in free air.

BudBundi commented 5 years ago

One dumb question, with Zigbee 3.0 would it possible to get the group id from the IKEA remotes and send them to the lamps like their original behavior?

Koenkk commented 5 years ago

@BudBundi actually not a dumb question! I've tried this, however it seems that a coordinator cannot become a touch link target, meaning that the touch link initiator (TRADFRI remote) cannot share the group ID to the coordinator. Note that the IKEA gateway also does not retrieve the group id from the remote so the current behaviour is already the "original behaviour".