CC2538 Support?

[dumpfheimer]

Due to lqi issues I ordered a CC2538, hoping I can replace my current ZZH! with a high power coordinator.

I realized, that zigpy sais support is experimental, using Z-Stack 1.2 and zigpy-cc (https://github.com/zigpy/zigpy/)
On zigbee2mqtt they suggest using Z-Stack 3.0 (https://www.zigbee2mqtt.io/information/supported_adapters#texas-instruments-cc2538-with-cc2592-rf-amplifier)

What can I expect from using a CC2538 with zigpy-znp? Is zigpy-znp more bound to the coordinator software (Z-Stack Version) or to the device itself?

Thank you for your time.

[puddly]

I don't own this hardware but zigpy-znp supports all versions of Z-Stack and has been tested on every other hardware combination except for this one. It should support the CC2538 without any major modifications (if any at all). Just make sure you run the correct firmware and enable the power amplifier in your configuration.yaml:

zha:
  zigpy_config:
    znp_config:
      tx_power:  19

Maybe by the time your stick arrives we'll get cross-device network migration working so you won't have to re-join all of your devices to the new network.

The only problem I can foresee is zigpy-znp's use of device-specific structures for low-level radio details so if you could, enable debug logging before you first plug it in and post the log here (it'll contain a randomly-generated network secrets but you can always reset the network with python -m zigpy_znp.tools.nvram_reset /dev/serial/by-id/your-radio).

[dumpfheimer]

Nice, good to hear!
I ordered it from Asia, so it will likely take a few weeks, but I will report back as soon as I have it in my hands and can try using it with zigpy.

Shot in the dark: is it worth trying to create a backup of my CC2652 and restore it on the CC2538 or could that possibly break something?

Thanks!

[puddly]

100% chance it won't work. Z-Stack 3.0.2 and newer Z-Stack releases have different NVRAM layouts and your device probably has a different architecture so the paddings on all the encoded structs will be wrong.

[dumpfheimer]

Okay, got it, thanks! I'll hope for the migration then ;-)

But I'm getting quite good at re-pairing it too, so..

One more thing: is it possible to run 2 zigpy (over hass) with 2 controllers and 2 different networks?

[puddly]

I believe there may be a way with https://github.com/lukas-hetzenecker/home-assistant-remote but I have not personally tried it.

One thing to be aware of is that the CC2538 is stuck with the end-of-life Z-Stack 3.0.2 firmware, so you won't be able to utilize all of the new bugfixes and features in later releases of Z-Stack. If you're looking for a coordinator with more range (and you cannot for whatever reason just extend your mesh with more routers), consider the LAUNCHXL-CC1352P-2, which incorporates a power amplifier but is still actively supported by Texas Instruments' Z-Stack.

[dumpfheimer]

Oh no! That is bad news to wake up to.

I am having link quality issues, not sure why. I have about 35 lights on 2 floors, the coordinator (ZZH!) is on the lower floor, most of the lights in the top floor (~15 lights) have an lqi of around 40 and are quite often dropping out of the network or not responding. But also in the lower floor some lights (5-6m in sight of the coordinator) have a link quality of ~40). For some strange reason some of those lights sometimes for a short period of time have a link quality of ~110 and respond perfectly fine.

I was hoping if the coordinator is strong and can handle many directly connected devices, they would more likely speak directly to each other and (if this actually was the problem) avoid bad routes.

Also, at the same time, I am in contact with ZZH! support, as I am suspecting there might be issues with the stick itself, because the experiences of other people seem to not represent what I am seeing.

Anyway: thanks for the link! I was hoping I could simply add another config entry or something like that. I am trying to keep things simple and as close together, and as close to hass, as possible (which was why I wanted to get rid of deconz in the first place) for multiple reasons (open source, speed of development, simplicity, community support, possibility of contributing / fixing things myself).

Is the LAUNCHXL-CC1352P-2 the best thing I can get my hands on?
I do not want to waste another piece of hardware, and money (I'm up to 2 bridges and 4 usb coordinators now, might open up a shop soon).

Thanks again for your help - really appreciate it!

[puddly]

I have about 35 lights on 2 floors, the coordinator (ZZH!) is on the lower floor, most of the lights in the top floor (~15 lights) have an lqi of around 40 and are quite often dropping out of the network or not responding.

If you're currently using ZHA with the ZZH!, please try installing the latest dev version of zigpy-znp: https://github.com/zigpy/zigpy-znp#testing-dev-with-home-assistant-core. It contains some route repairing logic that isn't present yet in the stable release installed by Home Assistant and may fix some of your problems.

For some strange reason some of those lights sometimes for a short period of time have a link quality of ~110 and respond perfectly fine.

Link quality is only for the last hop. For example, if you have a bulb right next to the coordinator and another bulb 200ft away, the reported link quality for the distant bulb may be very high if it's routing through the bulb next to your coordinator, or very low if it's routing directly.

[dumpfheimer]

I am already on the dev channel, and things definately got better. I believe since 2 days I have had no light drop out of the network, but they did get unavailable from time to time. But not having to re-join the devices is a huge step forward, so thank you 🙏

I did not know, that LQI is only for the last hop, good to know. Looking at my ZHA map the coordinator pretty much is the only device (except for a few end devices), that has not a single green line.
To be fair, I never saw lqi in deconz, but response times were fine and I never had devices dropping out, so all of this together definately is making me think there might be something wrong with the stick or the conbee might have more power.

I am sure there are much more possible reasons, but ruling those two out first makes sence to me.

A question concerning zigbee software: is it possible to choose the devices directly connected with the coordinator?
Simply by counting it looks like the directly connected devices are limited to ~20? could that be right?

I would like to try an experiment where I - if possible - somehow manually choose the routes or manually choose the directly connected devices. By fiddling around with those I might be able to achieve a more reliable route for certain clusters.

[puddly]

I am already on the dev channel, and things definately got better. I believe since 2 days I have had no light drop out of the network, but they did get unavailable from time to time.

If you can get some debug logs for zigpy-znp maybe you can see what types of errors cause the lights to be unreachable long enough for ZHA to mark them as unavailable. They should show up as RuntimeError exceptions in your logs and tell you the status code. If you're using HA OS, zigpy-znp's latest commit will be installed every time you restart HA. If you're using a HA Core install, you'll have to re-run that pip install command to pull in the latest changes.

A question concerning zigbee software: is it possible to choose the devices directly connected with the coordinator?
Simply by counting it looks like the directly connected devices are limited to ~20? could that be right?

Not really. I think routers should be periodically scanning for neighbors and will pick new routes over time. Someone else with a large network saw about 26 devices connected directly to their coordinator but I think the hard limit for child devices directly joined to the coordinator is about 40.

I would like to try an experiment where I - if possible - somehow manually choose the routes or manually choose the directly connected devices. By fiddling around with those I might be able to achieve a more reliable route for certain clusters.

If you're comfortable with Python, you can do this by editing the following code and manually specifying the NWK addresses to send packets through based on each router's NWK instead of letting zigpy-znp retry by sending the packet backwards via the last observed route:

zigpy-znp/zigpy_znp/zigbee/application.py

Lines 1494 to 1503 in 8901975

	elif (
	not tried_last_good_route
	and device is not None
	and device.relays is not None
	):
	# `ZDO.SrcRtgInd` callbacks tell us the last path taken by
	# messages from the device back to the coordinator. Sending
	# packets backwards via this same route may work.
	force_relays = device.relays[::-1]
	tried_last_good_route = True

It'll only run if the original request fails a few times, though.

[dumpfheimer]

Thanks I will definitely give it a try!
Maybe I can come up with an automatic way to choose the best route.

[dumpfheimer]

I should get my hands on a CC1352 today, is there currently any way to try the cross-device network migration you were talking about?

[puddly]

Not at the moment but I'll probably have some time to give it a shot in a few days.

[dumpfheimer]

just curious: where did you get the information that cc2538 is at end of life?
they seem to hide that pretty well..
and do you know the motivation behind it? for me it looks like the most powerful chip..

[puddly]

The last Z-Stack update for it was released more than two years ago and it will not support the newer route discovery features that improve network stability because the version of Z-Stack that it's stuck with supposedly has glitches.

As for power, it does have a little more built-in flash than the CC1352P but has half the RAM, a less sensitive receiver, and an older generation ARM processor without support for a new class of instructions and floating point operations. I don't think the CC2538 is more powerful than the CC1352P.

[dumpfheimer]

Thanks for clearing this up, glad to have bought one then.
I have the LXL CC1352P lying next to me (and currently a ZZH! in use) and am happy to test your network migration if you need someone.