AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

papa

Hallo,

ich habe mich mal daran gemacht und versucht, die bestehende AskSin bzw. NewAskSin Library einfacher benutzbar zu machen. Dabei ist die AskSin++ Library rausgekommen. Sie verwendet an vielen Stellen C++ Templates. Damit lassen sich die Devicechannels recht einfach zusammenstecken. Der aktuelle (leider noch undokumentierte) Code ist hier zu finden:

https://github.com/pa-pa/AskSinPP

Anleitungen und fertige Projekte gibt es auf der AskSin++ Webseite.

Hier mal kurz die Unterschiede zum (New)AskSin Code:
* im Ganzen mehr in C++ Klassen gekapselt
* Timer-Klasse, die Code zu einem bestimmten Zeitpunkt startet / Alarm ausführt
* Channel-Basis-Klasse, die direkt mit dem Flash arbeitet - kein RAM für die Channel-Listen-Kopien benötigt
* Templates zum konfigurieren der Channels eines Devices
* keine "handberechneten Tabellen" für die ChannelDaten nötig, damit einfacher neue Devices aufzusetzen

Die Library wird einfach in den Arduino Library Ordner gelegt. Derzeit sind folgende Beispiele als Proof-Of-Concept enthalten:
* HM-LC-SW(1|2|4)-SM - Anzahl der Kanäle wird über ein Define im Sketch eingestellt
* HM-SEC-MDIR - bin ich mir nicht sicher, ob das so mit den Nachrichten so richtig ist
* HM-WDS10-TH-O - sendet nur Testdaten
* HM-WDS100-C6-O-2 - sendet nur Testdaten
* HM-ES-TX-WM - für Gas und Strom
* HM-RC-4

Die Beispiele dienen derzeit hauptsächlich zur Validierung der Architektur.

AskSin++ benötigt derzeit drei andere Arduino Libraries:
* TimerOne - https://github.com/PaulStoffregen/TimerOne
* PinChangeInt - https://github.com/GreyGnome/PinChangeInt
* Low-Power - https://github.com/rocketscream/Low-Power

Ich möchte hiermit trilu, martinp876, Dirk und allen andere Beteiligten für die Arbeit an der originalen (New)AskSin Library danken. Ohne Eure Vorlage wäre dieser Code nie entstanden.

Genau wie die (New)AskSin kann die Library jeder nutzen und weiter entwickeln solange er seine Ergebnisse der Allgemeinheit wieder zur Verfügung stellt und keine wirtschaftlichen Nutzen daraus zieht!

Ich würde mich freuen, wenn auf Basis dieser Library viele neue Geräte entstehen würden. Es darf sich natürlich auch gerne an der Weiterentwicklung beteiligt werden.

Update 01.09.2017 Es gibt jetzt den stabilen V2 Branch. Hier werden nur noch Fehler beseitigt. Mit diesem ist es auch möglich neben ATMega328 CPUs auch STM32F1 CPUs zu verwenden. Anstatt der PinChange Library wird jetzt die EnableInterrupt Library benötigt.

https://github.com/GreyGnome/EnableInterrupt

Neue Example sind:

  • HM-LC-Dim1PWM-CV
  • HM-SEC-RHS
  • HM-SEN-MDIR-WM55

Update 21.05.2018 Es gibt jetzt den stabilen V3 Branch. Hier werden nur noch Fehler beseitigt.

Interessante Nachbauprojekte von hier bzw. aus dem Homematic Forum.

Update 09.05.2019 Es gibt jetzt den stabilen V4 Branch. Hier werden nur noch Fehler beseitigt.

Unter asksinpp.de gibt es eine schöne Zusammenstellung von Selbstbauprojekten.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

MBHG

#1
Hallo,

ich habe den SWX Sketch mal auf meinen Nano geladen.


Dann noch folgende Pins gesetzt.


// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN PORTD4
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN PORTB0


Er meldet sich beim Start bei FHEM mit



2016-10-02 19:46:35 CUL CUL_1 UNKNOWNCODE A0E0120101234560000000601C80000::-37.5:CUL_1


Wenn ich B8 mit GND brücke bekomme ich kein Pairing. Was ist für ein Pairing zu tun?

Danke

MB
-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

papa

Hallo,

die Pins beim Nano sollen eigentlich die gleichen wie beim Pro Mini sein. Setze einfach wieder


#define LED_PIN 4
#define CONFIG_BUTTON_PIN 8


Dann den Config-Button lange drücken. Bei einem kurzen Druck, sollte das erste Relais umschalten.

Holger
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

MBHG

#3
Hallo Holger,

danke. Nette Implementierung, eigentlich ideal für mich.

Ich habe die Einstellung zurückgestellt und getestet. Bei mir läuft das Pairing nicht ganz durch - was aber nicht an Deiner Implementierung liegt sondern an irgendeinem anderen Problem. Ich habe dasselbe seit ca einem Jahr mit der Newasksin Library.

Anbei die Tests:


SW4

longpressed
<- 1C 16 00 00 12 34 56 00 00 00 16 00 03 70 61 70 61 30 30 30 30 30 30 00 41 01 00 00 00
longreleased


Log

2016.10.03 08:46:19 4: CUL_Parse: CUL_1 A 1C 40 0000 123456 000000 1600037061706130303030303000410100000042 -41
2016.10.03 08:46:19 3: CUL_HM pair: HM_123456 switch, model HM-LC-SW4-SM serialNr papa000000
2016.10.03 08:46:19 4: CUL_send:  CUL_1As 10 55 A001 123456 123456 00050000000000



Event Monitor

2016-10-03 08:46:19 CUL_HM HM_123456 D-firmware: 1.6
2016-10-03 08:46:19 CUL_HM HM_123456 D-serialNr: papa000000
2016-10-03 08:46:19 CUL_HM HM_123456 CMDs_pending

..... und darüber kommt er nicht hinaus


List HM_123456

Internals:
   CUL_1_MSGCNT 43
   CUL_1_RAWMSG A1C4A000012345600000016000370617061303030303030004101000000::-42:CUL_1
   CUL_1_RSSI -42
   CUL_1_TIME 2016-10-03 08:47:27
   DEF        123456
   IODev      CUL_1
   LASTInputDev CUL_1
   MSGCNT     43
   NAME       HM_123456
   NOTIFYDEV  global
   NR         104
   NTFY_ORDER 50-HM_123456
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 HM_123456_Sw_01
   channel_02 HM_123456_Sw_02
   channel_03 HM_123456_Sw_03
   channel_04 HM_123456_Sw_04
   lastMsg    No:4A - t:00 s:123456 d:000000 16000370617061303030303030004101000000
   protCmdDel 3
   protLastRcv 2016-10-03 08:47:27
   protResnd  3 last_at:2016-10-03 08:46:32
   protResndFail 1 last_at:2016-10-03 08:46:37
   protSnd    1 last_at:2016-10-03 08:46:19
   protState  CMDs_done_Errors:1
   rssi_at_CUL_1 avg:-41.29 min:-43 lst:-42 cnt:43 max:-39.5
   Readings:
     2016-10-03 08:47:27   D-firmware      1.6
     2016-10-03 08:47:27   D-serialNr      papa000000
     2016-10-03 08:30:49   R-pairCentral   set_0x123456
     2016-10-03 08:46:37   state           MISSING ACK
   Helper:
     HM_CMDNR   94
     cSnd       ,0112345612345600050000000000
     mId        0003
     rxType     1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +123456,00,00,00
       nextSend   1475477247.47676
       prefIO
       rxt        0
       vccu
       p:
         123456
         00
         00
         00
     Mrssi:
       mNo        4A
       Io:
         CUL_1      -40
     Prt:
       bErr       0
       mmcS       1
       sProc      0
       mmcA:
         ++A00112345612345600050000000000
     Q:
       qReqConf   00
       qReqStat   02,03,04
     Role:
       dev        1
       prs        1
     Rssi:
       At_cul_1:
         avg        -41.2906976744186
         cnt        43
         lst        -42
         max        -39.5
         min        -43
     Shadowreg:
       RegL_00.    02:01 0A:12 0B:34 0C:56
Attributes:
   IODev      CUL_1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.6
   model      HM-LC-SW4-SM
   room       CUL_HM
   serialNr   papa000000
   subType    switch
   webCmd     getConfig:clear msgEvents


Cul_1
Internals:
   CMDS       BCFiAGMKUYRTVWXefLltx
   CUL_1_MSGCNT 50
   CUL_1_TIME 2016-10-03 09:01:14
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK0598M0-if00-port0@38400 2807
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK0598M0-if00-port0@38400
   FD         17
   FHTID      2807
   NAME       CUL_1
   NR         90
   NR_CMD_LAST_H 8
   PARTIAL
   RAWMSG     A1C5100001234560000001600037061706130303030303000410100000038
   RSSI       -46
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.21.00 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
Ar
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-10-03 08:45:09   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2016-10-03 08:44:46   cmds             B C F i A G M K U Y R T V W X e f L l t x
     2016-10-02 09:15:16   credit10ms      2015
     2016-10-02 09:15:20   fhtbuf          AE
     2016-10-03 09:01:15   state           Initialized
     2016-10-02 09:15:25   uptime          0 00:03:45
     2016-10-02 09:15:29   version         V 1.66 nanoCUL868
   XMIT_TIME:
     1475477179.67579
     1475477182.67972
     1475477187.63729
     1475477192.67658
     1475478075.01201
     1475478077.43509
     1475478081.72668
     1475478087.72353
   Helper:
     123456:
       QUEUE:
Attributes:
   devStateIcon .*:cul_cul
   hmId       123456
   rfmode     HomeMatic
   room       System
   verbose    4


Ich habe zwei fast baugleiche Arduino Nanos, mit echtem CC1101. Generell läuft bei mir das Pairing mit der Newasksin nicht ganz durch, was unabhängig ist von Deiner Variante der Newasksin. Der Switch mit der Newasksin(++) sendet ein Pairing, was von dem Nano auf FHEM auch empfangen wird. Der Nano von FHEM macht ein getConfig, was bei dem Switch aber nie ankommt. Je nach Bauart des Nanos an FHEM stürzt dieser auch ab.

Sprich ich kann die beiden fast baugleichen Nanos tauschen und habe dasselbe Phänomen. Ist aus meiner Sicht ein Softwarefehler in CULF oder FHEM, oder ein Kompatibilitätsproblem zwischen meinem Nano und dem culf.

Irgendwann bekomme ich es heraus.

Gruss Marc

-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

papa

#4
Verwendest Du für beides - Sender & Empfänger - den selben Aufbau ? Es gibt da einen entscheidenen Unterschied. Der NanoCUL hat GDO0 an D3 und GDO2 an D2 (siehe auch http://www.fhemwiki.de/wiki/Selbstbau_CUL. Die AskSin++ & NewAskSin erwartet GDO0 an D2. GDO2 wird nicht verwendet (siehe Schaltplan https://forum.fhem.de/index.php/topic,48235.0.html). Somit wird er Interrupt, der neue Daten signalisiert, nicht erkannt und das Device empfängt keine Daten.

Holger
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

MBHG

#5
Hallo Holger,

you made my day! Das war es. Danach suche ich schon Wochen. Funktioniert bestens! Meine Gartenbewässerung liegt, jetzt kann ich sie auch vom Tablet aus steuern.

Vielen Dank


Internals:
   CFGFN
   CUL_1_MSGCNT 25
   CUL_1_RAWMSG A0E0C20101234561234560100000000::-34:CUL_1
   CUL_1_RSSI -34
   CUL_1_TIME 2016-10-03 10:50:00
   DEF        123456
   IODev      CUL_1
   LASTInputDev CUL_1
   MSGCNT     25
   NAME       HM_123456
   NOTIFYDEV  global
   NR         154
   NTFY_ORDER 50-HM_123456
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_123456_Sw_01
   channel_02 HM_123456_Sw_02
   channel_03 HM_123456_Sw_03
   channel_04 HM_123456_Sw_04
   lastMsg    No:0C - t:10 s:123456 d:123456 0100000000
   protLastRcv 2016-10-03 10:50:00
   protSnd    37 last_at:2016-10-03 10:50:00
   protState  CMDs_done
   rssi_HM_123456 lst:-112 min:-112 max:-110 cnt:7 avg:-111.14
   rssi_at_CUL_1 min:-36.5 lst:-34 avg:-32.74 cnt:25 max:-29.5
   Readings:
     2016-10-03 10:48:27   CommandAccepted yes
     2016-10-03 10:48:27   D-firmware      1.6
     2016-10-03 10:48:27   D-serialNr      papa000000
     2016-10-03 10:48:31   PairedTo        0x123456
     2016-10-03 10:48:31   R-pairCentral   0x123456
     2016-10-03 10:48:31   RegL_00.          02:01 0A:12 0B:34 0C:56 00:00
     2016-10-03 10:50:00   state           CMDs_done
   Helper:
     HM_CMDNR   12
     cSnd       0112345612345604040000000001,011234561234560403
     mId        0003
     rxType     1
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +123456,00,00,00
       nextSend   1475484600.90647
       prefIO
       rxt        0
       vccu
       p:
         123456
         00
         00
         00
     Mrssi:
       mNo        0C
       Io:
         CUL_1      -32
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       prs        1
     Rpt:
       IO         CUL_1
       flg        2
       ts         1475484600.80924
       ack:
         HASH(0x53fc838)
         0C800212345612345600
     Rssi:
       Hm_123456:
         avg        -111.142857142857
         cnt        7
         lst        -112
         max        -110
         min        -112
       At_cul_1:
         avg        -32.74
         cnt        25
         lst        -34
         max        -29.5
         min        -36.5
     Shadowreg:
Attributes:
   IODev      CUL_1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.6
   model      HM-LC-SW4-SM
   room       CUL_HM
   serialNr   papa000000
   subType    switch
   webCmd     getConfig:clear msgEvents


Youtube
https://youtu.be/ahPvSpvzD5o
-----------------------------------------------------------
https://smarthome.family.blog Debian Linux, NanoCUL 868, Signalduino, 4x HM-SW4, 11x HM Asksin Unisensor, NodeMCU ESP8266, RCS 1000 N Comfort, Magic Home, Rauchmelder PT2262, Babble

papa

Freut mich, dass jetzt alles geht.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Dietmar63

#7
So, mein OAMP scheint nun zu funktionieren. Deshalb habe ich jetzt mehr Zeit für die Software.
Ich hatte ja schon angedeutet, dass ich es mit dieser Variante von AkSin probieren möchte.

Einige Fragen:
Gibt es eine Möglichkeit die Zeit abzufragen getMillis ()
Ist so eine Funktion geplant?

Wie genau schätzt du den Timer1 ein? Wdt weicht auf dem Pro Mini um 11% von millis() ab.

Funktioniert das Schreiben der Register? Wie kann ich das überprüfen?
Werden empfangene Nachrichten protokolliert?

Danke für Antworten - habe noch mehr Fragen.
Dietmar

Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

papa

Zitat von: Dietmar63 am 17 Oktober 2016, 17:30:44
Gibt es eine Möglichkeit die Zeit abzufragen getMillis ()
Ist so eine Funktion geplant?

Du kannst natürlich die millis() benutzen. Allerdings wird der Wert derzeit nicht durch den Powerdown-Wert korrigiert. Ich versuche alles gundsätzlich durch die Alarm-Klasse abzubilden. Die Alarme werden durch Timer1 ausgelöst. Hier erfolgt auch eine Korrektur nach einem PowerDown. Allerdings ist noch keine Kalibrierung eingebaut.

Wenn Du nach einer bestimmten Zeit eine Aktion durchführen willst, nimmst Du einen Alarm, überschreibst die trigger() Methode und fügst ihn der globalen "aclock" hinzu. Wenn die Zeit abgelaufen ist, wird trigger() synchron während der Main-Loop aufgerufen. Der Timer kann in AlarmClock konfiguriert werden. Er tickt im Defaultsetup nur mit 10 Ticks per Second. Genauer habe ich bisher nicht gebraucht. Kann aber in AlarmClock.h eingestellt werden. Wenn dann immer schön brav die Macros zur Umrechnung genutzt werden, sollten keine weiteren Änderungen zur Anpassung der Timer-Frequenz nötig sein.

Zitat von: Dietmar63 am 17 Oktober 2016, 17:30:44
Wie genau schätzt du den Timer1 ein? Wdt weicht auf dem Pro Mini um 11% von millis() ab.

Timer1 läuft (glaube ich) mit normalen Systemtakt. Also so genau wie auch Timer0. Das Problem beim WDT ist ja, dass er mit einer anderen Taktquelle viel langsamer läuft.

Zitat von: Dietmar63 am 17 Oktober 2016, 17:30:44
Funktioniert das Schreiben der Register? Wie kann ich das überprüfen?

Natürlich. Von FHEM aus Schreiben und getConfig.

Zitat von: Dietmar63 am 17 Oktober 2016, 17:30:44
Werden empfangene Nachrichten protokolliert?

Hier weiss ich nicht, wie Du das meinst. Empfangende und gesendete Nachrrichten werden derzeit immer auf die Serial-Console geschrieben. Kann in Debug.h durch Definition von NDEBUG abgeschalten werden.

Zitat von: Dietmar63 am 17 Oktober 2016, 17:30:44
Danke für Antworten - habe noch mehr Fragen.
Dietmar

bitte
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

Im anderen Thread der NewAskSin Library wurde nach eine WDS100-C6-O-2 Template gefragt. Ich habe ein entsprechendes Example hier eingefügt. Ist aber nur ganz basic getestet. Zumindest konnte ich mit FHEM pairen und die empfangenen Werte sahen auch ganz gut aus.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Dietmar63

#10
ZitatWenn die Zeit abgelaufen ist, wird trigger() synchron während der Main-Loop aufgerufen.
Heißt das, dass nach Ablauf des Alarms sofort trigger() ausgeführt wird, weil ein Interrupt den A. weckt, oder wird trigger() erst dann geweckt, wenn LowPower.powerDown(SLEEP_8S...) abgelaufen ist.

ZitatFunktioniert das Schreiben der Register? Wie kann ich das überprüfen?
wenn ja, dann müsste ich das Schreiben im Funkverkehr sehen oder nicht?

ZitatTimer1 läuft (glaube ich) mit normalen Systemtakt. Also so genau wie auch Timer0. Das Problem beim WDT ist ja, dass er mit einer anderen Taktquelle viel langsamer läuft.

das wäre genau genug. Da ich den Stromverbrauch ermitteln will und der Arduino(HM-ES-TX-WM) die Leistung ausrechnen muss ist die genaue Zeit unverzichtbar. Mal sehen was ich da mache.

Nebenbei. Die offsets nach sleeps habe ich gesehen. Aber sidn die nicht sehr ungenau? 8s sind nicht wirklich 8 Sekunden, selbst wenn die Uhr genau funktionieren würde.

müsste man offset(WDTtime) nicht irgendwie so ausrechen?


void WDTEnable (uint8_t period) {

    wdt_enable(period);
    WDTCSR |= (1 << WDIE);
   
    WDTtime = 2 << (period + 3); // in Millisekunden

}


Was ich noch festgestellt hatte:
Wenn der A. in der NewAskSin durch einen Interrupt geweckt wurde, lief die loop() wieder automatisch an und der WDT wurde von neuem in der Klasse Power gesetzt, so dass die Zeit bis  zum Interrupt bei der Aufsummierung der tmillis für getMillis() nicht mit gezählt wurde(so glaube ich jedenfalls).

Für ein sinnvolles Zeitsignal darf man vielleicht nur die offsets der Alarms von Timer1 addieren. Ein genaues Bild habe ich leider nicht. Aber bei Tests ist mir aufgefallen, dass es sich so ähnlich verhielt. Man kennt einfach die Zeit eines asynchronen Ereignisses nicht.

micky0867
Könnte vielleicht auch ein Fan von dieser Variante der AskSin werden. Zu NewAskSin gibt es ja kaum Unterstützung.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Linef

Hallo,
ZitatKönnte vielleicht auch ein Fan von dieser Variante der AskSin werden. Zu NewAskSin gibt es ja kaum Unterstützung.

Trilu baut die NewAskSin gerade komplett um - das Ganze wird jetzt viel strukturierter.
Destillregs ist auch nicht mehr notwendig.

Ich bin grad dran, den Power-Save-Modus zusammen mit dem 32KHz Quarz zu implementieren. Dann läuft der Chip noch etwas sparsamer als mit RC-Osc und Watchdog und die katastrophale Watchdog-"Un-Genauigkeit" ist dann auch passé...

ZitatMan kennt einfach die Zeit eines asynchronen Ereignisses nicht.
An dem Problem habe ich auch schon rum überlegt - man könnte beim async. Interrupt den Timer auslesen und damit die Zeit seit dem letzten Sleep berechnen - allerdings geht die Info aus dem Timer-Prescaler verloren...
Das Verfahren geht wahrscheinlich nur mit dem normalen Timer - nicht mit dem Watchdog. Und im Stromsparmodus läuft auch nur noch der Timer2 (im async. Modus).

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

papa

Ich denke, wenn eine wirklich genaue Zeit benötigt, wird, muss man auf PowerDown verzichten, oder den Modus mit dem externen Quarz wählen. Das braucht dann halt extra Hardware. Die Zeitmessung müsste dann auch entsprechend an den Timer2 angebunden werden. Alles andere ist (meiner Meinung nach) vergebene Mühe.

@Dietmar63 - Während des PowerDown wird der Timer nicht abgearbeitet. Der Trigger kommt also erst nach dem PowerDown. Allerdings wird die Zeitspanne entsprechend dem nächsten Timeout ausgerechnet. Also die CPU wird maximal bis zum nächsten Timer-Event schlafen gelegt.
Das Schreiben der Register sieht man auch im Funkverkehr. Achtung beim HM-ES-TX-WM musst Du immer den Config-Button drücken, nachdem Du iregndwas in den Registern mit FHEM geändert hast. Erst dann wird das ganze von FHEM aus gesendet.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Dietmar63

Ich will in meiner Version von HM-ES-TX-WM gleichzeitig den Gasverbrauch und den Stromverbrauch messen. Dazu will ich alle 5 Minuten den Wert für Strom und alle 10 Minuten den Wert für Gas übermitteln.

Dazu habe ich folgenden zusätzlichen Alarm eingebaut.


// ----------------------------------------------------------------------
// --- AlarmGas
// ----------------------------------------------------------------------
class AlarmGas : public Alarm {

MeterChannel &channel;
 
public:   
    AlarmGas(MeterChannel &c) : Alarm(MSG_CYCLE_GAS), channel(c) {}
   
    virtual void trigger (AlarmClock& clock) {
   
       channel.triggerGas();
         
       tick = MSG_CYCLE_GAS;
       clock.add(*this);       
    }   
};

AlarmGas alarmGas = AlarmGas(sdev.channel(0));


das Ganze startet auch aber ich bekomme folgenden output:

AskSin++ V0.1.0
CC init12..............3 - ready
Bat: 33
Strom
<- 10 00 20 5E 44 12 34 00 00 00 80 00 00 00 00 00 00
Gas
<- 10 00 20 53 23 01 E6 01 00 00 00 00 00 00 00 00 00
waitAck: 00
waitAck: 00
waitAck: 00
waitAck: 00
waitAck: 00
waitAck: 00
Strom
<- 10 01 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 02 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
AskSi


sieht nach einer Endlosschleife oder restart aus. Nach dem AskSi scrollt der Serielle Monitor wie wild.

Hast du eine Idee was da warum nicht funktioniert.
Kann man ein Multichanneldevice aus verschiedenen Kanälen(MeterChannelGas, MeterChannelStrom) aufbauen, dann würde ich zwei channel bauen, die sich in der trigger() Funktion unterscheiden.

Bezüglich der Zeitproblematik warte ich erst einmal ab.
Vielleicht ist das Problem nicht wirklich groß, Eventuell muss ich in Activity etwas verbessern.

Durch deine Erklärung habe ich jetzt auch den Code verstanden:
Wenn ich es richtig sehe, wird je nach Zeit bis zum Ablauf des nächsten timers 8,1 oder 1/2 Sekunde der wdt gestartet. Wenn weniger als 500 ms bis zum nächsten timer sind, bleibt der A. wach und der Timer1kann feuern. Nach jedem Ablauf des wdt wird der offset in alle Alarme gerechnet.

Danke
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

papa


AlarmGas alarmGas = AlarmGas(sdev.channel(0));


Channel 0 gibt es nicht. Es geht bei 1 los.

Zitat
Wenn ich es richtig sehe, wird je nach Zeit bis zum Ablauf des nächsten timers 8,1 oder 1/2 Sekunde der wdt gestartet. Wenn weniger als 500 ms bis zum nächsten timer sind, bleibt der A. wach und der Timer1kann feuern. Nach jedem Ablauf des wdt wird der offset in alle Alarme gerechnet.

Korrekt. Da alle Timer relativ zueinander und sortiert verwaltet werden, braucht man den Offset nur beim Ersten abziehen.
Als Verbesserung könnte man noch eine WDT-Kalibrierung am Start machen und diese dann bei der Offsetberechnung nutzen und den WDT erst wieder neu starten, nachdem der Interrupt da war.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire