CC2538 und CC2530+CC2592 ZigBee Raspberry Pi Modul

Deutsche Foren Hardware
#47

Ich hatte die Jethome Firmware geflasht - leider besteht das Problem (bei mir) weiterhin. Ich warte jetzt auf ein Ersatzmodul (nur um sicher zu gehen, dass nicht doch bspw. das NVRAM eine Macke hat).

Kleiner Tipp am Rande (falls nicht allseits bekannt): Sollte das Problem nicht kurzfristig zu lösen sein, kann man per “group” und “bind” zumindest Lampen/Fernbedienungen koppeln, ohne dass das Zigbee Gateway funktionieren muss.

In Zigbee2mqtt eine neue Group anlegen und alle gewünschten Lampen hinzufügen. Dann unter den Eigenschaften einer Fernbedienung ein “bind” auf die neue Gruppe durchführen. Die “default_bind_group” muss man dafür löschen, damit das auch funktioniert.

Jetzt sollte die Fernbedienung alle Geräte dieser Gruppe bedienen können, selbst ohne eingeschaltetes Gateway.

Ich habe in den letzten Wochen bestimmt 10x alle meine 21 Zigbee Geräte neu angelernt - mittlerweile bin ich zwar recht gut darin, den 6x an/aus Rhythmus der Ikea Lampen zu treffen, aber so langsam lässt der Spaß nach :wink:

Gruß,
Florian

1 Like
#48

Danke euch allen für die super Diskussion.
Hat einer von euch schon mal bei ModKam oder JetHome in den Issues kommentiert?
Ich mein, das Problem muss denen ja bekannt sein…

#49

Ja, hier:

Aber noch nix weiter gehört…

1 Like
#50

Ok, das ist das Issue was ich auch kenne.

Es gibt halt sehr viele Varianten des CC2538 die alle die ModKam oder JetHome-Firmware nutzen, das Problem muss also schon mal jemand gehabt haben.

Ich gehe nicht davon aus, dass das nur mit der UART-Variante so ist.

#51

@Adrian maybe you can give some insight here. Still havin the problem that the CC2538 “forgets” all non active devices after reboot.

#52

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
#53

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: https://www.tindie.com/products/GiovanniCas/zigbee-hat-with-cc2538-for-raspberry/

#54

Only modkam one was signaled to me.

#55

Jethome is here:

It’s also linked by Koenkk:

#56

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.

"coordinator":{"meta":{"maintrel":2,"majorrel":2,"minorrel":7,"product":2,"revision":20200327,"transportrev":2},"type":"zStack30x"}

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
2 Likes
#57

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
#58

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…
Giovanni

1 Like
#59

Hey @GiovanniC, thanks for joining the conversation.

Cheers,
Patrik

#60
#61

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
#62

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

#63

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

#64

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
#65

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

#66

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

1 Like