[gelöst] Ideen/Brainstorming - Zeitprofile bei AskSin++ Aktoren

[jp112sdl]

Mahlzeit miteinander.

Zeitprofile gibt es ja nur bei HmIP-Geräten.
An manchen Stellen wäre ich froh, das auch beim klassischen HMRF zu haben.

Eine große Frage dabei:

• Wie kommt die aktuelle Uhrzeit zum Aktor, möglichst zeitnah nach Stromzufuhr?

Vor kurzem hatte ich dazu schon mal recherchiert, wie das denn bei den HmIP-Geräten funktioniert.
So wie Baxxy es ermitteln konnte, bekommen sie die Uhrzeit mit dem ersten Ack-Telegramm der CCU.

In der BidCos-Welt geht das leider nicht so einfach.
Dort wird die Uhrzeit zyklisch mit vielen Stunden Abstand über den Prozess SetInterfaceClock gesendet, zudem mit BURST.

Mir ist leider keine Möglichkeit bekannt, der CCU ein TIMESTAMP-Telegramm (ohne BURST) manuell zu entlocken.

Daher wäre meine Idee, einen Zeitsender zu bauen, der alle paar Minuten das TIMESTAMP-Telegramm per Broadcast aussendet.
Dieser benötigt natürlich wiederum selbst eine aktuelle Zeit, die er aussenden soll.

Mein bisher im Kopf schwirrender Aufbau:
ESP32 mit DS3231 RTC Modul, CC1101 Funkmodul und Berücksichtigung folgender Szenarien:

• Regelfall:
  Der ESP32 holt sich bei Inbetriebnahme die Uhrzeit bei NTP aus dem Internet und stellt dabei die DS3231 RTC.
  Anschließend wird alle n Minuten ein TIMESTAMP gebroadcastet.
• kein Internet/NTP verfügbar, RTC nicht gestellt:
  Der ESP wartet auf ein zyklisches TIMESTAMP-Telegramm (von SetInterfaceClock) und mit dieser empfangenen Uhrzeit wird die DS3231 RTC gestellt.
  Anschließend wird alle n Minuten ein TIMESTAMP gebroadcastet.
• kein Internet/NTP verfügbar, RTC ist gestellt:
  Der ESP32 prüft die RTC Zeit auf Plausibilität (z.B. muss das Datum nach dem Kompilierzeitpunkt sein) und broadcastet diese dann alle n Minuten.

Natürlich fehlt noch der Gegenpart - die eigentliche Implementierung von Zeitprofilen im Aktor und auch der Konfiguration mithilfe der CCU.

Hat jemand Vorschläge zur Verbesserung?
Habe ich irgendwas nicht bedacht?

[Black]

eigentlich betrifft dieses ja in irgendeiner form schaltaktoren... sensoren mit einem Zeitprogramm, fällt mir jetzt nicht sooo der sinn ein.
wäre es da bei Aktoren in zukünftigen PCBs nicht sinnreicher, im Layout direkt eine gepufferte RTC einzusetzen ?

sowas in der Art:

PCF2127 oder M41T01 ?

dann brächte es das drumgerum gewürge nicht und bei einem empfangene Time Broadcast wird die interne Uhr mitgeführt

Black

[HMSteve]

Hallo Jérôme,

Coole Idee, koennte mir vorstellen, dass sich noch diverse Ideen fuer eine Nutzung entwickeln, wenn es erstmal eine HM-Uhrzeitbake gibt.
Da ich immer versuche, den Wildwuchs netzbetriebener Geraete im Zaum zu halten, vielleicht eine Abwandlung Deiner Idee fuer Batteriebetrieb: ATMega mit DCF77-Empfaenger und RTC?

Viele Gruesse,
Stephan

[jp112sdl]

irgendeiner form schaltaktoren

Genau, so ziemlich ausschließlich

in zukünftigen PCBs nicht sinnreicher, im Layout direkt eine gepufferte RTC einzusetzen ?

Klar, aber auch da muss die Zeit erstmal zur RTC kommen.
Und meine Bestands-Elektronik möchte ich ungern mit neuen PCBs aufbauen.
Dazu kommen noch die umgeflashten eQ-3 Geräte ohne RTC.

So lange das Gerät an ist, kann nach einmaligem Empfang eines TIMESTAMP intern mit den millis() weitergearbeitet werden (auch wenn sie nach 49 Tagen überlaufen, aber das bekommt man in den Griff)

Da ich immer versuche, den Wildwuchs netzbetriebener Geraete im Zaum zu halten,

Ich versuche, möglichst wenig Batterien zu verbasteln
Und der Zeitsender kann ruhig netzbetrieben sein... hängt meinetwegen an nem USB Port vom Raspi oder so.

mit DCF77-Empfaenger

Den hatte ich auch mal geplant als Zeitgeber für den Raspi, aber bei mir ist echt schlechter Empfang, da müsste ich die Antenne irgendwo am Fenster platzieren. Selbst Funkuhren stellen sich hier nur wenn sie irgendwo am Fenster stehen.
Daher war meine Idee, am schnellsten an eine Uhrzeit zu kommen, per NTP.

[Horbi]

Wie läuft das denn bei den Heizkörperreglern/Wandthermostaten, die bekommen ihre Zeit recht zügig von der CCU?
Zumindest geht es recht schnell nach dem Batteriewechsel...

[jp112sdl]

Wie läuft das denn bei den Heizkörperreglern/Wandthermostaten, die bekommen ihre Zeit recht zügig von der CCU?

Sehr guter Hinweis!

In den XML der beiden Gerätetypen kann ich in den ...to_device... Frames nix finden, was mir da weiterhilft.
https://github.com/AskSinPP/asksinpp-we ... _rt_dn.xml
https://github.com/AskSinPP/asksinpp-we ... m-w-eu.xml

Jedoch konnte ich im AskSinAnalyzer sehen, dass das HKT nach dem Einlegen der Batterie die Uhrzeit ohne Burst sofort bekommt.

An der Stelle suche ich mal weiter.

[jp112sdl]

Wie läuft das denn bei den Heizkörperreglern/Wandthermostaten, die bekommen ihre Zeit recht zügig von der CCU?
Zumindest geht es recht schnell nach dem Batteriewechsel...

PERFEKT!
Danke für den Denkanstoß.
Hab ich mir (mal wieder) völlig umsonst einen riesigen Workaround konstruiert.
Dann kann ich mir den ganzen anderen Spaß sparen.

Hier noch der Code, falls jemand testen möchte:

Code: Alles auswählen

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <Device.h>
#include <Register.h>
#include <TimeLib.h>

#define CC1101_GDO0_PIN     2
#define CC1101_CS_PIN       10
#define CC1101_MOSI_PIN     11
#define CC1101_MISO_PIN     12
#define CC1101_SCK_PIN      13

using namespace as;

HMID  CENTRAL_CCU(0x2B,0xE1,0x4D); 
HMID KNOWN_DEVICE(0x20,0x20,0x20);

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

typedef AvrSPI<CC1101_CS_PIN, CC1101_MOSI_PIN, CC1101_MISO_PIN, CC1101_SCK_PIN> SPIType;
typedef AskSin<NoLed,NoBattery,Radio<SPIType, CC1101_GDO0_PIN>> HalType;

class TimestampDev : public Device<HalType,DefList0> {
  DefList0 l0;
public:
  HMID id;

  typedef Device<HalType,DefList0> BaseDevice;
  TimestampDev (const DeviceInfo& i,uint16_t addr) : BaseDevice(i,addr,l0,0), l0(addr) {}
  virtual ~TimestampDev () {}
  virtual bool process(Message& msg) {
     if (getMasterID() == msg.from()) {
      if(msg.type() == AS_MESSAGE_TIMESTAMP) {
        if (msg.command() == AS_ACTION_SET) {
         DPRINTLN("Got TIMESTAMP Message");
         msg.dump();
         static const uint32_t sec2000 = 946684800;

         int8_t timezone = msg.buffer()[10] / 2;

         uint32_t tPayload =
            (((uint32_t)msg.buffer()[11]) << 24) +
            (((uint32_t)msg.buffer()[12]) << 16) +
            (((uint32_t)msg.buffer()[13]) << 8) +
            (((uint32_t)msg.buffer()[14]))       ;

         uint32_t unixtime = sec2000 + tPayload;

         setTime(unixtime);

         time_t t = now();
         DPRINT("UTC   Time is ");DDEC(day(t));DPRINT(".");DDEC(month(t));DPRINT(".");DDEC(year(t));DPRINT(" ");DDEC(hour(t));DPRINT(":");DDEC(minute(t));DPRINT(":");DDECLN(second(t));

         adjustTime(timezone * 3600);
         t = now();
         DPRINT("local Time is ");DDEC(day(t));DPRINT(".");DDEC(month(t));DPRINT(".");DDEC(year(t));DPRINT(" ");DDEC(hour(t));DPRINT(":");DDEC(minute(t));DPRINT(":");DDECLN(second(t));
        }
      }
    }
    
    return true;
  }

  bool init (HalType& hal) {
    this->setHal(hal);
    this->getDeviceID(id);
    hal.init(id);
    return false;
  }
};

HalType hal;
TimestampDev sdev(devinfo,0x20);

class InfoTimestampMsg : public Message {
public:
  void init () {
    Message::init(0x09,0x00,AS_MESSAGE_TIMESTAMP,BIDI|RPTEN,0x00,0x00);
  }
};

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

  InfoTimestampMsg msg;
  msg.init();
  msg.to(CENTRAL_CCU);
  msg.from(KNOWN_DEVICE);
  sdev.radio().write(msg, false);
  DPRINTLN("Sending Timestamp request...");
  msg.dump();
 }

void loop() {
  sdev.pollRadio();
  hal.runready();
}

Die Adressen CENTRAL_CCU (CCU) und KNOWN_DEVICE (Adresse eines angelernten Geräts) sind noch entsprechend anzupassen.

[Horbi]

Coole Sache, das mit der Zeit eröffnet völlig neue Möglichkeiten. Lampen die bei Nacht weniger hell sind, oder eine Klingel die Leiser wird...

Das größere Problem wird bei solchen Geräten und Optionen jetzt die XML auf der CCU Seite. Braucht ja neue Register für die Steuerung, oder?

[jp112sdl]

Braucht ja neue Register für die Steuerung, oder?

Ja, darüber habe ich mir auch gerade Gedanken gemacht.

Das HM-CC-RT-DN hat nur 1 Zeitprofil, das liegt in List 7
Das HM-TC-IT-WM-W-EU kann 3 Profile, die liegen in List 7, 8 und 9

Je Wochentag lassen sich bis zu 13 Schaltzeiten festlegen.

Ich würde erstmal vorsichtig mit einem Profil anfangen und die List 7 implementieren.

[jp112sdl]

Ich würde erstmal vorsichtig mit einem Profil anfangen

Kurzer Zwischenstand... die WebUI Modifikationen nehmen die meiste Zeit in Anspruch