AskSin++ Library

[Tom Major]

Hallo papa,
ich habe auf Anregung von jp112sdl mein UniSensor Beispiel so überarbeitet dass das Sendeintervall von RaspberryMatic oder CCU aus konfiguriert werden kann.
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino

Ich möchte ein 16bit Register in List1 verwenden, um einen großen Bereich (ohne Skalierung) dafür zu haben.
Alle Regs in List0 und List1 sind 8bit oder?
Ich habe refRunningTimeTopButton() zweck­ent­frem­det weil das eines der wenigen vordef. ist wo ich einen 16bit Wert schreiben kann. Solange der Sketch und das xml file für ein Eigenbaugerät dafür zusammenpassen ist die Zweckentfremdung ok, oder?

Könnte man auch eine public 16bit readRegister/writeRegister für List1 einführen um solche Fälle besser abzubilden oder gibt es da schon einen anderen Mechanismus?
Und wo wird eigentlich die Größe von List1 für ein Device festgelegt?

Danke,

[papa]

Du kannst Dir auch ganz einfach eigene Register definieren - hier z.B. 16bit an Offset 0xe0.

Code Auswählen Erweitern


DEFREGISTER(Reg1, 0xe0, 0xe1)
class SensorList1 : public RegList1<Reg1> {
  public:
    SensorList1 (uint16_t addr) : RegList1<Reg1>(addr) {}

   bool myValue (uint16_t value) const {
    return this->writeRegister(0xe0, (value >> 8) & 0xff) && this->writeRegister(0xe1, value & 0xff);
  }
  uint16_t myValue () const {
    return (this->readRegister(0xe0,0) << 8) + this->readRegister(0xe1,0);
  }
    void defaults () {
      clear();
      myValue(60);
    }
};


Die Größe der Liste wird durch das Macro DEFREGISTER mit erzeugt. Das obige wird zu:

Code Auswählen Erweitern


const uint8_t __Reg1Register__[(sizeof((int[]){0xe0,0xe1})/sizeof(int))]  = {0xe0,0xe1};
  class Reg1 {
  public:
  static uint8_t getOffset(uint8_t reg) { return AskSinRegister::getOffset(reg,__Reg1Register__,sizeof(__Reg1Register__)); }
  static uint8_t getRegister(uint8_t offset) { return AskSinRegister::getRegister(offset,__Reg1Register__,sizeof(__Reg1Register__)); }
  static uint8_t getSize () { return sizeof(__Reg1Register__); }
};


Die erzeugte Klasse Reg1 beinhaltet die Umrechnung Register -> Offset und umgekehrt. Außerdem wird getSize() definiert und gibt die Anzahl der Byte zurück.

[Tom Major]

Du kannst Dir auch ganz einfach eigene Register definieren - hier z.B. 16bit an Offset 0xe0.

Ok, habe das verstanden und probiere das morgen bei meinem Sketch aus, um die Hilfslösung mit refRunningTimeTopButton damit zu ersetzen.
Danke schon mal für den Hinweis und den Beispielcode.

[hailfinger]

Ist eine Portierung auf EFM32G200F64 (SiLabs Energy Micro EFM32 Family) geplant?
Von den Hardwaredaten (ARM Cortex-M3, 64kB Flash, 16 kB RAM) sollte das theoretisch möglich sein.
Dieser Mikrocontroller ist in den aktuellen Hm-Sec-SCo Tür-/Fensterkontakt ARR verbaut (die Beschriftung auf dem Mikrocontroller lautet EFM32 G200F64).

Ich würde gerne langfristig den HM-Sec-SCo um einen Zusatzsensor erweitern, da die Plattform aus Bastlersicht sehr praktisch ist (AAA-Batterie, kompakte Bauform). Mit AskSin++-Unterstützung wäre das eine gangbare Lösung.

[papa]

Ist eine Portierung auf EFM32G200F64 (SiLabs Energy Micro EFM32 Family) geplant?
Von den Hardwaredaten (ARM Cortex-M3, 64kB Flash, 16 kB RAM) sollte das theoretisch möglich sein.
Dieser Mikrocontroller ist in den aktuellen Hm-Sec-SCo Tür-/Fensterkontakt ARR verbaut (die Beschriftung auf dem Mikrocontroller lautet EFM32 G200F64).

Ich würde gerne langfristig den HM-Sec-SCo um einen Zusatzsensor erweitern, da die Plattform aus Bastlersicht sehr praktisch ist (AAA-Batterie, kompakte Bauform). Mit AskSin++-Unterstützung wäre das eine gangbare Lösung.

Soweit ich das weiss, gibt es keine Arduino-Umgebung für den EFM32.

[Tom Major]

Habe den Code für eigene Register Def. getestet und funktioniert einwandfrei, damit ist z.B. ein 16bit Register zum Konfigurieren des Sendeintervalls des Universalsensors möglich.
https://github.com/TomMajor/AskSinPP_Examples

Außerdem herausgefunden durch Tests, sicherlich dem Entwickler dieser genialen Lib klar, mir war es noch unbekannt, vielleicht hilft es noch jemanden:

mit BIDI als 4. Param bei Message::init()
- Ack wird von der Zentrale erwartet und gesendet
- LazyConfig funktioniert, d.h. eine anstehende Konf. Änderung von der Zentrale wird nach dem nächsten Senden des Sensors übernommen
- mehr Funk und Stromverbrauch

mit BCAST als 4. Param bei Message::init()
- Ack wird nicht erwartet
- LazyConfig funktioniert nicht, d.h. eine anstehende Konf.Änderung von der Zentrale muss durch den Config Button am Sensor übernommen werden!
- optimal für Batterielebensdauer

[Wzut]

Deswegen auch das Angebot an LuBeDa, den FHEM Perl code HMConfig_SenTHPL.pm für das neue Unisensor Demo anzupassen falls er das dann in FHEM testen kann...

@Tom Major , ich habe gerade deinen HB_UNI-Sensor1 auf dem Steckbrett laufen, ich habe lediglich deine Device Model F301 in F101 geändert damit es mit  der HMConfig_SenTHPL.pm zusammen passt. An Readings bekomme ich jetzt schon mal

Code Auswählen Erweitern


2018-03-18 15:51:25   batVoltage      0.00
2018-03-18 15:51:25   battery         ok
2018-03-18 15:51:25   humidity        4
2018-03-18 15:51:25   pressure        211.4
2018-03-18 15:51:25   state           T: 19.2 H: 4 P: 211.4
2018-03-18 15:51:25   temperature     19.2
Sensoren sind keine z.Z. angeschlossen, lasse das mit deinen  Dummys laufen. BCAST auf ich auf BIDI geändert, aber LazyConfig scheint doch nicht zu gehen.
Hatte versucht das Register lowBatLimitTHPL so zu ändern, die Änderungen wurde aber nicht beim Empfang von Sensordaten übertragen sondern erst durch drücken des Config Buttons.

[papa]

Hatte versucht das Register lowBatLimitTHPL so zu ändern, die Änderungen wurde aber nicht beim Empfang von Sensordaten übertragen sondern erst durch drücken des Config Buttons.

FHEM muss für das Device auch LazyConfig kennen, sonst geht das nicht.
Außerdem sollte in der Message das WKMEUP Flag gesetzt sein, damit wird signalisiert, dass das Gerät bereit ist, weitere Nachrichten zu empfangen.

[papa]

Habe den Code für eigene Register Def. getestet und funktioniert einwandfrei, damit ist z.B. ein 16bit Register zum Konfigurieren des Sendeintervalls des Universalsensors möglich.
https://github.com/TomMajor/AskSinPP_Examples

Außerdem herausgefunden durch Tests, sicherlich dem Entwickler dieser genialen Lib klar, mir war es noch unbekannt, vielleicht hilft es noch jemanden:

mit BIDI als 4. Param bei Message::init()
- Ack wird von der Zentrale erwartet und gesendet
- LazyConfig funktioniert, d.h. eine anstehende Konf. Änderung von der Zentrale wird nach dem nächsten Senden des Sensors übernommen
- mehr Funk und Stromverbrauch

mit BCAST als 4. Param bei Message::init()
- Ack wird nicht erwartet
- LazyConfig funktioniert nicht, d.h. eine anstehende Konf.Änderung von der Zentrale muss durch den Config Button am Sensor übernommen werden!
- optimal für Batterielebensdauer

Naja - fast. Soweit ich das verstehe, funktioniert es so:

BIDI - fordert den Empfänger auf ein Ack zu schicken. Das wird auch zwingend für AES-Handling gebraucht.
BCAST - signalisiert eine Broadcast-Message. Das wird z.B. verwendet, wenn mehrere Peers vor einen Sensor existieren. Es wird dann an einen Peer gesndet und zusätzlich das BCAST-Flag gesetzt. So dass sich alle die Nachrricht ansehen. Ein Ack macht dann natürlich keinen Sinn - es ist ja nicht klar, wer das senden soll.
WKMEUP - wird für LazyConfig verwendet. Ist es in einer Message gesetzt, so weiss die Zentrale, dass das Geräte noch kurz auf weitere Nachrichten wartet. Die Lib setzt diese Flag für die StatusInfo-Message automatisch. Außerdem bleibt nach einer Kommunikation der Empfang grundsätzlich für 500ms angeschalten.

[Tom Major]

@Tom Major , ich habe gerade deinen HB_UNI-Sensor1 auf dem Steckbrett laufen, ich habe lediglich deine Device Model F301 in F101 geändert damit es mit  der HMConfig_SenTHPL.pm zusammen passt. An Readings bekomme ich jetzt schon mal

Sensoren sind keine z.Z. angeschlossen, lasse das mit deinen  Dummys laufen. BCAST auf ich auf BIDI geändert, aber LazyConfig scheint doch nicht zu gehen.
Hatte versucht das Register lowBatLimitTHPL so zu ändern, die Änderungen wurde aber nicht beim Empfang von Sensordaten übertragen sondern erst durch drücken des Config Buttons.

Hmm, wie weiter oben schon geschrieben, ich habe die Sache bei mir an RaspberryMatic am Laufen, die ist zur Zeit noch nicht mit FHEM verbunden.

Ich kann nur sagen, dass bei meinem Projekt - mit BIDI - sich Sendeintervall, lowbatt und Anzahl der Sendeversuche einwandfrei über die Zentrale konfigurieren lassen, beim Ändern dort wird eine Servicemeldung erzeugt "Konfiguration anstehend", wenn sich der Sensor das nächste Mal meldet wird diese übernommen.
WKMEUP flag braucht es dafür bei RaspberryMatic bei meinen diversen Tests bisher nicht.

Hast Du mal geschaut ob FHEM diesen Mechanismus einer "anstehenden Konfigurationsänderung" überhaupt unterstützt?

[cactus-online]

Ich komme ja aus der reinen HomeMatic-Welt und finde das mit dem Addon, denn es ist ja nur eine einmalige Installation, nicht weiter schlimm.
Hat auch den Vorteil, dass in der WebUI auch ein passendes Gerätesymbol angezeigt werden.

Hast Du schon mal ein CCU Firmware-Update gemacht ? War die Beschreibungsdatei bzw. das Gerät dann noch da ? Ich  Frage, weil das beim UWS https://wiki.fhem.de/wiki/Universalsensor leider nicht der Fall war und nach jedem CCU Firmware-Update, dann das "add-on" wieder erneut eingespielt werden muss.

[jp112sdl]

Ja, das Addon ist anschließend noch da.
Ggf muss 2x neu gestartet werden nach einem Firmware Update


Gesendet von iPhone mit Tapatalk

[jp112sdl]

Das mit dem 2x neustarten kommt daher, dass bei der Installation des Addons (und das wird auch automatisch nach einem Firmware Update durchgeführt) die Gerätebeschreibungsdateien erst kopiert werden, wenn alle Dienste schon laufen

[Wzut]

FHEM muss für das Device auch LazyConfig kennen, sonst geht das nicht.
Außerdem sollte in der Message das WKMEUP Flag gesetzt sein, damit wird signalisiert, dass das Gerät bereit ist, weitere Nachrichten zu empfangen.

hmm laut https://github.com/kc-GitHub/Wettersensor/tree/master/Contrib/FHEM -> add lazy config option , sollte also für F101 und F102 nichts Neues sein.
BIDI habe auf WKMEUP geändert, leider ohne Erfolg.

Hast Du mal geschaut ob FHEM diesen Mechanismus einer "anstehenden Konfigurationsänderung" überhaupt unterstützt?

Da es bei anderen Geräten aus papas Baukasten geht sollte FHEM das nicht unbekannt sein.  Ist für mich aber nicht tragisch da ich z.Z. dafür keinen Einsatzfall habe,     

[cactus-online]

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

Code Auswählen Erweitern

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

Argh, ich verstehe noch zu wenig von dem Ganzen. Allerdings hätte ich gedacht, dass ich folgendes tun müsste:

Code Auswählen Erweitern


typedef AvrSPI<10,11,12,9> SPIType;        //CS, MOSI, MISO, SCLK

um den üblicherweise verwendeten Pin 13 frei zu bekommen (da hängt auf meinem Pro Mini die BuiltIn LED) und Pin 9 zu verwenden. Leider initialisiert er dann das CC1101 Modul nicht richtig.

Code Auswählen Erweitern

AskSin++ V2.1.3 (Mar 18 2018 18:20:24)
Address Space: 32 - 99
CC init1
Error at 00 expected: 2E read: 00
Error at 02 expected: 06 read: 00
Error at 03 expected: 0D read: 00
Error at 04 expected: E9 read: 00
Error at 05 expected: CA read: 00
Error at 07 expected: 0C read: 00
Error at 0B expected: 06 read: 00
Error at 0D expected: 21 read: 00
Error at 0E expected: 65 read: 00
Error at 0F expected: 6A read: 00
Error at 10 expected: C8 read: 00
Error at 11 expected: 93 read: 00
Error at 12 expected: 03 read: 00
Error at 15 expected: 34 read: 00
Error at 17 expected: 03 read: 00
Error at 18 expected: 18 read: 00
Error at 19 expected: 16 read: 00
Error at 1B expected: 43 read: 00
Error at 21 expected: 56 read: 00
Error at 23 expected: E9 read: 00
Error at 24 expected: 2A read: 00
Error at 25 expected: 1F read: 00
Error at 26 expected: 11 read: 00
Error at 29 expected: 59 read: 00
Error at 2C expected: 81 read: 00
Error at 2D expected: 35 read: 00
Error at 2E expected: 09 read: 00
Error at 3E expected: 03 read: 00
CC Version: 00
Error at 3E expected: C0 read: 00
- ready
Bat: 50


Verwende ich bei gleicher Einstellung im Sketch jedoch wieder Pin 13 geht es

Code Auswählen Erweitern

AskSin++ V2.1.3 (Mar 18 2018 18:24:30)
Address Space: 32 - 99
CC init1
CC Version: 14
- ready
Bat: 50

Ich bin echt ratlos, was mache ich falsch ? Wer kann mir einen kleinen Stups in die richtige Richtung geben ?

lg.