AskSin++ Library

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

Vorheriges Thema - Nächstes Thema

jp112sdl

Zitat von: papa am 20 Februar 2018, 17:00:09
Du kannst natürlich auch andere Pins verwenden.
...wobei ich dann aber wieder die gesamte Klasse neu definieren muss?
Oder gibt eine "Kurzversion", wenn ich lediglich andere Pins nutzen möchte?

Und noch mal zum Energiesparen...

Der Unterschied zwischen <Sleep> und <SleepRTC>, also zwischen Verwendung eines 8MHz oder 32.786kHz Taktes, schlägt sich offensichtlich ja nicht nur in der Ganggenauigkeit nieder, sondern auch im Stromverbrauch. Ich hab mich derweil etwas unter diesem Link belesen:
https://www.mikrocontroller.net/articles/Sleep_Mode#.C3.9Cberblick_.C3.BCber_alle_Sleep_Modes_der_AVRs

Welcher Sleep Mode greift denn bei <Sleep>? Bei <SleepRTC> ist es dann Power Save?

Gibt es praktische Erfahrungs- / Messwerte der Ruheströme zwischen den beiden Sleep-Modes?

Wenn wir dich weiter so löchern, haben wir die Doku so schon bald zusammen ;)

Danke für deine Geduld und ausführlichen Erklärungen!

papa

Zitat von: jp112sdl am 20 Februar 2018, 17:25:39
...wobei ich dann aber wieder die gesamte Klasse neu definieren muss?
Oder gibt eine "Kurzversion", wenn ich lediglich andere Pins nutzen möchte?

Die Pins sind Template-Argumente. Siehe auch BatterySensor.h

typedef AskSin<LedType,BatterySensorUni<SENSPIN,ACTIVATIONPIN>,RadioType> HalType;

Zitat von: jp112sdl am 20 Februar 2018, 17:25:39
Und noch mal zum Energiesparen...

Der Unterschied zwischen <Sleep> und <SleepRTC>, also zwischen Verwendung eines 8MHz oder 32.786kHz Taktes, schlägt sich offensichtlich ja nicht nur in der Ganggenauigkeit nieder, sondern auch im Stromverbrauch. Ich hab mich derweil etwas unter diesem Link belesen:
https://www.mikrocontroller.net/articles/Sleep_Mode#.C3.9Cberblick_.C3.BCber_alle_Sleep_Modes_der_AVRs

Welcher Sleep Mode greift denn bei <Sleep>? Bei <SleepRTC> ist es dann Power Save?

Gibt es praktische Erfahrungs- / Messwerte der Ruheströme zwischen den beiden Sleep-Modes?

Ist in Activity.h implementiert:

Sleep nutzt Power Down
SleepRTC nutzt Extended Standby - da der Timer2 an bleiben muss.

Je mehr an bleibt, um so mehr Power wird benötigt. Hängt natürlich auch von der restlichen Beschaltung ab. Da wird man immer das entsprechende Desgin untersuchen müssen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

#662
ZitatNaja - nicht ganz. Du musst eine neue Klasse vom ThreeStateChannel ableiten und dort die trigger Methode überschreiben. Dann kommt diese neue Channelklasse in das ThreeStateDevice-Template.
Ok, probiere ich die nächsten Tage aus wenn mein CC1101 kommt, ich werde berichten - oder vorher weiter nerven falls ich es mit der Ableitung von ThreeStateChannel / trigger nicht hinbekomme.

ZitatGibt es praktische Erfahrungs- / Messwerte der Ruheströme zwischen den beiden Sleep-Modes?
Ich hatte vor einigen Wochen einen Wassermelder mit ATmega328P und RFM69 als Prototyp designed, den wollte ich an meinen JeeLink anbinden.
Da ich parallel die ccu2 auf RPi laufen habe und kürzlich die HM Selbstbau Sensoren sowie papas AskSin++ entdeckt habe werde ich jetzt erstmal den Wassermelder a la HM-SEC-WDS an ccu2 testen.
Mit meinem Prototyp ATmega328P und RFM69 erreiche ich bei 2,6V (2x NiMH) jedenfalls traumhafte 4 uA im Sleep (run clock 1MHz RC OSC, WD enabled, BOD disabled, RFM69 im sleep).
Mal sehen wie sich da der HM-SEC-WDS Nachbau schlägt..
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Wzut

@papa, jetzt hast schon so viel zum Thema Batterie verraten, dann kannst du bestimmt auch noch was zur untergegangen Frage im FensterDrehgriff Thread sagen :
Wird der Batterie Status ok,low,critical jedesmal neu ermittelt ohne Rücksicht auf den zuletzt gemeldeten Wert ?
Die Frage ist eigentlich zuerst im Batterie Monitoring Thread aufgetaucht, die User die HM schon länger einsetzen sind der Meinung das HM Geräte ein einmal erkanntes low/critical  erst wieder zurücksetzen wenn das Gerät spannungslos gemacht wurde, d.h. eigentlich nur wenn die Batterien getauscht wurden (IMHO machen das die LaCrosse Sensoren auch so).
Mein erster FensterDrehgriff Sensor zeigte aber ein Verhalten wie es eigentlich sonst nur typisch für MAX! Geräte ist. D.h. es wurde mal low gemeldet, dann wieder etliche Male ok und ab und an wieder low.
Ich selbst habe HM noch nicht lange genug im Einsatz um das Verhalten mit Original HM Geräten vergleichen zu können. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

papa

Zitat von: Wzut am 21 Februar 2018, 09:35:26
@papa, jetzt hast schon so viel zum Thema Batterie verraten, dann kannst du bestimmt auch noch was zur untergegangen Frage im FensterDrehgriff Thread sagen :
Wird der Batterie Status ok,low,critical jedesmal neu ermittelt ohne Rücksicht auf den zuletzt gemeldeten Wert ?
Die Frage ist eigentlich zuerst im Batterie Monitoring Thread aufgetaucht, die User die HM schon länger einsetzen sind der Meinung das HM Geräte ein einmal erkanntes low/critical  erst wieder zurücksetzen wenn das Gerät spannungslos gemacht wurde, d.h. eigentlich nur wenn die Batterien getauscht wurden (IMHO machen das die LaCrosse Sensoren auch so).
Mein erster FensterDrehgriff Sensor zeigte aber ein Verhalten wie es eigentlich sonst nur typisch für MAX! Geräte ist. D.h. es wurde mal low gemeldet, dann wieder etliche Male ok und ab und an wieder low.
Ich selbst habe HM noch nicht lange genug im Einsatz um das Verhalten mit Original HM Geräten vergleichen zu können.

Das Handling ist derzeit sehr einfach. Es wird in regelmäßigen Abständen gemessen und der gemessene Wert abgespeichert. Wenn der Batteriestatus abgefragt wird, wird der gemessene Wert mit dem Low- bzw. Critical-Wert verglichen. Deshalb kann es auch zu dem beschriebenen Verhalten kommen, dass Low und Ok sich abwechseln. Man könnte sich auch merken, wenn man einmal Low gemeldet hat und dann immer Low melden. Der Batteriewechsel/Neustart würde das dann zurücksetzen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

#665
Hallo papa,

Zitat von: papa am 20 Februar 2018, 16:49:23
Naja - nicht ganz. Du musst eine neue Klasse vom ThreeStateChannel ableiten und dort die trigger Methode überschreiben. Dann kommt diese neue Channelklasse in das ThreeStateDevice-Template.

Mit dem Ableiten der neue Klasse komme ich ohne Hilfe nicht klar. So in etwa?
(Das Ziel war eigenen Code in trigger() generieren zu können).

DEFREGISTER(Reg0,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX)
...

DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTFILTERTIME,CREG_TRANSMITTRYMAX)
...

class MyThreeStateChannel : public ThreeStateChannel <???> {

  void trigger (__attribute__ ((unused)) AlarmClock& clock)  {
    // my custom trigger stuff here
  }
}

typedef MyThreeStateChannel<HalType,WDSList0,WDSList1,DefList4,PEERS_PER_CHANNEL> ChannelType;
typedef ThreeStateDevice<HalType,ChannelType,1,WDSList0> DevType;


Grosses Rätsel public ThreeStateChannel <???>, was genau sind die Parameter in spitzer Klammer? Und wie bekomme ich raus welche davon ThreeStateChannel wirklich benötigt werden?


Danke,
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

Du brauchst die Template-Argumente doch nur durchreichen.


template <class HALTYPE,class List0Type,class List1Type,class List4Type,int PEERCOUNT>
class MyThreeStateChannel : public ThreeStateChannel<HALTYPE,List0Type,List1Type,List4Type,PEERCOUNT> {
public:
  MyThreeStateChannel () {}
  virtual ~MyThreeStateChannel () {}

  virtual void trigger (AlarmClock& clock) {
    // do your magic here
    // we simple call the super class
    ThreeStateChannel<HALTYPE,List0Type,List1Type,List4Type,PEERCOUNT>::trigger(clock);
  }
};

typedef MyThreeStateChannel<HalType,WDSList0,WDSList1,DefList4,PEERS_PER_CHANNEL> ChannelType;
typedef ThreeStateDevice<HalType,ChannelType,1,WDSList0> DevType;
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Wzut

Zitat von: papa am 21 Februar 2018, 11:56:33
Man könnte sich auch merken, wenn man einmal Low gemeldet hat und dann immer Low melden. Der Batteriewechsel/Neustart würde das dann zurücksetzen.
Mir persönlich ist das relativ wurscht, ich kann gut mit der heutigen Version leben. Mir ging es in erster Linie erst einmal "nur" um die Klärung des bestehendes Sachrverhalts. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tom Major

Zitat von: papa am 22 Februar 2018, 08:19:42
Du brauchst die Template-Argumente doch nur durchreichen.

Danke, mir war da nicht klar. Diese template Klassen sehen für mich total ungewohnt aus.
Wenn ich jetzt die originale trigger() Funktion aus ThreeStateChannel in meine neue MyThreeStateChannel kopiere, für das message handling, kommen eine Menge Fehler, der erste z.B. hier
uint8_t newstate = sender.state;
sender ist in MyThreeStateChannel nicht bekannt. Gibt es dafür einfache Abhilfe? Sorry wenn das eine blöde Frage ist.

Ansonsten könnte ich natürlich alternativ ThreeState.h kopieren und dort meinen trigger code direkt einfügen, dann verzichte ich auf das Konzept mit dem Ableiten, ist nicht so elegant, wäre aber wahrscheinlich einfacher zum Laufen zu bekommen.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

Die Membervariablen sind all private. die müsste man dann protected machen, damit die abgeleutete Klasse darauf zugreifen kann. Das beste wäre wahrscheinlich, das trigger() im ThreeStateChannel nochmal aufzuteilen und das Ermitteln der Position auszulagern.
Kopieren und ändern geht natürlich auch erst mal. Der Name muss aber trotzdem geändert werden.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

#670
Zitat von: papa am 22 Februar 2018, 20:27:58
Die Membervariablen sind all private. die müsste man dann protected machen, damit die abgeleutete Klasse darauf zugreifen kann. Das beste wäre wahrscheinlich, das trigger() im ThreeStateChannel nochmal aufzuteilen und das Ermitteln der Position auszulagern.
Kopieren und ändern geht natürlich auch erst mal. Der Name muss aber trotzdem geändert werden.
Sehr gute Idee den trigger() nochmal aufzuteilen, so wäre man viel flexibler. Bei der Kopie gibt es immer die Gefahr dass man out of sync zum Repo kommt.
Akzeptierst Du pull requests? Dann würde ich das mit der Aufteilung mal versuchen.

Andere Frage, wenn man vorhat ein Device nur mit der Zentrale zu pairen und nie direkt mit anderen devices zu peeren, kann man dann PEERS_PER_CHANNEL auf 0 setzen um etwas flash zu sparen?

Seltsam: HM-SEC-WDS.ino
das es bei 2 hochgeht:

PEERS_PER_CHANNEL 8: 19382 bytes flash
PEERS_PER_CHANNEL 6: 19382 bytes flash
PEERS_PER_CHANNEL 4: 19382 bytes flash
PEERS_PER_CHANNEL 2: 19466 bytes flash
PEERS_PER_CHANNEL 0: 17756 bytes flash

Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

Zitat von: Tom Major am 23 Februar 2018, 00:17:59
Sehr gute Idee den trigger() nochmal aufzuteilen, so wäre man viel flexibler. Bei der Kopie gibt es immer die Gefahr dass man out of sync zum Repo kommt.
Akzeptierst Du pull requests? Dann würde ich das mit der Aufteilung mal versuchen.

Im Prinzip schon. Ich würde das ganze gern über ein weiteres Template-Argument machen. So wie zum Beispiel der MotionChannel den LightSensor einbindet. Sonst geht es nur über eine virtuelle Moethde. Die kostet aber Speicher und außerdem brauchen die 2 Pinvariablen dann auch nicht mehr in der Klasse sein.

Zitat von: Tom Major am 23 Februar 2018, 00:17:59
Andere Frage, wenn man vorhat ein Device nur mit der Zentrale zu pairen und nie direkt mit anderen devices zu peeren, kann man dann PEERS_PER_CHANNEL auf 0 setzen um etwas flash zu sparen?

Flash wirst Du damit nicht sparen. Die Peer-Listen kommen ins EEProm.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

andirs

Hallo, wie bekomme ich denn ein erstelltes Gerät mit dem aktuellen aktuellen Master-branch angelernt?
Beim kurzen Drücken der Configtaste gibt der ser. Monitor folgendes aus:

debounce
pressed
longpressed
longpressed
RESET
AskSin++ V2.1.4 (Feb 25 2018 14:02:34)
Address Space: 32 - 70
00000000
Init Storage: CAFE028E
CC init1
CC Version: 14
- ready


Auf längere Tastendrücke reagiert es garnicht.

Danke  :)

jp112sdl

Zitat von: andirs am 25 Februar 2018, 14:10:45
Hallo, wie bekomme ich denn ein erstelltes Gerät mit dem aktuellen aktuellen Master-branch angelernt?
Beim kurzen Drücken der Configtaste gibt der ser. Monitor folgendes aus:

debounce
pressed
longpressed
longpressed
RESET
AskSin++ V2.1.4 (Feb 25 2018 14:02:34)
Address Space: 32 - 70
00000000
Init Storage: CAFE028E
CC init1
CC Version: 14
- ready


Auf längere Tastendrücke reagiert es garnicht.

Danke  :)

Nutzt du nen 16 MHz Pro Mini?


Gesendet von iPhone mit Tapatalk

andirs

Sorry hätte mehr infos geben können:

Pro mini 8Mhz mit CC1101 Funke