Autor Thema: AskSin++ Library  (Gelesen 179223 mal)

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1762
Antw:AskSin++ Library
« Antwort #690 am: 26 Februar 2018, 20:30:52 »
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)
//- -----------------------------------------------------------------------------------------------------------------------
// 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);
  }
}
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Klaus0815

  • Sr. Member
  • ****
  • Beiträge: 572
Antw:AskSin++ Library
« Antwort #691 am: 26 Februar 2018, 22:13:28 »
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

Offline Linef

  • Jr. Member
  • **
  • Beiträge: 92
Antw:AskSin++ Library
« Antwort #692 am: 26 Februar 2018, 23:00:25 »
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
fhem auf cubietruck, HM-USB-CFG-2, CUL-V3, 6x HM-CC-RT-DN, 5x HM-SEC-SD, 2x HM-SEC-SCo, 5x HM Eigenbausensoren, AVR-Heizungsgateway

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 532
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #693 am: 27 Februar 2018, 00:31:25 »
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"
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 532
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #694 am: 27 Februar 2018, 00:38:37 »
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.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Offline andirs

  • New Member
  • *
  • Beiträge: 20
Antw:AskSin++ Library
« Antwort #695 am: 27 Februar 2018, 07:42:15 »
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

  • Gast
Antw:AskSin++ Library
« Antwort #696 am: 27 Februar 2018, 07:53:38 »
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.  :)

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1762
Antw:AskSin++ Library
« Antwort #697 am: 27 Februar 2018, 08:11:01 »
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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1762
Antw:AskSin++ Library
« Antwort #698 am: 27 Februar 2018, 08:13:02 »
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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1762
Antw:AskSin++ Library
« Antwort #699 am: 27 Februar 2018, 08:16:10 »
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)
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1762
Antw:AskSin++ Library
« Antwort #700 am: 27 Februar 2018, 08:20:48 »
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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline andirs

  • New Member
  • *
  • Beiträge: 20
Antw:AskSin++ Library
« Antwort #701 am: 27 Februar 2018, 13:30:01 »
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?

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1762
Antw:AskSin++ Library
« Antwort #702 am: 27 Februar 2018, 13:39:02 »
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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline andirs

  • New Member
  • *
  • Beiträge: 20
Antw:AskSin++ Library
« Antwort #703 am: 27 Februar 2018, 14:29:23 »
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 :)

Offline Linef

  • Jr. Member
  • **
  • Beiträge: 92
Antw:AskSin++ Library
« Antwort #704 am: 27 Februar 2018, 17:39:25 »
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).
fhem auf cubietruck, HM-USB-CFG-2, CUL-V3, 6x HM-CC-RT-DN, 5x HM-SEC-SD, 2x HM-SEC-SCo, 5x HM Eigenbausensoren, AVR-Heizungsgateway