CC2538 und CC2530+CC2592 ZigBee Raspberry Pi Modul

2538 has non volatile memory as well as volatile one. For the later, its contents are lost in case of the ‘stick’ losing power. Because of that, it should contain only the program stack and variables that do not need saving.

My guess is that they did some firmware adjustments that moved something critical in the volatile memory so some very important settings are lost when losing power.

The solution would be to use a firmware that does not have those changes (it won’t be able to deal with so many devices, though).

1 Like

Thank you Adrian.
Did you come across the problem on both, the modkam and jethome, firmware?

I’ve just asked Giovanni on Tindie if he has the same issues:

Only modkam one was signaled to me.

Jethome is here:

It’s also linked by Koenkk:

Currently testing zigbee2mqtt with modkam from March last year. Connected are an innr plug and an xiaomi battery temperature sensor.

I will try different firmwares and check for the behavior.
Getting back to you guys as soon as I have some insight.

Currently replicateable:

CC2538 (dev board of mine) with ModKam from 2020-03-27 (should be revierline), innr plug, xiaomi sensor.


Both worked, sudo halt on the PI, removed power and put it back, after boot start zigbee2mqtt. No devices react/send. Waited 15minutes, still the same.

Pushed the button on the Xiaomi, typically it sends data then -> nothing can be seen in z2m
Switched the plug -> nothing can be seen in z2m

long press xiaomi to repair:

Zigbee2MQTT:info  2021-01-19 12:43:47: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00158d000309a241","ieee_address":"0x00158d000309a241"},"type":"device_announce"}'
Zigbee2MQTT:info  2021-01-19 12:43:47: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"0x00158d000309a241"},"type":"device_announced"}'
Zigbee2MQTT:info  2021-01-19 12:43:48: MQTT publish: topic 'zigbee2mqtt/0x00158d000309a241', payload '{"battery":100,"humidity":55.43,"linkquality":199,"pressure":972.7,"temperature":22.6,"voltage":3055}'

long press on the innr plug:

Zigbee2MQTT:info  2021-01-19 12:44:24: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x680ae2fffe7249a8","ieee_address":"0x680ae2fffe7249a8"},"type":"device_announce"}'
Zigbee2MQTT:info  2021-01-19 12:44:24: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"0x680ae2fffe7249a8"},"type":"device_announced"}'

both working.

Other step’s I’ve taken to reproduce:

  • Simple Restart of zigbee2mqtt - everything is working
  • Stopped zigbee2mqtt, waited half an hour and restarted - everythings working.
  • Stopped z2m, pulled the module of the GPIO, plugged it back and started z2m - same behavior as a reboot of the pi with cutting power
  • Reboot of Pi without cutting power- same behavior as a reboot of the pi with cutting power

So, I’ve tested all for me know variants of the firmware and all have the same problem:

zigbee2mqtt 1.17.0
zigbee-herdsman 0.13.46

Revision cold reboot reboot reboot + wait z2m restart comment
revierline 20200327 no no no yes without SBL
jethome 20201010 no no no yes with SBL
modkam 20200211 no no no yes with SBL

“yes” means you did not have to re-pair respectively to “anounce” the device again. Often a complete re-pair is not needed.

I find it rather confusing that obviously nobody ever made that observation. Is it confirmed that this also happens with the USB variants of the CC2538?

1 Like

Hello Peter, thanks to invite me…
I’ve asked to perform same test with different firmware using my hardware and will let you know.
I don’t have any USB stick (all sold out) but I’ll do same test with CC2538 via USB once I’ll have new batch of dongles…

1 Like

Hey @GiovanniC, thanks for joining the conversation.


I have currently 46 devices paired to my zigbee2mqtt with that adapter, so i hope i do not need to restart that pi.I am a bit happy it is also responsible for managing the ups.

1 Like

Here are the used firmware for reference:

Modkam V3 UART with SBL: MODKAM-STICK-V3/firmware/cc2538/Riverieline_2020-02 at master · egony/MODKAM-STICK-V3 · GitHub
Revierline: GitHub - reverieline/CC2538-CC2592-ZNP: Z-Stack 3.0.2 minimal coordinator building patch for CC2538-CC2592 module
Jethome: zigbee-firmware/ti/coordinator/cc2538_cc2592 at master · jethome-ru/zigbee-firmware · GitHub

@Adrian, could you maybe comment on this: Z-Stack 3 on CC2538 adventures · Discussion #1568 · Koenkk/zigbee2mqtt · GitHub

hi Patrik, just did the test with my setup:

  • Raspberry PiZeroW + CC2538 piHat
  • firwmare MODKAMRU 20200211
  • paired devices: Xiaomi Click, Aqara Water Leak; IKEA Dimmer

I make the most brutal test, unplug microUSB while zigbee2mqtt was running, after plug it back PiZeroW restarted I run zigbee2mqtt and all sensors are wokring as expected; I did it 3 times and always the same results.

1 Like

Hey Giovanni, it’s Patrik :slight_smile:

Ok, could you maybe link the used firmware? Will test again tomorrow. Did the “pull USB power cord” thing also…
Which z2m/herdsman version were you using? Also, could you post your config?

If it’s ok for you, could you share the schematics? Would be painfull but maybe I missed something. And, did you change anything for the UART besides what’s mentioned in UART configuration - Raspberry Pi Documentation?

Sorry if this is much what I’m asking…


The chance of the issue being from the external software is low, as it manifests in the homgear zigbee module as well.

1 Like

I will check for this later today:

used the one dowloaded here --> MODKAM-STICK-V3/firmware/cc2538/Riverieline_2020-02 at master · egony/MODKAM-STICK-V3 · GitHub
zigbee2mqtt is latest version, 1.17.0; as this is my test unit I did not change anything in the config, it’s the one that comes with z2m where I only put the right port (/dev/ttyAMA0) and my mqtt credential, no other changes or additions.
I followed the link you posted to configure raspbian (I do use Raspbian Lite).
Will add later my schematic, basically the only difference I can see with yours is that you take 3.3v power from the PI while I take 5V and bring it down to 3.3V with an LDO and proper capacitors to keep the power more stable, not sure if this can make a difference


Is there a chance that the 50mA max which the Pi can provide on 3.3V is not enough for NVRAM write access?

Transmit current of the CC2592 amplifier looks critical to me…

Unfortunately usage of external power supply didn’t help, as my highly sophisticated lab setup proved…

Behaves the same, after reboot / power outage, everything’s gone.

1 Like