AskSin++ Library

[jp112sdl]

Frage daher: gibt es die Möglichkeit eine Art Totzeit zu realisieren, in der *keine* Transmits stattfinden, egal ob ein Interrupt (durch den PIR) getriggert wird?

Ja, schau dir mal die Motion.h an.
Beim HM Bewegungsmelder kann man auch sowas über List1-Parameter definieren.

[Tom Major]

Ja, schau dir mal die Motion.h an.
Beim HM Bewegungsmelder kann man auch sowas über List1-Parameter definieren.

Das Ganze soll für den Unisensor sein und der Dig.Input dort möglichst universell. Bin nicht sicher wie ich das mit Motion verheiratet bekomme.

[Tom Major]

@papa,

bin ja gerade dran, mit Tom eine optimierte Version seines UniSensors fertig zu stellen - sind schon gut voran gekommen. Was uns bei dem verwendeten PIR aufgefallen ist, dass er alle 2 sek. bei einer einer Motion Detection eine Zustandsänderung auslöst. Dies erzeugt eine hohe Anzahl von Sendezyklen, die wir gerne vermeiden möchten (zum Strom sparen).

Frage daher: gibt es die Möglichkeit eine Art Totzeit zu realisieren, in der *keine* Transmits stattfinden, egal ob ein Interrupt (durch den PIR) getriggert wird?

Andreas

@papa
ich versuche mal die Frage so zu formulieren:

fhemfreund betreibt den UniSensor mit RTC configuration.
Wir möchten beim Aufwachen über den interrupt des dig. Eingangs entscheiden ob wir senden oder nicht, abhängig vom der vergangenen Zeitdauer zum letzten Sendevorgang.

Mein Eindruck ist das die RTC keine kontinuierliche Zeit liefert, oder? getCounter() resetet die ovrfl Variable.
Wie können wir eine kontinuierliche Zeit bekommen, auch wenn das Gerät mit RTC läuft (32kHz Quarz an XTAL, 8MHz RC nur wenn das Gerät wach ist) Wird die sysclock jetzt schon auch für diesen Fall von der RTC korrigiert? Falls ja, wie genau kann man die kontinuierliche Zeit bekommen?

Hoffe es ist einigermaßen verständlich..
Vielen Dank,

p.s. Das Update-Intervall soll dafür auch noch on-the-fly umprogrammiert werden, um nach Ende der Totzeit immer den aktuellen Status zu übertragen, nur das "Retrigger" innerhalb der Totzeit soll nicht senden.

[papa]

Ihr macht einfach einen Alarm, der eine interne Variable hat, ob neue Events gesendet werden sollen. Dieser wird mit dem Timeout in die RTC gehangen und bei neuen Events abgefragt. So macht es in etwas auch der Motion-Channel.

Code Auswählen Erweitern

class SendePause : public Alarm {
private:
  bool pause;
public:
  SendePause () : Aöarm(0), pause(false) { }
  virtual void trigger (AlarmClock& clock) { pause=false; }
  bool canSend (AlarmClock& clock,uint16_t timeout) {
    if( pause == false ) {
      pause = true;
      set(timeout); // in seconds for rtc or use seconds2ticks for sysclock
      clock.add(*this);
      return true;
    }
    return false;
}
}
Wenn dann der Motionsensor ein Event liefert einfach

Code Auswählen Erweitern


// defien the object somewhere
SendePause sendepause;
......
  if( sendepause.canSend(rtc,120) == true ) {
    // send message here
  }

Alles nur hier schnell eingetippert. Wird wahrscheinlich nicht sofort durch den Compiler gehen. Aber die Idee sollte erkennbar sein.

[papa]

Alternativ könnte der Alarm aber auch einfach den Interrupt abschalten und im trigger() wieder anschalten. Damit würde dann keine Energie für die Interruptverarbeitung, die ja eh ignoriert wird, verschwendet.

[Tom Major]

Hallo papa,
vielen Dank für die Idee mit der class SendePause, ich verstehe das Konzept, aber selber drauf gekommen wäre ich nicht.

Das heißt die RTC kann quasi viele verschiedene virtual void trigger() bedienen, nicht nur einen. Weil SendePause von Alarm abgeleitet wird nehme ich an.

In deinem Bsp. wacht der uC also völlig unabhängig vom Haupt-SendeIntervall des Sensors auf (ich weiß, eigentlich weckt die RTC sowieso jede Sekunde), setzt still und leise pause zurück (oder enabled den pin INT) und geht wieder in den sleep, korrekt?

[papa]

Hallo papa,
vielen Dank für die Idee mit der class SendePause, ich verstehe das Konzept, aber selber drauf gekommen wäre ich nicht.

Das heißt die RTC kann quasi viele verschiedene virtual void trigger() bedienen, nicht nur einen. Weil SendePause von Alarm abgeleitet wird nehme ich an.

Genau. Die RTC verwaltet eine Liste mit auszulösenden Alarmen und ruft die trigger() entsprechend auf. Für "kleien" Sachen, kann auch noch async(true) im Alarm gesetzt werden. Dann erfolgt sie Ausführung direkt im Timer-Interupt. Sonst wird es im Main-Loop durch rtc.runready() synchron zur Anwendung ausgeführt. Die sysclock arbeitet genau gleich. Dadurch kann man recht einfach die CPU für die maximal mögliche Zeit schlafen legen, da ja der nächste zu berbeitende Alarm bekannt ist.

In deinem Bsp. wacht der uC also völlig unabhängig vom Haupt-SendeIntervall des Sensors auf (ich weiß, eigentlich weckt die RTC sowieso jede Sekunde), setzt still und leise pause zurück (oder enabled den pin INT) und geht wieder in den sleep, korrekt?

Genau.

[Tom Major]

Alles klar, sehr schönes Konzept, danke für die Erläuterungen 
Werde ich die nächsten Tage mal für einen ersten Test bei fhemfreund implementieren.

[gloob]

Kann es sein, dass die Werte für die Frequenzanpassung jetzt nicht mehr durch einen LongPress Reset überschrieben werden? Irgendwo hatte ich da letztens was zu gelesen.

Ich nutze den Master Stand von heute.

[papa]

Kann es sein, dass die Werte für die Frequenzanpassung jetzt nicht mehr durch einen LongPress Reset überschrieben werden? Irgendwo hatte ich da letztens was zu gelesen.

Ich nutze den Master Stand von heute.

Meiner Meinung nach sollte das auch bisher nicht passieren. Aber ich hatte noch keine Zeit, das nochmal zu debuggen. Der RESET löscht eigentlich nur die ersten 4 Byte im EEPROM. Damit stimmt beim nächsten Neustart die Checksumme nicht mehr und der Speicher wird neu eingerichtet. Dabei werden die ersten 4 Byte mit der Checksumme beschrieben und dann ab Byte 32 die Gerätedaten/ChannelListen. Der Bereich dazwischen sollte eigentlich nicht geändert werden. Und ganau da wird die Frequenz abgelegt.

[gloob]

Okay dann funktioniert es mit der Frequenz wie gewünscht und ich kann den beschriebenen Fehler aus dem Nachbar Thread nicht nachvollziehen. Vielen Dank für die Erklärung.

[CatWeazle]

Hi Leutz,

also die AskSin++ Library finde ich schon sehr interessant.
Ich habe den Chinetzen schon mal die HB-UNI-SEN-BATT zur Fertigung in Auftrag gegeben.

In Eagle habe ich den ersten Entwurf für das gleiche in klein (35x45 mm) und auch ohne SMD aber mit einer CR2450 als Stromversorgung.

Jetzt habe ich die 82 Seiten dieses Beitrags überflogen und hier und da etwas über die Versorgungsspannung gefunden.
Was ich aber nicht gelesen, oder überlesen habe, wie kommt es zu dem Bat-Status Reading?
Braucht es noch einen Spannungsteiler an einem analogen Eingang oder erfasst die AskSin++ Library die Werte intern am AVR ?

[PeMue]

Was ich aber nicht gelesen, oder überlesen habe, wie kommt es zu dem Bat-Status Reading?
Braucht es noch einen Spannungsteiler an einem analogen Eingang oder erfasst die AskSin++ Library die Werte intern am AVR?

Tom hat das hier https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#messung-der-batteriespannung super dargestellt, die Schaltung die Messung ermöglichen und die Software natürlich auch. Sprich die ersten zwei sind Deine angesprochenen Varianten, die dritte halte ich jedoch für die Beste.

Gruß Peter

[CatWeazle]

Hallo Peter,
danke für den Link.
Ja die dritte Lösung ist schon raffiniert, eine Last über einen FET zu schalten und dann messen, echt clever!

Ich hatte schon überlegt, das CC1101 Modul über einen FET zwischen den Messungen (Temp, Hum, Druck) abzuschalten.
Aber das habe ich auch schnell wieder verworfen, aus mehreren Gründen.

Okay, ich werde mir das ganze nochmal durch den Kopf gehen lassen.
Wenn die Chinesen die HB-UNI-SEN-BATT geliefert haben schau ich mir den  Spannungsverlauf mal eine Zeit lang an. (zu Fuß)

By The Way, die aktuellen Gerber Files der HB-UNI-SEN-BATT haben den Fehler das drei Leitungen des CC1101 durch die Masse laufen nicht mehr!

Fürs Erste, besten Dank.

[vbs]

Ich versuche gerade etwas warm zu werden mit AskSin++ und hab mir einen von Tom's Sensoren gebaut: https://github.com/TomMajor/SmartHome/tree/master/PCB/Sensor_PLHT

Tut auch erstmal etwas, aber ich hab hier und da noch Sachen, die mir komisch vorkommen. Ich kann aber nicht genau sagen, was jetzt Ursache bzw. Wirkung ist bzw. was eigenständige Probleme sind.

Also vielleicht darf ich mal einfach zu einem Verhalten fragen:
Anlernen hat nach einigen Versuchen dann geklappt. Ich hab ein Gerät in FHEM und ich empfange auch regelmäßig (Dummy-)Werte vom Sensor. Komisch ist: Wenn ich zB "getConfig" mache, dann bekomme ich "Pending Message", die jedoch nie verarbeitet werden. Ich hätte gedacht, dass (ohne Burst) diese Messages bei der nächsten Kontaktaufnahem, also beim nächsten Senden, abgearbeitet werden. Ist aber nicht der Fall bei mir.
Erst wenn ich den Taster am Gerät drücke, dann wird offenbar genau eine Pending-Nachricht verarbeitet. Ich muss also mehrfalls drücken, um die Queue zu leeren. Kenne ich eigentlich bei HM-Sensoren anders. Ist das ein normales Verhalten oder geht da etwas schief?

Ein List vom Device:

Code Auswählen Erweitern


Historie löschen
Internals:
   CFGFN     
   DEF        A5A502
   FUUID      5ca3923e-f33f-af31-f00a-6d4e5662fbab03bf
   IODev      sys_culHm
   LASTInputDev sys_culHm
   MSGCNT     42
   NAME       HM_A5A502
   NOTIFYDEV  global
   NR         39001
   STATE      T: 18.8 P: 1088.0 H: 88 B: 88000 I: 0
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:1F - t:70 s:A5A502 d:<VCCUID> 00BC2A8058000157C0000D36
   protLastRcv 2019-04-02 23:09:46
   protRcv    43 last_at:2019-04-02 23:09:46
   protResnd  4 last_at:2019-04-02 21:26:58
   protSnd    17 last_at:2019-04-02 21:26:55
   protState  CMDs_pending
   rssi_at_sys_culHm cnt:43 min:-73 max:-62 avg:-67.83 lst:-63
   rssi_sys_culHm cnt:3 min:-76 max:-74 avg:-75 lst:-74
   sys_culHm_MSGCNT 42
   sys_culHm_RAWMSG 0501003F1F8470A5A502<VCCUID>00BC2A8058000157C0000D36
   sys_culHm_RSSI -63
   sys_culHm_TIME 2019-04-02 23:09:46
   READINGS:
     2019-04-02 23:28:22   Activity        dead
     2019-04-02 18:48:14   CommandAccepted yes
     2019-04-02 18:48:22   D-firmware      1.2
     2019-04-02 18:48:22   D-serialNr      UNISENS001
     2019-04-02 18:48:21   PairedTo        <VCCUID>
     2019-04-02 18:48:19   R-pairCentral   <VCCUID>
     2019-04-02 18:48:21   RegL_00.         00:00 05:40 0A:F1 0B:55 0C:44 12:15 14:06 20:02 21:58 22:00 23:00
     2019-04-02 23:09:46   batVoltage      3.38
     2019-04-02 23:09:46   battery         ok
     2019-04-02 23:09:46   brightness      88000
     2019-04-02 23:09:46   digitalInput    0
     2019-04-02 23:09:46   humidity        88
     2019-04-02 18:48:16   powerOn         2019-04-02 18:48:16
     2019-04-02 23:09:46   pressure        1088.0
     2019-04-02 21:26:55   recentStateType info
     2019-04-02 23:09:46   state           T: 18.8 P: 1088.0 H: 88 B: 88000 I: 0
     2019-04-02 23:09:46   temperature     18.8
   cmdStack:
   helper:
     HM_CMDNR   31
     PONtest    0
     cSnd       01<VCCUID>A5A5020103,01<VCCUID>A5A502010E
     mId        F103
     peerFriend
     peerIDsRaw ,00000000
     peerOpt    p:UniSensor1
     regLst     0
     rxType     156
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +A5A502,02,00,00
       nextSend   1554239386.66568
       prefIO     
       rxt        2
       vccu       
       p:
         A5A502
         00
         00
         00
     mRssi:
       mNo        1F
       io:
         sys_culHm:
           -59
           -59
     prt:
       bErr       0
       sProc      2
       sleeping   0
       wuReSent   2
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       at_sys_culHm:
         avg        -67.8372093023255
         cnt        43
         lst        -63
         max        -62
         min        -73
       sys_culHm:
         avg        -75
         cnt        3
         lst        -74
         max        -74
         min        -76
     shadowReg:
     tmpl:
Attributes:
   IODev      sys_culHm
   IOgrp      VCCU:sys_culHm
   actCycle   000:10
   actStatus  dead
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   model      HB-UNI-Sensor1
   peerIDs    00000000,
   room       CUL_HM
   serialNr   UNISENS001
   subType    UniSensor1

Vermtl. anderes Problem aber mag auch zusammen hängen: Ich bekomme regelmäßig (ich glaube auch beim Drücken) diese Warning im Log:

Code Auswählen Erweitern

2019.04.02 18:48:21.315 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.02 18:48:21.315 1: stacktrace:
2019.04.02 18:48:21.315 1:     main::__ANON__                      called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.02 18:48:21.317 1:     main::CUL_HM_getRegFromStore        called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.02 18:48:21.317 1:     main::CUL_HM_updtRegDisp            called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.02 18:48:21.317 1:     main::CUL_HM_parseCommon            called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.02 18:48:21.317 1:     main::CUL_HM_Parse                  called by fhem.pl (3893)
2019.04.02 18:48:21.317 1:     main::Dispatch                      called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.02 18:48:21.317 1:     main::HMUARTLGW_Parse               called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.02 18:48:21.317 1:     main::HMUARTLGW_Read                called by fhem.pl (3697)
2019.04.02 18:48:21.317 1:     main::CallFn                        called by fhem.pl (744)

("FHEM/HMConfig_UniSensor1.pm" hab ich installiert)