Universelles Zigbee End Device

Hallo zusammen,
ich habe jetzt ein paar Tage mit CC2530 Device herumgebastelt und möchte gerne meine Erfahrung damit teilen.

Aufgabenstellung
Ich suche eine Lösung mit der man Daten von einem beliebigen Microcontroller per UART an ein Zigbee End-Device schickt. Dieses soll als Zigbee2MQTT Gerät in HA eingebunden werden. Damit kann man dann z.B. Messwertdaten an HA übertragen. In meinem Fall suche ich nach einer Lösung für eine klassische Wetterstation. Aber die hier beschreibene Vorgehensweise ist natürlich auch für ein ganz anderes Projekt nutzbar.

Zigbee Knoten
Eine der günstigsten Lösungen, die ich gefunden habe, ist so ein PCB, das man ab 3€ im Handel bekommt:


Darauf verbaut ist ein CC2530 Chip von Texas Instuments. Von der Prozessor-Architektur ist das ein klassisches 8051 Derivat, das aber auch Low Power Modes unterstützt. Damit kann man den Stromverbrauch auf bis zu 0,4 uA senken. Betrieben wird der MC an 3.3V.

PTVO
Für den Baustein gibt es eine Firmware die sich PTVO nennt. Der Charme dabei ist es, dass über ein Tool zur Konfiguration die Firmware individuell angepasst werden kann. Unter anderem kann man über PTVO eine Uart konfigurieren; und die benötige ich ja für den Datentransfer mit meinem MC.

Ich habe mich für PTVO entschieden, da ich nicht auch noch in die Zigbee Programmierung mit dem 8051 einsteigen, bzw. schneller voran kommen wollte. Wenn man aber bestimmte Features des Tools verwenden möchte muss man eine Lizenz pro Gerät (ca. 8€) kaufen. Ich werde das noch machen, da die Low-Power Modi nur in der Premium Variante konfiguriert werden können. Die braucht man jedoch unbedingt für ein batteriebetriebenes Gerät!

Das Tool ist ein Windows Programm, das aber auch per Wine unter Linux läuft.

Für meinen Test (in der kostenlosen Standard-Version) habe ich folgende Einstellungen gemacht:

Für einen Batteriebetrieb, werde ich aber noch mal Änderungen durchführen und z.B. die LED und das Standard-Berichtsintervall deaktivieren, da das nur unnötig das System wachhält.

Zigbee device programmieren
Das Device wird mit einem CC-Debugger programmiert. Auch das kann man im Handel ab 6€ bestellen.
image
Das Gerät wird dann per USB Kabel am PC angeschlossen. Am 10 polige Pfostenstecker sind folgende Pins an das PCB vom Zigbee Gerät anzuschließen

  • Pin 1 → GND
  • Pin 3 → P2.2
  • Pin 4 → P2.1
  • Pin 7 → Reset
  • Pin 9 → 3.3V
    image

Um eine saubere Verkabelung zu erreichen habe ich mir ein kleines PCB anfertigen lassen um alle Pins des MC herauszuführen. Hier der Schaltplan


Grün markiert der Debug-Port. Bitte beachtet, dass die Zählweise der Pins am Pfostenstecker (Siehe Bild des Pfostensteckers) anders ist, als hier im Schaltbild dargestellt!

Das über das PTVO tool generierte Hex file wird mit Hilfe von “Smart Flash” programmiert. Das Tool wird von TI bereitgestellt. Ich habe die Version 1 des Tools verwendet, da das von PTVO empfohlen wurde.

Der Programmer ist eigentlich ziemlich selbsterklärend

  1. Hex File auswählen
  2. Erase Program and Verify auswählen
  3. Programmiervorgang starten

Pairing mit Zigbee
Wird das Zigbee Device an die Spannungsversorgung angeschlossen, blinkt die LED zunächst erst mal schnell (ca. 1/s). Da bedeutet, dass das Gerät nicht gekoppelt ist. Sobald das Anlernen in der Zigbee2MQTT integration aktiviert wird, erfolgt in der Regel auch das Pairing des neuen Geräts. Danach blinkt die LED, wie konfiguriert, alle 5s.


Ich habe den Gerätenamen dann händisch verändert und auch die Home Assistant Entität aktualisiert.

Datenübertragung
Die Uart Schnittstelle zum MC habe ich simuliert.


Ich habe einfach einen Buspirate 4 (kann natürlich auch ein beliebig anderer USB-RS232 Converter sein) verwendet um vom PC aus Daten an den Uart Port vom Zigbee Device zu schicken. Wie auf dem Bild zu erkennen lege ich die Tx Leitung vom Buspirate auf den RX Pin (P0.2) vom Zigbee Device. Rx vom Buspirate liegt dann an P0.3 (Tx)

Ich habe mir dann ein kleines Python Script gebastelt, dass mir einfach Daten rausschickt:

import serial

PACKET_END = '\r'



ser = serial.Serial('/dev/ttyACM0', 57600)  # open serial port
print(ser.name)         # check which port was really used
data =  'wind_speed:85;wind_force:18;wind_direction:350;temperature:20' \
        + PACKET_END
data_bytes = data.encode('utf-8')
print(data_bytes)
ser.write(data_bytes)     # write a string
ser.close()             # close port

Das Format, in dem die Daten geschickt werden ist sehr simpel es werden einfach durch semikolon getrennte “Key:value” Paare als ein Datenstrom geschickt. Insgesamt kann man in einer seriellen Übertragung 127 Bytes am Stück senden. Braucht man mehr Daten, muss dann in Chunks aufgeteilt werden.

Dekodieren der Daten in der Zigbee Integration
zunächst kann Zigbee die übertragenen Daten nicht Interpretieren. Im Z2M Protokoll (Einstellungen>Add-Ons>Z2M>Protokoll) erfolgt dann folgende Fehlermeldung:

z2m: No converter available for 'weatherstation' with cluster 'genMultistateValue' and type 'attributeReport' and data '{"stateText":{"data":[119,105,110,100,95,115,116,114,101,110,103,116,104,58,50,48,59,119,105,110,100,95,100,105,114,101,99,116,105,111,110,58,49,48,48,59,116,101,109,112,101,114,97,116,117,114,101,58,50,52],"type":"Buffer"}}'

Damit Z2M die Daten interpretieren kann, benötigt die Integration einen Converter. Das ist ein Nodejs File, in dem alle Informationen enthalten sind, die benötigt werden um die empfangenen Daten zu interpretieren.

Hier meine Datei

const zigbeeHerdsmanConverters = require('zigbee-herdsman-converters');
const zigbeeHerdsmanUtils = require('zigbee-herdsman-converters/lib/utils');


const exposes = require('zigbee-herdsman-converters/lib/exposes');
const ea = exposes.access;
const e = exposes.presets;
const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');

fz.ptvo_switch_uart = {
    cluster: 'genMultistateValue',
    type: ['attributeReport', 'readResponse'],
    convert: (model, msg, publish, options, meta) => {
        let data = msg.data['stateText'];
        var ws = null;
        var wf = null;
        var wd = null;
        var temp = null;


        if (typeof data === 'object') {
            let bHex = false;
            let code;
            let index;
            for (index = 0; index < data.length; index += 1) {
                code = data[index];
                if (code < 32 || code > 127) {
                    bHex = true;
                    break;
                }
            }
            if (!bHex) {
                data = data.toString('latin1');
            } else {
                data = [...data];
            }
        }
        /* parse the received data in string format: "key_1:value_1;key_1:value_2..."
        and fill the adequate variables to be returned.*/
        var splitted = data.split(";");
        var keyval;
        for(i=0; i<splitted.length; i++){
            keyval = splitted[i].split(":",2);
            if(keyval[0] == "wind_force")wf = keyval[1];
            else if(keyval[0] == "wind_direction")wd = keyval[1];
            else if(keyval[0] == "temperature")temp = keyval[1];
            else if(keyval[0] == "wind_speed")ws = keyval[1];
        }

        return {action: keyval, 
            wind_force: wf,
            wind_speed: ws,
            wind_direction: wd,
            temperature: temp,
        };
    },
} 

const device = {
    zigbeeModel: ['weatherstation'],
    model: 'weatherstation',
    vendor: 'daest',
    description: 'weatherstation with ptvo based firmware',
    // methods for receivibg data from device. Since 
    fromZigbee: [fz.ignore_basic_report, fz.ptvo_switch_uart,],
    toZigbee: [tz.ptvo_switch_trigger, tz.ptvo_switch_uart,],
    // definition of exposed items like measurement values.
    // more information about presets and how to configure attributes can be found here:
    // https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/lib/exposes.ts#L23
    // Min Max values seems to be ignored when receiving data
    exposes: [
        exposes.numeric('wind_speed', ea.STATE)
            .withUnit('m/s')
            .withValueMin(0)
            .withValueMax(100)
            .withDescription('Measured wind speed'),
        exposes.numeric('wind_force', ea.STATE)
            .withUnit('Bft')
            .withValueMin(0)
            .withValueMax(17)
            .withDescription('Measured wind force'),
        exposes.numeric('wind_direction', ea.STATE)
            .withUnit('°')
            .withValueMin(0)
            .withValueMax(360)
            .withDescription('Measured wind direction'),
        e.temperature()
    ],
};

module.exports = device;

Die Datei wird einfach im Z2M Verzeichnis neben der speziefischen configuration.yaml abgelegt. In der configuration.yaml muss der Converter noch bekannt gemacht werden. Das geschieht über folgenden Eintrag, den ich einfach unterhalb der Sektion “advanced” platziert habe:

external_converters:
  - weatherstation.js

Im weiteren gehe ich wieder auf das Converter-File ein. Das device Beschreibt unter anderem die Struktur der anzuzeigenden Daten, die in dem Array exposes definiert sind. Ich möchte nur Daten empfangen und als Sensoren anzeigen (vom Typ ea.State). Es gibt bereits einen Satz vorgefertigter Sensoren, wie zum Beispiel der Temperatursensor. Für diesen kann man direct den expose vom Typ e.temperature verwenden.

Für “eigene” Sensoren muss man selber den Sensor definieren.

PTVO sendet normalerweise die Daten als einen Block, der in der Instanz action abgelegt wird. PTVO ünterstützt übrigens auch das Generieren eines Converters. Dort kann man nachschauen wie der Expose action angelegt wird.

Verwendet man die von Z2M bereits integrierte Methode fz.ptvo_switch_uart so kommen die Daten nie an den von mir definierten exposes an.

Daher habe ich ein “Function overriding” gemacht. Ab der Zeile mit dem Kommentar /* parse the received data in string format: “key_1:value_1;key_1:value_2…” */ habe ich einen simplen Parser geschrieben, der letztendlich dann die empfangenen Daten an die exposes Überträgt,

Die Ansicht von meinem MQTT Gerät sieht dann so aus:

Ich hoffe, dass dieser Artikel Euch weiterhilft, falls Ihr auch mal Daten von einem Endgerät übertragen wollt. Den umgekehrten Weg habe ich bislang noch nicht ausprobiert.

6 „Gefällt mir“

Hi,
ähnliche Platinen hatte ich mir auch mal bei Aliexpress gekauft ohne überhaupt zu wissen wie ich die programmieren oder nutzen könnte. Muss mir deinen Beitrag daher mal genauer durchlesen! :slight_smile:

Ja gerne, bei Fragen, einfach melden.

Hi @daest
Vielen, vielen Dank für diese Anleitung. :grinning:
Ich habe nur noch ein Problem und eine Frage dazu:
Ich bekomme bei jedem Datenempfang von zigbee2mqtt folgende Fehlermeldung.

Error `z2m: Exception while calling fromZigbee converter: data.split is not a function}`

Es scheint aber alles zu funktionieren. Ich sende genau den string aus dem Beispiel, im Moment noch statisch, von einem Arduino und alle Werte passen. Was stimmt da nicht?

Im string sind alle Zahlen ganz. Wie könnte ich es anstellen, kommagetrennte float Werte an Z2M zu schicken?

Grüsse Michael

Hi RedFlash,
das scheint mir eine Fehlermeldung beim Zerlegen des übertragenen Messwertestrings zu sein an dieser Stelle:

var splitted = data.split(";");

Kannst Du mal im Log (Einstellungen>Addons>Zigbee2MQTT>Protokoll) schauen, welche Daten Dein Gerät überträgt. Vermutlich wird ein Zeichen übertragen, was einen TypeError erzeugt.

Wie hier auch erklärt wird:
TypeError: split is not a function in JavaScript

Vielleicht noch als ergänzung hier meine Umsetzung in C aus meinem STM32 projekt:

#define ZBEE_PACKET_END '\r'
memset(buffer, 0, 255);
		/* transmit data
			ws: wind speed [m/s]
			wf: wind force [Bft]
			wd: wind direction [°]
			te: temperature [°C]
			pr: pressure [hPa]
			hu: humidity*/
		n = sprintf(buffer, "ws:%d;wf:%d;wd:%d;te:%.2f;pr:%.2f;hu:%.2f%c", a, b, c,
				temperature, pressure, humidity, ZBEE_PACKET_END);

		// send it to Zigbee transmitter
 		ZBEE_transmit(buffer, n);

Ich lösche den zu übertragenden Puffer vorher mit memset. Dann ist auf jeden Fall der String korrekt abgeschlossen. Das funktioniert auch mit float Werten

Danke nochmal.
Die Fehlermeldung ist weg. Es war der CC2530, der nicht schnell genug erwacht ist. Ich wecke den aus dem PSM per external_wakeup mit einem Arduino pin und schicke ihm den string. Mit 100ms zwischen wecken und schicken klappt es.

Das mit den realen float werten kommt als nächstes dran. Danke für die Tipps.

Grüsse Michael

Moin

Das problem war nicht das timing sondern der ESP32c6 bootloader, der bei jedem start (auch aus dem sleepmode) eine Startmeldung per Uart verschickt. Das hat der CC2530 nicht verstanden. Eine Wartezeit und ein serial.flush nach dem Start hat das Problem umgangen.
Die Daten kann ich alle wie gewünscht übertragen, soweit so gut.

Nun kämpfe ich noch damit, im PSM Modus die Reports zuverlässig regelmässig zu schicken. Ich habe ein timing gefunden, dass fast jedesmal funktioniert. Aber eben nur fast. Manchmal kommt gar nichts und manchmal nur die Werte von der letzten Übertragung.

Hast du die Lizenz schon besorgt und mit dem PSM gespielt @daest ?

Grüsse Michael

Hi RedFlash,
der CC2530 schickt ja quasi alles raus was er empfängt. Wenn der ESP32 Daten schickt, wie z.B. Steuerzeichen, kann der Converter dann die Stringoperationen nicht durchführen und es kommt zu dem von Dir beschriebenen Fehler. Das Thema hast Du ja in den Griff bekommen.

Ich habe mittlerweile eine Lizenz besorgt, hatte aber bislang noch keine Zeit mich damit näher mit dem power saving mode zu beschäftigen. Ich habe nur gesehen, dass es verschiedene Sleep modes gibt. Verwendest Du den mit Timer? Ich würde eher den Ansatz über einen External wakeup pin gehen.

Moin
Das war auch meine Idee.
Bei der firmware ist nur Uart und wakeup pin definiert und unter expert alles disabled und den report interval auf 0.

Ich habe jetzt einen Xiao Samd21 dran, der jede Minute aus dem deepsleep aufwacht, die Sensordaten sammelt und den string erstellt, dann den Ptvo per pin weckt und den string verschickt.

Das funktioniert gut…die ersten zwei Mal. Danach kommen nur noch unregelmässige reports, auch mal 2 Stunden gar nichts.

Mit aktiviertem report interval 60s geht es besser, wie schon erwähnt fast jede Minute ein report. Das schickt so aber unnötig viele reports raus.

Ich probiere weiter und hoffe auf Erkenntnisse von dir. Die ptvo dokumentation ist ja nicht so toll. Gerade was Uart mit PSM betrifft, habe ich gar nichts gefunden.

Grüsse Michael

Laut der Beschreibung für den PSM wacht das System für 3 Sekunden auf und geht dann wieder schlafen, nachdem der Wakeup Pin bedient wurde. Wie lange wartest Du denn nach dem Wakeup bis Du Daten sendest? Eventuell ist das ein Timing problem.

Das habe ich auch vermutet. Darum habe ich einiges zwischen 100ms und 2s ausprobiert. Hat aber leider nichts geändert.
Im Moment glaube ich es ist was anderes. Heute ist mir aufgefallen dass die Status LED vom CC2530 immer nach 2 Minuten blinkt, aber nichts bei Zigbee2mqtt ankommt und ab der 3. Minute blinkt es einmal und dann dreimal kurz nacheinander, bis es nach x Minuten zwischendurch mal wieder 2-3 Minuten funktioniert.
Sieht nach Fehlermeldung aus.

Hallo daest,
super Ausführung und super Idee.
Das Gleiche/Ähnliche hatte ich auch und habe alles soweit:

Idee ist: Reichweite mit Zigbee Mesh nutzen weil mit Wlan reicht es nicht.
Aufbau: ESP32 misst 5 Tempstellen mit Dallas DS18B20,
übergibt per uart an CC2530 - der dann in das vorhandene Zigbee Mesh
die Daten bringt … dachte ich :frowning:

Habe alle soweit fertig (TTL gekauft, ESP32 anstelle von ESP8266 probiert)
Pinning 100x überprüft…
und hänge schon 2 Wochen… muss allerdings sagen dass ich nicht der geborene Hacker bin … bin Maschinenbauing.

Auf CC250 (korrekt cc2530+cc2591) habe ich mit Debugger
router-cc2530-cc2591-std.hex gefashed,
ESP32 mit ESP-Home und uart alles soweit gebracht dass er über TX und RX an CC2530 die Messinfo übergibt - mit TTL und Putty geprüft -Messdaten werden gesendet.
Im Mqtt kann ich Gerät wunderbar sehen:
image

ich aber nur den Status wird über tragen - keine Messdaten:
{
“led”: true,
“linkquality”: 225
}
bin am verzweifeln… was ich noch ausprobieren könnte - hast Du eine Tipp?
danke
Hans

Hallo Hans,
bitte schau mal in das Protokoll vom MQTT Plugging. Dazu öffnest Du unter Einstellungen>Add-ons>Zigbee2MQTT das Protokoll.

[2025-03-01 16:52:49] debug: 	z2m: No converter available for 'wetterstation' with cluster 'genMultistateValue' and type 'attributeReport' and data '{"stateText":{"data":[119,115,58,50,49,54,59,119,102,58,49,56,55,59,119,100,58,49,49,48,59,116,101,58,48,46,48,48,59,112,114,58,48,46,48,48,59,104,117,58,48,46,48,48],"type":"Buffer"}}'

Ich vermute, dass Du keinen passenden Converter konfiguriert hast. Dann kann er die Messdaten nicht anzeigen. In dem Beispiel habe ich mal meinen Converter entfernt. Dann müsstest Du eine Fehlermeldung wie oben sehen.

Den Status sendet das Device unabhängig von der Datenpayload die Du verschicken willst.

Die Alternative ist, dass Du nichts an das Zigbee Device schickst. Das könnte verschiedene Ursachen haben. RX/TX vertausch, falsche Datenrate etc.

Hallo Daest,
danke schon mal für die Antwort :slight_smile:
Hab die logs angeschaut - keine Einträge von E4… oder ähnlichen Einträgen


… auch nicht weit in Vergangenheit :frowning:
Habe RX und TX schon einige male getauscht.
Möglicherweise übernimmt der CC2530 vom ESP32 (mein E4) nichts.
Eingebunden ist er - siehe Mqtt Geräte


:frowning: :frowning:

online ist er auch
image
… ab ihn auch gerade mit Zigbeex umbenannt … macht er alles :slight_smile:

habe gerade gesehen … da ist doch was gekommen durch das interviewen…

die Entität binary_sensor.e3_als_zigbee_led sendet er
image

:crayon:by HarryP: Zusammenführung Mehrfachpost (bitte “bearbeiten” Funktion nutzen)

Hast Du beim Umbenennen das Häkchen bei “Home-Assistant-Entität aktualisieren” gesetzt? Dann müsstest Du unter Einstellungen>Geräte&Dienste ein entsprechend benanntes MQTT Gerät sehen. Siehst Du dort Sensoren? Ist der Sensor von dem Du einen Screenshot gesendet hast derjenige den Du erwartest?

Hinweis: Ab Zigbee2MQTT Version 2.0.0 sind converter in einem anderen Pfad zu speichern

image

Dazu wird einfach das Verzeichnis im Zigbee2mqtt Verzeichnis angeleg und das node js file dort abgelegt. Der Eintrag des external_converters im zigbee configuration.yaml kann dann entfallen.

:crayon:by HarryP: Zusammenführung Mehrfachpost (bitte “bearbeiten” Funktion nutzen)

Hi Red Flash. Es hat jetzt leider etwas länger gedauert, bis ich auf Deinen Post antworte. Ich habe mir eine Lizenz besorgt um den Power Saving Mode freizuschalten.

Damit ist es dann möglich einen Externen Wakeup Pin zu konfigurieren. Ich habe mich für P10 entschieden, da ich keinen Einfluss auf P0x haben will. In der Dokumentation steht im Kapitel “Limitations”, dass man nur einen Switch-Pin pro Range verwenden kann und es zu Problemen kommen kann (detecting signal edges) bei der Erkennung von Signalen von Pins in der selben Range. Das wäre für eine Uart natürlich schlecht. Wie gesagt ist das in der Doku nicht eindeutig beschrieben.

Ich habe die externe Pull-Up Variante gewählt um einen sauberen Pegel am Pin zu haben. Dazu steht wiederum in der Doku, dass interne Pullups immer pro Pin Range gesetzt werden. Das betrifft dann also 4 Pins. Ich verwende einen 10k nach VCC (3.3V). Der Wakeup Pin sollte dann Low-active sein.

Ich habe dann in meinem Source-Code das Wakeup Signal hinzugefügt und dann das Verhalten mit einem Logicanalyzer aufgezeichnet.

In dem Plot sieht man, dass ich den Wakeup Pin vor dem Senden für 500ms togglen lasse. Dadurch soll dem CC2530 genügend Zeit zum Aufwachen gegeben werden.

Wenn der Wakeup wieder inaktiv ist, sende ich dann nach etwa 2ms meine Daten per UART an den Chip. Insgesamt soll der CC2530 ja nach 3 Sekunden wieder in den Sleep gehen, nachdem er aufgewacht ist. Momentan habe ich noch eine Anfrage laufen, wie das Timing vom Wakeup Signal aussehen muss ( Breite des Pulses, Abstand fallende Flanke bis zur Sendebereitschaft) um die Daten sicher zu übertragen.

Damit funktioniert das Sytem wie erwartet. In HA kommen die Daten rein. Wenn ich die Wakeup Leitung auf meinem Board entferne, geht das Teil in den Sleep und keine Daten werden mehr übertragen.

Ich will dann vielleicht noch mal die Stromaufnahme im Sleep und beim senden mit meinem tinyCurrent messen. Dann sieht man wirklich mal das Verhalten beim Senden und beim Sleep.

Nachtrag:
ich habe noch mal im Datenblatt nachgelesen. Ein wakeup (von Sleep to Active) dauert ca. 0.1 ms

Beim Reset pin dauert die Erkennung der fallenden flanke mindestens 167 ns. Daraufhin habe ich jetzt mal meine Zeiten angepasst.

Demnach reicht ein Low Puls von ca 8us aus um den Chip zu wecken. Somit muss kein besonderes Timing eingehalten werden ich setze einfach den Pin auf Low und dann direkt danach wieder auf high. Das dauert dann bei meinem Microcontroller eben 8 us. Anschließend bereite ich die Daten auf um sie über die UART zu verschicken. Das reicht vom Timing her (1.7 ms) um sicher zu sein, dass der Chip wach ist.

Die sprintf funktion verbraucht ausreichen Zeit bei dem Zusammenkopieren des Sendepuffers, damit das Timing passt.

Moin.
Cool, dass du das so ausführlich getestet hast. Ich hatte alles in eine Ecke geschoben und nichts mehr dran gemacht.

Hast du eine Status LED am Cc2530 dran? Die sollte ja bei jedem senden aufleuchten. Bei mir hat die unregelmässig und mehrmals nacheinander geleuchtet.

Siehst du auf der Zigbee Seite die Nachrichten? Ich hatte da mehrfache Meldungen direkt nacheinander.

Hast du das Ganze einige Zeit laufen lassen? Bei mir hatte es nach 3-4 Nachrichten gar nichts mehr gesendet.

Ich baue das demnächst wieder auf und starte einen neuen Versuch. Eigentlich wollte ich zwischenzeitlich einen ESp32C6 nehmen, da hatte ich andere Probleme, aber das ist auch ein anderes Thema.

Danke erstmal

Hi RedFlash,
ich habe eine LED konfiguriert. Sie soll blinken, wenn das pairing aktiv ist oder Fehler auftreten (Konfiguration siehe Screenshot oben). Im laufenden Betrieb habe ich die LED noch nie blinken sehen.

Zum Testen habe ich verschiedene Zykluszeiten ausprobiert. Bei einer Sekunde geht der CC2530 quasi nie schlafen. Bei 10 Sekunden sehe ich an meinem Netzteil, dass die Stromaufnahme zwischen 2 und 20 mA hin und herspringt. Von daher gehe ich davon aus, das der Chip in den Sleep geht.

Ich kann keinen Datenverlust feststellen, die Daten laufen zyklisch rein. und ich habe den Datentransfer heute Vormittag mal länger als 'ne Stunde laufen lassen.

Also prinzipiell würde ich sagen funktioniert der PSM

Ergänzung:
Ich möchte noch ergänzend hinzufügen, dass ich mittlerweile die Daten die ich per Zigbee an mein HA schicke in unterschiedlichen Frames übertrage. Dadurch kann ich nur die Daten schicken, die gerade in meinem Gerät (Wetterstation) anfallen. Beispielsweise fallen dort Temperaturmesswerte an, die ich jede Minute übertragen möchte. Der Blitzsensor liefert nur Daten, wenn ein Blitz erkannt wurde und der Windsensor liefert Daten nur wenn Wind weht und dann alle 30 Sekunden.
Ich habe einen einfachen Scheduler geschrieben, der die Zigbee Senderoutine alle 500ms aufruft. Sind Daten vorhanden, wird der Inhalt des Frames zusammengebaut

n = sprintf( buffer, "SET_3#en:%lu;di:%u;%c", as3935.energy, as3935.distance, ZBEE_PACKET_END );

// send it to Zigbee transmitter
ZBEE_transmit( buffer, n );

Die einzelnen Frames unterscheide ich dann durch das Token Set_X, das ich dann in meinem Converter entsprechend auswerte.

Danach wird die Funktion wieder verlassen, selbst wenn weitere Daten von anderen Sensoren vorhanden sind. Somit umgehe ich dann das Problem, dass zu schnell Daten hintereinander geschrieben werden, da dann der CC2530 Daten verschluckt. Das könnte beispielsweise zur vollen Minute passieren, wenn Temperatur, Wind und auch Blitzdaten zum Senden bereit stünden.

Hier noch der Code meines Converters
weatherstation_js.txt (5,0 KB)

Im MQTT Device kann man dann sehr schön sehen, wie die Daten mit unterschiedlichen Zykluszeiten reinkommen.