Aufteilen einer größeren Anzahl von Nutzdaten in mehrere Kanäle

[FUEL4EP]

Für einen neuen Sensor, der viele statistische Daten bereitstellen kann, suche ich ein Möglichkeit, die aktuelle Beschränkung der Nutzdaten auf maximal 17 Bytes zu überwinden:

Frage: Ist es möglich, die Nutzdaten eines Sensors in mehrere Kanäle aufzuteilen?

Die Idee dabei ist wie folgt:

1. Direkte Sensormessdaten werden wie üblich alle 3..4 Minuten im 'Basiskanal' übertragen. Die Beschränkung der maximalen Anzahl der Nutzdaten erlaubt z.B. die Übertragung von 8 Int16 Messwerten für jedes Messintervall.

2. Zusätzliche statistische Parameter wie z.B. minimaler Messwert, maximaler Messwert, minimaler gleitender Mittelwert, maximaler gleitender Mittelwert werden nur in größeren zeitlichen Abständen in 'erweiterten Kanälen' übertragen, z.B. jede Stunde oder auch nur 1x pro Tag

Hat das schon jemand von Euch gemacht? Wenn ja, bei welchem Sensor (zum Abkupfern )?

Geht das grundsätzlich? Wenn ja, wie geht es / könnte es gehen?

Bin gespannt auf Eure Antworten. Vielen Dank im Voraus!

[jp112sdl]

Wenn du es ohnehin auf mehrere Kanäle verteilst, ist es doch kein Problem?

[FUEL4EP]

Im Prinzip, ja. Die Herausforderung ist, wie immer, die spezifische Implementierung ohne zu viel Versuch und Irrtum:

Wie kann ich die Daten des statistischen Kanals seltener senden, z.B. nur jedes 15. Messintervall? Gibt es dazu bereits eine Referenz zum Studieren?

Gibt es bereits ein Beispiel rftypes XML, wo ich das Aufteilen eines Messdatensatzes in zwei Kanäle studieren kann?

[jp112sdl]

Wie kann ich die Daten des statistischen Kanals seltener senden, z.B. nur jedes 15. Messintervall?

Indem du in Kanal 1 einen Alarm hast, der z.B. alle 60 Sekunden triggert (und sendet) und in Kanal 2 einen Alarm, der alle 180 Sekunden triggert.

Gibt es bereits ein Beispiel rftypes XML, wo ich das Aufteilen eines Messdatensatzes in zwei Kanäle studieren kann?

Ich weiß immer noch nicht, ob ich dein Anliegen richtig verstanden habe.

Beim https://github.com/jp112sdl/HB-UNI-Sen- ... S18B20.ino arbeite ich mit den CHANNEL_FIELD, um 8 Temperaturwerte in 8 Kanälen zu übertragen, obwohl das Device intern nur 1 Kanal besitzt.
Die XML dazu https://github.com/jp112sdl/JP-HB-Devic ... n-temp.xml

[FUEL4EP]

Danke, Jérôme!

Ich werde es mal mit

Indem du in Kanal 1 einen Alarm hast, der z.B. alle 60 Sekunden triggert (und sendet) und in Kanal 2 einen Alarm, der alle 180 Sekunden triggert.

versuchen. Gibt es ein Beispiel für zwei (oder mehr) Alarme mit unterschiedlich Wiederholraten in einem Sketch?

HB-UNI-Sen-TEMP-DS18B20 bleibt insgesamt noch innerhalb der 17Bytes Payload-Grenze.

Zur Verdeutlichung meiner Anfrage: Bei meinem neuen Sensor sind im Kanal 0 folgende Datenpunkte geplant:

1. Temperatur 16Bit Int
2. relative Luftfeuchte 16Bit Int
3. Luftdruck 16Bit Int
4. absolute Luftfeuchte 16Bit Int
5. Gleitender Mittelwert der Temperatur über 24 Stunden 16Bit Int
6. Gleitender Mittelwert der Temperatur über 7 Tage 16Bit Int
7. Gleitender Mittelwert der Temperatur über 30 Tage 16Bit Int
8. Gleitender Mittelwert der Temperatur über 365 Tage 16Bit Int

Im Kanal 2 könnte es dann z.B. geben:

1. Minimum Gleitender Mittelwert der Temperatur über 24 Stunden 16Bit Int
2. Maximum Gleitender Mittelwert der Temperatur über 24 Stunden 16Bit Int
3. Minimum Gleitender Mittelwert der Temperatur über 7 Tage 16Bit Int
4. Maximum Gleitender Mittelwert der Temperatur über 7 Tage 16Bit Int
5. Minimum Gleitender Mittelwert der Temperatur über 30 Tage 16Bit Int
6. Maximum Gleitender Mittelwert der Temperatur über 30 Tage 16Bit Int
7. Minimum Gleitender Mittelwert der Temperatur über 365 Tage 16Bit Int
8. Maximum Gleitender Mittelwert der Temperatur über 365 Tage 16Bit Int

Ein Kanal 3 ist mit weiteren abgeleiteten statistischen Größen denkbar.

Für die Datenspeicherung der Messwerte plane ich ein 4Mbit SPI FRAM einzusetzen, siehe auch hier. So ist auch die gleitende Mittelwertbildung über ein Jahr möglich.

Grundsätzlich ließe sich die Methode aber für Messwerte jeglicher Art einsetzen, bei denen Statistiken über längere Zeiträume von Interesse sind.
Z.B. ist bei meinem Radioaktivitätssensor HB-UNI-Sensor1-RAD-AL53 schon ein gleitender Mittelwert über eine Woche realisiert.

[jp112sdl]

HB-UNI-Sen-TEMP-DS18B20 bleibt insgesamt noch innerhalb der 17Bytes Payload-Grenze.

Nein. Ich brauche 3 Byte je Temperatur, wegen des Channel-Field.
Macht bei 8 Kanälen = 24 Byte.

Gibt es ein Beispiel für zwei (oder mehr) Alarme mit unterschiedlich Wiederholraten in einem Sketch?

Nicht getestet, nur fix zusammengeschrieben:

Code: Alles auswählen

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <LowPower.h>
#include <AskSinPP.h>

#include <Register.h>
#include <MultiChannelDevice.h>

#define CONFIG_BUTTON_PIN   8
#define LED_PIN             4
#define CC1101_CS          10
#define CC1101_GDO0         2

#define PEERS_PER_CHANNEL 8
#define INTERVAL_1          60
#define INTERVAL_2         180

using namespace as;

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0xff,0xff,0xff},       // Device ID
    "ABC1234567",           // Device Serial
    {0xff,0xff},            // Device Model
    0xff,                   // Firmware Version
    as::DeviceType::Switch, // Device Type
    {0x01,0x00}             // Info Bytes
};


typedef AvrSPI<CC1101_CS,11,12,13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>,NoBattery,Radio<RadioSPI,CC1101_GDO0> > Hal;
Hal hal;

class Channel1 : public Channel<Hal, List1, EmptyList, List4, PEERS_PER_CHANNEL, List0>, public Alarm {
  public:
    Channel1 () : Channel(), Alarm(0) {}
    virtual ~Channel1 () {}

    virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
      seconds2ticks(INTERVAL_1);
      //...
    }

    void setup(Device<Hal, List0>* dev, uint8_t number, uint16_t addr) {
      Channel::setup(dev, number, addr);
      sysclock.add(*this);
    }

    void init() {
      //...
    }

    uint8_t status () const {return 0;}
    uint8_t flags () const {return 0;}
};

class Channel2 : public Channel<Hal, List1, EmptyList, List4, PEERS_PER_CHANNEL, List0>, public Alarm {
  public:
    Channel2 () : Channel(), Alarm(0) {}
    virtual ~Channel2 () {}

    virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
      seconds2ticks(INTERVAL_2);
      //...
    }

    void setup(Device<Hal, List0>* dev, uint8_t number, uint16_t addr) {
      Channel::setup(dev, number, addr);
      sysclock.add(*this);
    }

    void init() {
      //...
    }

    uint8_t status () const {return 0;}
    uint8_t flags () const {return 0;}
};

class UType : public ChannelDevice<Hal, VirtBaseChannel<Hal, List0>, 2, List0> {
  public:
    VirtChannel<Hal, Channel1, List0> channel1;
    VirtChannel<Hal, Channel2, List0> channel2;
  public:
    typedef ChannelDevice<Hal, VirtBaseChannel<Hal, List0>, 2, List0> DeviceType;

    UType (const DeviceInfo& info, uint16_t addr) : DeviceType(info, addr) {
      DeviceType::registerChannel(channel1, 1);
      DeviceType::registerChannel(channel2, 2);
    }
    virtual ~UType () {}

    Channel1& c1() { return channel1; }
    Channel2& c2() { return channel2; }

    virtual void configChanged () {
      DeviceType::configChanged();
    }
};

UType sdev(devinfo, 0x20);

ConfigButton<UType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);

  sdev.c1().init();
  sdev.c2().init();

  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<Idle<> >(hal);
   }
}

Im Kanal 2 könnte es dann z.B. geben:

1. Minimum Gleitender Mittelwert der Temperatur über 24 Stunden
2. Maximum Gleitender Mittelwert der Temperatur über 24 Stunden
3. Minimum Gleitender Mittelwert der Temperatur über 7 Tage
4. Maximum Gleitender Mittelwert der Temperatur über 7 Tage
5. Minimum Gleitender Mittelwert der Temperatur über 30 Tage
6. Maximum Gleitender Mittelwert der Temperatur über 30 Tage
7. Minimum Gleitender Mittelwert der Temperatur über 365 Tage
8. Maximum Gleitender Mittelwert der Temperatur über 365 Tage

Ich würde sowas wohl über ein internes CCU-Programm erledigen lassen.

[FUEL4EP]

Danke!

Dein Sketch-Gerüst für zwei Alarme mit unterschiedlichen Wiederholraten in einem Sketch ist perfekt. Das hat mir viele Versuche erspart. Vielen Dank!

Ich würde sowas wohl über ein internes CCU-Programm erledigen lassen.

Das habe ich anfangs auch erwogen. Zwei Gründe sprechen aus meiner Sicht dagegen:

1. Die aufwändige Statistik könnte die CCU (kurzfristig) blockieren. Daher der Gedanke, alles was sinnvoll in den Sensorknoten auszulagern ist, auch dort zu berechnen.
2. Der Speicherbedarf von 4Mbit pro Sensorknoten fiele dann in der CCU an. Bei einem Raspberry Pi 3B+ geht das schon nicht mehr.