CC2538 und CC2530+CC2592 ZigBee Raspberry Pi Modul

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…

Cheers,
Patrik

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

2 Likes

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

@trapperjohn, thank you so much for testing… wanted to do this myself and had hope that it would help. Sad that it didn’t… :confused:

Nevertheless, I think the next version should include an LDO as @GiovanniC mentioned - and when it’s only to play it safe.

Albeit the 33uF Tantalum is exactly for that as mentioned in the datasheet.

I will try to investigate the thing with the serial state of the Pi. It was mentioned here:

If this causes the problem it should be hopefully solvable with some config.txt tweaking.

If anybody has some ideas, let me know. I must admit that I’m a bit on a dead end currently.

Thank you guys!

Cheers,
Patrik

Do you have the possibility to try the same with a Zigbee light? In my tests I could see that Ikea remotes worked after power loss - probably because they actively transmit something. All your sensors also send data autonomously, i.e. they should also work with the Pi module.

But lights do nothing until correctly addressed (which seems to fail). Therefore I see a small chance they might also break on your USB setup.

1 Like

I do not have bulb in my lab at the moment, will try to ask a friend to lend me one for few days to make that test and will let you know…

2 Likes

@pmayer In your design the USB pins are floating, right? Might this introduce errors? Just a shot in the dark, in case the USB version of @GiovanniC is working…

1 Like

Good idea! Thank you. Hopefully I will find time to test this today.

Nevertheless, @GiovanniC is also using the UART, not USB.
The MODKAM Stick also does not connect the USB Pins:

all my dongle and hat use UART solution; in the past I was using the USB but switched to UART as it allows easier flash of the dongle by the users…

1 Like

danke das ihr euch um das Problem kümmert,

ich habe mir einen “Bausatz” (ZigBee 3.0 USB Stick KIT with CC2538 /CC2592 + PCB+ Components - New!) über die Bucht zukommen lassen, welcher die USB Schnittstelle nutzt, der JTag-Debugger ist unterwegs, wenn die Sachen da sind, werde ich die USB Variante testen,

die weiter oben angesprochenen Tests mit habe ich nicht gemacht, da andere Nutzer bereits den “negativen” Verlauf geschildert haben.

mfg BC

One could still try to run the module from a USB/serial adapter cable to eliminate the potential issues with the Pi UART interface at boot… that’s at least worth a quick test :wink:

1 Like

Tried to check USB connection but failed - could not get zigbee2mqtt to run. When connecting through an USB adapter (ch340 chipset) the initial communication between zigbee-herdsman and the module works (at least the debug output shows some responses from the module) but during startup it fails at a certain point (timeout) and zigbee2mqtt stops.

Direct GPIO connection on the Pi still works as before.

I have some additional debug logging of communication when toggling a bulb:

Successful toggling looks like this:

Zigbee2MQTT:debug 2021-01-26 14:58:30: Received MQTT message on 'rftest/office_e14/set' with data '{"state":"OFF"}'
Zigbee2MQTT:debug 2021-01-26 14:58:30: Publishing 'set' 'state' to 'office_e14'
2021-01-26T14:58:30.782Z zigbee-herdsman:controller:endpoint Command 0x000d6ffffe01a4ef/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null})
2021-01-26T14:58:30.801Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x000d6ffffe01a4ef:35665/1 (0,0,1)
2021-01-26T14:58:30.815Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":35665,"destendpoint":1,"srcendpoint":1,"clusterid":6,"transid":2,"options":0,"radius":30,"len":3,"data":{"type":"Buffer","data":[1,3,0]}}
2021-01-26T14:58:30.819Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,13,36,1,81,139,1,1,6,0,2,0,30,3,1,3,0,233]
2021-01-26T14:58:30.839Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2021-01-26T14:58:30.842Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2021-01-26T14:58:30.845Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2021-01-26T14:58:30.849Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2021-01-26T14:58:30.852Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2021-01-26T14:58:30.859Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,1,2,196]
2021-01-26T14:58:30.862Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,2,196]
2021-01-26T14:58:30.865Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,2] - 196
2021-01-26T14:58:30.869Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":2}
2021-01-26T14:58:30.872Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2021-01-26T14:58:30.899Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,25,68,129,0,0,6,0,81,139,1,1,0,57,0,211]
2021-01-26T14:58:30.902Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,25,68,129,0,0,6,0,81,139,1,1,0,57,0,211]
2021-01-26T14:58:30.908Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [44,21,0,0,5,8,3,11,0,0,81,139,29,17]
2021-01-26T14:58:30.911Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,25,68,129,0,0,6,0,81,139,1,1,0,57,0,211,44,21,0,0,5,8,3,11,0,0,81,139,29,17]
2021-01-26T14:58:30.914Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 25 - 2 - 4 - 129 - [0,0,6,0,81,139,1,1,0,57,0,211,44,21,0,0,5,8,3,11,0,0,81,139,29] - 17
2021-01-26T14:58:30.920Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":6,"srcaddr":35665,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":57,"securityuse":0,"timestamp":1387731,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[8,3,11,0,0]}}
2021-01-26T14:58:30.944Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":3,"manufacturerCode":null,"commandIdentifier":11},"Payload":{"cmdId":0,"statusCode":0}},"address":35665,"endpoint":1,"linkquality":57,"groupID":0}'
2021-01-26T14:58:30.961Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []

The same attempt after the module lost power once:

Zigbee2MQTT:debug 2021-01-26 14:56:03: Received MQTT message on 'rftest/office_e14/set' with data '{"state":"OFF"}'
Zigbee2MQTT:debug 2021-01-26 14:56:04: Publishing 'set' 'state' to 'office_e14'
2021-01-26T14:56:04.052Z zigbee-herdsman:controller:endpoint Command 0x000d6ffffe01a4ef/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null})
2021-01-26T14:56:04.067Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x000d6ffffe01a4ef:35665/1 (0,0,1)
2021-01-26T14:56:04.081Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":35665,"destendpoint":1,"srcendpoint":1,"clusterid":6,"transid":2,"options":0,"radius":30,"len":3,"data":{"type":"Buffer","data":[1,3,0]}}
2021-01-26T14:56:04.087Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,13,36,1,81,139,1,1,6,0,2,0,30,3,1,3,0,233]
2021-01-26T14:56:04.108Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2021-01-26T14:56:04.111Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2021-01-26T14:56:04.114Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2021-01-26T14:56:04.118Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2021-01-26T14:56:04.122Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2021-01-26T14:56:04.760Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,233,1,2,45]
2021-01-26T14:56:04.763Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,233,1,2,45]
2021-01-26T14:56:04.766Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [233,1,2] - 45
2021-01-26T14:56:04.772Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":233,"endpoint":1,"transid":2}
2021-01-26T14:56:04.778Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2021-01-26T14:56:04.784Z zigbee-herdsman:adapter:zStack:adapter Data confirm error (0x000d6ffffe01a4ef:35665,233,0)
2021-01-26T14:56:04.793Z zigbee-herdsman:adapter:zStack:adapter Wait 2000ms

(this is repeated several times until giving up)

1 Like