AskSin++ Library

[papa]

Danke dir.

Den HM-WDS10-TH-O wollte ich nicht 1zu1 nachbauen, sondern habe den als Vorlage für meinen Sensor genutzt.
Worauf ich hinaus möchte sind Sensoren für den Innenraum die Temp, Feuchte und Helligkeit messen und an die Zentrale senden.
Gleichzeitig soll dieser direkt mit HM-CC-RT-DN gepaired werden, damit dieser auf die Isttemperatur am UniSen regelt und nicht auf seine eigene.
Genau wegen diesem Direktpairing möchte ich möglichst nah bei der Vorlage von papa bleiben, weil er sich sicher was dabei gedacht hat

Also wenn Du direkt mit den HM-CC-RT-DN peeren willst, kommst Du am 32.768kHz Quarz und der RTC nicht vorbei. Die Geräte bereichen nach der aktuellen Messagenummer und der ID den nächsten Sendeslot. Dann wacht der Regler kurz auf und wartet auf die Nachricht mit der Temperatur. Da der Deep-Sleep beim AVR sehr ungenau ist, passt der Zeitpunkt nicht und die Kommunikation läuft ins leere.
Die RTC-Klasse nutzt den Timer2 mit den externen Quarz. Das ganze ist unabhängig vom Sleep-Mode.

Wie sieht denn der Mini aus ? Ist da ein grosser Qurz drauf ? Dann könnte man wahrscheinlich gegen ein 32.768kHz tauschen.

Mit sysclock sollte es so aussehen (nicht getestet)

Code Auswählen Erweitern


//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER

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

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

#include "Dht.h"
#include "LM393LLS.h"

// Arduino Pro mini 8 Mhz
// Arduino pin for the config button
#define CONFIG_BUTTON_PIN 8

// #define TIME_MEASURE_AND_SEND_IN_S 15

// number of available peers per channel
#define PEERS_PER_CHANNEL 6

// all library classes are placed in the namespace 'as'
using namespace as;

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x11,0x12,0x13},          // Device ID
    "USLR111111",              // Device Serial
    {0xF1,0x01},              // Device Model
    0x10,                      // Firmware Version
    as::DeviceType::THSensor, // Device Type
    {0x01,0x01}                // Info Bytes
};

/**
* Configure the used hardware
*/
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<4> LedType;
typedef BatterySensorUni<A1,6> BatterySensorType;
typedef AskSin<LedType,BatterySensorType,RadioType> BaseHal;
class Hal : public BaseHal {
public:
  void init (const HMID& id) {
    BaseHal::init(id);
    // measure battery every 1h
    battery.init(seconds2ticks(60UL*60),sysclock);
    battery.low(20); // Low voltage set to 2.0V
    battery.critical(18); // Critical voltage set to 1.8V
  }

  bool runready () {
    return BaseHal::runready();
  }
} hal;

class WeatherEventMsg : public Message {
public:
  void init(uint8_t msgcnt, int16_t temp, uint8_t humidity, int16_t brightness, bool batlow) {
    uint8_t t1 = (temp >> 8) & 0x7f;
    uint8_t t2 = temp & 0xff;
    if( batlow == true ) {
      t1 |= 0x80; // set bat low bit
    }
    Message::init(0xd,msgcnt,0x70,BIDI,t1,t2); // first byte determines message length; pload[0] starts at byte 13
    pload[0] = humidity;
    pload[1] = brightness;
  }
};

DEFREGISTER(WeatherRegsList0,DREG_BURSTRX)
typedef RegList0<WeatherRegsList0> WeatherList0;


class WeatherChannel : public Channel<Hal,List1,EmptyList,List4,PEERS_PER_CHANNEL,WeatherList0>, public Alarm {

  WeatherEventMsg msg;

  Dht<7,DHT22>      dht22;
  Lm393lls<A0>      lm393lls;
  uint16_t          millis;

public:
  WeatherChannel () : Channel(), Alarm(5), millis(0) {}
  virtual ~WeatherChannel () {}

  virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
    // wait also for the millis
    if( millis != 0 ) {
      tick = millis2ticks(millis);
      millis = 0; // reset millis
      sysclock.add(*this); // millis with sysclock
    }
    else {
      uint8_t msgcnt = device().nextcount();
      measure();
      msg.init(msgcnt,dht22.temperature(),dht22.humidity(),lm393lls.brightness(),device().battery().low());
      device().sendPeerEvent(msg,*this);
     
      // reactivate for next measure
      HMID id;
      device().getDeviceID(id);
      uint32_t nextsend = delay(id,msgcnt); // TIME_MEASURE_AND_SEND_IN_S*240000;
      tick = millis2ticks(nextsend);
      sysclock.add(*this);
    }
  }

  // here we do the measurement
  void measure () {
    dht22.measure();
    lm393lls.measure();
    DPRINT("T: ");DDEC(dht22.temperature());DPRINT(" H: ");DDEC(dht22.humidity());DPRINT(" B: ");DDECLN(lm393lls.brightness());
  }

  // here we calc when to send next value
  uint32_t delay (const HMID& id,uint8_t msgcnt) {
    uint32_t value = ((uint32_t)id) << 8 | msgcnt;
    value = (value * 1103515245 + 12345) >> 16;
    value = (value & 0xFF) + 480;
    value *= 250;

    DDEC(value / 1000);DPRINT(".");DDECLN(value % 1000);

    return value;
}

  void setup(Device<Hal,WeatherList0>* dev,uint8_t number,uint16_t addr) {
    Channel::setup(dev,number,addr);
    tick = seconds2ticks(5);
    sysclock.add(*this);
    dht22.init();
    lm393lls.init();
  }

  uint8_t status () const {
    return 0;
  }

  uint8_t flags () const {
    return 0;
  }

};

typedef MultiChannelDevice<Hal,WeatherChannel,1,WeatherList0> WeatherType;
WeatherType sdev(devinfo,0x20);

ConfigButton<WeatherType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  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<Sleep>(hal);
  }
}


[Klaus0815]

Code Auswählen Erweitern

Die Geräte bereichen nach der aktuellen Messagenummer und der ID den nächsten Sendeslot. Dann wacht der Regler kurz auf und wartet auf die Nachricht mit der Temperatur.
Hallo Papa, interessant, wie auch viele andere Details hier - wo erfährt man den sowas? Gibts da eine Newsgroup oder was in der Richtung?

Viele Grüße
Klaus

[Linef]

Also wenn Du direkt mit den HM-CC-RT-DN peeren willst, kommst Du am 32.768kHz Quarz und der RTC nicht vorbei. Die Geräte bereichen nach der aktuellen Messagenummer und der ID den nächsten Sendeslot. Dann wacht der Regler kurz auf und wartet auf die Nachricht mit der Temperatur. Da der Deep-Sleep beim AVR sehr ungenau ist, passt der Zeitpunkt nicht und die Kommunikation läuft ins leere.

Ich hatte bei meinen Sensoren die erste Version ohne 32KHz Quarz gebaut. Es stimmt, der Watchdog liegt oft 10-15% neben den Nominalwerten, ist damit für den RT-DN zu ungenau. Diese ersten Sensoren laufen gänzlich ohne Quarz, d.h. mit internem 8 MHz RC-Oszillator. Auch der ist ungenau.

Ich habe allerdings in meiner Firmware und im dazu passenden FHEM-Modul einen Parameter dazugebaut, mit dem ich den RC-Oszillator genau einstellen kann. Von diesem Takt abgeleitet habe ich dann eine Autokalibrierung für den Watchdog in die Firmware eingebaut, so daß die (nicht kalibrierbare) Ungenauigkeit des Watchdog softwaremäßig ausgeglichen wird.
Mit diesen zwei Anpassungen erreiche ich eine sehr gute Genauigkeit - die dann auf jeden Fall ausreichend für die Synchronität mit einem RT-DN ist.

Der Grund für mich, einen 32KHz Quarz dazuzubauen war, daß der Watchdog relativ viel Strom braucht. Mit der RTC kommt man in den stromsparendsten Modus - das war mir das Wichtigste. Obendrein gibt's noch etwas höhere Genauigkeit, die bei mir aber gar nicht nötig wäre.

Martin

[Tom Major]

Danke dir.
Den HM-WDS10-TH-O wollte ich nicht 1zu1 nachbauen, sondern habe den als Vorlage für meinen Sensor genutzt.
Worauf ich hinaus möchte sind Sensoren für den Innenraum die Temp, Feuchte und Helligkeit messen und an die Zentrale senden.
Gleichzeitig soll dieser direkt mit HM-CC-RT-DN gepaired werden, damit dieser auf die Isttemperatur am UniSen regelt und nicht auf seine eigene.
Genau wegen diesem Direktpairing möchte ich möglichst nah bei der Vorlage von papa bleiben, weil er sich sicher was dabei gedacht hat

ok, jetzt habe ich verstanden was Du vorhast. Dann nützt Dir der Vorschlag mit der sysclock fürs Peeren nichts, höchstens zum Testen der allgemeinen Funktionalität.
Du brauchst einen Uhrenquarz, z.B. so was
https://www.conrad.de/de/quarzkristall-euroquartz-quarz-tc38-zylinder-32768-khz-125-pf-o-x-h-31-mm-x-8-mm-156098.html
oder ebay "uhrenquarz 32 khz"

[Tom Major]

Der Grund für mich, einen 32KHz Quarz dazuzubauen war, daß der Watchdog relativ viel Strom braucht. Mit der RTC kommt man in den stromsparendsten Modus - das war mir das Wichtigste. Obendrein gibt's noch etwas höhere Genauigkeit, die bei mir aber gar nicht nötig wäre.

Ich möchte nur anmerken das der Unterschied zwischen power down Strom bei enabled/disabled Watchdog nur 4 uA beim mega328P beträgt. Bei einem typischen Sensor trägt Aufwachen/Messen/Funk-Kommunikation sicherlich viel mehr zum Verbrauch bei als die 4 uA.

[andirs]

Hallo zusammen, danke für die Antworten.

Papa deine Änderungen im ino File funktionieren, ich musste lediglich im loop()

hal.activity.savePower<Sleep>(hal); -- ändern zu --> hal.activity.savePower<Sleep<>>(hal);

damit es kompiliert. Danke

Quarze habe ich mir jetzt mal 10Stk. für ~1$ bei Aliexpress bestellt
Auf meinen Minis ist kein großer Quarz. Ich hab mal nen Foto angehangen.

Ist das hier der beste Link für die Umrüstung? Sonst finde ich nichts besonderes:
https://www.davidpilling.com/wiki/index.php/Arduino32768

[jp112sdl]

Hallo zusammen, danke für die Antworten.

Jetzt muss ich doch mal ganz blöd nachfragen...
Du verwendest in deinem Sketch das Model {0xF1,0x01}, was keinem gültigen/bekannten HomeMatic-Model entspricht, sondern dem Custom Device HB-UW-Sen-THPL, welches an der CCU2 auch nur funktioniert, wenn man in /firmware/rftypes das entsprechende XML Metafile ablegt.

Und dennoch kann man deinen Custom-Sensor mit einem originalen HM-CC-RT-DN peeren?
Ist im HM-CC-RT-DN nicht eine Art "Liste gültiger Partner" hinterlegt?
Vielleicht bin ich auf dem Holzweg... Klär(t) mich bitte auf. 

[papa]

Quarze habe ich mir jetzt mal 10Stk. für ~1$ bei Aliexpress bestellt
Auf meinen Minis ist kein großer Quarz. Ich hab mal nen Foto angehangen.

Ist das hier der beste Link für die Umrüstung? Sonst finde ich nichts besonderes:
https://www.davidpilling.com/wiki/index.php/Arduino32768

Da wird die Umrüstung schwierig. Das Board verwendet einen Resonator. Da sind Quarz und Lastkondensatoren in einem Bauteil. Wenn Du nun einen Qurz bestücken willst, müssen da noch die beiden Lastkondensatoren gegen Masse bestückt werden. Ich weiss nicht, ob es Resonatoren mit 32,768kHz in der kleinen Bauform gibt. Als Alternative könntest Du auch diese Platine hier nehmen.

[papa]

Jetzt muss ich doch mal ganz blöd nachfragen...
Du verwendest in deinem Sketch das Model {0xF1,0x01}, was keinem gültigen/bekannten HomeMatic-Model entspricht, sondern dem Custom Device HB-UW-Sen-THPL, welches an der CCU2 auch nur funktioniert, wenn man in /firmware/rftypes das entsprechende XML Metafile ablegt.

Und dennoch kann man deinen Custom-Sensor mit einem originalen HM-CC-RT-DN peeren?
Ist im HM-CC-RT-DN nicht eine Art "Liste gültiger Partner" hinterlegt?
Vielleicht bin ich auf dem Holzweg... Klär(t) mich bitte auf. 

Das geht super. Dem HM-CC-RT-DN ist egal, was da sendet. Es ist nur wichtig, dass an den richtigen Kanal die richtige Nachricht zur richtigen Zeit gesendet wird. Man das ist ja schon fast wie in ner Logistik-Vorlesung.

[papa]

Ich möchte nur anmerken das der Unterschied zwischen power down Strom bei enabled/disabled Watchdog nur 4 uA beim mega328P beträgt. Bei einem typischen Sensor trägt Aufwachen/Messen/Funk-Kommunikation sicherlich viel mehr zum Verbrauch bei als die 4 uA.

Naja, wenn ca. 2-3 Minuten geschlafen wird, um dann nur mal kurz zu Messen und zu Senden, ist das schon ein Unterschied, ob die CPU die gesamte Zeit durchschläft oder alle 8 Sekunden vom Watchdog geweckt wird. Jedes Wecken bedeutet auch ein komplettes Prüfen aller Weckquellen, da es nicht möglich ist festzustellen, wer für das Wecken verantwortlich war (Watchdog, Interrupt, Timer)

[papa]

Code Auswählen Erweitern

Die Geräte bereichen nach der aktuellen Messagenummer und der ID den nächsten Sendeslot. Dann wacht der Regler kurz auf und wartet auf die Nachricht mit der Temperatur.
Hallo Papa, interessant, wie auch viele andere Details hier - wo erfährt man den sowas? Gibts da eine Newsgroup oder was in der Richtung?

Ich habe ganz viel aus den "alten" NewAskSin-Sachen und dem Selbstbau HM-WDS10-TH-O gelernt. Da gibt es viel zu Lesen. Ohne diese Forschungsarbeiten, würde es die AskSin++ Library nicht geben.

[andirs]

Da wird die Umrüstung schwierig. Das Board verwendet einen Resonator. Da sind Quarz und Lastkondensatoren in einem Bauteil. Wenn Du nun einen Qurz bestücken willst, müssen da noch die beiden Lastkondensatoren gegen Masse bestückt werden. Ich weiss nicht, ob es Resonatoren mit 32,768kHz in der kleinen Bauform gibt. Als Alternative könntest Du auch diese Platine hier nehmen.

Mal noch ne doofe frage dazu, wenn ich den 8Mhz Quarz mit einem 32.768Hz tausche, läuft dann der Atmel nicht viel langsamer? Zwischen Mhz und Khz liegen ja 3 Potenzen... Passt das trotz des langsamerern Takts?

[papa]

Mal noch ne doofe frage dazu, wenn ich den 8Mhz Quarz mit einem 32.768Hz tausche, läuft dann der Atmel nicht viel langsamer? Zwischen Mhz und Khz liegen ja 3 Potenzen... Passt das trotz des langsamerern Takts?

Vorher müssen die Fuses auf internen 8MHz Takt umgestellt werden.

[andirs]

Cool, hab die Fuses grad mal umgeschrieben und den Resonator rausgelötet.
Dabei hab ich den Spannungsregler direkt mit entfernt.

Soweit scheint noch alles zu funktionieren

Dann muss ich jetzt nur noch auf die Quarze und die Keramik Kondensatoren warten

[Linef]

Naja, wenn ca. 2-3 Minuten geschlafen wird, um dann nur mal kurz zu Messen und zu Senden, ist das schon ein Unterschied, ob die CPU die gesamte Zeit durchschläft oder alle 8 Sekunden vom Watchdog geweckt wird. Jedes Wecken bedeutet auch ein komplettes Prüfen aller Weckquellen, da es nicht möglich ist festzustellen, wer für das Wecken verantwortlich war (Watchdog, Interrupt, Timer)

Insbesondere braucht der Betrieb des Watchdog den meisten Strom. Schlafende CPU mit RTC braucht laut Datenblatt nur 0,6uA. Mit Watchdog werden dagegen 4,5uA verbraucht. Ständig. Und das macht dann schon einen Unterschied. Wenn die CPU aufwacht, wird zwar Strom im mA-Bereich verbraucht, aber i.d.R. nur wenige mSec (außer es wird tatsächlich gesendet/empfangen).