FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: papa am 08 September 2016, 11:11:25

Titel: AskSin++ Library
Beitrag von: papa am 08 September 2016, 11:11:25
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 (https://github.com/pa-pa/AskSinPP)

Anleitungen und fertige Projekte gibt es auf der AskSin++ Webseite (https://asksinpp.de/).

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 (https://github.com/PaulStoffregen/TimerOne)
* PinChangeInt - https://github.com/GreyGnome/PinChangeInt (https://github.com/GreyGnome/PinChangeInt)
* Low-Power - https://github.com/rocketscream/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 (https://github.com/GreyGnome/EnableInterrupt)

Neue Example sind:

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 (https://homematic-forum.de/forum/viewforum.php?f=76).

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

Unter asksinpp.de (https://asksinpp.de/Projekte/) gibt es eine schöne Zusammenstellung von Selbstbauprojekten.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 02 Oktober 2016, 19:49:46
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
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 Oktober 2016, 21:12:45
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
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 03 Oktober 2016, 08:58:58
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

Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Oktober 2016, 10:17:18
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 (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 (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
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 03 Oktober 2016, 10:52:50
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://youtu.be/ahPvSpvzD5o)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Oktober 2016, 22:37:44
Freut mich, dass jetzt alles geht.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 17 Oktober 2016, 17:30:44
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

Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Oktober 2016, 23:07:39
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.

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.

Funktioniert das Schreiben der Register? Wie kann ich das überprüfen?

Natürlich. Von FHEM aus Schreiben und getConfig.

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.

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

bitte
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Oktober 2016, 23:10:13
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.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 17 Oktober 2016, 23:32:07
Zitat
Wenn 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.

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

Zitat
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.

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.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 18 Oktober 2016, 00:01:34
Hallo,
Zitat
Kö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é...

Zitat
Man 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
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Oktober 2016, 08:53:46
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.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 19 Oktober 2016, 20:48:06
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
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 Oktober 2016, 21:07:33
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.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 Oktober 2016, 21:19:51
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.

Du kannst in der trigger() mit number() die Nummer des Channels abfragen und dann halt eben Gas oder Strom machen. Der Timer kann auch im setup() gestartet werden:

void setup(Device* dev,uint8_t number,uint16_t addr) {
  Channel::setup(dev,number,addr);
  tick = seconds2ticks(5*60) * number();  // 5min Channel1 - 10min Channel2
  aclock.add(*this);
}

virtual void trigger (AlarmClock& clock) {
  // reactivate for next measure
  tick = seconds2ticks(5*60) * number();  // 5min Channel1 - 10min Channel2
  clock.add(*this);
  if( number() == 1 ) {
    // do Gas
  }
  else {
    // do Strom
  }
}
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 19 Oktober 2016, 22:36:17
AlarmGas alarmGas = AlarmGas(sdev.channel(0));

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

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.

das wars:
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 44 12 34 00 00 00 00 00 00 00 00 00 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
Gas
<- 10 01 20 53 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 03 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Gas
<- 10 02 20 53 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 04 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 05 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Gas
<- 10 03 20 53 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 06 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Danke

Die Kalibrierung ist notwendig. Der genaue Wert  in % ergibt sich aber erst so nach 2 Minuten Test.
Bei mir sind es am Pro Mini  ca. 11,34%
Man muss aber auch die 8 Sekunden in eine Korrektur von 8192 ms verändern(glaube ich) - gleiches gilt für die anderen Zeiten.


Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 19 Oktober 2016, 22:41:46
noch ein kleines Problem:

Zitat
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.

bekomme im Log einen Fehler, wenn ich den ConfigButton drücke.
Das Lesen/Schreiben der Register scheint als command vorzuliegen, aber es kommt zu folgendem Fehler.

2016.10.19 22:26:29 2: nanoCUL: unknown message ERR:CCA
2016.10.19 22:26:27 2: nanoCUL: unknown message ERR:CCA

in der Übersicht steht
HM_441234 CMDs_pending getConfig clear msgEvents
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 19 Oktober 2016, 23:08:37
habe jetzt folgendes herausgefunden:
(ERR:CCA -> Clear Channel Assessment)

was auch immer das ist

vielleicht hat der Fehler etwas damit zu tun das ich alle 5 Sekunden Gaswerte und alle 3 Sekunden Stromwerte gesendet habe. Damit war vielleicht zu viel Last auf der Leitung.

Jetzt kommt folgendes und das seit schon besser aus:
-> 0A 18 80 02 51 37 49 44 12 34 00
-> 10 19 A0 01 51 37 49 44 12 34 02 04 00 00 00 00 01
<- 1A 19 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
waitAck: 00
waitAck: 00
waitAck: 01
<- 1A 19 20 10 44 12 34 51 37 49 02 38 00 39 00 3A 00 3B 00 3C 00 3D 00 3E 00 3F 00
waitAck: 00
waitAck: 01
<- 1A 19 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
waitAck: 00
waitAck: 01
<- 1A 19 20 10 44 12 34 51 37 49 02 48 00 49 00 4A 00 4B 00 4C 00 4D 00 4E 00 4F 00
waitAck: 00
waitAck: 01
<- 1A 19 20 10 44 12 34 51 37 49 02 50 00 51 00 52 00 53 00 54 00 55 00 96 00 97 64
waitAck: 00
waitAck: 01
<- 14 19 20 10 44 12 34 51 37 49 02 98 00 99 0A 9A 27 9B 10 00 00
waitAck: 00
waitAck: 01

irgendwie ist das ganze nicht stabil:
jetzt kommt wieder:

RESPONSE TIMEOUT:RegisterRead
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 20 Oktober 2016, 01:02:36
weitere Frage:

warum werden die bytes der messages immer mit bit-shifting und bit-ands gefüllt:

    Message::init(0xc,msgcnt,0x70,Message::BIDI,t1,t2);

    pload[0] = humidity;
   
     pload[1] = (pres >> 8) & 0xFF;                      // air pressure
    pload[2] = pres & 0xFF;   

    pload[3] = (lux >> 24) & 0xFFFFFF;                    // luminosity
    lux = lux & 0xFFFFFF;
    pload[4] = (lux >> 16) & 0xFFFF;
    lux = lux & 0xFFFF;
    pload[5] = (lux >> 8) & 0xFF;
    pload[6] = lux & 0xFF;


funktioniert das ganze nicht auch so:

    memcpy(pload[0], &humidity,    sizeof(humidity));
    memcpy(pload[1], &pres,        sizeof(pres));
    memcpy(pload[3], &lux,         sizeof(lux));
dann könnte man sogar so vorgehen:
    uint8_t pp = 0
    memcpy(pload[pp], &humidity,    sizeof(humidity)); pp += sizeof(humidity);
    memcpy(pload[pp], &pres,        sizeof(pres)); pp += sizeof(pres)
    memcpy(pload[pp], &lux,         sizeof(lux)); pp += sizeof(lux)

    Message::length(base+pp);

besser wäre es dann vielleicht sogar ein makro zu bauen:
#define setPayload(VARIABLE)   memcpy(pload[pp], &VARIABLE, sizeof(VARIABLE)); pp += sizeof(VARIABLE)


Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Oktober 2016, 08:11:43
irgendwie ist das ganze nicht stabil:
jetzt kommt wieder:

RESPONSE TIMEOUT:RegisterRead

Hast Du den neuesten Code. Ich habe das Messagehandling letztens geändert. Möglicherweise hilft das hier. Das Ack auf die Nachricht kommt echt spät. Die "waitAck" Ausgabe kommt nach 300ms. Wenn dann noch kein Ack wird die Nachricht nochmals gesendet. Da sind bei Dir ganz schön viele Wiederholungen.

Ich werde auch mal das Versenden von Nachrichten an die Peers deaktivieren, wenn das Device im Config-Modus ist (Listen schreiben).
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Oktober 2016, 08:19:30
warum werden die bytes der messages immer mit bit-shifting und bit-ands gefüllt:

Der 8bit AVR verwendet little-endian Byteorder. Da stehen die Bytes in umgekehrter Reihenfolge im Speicher. Deshalb kannst Du die Werte, die mehrere Byte im Speicher brauchen, nicht einfach per memcpy() kopieren. Die Werte in den Messages sind big-endian. Durch das Shiften kümmert sich der Compiler um die richtige Reihenfolge. Der Code kann dann auch einfach so auf big-endian CPUs ausgeführt werden - da der Compiler bzw. die CPU das dann schon richtig machen. Ist einfach portierbarer.

Die Maske 0xff kann man sich wahrscheinlich auch sparen, da eh vorne mit 0 aufgefüllt wird. Ist eher zur Sicherheit, dass man dann auch wirklich nur ein Byte im Register hat und dieses in den Speicher schreibt.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 20 Oktober 2016, 11:58:53
Hast Du den neuesten Code. Ich habe das Messagehandling letztens geändert. Möglicherweise hilft das hier. Das Ack auf die Nachricht kommt echt spät. Die "waitAck" Ausgabe kommt nach 300ms. Wenn dann noch kein Ack wird die Nachricht nochmals gesendet. Da sind bei Dir ganz schön viele Wiederholungen.

Ich werde auch mal das Versenden von Nachrichten an die Peers deaktivieren, wenn das Device im Config-Modus ist (Listen schreiben).

ok, die allerneueste Version habe ich noch nicht.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 20 Oktober 2016, 12:01:42
Der 8bit AVR verwendet little-endian Byteorder. Da stehen die Bytes in umgekehrter Reihenfolge im Speicher. Deshalb kannst Du die Werte, die mehrere Byte im Speicher brauchen, nicht einfach per memcpy() kopieren. Die Werte in den Messages sind big-endian. Durch das Shiften kümmert sich der Compiler um die richtige Reihenfolge. Der Code kann dann auch einfach so auf big-endian CPUs ausgeführt werden - da der Compiler bzw. die CPU das dann schon richtig machen. Ist einfach portierbarer.

Die Maske 0xff kann man sich wahrscheinlich auch sparen, da eh vorne mit 0 aufgefüllt wird. Ist eher zur Sicherheit, dass man dann auch wirklich nur ein Byte im Register hat und dieses in den Speicher schreibt.

ok, irgendwie dachte ich dass es für diese Art zu programmieren einen Grund geben muss.
Ich wurde wohl in die Irre geleitet, weil die bytes mit DDEX immer in der  richtigen Reihenfolge erscheinen.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 20 Oktober 2016, 21:49:24
Das Einspielen der neuesten Version hat es leider auch noch nicht gebracht:
Kann den output auch nicht interpretieren. Vielleicht hängt das mit meinem nanoCul zusammen.
Pairing hat aber geklappt und die Nachrichten zu Strom und Gas werden auch empfangen.

<- 1C 0A 00 00 44 12 34 00 00 00 11 00 DE 70 61 70 61 35 35 35 35 35 35 70 03 01 00 00 00
*

*
-> 10 1F A0 01 51 37 49 44 12 34 00 04 00 00 00 00 00
<- 14 1F 20 10 44 12 34 51 37 49 02 02 01 0A 51 0B 37 0C 49 00 00
*
waitAck: 00
<- 14 1F 20 10 44 12 34 51 37 49 02 02 01 0A 51 0B 37 0C 49 00 00
*
*
waitAck: 01
*
-> 10 20 A0 01 51 37 49 44 12 34 01 04 00 00 00 00 01
<- 1A 20 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
*
waitAck: 00
<- 1A 20 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
*
*
*
waitAck: 01
<- 1A 20 20 10 44 12 34 51 37 49 02 38 00 39 00 3A 00 3B 00 3C 00 3D 00 3E 00 3F 00
*
waitAck: 00
<- 1A 20 20 10 44 12 34 51 37 49 02 38 00 39 00 3A 00 3B 00 3C 00 3D 00 3E 00 3F 00
*
*
waitAck: 01
<- 1A 20 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
waitAck: 00
<- 1A 20 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
*
waitAck: 01
<- 1A 20 20 10 44 12 34 51 37 49 02 48 00 49 00 4A 00 4B 00 4C 00 4D 00 4E 00 4F 00
*
*
waitAck: 01
<- 1A 20 20 10 44 12 34 51 37 49 02 50 00 51 00 52 00 53 00 54 00 55 00 96 00 97 64
*
waitAck: 00
<- 1A 20 20 10 44 12 34 51 37 49 02 50 00 51 00 52 00 53 00 54 00 55 00 96 00 97 64
*
*
waitAck: 01
<- 14 20 20 10 44 12 34 51 37 49 02 98 00 99 0A 9A 27 9B 10 00 00
*
waitAck: 00
<- 14 20 20 10 44 12 34 51 37 49 02 98 00 99 0A 9A 27 9B 10 00 00
*
*
waitAck: 01
*
-> 10 21 A0 01 51 37 49 44 12 34 02 04 00 00 00 00 01
<- 1A 21 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
*
*
waitAck: 00
<- 1A 21 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
*
*
waitAck: 01
<- 1A 21 20 10 44 12 34 51 37 49 02 38 00 39 00 3A 00 3B 00 3C 00 3D 00 3E 00 3F 00
*
*
waitAck: 01
<- 1A 21 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
waitAck: 00
<- 1A 21 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
waitAck: 00
<- 1A 21 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
*
waitAck: 01
<- 1A 21 20 10 44 12 34 51 37 49 02 48 00 49 00 4A 00 4B 00 4C 00 4D 00 4E 00 4F 00
*
*
waitAck: 01
<- 1A 21 20 10 44 12 34 51 37 49 02 50 00 51 00 52 00 53 00 54 00 55 00 96 00 97 64
*
*
waitAck: 01
<- 14 21 20 10 44 12 34 51 37 49 02 98 00 99 0A 9A 27 9B 10 00 00
*
*
waitAck: 01
*
-> 0A 21 80 02 51 37 49 44 12 34 00
Strom
<- 10 0B 20 5E 44 12 34 51 37 49 00 00 00 00 00 00 00
*
waitAck: 00
<- 10 0B 20 5E 44 12 34 51 37 49 00 00 00 00 00 00 00
*
*
waitAck: 01
*
-> 0A 0B 80 02 51 37 49 44 12 34 00
Gas
<- 10 09 20 53 44 12 34 51 37 49 00 00 00 00 00 00 00
*
*
waitAck: 01
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Oktober 2016, 22:06:53
Wie sieht denn der RSSI Wert aus ?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Oktober 2016, 22:21:20
Du könntest zum Testen auch mal den Timeout für das Empfangen des Ack hoch setzen. Derzeit werden maximal 300ms gewartet. Ich weiss nicht, was hier die "normale" Zeit ist. Dein Log sieht so aus, als würden auch 2 Acks kommen.

Ändere doch mal in Zeile 21 in Device.cpp die 30 auf 50. Dann wird 500ms auf das Ack gewartet.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 21 Oktober 2016, 15:36:11
Wie sieht denn der RSSI Wert aus ?

Ich teste 2m vom nanoCul entfernt. Er ist noch nicht im produktivem Betrieb, habe ihn aber mal 5 Stunden vier Geräte zufällig an- ausschalten lassen - problemlos
Rssi:-45

Werde mal den timout hochsetzen und vielleicht mit einem echten CUL testen.
Komme aber erst am Sonntag abend dazu etwas neues auszuprobieren.

Wie sicher bist du dass die Nachricht des PowerMeters Gas korrekt aufgebaut wird. Habe mit der Variante von Trilu verglichen und kann auf dem ersten Blick keinen Fehler finden. Aber die Daten die ankommen sind Schrott.

Dietmar

Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Oktober 2016, 15:56:02
Wie sicher bist du dass die Nachricht des PowerMeters Gas korrekt aufgebaut wird. Habe mit der Variante von Trilu verglichen und kann auf dem ersten Blick keinen Fehler finden. Aber die Daten die ankommen sind Schrott.

Der Example HM-ES-TX-WM läuft bei mir seit einigen Wochen am Gaszähler und zählz auch fleissig mit. Was heisst den Schrott ?
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 21 Oktober 2016, 16:17:07
Da ich per reset kein mtr*LED auf 500 (blink /Kwh) setzen kann weiß ich nicht was im Register ankommt. Im Code habe ich gesehen, dass der Wert des Registers {dx} einfach pro tick addiert wird.

Durch Rechnen (vielleicht falsch) glaube ich dass ich immer 20 pro tick addieren muss. Dann habe ich bei 500 Ticks pro Stunde genau 500*20 =10000centiKwH=1Kwh verbraucht. In Fhem kommen die Zahlen aber so nicht an. Nicht einmal annähernd ein vielfaches von 1,10,100. In Fhem scheinen die Daten verschoben zu sein. Vor Sonntag werde ich nichts machen können.

Ich weiß einfach noch nicht wo der Fehler liegt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Oktober 2016, 22:07:50
Gibt den gesendeten Wert doch einfach mal vor dem Versenden auf der Serial-Console aus. Dann siehst Du, ob er falsch rechnet oder die Message falsch ist.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 22 Oktober 2016, 00:13:47
Das habe ich schon gemacht, aber in Fhem kommen die bytes sogar an, aber sie werden verschoben interpretiert
Wie schon gesagt, ich komme erst am Sonntag dazu mich damit zu beschäftigen

Dietmar
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 Oktober 2016, 19:51:13
Arg - kann es ein, dass Du Stromwerte mmit der Gas-Message senden willst ? Das kann nicht funktionieren. Die Message für Strom sieht anders aus. Wenn ich nachher noch dazu komme, ergämze ich die entsprechende Message im Example.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 22 Oktober 2016, 21:58:38
Den Unterschied habe ich noch nicht herausgefunden.
Habe die Gas  Nachricht kopiert und den Code auf 53 oder 5E geändert.
Die Struktur habe ich so gelassen.

Schon 5mal mit einer funktionierenden Variante verglichen, aber das Problem noch nicht gelöst
Titel: Antw:AskSin++ Library
Beitrag von: p2122 am 22 Oktober 2016, 23:26:00
Hallo, sollte der HM-RC-4 schon funktionieren? Ich bekomme es irgendwie nicht hin  :(   Im Serial Monitor kommt:

AskSin++ V0.1.0
CC init12.................3 - ready
*

...und dann nichts mehr. Der HM-LC-SWX-SM funktioniert gut.

Peter
Titel: Antw:AskSin++ Library
Beitrag von: papa am 23 Oktober 2016, 19:07:53
Den Unterschied habe ich noch nicht herausgefunden.
Habe die Gas  Nachricht kopiert und den Code auf 53 oder 5E geändert.
Die Struktur habe ich so gelassen.

Schon 5mal mit einer funktionierenden Variante verglichen, aber das Problem noch nicht gelöst

Mach mal nen Update. Habe die PowerMessage eingecheckt. Probiere die mal.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 23 Oktober 2016, 19:20:37
Hallo, sollte der HM-RC-4 schon funktionieren? Ich bekomme es irgendwie nicht hin  :(   Im Serial Monitor kommt:

AskSin++ V0.1.0
CC init12.................3 - ready
*

...und dann nichts mehr. Der HM-LC-SWX-SM funktioniert gut.

Sollte eigentlich funktionieren. Allerdings ist die Beschaltung der Taster so wie hier beschrieben nötig.

http://www.breadboarding.de/arduinoavr-buttons-an-einem-interrupt/

Nur der Interrupt an Pin 3 löst eine Aktion aus.

Mitterweile habe ich aber herausgefunden, dass der AVR auch durch den PinChange-Interrupt aus den Tiefschlaf geweckt wird. Damit ist die aufwendige Beschaltung nicht mehr nötig. Bin nur noch nicht dazu gekommen, den Code entsprechend anzupassen.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 23 Oktober 2016, 21:53:09
Hallo Holger,

Mein Sw4 läuft immer noch einwandfrei und es werden immer mehr davon. Frage: kann ich einen externen Schalter an einen Interrupt hängen, der dann einen der vier anschaltet? Dann kömnte ich das als Eingang nutzen und an die Zentrale zurückmelden.

Sprich ich brauche drei Schakter und eine Rückmeldung. Theoretisch ggfs. sogar über das Batteriesignal, ist aber kein Muss.

Kanmst du mir einen Tipp geben?

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: papa am 23 Oktober 2016, 21:59:48
Hallo Marc,

ich bin mir zwar nicht sicher, ob ich Dich richtig verstanden habe, aber der Config-Button im Example schaltet doch Channel 1. Du kannst natürlich noch weitere Buttons entsprechend anlegen (an andere Pins) und andere Channels schalten.

Holger
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 23 Oktober 2016, 23:02:45
so, ich habe die Differnz mit den power Signal gefunden.
die Powermessage Strom darf Counter nur 24bit liefern. Ich hatte die GasMessage kopiert nur einfach so gelassen. Das hat dann zu der Verschiebung geführt.

den timeout hochsetzen auf 500ms hat auch etwas gebracht, aber ganz rund(gefühlsmäßig) läuft es noch nicht.

Jetzt habe ich ein kleines neues Problem:
Ich lasse die Powernachricht alle 60 Sekunden vom A. liefern.
Das klappt auch im Abstand von 66 Sekunden. Die Differenz ist auf den ungenauen wdt zurückzuführen.

Wenn ich aber per Taschenlampe Interrupts an der Fotodiode erzeuge, kommt die Zeit im A. aus dem Tritt.
Das liegt meiner Meinung nach daran, das der A. durch den Interrupt aufwacht,  den tick im aClock um 80 Zentelsekunden aktualisiert, obwohl der wdt-timer nicht komplett abgelaufen ist.

Ich hatte dieses Problem schon einmal mit dem A. und habe mir damals geholfen indem ich einen Unterschied gemacht habe,zwischen dem Aufwachen durch einen PinchangeInterrupt und den Ablauf des wdt-timers.

Bei ein Pinchangeinterrupt habe ich den wdt einfach weiterlaufen lassen, ohne Neuladen des wdt. Ich weiß nicht, ob das mit dem LowPower Framework einfach möglich ist.

2016.10.23 22:52:14 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:51:08 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:50:03 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:48:57 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:47:51 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:46:45 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:45:39 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:44:33 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:43:27 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:42:21 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:41:15 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:40:10 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:39:04 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:37:58 3: Nachricht von HM_441234_IEC_02: power: 120
2016.10.23 22:37:01 3: Nachricht von HM_441234_IEC_02: power: 720
2016.10.23 22:36:58 3: Nachricht von HM_441234_IEC_02: power: 720
2016.10.23 22:36:53 3: Nachricht von HM_441234_IEC_02: power: 1080
2016.10.23 22:36:42 3: Nachricht von HM_441234_IEC_02: power: 960
2016.10.23 22:36:39 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.23 22:36:15 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:35:13 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:34:04 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:32:58 3: Nachricht von HM_441234_IEC_02: power: 0
2016.10.23 22:31:52 3: Nachricht von HM_441234_IEC_02: power: 0

hier das Beispiel:

void loop(){
 
   unsigned long now = millis();
   
   if (wdt != wdtold) {
      Serial << "pircount: " << pir << "ms:"<<millis() << " wdtcount: " << wdt << " " << tim << " " << now%1000 << " WDTtime: " << WDTtime << "\n";;
      Serial.flush();
   }
   
   ADCSRA = 0;                                 // disable ADC
// #################
  if (wdt != wdtold) {
      wdtEnable (9, 1);
  }
 
  wdtold = wdt;
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  cli();
  if (0)
  {
    sleep_enable();
    sleep_bod_disable();
    sei();
    sleep_cpu();
    sleep_disable();
  }
  sei();

 // Serial << "... wieder wach\n";
 // Serial.flush();

// #################   
}

void pirCount()   
   { pir++;  }

ISR(WDT_vect)
{
   wdt++;
   tim += WDTtime;
}

vielleicht geht folgendes:

  if (wdt != wdtold) {
      LowPower.powerDown(SLEEP_1S,ADC_OFF,BOD_OFF);
  } else {
     // sebst gemachtes sleep, wie oben
  }
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 24 Oktober 2016, 09:03:33
Ich werde mal eine für mich passende doSleep-Methode in Activity bauen und wenn ich sie zum Laufen bekomme ggf. zur Verfügung stellen.


Eingenschaften:

ein gestriger Langzeittest(zdwei Stunden) hat ergeben, dass die PowerMessages jetzt recht zuverlässig zwischen NanoCul und Arduino versendet werden. Auch der Inhalt passt.
Im SerialMonitor wird jetzt selbst jede PowerMessage mit waitAck: 01 protokolliert.

Und die ursprüngliche Idee, Gasnachrichten und Powernachrichten alle 10 bzw. alle 5 Minuten zu versenden funktioneirt auch.
FHEM erzeugt die Readings in den Channels anhand des Message-typ.

Nenbenbei eine Frage:
Gibt es einen Grund warum der typ zweimal versorgt wird?
Zeile 229 und Zeile 241 - manchmal mit verschiedenen Werten.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 24 Oktober 2016, 09:24:14
Hallo Holger,

danke. Das wird wohl mein Lieblingsmodul.

Zitat
ich bin mir zwar nicht sicher, ob ich Dich richtig verstanden habe, aber der Config-Button im Example schaltet doch Channel 1. Du kannst natürlich noch weitere Buttons entsprechend anlegen (an andere Pins) und andere Channels schalten.

Ich hätte mich genauer ausdrücken sollen. Stimmt, der Config Button schaltet eines der Relais. Allerdings ist es in dem Fall so, daß das externe Signal nicht nur ein kurzes an / aus ist, sondern dann für  mehrere Minuten an ist. Das würde dann ja den Config triggern.

Wie kann ich den Buttons anlagen? Macht es was aus, wenn diese für längere Zeit ein Signal liefern?

Danke & Gruss

Marc

Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 Oktober 2016, 13:23:46
Ich werde mal eine für mich passende doSleep-Methode in Activity bauen und wenn ich sie zum Laufen bekomme ggf. zur Verfügung stellen.

Für die Anpassung der PowerDown-Implementierung ist das Template-Argument Saver bei Activity::savePower() gedacht. Hier gibt es bisher die Implementierungen Idle und Sleep. Du kannst einfach eine neue Ableitung HighPrecisionSleep von Sleep machen, die dann doSleep() entsprechend implementiert. Da kann die Low-Power-Library auch komplett weg fallen.

Nenbenbei eine Frage:
Gibt es einen Grund warum der typ zweimal versorgt wird?
Zeile 229 und Zeile 241 - manchmal mit verschiedenen Werten.

In der Gerätebeschreibungs-XML vom HM-ES-TX-WM https://github.com/eq-3/occu/blob/master/firmware/rftypes/rf_es_tx_wm.xml (https://github.com/eq-3/occu/blob/master/firmware/rftypes/rf_es_tx_wm.xml) sind diese zwei Messages definiert. Sie unterscheiden sich nur in der ID. Ich weiss auch nicht, welche wann zu verwenden ist. Beim Gas-Event ist es auch so. Dort versende ich GAS_POWER_EVENT_CYCLIC=0x53. Das scheint soweit gut zu funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 Oktober 2016, 13:38:41
Wie kann ich den Buttons anlagen? Macht es was aus, wenn diese für längere Zeit ein Signal liefern?

class Channel2Button : public Button {
public:
  Channel2Button () {
    setLongPressTime(seconds2ticks(60UL*60*60)); // 1hour
  }
  virtual void state (uint8_t s) {
    Button::state(s);
    if( s == Button::pressed ) {
      sdev.channel(2).toggleState();
    }
  }
};
Channel2Button c2Btn;
void c2BtnISR () { c2Btn.check(); }

Einfach einen Button ableiten, der nur auf das "Pressed" Event reagiert. Die LongPressTime schön hoch setzen, damit wir uns die vielen unnötigen Events im Hintergrund sparen können. Und dann im setup() mit dem Pin und dem entsprechenden PinChangeInterrupt verbinden:

  ....
  c2Btn.init(CHANNEL2_BUTTON_PIN);
  attachPinChangeInterrupt(CHANNEL2_BUTTON_PIN,c2BtnISR,CHANGE);
  ....

Sollte so funktionieren ..... habe es aber nur hier im Editor geschrieben - also ungetestet. Der Channel könnte natürlich noch als Member änderbar gemacht werden.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 24 Oktober 2016, 20:28:48
Hallo Holger,

lieben Dank, ich werde es demnächst mal ausprobieren und Rückmeldung geben.

Toll. Danke

Marc
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 25 Oktober 2016, 09:40:47
Zitat
In der Gerätebeschreibungs-XML vom HM-ES-TX-WM https://github.com/eq-3/occu/blob/master/firmware/rftypes/rf_es_tx_wm.xml sind diese zwei Messages definiert. Sie unterscheiden sich nur in der ID. Ich weiss auch nicht, welche wann zu verwenden ist. Beim Gas-Event ist es auch so. Dort versende ich GAS_POWER_EVENT_CYCLIC=0x53. Das scheint soweit gut zu funktionieren.

aber sie unterscheiden sich doch:
Gas: 32bit  0x53
counter >> 24
counter >> 16
counter >> 8
counter >> 0

Power: 24 bit 0x5e
counter >> 16
counter >> 8
counter >> 0

Wie kannst du das richtig gemacht haben, wenn du keinen Unterschied gesehen hast?

Ich habe mir das xml  mal angesehen. Ich kann nicht erkennen wie festgelegt wird wie lang ein Element sein soll.
Der einzige Unterschied zwischen GAS_POWER und POWER ist neben dem maxvalue:
<conversion type="float_integer_scale" factor="1000"/>
Zitat
Für die Anpassung der PowerDown-Implementierung ist das Template-Argument Saver bei Activity::savePower() gedacht. Hier gibt es bisher die Implementierungen Idle und Sleep. Du kannst einfach eine neue Ableitung HighPrecisionSleep von Sleep machen, die dann doSleep() entsprechend implementiert. Da kann die Low-Power-Library auch komplett weg fallen.

Das ist ja eine klasse Idee - wäre ich vielleicht nie drauf gekommen. Hatte mir allerdings über die endgülitge Implementierung auch noch keine Gedanken gemacht. Wollte es nur ersteinmal zu Laufen bringen. Klappt schon einigermaßen, habe aber noch ein für mich unverständliches Problem, kann aber noch nicht erklären worin es genau besteht.

Danke Dietmar.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 Oktober 2016, 10:35:03
Wie kannst du das richtig gemacht haben, wenn du keinen Unterschied gesehen hast?

Natürlich unterscheiden sich Gas und Power Messages. Aber es gibt sowohl für Gas als auch für Power 2 Messages, die sich nur durch den Typ unterschieden. Deshalb habe ich auch für Gas und Power jeweils 2 Klassen definiert. Ich kann aber nicht sagen, wann welche zu nutzen ist. Ich benutzte für meine Gaszähler die GasPowerEventCycleMsg (Type=0x53). Das scheint soweit gut zu funktionieren.

Ich habe mir das xml  mal angesehen. Ich kann nicht erkennen wie festgelegt wird wie lang ein Element sein soll.

Die Länge steht im size Attribute des Parameters. So bedeute 2.7 beim ENERGY_COUNTER 2 Byte und 7 Bit. Also das höchste Bit gehört nicht zum Counter. Das wird nähmlich für das BOOT Flag benutzt. Entsprechend ist der Index zu verstehen. So bedeutet 9.7 das 7te Bit im 9ten Byte der Message. Eigentlich könnte man den Code für die Listen und  Messages direkt aus den XML-Daten generieren. Das macht ja auch trilu in der NewAskSin.

Das Nachrichtenformat steht übrigens im frames Abschnitt.
Titel: Antw:AskSin++ Library
Beitrag von: lech am 26 Oktober 2016, 20:56:20
Könnt ihr bitte die Beschaltung nochmal kurz erklären.
Ich versuche gerade HM-RC-4 anzulernen, aber weder die LED noch das Serial reagieren auf den Pin-8 gegen die Masse.
Habe auch schon versucht Pin-8 mit dem Pin-3 zu verbinden und beide gegen die Masse, ohne Erfolg.
Im Serial kommt nur:

AskSin++ V0.1.0
CC init12.................3 - ready
*

Auf die A0-A3 (gegen die Masse) scheint er zu reagieren:

debounce
 pressed
 released

Aber das bringt mich nicht weiter, denn der Schalter muss erst angelernt werden!?
Danke schon mal im Voraus für eine kurze Rückmeldung
Titel: Antw:AskSin++ Library
Beitrag von: papa am 26 Oktober 2016, 23:23:08
Pin 8 gegen Masse ist richtig. Das ist der Config-Taster. Wenn dieser gedrückt wurde, sollte auf der Console eine Nachricht (DEVICE-INFO) zu sehen sein. Diese startet das Pairing mit FHEM.

Die anderen Taster sind (derzeit noch) mittels einer Diode zusätzlich an Pin 3 für den gemeinsamen Interrupt anzuschliessen. Das ist allerdings gar nicht wirklich nötig. Muss ich mal umbauen, wenn etwas Zeit ist. Diese scheinen ja aber bei Dir zu funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: lech am 27 Oktober 2016, 18:12:31
Dann verstehe ich irgendwas nicht  ???

Ich nehme die gleiche Platine, spiele einen Sketch von der New AskSin ein, und schon kann ich die Hardware anlernen mit dem gleichen Pin-8.
Das funktioniert einwandfrei......

Kann das sein dass ich falsche Lib eingebunden habe? Denn beim Kompilieren fehlten ihm <PinChangeInt.h>
Ich habe die <PinChangeInterrupt by NicoHood> installiert und im Sketch auf #include <PinChangeInterrupt.h>  geändert.
Es fehlten noch zwei andere Libs  <Low-Power> und <TimerOne>, aber die gingen problemlos...

Hat jemand das gleiche Problem?
Titel: Antw:AskSin++ Library
Beitrag von: lech am 27 Oktober 2016, 19:51:05
OK, war doch mein Fehler. Man muss die PinChangeInterrupt vom "GreyGnome", die im Github verlinkt, nehmen  :D

So, jetzt reagiert er auf Pin 8, nur anlernen an der CCU2 lässt er sich nicht.....
Die CCU2 sieht ihn leider nicht. Und wenn ich versuche über die Seriennummer manuel, dann kommt im Serial periodisch "waitAck: 00" und die Zentrale meldet nach paar Sekunden einen Fehler.
Schade eigentlich....
Ist momentan die Kommunikation nur mit FHEM möglich?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Oktober 2016, 20:25:26
OK, war doch mein Fehler. Man muss die PinChangeInterrupt vom "GreyGnome", die im Github verlinkt, nehmen

Ja - bitte die verlinkten Libs installieren. Dann klappts auch mit der Software ...

Ist momentan die Kommunikation nur mit FHEM möglich?

Hm - keine Ahnung. Habe keine CCU und entwickele nur mit FHEM. Aber gundsätzlich sollte es funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: lech am 27 Oktober 2016, 20:54:30
irgendwie gefällt der CCU die Seriennummer nicht.
Ist es vielleicht aus einer bestimmten Zahlenkombination? ???
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Oktober 2016, 20:57:40
So, jetzt reagiert er auf Pin 8, nur anlernen an der CCU2 lässt er sich nicht.....
Die CCU2 sieht ihn leider nicht. Und wenn ich versuche über die Seriennummer manuel, dann kommt im Serial periodisch "waitAck: 00" und die Zentrale meldet nach paar Sekunden einen Fehler.

Kannst Du bitte mal alle Ausgaben der Console posten.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 27 Oktober 2016, 21:05:20
Der Stromverbrauchzähler läuft. Die Zeit (hier eine Minute ) hält er ganz gut ein.
Problem sind und bleiben die Interrupts. Sie praktisch nicht in den Griff zu bekommen.
Ich habe viel probiert, aber leider wenig Erfolg gehabt. Jetzt wird der A. Alle 250ms geweckt und durch probieren habe ich es geschaft die Zeiten so aufzusummieren, dass nach einer Minute kaum eine Abweichung mehr vorlag.

Bei Interrupts habe ich mir nun gedacht dass dieser im Mittel immer in der Mitte eines wdt eintritt und bewerte ihn nun mit der halben Zeit. Das passt einigermaßen.

Also danke für das wirklich einfach zu verwenden Framework.
Ich habe einige Ideen, die auf Umsetzung warten

016.10.27 15:14:47 3: Nachricht von HM_441234_IEC_02: power: 1320
2016.10.27 15:13:48 3: Nachricht von HM_441234_IEC_02: power: 600
2016.10.27 15:12:48 3: Nachricht von HM_441234_IEC_02: power: 840
2016.10.27 15:11:49 3: Nachricht von HM_441234_IEC_02: power: 1560
2016.10.27 15:10:51 3: Nachricht von HM_441234_IEC_02: power: 1680
2016.10.27 15:09:53 3: Nachricht von HM_441234_IEC_02: power: 1440
2016.10.27 15:08:54 3: Nachricht von HM_441234_IEC_02: power: 1560
2016.10.27 15:07:56 3: Nachricht von HM_441234_IEC_02: power: 1680
2016.10.27 15:06:57 3: Nachricht von HM_441234_IEC_02: power: 2040
2016.10.27 15:06:57 3: Nachricht von HM_441234_IEC_01: gasPower: 0
2016.10.27 15:05:59 3: Nachricht von HM_441234_IEC_02: power: 2160
2016.10.27 15:05:01 3: Nachricht von HM_441234_IEC_02: power: 1560
2016.10.27 15:04:03 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 15:03:03 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 15:02:03 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 15:01:04 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 15:00:04 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:59:05 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:58:05 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:57:06 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:57:06 3: Nachricht von HM_441234_IEC_01: gasPower: 0
2016.10.27 14:56:06 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:55:07 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:54:07 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:53:08 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:52:08 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:51:09 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:50:09 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:49:10 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:48:10 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:47:11 3: Nachricht von HM_441234_IEC_02: power: 120
2016.10.27 14:47:11 3: Nachricht von HM_441234_IEC_01: gasPower: 0
2016.10.27 14:46:11 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:45:12 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:44:12 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:43:12 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:42:13 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:41:14 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:40:14 3: Nachricht von HM_441234_IEC_02: power: 240
2016.10.27 14:39:15 3: Nachricht von HM_441234_IEC_02: power: 360
2016.10.27 14:38:16 3: Nachricht von HM_441234_IEC_02: power: 240
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Oktober 2016, 21:48:53
Das klingt doch gut. Könnte man den PowerDown-Code in die Lib mit aufnehmen ?
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 28 Oktober 2016, 01:33:41
ja,
aber im Moment sieht der noch ziemlich hässlich aus. Ich bin in viele Probleme geraten, die ich zunächst nur provisorisch gelöst habe:


häßlich:

public:

  static uint8_t offsetRest;
  static bool wdtAbgelaufen;
  static bool lowPinFound;

...
    if( ticks == 0 ) {
      LowPower.powerDown(SLEEP_FOREVER,ADC_OFF,BOD_OFF);
    }
    else if (ticks2millis(ticks) > 300 ) {
      wdtAbgelaufen = false;
      lowPinFound   = false;
    //Serial << "Schlafen:" << "\n";
      waitSerial();
      LowPower.powerDown(SLEEP_250MS,ADC_OFF,BOD_OFF);
      if (wdtAbgelaufen) {
         offset = millis2ticks(100);
         offsetRest += 77;
       //Serial << "LPD:normal aufgewacht:" <<  offset << " " << offsetRest << "\n";
      }else{
         if (lowPinFound) {
            offset = millis2ticks(000);
            offsetRest += 50+35+4-20;
            Serial << "LPD:Interrupt aufgewacht:" <<  offset << " " << offsetRest << "\n";
         }else{
            offset = 0;
         }   
      }
    }

    radio.wakeup();
    if (offsetRest>=100) {
       offset += millis2ticks(100); offsetRest -= 100;
     //Serial << "offset erhöht:" <<  offset << " " << offsetRest << "\n";       
    }       
    return offset;
  }

Ach, was mir aufgefallen ist. Nachdem ich auf wdt 250ms umgestellt hatte, habe ich festgestellt, dass die kleine rote LED am A. nach jedem Weckruf ganz kurz, kaum wahrnehmbar aufblinkt, offensichtlich im Takt dieser 250ms aufblinkt.

Habe natürlich daran gedacht, dass es eventuell an meinem Code liegen könnte und habe dann herausgefunden, dass es in radio.setIdle(); passiert. Jenes Modul habe ich dann nicht weiter untersucht.:

void    CC1101::setIdle() { // put CC1101 into power-down state
strobe(CC1101_SIDLE); // coming from RX state, we need to enter the IDLE state first
//strobe(CC1101_SFRX);
strobe(CC1101_SPWD); // enter power down state
//dbg << "pd\n";
}

Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Oktober 2016, 08:45:28
  • Korrektur per offset - nur auf Zentelsekunde, offsetRest eingeführt, um genauer aktualisieren zu können
Die Auflösung des Timers kannst Du in AlarmClock.h durch ändern von TICKS_PER_SECOND einstellen/erhöhen
Zitat
  • Der Arduino wird bei einem Interrupt CHANGE zweimal kurz hintereinander aus dem LowPowermode  geweckt.
Steigende und fallende Flanke
Zitat
  • Bei meiner Idee den wdt durch LowPower.powerDown(SLEEP_FOREVER, ...) einfach weiterlaufen zu lassen wollte ich durch aktualisieren des aclock mit 0 kompensieren. Leider ist das nicht möglich weil das in aClock eine Korrekur nach sich zog. in aClock werden die ticks(0) um eins vermindert(ticks--), ticks-- wird dann zu ~4554455444556, und dann eingerechnet min(...)..., führt dazu,dass der Alarm abläuft. Das gleiche Problem tritt auch bei der aktuellen Lösung auf.
Hm - die Korrektur hat ein paar Randbedingungen, die sollte man besser dokumentieren bzw. die Fehlerfälle mit halbwegs sinnvollem Code behandeln.

Zitat
Ach, was mir aufgefallen ist. Nachdem ich auf wdt 250ms umgestellt hatte, habe ich festgestellt, dass die kleine rote LED am A. nach jedem Weckruf ganz kurz, kaum wahrnehmbar aufblinkt, offensichtlich im Takt dieser 250ms aufblinkt.

Habe natürlich daran gedacht, dass es eventuell an meinem Code liegen könnte und habe dann herausgefunden, dass es in radio.setIdle(); passiert. Jenes Modul habe ich dann nicht weiter untersucht.:

Das ist ganz normal, da die Led an MOSI oder MISO (weiss jetzt nicht genau) hängt und somit die Kommunikation mit dem CC1101 sichtbar macht.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 28 Oktober 2016, 09:42:31
Hallo Holger,

Zitat
Sollte so funktionieren ..... habe es aber nur hier im Editor geschrieben - also ungetestet. Der Channel könnte natürlich noch als Member änderbar gemacht werden.

super, funktioniert. Lieben Dank.

Marc
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 28 Oktober 2016, 12:49:56
Zitat
Die Auflösung des Timers kannst Du in AlarmClock.h durch ändern von TICKS_PER_SECOND einstellen/erhöhen
müssten dann nicht die makros angepasst werden, Sie berücksichtigen im Moment TICKS_PER_SECOND  nicht vollständig
#define TICKS_PER_SECOND 10

#define seconds2ticks(tm) ( tm * TICKS_PER_SECOND )
#define ticks2seconds(tm) ( tm / TICKS_PER_SECOND )

//#define decis2ticks(tm) ( tm * TICKS_PER_SECOND / 10 )
#define decis2ticks(tm) ( tm )
#define ticks2decis(tm) ( tm )

//#define centis2ticks(tm)  ( tm * TICKS_PER_SECOND / 100 )
#define centis2ticks(tm)  ( tm / 10 )
#define ticks2centis(tm)  ( tm * 10 )

//#define millis2ticks(tm) ( tm * TICKS_PER_SECOND / 1000 )
#define millis2ticks(tm) ( tm / 100 )
#define ticks2millis(tm) ( tm * 100 )

Zitat
Steigende und fallende Flanke
ist mir auch inzwischen klar, aber erst einmal darauf kommen.

Zitat
Hm - die Korrektur hat ein paar Randbedingungen, die sollte man besser dokumentieren bzw. die Fehlerfälle mit halbwegs sinnvollem Code behandeln.
Wie meinst du das? ich habe die Methode correct offset bei mir korrigirt, damit ich aClock.correct(0) aufrufen kann. Soll ich eine Version erstellen, die bei mir funktioniert und dann den Code verschmelzen - wäre wahrscheinlich das beste.
Ich will nochmals versuchen von der Version mit konstant 250ms zu wecken in eine dynamischere Version zu wechseln. Das sollte möglich sein, dann kann ich vielleicht auch dafür sorgen, die häßlichen Codestellen zu verbessern.

Zitat
Das ist ganz normal, da die Led an MOSI oder MISO (weiss jetzt nicht genau) hängt und somit die Kommunikation mit dem CC1101 sichtbar macht.
Das ist mir bisher nicht aufgefallen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Oktober 2016, 21:55:40
irgendwie gefällt der CCU die Seriennummer nicht.
Ist es vielleicht aus einer bestimmten Zahlenkombination? ???

Ich habe noch eine Kleinigkeit angepasst - die Nachricht war zu lang. Kannst Du nochmal versuchen ?
Titel: Antw:AskSin++ Library
Beitrag von: lech am 28 Oktober 2016, 23:09:46
Zitat
Ich habe noch eine Kleinigkeit angepasst - die Nachricht war zu lang. Kannst Du nochmal versuchen ?

ja natürlich:

AskSin++ V0.1.0
CC init12.................3 - ready
 debounce
 pressed
 released
<- 1A 01 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 01 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 01 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 01 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 01 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 01 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00

 debounce
 pressed
 released
<- 1A 02 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 02 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 02 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 02 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 02 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00
<- 1A 02 20 00 78 90 12 3D 1C 40 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
waitAck: 00


irgendwas passt der CCU nicht >:(

und so sieht das Anlernen bei der NewAskSin aus:

HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
SN.
RV.
HMID: 58 23 EF, MAID: 00 00 00

<- 0E 00 80 10 58 23 EF 00 00 00 06 01 00 00 00 (1171)
b> 0F 43 86 10 22 11 3D 00 00 00 0A A0 DF 0D 00 00 (1751)
<- 1A 01 80 00 58 23 EF 00 00 00 10 00 6C 58 4D 53 31 31 31 31 31 31 37 00 41 01 00 (8347)
x> 10 01 B0 01 3D 1C 40 58 23 EF 00 05 00 00 00 00 00 (8954)
<- 0A 01 80 02 58 23 EF 3D 1C 40 00 (8958)
x> 13 0A A0 01 3D 1C 40 58 23 EF 00 08 02 01 0A 3D 0B 1C 0C 40 (9120)
x0 :02
x2 :0A
x4 :0B
x6 :0C
x8 :00
new masterid

<- 0A 0A 80 02 58 23 EF 3D 1C 40 00 (9137)
m> 0B 13 A0 01 3D 1C 40 58 23 EF 00 06 (9294)
<- 0A 13 80 02 58 23 EF 3D 1C 40 00 (9296)
m> 10 1C A0 01 3D 1C 40 58 23 EF 00 04 00 00 00 00 00 (9457)
cnl: 0 s: 0
totSlc: 2
<- 16 1C A0 10 58 23 EF 3D 1C 40 02 02 01 0A 3D 0B 1C 0C 40 12 00 18 00 (9472)
m> 0A 1C 80 02 3D 1C 40 58 23 EF 00 (9603)
<- 0C 1D A0 10 58 23 EF 3D 1C 40 03 00 00 (9606)
m> 0A 1D 80 02 3D 1C 40 58 23 EF 00 (9747)
m> 10 26 A0 01 3D 1C 40 58 23 EF 01 04 00 00 00 00 01 (9910)
cnl: 1 s: 0
totSlc: 1
<- 0C 26 A0 10 58 23 EF 3D 1C 40 03 00 00 (9920)
m> 0A 26 80 02 3D 1C 40 58 23 EF 00 (10056)
m> 10 2F A0 01 3D 1C 40 58 23 EF 01 05 00 00 00 00 01 (10235)
<- 0A 2F A0 02 58 23 EF 3D 1C 40 00 (10240)
m> 0D 38 A0 01 3D 1C 40 58 23 EF 01 08 08 00 (10396)
<- 0A 38 A0 02 58 23 EF 3D 1C 40 00 (10538)
m> 0B 41 A0 01 3D 1C 40 58 23 EF 01 06 (10695)
<- 0A 41 A0 02 58 23 EF 3D 1C 40 00 (10839)
m> 0B 4A A0 01 3D 1C 40 58 23 EF 01 03 (10996)
  timed out (11139)
<- 0E 4A A0 10 58 23 EF 3D 1C 40 01 00 00 00 00 (11142)
m> 0A 4A 80 02 3D 1C 40 58 23 EF 00 (11282)
m> 10 53 A0 01 3D 1C 40 58 23 EF 01 04 00 00 00 00 01 (11458)
cnl: 1 s: 0
totSlc: 1
<- 0C 53 A0 10 58 23 EF 3D 1C 40 03 00 00 (11468)
m> 0A 53 80 02 3D 1C 40 58 23 EF 00 (11604)
m> 0B 5C A0 01 3D 1C 40 58 23 EF 01 0E (11812)
<- 0E 5C A0 10 58 23 EF 3D 1C 40 06 01 00 00 58 (11824)
m> 0A 5C 80 02 3D 1C 40 58 23 EF 00 (11964)
b> 0F E2 86 10 22 10 A2 00 00 00 0A 88 C8 0C 00 00 (13367)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 Oktober 2016, 00:47:19
Ok - da war noch ein Flag nicht gesetzt. Kannst Du nochmal testen ?
Titel: Antw:AskSin++ Library
Beitrag von: lech am 29 Oktober 2016, 09:16:30
jetzt kommt er leider nicht weiter...
AskSin++ V0.1.0
CC init12.................3 - ready
 debounce
 pressed
 released
<- 1A 01 80 00 78 90 12 00 00 00 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00

 debounce
 pressed
 released
<- 1A 02 80 00 78 90 12 00 00 00 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00

 debounce
 pressed
 released
<- 1A 03 80 00 78 90 12 00 00 00 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00
Titel: Antw:AskSin++ Library
Beitrag von: Snobs am 29 Oktober 2016, 17:17:29
Hallo,
ich weiß ihr seit technisch schon ein ganzes Stück weiter, aber ich haeb zwei vielelicht einfacherer Fragen.
Erstmal Danke für den Post, ich habe es endlich zusammen bekommen, das sich mein Nano mit CC1101 Modul am HM-Lan-Adapter meldet.
Die Werte die dort ankommen sind natürlich föllig Banane, da noch kein Sensor angeschlossen ist und dies führt zu meiner ersten Frage.

1. Gibt es irgendwie eine Doku / Schaltplan / PDF wie ich einen DTH22 da anschliesse.
Der hat ja nur VCC / GND und den Data Pin, aber woran soll der damit ich die Werte bekomme.

2. In dem Sketch ein Sleep eingebaut. Ich denke zum einen um Strom zu sparen und die Funk "Last" nicht nach oben zu treiben.
Leider finde ich nicht die dauer des Sleeps. Wie häufig, oder in welchem Abstand wird die Temp/Hum gemessen und übertragen ?

Über Info`s würde ich mich freuen.

VG
Sascha
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 Oktober 2016, 20:46:30
jetzt kommt er leider nicht weiter...

Kannst Du bitte mal prüfen, ob überhaupt etwas empfangen wird. Bitte mal die Kommentare in den Zeilen 219/219 in MultiChannelDevice.h entfernen. Dann wird alles ausgegeben, auch Nachrichten für andere Geräte.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 Oktober 2016, 20:49:21
1. Gibt es irgendwie eine Doku / Schaltplan / PDF wie ich einen DTH22 da anschliesse.
Der hat ja nur VCC / GND und den Data Pin, aber woran soll der damit ich die Werte bekomme.

Google -> Arduino DHT22.
Da sollte so einiges zu finden sein.

2. In dem Sketch ein Sleep eingebaut. Ich denke zum einen um Strom zu sparen und die Funk "Last" nicht nach oben zu treiben.
Leider finde ich nicht die dauer des Sleeps. Wie häufig, oder in welchem Abstand wird die Temp/Hum gemessen und übertragen ?

Ich gehe mal davon aus, Du meinst das HM-WDS10-TH-O Beispiel. Dort wird die Zeit bis zur nächsten Messung in Zeile 95 festgelegt - auf 5 Sekunden.
Titel: Antw:AskSin++ Library
Beitrag von: Snobs am 29 Oktober 2016, 21:13:19
Hallo papa,

ja den Sketch meinte ich. Das hätte ich natürlich dazu schreiben sollen. Sorry dafür.
Das bedeutet also ich muss den DHT22 einfach dazu bauen. Fehlt mir nur noch die Brücke zwischen Wert auslesen und in den Sendeteil einbringen. Das lässt sich sicher auch lösen. Ich mache seit 3 Tagen damit rum und der Selbstbau CUL hat auch direkt funktioniert. BTW meier sendet die "gewürfelten" Werte im Sekunden Takt ...

//Edit ich bin bei den return seconds2ticks(225); bei <- 225 angekommen das entspricht bei mir ~+- 30 Sekunden mal mehr mal weniger. Da tickt doch bei mir was nicht richtig :)

// Das übertragen der (falschen) Werte geht immer nur einmal. Danach kommt nichts mehr an. <- Geht jetzt.
// Ich versuche das mal zu prüfen. Auch wenn ich das mit Zeile 215 noch nicht verstehe. Ich hab da einen HM-Lan Adapter dran da lässt sich nix ändern.
215 hab ich gefunden, ändert aber irgendwie nichts am Output.

Danke für die Unterstützung.

Gruß
Sascha
Titel: Antw:AskSin++ Library
Beitrag von: Snobs am 30 Oktober 2016, 09:45:23
Nachmals Danke für die Unterstützung,

heute Nacht habe ich Gedanklich die Brücke gefunden wie ich den DTH22 da rein bekomme. Ich hab mir das mit den Werten im Sketch nochmal angeschaut und bin darauf gekommen, das ich ja nur den Return vom DHT22 an der Stelle einbauen muss und schon ist alles gut :) Also DTH Modul/Sketch dazu und Werte an der richtigen Stelle parsen.

Vielen Dank dafür und schönen Sonntag.

VG
sascha
Titel: Antw:AskSin++ Library
Beitrag von: svenson08 am 01 November 2016, 19:51:23
Hallo Holger,

tolle Sache. Hab nach etwas Code Studium den HM-WDS10-TH-O mit meinem AM2302 ans laufen bekommen.
Weist du ob es möglich ist neben dem Battery Status ok bzw. low auch den BatteryLevel zu übermitteln? Dazu hab ich noch nichts finden können. Unterstützt das der orig. HM-WDS10-TH-O eigentlich?
Ansonsten läuft das ganze prima. Ich will die Tage mal in den Langzeittest starten um zu sehen wie sich der Batteriebetrieb verhält.

Gruß
Sascha
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 November 2016, 20:37:36
Weist du ob es möglich ist neben dem Battery Status ok bzw. low auch den BatteryLevel zu übermitteln? Dazu hab ich noch nichts finden können. Unterstützt das der orig. HM-WDS10-TH-O eigentlich?

Das unterstützt der Originale nicht. Um das mit aufzunehmen, müsste man sich ein eigenes Device definieren und eine entsprechende Erweiterung in FHEM ablegen. Wie man sowas prinzpiell geht, kann man sich beim Universalsensor http://www.fhemwiki.de/wiki/Universalsensor (http://www.fhemwiki.de/wiki/Universalsensor) abschauen.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 02 November 2016, 06:49:51
Der WDS10-TH-O  liefert doch auch noch Luftdruck und Lux
Vielleicht kannst du ja über diese Variable die Batteriespannung übertragen.
Titel: Antw:AskSin++ Library
Beitrag von: svenson08 am 02 November 2016, 07:07:20
Zum testen des Batteriebetriebs ist das bestimmt eine Möglichkeit, danke für den Tipp
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 November 2016, 08:55:45
Der WDS10-TH-O  liefert doch auch noch Luftdruck und Lux
Vielleicht kannst du ja über diese Variable die Batteriespannung übertragen.

Also laut dem Device-XML hat der nur Temperatur und Luftfeuchtigkeit.

https://github.com/eq-3/occu/blob/master/firmware/rftypes/rf_ash550.xml (https://github.com/eq-3/occu/blob/master/firmware/rftypes/rf_ash550.xml)
Titel: Antw:AskSin++ Library
Beitrag von: svenson08 am 02 November 2016, 09:03:55
wenn du in pload[1] einen Wert übergibst wird der in FHEM als Luftdruck ausgegeben. Das hatte ich gestern schon durch gespielt. Hat mich aber auch gewundert das es in der XML nicht erwähnt wurde.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 November 2016, 09:11:52
Möglicherweise eine Anpassung in FHEM an den Universalsensor, der zu Begin noch kein eigenes Device implementiert hatte.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 November 2016, 21:55:47
müssten dann nicht die makros angepasst werden, Sie berücksichtigen im Moment TICKS_PER_SECOND  nicht vollständig

Habe ich gemacht.
Titel: Antw:AskSin++ Library
Beitrag von: lech am 03 November 2016, 00:21:37
Zitat
Kannst Du bitte mal prüfen, ob überhaupt etwas empfangen wird. Bitte mal die Kommentare in den Zeilen 219/219 in MultiChannelDevice.h entfernen. Dann wird alles ausgegeben, auch Nachrichten für andere Geräte.

Sorry, war jetzt über die Feiertage weg...
Das ist es, ich glaube der CCU gefällt der Anlernestring nicht. Deswegen schickt sie auch keine Bestätigung?! Im Serial gibt es wirklich Nachrichten von anderen Geräten:
AskSin++ V0.1.0
CC init12.................3 - ready
 debounce
 pressed
 released
<- 1A 01 80 00 78 90 12 00 00 00 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00

ignore 0C 8F 86 70 20 6B 37 00 00 00 00 21 59
 debounce
 pressed
 released
<- 1A 02 80 00 78 90 12 00 00 00 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00

ignore 0F 9A 86 10 22 10 A9 00 00 00 0A 24 D1 0D 00 40
ignore 0F 1B 86 10 22 2B 38 00 00 00 0A 24 D5 0D 00 40
 debounce
 pressed
 released
<- 1A 03 80 00 78 90 12 00 00 00 00 00 08 70 61 70 61 33 33 33 33 33 33 00 03 01 00

ignore 0C F9 86 70 1F 4A D3 00 00 00 00 DA 37
ignore 0F 8D 86 10 22 11 3D 00 00 00 0A 90 D6 0D 00 00

Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 November 2016, 08:57:07
Das ist es, ich glaube der CCU gefällt der Anlernestring nicht. Deswegen schickt sie auch keine Bestätigung?!

Könntest Du bitte mal ein anderes Beispiel (HM-LC-SWX-SM) probieren ? Möglicherweise stimmt was bei den DeviceInfo-Daten nicht.
Ich habe auch mal den Subtype (auf 0x40) und die Firmeware-Version (auf 0x11) angepasst. Vielleicht geht es ja dann.

Gibt es eigentlich irgendwo eine Liste mit den Subtypes ?
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 03 November 2016, 09:36:04
ich glaube ich habe zu Hause so etwas - stelle ich heut Abend mal hier rein.
Titel: Antw:AskSin++ Library
Beitrag von: lech am 03 November 2016, 16:51:46
Zitat
Ich habe auch mal den Subtype (auf 0x40) und die Firmeware-Version (auf 0x11) angepasst
Cool, geil, super, jetzt geht's!!!  ;D ;D ;D
Papa, danke dir!
Ich kann die Fernbediengung jetzt problemlos mit der CCU2 pairen.
Die Tasten funktionieren noch nicht (A0 gegen Massse), aber das liegt wahrscheinlich an der etwas aufwendigeren Beschaltung. Ich muss noch paar Drähte zusammenlöten.  ;)
Super Arbeit!
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 November 2016, 19:13:55
Warte mal noch - ich wollte das eh nochmal ändern.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 03 November 2016, 20:38:56
meint ihr so etwas?

models:
  subType          name                       ID supportedMode            Info  List  channels
  --------------------------------------------------------------------------------------------
  AlarmControl     HM-Sec-Cen               004B normal                         1,3
  blindActuator    HM-LC-BL1-FM             0005 normal                         1,3
  blindActuator    HM-LC-Bl1-FM-2           00D2 normal                         1,3
  blindActuator    HM-LC-BL1-PB-FM          0053 normal                         1,3
  blindActuator    HM-LC-Bl1PBU-FM          006A normal                         1,3
  blindActuator    HM-LC-BL1-SM             0006 normal                         1,3
  blindActuator    HM-LC-Bl1-SM-2           00D1 normal                         1,3
  blindActuator    ROTO_ZEL-STG-RM-FEP-230V 007B normal                         1,3
  blindActuator    Schueco_263-146          0086 normal                         1,3
  blindActuator    Schueco_263-147          0087 normal                         1,3
  blindActuatorSol WDF-solar                0096 burst                          1,3   1 win, 2-3 blind,
  dimmer           HM-LC-DIM1L-CV           0012 normal                         1,3
  dimmer           HM-LC-Dim1L-CV-2         00B7 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1L-CV-644       006E normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM1L-PL           0013 normal                         1,3
  dimmer           HM-LC-Dim1L-Pl-2         00A3 normal                         1,3
  dimmer           HM-LC-Dim1L-Pl-3         00B3 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1L-Pl-644       006F normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1PWM-CV         0067 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1PWM-CV-2       00B5 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM1T-CV           0058 normal                         1,3
  dimmer           HM-LC-Dim1T-CV-2         00B9 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1T-CV-644       0072 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM1T-FM           0059 normal                         1,3
  dimmer           HM-LC-Dim1T-FM-2         00BA normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1T-FM-644       0073 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1T-FM-LF        00F5 normal                         1,3
  dimmer           HM-LC-Dim1TPBU-FM        0068 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1TPBU-FM-2      00B6 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM1T-PL           0057 normal                         1,3
  dimmer           HM-LC-Dim1T-Pl-2         00A4 normal                         1,3
  dimmer           HM-LC-Dim1T-Pl-3         00B4 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1T-Pl-644       0071 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM2L-CV           0016 normal                         1,3   1-2 Sw,
  dimmer           HM-LC-DIM2L-SM           002E normal                         1,3   1-2 Sw,
  dimmer           HM-LC-Dim2L-SM-2         00B8 normal                         1,3   1-2 Sw, 3-4 Sw1_V, 5-6 Sw2_V,
  dimmer           HM-LC-Dim2L-SM-644       0070 normal                         1,3   1-2 Sw, 3-4 Sw1_V, 5-6 Sw2_V,
  dimmer           HM-LC-DIM2T-SM           005A normal                         1,3   1-2 Sw,
  dimmer           HM-LC-Dim2T-SM           0074 normal                         1,3   1-2 Sw, 3-4 Sw1_V, 5-6 Sw2_V,
  dimmer           HM-LC-Dim2T-SM-2         00BB normal                         1,3   1-2 Sw, 3-4 Sw1_V, 5-6 Sw2_V,
  dimmer           OLIGO-smart-iq-HM        00FC normal                         1,3   1-2 Dim, 3-4 Dim1_V, 5-6 Dim2_V,
  dimmer           Schueco_263-132          0088 normal                         1,3
  dimmer           Schueco_263-133          008A normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           Schueco_263-134          0089 normal                         1,3
                   DORMA_atent              0064 config                         1,3   1-3 Btn,
  keyMatic         HM-SEC-KEY               0019 burst                          1,3
  keyMatic         HM-SEC-KEY-O             0027 burst                          1,3
  keyMatic         HM-SEC-KEY-S             0026 burst                          1,3
  KFM100           KFM-Display              0049 normal                         1,3
  KFM100           KFM-Sensor               0047 config                         1,3

  motionAndBtn     HM-Sen-MDIR-WM55         00DB config,wakeup,lazyConf         1,4   1-2 Btn, 3 Motion,
  motionDetector   HM-SEC-MDIR              004A config,wakeup,lazyConf   00:20 1,4
  motionDetector   HM-SEC-MDIR-2            00C0 config,wakeup,lazyConf   00:20 1,4
  motionDetector   HM-SEC-MDIR-3            00F7 config,wakeup,lazyConf   00:20 1,4
  motionDetector   HM-Sen-MDIR-O            005D config,wakeup,lazyConf   00:10 1,4
  motionDetector   HM-Sen-MDIR-O-2          00C1 config,wakeup,lazyConf   00:10 1,4
  motionDetector   HM-SEN-MDIR-SM           004F config,wakeup,lazyConf         1,4
  motionDetector   Schueco_263-162          0090 config,wakeup,lazyConf   00:30 1,3
  outputUnit       HM-OU-CFM-PL             0075 normal                         3     1 Led, 2 Mp3,
  outputUnit       HM-OU-CFM-TW             00FA config,burst                   3     1 Led, 2 Mp3,
  outputUnit       HM-OU-CF-PL              005C normal                         3     1 Led, 2 Sound,
  outputUnit       HM-OU-CM-PCB             00AF normal                         3
  outputUnit       HM-OU-LED16              006D normal                         ,1    1-16 Led,
  powerMeter       HM-ES-PMSw1-DR           00EA normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl           00AC normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R1     00D7 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R2     00E2 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R3     00E3 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R4     00E4 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R5     00E5 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-SM           00F6 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerSensor      HM-ES-TX-WM              00DE config,wakeup            00:10 1     1-2 IEC,
  pushButton       HM-Dis-EP-WM55           00FB config,burst                   1,3   1-2 Dis, 3-9 Key,
  pushButton       HM-Dis-WM55              00D3 config                         1,    1-10 Dis,
  pushButton       HM-PB-2-FM               00BF config,lazyConf                1,4   1-2 Btn,
  pushButton       HM-PB-2-WM               0036 config                         1,4   1-2 Btn,
  pushButton       HM-PB-2-WM55             006B config,wakeup,lazyConf         1,4   1-2 Btn,
  pushButton       HM-PB-2-WM55-2           00C2 config,wakeup,lazyConf         1,4   1-2 Btn,
  pushButton       HM-PB-4DIS-WM            0060 config,wakeup,lazyConf         1,4   1-20 Btn,
  pushButton       HM-PB-4DIS-WM-2          00DD config,wakeup,lazyConf         1,4   1-20 Btn,
  pushButton       HM-PB-4-WM               0035 config                         1,4   1-4 Btn,
  pushButton       HM-PBI-4-FM              0034 config                         1,4   1-4 Btn,
  pushButton       HM-Sen-DB-PCB            00DC config                         1,4
  pushButton       ROTO_ZEL-STG-RM-DWT-10   007E config,wakeup,lazyConf         1,4   1-20 Btn,
  pushButton       ROTO_ZEL-STG-RM-FST-UP4  007F config                         1,4   1-4 Btn,
  pushButton       ROTO_ZEL-STG-RM-WT-2     007D config,wakeup,lazyConf         1,4
  pushButton       Schueco_263-135          008D config,wakeup,lazyConf         1,4
  pushButton       Schueco_263-145          008F config                         1,4
  remote           CMM                      0018 normal                         3
  remote           DORMA_RC-H               0054 config                         1,3
  remote           HM-MOD-Em-8              00D9 lazyConf                       1,4   1-8 Btn,
  remote           HM-PB-6-WM55             00A9 config,wakeup,lazyConf         1,4   1-6 Btn,
  remote           HM-RC-12                 0029 config                         1,4   1-12 Btn,
  remote           HM-RC-12-B               002A config                         1,4   1-12 Btn,
  remote           HM-RC-12-SW              004C config                         1,4   1-12 Btn,
  remote           HM-RC-19                 0037 config,burst                   1,1.2p.3p.4p.5p.6p.7p.8p.9p.10p.11p.12p.13p.14p.15p.16p 1-17 Btn, 18 Disp,
  remote           HM-RC-19-B               0038 config,burst                   1,1.2p.3p.4p.5p.6p.7p.8p.9p.10p.11p.12p.13p.14p.15p.16p 1-17 Btn, 18 Disp,
  remote           HM-RC-19-SW              004D config,burst                   1,1.2p.3p.4p.5p.6p.7p.8p.9p.10p.11p.12p.13p.14p.15p.16p 1-17 Btn, 18 Disp,
  remote           HM-RC-2-PBU-FM           00E0 normal                         1,4   1-2 Btn,
  remote           HM-RC-4                  0008 config                         1,4   1-4 Btn,
  remote           HM-RC-4-2                00A0 config,lazyConf                1,4   1-4 Btn,
  remote           HM-RC-4-3                00D4 config,wakeup,lazyConf         1,4   1-4 Btn,
  remote           HM-RC-4-3-D              00F8 config,wakeup,lazyConf         1,4   1-4 Btn,
  remote           HM-RC-4-B                003B config                         1,4   1-4 Btn,
  remote           HM-RC-8                  00DA config,wakeup,lazyConf         1,4   1-8 Btn,
  remote           HM-RC-Dis-H-x-EU         00E1 config,wakeup,lazyConf         1,4   1-20 Btn,
  remote           HM-RC-KEY3               001D config                         1,4   1-3 Btn,
  remote           HM-RC-KEY3-B             001E config                         1,4   1-3 Btn,
  remote           HM-RC-Key4-2             00A6 config,lazyConf                1,4   1 unlock, 2 lock, 3 light, 4 open,
  remote           HM-RC-Key4-3             00D6 config,lazyConf                1,4   1 unlock, 2 lock, 3 light, 4 open,
  remote           HM-RC-P1                 001A config                         1,4
  remote           HM-RC-SEC3               001B config                         1,4   1-3 Btn,
  remote           HM-RC-SEC3-B             001C config                         1,4   1-3 Btn,
  remote           HM-RC-Sec4-2             00A5 config,lazyConf                1,4   1 armInt, 2 armExt, 3 light, 4 disarm,
  remote           HM-RC-Sec4-3             00D5 config,lazyConf                1,4   1 armInt, 2 armExt, 3 light, 4 disarm,
  remote           ROTO_ZEL-STG-RM-HS-4     0080 config                         1,4
  remote           Schueco_263-155          008E config                         1,4
  repeater         HM-Sys-sRP-Pl            0076 normal                         ,2
  rgb              HM-LC-RGBW-WM            00F4 normal                         1,3   1 Dim, 2 Color, 3 Auto,
  senBright        HM-Sen-LI-O              00FD config,wakeup            00:10 1
  sensor           HM-SEN-EP                0044 config,wakeup                  1,4   1-2 Sen,
  sensor           HM-Sen-Wa-Od             009F config,wakeup            28:00 1,4
  sensRain         HM-Sen-RD-O              00A7 normal                         1,1   1 Rain, 2 Heating,
  singleButton     DORMA_BRC-H              0065 config                         1,3   1-4 Btn,
  siren            HM-Sec-Sir-WM            00F9 config,burst                   1,3   1-2 Sen, 3 Panic, 4 Arm,
  smokeDetector    HM-CC-SCD                0056 config,wakeup            28:00 1,4
  smokeDetector    HM-SEC-SD                0042 burst                    99:00
  smokeDetector    HM-SEC-SD-2              00AA config,3Burst            99:00
  smokeDetector    Schueco_263-160          0084 config,wakeup                  1,4
  smokeDetector    Schueco_263-167          0091 burst                    99:00
  swi              HM-SWI-3-FM              0046 config                         4     1-3 Sw,
  swi              Roto_ZEL-STG-RM-FSS-UP3  0083 config                         4
  switch           HM-Dis-TD-T              0078 burst                          3
  switch           HM-LC-DDC1-PCB           004E normal                         1,3
  switch           HM-LC-SW1-BA-PCB         006C burst                          1,3
  switch           HM-LC-Sw1-DR             00F0 normal                         1,3
  switch           HM-LC-SW1-FM             0004 normal                         1,3
  switch           HM-LC-Sw1-FM-2           00CA normal                         1,3
  switch           HM-LC-SW1-PB-FM          0051 normal                         3
  switch           HM-LC-Sw1PBU-FM          0069 normal                         1,3
  switch           HM-LC-Sw1-PCB            0103 normal                         1,3   1-4 Sw,
  switch           HM-LC-SW1-PL             0011 normal                         1,3
  switch           HM-LC-SW1-PL2            00A1 normal                         1,3
  switch           HM-LC-Sw1-Pl-3           00C8 normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R1       00EB normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R2       00EC normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R3       00ED normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R4       00EE normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R5       00EF normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R1       00D8 normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R2       00E6 normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R3       00E7 normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R4       00E8 normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R5       00E9 normal                         1,3
  switch           HM-LC-SW1-PL-OM54        0001 normal                         1,3
  switch           HM-LC-SW1-SM             0002 normal                         1,3
  switch           HM-LC-Sw1-SM-2           00C9 normal                         1,3
  switch           HM-LC-SW1-SM-ATMEGA168   0014 normal                         3
  switch           HM-LC-SW2-DR             0062 normal                         1,3   1-2 Sw,
  switch           HM-LC-Sw2-DR-2           00CC normal                         1,3   1-2 Sw,
  switch           HM-LC-SW2-FM             0009 normal                         1,3   1-2 Sw,
  switch           HM-LC-Sw2-FM-2           00CB normal                         1,3   1-2 Sw,
  switch           HM-LC-SW2-PB-FM          0052 normal                         3     1-2 Sw,
  switch           HM-LC-Sw2PBU-FM          0101 normal                         1,3   1-2 Sw,
  switch           HM-LC-SW2-SM             000A normal                         1,3   1-2 Sw,
  switch           HM-LC-SW4-BA-PCB         00AB burst                          1,3   1-4 Sw,
  switch           HM-LC-SW4-DR             0061 normal                         1,3   1-4 Sw,
  switch           HM-LC-Sw4-DR-2           00D0 normal                         1,3   1-4 Sw,
  switch           HM-LC-SW4-PCB            002D normal                         1,3   1-4 Sw,
  switch           HM-LC-Sw4-PCB-2          00CE normal                         1,3   1-4 Sw,
  switch           HM-LC-SW4-SM             0003 normal                         1,3   1-4 Sw,
  switch           HM-LC-Sw4-SM-2           00CD normal                         1,3   1-4 Sw,
  switch           HM-LC-SW4-SM-ATMEGA168   0015 normal                         1,3   1-4 Sw,
  switch           HM-LC-SW4-WM             0066 normal                         1,3   1-4 Sw,
  switch           HM-LC-Sw4-WM-2           00CF normal                         1,3   1-4 Sw,
  switch           HM-MOD-Re-8              00BE burst                          1,3   1-8 Sw,
  switch           HM-SEC-SFA-SM            0050 normal                         1,3   1 Siren, 2 Flash,
  switch           PS-switch                8001 normal                         1,3   1-4 Sw,
  switch           ROTO_ZEL-STG-RM-FZS      007C normal                         1,3
  switch           ROTO_ZEL-STG-RM-FZS-2    00A2 normal                         1,3
  switch           Schueco_263-130          008B normal                         1,3
  switch           Schueco_263-131          008C normal                         1,3
  switch           Schueco_263-144          0092 config                         1,3
  thermostat       HM-CC-RT-DN              0095 config,wakeup,burstCond  00:10 1.2p.4p.5p.6p,3p.6p,1,3p.4 1 Weather, 2 Climate, 3 WindowRec, 4 Clima, 5 ClimaTeam, 6 remote,
  thermostat       HM-CC-RT-DN-BoM          00BD config,wakeup,burstCond  00:10 1.2p.4p.5p.6p,3p.6p,1,3p.4 1 Weather, 2 Climate, 3 WindowRec, 4 Clima, 5 ClimaTeam, 6 remote,
  thermostat       HM-CC-TC                 0039 config,wakeup,burstCond  00:10 2,2.3p,2 1 Weather, 2 Climate, 3 WindowRec,
  thermostat       HM-CC-VD                 003A config,wakeup            28:00 ,5
  thermostat       HM-TC-IT-WM-W-EU         00AD config,burst             00:10 1.2p.6p.7p,3p.6p,1,2.3p.7p,2,2 1 Weather, 2 Climate, 3 WindowRec, 6 remote, 7 SwitchTr,
  thermostat       ROTO_ZEL-STG-RM-FSA      007A config,wakeup            28:00 ,5
  thermostat       ROTO_ZEL-STG-RM-FWT      0079 config,wakeup,burstCond  00:10 2,2.3p,2 1 Weather, 2 Climate, 3 WindowRec,
  threeStateSensor HM-SCI-3-FM              005F config,wakeup            28:00 1,4   1-3 Sw,
  threeStateSensor HM-SEC-RHS               0030 config                   28:00 1,4
  threeStateSensor HM-SEC-RHS-2             00C3 config,wakeup            28:00 1,4
  threeStateSensor HM-SEC-SC                002F config                   28:00 1,4
  threeStateSensor HM-SEC-SC-2              00B1 config,wakeup,lazyConf   28:00 1,4
  threeStateSensor HM-SEC-SCo               00C7 config,wakeup,lazyConf   00:50 1,4
  threeStateSensor HM-SEC-TIS               0043 config,wakeup            28:00 1,4
  threeStateSensor HM-SEC-WDS               0045 config,wakeup            28:00 1,4
  threeStateSensor HM-SEC-WDS-2             00B2 config,wakeup            28:00 1,4
  threeStateSensor ROTO_ZEL-STG-RM-FDK      0081 config,wakeup            28:00 1,4
  threeStateSensor Roto_ZEL-STG-RM-FFK      0082 config,wakeup            28:00 1,4
  THSensor         ASH550                   000D config,wakeup,burstCond  00:10
  THSensor         ASH550I                  000E config,wakeup,burstCond  00:10
  THSensor         HM-WDC7000               0041 normal                   00:10 1,4
  THSensor         HM-WDS100-C6-O           0040 config,wakeup            00:10 ,1,1p
  THSensor         HM-WDS100-C6-O-2         00AE config,wakeup,burst      00:10 4
  THSensor         HM-WDS10-TH-O            003D config,burstCond,wakeup  00:10
  THSensor         HM-WDS20-TH-O            003C config,burstCond         00:10
  THSensor         HM-WDS30-OT2-SM          00A8 config,wakeup,burstCond  12:00       1 T1, 2 T2, 3 T1_T2, 4 T2_T1, 5 Event,
  THSensor         HM-WDS30-OT2-SM-2        0102 config,wakeup,burstCond  12:00       1 T1, 2 T2, 3 T1_T2, 4 T2_T1, 5 Event,
  THSensor         HM-WDS30-T-O             003E config,wakeup            00:10
  THSensor         HM-WDS40-TH-I            003F config,burstCond         00:10
  THSensor         HM-WDS40-TH-I-2          00BC config,burstCond         00:10
  THSensor         HM-WS550                 000B normal
  THSensor         HM-WS550LCB              0031 normal
  THSensor         HM-WS550LCW              0032 normal
  THSensor         HM-WS550Tech             002B normal
  THSensor         IS-WDS-TH-OD-S-R3        0048 config,wakeup,burstCond  00:10
  THSensor         KS550                    0007 config,wakeup            00:10 ,1,1p
  THSensor         KS550LC                  0033 config,wakeup            00:10 ,1,1p
  THSensor         KS550TECH                002C config,wakeup            00:10 ,1,1p
  THSensor         KS888                    001F config,wakeup            00:10 ,1,1p
  THSensor         PS-Th-Sens               8002 normal                         1,4   1-4 Sen,
  THSensor         S550IA                   000F config,wakeup            00:10
  THSensor         Schueco_263-157          0094 config,wakeup            00:10
  THSensor         Schueco_263-158          0093 config,wakeup,burstCond  00:10
  timer            SensoTimer-ST-6          00F3 config,burst                   1,5.6p.7p.8p.9p 1-2 Sw, 3-4 Sen, 5-7 Key, 8-9 ecoKey,
  tipTronic        Schueco_263-xxx          009B config,wakeup            28:00 1.2,1.3p 1 act, 2 sen, 3 sec,
  virtual          CCU-FHEM                 FFF0 normal                               1-50 Btn,
  winMatic         HM-SEC-WIN               0028 burst                          1,1   1 Win, 2 Akku,
                   WS888                    0022 normal                         1,3
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 November 2016, 21:06:03
Fast. Ich brauche den Zahlenwert für die Subtypes.

remote == 0x40
THSensor == 0x70
dimmer ==
switch ==
usw.

Scheinbar reagiert die CCU nur, wenn der Subtype stimmt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 November 2016, 21:34:47
Habe gerade das HM-RC-4 Example aktualisiert. Es reicht jetzt, die Buttons einfach gegen Masse zu schalten. Die Verbindung zum Pin3 mit Dioden ist nicht mehr nötig.

Außerdem unterstützt der Switch jetzt auch das SensorEvent. Habe ich allerdings noch nicht richtig getestet.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 03 November 2016, 23:42:20
Die 70 habe ich hier gefunden:
die 40 für remote findet sich auch dort.

fhem,
10_CUL_HM.pm


HMConfig.pm:

#my %culHmDevProps=(
#  "01" => { st => "AlarmControl",
#  "10" => { st => "switch",
#  "12" => { st => "outputUnit",
#  "20" => { st => "dimmer",
#  "30" => { st => "blindActuator",
#  "39" => { st => "ClimateControl",
#  "40" => { st => "remote",
#  "41" => { st => "sensor",
#  "42" => { st => "swi",
#  "43" => { st => "pushButton",
#  "44" => { st => "singleButton",
#  "51" => { st => "powerMeter",
#  "58" => { st => "thermostat",
#  "60" => { st => "KFM100",
#  "70" => { st => "THSensor",
#  "80" => { st => "threeStateSensor"
#  "81" => { st => "motionDetector",
#  "C0" => { st => "keyMatic",
#  "C1" => { st => "winMatic",
#  "C3" => { st => "tipTronic",
#  "CD" => { st => "smokeDetector",
#);
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 04 November 2016, 00:38:14
Möglicherweise eine Anpassung in FHEM an den Universalsensor, der zu Begin noch kein eigenes Device implementiert hatte.

stimmt:
http://www.fhemwiki.de/wiki/Universalsensor (http://www.fhemwiki.de/wiki/Universalsensor)
Zitat
Inbetriebnahme:

    Das FHEM-Modul für den Sensor muss installiert werden. Dazu folgenden Befehl in das Fhem-Befehlsfeld eingeben:
    update HMConfig_SenTHPL.pm https://raw.githubusercontent.com/kc-GitHub/Wettersensor/master/Contrib/control-fhem.txt
    Anschließend muss FHEM neu gestartet werden: shutdown restart
    Batterien in den Sensor einlegen
    CUL in den Pairingmodus schalten

dann wird dies alles gesendet:
hm->sendPeerWEATHER(regCnl, tTemp, tHum, tPres, tLux);
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 November 2016, 08:08:16
Die 70 habe ich hier gefunden:
die 40 für remote findet sich auch dort.

Ja - genau das habe ich gesucht.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 04 November 2016, 09:26:32
die HMConfig.pm ist eine Fundgrube mit sehr vielen Dingen, die man über HM wissen muss.
Titel: Antw:AskSin++ Library
Beitrag von: lech am 04 November 2016, 10:51:09
Zitat
Es reicht jetzt, die Buttons einfach gegen Masse zu schalten. Die Verbindung zum Pin3 mit Dioden ist nicht mehr nötig.
Ich habe jetzt nochmal alle Libs neu eingebunden und neu kompiliert, aber bei meiner Platine (Arduino Pro Mini 3.3V 8Mhz + CC1101) geht A0 gegen Masse noch nicht. Auch Serial bleibt stumm, keine Reaktion. Was könnte ich denn falsch machen... ???
Kann das sein, dass es mit dem Pin 3 zusammenhängt? Den der ist bei mir über einen Widerstand zur Masse gezogen (Steuerung eines Mosfets).
Welche Hardware habt ihr?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 November 2016, 11:29:07
Hast Du auch den Sketch selber aktualisiert ? Das Handling ist nicht in der Lib.
Titel: Antw:AskSin++ Library
Beitrag von: lech am 04 November 2016, 15:25:55
Zitat
Hast Du auch den Sketch selber aktualisiert ? Das Handling ist nicht in der Lib.
Ja, ich habe den AskSinPP-master Ordner komplett gelöscht, vom Github neu runtergeladen und die zip-Datei in der Arduino-IDE komplett neu eingebunden. Dann sieht man auch die Beispiel-Sketches. So habe ich schon immer gemacht.
Was ich noch nicht getestet habe, die Platine wird durch den UART-Adapter (FTDI) eingespeist. Vielleicht sollte ich den Adapter wegnehmen und extern einspeisen...
Was mir noch aufgefallen ist, es kommen keine Fremdmeldungen, trotz auskommentierter Zeile im MultiChanneldevice.h.
Der   HM-LC-SWX-SM lässt sich leider mit der CCU nicht pairen. Hier kommen aber die Fremdmeldungen an!

Warum CCU2?
Ich bin vor 2 Jahren umgestiegen von FHEM auf Raspberrymatic(CCU Emulator auf Raspberry), weil die Programmierung und Unübersichtlichkeit von FHEM für einen Nichtprogrammierer ziemlich problematisch sind. Selbst wenn du dich eingearbeitet und alles eingestellt hast, nach einem halben Jahr muss man wieder von vorne anfangen.

Momentan brauche ich einen Sketch für meine Türklingel. Die Hardware dazu habe selber auf einer Platine zusammengelötet und nutze einen Sketch von Trilu (HM_LC_SW1_BA_PCB). Das funktioniert soweit, nur die Reaktionszeit ist sehr lang und wenn man den Taster mehrmals drückt, dann geht da gar nichts mehr.
Deswegen möchte ich deinen HM-RC-4 in Kombination mit der CCU zum Laufen bekommen.
Ich müsste vielleicht die Dinger auf einem Breadboard neu aufbauen und nochmal testen   
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 04 November 2016, 18:20:10
wird das Batteriesignal schon in den Nachrichten weitergegeben.
Es wird emittelt, aber wie wird es zurückgegeben.

in FHEM gibt es folgenden Code:
würde ich so interpretieren im AcK_status oder  Info_Status  muss das höchste bit 0x80 im dritten Element (err) gesetzt sein.
Da die sendAck() alle in Mutichanneldevice gesendet werden kann das Gerät nicht auf batterie aus HM-ES-TX-WM.ino zugreifen.

muss vielleicht dieses bit gesetzt werden:
    RPTEN = 0x80,  // set in every message. Meaning?
  elsif($mh{st} eq "powerSensor") {############################################
    if (($mh{mTyp} eq "0201") ||  # handle Ack_Status
        ($mh{mTyp} eq "1006")) {  #    or Info_Status message here

      my ($chn,$val,$err) = (hex($mI[1]),hex($mI[2])/2,hex($mI[3]));
      $chn = sprintf("%02X",$chn&0x3f);
      my $chId = $mh{src}.$chn;
      $mh{shash} = $modules{CUL_HM}{defptr}{$chId}
                             if($modules{CUL_HM}{defptr}{$chId});
                             
      push @evtEt,[$mh{devH},1,"battery:".(($err&0x80)?"low"  :"ok"  )];

      push @evtEt,[$mh{shash},1,"state:$val"];
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 November 2016, 17:51:23
Das Battery-Bit wird von der flags() Methode im Channel zurück gegeben. Diese Methode wird bei sendAck(Message,Channel) und sendInfoActuatorStatus() ausgewertet. Man müsste eigentlich nur ab und zu sendInfoActuatorStatus() aufrufen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 November 2016, 17:57:59
Ja, ich habe den AskSinPP-master Ordner komplett gelöscht, vom Github neu runtergeladen und die zip-Datei in der Arduino-IDE komplett neu eingebunden. Dann sieht man auch die Beispiel-Sketches. So habe ich schon immer gemacht.
Was ich noch nicht getestet habe, die Platine wird durch den UART-Adapter (FTDI) eingespeist. Vielleicht sollte ich den Adapter wegnehmen und extern einspeisen...
Was mir noch aufgefallen ist, es kommen keine Fremdmeldungen, trotz auskommentierter Zeile im MultiChanneldevice.h.

Aber es ging doch schon mal was. Der FTDI sollte reichen.

Der   HM-LC-SWX-SM lässt sich leider mit der CCU nicht pairen. Hier kommen aber die Fremdmeldungen an!

Da war noch der SubType falsch. Habe ich gerade geändert und eingecheckt.

Ich müsste vielleicht die Dinger auf einem Breadboard neu aufbauen und nochmal testen

Das ist sicherlich keine schlechte Idee.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 05 November 2016, 18:45:59
Status Batterie: Werde ich mal probieren.
Die Messwerte sehen doch ganz gut aus - oder?

Das fertige Lötwerk ist jetzt so empfindlich, dass ich Abschirmen muss. Selbst die Wärmestrahlung meiner Hand oder das Nachglimmen einer ausgeschalteten Taschenlampe erzeugt Interrupts. Auf dem Breadboard war das nicht so heftig. Aber gut es läuft.

Weiterhin benötigt das Gesamtsystem 0,6 mA. Dafür scheint der Lm358 verantwortlich zu sein. Ohne ihn liegt der Verbrauch bei 0.046 mA. Wenn jemand einen Tipp hat wie man dem oamp den Durst abgewöhnen kann, her mit dem Tipp. 
Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 08 November 2016, 20:41:39
Lötwerk?
Das sieht aber so aus, als hättest du gar nicht gelötet, oder?

Btw: womit hast du den Verbrauch gemessen?
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 12 November 2016, 15:27:58
Zu dem Zeitpunkt hatte ich noch nichts verlötet. Trockenentwurf
Ganz normales Multimeter - Voltcraft

Habe herausgefunden, dass das Framework hier nach jedem Powerdown ersteinmal das Funkmodul einschaltet. Für mein zweites Projekt eine Helligkeitssensor analog dem Wettersensor universal, will ich ja nur alle drei Minuten wirklich senden. Deshalb schalte ich erst kurz vorm Senden das Modul an. Benötigt so nur 0,090 mA. Temperatur sensor ist noch nicht angekommen. Ich hoffe ich kann ihn noch irgendwie unterbringen. Das Gehäuse ist recht klein.


 2016.11.12 15:35:27 3: HM_995678: luminosity: 751 -> 9
2016.11.12 15:32:31 3: HM_995678: luminosity: 685 -> 9
2016.11.12 15:29:35 3: HM_995678: luminosity: 770 -> 9
2016.11.12 15:26:39 3: HM_995678: luminosity: 731 -> 9
2016.11.12 15:24:59 1: No Logdevice Jahresverbrauch

2016.11.12 15:23:43 3: hm2 return value: Undefined subroutine &main::Int called at (eval 1697) line 1.
2016.11.12 15:20:47 3: HM_995678: luminosity: 817 -> 9.67419226814568
2016.11.12 15:20:36 1: No Logdevice Jahresverbrauch
2016.11.12 15:17:50 3: HM_995678: luminosity: 822 -> 9.68299458368168
2016.11.12 15:14:54 3: HM_995678: luminosity: 862 -> 9.7515440590891
2016.11.12 15:11:58 3: HM_995678: luminosity: 923 -> 9.85018683764577
2016.11.12 15:09:02 3: HM_995678: luminosity: 1019 -> 9.99293833616581
2016.11.12 15:06:06 3: HM_995678: luminosity: 1582 -> 10.6275338844728
2016.11.12 15:03:10 3: HM_995678: luminosity: 2341 -> 11.192909219112
2016.11.12 15:00:14 3: HM_995678: luminosity: 2593 -> 11.3404064908533
2016.11.12 14:57:18 3: HM_995678: luminosity: 2776 -> 11.4387918525783
2016.11.12 14:54:22 3: HM_995678: luminosity: 3283 -> 11.680799034573
2016.11.12 14:51:26 3: HM_995678: luminosity: 3873 -> 11.9192357860283
2016.11.12 14:48:29 3: HM_995678: luminosity: 3909 -> 11.9325838692893
2016.11.12 14:45:33 3: HM_995678: luminosity: 3930 -> 11.940313597146
2016.11.12 14:43:32 1: No Logdevice Jahresverbrauch
2016.11.12 14:42:37 3: HM_995678: luminosity: 4108 -> 12.0042204663182
2016.11.12 14:39:41 3: HM_995678: luminosity: 4183 -> 12.030322282644
2016.11.12 14:36:45 3: HM_995678: luminosity: 4254 -> 12.0546043179607
2016.11.12 14:33:49 3: HM_995678: luminosity: 4359 -> 12.089781488354
2016.11.12 14:30:53 3: HM_995678: luminosity: 4521 -> 12.142426202319
2016.11.12 14:27:56 3: HM_995678: luminosity: 4873 -> 12.2505945071923
2016.11.12 14:25:00 3: HM_995678: luminosity: 5102 -> 12.3168471836025
2016.11.12 14:22:04 3: HM_995678: luminosity: 5157 -> 12.3323163301992
2016.11.12 14:19:08 3: HM_995678: luminosity: 5191 -> 12.3417967723918
2016.11.12 14:16:12 3: HM_995678: luminosity: 6198 -> 12.5975870395862
2016.11.12 14:13:16 3: HM_995678: luminosity: 6790 -> 12.7291958591321
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 12 November 2016, 20:29:52
habe folgendes Problem:

durch die Nutzung diverser Libraries steigt der Speicherbedarf schnell stark an.
Jetzt würde ich gern wissen was wie zum Anstieg beiträgt, finde aber nicht viel dazu.

Mit avr-size -x *.o
bekomme ich folgende Liste heraus. Kann jemand das interpretieren?

Kann man irgendwie verhindern, dass so fette Bibliotheken wie WString oder Tone nicht genutzt werden müssen. Ich habe keine Ahnung wodurch sie eingebunden werden.
Auf dem ersten Blick benötigt man nicht so viel von LowPower und TSL2561. Vielleicht lassen sich abgespeckte Versionen aufbauen und verwenden.

Hat jemand von Euch da Erfahrung?

    0x0     0x0     0x0       0       0 ./core/CDC.cpp.o
    0x0     0x0     0x0       0       0 ./core/HardwareSerial1.cpp.o
    0x0     0x0     0x0       0       0 ./core/HardwareSerial2.cpp.o
    0x0     0x0     0x0       0       0 ./core/HardwareSerial3.cpp.o
    0x0     0x0     0x0       0       0 ./core/PluggableUSB.cpp.o
    0x0     0x0     0x0       0       0 ./core/USBCore.cpp.o
    0x2     0x0     0x0       2       2 ./core/hooks.c.o
    0x0     0x1     0x4       5       5 ./libraries/AskSinPP/AccurateSleep.cpp.o
    0x8     0x0     0x0       8       8 ./core/abi.cpp.o
   0x10     0x0     0x0      16      10 ./core/new.cpp.o
   0x10     0x0     0x3      19      13 ./libraries/AskSinPP/HMID.cpp.o
   0x28     0x0     0x0      40      28 ./core/main.cpp.o
   0x4e     0x0     0x6      84      54 ./libraries/TimerOne/TimerOne.cpp.o
   0x56     0x0     0x0      86      56 ./libraries/AskSinPP/Radio_ProMini.cpp.o
   0x8a     0x0     0x0     138      8a ./core/wiring_pulse.S.o
   0xe8     0x0     0x0     232      e8 ./core/wiring_shift.c.o
   0xfe     0x1     0x0     255      ff ./core/wiring_analog.c.o
  0x102     0x4     0x0     262     106 ./core/WInterrupts.c.o
  0x10c     0x0     0x1     269     10d ./libraries/AskSinPP/EEProm.cpp.o
  0x12a     0x0     0x0     298     12a ./core/WMath.cpp.o
  0x177     0x0    0x10     391     187 ./libraries/AskSinPP/Activity.cpp.o
  0x1a4     0x0     0x6     426     1aa ./core/IPAddress.cpp.o
  0x1b3     0x0     0x0     435     1b3 ./libraries/AskSinPP/Device.cpp.o
  0x1d6     0x0     0x0     470     1d6 ./libraries/AskSinPP/SwitchStateMachine.cpp.o
  0x1da     0x0     0x0     474     1da ./core/wiring_pulse.c.o
  0x1dc     0x0     0x0     476     1dc ./core/wiring_digital.c.o
  0x14c     0x0    0x9d     489     1e9 ./core/HardwareSerial0.cpp.o
  0x1ee     0x0     0x9     503     1f7 ./core/wiring.c.o
  0x2f0     0x0     0x0     752     2f0 ./core/HardwareSerial.cpp.o
  0x32d     0x0    0x1a     839     347 ./libraries/AskSinPP/Led.cpp.o
  0x32a     0x0    0x56     896     380 ./libraries/Wire/Wire.cpp.o
  0x490     0x0     0x0    1168     490 ./libraries/AskSinPP/SwitchList3.cpp.o
  0x492     0x0    0x6e    1280     500 ./libraries/Wire/utility/twi.c.o
  0x541     0x1    0x15    1367     557 ./core/Tone.cpp.o
  0x5ca     0x0     0x1    1483     5cb ./libraries/Low-Power/LowPower.cpp.o
  0x61f     0x0     0x0    1567     61f ./core/Print.cpp.o
  0x660     0x0     0x8    1640     668 ./libraries/AskSinPP/AlarmClock.cpp.o
  0x6dd     0x0     0x0    1757     6dd ./core/Stream.cpp.o
  0x80c     0x0     0x0    2060     80c ./libraries/TSL2561/TSL2561.cpp.o
  0x7cf     0x0    0x4f    2078     81e ./libraries/AskSinPP/Radio.cpp.o
 0x13a1     0x0     0x1    5026    13a2 ./core/WString.cpp.o
 0x24aa     0x0    0xe4    9614    258e ./sketch/HM-WDS10-TH-O.ino.cpp.o
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 November 2016, 08:57:20
Das ist nur die Größe der Object-File. Der Linker sollte nur die wirklich benötigten Teile in das Image aufnehmen. Du kannst ja mal die Debug-Ausgaben abschalten. Einfach in Debug.h ein "define  NDEBUG" einfügen.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 13 November 2016, 18:41:46
Gilt das auch für die Methoden einer Bibliothek, die nicht aufgerufen werden? Gerade die Verwendung von late Binding in C++ führt dazu, dass der Compiler nicht genau vorhersagen kann, was er alles binden muss.

Kann man solche Details irgendwo her bekommen. Noch habe ich von der Größe her keine Probleme, aber wenn noch weitere Bibliotheken benötige, hätte ich gern ein Verfahren effektiv abzuspecken.

Gibt es eine Möglichkeit den Assemblercode zu erzeugen? Eventuell mit der Größe der einzelnen Methode?

Danke!
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 November 2016, 16:02:19
Gilt das auch für die Methoden einer Bibliothek, die nicht aufgerufen werden? Gerade die Verwendung von late Binding in C++ führt dazu, dass der Compiler nicht genau vorhersagen kann, was er alles binden muss.

Der Linker packt alles rein, was potientiell genutzt werden kann, weil es irgendwo im Code referenziert wird. Da gehören natürlich die virtuellen Methoden, die in der VirtualMethodTable stehen, immer dazu. Deshalb habe ich an vielen Stellen Templates benutzt, da das der Compiler beim übersetzen schon komplett auflösen kann. Allerdings kann es dann auch zu Codedublizierungen kommen, wenn ein Template häufig benutzt wird.
Irgendwas ist halt immer.

Kann man solche Details irgendwo her bekommen. Noch habe ich von der Größe her keine Probleme, aber wenn noch weitere Bibliotheken benötige, hätte ich gern ein Verfahren effektiv abzuspecken.

Gibt es eine Möglichkeit den Assemblercode zu erzeugen? Eventuell mit der Größe der einzelnen Methode?

Schau Dir mal avr-objdump an. Damit kriegt man viel raus.
Vielleicht kann der Linke auch noch was zusätzliches generieren, was er wo im Image plaziert hat. Das wäre sicherlich die besten Infos ergeben. Keine Ahnung, ob da was geht.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 01 Dezember 2016, 21:49:29
ich probiere einen Bewegungsmelder zu bauen

sending peer events ...
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0
waitAck: 00
<- 0D 01 A0 41 99 45 67 27 10 00 01 01 14 B0
waitAck: 00
 

kann es sein, dass hier ein Fehler vorliegt. Ich habe nur mit der Zentrale gepairt.
Über
      Serial << "sending peer events ...\n";
      device().sendPeerEvent(msg,*this);
wird dreimal versucht eine Nachricht abzusetzen, obwohl kein peer gepairt ist.
Habe ich was falsch verstanden?

Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 Dezember 2016, 08:03:37
Das sieht so aus, als wären noch Daten im EEProm von einem vorherigen Sketch. Mach mal nen RESET - Config-Taster mehr als 6 Sekunden drücken. Dann werden alle Channels neu initialisiert. Danach muss neu angelernt werden.

Ich muss mir mal Gedanken machen, wie ich die Initialisierung des EEProm verbessern kann, so daß Änderungen an der Channelkonfiguration eine neue Initialisierung auslösen.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 05 Dezember 2016, 22:21:23
versuche den HM-SEC-MDIR zum Laufen zu bringen.

Habe ein Problem mit minInterval.
Das Feld wird mit  minInterval(4) initialisiert.

Der Inhalt des Feldes wird mit     pload[1] = (next+4) << 4;  an fhem übergeben.

minInterval() liefert aber nicht 4 sondern 7 zurück.
Das führt dann dazu, dass in fhem nicht 240s sondern 1920s angezeigt wird.

Irgendwo funktioniert da etwas nicht. Verstehe die bit-Funktionen in setByte/getByte nicht.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 06 Dezember 2016, 11:24:19
Ich würde mal behaupten, das der Speicher nicht initialisiert wurde. Rufe doch bitte einmal dev.firstinit() direkt in setup() auf.

Der getByte/setByte Code funktioniert auf jeden Fall. Für minInterval werden nur die unteren 3 Bits des ersten Byte genutzt. Deshalb die Maske 0x07 und der Shift-Wert 0.

getByte macht folgendes:
  * Wert vom Offset lesen
  * die Maske anwenden - sprich alle Bits auf 0, die nicht zum Wert gehören
  * Wert um Shift nach rechts schieben

setByte arbeite wie folgt:
  * Wert von Offset lesen
  * die Maske invertieren und die Bits, die zum Wert gehören löschen
  * in Variable zwischenspeichern
  * neuen Wert um Shift nach links schieben und sicherheitshalber die Maske anwenden
  * mit bitweisem OR den neuen Wert in die Variable einfügen
  * gesamtes Byte wieder an Offset schreiben

Das muss natürlich nur für Werte gemacht werden, die kein ganzes Byte benutzen.

Ich habe mal Testcode hier angehängt. Kann einfach mit g++ -o code code.cc übersetzt werden.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 13 Dezember 2016, 14:10:57
Hi,

ein weiterer Klon von HM-LC-SW4-SM. Läuft sehr sauber und störungsfrei.

https://youtu.be/2TJcLecfups (https://youtu.be/2TJcLecfups)

Danke!
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 14 Dezember 2016, 20:05:13
@MBHG:
Kannst du näher beschreiben welche hardware(220V) du verwendet und wie du es verschaltet hast?
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 15 Dezember 2016, 14:43:15
Hallo Dietmar,

ich nutze Relais wie
https://de.aliexpress.com/item/1pcs-lot-4-channel-relay-module-4-channel-relay-control-board-with-optocoupler-Relay-Output-4/32340914033.html?spm=2114.010208.8.5.RPjxqJ (https://de.aliexpress.com/item/1pcs-lot-4-channel-relay-module-4-channel-relay-control-board-with-optocoupler-Relay-Output-4/32340914033.html?spm=2114.010208.8.5.RPjxqJ)

Die Eingänge des Relais sind mit A2 - A5 verbunden, A0 und A1 brücken invertiert das Signal.

Der genutzte Script ist der Beispielscript HM-LC-SWX...

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 15 Dezember 2016, 14:50:42
AES wäre fantastisch, es scheint aber noch nicht in FHEM implementiert zu sein, korrekt?

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 Dezember 2016, 15:13:00
In FHEM schon, bloss noch nicht in der Library. Steht aber auf meiner Liste :-)
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 16 Dezember 2016, 17:11:50
Hallo Dietmar,

ich nutze Relais wie
https://de.aliexpress.com/item/1pcs-lot-4-channel-relay-module-4-channel-relay-control-board-with-optocoupler-Relay-Output-4/32340914033.html?spm=2114.010208.8.5.RPjxqJ (https://de.aliexpress.com/item/1pcs-lot-4-channel-relay-module-4-channel-relay-control-board-with-optocoupler-Relay-Output-4/32340914033.html?spm=2114.010208.8.5.RPjxqJ)

Die Eingänge des Relais sind mit A2 - A5 verbunden, A0 und A1 brücken invertiert das Signal.

Der genutzte Script ist der Beispielscript HM-LC-SWX...

Gruss Marc

nutzt du eine  Mini Pro oder Nano(3V,  5V)
wird das Relais mit Batterie betrieben? Geht das überhaupt?
 
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 16 Dezember 2016, 21:41:31
Aktuell benutze ich arduino nanos, habe mir aber zwei pro minis bestellt mit denen ich meine nächsten Module erstellen werde. Alles ist 5v. Sollten bald kommen, werde dann berichten.

Batterien habe ich momemtan nicht im Einsatz.

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 17 Dezember 2016, 01:33:01
Leidet bei 5v nicht das Cc1101?
Ich habe einen HM-ES-TX-WM  und einen
HB-UW-Sen-THPL-O gebastelt, und darauf geachtet, dass alles schön 3,3v hat. Das ganze ist inzwischen ziemlich stromsparend aufgebaut 0,040 mA. Dazu musste ich an der Original Version der Asksinpp  ein wenig verändern.

Diese Einheitlichkeit mit 3,3V geht dann natürlich flöten. Zweite Stromquelle, Stromwandlung...
Ich dachte auch bei einem Relais an eine Batterie Version. Kann man aus 220v nicht irgendwie 5v herstellen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Dezember 2016, 19:08:26
Dafür kann man die hier gut nehmen:

https://de.aliexpress.com/item/5-pcs-HLK-PM01-AC-DC-220V-to-5V-Step-Down-Power-Supply-Module-Intelligent-Household/32319202093.html?detailNewVersion=&categoryId=400103 (https://de.aliexpress.com/item/5-pcs-HLK-PM01-AC-DC-220V-to-5V-Step-Down-Power-Supply-Module-Intelligent-Household/32319202093.html?detailNewVersion=&categoryId=400103)
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 17 Dezember 2016, 22:01:54
Zum Beispiel. Oder ein USB Steckerladegerätfür 60cent. Kannst auch die Kontakte ausbauen und die Drähte direkt anschliessen. Einfach zwischen cc1101 und arduino noch ein Wandler funktioniert wunderbar.

Gruss
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 18 Dezember 2016, 02:01:52
Kann ich so etwas irgendwo nachlesen.
Bin Nachwuchs Elektroniker und muss mir alles selbst per Tante Google beibringen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Dezember 2016, 13:21:15
Dann nimm bitte ein 5V Steckernetzteil. Soviel sollte Dir Deine Sicherheit wert sein.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 18 Dezember 2016, 13:39:20
Bin eh noch in der Planung - aber das eine oder andere Relais schalten zu können, finde ich schon klasse.
Für 60cent habe ich aber noch keines gefunden.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 19 Dezember 2016, 15:32:22
Als Beispiel:

4-Channel Relay
https://www.aliexpress.com/item/Free-Shipping-1PCS-LOT-5V-4-Channel-Relay-Module-Shield-for-Arduino-ARM-PIC-AVR-DSP/32728446686.html?spm=2114.30010308.3.20.V5ZvBa&ws_ab_test=searchweb0_0,searchweb201602_3_10065_10068_10084_10083_10080_10082_10081_10060_10061_10062_10056_10055_10037_10054_10033_10059_10032_10099_10078_10079_10077_427_10103_10073_10102_10101_10096_10052_10050_10051,searchweb201603_9&btsid=3dff420b-ebd9-4586-9944-65917f3bfde5
 (https://www.aliexpress.com/item/Free-Shipping-1PCS-LOT-5V-4-Channel-Relay-Module-Shield-for-Arduino-ARM-PIC-AVR-DSP/32728446686.html?spm=2114.30010308.3.20.V5ZvBa&ws_ab_test=searchweb0_0,searchweb201602_3_10065_10068_10084_10083_10080_10082_10081_10060_10061_10062_10056_10055_10037_10054_10033_10059_10032_10099_10078_10079_10077_427_10103_10073_10102_10101_10096_10052_10050_10051,searchweb201603_9&btsid=3dff420b-ebd9-4586-9944-65917f3bfde5)

USB Charger
https://www.aliexpress.com/item/USB-Power-Adapter-EU-Plug-5V-AC-Micro-Usb-Wall-Charger-For-Apple-Iphone-6-Plus/32763844087.html?spm=2114.30010308.3.288.Nab4cg&ws_ab_test=searchweb0_0,searchweb201602_3_10065_10068_10084_10083_10080_10082_9026_10081_10060_10061_10062_10056_10055_10037_10054_10033_10059_10032_10099_10078_10079_10077_427_10103_10073_10102_10101_10096_10052_10050_10051,searchweb201603_9&btsid=5e7965a2-4f90-4ee4-9ba0-42e116d7c2cf (https://www.aliexpress.com/item/USB-Power-Adapter-EU-Plug-5V-AC-Micro-Usb-Wall-Charger-For-Apple-Iphone-6-Plus/32763844087.html?spm=2114.30010308.3.288.Nab4cg&ws_ab_test=searchweb0_0,searchweb201602_3_10065_10068_10084_10083_10080_10082_9026_10081_10060_10061_10062_10056_10055_10037_10054_10033_10059_10032_10099_10078_10079_10077_427_10103_10073_10102_10101_10096_10052_10050_10051,searchweb201603_9&btsid=5e7965a2-4f90-4ee4-9ba0-42e116d7c2cf)
Titel: Antw:AskSin++ Library
Beitrag von: kadettilac89 am 19 Dezember 2016, 21:41:48
Leidet bei 5v nicht das Cc1101?
Ich habe einen HM-ES-TX-WM  und einen
HB-UW-Sen-THPL-O gebastelt, und darauf geachtet, dass alles schön 3,3v hat. Das ganze ist inzwischen ziemlich stromsparend aufgebaut 0,040 mA. Dazu musste ich an der Original Version der Asksinpp  ein wenig verändern.

Diese Einheitlichkeit mit 3,3V geht dann natürlich flöten. Zweite Stromquelle, Stromwandlung...
Ich dachte auch bei einem Relais an eine Batterie Version. Kann man aus 220v nicht irgendwie 5v herstellen?

Hi Dietmar,

CC1101 und 5 V --> Ich habe 2 nanoCul mit USB, also mit 5V laufen. War einer der ersten der das Modul nachgebaut hat, d. h. die CC1101 laufen seit 2 Jahren permanent .... und sie laufen immer noch. Ist außerhalb der Spezifikation und keiner weiß wie lange, aber bei 3,50 das Stück ... Ich denke, dass viele hier im Forum den nanoCul ohne Spannungsteiler mit 5V betreiben. Habe aber noch keinen Beitrag gesehen, in dem jemand über ein defektes CC1101 geschrieben hat.

Zu den Relais kann ich dir sagen, dass die mit Glück auch mit 3,3V laufen. Ich habe zum Basteln 4 2er Module gekauft und 5 oder 6 der Relais schalten auch mit 3,3v. Die restlichen nicht.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 21 Dezember 2016, 20:18:09
Was haltet ihr von dieser Idee?

Links drei(nur Beispiel) Schukosteckdosen mit ihrem Relais.
Rechts unten eine Steckdose für das Steckernetzteil, dass die 5 Volt für die Relais- und Arduinoversorgung bereitstellt.

Wenn man mehr Steckdosen benötigt einfach nach links symmetrisch erweitern.
Wenn man weniger bracht kann was wegfallen.

Kann man eigentlich beruhigt auf die Relais aus China zurückgreifen?
Teilweise gibt es in den Foren kritische Stimmen bezüglich der Spannungsfestigkeit.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 22 Dezember 2016, 16:51:11
Hallo Dietmar,

ich schalte mit "China" Relais schon seit längeren meine 1000W Wasserpumpe im Garten. Habe bisher noch kein Problem gehabt.

Bzgl Deiner Schaltung: genau diese würde ich gerne einmal in eine Steckdosenleiste einbauen, bisher habe ich aber keine gefunden, die dementsprechend Platz hat. Finde bestimmt noch eine.... Die kommt dann ins Wohnzimmer an Stereoanlage, Beamer und Co.

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 22 Dezember 2016, 18:44:13
Ich denke das geht nicht(Steckdose umbauen)  weil die Kaufsteckdosen alle intern alle per Schiene verbunden sind.
Ich habe 4 China Relais bestellt, und suche jetzt nach einem Gehäuse in das ich normale Wandsteckdosen Einbauen will.

Ist bei deinen Tests der Arduino immer (7x24h) empfangsbereit?
Habe wie gesagt nur Sensoren gebaut, die im power_down Mode herrumdösen, nur alle 3 Minuten richtig aufwachen und ihr Datenpaket senden.

Stromverbrauch : 0,040 mA.

Schaltung meinst du ist so ok?
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 23 Dezember 2016, 10:36:36
Hallo Dietmar,

danke für den Tipp mit der Steckdosenleiste. Hatte bisher noch keine geöffnet. Meine Arduinos sind alle 24h/7d im Einsatz und Laufen problemlos. Ganz ganz selten, daß einer Mal das ack nicht zurücksendet. Wäre langfristig noch an AES interessiert.

Wüßte nicht, wie ich die Schaltung anders aufbauen sollte. Wäre vielleicht gut, die Phase über das Relais zu schicken und nicht den Nulleiter. Bin in dem Bereich aber Laie.

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 23 Dezember 2016, 22:32:21
Zitat
...die Phase über das Relais zu schicken und nicht den Nulleiter
so soll es sein.

Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 30 Dezember 2016, 15:44:39
Hi,

wenn ich Pro Minis (5V) verwende, muss ich irgendetwas spezielles beachten? Wir haben ein paar analoge Ausgänge weniger habe ich gesehen. Eigentlich aber kein Problem, die A0 / A1 Abfrage kann man auch softwaretechnisch abfangen.

Sonst noch etwas, was Euch einfällt?

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 30 Dezember 2016, 16:26:35
Ich habe alle bisherigen Projekte mit Pro Minis 3,3V 8Mhz(Batteriebetrieb)  aufgebaut.
Die Pins reichen immer - musst halt eventuell neu zuordnen.

Meine neueste Erungenschaft ist ein HM-SEC-WDS mit 5 Spikes, der alle 15 Sekunden auf Feuchtigkeit bzw. Wasser prüft.
Software steht soweit, zwecks Stromsparen muss ich noch die BetriebsLED herauslösen. Dann sollte der Verbrauch auf weniger als 0,040 mA absinken.

Überlege noch, ob ich eine LED einbaue, die Wasser anzeigt, wäre eine gute Möglichkeit die Funktion zu testen. Würde ja nicht häufig gebraucht.

Im Januar baue ich dann die Steckdosen Leiste(N) . HM-...
Dann kann ich fs20 aufs Altenteil schicken.



Titel: Antw:AskSin++ Library
Beitrag von: papa am 30 Dezember 2016, 20:28:02
Meine neueste Erungenschaft ist ein HM-SEC-WDS mit 5 Spikes, der alle 15 Sekunden auf Feuchtigkeit bzw. Wasser prüft.

Willst Du das vielleicht als Example im Git zur Verfügung stellen ?
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 30 Dezember 2016, 21:02:00
Grundsätzlich  ja!

Ich habe allerdings an diversen Klassen Veränderungen vorgenommen, damit ich die 0,040 mA auch erreiche.
Teilweise auch nur, damit ich verstehe was wie im Framework passiert, bzw. um debuggen zu können

Um beim powerSensor eine genaue Zeit zu bekommen, habe ich eine neue Klasse gebaut, die Resolution von 1/10 auf 1/100 verstellt, um dann doch feststellen zu müssen, dass Interrupts eine auch nur ungefähre Zeitmessung unmöglich machen. Zu guter letzt habe ich eine RTC eingebaut.

Manches erscheint mir noch wackelig, zum Beispiel dann wenn neue kurze  timer(debounce)  in Interrupts erzeugt werden.
Dann wird jedenfalls bei mir offset vom falschen timer abgezogen. LED habe ich komplett abgeklemmt, weil sie bei mir nie funktionierte. Ich glaube es liegt daran, dass am pro mini die LED am 13 nicht funktionieren kann.

Man müsste also erst einmal konsolidieren. Darüber hinaus habe ich keine Lust im Support zu ersticken.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 02 Januar 2017, 11:38:44
Danke, das mit dem Pro Mini läuft absolut perfekt. Werde wohl fast nur noch Pro Minis verwenden wo möglich.

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 02 Januar 2017, 12:51:07
Im Batteriebetrieb kommst du an Pro Minis nicht vorbei.

Im PowerDown modus nach dem Ausbau der LED verbraucht meine Version noch 0,040 mA.
Wenn man LOD noch ausbaut kann man auf 0,004 mA herunterkommen - habe ich aber bisher nicht gemacht.

http://s6z.de/cms/index.php/arduino/nuetzliches/9-winterschlaf-fuer-arduino (http://s6z.de/cms/index.php/arduino/nuetzliches/9-winterschlaf-fuer-arduino)
... und noch viele andere Seiten im Netz.

Mit AskSin++ muss man aber immer nachmessen, da bestimmter Programmcode den tatsächlichen Stromverbrauch beeinflussen kann. So wird beispielsweise in Activity nach jedem Schlafzyklus (8s,..500ms) immer das Funkmodul eingeschaltet, auch wenn nichts gesendet werden soll. Das verbraucht auch ordentlich Strom(im Vergleich zu 0,040 mA).
So hatte ich beispielsweise den Fall, dass zwei aufeinaderfolgende powerDown-Zyklen(8s) mal mit einem Verbrauch von 0,040 mA mal mit 1,7 mA zu Buche schlugen, immer abwechselnd - Ursache schwer nachzuvollziehen.
Weiterhin ist es ratsam im powerDown-Modus alle Verbraucher, wenn möglich abzuschalten. Das war bei meinem powerSensor möglich indem ich den Strom zur RTC und zum SHT21 per PIN bereitstelle und in den Schlafzyklen abstelle.

Für den Bau von schaltbaren Steckdosen wird der Arduino eh nicht in den Stromsparmodus versetzt, so dass dieser Aspekt nicht ins Gewicht fällt.

Gruß Dietmar
Titel: Antw:AskSin++ Library
Beitrag von: Sequenzial am 16 Januar 2017, 07:39:50
Hi Dietmar,

CC1101 und 5 V --> Ich habe 2 nanoCul mit USB, also mit 5V laufen. War einer der ersten der das Modul nachgebaut hat, d. h. die CC1101 laufen seit 2 Jahren permanent .... und sie laufen immer noch. Ist außerhalb der Spezifikation und keiner weiß wie lange, aber bei 3,50 das Stück ... Ich denke, dass viele hier im Forum den nanoCul ohne Spannungsteiler mit 5V betreiben. Habe aber noch keinen Beitrag gesehen, in dem jemand über ein defektes CC1101 geschrieben hat.

Zu den Relais kann ich dir sagen, dass die mit Glück auch mit 3,3V laufen. Ich habe zum Basteln 4 2er Module gekauft und 5 oder 6 der Relais schalten auch mit 3,3v. Die restlichen nicht.

Hi,

kann ich bestätigen.
Die CC1101 laufen stabil mit 5V an den Ein-/Ausgängen.
Wichtig ist nur die 3,3V als Spannungsversorgung (VCC), sonst geht der CC1101 relativ schnell hops.

Ich habe auch mit Levelshiftern rumgebastelt, aber überwiegend Probleme damit gehabt.
Man kann natürlich auch Widerstände vorlöten um die Spannung zu reduzieren.

Funktioniert aber auch ohne.
Bei mir laufen
3 nanoCULs mit 868 Mhz CC1101
1 nanoCUL mit 433 Mhz C1101 und
2 SignalDuinos -> 1x RX6B (sowieso 5V) / 1x CC1101 sowie
ein Lacrosse JeeLink.

Bis auf einen CC1101 laufen alle ohne Spannungswandler.
Werden nicht warm und tun was sie sollen.

Gruß
Seq
Titel: Antw:AskSin++ Library
Beitrag von: 0xFFFF am 16 Januar 2017, 21:14:07
Hi,

gibt es schon eine ungefähre Abschätzung, wann AES verfügbar sein wird? Langfristig ist es für mich keine Option darauf zu verzichten und ich fürchte, dass ich selber leider nicht in der Lage bin da was funktionierendes umzusetzen :(
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Januar 2017, 09:13:23
Ich kann da leider keine seriöse Aussage machen, aber ich bin dabei. Allerdings ist meine zur Verfügung stehende Zeit sehr begrenzt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Januar 2017, 15:48:52
Habe eben den AES Code eingecheckt. Die Beispiele sind alle entsprechend angepasst. Getestet habe ich hauptsächlich mit dem HM-LC-SWX-SM Code.

AES wird mit "#define USE_AES" aktiviert. Es sind dann auch der Key und der Index zu definieren. Doku werde ich die Tage im Readme ergänzen.
Titel: Antw:AskSin++ Library
Beitrag von: 0xFFFF am 21 Januar 2017, 18:39:34
So schnell hätte ich jetzt echt nicht damit gerechnet :D Vielen dank fürs zur Verfügung stellen!
Titel: Antw:AskSin++ Library
Beitrag von: bjoernh am 22 Januar 2017, 19:31:01
Hallo papa.

zuerst vielen Dank für die tolle Arbeit.

Ich möchte mir einen RC1 Sender bauen. Nun bekomme ich es aber irgendwie nicht hin, dass das neue Device nur einen Channel hat.
Ich denke das liegt an der Model ID. Kannst Du mir vielleicht sagen wo ich eine Liste mit den Model IDs finde.
Desweiteren wollte ich meinem RC dann eine Batterieüberwachung hinzufügen. Sehe ich es richtig, dass ich dazu den BatterySensor.h verwenden kann?

Gruß
Björn
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 Januar 2017, 19:58:17
Versuche mal nen HM-RC-P1 - 0x001a

Infos gibt es hier:

https://github.com/eq-3/occu/blob/master/firmware/rftypes/rf_rc.xml

BatterySensor.h ist richtig. Dort gibt es 3 unterschiedliche Varianten. Die einfachste nutzt die interne Messung. Siehe auch HM-SEC-MDIR als Beispiel.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 23 Januar 2017, 20:23:02
models:
  subType          name                       ID supportedMode            Info  List  channels
  --------------------------------------------------------------------------------------------
  AlarmControl     HM-Sec-Cen               004B normal                         1,3
  blindActuator    HM-LC-BL1-FM             0005 normal                         1,3
  blindActuator    HM-LC-Bl1-FM-2           00D2 normal                         1,3
  blindActuator    HM-LC-BL1-PB-FM          0053 normal                         1,3
  blindActuator    HM-LC-Bl1PBU-FM          006A normal                         1,3
  blindActuator    HM-LC-BL1-SM             0006 normal                         1,3
  blindActuator    HM-LC-Bl1-SM-2           00D1 normal                         1,3
  blindActuator    ROTO_ZEL-STG-RM-FEP-230V 007B normal                         1,3
  blindActuator    Schueco_263-146          0086 normal                         1,3
  blindActuator    Schueco_263-147          0087 normal                         1,3
  blindActuatorSol WDF-solar                0096 burst                          1,3   1 win, 2-3 blind,
  dimmer           HM-LC-DIM1L-CV           0012 normal                         1,3
  dimmer           HM-LC-Dim1L-CV-2         00B7 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1L-CV-644       006E normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM1L-PL           0013 normal                         1,3
  dimmer           HM-LC-Dim1L-Pl-2         00A3 normal                         1,3
  dimmer           HM-LC-Dim1L-Pl-3         00B3 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1L-Pl-644       006F normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1PWM-CV         0067 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1PWM-CV-2       00B5 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM1T-CV           0058 normal                         1,3
  dimmer           HM-LC-Dim1T-CV-2         00B9 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1T-CV-644       0072 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM1T-FM           0059 normal                         1,3
  dimmer           HM-LC-Dim1T-FM-2         00BA normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1T-FM-644       0073 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1T-FM-LF        00F5 normal                         1,3
  dimmer           HM-LC-Dim1TPBU-FM        0068 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1TPBU-FM-2      00B6 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM1T-PL           0057 normal                         1,3
  dimmer           HM-LC-Dim1T-Pl-2         00A4 normal                         1,3
  dimmer           HM-LC-Dim1T-Pl-3         00B4 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-Dim1T-Pl-644       0071 normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           HM-LC-DIM2L-CV           0016 normal                         1,3   1-2 Sw,
  dimmer           HM-LC-DIM2L-SM           002E normal                         1,3   1-2 Sw,
  dimmer           HM-LC-Dim2L-SM-2         00B8 normal                         1,3   1-2 Sw, 3-4 Sw1_V, 5-6 Sw2_V,
  dimmer           HM-LC-Dim2L-SM-644       0070 normal                         1,3   1-2 Sw, 3-4 Sw1_V, 5-6 Sw2_V,
  dimmer           HM-LC-DIM2T-SM           005A normal                         1,3   1-2 Sw,
  dimmer           HM-LC-Dim2T-SM           0074 normal                         1,3   1-2 Sw, 3-4 Sw1_V, 5-6 Sw2_V,
  dimmer           HM-LC-Dim2T-SM-2         00BB normal                         1,3   1-2 Sw, 3-4 Sw1_V, 5-6 Sw2_V,
  dimmer           OLIGO-smart-iq-HM        00FC normal                         1,3   1-2 Dim, 3-4 Dim1_V, 5-6 Dim2_V,
  dimmer           Schueco_263-132          0088 normal                         1,3
  dimmer           Schueco_263-133          008A normal                         1,3   1 Sw, 2-3 Sw1_V,
  dimmer           Schueco_263-134          0089 normal                         1,3
                   DORMA_atent              0064 config                         1,3   1-3 Btn,
  keyMatic         HM-SEC-KEY               0019 burst                          1,3
  keyMatic         HM-SEC-KEY-O             0027 burst                          1,3
  keyMatic         HM-SEC-KEY-S             0026 burst                          1,3
  KFM100           KFM-Display              0049 normal                         1,3
  KFM100           KFM-Sensor               0047 config                         1,3

  motionAndBtn     HM-Sen-MDIR-WM55         00DB config,wakeup,lazyConf         1,4   1-2 Btn, 3 Motion,
  motionDetector   HM-SEC-MDIR              004A config,wakeup,lazyConf   00:20 1,4
  motionDetector   HM-SEC-MDIR-2            00C0 config,wakeup,lazyConf   00:20 1,4
  motionDetector   HM-SEC-MDIR-3            00F7 config,wakeup,lazyConf   00:20 1,4
  motionDetector   HM-Sen-MDIR-O            005D config,wakeup,lazyConf   00:10 1,4
  motionDetector   HM-Sen-MDIR-O-2          00C1 config,wakeup,lazyConf   00:10 1,4
  motionDetector   HM-SEN-MDIR-SM           004F config,wakeup,lazyConf         1,4
  motionDetector   Schueco_263-162          0090 config,wakeup,lazyConf   00:30 1,3
  outputUnit       HM-OU-CFM-PL             0075 normal                         3     1 Led, 2 Mp3,
  outputUnit       HM-OU-CFM-TW             00FA config,burst                   3     1 Led, 2 Mp3,
  outputUnit       HM-OU-CF-PL              005C normal                         3     1 Led, 2 Sound,
  outputUnit       HM-OU-CM-PCB             00AF normal                         3
  outputUnit       HM-OU-LED16              006D normal                         ,1    1-16 Led,
  powerMeter       HM-ES-PMSw1-DR           00EA normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl           00AC normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R1     00D7 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R2     00E2 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R3     00E3 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R4     00E4 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-Pl-DN-R5     00E5 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerMeter       HM-ES-PMSw1-SM           00F6 normal                   00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
  powerSensor      HM-ES-TX-WM              00DE config,wakeup            00:10 1     1-2 IEC,
  pushButton       HM-Dis-EP-WM55           00FB config,burst                   1,3   1-2 Dis, 3-9 Key,
  pushButton       HM-Dis-WM55              00D3 config                         1,    1-10 Dis,
  pushButton       HM-PB-2-FM               00BF config,lazyConf                1,4   1-2 Btn,
  pushButton       HM-PB-2-WM               0036 config                         1,4   1-2 Btn,
  pushButton       HM-PB-2-WM55             006B config,wakeup,lazyConf         1,4   1-2 Btn,
  pushButton       HM-PB-2-WM55-2           00C2 config,wakeup,lazyConf         1,4   1-2 Btn,
  pushButton       HM-PB-4DIS-WM            0060 config,wakeup,lazyConf         1,4   1-20 Btn,
  pushButton       HM-PB-4DIS-WM-2          00DD config,wakeup,lazyConf         1,4   1-20 Btn,
  pushButton       HM-PB-4-WM               0035 config                         1,4   1-4 Btn,
  pushButton       HM-PBI-4-FM              0034 config                         1,4   1-4 Btn,
  pushButton       HM-Sen-DB-PCB            00DC config                         1,4
  pushButton       ROTO_ZEL-STG-RM-DWT-10   007E config,wakeup,lazyConf         1,4   1-20 Btn,
  pushButton       ROTO_ZEL-STG-RM-FST-UP4  007F config                         1,4   1-4 Btn,
  pushButton       ROTO_ZEL-STG-RM-WT-2     007D config,wakeup,lazyConf         1,4
  pushButton       Schueco_263-135          008D config,wakeup,lazyConf         1,4
  pushButton       Schueco_263-145          008F config                         1,4
  remote           CMM                      0018 normal                         3
  remote           DORMA_RC-H               0054 config                         1,3
  remote           HM-MOD-Em-8              00D9 lazyConf                       1,4   1-8 Btn,
  remote           HM-PB-6-WM55             00A9 config,wakeup,lazyConf         1,4   1-6 Btn,
  remote           HM-RC-12                 0029 config                         1,4   1-12 Btn,
  remote           HM-RC-12-B               002A config                         1,4   1-12 Btn,
  remote           HM-RC-12-SW              004C config                         1,4   1-12 Btn,
  remote           HM-RC-19                 0037 config,burst                   1,1.2p.3p.4p.5p.6p.7p.8p.9p.10p.11p.12p.13p.14p.15p.16p 1-17 Btn, 18 Disp,
  remote           HM-RC-19-B               0038 config,burst                   1,1.2p.3p.4p.5p.6p.7p.8p.9p.10p.11p.12p.13p.14p.15p.16p 1-17 Btn, 18 Disp,
  remote           HM-RC-19-SW              004D config,burst                   1,1.2p.3p.4p.5p.6p.7p.8p.9p.10p.11p.12p.13p.14p.15p.16p 1-17 Btn, 18 Disp,
  remote           HM-RC-2-PBU-FM           00E0 normal                         1,4   1-2 Btn,
  remote           HM-RC-4                  0008 config                         1,4   1-4 Btn,
  remote           HM-RC-4-2                00A0 config,lazyConf                1,4   1-4 Btn,
  remote           HM-RC-4-3                00D4 config,wakeup,lazyConf         1,4   1-4 Btn,
  remote           HM-RC-4-3-D              00F8 config,wakeup,lazyConf         1,4   1-4 Btn,
  remote           HM-RC-4-B                003B config                         1,4   1-4 Btn,
  remote           HM-RC-8                  00DA config,wakeup,lazyConf         1,4   1-8 Btn,
  remote           HM-RC-Dis-H-x-EU         00E1 config,wakeup,lazyConf         1,4   1-20 Btn,
  remote           HM-RC-KEY3               001D config                         1,4   1-3 Btn,
  remote           HM-RC-KEY3-B             001E config                         1,4   1-3 Btn,
  remote           HM-RC-Key4-2             00A6 config,lazyConf                1,4   1 unlock, 2 lock, 3 light, 4 open,
  remote           HM-RC-Key4-3             00D6 config,lazyConf                1,4   1 unlock, 2 lock, 3 light, 4 open,
  remote           HM-RC-P1                 001A config                         1,4
  remote           HM-RC-SEC3               001B config                         1,4   1-3 Btn,
  remote           HM-RC-SEC3-B             001C config                         1,4   1-3 Btn,
  remote           HM-RC-Sec4-2             00A5 config,lazyConf                1,4   1 armInt, 2 armExt, 3 light, 4 disarm,
  remote           HM-RC-Sec4-3             00D5 config,lazyConf                1,4   1 armInt, 2 armExt, 3 light, 4 disarm,
  remote           ROTO_ZEL-STG-RM-HS-4     0080 config                         1,4
  remote           Schueco_263-155          008E config                         1,4
  repeater         HM-Sys-sRP-Pl            0076 normal                         ,2
  rgb              HM-LC-RGBW-WM            00F4 normal                         1,3   1 Dim, 2 Color, 3 Auto,
  senBright        HM-Sen-LI-O              00FD config,wakeup            00:10 1
  sensor           HM-SEN-EP                0044 config,wakeup                  1,4   1-2 Sen,
  sensor           HM-Sen-Wa-Od             009F config,wakeup            28:00 1,4
  sensRain         HM-Sen-RD-O              00A7 normal                         1,1   1 Rain, 2 Heating,
  singleButton     DORMA_BRC-H              0065 config                         1,3   1-4 Btn,
  siren            HM-Sec-Sir-WM            00F9 config,burst                   1,3   1-2 Sen, 3 Panic, 4 Arm,
  smokeDetector    HM-CC-SCD                0056 config,wakeup            28:00 1,4
  smokeDetector    HM-SEC-SD                0042 burst                    99:00
  smokeDetector    HM-SEC-SD-2              00AA config,3Burst            99:00
  smokeDetector    Schueco_263-160          0084 config,wakeup                  1,4
  smokeDetector    Schueco_263-167          0091 burst                    99:00
  swi              HM-SWI-3-FM              0046 config                         4     1-3 Sw,
  swi              Roto_ZEL-STG-RM-FSS-UP3  0083 config                         4
  switch           HM-Dis-TD-T              0078 burst                          3
  switch           HM-LC-DDC1-PCB           004E normal                         1,3
  switch           HM-LC-SW1-BA-PCB         006C burst                          1,3
  switch           HM-LC-Sw1-DR             00F0 normal                         1,3
  switch           HM-LC-SW1-FM             0004 normal                         1,3
  switch           HM-LC-Sw1-FM-2           00CA normal                         1,3
  switch           HM-LC-SW1-PB-FM          0051 normal                         3
  switch           HM-LC-Sw1PBU-FM          0069 normal                         1,3
  switch           HM-LC-Sw1-PCB            0103 normal                         1,3   1-4 Sw,
  switch           HM-LC-SW1-PL             0011 normal                         1,3
  switch           HM-LC-SW1-PL2            00A1 normal                         1,3
  switch           HM-LC-Sw1-Pl-3           00C8 normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R1       00EB normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R2       00EC normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R3       00ED normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R4       00EE normal                         1,3
  switch           HM-LC-Sw1-Pl-CT-R5       00EF normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R1       00D8 normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R2       00E6 normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R3       00E7 normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R4       00E8 normal                         1,3
  switch           HM-LC-Sw1-Pl-DN-R5       00E9 normal                         1,3
  switch           HM-LC-SW1-PL-OM54        0001 normal                         1,3
  switch           HM-LC-SW1-SM             0002 normal                         1,3
  switch           HM-LC-Sw1-SM-2           00C9 normal                         1,3
  switch           HM-LC-SW1-SM-ATMEGA168   0014 normal                         3
  switch           HM-LC-SW2-DR             0062 normal                         1,3   1-2 Sw,
  switch           HM-LC-Sw2-DR-2           00CC normal                         1,3   1-2 Sw,
  switch           HM-LC-SW2-FM             0009 normal                         1,3   1-2 Sw,
  switch           HM-LC-Sw2-FM-2           00CB normal                         1,3   1-2 Sw,
  switch           HM-LC-SW2-PB-FM          0052 normal                         3     1-2 Sw,
  switch           HM-LC-Sw2PBU-FM          0101 normal                         1,3   1-2 Sw,
  switch           HM-LC-SW2-SM             000A normal                         1,3   1-2 Sw,
  switch           HM-LC-SW4-BA-PCB         00AB burst                          1,3   1-4 Sw,
  switch           HM-LC-SW4-DR             0061 normal                         1,3   1-4 Sw,
  switch           HM-LC-Sw4-DR-2           00D0 normal                         1,3   1-4 Sw,
  switch           HM-LC-SW4-PCB            002D normal                         1,3   1-4 Sw,
  switch           HM-LC-Sw4-PCB-2          00CE normal                         1,3   1-4 Sw,
  switch           HM-LC-SW4-SM             0003 normal                         1,3   1-4 Sw,
  switch           HM-LC-Sw4-SM-2           00CD normal                         1,3   1-4 Sw,
  switch           HM-LC-SW4-SM-ATMEGA168   0015 normal                         1,3   1-4 Sw,
  switch           HM-LC-SW4-WM             0066 normal                         1,3   1-4 Sw,
  switch           HM-LC-Sw4-WM-2           00CF normal                         1,3   1-4 Sw,
  switch           HM-MOD-Re-8              00BE burst                          1,3   1-8 Sw,
  switch           HM-SEC-SFA-SM            0050 normal                         1,3   1 Siren, 2 Flash,
  switch           PS-switch                8001 normal                         1,3   1-4 Sw,
  switch           ROTO_ZEL-STG-RM-FZS      007C normal                         1,3
  switch           ROTO_ZEL-STG-RM-FZS-2    00A2 normal                         1,3
  switch           Schueco_263-130          008B normal                         1,3
  switch           Schueco_263-131          008C normal                         1,3
  switch           Schueco_263-144          0092 config                         1,3
  thermostat       HM-CC-RT-DN              0095 config,wakeup,burstCond  00:10 1.2p.4p.5p.6p,3p.6p,1,3p.4 1 Weather, 2 Climate, 3 WindowRec, 4 Clima, 5 ClimaTeam, 6 remote,
  thermostat       HM-CC-RT-DN-BoM          00BD config,wakeup,burstCond  00:10 1.2p.4p.5p.6p,3p.6p,1,3p.4 1 Weather, 2 Climate, 3 WindowRec, 4 Clima, 5 ClimaTeam, 6 remote,
  thermostat       HM-CC-TC                 0039 config,wakeup,burstCond  00:10 2,2.3p,2 1 Weather, 2 Climate, 3 WindowRec,
  thermostat       HM-CC-VD                 003A config,wakeup            28:00 ,5
  thermostat       HM-TC-IT-WM-W-EU         00AD config,burst             00:10 1.2p.6p.7p,3p.6p,1,2.3p.7p,2,2 1 Weather, 2 Climate, 3 WindowRec, 6 remote, 7 SwitchTr,
  thermostat       ROTO_ZEL-STG-RM-FSA      007A config,wakeup            28:00 ,5
  thermostat       ROTO_ZEL-STG-RM-FWT      0079 config,wakeup,burstCond  00:10 2,2.3p,2 1 Weather, 2 Climate, 3 WindowRec,
  threeStateSensor HM-SCI-3-FM              005F config,wakeup            28:00 1,4   1-3 Sw,
  threeStateSensor HM-SEC-RHS               0030 config                   28:00 1,4
  threeStateSensor HM-SEC-RHS-2             00C3 config,wakeup            28:00 1,4
  threeStateSensor HM-SEC-SC                002F config                   28:00 1,4
  threeStateSensor HM-SEC-SC-2              00B1 config,wakeup,lazyConf   28:00 1,4
  threeStateSensor HM-SEC-SCo               00C7 config,wakeup,lazyConf   00:50 1,4
  threeStateSensor HM-SEC-TIS               0043 config,wakeup            28:00 1,4
  threeStateSensor HM-SEC-WDS               0045 config,wakeup            28:00 1,4
  threeStateSensor HM-SEC-WDS-2             00B2 config,wakeup            28:00 1,4
  threeStateSensor ROTO_ZEL-STG-RM-FDK      0081 config,wakeup            28:00 1,4
  threeStateSensor Roto_ZEL-STG-RM-FFK      0082 config,wakeup            28:00 1,4
  THSensor         ASH550                   000D config,wakeup,burstCond  00:10
  THSensor         ASH550I                  000E config,wakeup,burstCond  00:10
  THSensor         HM-WDC7000               0041 normal                   00:10 1,4
  THSensor         HM-WDS100-C6-O           0040 config,wakeup            00:10 ,1,1p
  THSensor         HM-WDS100-C6-O-2         00AE config,wakeup,burst      00:10 4
  THSensor         HM-WDS10-TH-O            003D config,burstCond,wakeup  00:10
  THSensor         HM-WDS20-TH-O            003C config,burstCond         00:10
  THSensor         HM-WDS30-OT2-SM          00A8 config,wakeup,burstCond  12:00       1 T1, 2 T2, 3 T1_T2, 4 T2_T1, 5 Event,
  THSensor         HM-WDS30-OT2-SM-2        0102 config,wakeup,burstCond  12:00       1 T1, 2 T2, 3 T1_T2, 4 T2_T1, 5 Event,
  THSensor         HM-WDS30-T-O             003E config,wakeup            00:10
  THSensor         HM-WDS40-TH-I            003F config,burstCond         00:10
  THSensor         HM-WDS40-TH-I-2          00BC config,burstCond         00:10
  THSensor         HM-WS550                 000B normal
  THSensor         HM-WS550LCB              0031 normal
  THSensor         HM-WS550LCW              0032 normal
  THSensor         HM-WS550Tech             002B normal
  THSensor         IS-WDS-TH-OD-S-R3        0048 config,wakeup,burstCond  00:10
  THSensor         KS550                    0007 config,wakeup            00:10 ,1,1p
  THSensor         KS550LC                  0033 config,wakeup            00:10 ,1,1p
  THSensor         KS550TECH                002C config,wakeup            00:10 ,1,1p
  THSensor         KS888                    001F config,wakeup            00:10 ,1,1p
  THSensor         PS-Th-Sens               8002 normal                         1,4   1-4 Sen,
  THSensor         S550IA                   000F config,wakeup            00:10
  THSensor         Schueco_263-157          0094 config,wakeup            00:10
  THSensor         Schueco_263-158          0093 config,wakeup,burstCond  00:10
  timer            SensoTimer-ST-6          00F3 config,burst                   1,5.6p.7p.8p.9p 1-2 Sw, 3-4 Sen, 5-7 Key, 8-9 ecoKey,
  tipTronic        Schueco_263-xxx          009B config,wakeup            28:00 1.2,1.3p 1 act, 2 sen, 3 sec,
  virtual          CCU-FHEM                 FFF0 normal                               1-50 Btn,
  winMatic         HM-SEC-WIN               0028 burst                          1,1   1 Win, 2 Akku,
                   WS888                    0022 normal                         1,3

Titel: Antw:AskSin++ Library
Beitrag von: plombe am 31 Januar 2017, 20:26:29
Beim Testen der Lib für HM-LC-SWX-SM stellte ich fest,  dass ein wiederholtes Pairing bei bereits gepairtem Gerät über den Config Button zum Aufhängen der Software
führt. In Device.h habe ich alle delay() durch _delay_ms() ersetzt. Damit ist das Problem behoben. War das o.k so ?

Hans-Georg
Titel: Antw:AskSin++ Library
Beitrag von: papa am 31 Januar 2017, 21:53:53
In Device.h habe ich alle delay() durch _delay_ms() ersetzt. Damit ist das Problem behoben. War das o.k so ?

Keine Ahnung. Werde dasmal so übernehmen. Was ich so auf die Schnelle im Web gefunden habe - die _delay_ms ist unabhängig von Interrupts.
Titel: Antw:AskSin++ Library
Beitrag von: CitationJet am 01 Februar 2017, 22:16:30
Tolles Projekt! Funktioniert auch ohne AES hervorragend. Die Pin-Definitionen konnte ich zur Benutzung mit einer nanoCUL umbauen, in der Radio_ProMini.cpp:
#define CC_GDO0_DDR            DDRD                   // GDO0 pin, signals received data
#define CC_GDO0_PORT           PORTD
#define CC_GDO0_PIN            PORTD3

#define CC_GDO0_PCICR          PCICR                  // GDO0 interrupt register
#define CC_GDO0_PCIE           PCIE2
#define CC_GDO0_PCMSK          PCMSK2                 // GDO0 interrupt mask
#define CC_GDO0_INT            PCINT19                  // pin interrupt
#define CC_GDO0_INTPIN         3

void CC1101::enableGDO0Int(void) {
  ::attachInterrupt(digitalPinToInterrupt(CC_GDO0_INTPIN), radioISR, FALLING);
}

void CC1101::disableGDO0Int(void) {
  ::detachInterrupt(digitalPinToInterrupt(CC_GDO0_INTPIN));
}

Leider habe ich mit AES im Beispiel HM-RC-4 ein paar Probleme:
in meiner VCCU steht als Attribut (Beispiel): hmKey      01:abcdef000102(usw...)
Dann muss ich im Kopf ja angeben:
#define USE_AES
#define HM_DEF_KEY 0xab,0xcd,0xef,0x00,0x01,0x02(usw...)
#define HM_DEF_KEY_INDEX 2
Da mag er nicht richtig signieren, wenn ich in FHEM für Device+Buttons aesCommReq auf 1 setze und einen Button betätige:
CUL_HM HM_789012 aesCommToDev: pending
CUL_HM HM_789012 aesCommToDev: pending
CUL_HM HM_789012 aesCommToDev: pending
CUL_HM HM_789012 aesCommToDev: pending
CUL_HM HM_789012 aesCommToDev: pending
CUL_HM HM_789012 aesCommToDev: pending
Umgekehrt habe ich mal set HM_789012 assignHmKey probiert, da meldet mir der Nano allerdings Signature FAILED zurück.
Habe schon probiert, in der Library den Homematic-Standardkey A4E375C6B09FD185F27C4E96FC273AE4 mit Index 0 zu hinterlegen, hat aber auch nicht funktioniert.
Ebenfalls nicht funktioniert hat das Umdrehen der Bytes, also im Beispiel oben
#define HM_DEF_KEY (usw...),0x02,0x01,0x00,0xef,0xcd,0xab
Titel: Antw:AskSin++ Library
Beitrag von: CitationJet am 01 Februar 2017, 22:55:21
Als Nachtrag noch eine kurze Vorstellung, was ich vor habe:

Ich möchte das alte Keymatic-Codeschloss nachbauen, das ja leider nie in einer Homematic-Version produziert wurde.
Wie das ursprüngliche Gerät soll es batteriebetrieben und direkt mit der Keymatic koppelbar sein.
Mit den verschiedenen Kanälen kann man neben Schließen und Öffnen auch gleich die Türklingel realisieren.

Mir schwirren auch noch ein paar Ideen zur Erhöhung der Sicherheit durch den Kopf, wie eine Ableitung des Homematicschlüssels aus der Geheimzahl, wodurch der Schlüssel nicht im Klartext im EEPROM steht (obwohl es schon unwahrscheinlich ist, dass jemand sich die Mühe macht).
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 Februar 2017, 09:27:52
Der Standardkey sollte auf jeden Fall gehen. Am besten mal folgendes versuchen:

* Code mit Standardkey und Index 0 erstellen und flashen
* EProm komplett neu initialisieren - also den Config-Button mindestens 6 Sekunden drücken
* assignHmKey ausführen

Es müsste dann eine Debug-Ausgabe mit dem neuen Key und dem Index kommen.

Wenn der Key im Code geändert wird, muss auch der EProm neu initialisiert werden, da sonst die alten, gespeicherten Daten verwendet werden. Vielleicht sollte ich den Keyinhalt mit in die Berechnung der Prüfsumme aufnehmen, die beim Start prüft, ob der EProm initialisiert werden muss.

Edit: Der letzte Satz ist Blödsinn, da dann nach Setzen eines neuen Keys beim nächsten Start der EProm neu eingerichtetw wird.
Titel: Antw:AskSin++ Library
Beitrag von: CitationJet am 02 Februar 2017, 18:42:12
Danke - der Fehler lag wohl im Gerätetyp HM-RC-4. Es funktioniert prinzipiell wie es soll, nachdem ich den Gerätetyp im HM-RC-4-Beispielsketch auf HM-RC-Key4-3 (sdev.setModel(0x00,0xD6);) gestellt habe. Pairing mit Keymatic funktioniert auch, allerdings kann man nach Drücken des Configbuttons nur 1x ein Kommando pro Kanal senden.
Siehe Nachtrag ein Beitrag weiter

Zum Test habe ich in FHEM den Arduino (vorher 6 Sekunden Configbutton f. Reset) gepairt, ohne Peering mit der Keymatic. In der VCCU habe ich einen Testschlüssel 01:11111111111111111111111111111111 gesetzt, danach:
set HM_789012 assignHmKey
set HM_789012.* regSet sign on
attr HM_789012.* aesCommReq 1
Ist alles durchgelaufen und das Hinterlegen des Schlüssels wurde auf der seriellen Ausgabe gemeldet.

Wenn ich anschließend den Configbutton kurz drücke und danach eine Taste, passiert fehlerfrei folgendes:
### Devicelog:
2017-02-02_18:16:23 HM_789012 D-firmware: 1.1
2017-02-02_18:16:23 HM_789012 D-serialNr: papa333333
2017-02-02_18:16:23 HM_789012 CMDs_done
2017-02-02_18:16:26 HM_789012 aesCommToDev: pending
2017-02-02_18:16:26 HM_789012 aesCommToDev: ok
2017-02-02_18:16:26 HM_789012 battery: ok
2017-02-02_18:16:26 HM_789012 CMDs_done
2017-02-02_18:16:26 HM_789012 HM_789012_unlock Short

### CUL:
2017.02.02 18:16:23.581 4: TSCUL_Parse: rf_nanocul_868  244872 A FF01 03515364 00 1A 07 A000 789012 42F0FF 1100D67061706133333333333340040000 -61
2017.02.02 18:16:23.601 4: TSCUL_send:  rf_nanocul_868                         As 0A 07 8002 42F0FF 789012 00
2017.02.02 18:16:23.601 3: TSCUL_XmitDlyHM:  rf_nanocul_868  id:789012 dDly:83 toms:32
2017.02.02 18:16:23.718 4: TSCUL_Parse: rf_nanocul_868  245018 A FF03 03515484 01 0A 07 8002 42F0FF 789012 00 _CCAdly:4 _dhmSt:120 -138
2017.02.02 18:16:26.558 4: TSCUL_Parse: rf_nanocul_868  247858 A FF01 03518352 00 0B 0D A040 789012 42F0FF 0100 -65.5
2017.02.02 18:16:26.573 4: TSCUL_send:  rf_nanocul_868                         As 11 0D A002 42F0FF 789012 040F596B68091302
2017.02.02 18:16:26.574 3: TSCUL_XmitDlyHM:  rf_nanocul_868  id:789012 dDly:93 toms:33
2017.02.02 18:16:26.709 4: TSCUL_Parse: rf_nanocul_868  248009 A FF03 03518472 01 11 0D A002 42F0FF 789012 04 _CCAdly:4 _dhmSt:120 -138
2017.02.02 18:16:26.759 4: TSCUL_Parse: rf_nanocul_868  248050 A FF01 03518544 00 19 0D 8003 789012 42F0FF AAF19BB20CE4FBB77C14C65BA479F930 -59.5
2017.02.02 18:16:26.779 4: TSCUL_send:  rf_nanocul_868                         As 0E 0D 8002 42F0FF 789012 00604ce697
2017.02.02 18:16:26.779 3: TSCUL_XmitDlyHM:  rf_nanocul_868  id:789012 dDly:81 toms:33
2017.02.02 18:16:26.898 4: TSCUL_Parse: rf_nanocul_868  248198 A FF03 03518664 01 0E 0D 8002 42F0FF 789012 00 _CCAdly:4 _dhmSt:120 -138

### Seriell:
 debounce
 pressed
 released
<- 1A 07 A0 00 78 90 12 42 F0 FF 11 00 D6 70 61 70 61 33 33 33 33 33 33 40 04 00 00
waitAck: 01

01 debounce
01 pressed
01 released
<- 0B 0D A0 40 78 90 12 42 F0 FF 01 00
Process Challenge - Key: 02
<- 19 0D 80 03 78 90 12 42 F0 FF AA F1 9B B2 0C E4 FB B7 7C 14 C6 5B A4 79 F9 30
waitAck: 01
01
-> 0E 0D 80 02 42 F0 FF 78 90 12 00 60 4C E6 97

Wenn ich allerdings einige Zeit später nochmal die gleiche Taste drücke, passiert dies:
### Devicelog:
2017-02-02_18:19:58 HM_789012 aesCommToDev: pending

### CUL:
2017.02.02 18:19:58.940 4: TSCUL_Parse: rf_nanocul_868  460238 A FF01 03730848 00 0B 0E A040 789012 42F0FF 0100 -50
2017.02.02 18:19:58.961 4: TSCUL_send:  rf_nanocul_868                         As 11 0E A002 42F0FF 789012 04310D5F91ECC602
2017.02.02 18:19:58.962 3: TSCUL_XmitDlyHM:  rf_nanocul_868  id:789012 dDly:83 toms:33
2017.02.02 18:19:59.088 4: TSCUL_Parse: rf_nanocul_868  460388 A FF03 03730968 01 11 0E A002 42F0FF 789012 04 _CCAdly:4 _dhmSt:120 -138
2017.02.02 18:19:59.324 4: TSCUL_Parse: rf_nanocul_868  460624 A FF03 03731204 01 11 0E A002 42F0FF 789012 04 _CCAdly:4 _dhmSt:356 -138
2017.02.02 18:19:59.559 4: TSCUL_Parse: rf_nanocul_868  460859 A FF03 03731440 01 11 0E A002 42F0FF 789012 04 _CCAdly:4 _dhmSt:592 -138
2017.02.02 18:19:59.760 1: TSCUL_ParseTsHM rf_nanocul_868 HM repeat failed sending to 789012/HM_789012: AFF00000E3C3600110EA00242F0FF78901204
2017.02.02 18:19:59.761 4: TSCUL_Parse: rf_nanocul_868  461060 A FF00 03731672 00 11 0E A002 42F0FF 789012 04 _sfail -138

### Seriell:
01 debounce
01 released
<- 0B 0E A0 40 78 90 12 42 F0 FF 01 00
Process Challenge - Key: 02
<- 19 0E 80 03 78 90 12 42 F0 FF 56 91 5E 03 78 93 FA A0 A4 1B 15 9F 15 9C A3 53
waitAck: 01
01
Anbei auch mein Sketch, bei dem ich die Button- und LED-Ports für das Ausführen auf einer nanoCUL-Hardware angepasst habe, und die geänderte Radio_ProMini.cpp für nanoCUL.
Titel: Antw:AskSin++ Library
Beitrag von: CitationJet am 02 Februar 2017, 23:01:38
Nachtrag: Das Bedienen der anderen Tasten funktioniert, egal wie oft, ziemlich genau 20 Sekunden lang, nachdem man den Configbutton kurz gedrückt hat. Anschließend kommen die aesCommToDev: pending Meldungen bei jedem Tastendruck, bis man erneut den Configbutton drückt. Das gleiche auch nach einem Powercycle des Arduino, man muss erst einmal den Configbutton kurz drücken, sonst kommen auch die Pending-Meldungen.

Edit: Ich nehme mal an, es hängt mit diesen Zeilen in MultiChannelDevice.h zusammen:
activity.stayAwake( seconds2ticks(20) ); // 20 seconds

Edit2: Mit folgendem Hack im Sketchfile in der BtnChannel-Klasse funktioniert es jetzt immer ohne Configbutton-Drücken:
  virtual void state(uint8_t s) {
    DHEX(number());
    Button::state(s);
    if( s == released ) {
      repeatcnt=0;
      msg.init(++msgcnt,number(),repeatcnt,false);
      device().sendPeerEvent(msg,*this);
      activity.stayAwake(millis2ticks(500));    // <- HACK
    }
    else if( s == longpressed ) {
      msg.init(++msgcnt,number(),repeatcnt++,true);
      device().sendPeerEvent(msg,*this);
      activity.stayAwake(millis2ticks(500));    // <- HACK
    }
  }
Ich vermute ohne den Hack ist das Radio nicht Awake und kann die AES-Signrequest nicht empfangen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Februar 2017, 10:04:03
Hm - interessant. Die Abarbeitung der Aes-Signierung sollte eigentlich komplett in der Device::send() durchgeführt werden. Hier wird nach dem Senden einer Nachricht aktive auf die Antwort gewartet. Wenn es ein Ack ist geht es einfach raus. Ist es eine Aes-Challenge, wird diese abgearbeitet. Ich denke, hier liegt irgendwo der Fehler. Ich hatte letztens auch komischerweise Acks wo ich eigentlich Nacks erwartet hatte. Allerdings hatte ich noch keine Zeit, mir das mal genauer anzusehen. Unter Umständen gibt es noch Probleme in der waitResponse und der folgenden Auswertung.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Februar 2017, 20:08:48
Ich habe Device::send() gerade gefixed. Bitte nochmal ohne den Hack probieren.
Titel: Antw:AskSin++ Library
Beitrag von: CitationJet am 03 Februar 2017, 22:28:53
Funktioniert ohne den Hack leider nicht. Wieder AES Pendingmeldungen, die man per Configbuttondrücken für 20 Sekunden lösen kann.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 Februar 2017, 11:37:12
Funktioniert ohne den Hack leider nicht. Wieder AES Pendingmeldungen, die man per Configbuttondrücken für 20 Sekunden lösen kann.

Kannst Du bitte nochmal die Debug-Messages aufzeichnen. Und dabei bitte noch das "response.dump()" in waitResponse mit reinnehmen.
Titel: Antw:AskSin++ Library
Beitrag von: CitationJet am 04 Februar 2017, 18:14:08
2017.02.04 18:12:45.562 4: TSCUL_Parse: rf_nanocul_868  336109 A FF01 08421540 00 0B 01 A040 789012 42F0FF 0100 -47.5
2017.02.04 18:12:45.578 4: TSCUL_send:  rf_nanocul_868                         As 11 01 A002 42F0FF 789012 0470B4484E016902
2017.02.04 18:12:45.699 4: TSCUL_Parse: rf_nanocul_868  336248 A FF03 08421660 01 11 01 A002 42F0FF 789012 04 _CCAdly:4 -138
2017.02.04 18:12:45.935 4: TSCUL_Parse: rf_nanocul_868  336483 A FF03 08421896 01 11 01 A002 42F0FF 789012 04 _CCAdly:4 -138
2017.02.04 18:12:46.171 4: TSCUL_Parse: rf_nanocul_868  336719 A FF03 08422132 01 11 01 A002 42F0FF 789012 04 _CCAdly:4 -138
2017.02.04 18:12:46.375 1: TSCUL_ParseTsHM rf_nanocul_868 HM repeat failed sending to 789012/HM_789012: AFF0002A020F7001101A00242F0FF78901204
2017.02.04 18:12:46.376 4: TSCUL_Parse: rf_nanocul_868  336923 A FF00 08422364 00 11 01 A002 42F0FF 789012 04 _sfail -138
AskSin++ V0.3.0
CC init12................................3 - ready
01 debounce
01 pressed
01 released
<- 0B 01 A0 40 78 90 12 42 F0 FF 01 00
11 01 A0 02 42 F0 FF 78 90 12 04 70 B4 48 4E 01 69 02
Process Challenge - Key: 02
<- 19 01 80 03 78 90 12 42 F0 FF 2F BD 59 C4 3F 5E 67 E3 7A 4C 6D F0 EB 18 3B C8
waitAck: 01
01
Key ist immernoch 01:11111111111111111111111111111111
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 Februar 2017, 19:20:46
Und jetzt ? Hab noch ne kleine Anpassung gemacht.
Titel: Antw:AskSin++ Library
Beitrag von: CitationJet am 05 Februar 2017, 17:45:46
Bingo - funktioniert einwandfrei. Vielen Dank!
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 Februar 2017, 18:27:42
Sehr schön. Aber warum der TS_CUL einen Fehler signalisiert, wenn ich das letzte Ack nicht empfange, verstehe ich noch nicht ganz. Eine Antwort kriegt er darauf auf jeden Fall nicht. Egal - jetzt geht es ja.
Titel: Antw:AskSin++ Library
Beitrag von: CitationJet am 05 Februar 2017, 18:47:21
Also jetzt wo es funktioniert sieht das TSCUL-Log so aus:
2017.02.05 18:45:57.159 4: TSCUL_Parse: rf_nanocul_868  123034 A FF01 12976332 00 0B 0D A040 789012 42F0FF 0100 -53.5
2017.02.05 18:45:57.173 4: TSCUL_send:  rf_nanocul_868                         As 11 0D A002 42F0FF 789012 04B5021BED386302
2017.02.05 18:45:57.174 3: TSCUL_XmitDlyHM:  rf_nanocul_868  id:789012 dDly:91 toms:33
2017.02.05 18:45:57.311 4: TSCUL_Parse: rf_nanocul_868  123187 A FF03 12976452 01 11 0D A002 42F0FF 789012 04 _CCAdly:4 _dhmSt:120 -138
2017.02.05 18:45:57.366 4: TSCUL_Parse: rf_nanocul_868  123234 A FF01 12976532 00 19 0D A003 789012 42F0FF 99A8464A39105F13291D612EA51F956F -52.5
2017.02.05 18:45:57.386 4: TSCUL_send:  rf_nanocul_868                         As 0E 0D 8002 42F0FF 789012 0047e6f2f0
2017.02.05 18:45:57.387 3: TSCUL_XmitDlyHM:  rf_nanocul_868  id:789012 dDly:78 toms:33
2017.02.05 18:45:57.505 4: TSCUL_Parse: rf_nanocul_868  123381 A FF03 12976652 01 0E 0D 8002 42F0FF 789012 00 _CCAdly:4 _dhmSt:120 -138
Er scheint also im letzten Schritt noch eine Nachricht zu bekommen, die ihm vorher gefehlt hat.
Titel: Antw:AskSin++ Library
Beitrag von: plombe am 08 Februar 2017, 22:05:50
Folgender Testaufbau:
Arduino Pro Mini 8MHz 3,3V mit CC1101
HM-WDS10-TH-O  Testmesswerte alle 60 Sekunden.
Stromaufnahme im Sleep Modus  in den ersten  8 Sekunden 4,65µA, dann beim nächsten Durchlauf der Schleife 1,73 mA.
Das wechselte so bis die Zeit abgelaufen war.

Der Grund liegt in Radio.cpp. Hier die Lösung:

void    CC1101::setIdle() { // put CC1101 into power-down state
// strobe(CC1101_SIDLE); // coming from RX state, we need to enter the IDLE state first
// strobe(CC1101_SFRX);
        uint8_t cnt = 0xff;
        while(cnt-- && (strobe( CC1101_SIDLE ) & 0x70) != 0) _delay_us(10);
strobe(CC1101_SPWD); // enter power down state
//dbg << "pd\n";
}

uint8_t CC1101::strobe(uint8_t cmd) { // send command strobe to the CC1101 IC via SPI
ccSelect(); // select CC1101
waitMiso(); // wait until MISO goes low
//        ccSendByte(cmd); // send strobe command
uint8_t ret = ccSendByte(cmd); // send strobe command
  ccDeselect(); // deselect CC1101
        return ret;
}

In Radio.h
//void    strobe(uint8_t cmd);                              // send command strobe to the CC1101 IC via SPI
uint8_t    strobe(uint8_t cmd);                              // send command strobe to the CC1101 IC via SPI


Die Lösung ist aus culfw.
Ich hoffe, damit Anderen langes Suchen zu ersparen.

Hans-Georg
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Februar 2017, 08:29:16
Danke - werde ich einbauen.
Titel: Antw:AskSin++ Library
Beitrag von: plombe am 10 Februar 2017, 11:27:05
Der Watchdog Timer im Tiefschlaf des Arduino's  ist bekannlich nicht so genau. Im Nachbau des Universalsensors von Dirk nutze ich eine Möglichkeit, die Genauigkeit der Zeitmessung  zu verbessern. Damit ergibt sich auch im Tiefschlaf eine Genauigkeit, die annähernd der des Timer1 entspricht, und zwar unabhängig von Temperatur und Versorgungsspannung.
Einschränkung: Interrupt durch Tastendruck.
Um diese Verbesserung nutzen zu können, muß in der Datei Activity.h folgendes geändert werden:
//      LowPower.powerDown(SLEEP_8S,ADC_OFF,BOD_OFF);
      LowPower.delay(8000);
........
//      LowPower.powerDown(SLEEP_1S,ADC_OFF,BOD_OFF);
      LowPower.delay(1000);

Die angehängte Datei statt der Low-Power Bibliothek benutzen.
Viel Erfolg beim Ausprobieren.
Hans-Georg
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 10 Februar 2017, 17:47:59
Stromaufnahme im Sleep Modus  in den ersten  8 Sekunden 4,65µA, dann beim nächsten Durchlauf der Schleife 1,73 mA.
Das wechselte so bis die Zeit abgelaufen war.

Ja, das grundsätzliche Problem ist aber, daß durch eine ungünstige Konstellation ein bereits im Idle-Mode befindlicher CC1101 nochmals in Idle geschickt wird. Dabei wacht er dann aber auf - bekommt aber nicht mehr mit, daß jetzt doch wieder ein Idle-Command kommt und bleibt deshalb eine Periode lang wach.
Der Fehler liegt in der alten AskSin-Lib (fehlerhafte Auswertung des CC1101-Status sowie ungünstige Abarbeitungsreihenfolgen, die letztendlich zu dem Verhalten führen)

void    CC1101::setIdle() { // put CC1101 into power-down state
// strobe(CC1101_SIDLE); // coming from RX state, we need to enter the IDLE state first
// strobe(CC1101_SFRX);
        uint8_t cnt = 0xff;
        while(cnt-- && (strobe( CC1101_SIDLE ) & 0x70) != 0) _delay_us(10);
strobe(CC1101_SPWD); // enter power down state
//dbg << "pd\n";
}

Der Code dürfte ebenfalls zum Aufwecken des CC1101 führen, legt ihn dann aber gleich wieder erfolgreich schlafen - trotzdem unnötiges Aufwecken.
Günstiger ist ein Wrapper um setIdle, der dafür sorgt, daß ein schlafender CC1101 erst gar nicht schlafen gelegt wird (und damit zunächst aufwacht).
In den aktuellen Lib-Versionen sind die Bugs behoben.

Martin
Titel: Antw:AskSin++ Library
Beitrag von: plombe am 10 Februar 2017, 19:14:32
Hallo,

@Linef: Ganz so wie du schreibst, ist es nicht. Um den Fehler zu finden, hatte ich HM-WDS10-TH-O.ino so abgeändert, daß in loop() nur stand:
  radio.setIdle
_delay_ms(8000);
radio.wakeup;
Den Interrupt hatte ich abgeschaltet. Da konnte ich eine Stromaufnahme von 5,7mA und 4,0 mA im Wechsel messen. Ebenso etwa 4mA ohne CC1101.
Da lag es nahe, daß die 1,7mA entsprechend Datenblatt
Zitat
1.6 mA Only voltage regulator to digital part and crystal oscillator running (IDLE state)
vom fehlerhaften Power down Status kamen.  Andere Einflüsse waren da meines Wissens ausgeschlossen.
Wenn CSn auf Low geht, ist es natürlich klar, daß power-down mode beendet wird.
H-G.

Titel: Antw:AskSin++ Library
Beitrag von: Linef am 10 Februar 2017, 21:28:05
  radio.setIdle
_delay_ms(8000);
radio.wakeup;

Hatte der wakeup auch gewartet, bis der Chip wieder komplett oben und für neue Kommandos bereit war?
(Im Wettersensor-Code von Dirk scheint mir nicht entsprechend gewartet zu werden)
Ansonsten läuft der unmittelbar in der Loop folgende setIdle ins Leere und wir haben den alternierenden Effekt...

Im Code von papa ist der Wrapper schon drin - dort sollte der Fehler also nicht mehr auftreten.

Martin
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Februar 2017, 21:56:39
Im Code von papa ist der Wrapper schon drin - dort sollte der Fehler also nicht mehr auftreten.

Die derzeitige Implementierung schickt den CC1101 schlafen und weckt ihn nach dem Watchdog sofort wieder auf. Wenn dann aber nicht passiert ist, geht es sofort wieder in den Idle. Ich wollte das mal so ändern, dass das Wakeup erst erfolgt, wenn wirklich was gesendet oder empfangen werden soll.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Februar 2017, 22:18:08
Der Watchdog Timer im Tiefschlaf des Arduino's  ist bekannlich nicht so genau. Im Nachbau des Universalsensors von Dirk nutze ich eine Möglichkeit, die Genauigkeit der Zeitmessung  zu verbessern. Damit ergibt sich auch im Tiefschlaf eine Genauigkeit, die annähernd der des Timer1 entspricht, und zwar unabhängig von Temperatur und Versorgungsspannung.
Einschränkung: Interrupt durch Tastendruck.
Um diese Verbesserung nutzen zu können, muß in der Datei Activity.h folgendes geändert werden:
//      LowPower.powerDown(SLEEP_8S,ADC_OFF,BOD_OFF);
      LowPower.delay(8000);
........
//      LowPower.powerDown(SLEEP_1S,ADC_OFF,BOD_OFF);
      LowPower.delay(1000);

Die angehängte Datei statt der Low-Power Bibliothek benutzen.
Viel Erfolg beim Ausprobieren.

Um das Power-Down-Verhalten zu beeinflussen, kann einfach die Sleep-Klasse überladen und dann als Template-Parameter in activity.savePower() übergeben werden.

Für exakte Timer plane ich noch die Unterstützung eines 32kHz Quarz am Timer2. Damit kann man dann auf die ganzen Tricks verzichten und den Power-Save Mode verwenden. Die 32kHz Quarze liegen hier schon in der Bastelkiste.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 10 Februar 2017, 23:32:47
Für exakte Timer plane ich noch die Unterstützung eines 32kHz Quarz am Timer2. Damit kann man dann auf die ganzen Tricks verzichten und den Power-Save Mode verwenden. Die 32kHz Quarze liegen hier schon in der Bastelkiste.

Wegen des Powersave-Modus habe ich meine letzten 2 Sensoren auch mit 32KHz-Quarzen aufgebaut. Funktioniert prima.
Es war nur einiges an Rechnerei, einen einigermaßen 1ms-Timer hinzubekommen, da eine Frequenz von 1 KHz durch Teilung aus 32.768Hz nicht hinzubekommen ist. Durch einen Korrekturzähler geht's dann aber, so daß man nie mehr als 1ms "daneben" ist. Und alle 125 Sek. geht's dann sogar wieder glatt auf, so daß man über lange Zeit gesehen dann doch wieder Quarzgenauigkeit hat.

Martin
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 10 Februar 2017, 23:40:30
Zu der 32KHz Thematik gibt's ein gutes Whitepaper von Atmel, da wegen Ultra-Low-Power doch die eine oder andere hardwaretechnische Problematik entstehen kann. Da sind dann auch einige zu den verschiedenen Oszillatoren der Atmel-Prozessoren passende Quarze aufgelistet...

Martin
Titel: Antw:AskSin++ Library
Beitrag von: plombe am 10 Februar 2017, 23:51:22
Das Beispiel mit dem Watchdog sollte kein Vorschlag für eine Codeänderung sondern nur ein Beleg für die Möglichkeit sein, auch den Watchdog Timer Millisekunden genau zu betreiben. In der Praxis kommt es bei HM ja nicht auf eine absolut genaue Zeit an, sondern einen Timer, der jeweils zwischen 120 und 185 Sekunden  auf ca. 50ms genau läuft. Und das bei minimalstem Stromverbrauch. Ich denke, es ist ein Irrtum, eine genau gehende Uhr implementieren zu wollen. Den HM-CC-RT-DN interessiert nur die Zeitspanne von einem empfangenen Datentelegramm bis zum nächsten. Eine RTC oder einen Quarzofen benötigt man da nicht. Also Aufwand und Nutzen.
Hans-Georg.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 11 Februar 2017, 00:03:08
Mir gings auch gar nicht um die Genauigkeit - im ersten Step hatte ich auch eine Kalibrierung für den Watchdog bei mir eingebaut, und die ist für den RT-DN völlig ausreichend.

Viel mehr ging's mir um den Stromverbrauch, da man mit dem Quarz in den Powersave-Modus gehen kann und da braucht
der Atmel statt 4,5uA (mit WD) nur noch 0,6uA...

Martin
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 11 Februar 2017, 00:22:43
Ich habe extrem viel versucht eine genaue Zeit zu bekommen.
Ein Powersensor sollte aus meiner Sicht da ganz genau sein, sonst kann er die Leistung nicht genau berechnen.

Habe es inzwischen mit einer zs-042 gelöst.
Der powersensor zählt 5 Minuten lang per Interrupt die LED -  Signale am Zähler aus.
Ohne Uhr bekommt man keine Zeit hin.

Klasse finde ich die Kalibrierung - werde ich bei mir einbauen.
Es scheint so zu sein, dass jeder Arduino seine eigene Abweichung hat.

Für welchen Zweck benötigt man 0,6uA?
Was machst du mit dem Strom, den du da sparst?  ;)

Im Übrigen vielen Dank für diese Version des AskSin Frameworks. Hier habe ich einen leichten verständlichen Einstieg gefunden. Die Unterstützung ist hier am besten.

Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Februar 2017, 09:57:31
Das Beispiel mit dem Watchdog sollte kein Vorschlag für eine Codeänderung sondern nur ein Beleg für die Möglichkeit sein, auch den Watchdog Timer Millisekunden genau zu betreiben. In der Praxis kommt es bei HM ja nicht auf eine absolut genaue Zeit an, sondern einen Timer, der jeweils zwischen 120 und 185 Sekunden  auf ca. 50ms genau läuft. Und das bei minimalstem Stromverbrauch. Ich denke, es ist ein Irrtum, eine genau gehende Uhr implementieren zu wollen. Den HM-CC-RT-DN interessiert nur die Zeitspanne von einem empfangenen Datentelegramm bis zum nächsten. Eine RTC oder einen Quarzofen benötigt man da nicht. Also Aufwand und Nutzen.

Du hast ja die originale LowPower Lib erweitert. Könntest Du das ganze auf GitHub forken ? Dann würde ich diesen Fork als Alternative mit aufnehmen. Ich möchte gern nur Libs verwenden, die einfach per GitHub installiert und aktualisiert werden können. Das macht es für andere einfacher den Code zu nutzen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Februar 2017, 10:02:38
Habe es inzwischen mit einer zs-042 gelöst.
Der powersensor zählt 5 Minuten lang per Interrupt die LED -  Signale am Zähler aus.
Ohne Uhr bekommt man keine Zeit hin.

Durch die vielen Interrupts geht es hier nur mit einer separaten Zeitmessung. Liest Du die RTC jedes mal aus ? Oder kann die CPU mit einem Interrupt geweckt werden ?

Für welchen Zweck benötigt man 0,6uA?
Was machst du mit dem Strom, den du da sparst?  ;)

Fernbedienung mit CR2032
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Februar 2017, 10:11:15
Hat jemand schon Erfahrung mit nem STM32 ? Habe mir ein Maple Mini Clone in China bestellt und wollte damit mal experiementieren. Mit STM32duino gibt es ja eine Arduino-kompatible Entwicklungsumgebung.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 12 Februar 2017, 10:18:51
Fernbedienung mit CR2032
Hast Du so was schon gebaut?
Welches Gehäuse, welche Tasten verwendest Du?

Martin
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Februar 2017, 10:28:55
Hast Du so was schon gebaut?
Welches Gehäuse, welche Tasten verwendest Du?

Ich will meine IT Fernbedienugen umbauen. Platine dafür habe ich grob schon fertig. Das ganz soll dann als HM-RC-12 funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 12 Februar 2017, 10:53:30
Oh, sehr schön! So was steht bei mir auch noch an...
Wo bekommt man das Gehäuse (mit Tasten)? Oder ist das was Altes / Umfunktioniertes?

Martin
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 12 Februar 2017, 11:25:35
Die zs-042 ist ein chinesischer Nachbau der ds3231 - sehr genau.
Diverse Abhandlungen im Netz beschäftigen sich mit der Verbesserung.

- Ladediode auslöten
- Widerstandsarray auslöten, dafür dann Pullups auf Signalleitungen auf dem Arduino auf high setzen.

Es soll möglich sein dann den Arduino per Interrupt im Batteriebetrieb der zs-042 wecken zu lassen. Ein Testprogramm funktioniert auch, aber beim powersensor mache ich es anders, weil es irgendwie nicht klappen wollte

Per WDT nähert sich der A. an den Lieferzeitpunkt der Daten (5Min) an. Interrupts lassen die Zeit schneller vergehen(weil offsets abgezogen werden). Wenn dann der Zeitpunkt zum Senden erreicht scheint, wird nachjustiert. Zum Auslesen der Zeit wird die Uhr kurz über den vcc am PIN mit Strom versorgt und wieder abgeschaltet.

Stromverbrauch 50uA. Könnte man durch den Ausbau des LOD weiter herunterbringen.
I2C schalte ich während der 5Min auch stromlos.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 12 Februar 2017, 11:31:44
Wäre es nicht besser die Kalibrierung in AlarmClock einzubauen und irgendwie einen Faktor beim Verbrauch der Zeit oder beim ermitteln der ticks in setTicks() einzurechnen.

Extra eine LowPower bereitzustellen erscheint mir nicht sinnvoll. Man wäre immer davon abhängig dass diese Variante aktuell gehalten wird.

Für mich ist das eindeutig eine Eigenschaft der AlarmClock, wenn sie nicht genau genug ist.
Und calibrate lässt sich super einbauen

Und jedesmal wenn offset abgezogen wird, wird vorher der Faktor eingerechnet.

etwa so(basiert auf Code von plombe).


// =====================================================================
class AlarmClock: public Link {

   Link     ready;
 
   uint32_t summe      = 0;
   uint32_t summeCount = 0;
   
public:
   uint32_t korrekturZaehler = 0;
   uint32_t korrekturNenner  = 0;
...
// =====================================================================

void AlarmClock::init() {
 
  if (korrekturZaehler==0) {
     getCalibrierungsFactor();
  }
 
  Serial << "cycleSoll_for_SLEEP_15MS: " << (F_CPU / 64 / 8)  << " (" << korrekturZaehler << "/" << korrekturNenner << ")" << eol;
 
  Timer1.initialize(CLOCK_RESOLUTION * 1000L); // initialize timer1, and set a 1/10 second period
  enable();
}
...
// ---------------------------------------------------------------------
void AlarmClock::getCalibrierungsFactor() {

   Serial.flush();
   uint32_t cycleSoll_for_15_625ms = F_CPU / 64 / 8;

   for (uint8_t i=0;i<3;i++) {
      summe += getCycleIst_for_15_625ms();
      summeCount++;   
   }
   // Serial << "summe:" << summe << eol;

   //Serial << "cycleSoll_for_SLEEP_15MS: " << cycleSoll_for_15_625ms  << " (" << korrekturZaehler << "/" << korrekturNenner << ")" << eol;

}
// ---------------------------------------------------------------------
uint32_t  AlarmClock::getCycleIst_for_15_625ms() {
 
  // Calibration needs Timer 1. Ensure it is powered up.
  uint8_t PRRcopy = PRR;
  PRR &= ~_BV(PRTIM1);
 
  uint8_t TCCR1Bcopy = TCCR1B;
  TCCR1B &= ~(_BV(CS12) | _BV(CS11) | _BV(CS10)); // Stop clock immediately
 
  // Capture Timer 1 state
  uint8_t TCCR1Acopy = TCCR1A;
  uint16_t TCNT1copy = TCNT1;
  uint16_t OCR1Acopy = OCR1A;
  uint16_t OCR1Bcopy = OCR1B;
  uint16_t ICR1copy  = ICR1;
  uint8_t TIMSK1copy = TIMSK1;
  uint8_t TIFR1copy  = TIFR1;

  // Configure as simple count-up timer
  TCCR1A = 0;
  TCCR1B = 0;
  TCNT1  = 0;
  TIMSK1 = 0;
  TIFR1  = 0;
  // Set clock to /8 (should take 15625 cycles at 16MHz clock)
  TCCR1B = _BV(CS11);
 
  LowPower.idle(SLEEP_15MS,ADC_OFF,TIMER2_OFF,TIMER1_ON,TIMER0_OFF,SPI_ON,USART0_ON,TWI_OFF);
 
  uint16_t watchdogDuration = TCNT1;
  //Serial << "watchdogDuration: " << watchdogDuration << eol;
  //Serial.flush();
   
  TCCR1B = 0; // Stop clock immediately

  // Restore Timer 1
  TIFR1  = TIFR1copy;
  TIMSK1 = TIMSK1copy;
  ICR1   = ICR1copy;
  OCR1B  = OCR1Bcopy;
  OCR1A  = OCR1Acopy;
  TCNT1  = TCNT1copy;
  TCCR1A = TCCR1Acopy;
  TCCR1B = TCCR1Bcopy;

  // Restore power reduction state
  PRR = PRRcopy;
 
  return  watchdogDuration;
}

und in Sleep:

// ---------------------------------------------------------------------
  static inline uint32_t wdt_Abschlag(uint32_t zeit) {
   
     uint32_t z = aclock.korrekturZaehler;
     uint32_t n = aclock.korrekturNenner;
   
     uint32_t aufschlag = z - n;
     return (zeit * aufschlag / n );
  }   
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Februar 2017, 14:33:52
Oh, sehr schön! So was steht bei mir auch noch an...
Wo bekommt man das Gehäuse (mit Tasten)? Oder ist das was Altes / Umfunktioniertes?

Alte Platine raus - neue rein  :)
Ab und an findet man die in der Bucht. Sicherlich lassen sich auch andere Bauformen recyceln.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Februar 2017, 15:00:37
Wäre es nicht besser die Kalibrierung in AlarmClock einzubauen und irgendwie einen Faktor beim Verbrauch der Zeit oder beim ermitteln der ticks in setTicks() einzurechnen.

Ja und nein. Es gibt ja auch Geräte, die den Deep-Sleep nicht brauchen. Dort ist dann die Kalibrierung des WDT unnötig. Aber man könnte eine Ableitung CalibratedAlarmClock machen und dann aclock selbst mit der benötigten Klasse anlegen. Oder wir machen ein Define USE_CLOCK_CALIBRATION, welches das entsprechend einschaltet. Aber zu viele Defines machen den Code so unleserlich. Das USE_AES will ich eigentlich auch wieder weg kriegen.

Edit: Nach nochmaligem Überegen würde ich das nicht in die AlarmClock einbauen, da diese ja nur die Ticks zählt und entsprechend die Alarme auslöst. Sie ist komplett vom Auslöser der Zählevents entkoppelt. Das kein ein Timer sein - oder aber auch einfach nur das Empfangen einer nachrricht - oder - oder - oder
Ich denke die Korrektur der WDT-Abweichung muss dort gemacht werden, wo sie auftritt. Und das ist im Sleep-Code. Also eher ein CalibratedSleep.
Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 13 Februar 2017, 10:12:04
Hallo,

ich habe 2 selbstgebaute HM_SEC_WDS, die mit der NewAskSin laufen.
Jetzt wollte ich sie mal auf die AskSinPP umbauen.

Dabei ist mir aufgefallen, dass es in der AskSinPP zwei Beispiele gibt, bei denen die minimale Spannung bei Pro Minis mit 2.2 Volt angegeben/geprüft wird.
Bei mir hat der HM_SEC_WDS bei ca. 2.7 Volt aufgegeben, bis ich die BOD rausgenommen habe...wie lange der jetzt noch läuft, bleibt abzuwarten.

Sind denn 2.2 Volt als Minimalspannung realistisch?

Micky
Titel: Antw:AskSin++ Library
Beitrag von: plombe am 13 Februar 2017, 10:18:52
Zitat
Sind denn 2.2 Volt als Minimalspannung realistisch?

Datenblatt ATmega48A/PA/88A/PA/168A/PA/328/P

Zitat
Operating Voltage:
1.8 - 5.5V
Speed Grade:
0 - 4MHz@1.8 - 5.5V, 0 - 10MHz@2.7 - 5.5.V, 0 - 20MHz @ 4.5 - 5.5V

CC1101:
Zitat
Parameter                           Min  Max  Unit  Condition
 Operating temperature   -40   85    °C     
Operating supply voltage 1.8  3.6     V     All supply pins must have the same voltage
H-G
Titel: Antw:AskSin++ Library
Beitrag von: bjoernh am 13 Februar 2017, 10:22:24
Datenblatt ATmega48A/PA/88A/PA/168A/PA/328/P

H-G
Aber der cc1101 macht früher schlapp.

Gesendet von meinem Mobile Device.

Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 13 Februar 2017, 11:13:06
Reply-in-Echtzeit  ;) find ich cool  8) Danke!

Ok, hatte die Möglichkeit von <=4MHz außer Acht gelassen...
Der CC1101 sollte auch noch mit 1.9 Volt laufen...da frage ich mich jetzt, woher 2.2 Volt kommen?
Erfahrungswerte?

Micky
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Februar 2017, 13:58:29
Mehr oder weniger aus der Luft gegriffen. Sollte ein Wert sein, wo alles noch garantiert funktioniert.
Bitte beachtet, dass es sich bei den Examples um Examples handelt, welche die Nutzung der Library zeigen sollen. Da muss nicht immer alles bis in Details ausimplementiert sein. Vielleicht können wir ja auch mal noch Code von "fertigen" Geräten mit aufnehmen. Da gehört dann aber auch immer der Schaltplan und die Fuse-Settings mit dazu.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 13 Februar 2017, 21:31:00
@papa:

Wie erzeugst du den Code für die Register?
Ich meine, das trilu irgendetwas generieren kann.

Kann man das für Asksinpp irgendwie nutzen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Februar 2017, 21:34:19
Der Generator sitzt vor dem Monitor :-)
Musst Du leider alles per Hand schreiben. Im Prinzip könnte man einen Generator schreiben, der die XML-Beschreibungen versteht. Aber die Mühe habe ich mir bisher nicht gemacht.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Februar 2017, 21:37:37
Ich habe mal eine Branch V1 im GitHub erstellt. Diese stellt den aktuellen, stabilen Stand dar und sollte für eigene Geräte genutzt werden. Hier wird es nur noch Bugfixes geben.
Im Master plane ich einige größere Umbauten, so dass es hier zu Inkompatibilitäten kommen wird.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 13 Februar 2017, 22:01:19
Der Generator sitzt vor dem Monitor :-)
Musst Du leider alles per Hand schreiben. Im Prinzip könnte man einen Generator schreiben, der die XML-Beschreibungen versteht. Aber die Mühe habe ich mir bisher nicht gemacht.

Hatte trilu nicht so etwas für NewAskSin?

Wenn man da aufsetzen könnte.
Einige getter und setter zu bauen kann ja nicht so schwer sein.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 13 Februar 2017, 22:38:46
Habe selber was gefunden - in NewAskSin gibt es ein destillregs2
Mal sehen, ob ich das verstehe.

mit perl analyze.pl devicetypes/rf_wds_v1_1.xml habe ich folgendes generiert. Kann man das in AskSinPP verwenden?:

--------------------------------------------------------------------------------------------
 This is the register.h content for the analysed xml file
 There are several information missing for a comlete register.h configuration
--------------------------------------------------------------------------------------------

#ifndef _REGISTER_h
    #define _REGISTER_h

    /**
     * @brief Settings of HM device
     * firmwareVersion: The firmware version reported by the device
     *                  Sometimes this value is important for select the related device-XML-File
     *
     * modelID:         Important for identification of the device.
     *                  @See Device-XML-File /device/supported_types/type/parameter/const_value
     *
     * subType:         Identifier if device is a switch or a blind or a remote
     * DevInfo:         Sometimes HM-Config-Files are referring on byte 23 for the amount of channels.
     *                  Other bytes not known.
     *                  23:0 0.4, means first four bit of byte 23 reflecting the amount of channels.
     */
    const uint8_t devIdnt[] PROGMEM = {               // HM-Sec-WDS
        /* firmwareVersion 1 byte */  0x11,           // or GE
        /* modelID         2 byte */  0x00,0x45,
        /* subTypeID       1 byte */  0x__,           // replace __ by a valid type id
        /* deviceInfo      3 byte */  0x00,0x00,0x00, // device info not found, replace by valid values
    };

    const uint8_t devIdnt[] PROGMEM = {               // HM-Sec-WDS-2
        /* firmwareVersion 1 byte */  0x13,           // or GE
        /* modelID         2 byte */  0x00,0xb2,
        /* subTypeID       1 byte */  0x__,           // replace __ by a valid type id
        /* deviceInfo      3 byte */  0x00,0x00,0x00, // device info not found, replace by valid values
    };

    /**
     * @brief Register definitions
     * The values are adresses in relation to the start adress defines in cnlTbl
     * Register values can found in related Device-XML-File.
     *
     * Spechial register list 0: 0x0A, 0x0B, 0x0C
     * Spechial register list 1: 0x08
     *
     * @See Defines.h
     *
     * @See: cnlTbl
     */
    const uint8_t cnlAddr[] PROGMEM = {
        // channel: 0, list: 0
        0x09,0x0a,0x0b,0x0c,0x14,
        // channel: 1, list: 1
        0x08,0x20,0x23,0x30,
        // channel: 1, list: 4
        0x01,
        // channel: 2, list: 1, link to 01 01
        // channel: 2, list: 4, link to 01 04
        // channel: 3, list: 1, link to 01 01
        // channel: 3, list: 4, link to 01 04
        // channel: 4, list: 1, link to 01 01
        // channel: 4, list: 4, link to 01 04
        // channel: 5, list: 1, link to 01 01
        // channel: 5, list: 4, link to 01 04
        // channel: 6, list: 1, link to 01 01
        // channel: 6, list: 4, link to 01 04
    }; // 10 byte

    /**
     * @brief Channel - List translation table
     * channel, list, startIndex, start address in EEprom, hidden
     * do not edit the table, if you need more peers edit the defines accordingly.
     */
    #define PHY_ADDR_START 0x20
    #define CNL_01_PEERS   1
    #define CNL_02_PEERS   1
    #define CNL_03_PEERS   1
    #define CNL_04_PEERS   1
    #define CNL_05_PEERS   1
    #define CNL_06_PEERS   1

    const EE::s_cnlTbl cnlTbl[] = {
        // cnl, lst, sIdx, sLen, hide, pAddr
        {    0,   0,    0,    5,    0, PHY_ADDR_START },
        {    1,   1,    5,    4,    0, cnlTbl[0].pAddr + cnlTbl[0].sLen },
        {    1,   4,    9,    1,    0, cnlTbl[1].pAddr + cnlTbl[1].sLen },
        {    2,   1,    5,    4,    0, cnlTbl[2].pAddr + (cnlTbl[2].sLen * CNL_01_PEERS) },
        {    2,   4,    9,    1,    0, cnlTbl[3].pAddr + cnlTbl[3].sLen },
        {    3,   1,    5,    4,    0, cnlTbl[4].pAddr + (cnlTbl[4].sLen * CNL_02_PEERS) },
        {    3,   4,    9,    1,    0, cnlTbl[5].pAddr + cnlTbl[5].sLen },
        {    4,   1,    5,    4,    0, cnlTbl[6].pAddr + (cnlTbl[6].sLen * CNL_03_PEERS) },
        {    4,   4,    9,    1,    0, cnlTbl[7].pAddr + cnlTbl[7].sLen },
        {    5,   1,    5,    4,    0, cnlTbl[8].pAddr + (cnlTbl[8].sLen * CNL_04_PEERS) },
        {    5,   4,    9,    1,    0, cnlTbl[9].pAddr + cnlTbl[9].sLen },
        {    6,   1,    5,    4,    0, cnlTbl[10].pAddr + (cnlTbl[10].sLen * CNL_05_PEERS) },
        {    6,   4,    9,    1,    0, cnlTbl[11].pAddr + cnlTbl[11].sLen },
    }; // 91 byte

    /**
     * @brief Peer-Device-List-Table
     * maximum allowed peers, link to row in cnlTbl, start address in EEprom
     */
    const EE::s_peerTbl peerTbl[] = {
        //    pMax, pLink, pAddr;
        {            0, 0, cnlTbl[12].pAddr + (cnlTbl[12].sLen * CNL_06_PEERS) },
        { CNL_01_PEERS, 2, peerTbl[0].pAddr + (peerTbl[0].pMax * 4) },
        { CNL_02_PEERS, 4, peerTbl[1].pAddr + (peerTbl[1].pMax * 4) },
        { CNL_03_PEERS, 6, peerTbl[2].pAddr + (peerTbl[2].pMax * 4) },
        { CNL_04_PEERS, 8, peerTbl[3].pAddr + (peerTbl[3].pMax * 4) },
        { CNL_05_PEERS, 10, peerTbl[4].pAddr + (peerTbl[4].pMax * 4) },
        { CNL_06_PEERS, 12, peerTbl[5].pAddr + (peerTbl[5].pMax * 4) },
    }; // 28 byte

    /**
     * @brief Struct with basic information for the AskSin library.
     * amount of user channels, amount of lines in the channel table,
     * link to devIdent byte array, link to cnlAddr byte array
     */
    EE::s_devDef devDef = {
        6, 13, devIdnt, cnlAddr,
    };

    /**
     * @brief Sizing of the user module register table.
     * Within this register table all user modules are registered to make
     * them accessible for the AskSin library   
     */
    RG::s_modTable modTbl[6];

#endif

--------------------------------------------------------------------------------------------
 This are some additional information especially for developers of user modules
 The channel structs reflecting the register content, the frame section shows
 which message types are used for the device functionallity
--------------------------------------------------------------------------------------------

/**
* @brief Channel structs (for developers)
* Within the channel struct you will find the definition of the respective registers per channel and list.
* These information is only needed if you want to develop your own channel module, for pre defined
* channel modules all this definitions enclosed in the pre defined module. 
*/

struct s_cnl0_lst0 {
   uint8_t CYCLIC_INFO_MSG           :8;  // 0x09.0, s:8   d: false 
   uint8_t MASTER_ID                 :24; // 0x0a.0, s:24  d:   
   uint8_t TRANSMIT_DEV_TRY_MAX      :8;  // 0x14.0, s:8   d: 6.0 
}; // 5 byte

struct s_cnl1_lst1 {
   uint8_t AES_ACTIVE                :1;  // 0x08.0, s:1   d: false 
   uint8_t                           :7;  // 0x08.1, s:7   d:   
   uint8_t MSG_FOR_POS_C             :2;  // 0x20.2, s:2   d: WATER 
   uint8_t MSG_FOR_POS_B             :2;  // 0x20.4, s:2   d: WET 
   uint8_t MSG_FOR_POS_A             :2;  // 0x20.6, s:2   d: DRY 
   uint8_t EVENT_FILTERTIME          :8;  // 0x23.0, s:8   d: 5.0 s
   uint8_t TRANSMIT_TRY_MAX          :8;  // 0x30.0, s:8   d: 6.0 
}; // 3.75 byte

struct s_cnl1_lst4 {
   uint8_t PEER_NEEDS_BURST          :1;  // 0x01.0, s:1   d: false 
   uint8_t                           :6;  // 0x01.1, s:6   d:   
   uint8_t EXPECT_AES                :1;  // 0x01.7, s:1   d: false 
}; // 1 byte

// struct s_cnl2_lst1 linked to 01 01
// struct s_cnl2_lst4 linked to 01 04
// struct s_cnl3_lst1 linked to 01 01
// struct s_cnl3_lst4 linked to 01 04
// struct s_cnl4_lst1 linked to 01 01
// struct s_cnl4_lst4 linked to 01 04
// struct s_cnl5_lst1 linked to 01 01
// struct s_cnl5_lst4 linked to 01 04
// struct s_cnl6_lst1 linked to 01 01
// struct s_cnl6_lst4 linked to 01 04

/**
 * @brief Message description:
 *
 *        00        01 02    03 04 05  06 07 08  09  10  11   12     13
 * Length MSG_Count    Type  Sender__  Receiver  ACK Cnl Stat Action RSSI
 * 0F     12        80 02    1E 7A AD  23 70 EC  01  01  BE   20     27    dimmer
 * 0E     5C        80 02    1F B7 4A  63 19 63  01  01  C8   00     42    pcb relay
 *
 * Needed frames:
 *
 * <frame id="EVENT" direction="from_device" allowed_receivers="BROADCAST,CENTRAL,OTHER" event="true" type="0x41" channel_field="9:0.6">
 *      <parameter type="integer" index="11.0" size="1.0" param="STATE"/>
 *      <parameter type="integer" index="9.7" size="0.1" param="LOWBAT"/>
 * <frame id="INFO_LEVEL" direction="from_device" allowed_receivers="BROADCAST,CENTRAL,OTHER" event="true" type="0x10" subtype="6" subtype_index="9" channel_field="10">
 *      <parameter type="integer" index="11.0" size="1.0" param="STATE"/>
 *      <parameter type="integer" index="12.7" size="0.1" param="LOWBAT"/>
 * <frame id="ACK_STATUS" direction="from_device" allowed_receivers="BROADCAST,CENTRAL,OTHER" event="true" type="0x02" subtype="1" subtype_index="9" channel_field="10">
 *      <parameter type="integer" index="11.0" size="1.0" param="STATE"/>
 *      <parameter type="integer" index="12.7" size="0.1" param="LOWBAT"/>
 */


Titel: Antw:AskSin++ Library
Beitrag von: Linef am 13 Februar 2017, 22:39:38
trilu hatte im Sommer/Herbst noch dran gebaut - dann allerdings die NewAskSin-Lib komplett umgebaut, so daß das alles nicht mehr notwendig ist.
Jetzt definiert man noch die gewünschten Register mit den Defaultwerten und fertig.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 13 Februar 2017, 22:57:45
Zitat
... NewAskSin-Lib komplett umgebaut
kann man sich das irgendwo ansehen?
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 13 Februar 2017, 23:16:19
Bei trilu im DevAES-Zweig oder bei mir im dev-Zweig:
https://github.com/trilu2000/NewAskSin/tree/DevAES
https://github.com/LineF/HM-Sensor

trilu ist aber noch nicht ganz durch - derzeit ist das Dimmer-Modul dran...

Gruss,
Martin
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 14 Februar 2017, 02:21:40
ich habe einige Fehler aus  distillRegs ausgebaut, so dass ich jedes xml fehlerfrei in die Datenstruktur verwandeln kann.
Mit ein wenig weiterem Perl könnte man die  getter und setter auch generieren, bzw gleich die Klasse für AskSinPP erzeugen.

z.B:
perl analyze.pl devicetypes/rf_bl.xml

/**
* @brief Channel structs (for developers)
* Within the channel struct you will find the definition of the respective registers per channel and list.
* These information is only needed if you want to develop your own channel module, for pre defined
* channel modules all this definitions enclosed in the pre defined module. 
*/

struct s_cnl0_lst0 {
   uint8_t                           :7;  // 0x02.0, s:7   d:   
   uint8_t INTERNAL_KEYS_VISIBLE     :1;  // 0x02.7, s:1   d: true 
   uint8_t MASTER_ID                 :24; // 0x0a.0, s:24  d:   
   uint8_t CONF_BUTTON_TIME          :8;  // 0x15.0, s:8   d: nF minutes
   uint8_t LOCAL_RESET_DISABLE       :1;  // 0x18.0, s:1   d: false 
   uint8_t                           :7;  // 0x18.1, s:7   d:   
}; // 6 byte

struct s_cnl1_lst1 {
   uint8_t AES_ACTIVE                :1;  // 0x08.0, s:1   d: false 
   uint8_t                           :7;  // 0x08.1, s:7   d:   
   uint8_t REFERENCE_RUNNING_TIME_TOP_BOTTOM :16; // 0x0b.0, s:16  d: 50.0 s
   uint8_t REFERENCE_RUNNING_TIME_BOTTOM_TOP :16; // 0x0d.0, s:16  d: 50.0 s
   uint8_t CHANGE_OVER_DELAY         :8;  // 0x0f.0, s:8   d: 0.5 s
   uint8_t REFERENCE_RUN_COUNTER     :8;  // 0x10.0, s:8   d: nF 
   uint8_t TRANSMIT_TRY_MAX          :8;  // 0x30.0, s:8   d: nF 
   uint8_t STATUSINFO_MINDELAY       :5;  // 0x57.0, s:5   d: 2.0 s
   uint8_t STATUSINFO_RANDOM         :3;  // 0x57.5, s:3   d: 1.0 s
}; // 9 byte

struct s_cnl1_lst3 {
   uint8_t SHORT_CT_RAMPON           :4;  // 0x01.0, s:4   d: X GE COND_VALUE_LO 
   uint8_t SHORT_CT_RAMPOFF          :4;  // 0x01.4, s:4   d: X GE COND_VALUE_LO 
   uint8_t SHORT_CT_ONDELAY          :4;  // 0x02.0, s:4   d: X GE COND_VALUE_LO 
   uint8_t SHORT_CT_OFFDELAY         :4;  // 0x02.4, s:4   d: X GE COND_VALUE_LO 
   uint8_t SHORT_CT_ON               :4;  // 0x03.0, s:4   d: X GE COND_VALUE_LO 
   uint8_t SHORT_CT_OFF              :4;  // 0x03.4, s:4   d: X GE COND_VALUE_LO 
   uint8_t SHORT_COND_VALUE_LO       :8;  // 0x04.0, s:8   d: nF 
   uint8_t SHORT_COND_VALUE_HI       :8;  // 0x05.0, s:8   d: nF 
   uint8_t SHORT_ONDELAY_TIME        :8;  // 0x06.0, s:8   d: 0 s
   uint8_t SHORT_ON_TIME             :8;  // 0x07.0, s:8   d: 111600.0 s
   uint8_t SHORT_OFFDELAY_TIME       :8;  // 0x08.0, s:8   d: 0 s
   uint8_t SHORT_OFF_TIME            :8;  // 0x09.0, s:8   d: 111600.0 s
   uint8_t SHORT_ACTION_TYPE         :2;  // 0x0a.0, s:2   d: JUMP_TO_TARGET 
   uint8_t                           :4;  // 0x0a.2, s:4   d:   
   uint8_t SHORT_OFF_TIME_MODE       :1;  // 0x0a.6, s:1   d: ABSOLUTE 
   uint8_t SHORT_ON_TIME_MODE        :1;  // 0x0a.7, s:1   d: ABSOLUTE 
   uint8_t SHORT_JT_ON               :4;  // 0x0b.0, s:4   d: OFF 
   uint8_t SHORT_JT_OFF              :4;  // 0x0b.4, s:4   d: OFF 
   uint8_t SHORT_JT_ONDELAY          :4;  // 0x0c.0, s:4   d: OFF 
   uint8_t SHORT_JT_OFFDELAY         :4;  // 0x0c.4, s:4   d: OFF 
   uint8_t SHORT_JT_RAMPON           :4;  // 0x0d.0, s:4   d: OFF 
   uint8_t SHORT_JT_RAMPOFF          :4;  // 0x0d.4, s:4   d: OFF 
   uint8_t SHORT_OFF_LEVEL           :8;  // 0x0f.0, s:8   d: 0.0 %
   uint8_t SHORT_ON_LEVEL            :8;  // 0x11.0, s:8   d: 1.0 %
   uint8_t SHORT_CT_REFON            :4;  // 0x1c.0, s:4   d: X GE COND_VALUE_LO 
   uint8_t SHORT_CT_REFOFF           :4;  // 0x1c.4, s:4   d: X GE COND_VALUE_LO 
   uint8_t SHORT_MAX_TIME_FIRST_DIR  :8;  // 0x1d.0, s:8   d: 25.5 s
   uint8_t SHORT_JT_REFON            :4;  // 0x1e.0, s:4   d: OFF 
   uint8_t SHORT_JT_REFOFF           :4;  // 0x1e.4, s:4   d: OFF 
   uint8_t SHORT_DRIVING_MODE        :8;  // 0x1f.0, s:8   d: DRIVE_DIRECTLY 
   uint8_t LONG_CT_RAMPON            :4;  // 0x81.0, s:4   d: X GE COND_VALUE_LO 
   uint8_t LONG_CT_RAMPOFF           :4;  // 0x81.4, s:4   d: X GE COND_VALUE_LO 
   uint8_t LONG_CT_ONDELAY           :4;  // 0x82.0, s:4   d: X GE COND_VALUE_LO 
   uint8_t LONG_CT_OFFDELAY          :4;  // 0x82.4, s:4   d: X GE COND_VALUE_LO 
   uint8_t LONG_CT_ON                :4;  // 0x83.0, s:4   d: X GE COND_VALUE_LO 
   uint8_t LONG_CT_OFF               :4;  // 0x83.4, s:4   d: X GE COND_VALUE_LO 
   uint8_t LONG_COND_VALUE_LO        :8;  // 0x84.0, s:8   d: nF 
   uint8_t LONG_COND_VALUE_HI        :8;  // 0x85.0, s:8   d: nF 
   uint8_t LONG_ONDELAY_TIME         :8;  // 0x86.0, s:8   d: 0 s
   uint8_t LONG_ON_TIME              :8;  // 0x87.0, s:8   d: 111600.0 s
   uint8_t LONG_OFFDELAY_TIME        :8;  // 0x88.0, s:8   d: 0 s
   uint8_t LONG_OFF_TIME             :8;  // 0x89.0, s:8   d: 111600.0 s
   uint8_t LONG_ACTION_TYPE          :2;  // 0x8a.0, s:2   d: JUMP_TO_TARGET 
   uint8_t                           :3;  // 0x8a.2, s:3   d:   
   uint8_t LONG_MULTIEXECUTE         :1;  // 0x8a.5, s:1   d: ON 
   uint8_t LONG_OFF_TIME_MODE        :1;  // 0x8a.6, s:1   d: ABSOLUTE 
   uint8_t LONG_ON_TIME_MODE         :1;  // 0x8a.7, s:1   d: ABSOLUTE 
   uint8_t LONG_JT_ON                :4;  // 0x8b.0, s:4   d: OFF 
   uint8_t LONG_JT_OFF               :4;  // 0x8b.4, s:4   d: OFF 
   uint8_t LONG_JT_ONDELAY           :4;  // 0x8c.0, s:4   d: OFF 
   uint8_t LONG_JT_OFFDELAY          :4;  // 0x8c.4, s:4   d: OFF 
   uint8_t LONG_JT_RAMPON            :4;  // 0x8d.0, s:4   d: OFF 
   uint8_t LONG_JT_RAMPOFF           :4;  // 0x8d.4, s:4   d: OFF 
   uint8_t LONG_OFF_LEVEL            :8;  // 0x8f.0, s:8   d: 0.0 %
   uint8_t LONG_ON_LEVEL             :8;  // 0x91.0, s:8   d: 1.0 %
   uint8_t LONG_CT_REFON             :4;  // 0x9c.0, s:4   d: X GE COND_VALUE_LO 
   uint8_t LONG_CT_REFOFF            :4;  // 0x9c.4, s:4   d: X GE COND_VALUE_LO 
   uint8_t LONG_MAX_TIME_FIRST_DIR   :8;  // 0x9d.0, s:8   d: 0.5 s
   uint8_t LONG_JT_REFON             :4;  // 0x9e.0, s:4   d: OFF 
   uint8_t LONG_JT_REFOFF            :4;  // 0x9e.4, s:4   d: OFF 
   uint8_t LONG_DRIVING_MODE         :8;  // 0x9f.0, s:8   d: DRIVE_DIRECTLY 
}; // 38 byte

Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 Februar 2017, 08:08:50
Cool - sieht sehr gut aus. Die Defaultwerte stehen doch auch im XML. Damit hätte man gleich das initiale Setup fertig.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 14 Februar 2017, 09:35:56
Ich erkläre mich bereit einen solchen Klassengenerator für die Regs zu bauen.
Wenn er läuft, kannst du ihn in AskSinPP einchecken.

Ich stelle mir folgenes vor. Der Code sollte komplett so(ähnlich) herauskommen. Man könnte den Code in ein eigenes File auslagern, dass müllt er nicht das *.ino so zu:
class MotionList1Data {
public:
  uint8_t EventFilterPeriod : 4;     // 0x01
  uint8_t EventFilterNumber : 4;     // 0x01
  uint8_t MinInterval       : 3;     // 0x02
  uint8_t CaptureWithinInterval : 1; // 0x02
  uint8_t BrightnessFilter  : 4;     // 0x02
  uint8_t AesActive         :1;      // 0x08, s:0, e:1
  uint8_t LedOntime;                 // 0x20

  static uint8_t getOffset(uint8_t reg) {
    switch (reg) {
      case 0x01: return 0;
      case 0x02: return 1;
      case 0x08: return 2;
      case 0x20: return 3;
      default: break;
    }
    return 0xff;
  }

  static uint8_t getRegister(uint8_t offset) {
    switch (offset) {
      case 0:  return 0x01;
      case 1:  return 0x02;
      case 2:  return 0x08;
      case 3:  return 0x20;
      default: break;
    }
    return 0xff;
  }
};

class MotionList1 : public ChannelList<MotionList1Data> {
public:
  MotionList1(uint16_t a) : ChannelList(a) {}

  uint8_t eventFilterPeriod () const { return getByte(0,0x0f,0); }
  bool eventFilterPeriod (uint8_t value) const { return setByte(0,value,0x0f,0); }
  uint8_t eventFilterNumber () const { return getByte(0,0xf0,4); }
  bool eventFilterNumber (uint8_t value) const { return setByte(0,value,0xf0,4); }

  uint8_t minInterval () const { return getByte(1,0x07,0); }
  bool minInterval (uint8_t value) const { return setByte(1,value,0x07,0); }
  bool captureWithinInterval () const { return isBitSet(1,0x08); }
  bool captureWithinInterval (bool value) const { return setBit(1,0x08,value); }
  uint8_t brightnessFilter () const { return getByte(1,0xf0,4); }
  bool brightnessFilter (uint8_t value) const { return setByte(1,value,0xf0,4); }

  bool aesActive () const { return isBitSet(2,0x01); }
  bool aesActive (bool s) const { return setBit(2,0x01,s); }

  uint8_t ledOntime () const { return getByte(3); }
  bool ledOntime (uint8_t value) const { return setByte(3,value); }

  void defaults () {
    eventFilterPeriod(1);
    eventFilterNumber(1);
    minInterval(4);
    captureWithinInterval(false);
    brightnessFilter(7);
    aesActive(false);
    ledOntime(100);
  }
};

Für den  hm-es-tx habe ich für die folgendne Felder kein xml gefunden - hat sich was am xml geändert und ich habe eine alten Stand des xml?
# ----------------------------------------------------------------------
# --- MeterList0Data
# ----------------------------------------------------------------------
class MeterList0Data : public List0Data {
  uint8_t LocalResetDisbale : 1;   // 0x18 - 24
  uint8_t Baudrate          : 8;   // 0x23 - 35
  uint8_t SerialFormat      : 8;   // 0x24 - 36
  uint8_t MeterPowerMode    : 8;   // 0x25 - 37
  uint8_t MeterProtocolMode : 8;   // 0x26 - 38
  uint8_t SamplesPerCycle   : 8;   // 0x27 - 39
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 Februar 2017, 10:39:04
Das wäre wirklich super.

Im Prinzip würde es ja reichen, wenn der Code auf der Console ausgegeben wird. Man kann sich das ja dann leicht in eine Datei umleiten oder kopieren oder ....

Zitat
Für den  hm-es-tx habe ich für die folgendne Felder kein xml gefunden - hat sich was am xml geändert und ich habe eine alten Stand des xml?

Die stehen ganz oben
<paramset type="MASTER" id="powermeter_iec_dev_master">
<parameter id="LOCAL_RESET_DISABLE">
<logical type="boolean" default="false"/>
<physical type="integer" interface="config" list="0" index="24" size="0.1"/>
</parameter>
<parameter id="BAUDRATE">

Und werden unten im Channel 0 dann einfach referenziert
<channels>
<channel index="0" type="MAINTENANCE" ui_flags="internal" class="maintenance" count="1">
<paramset type="MASTER" id="maint_ch_master"/>

Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 14 Februar 2017, 14:31:33
Ich würde die Variante als Headderdatei + cpp-Datei bevorzugen.Dann bleibt das .ino schön klein.
Ich bin bei meinen Versuchen an AskSinPP etwas zu verändern in der Headderhölle gelandet.

Sauberer scheint es zu sein, zwei Files zu schreiben.
Trotzdem sagt der Compiler mir manchmal, dass er von unvollständige Klassen nicht ableiten könne. Forwarddeklarationen sind dann auch nicht hilfreich.

Heute komme ich nicht dazu. Aber zu lange wird es mit Perl ja nicht dauern das zubauen, zumal das Parsen ja schon teilweise vorhanden ist.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 14 Februar 2017, 17:52:41
Für den  hm-es-tx habe ich jetzt ein neueres xml gefunden.
Dort habe ich die vermissten Sachen gefunden.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 Februar 2017, 19:22:04
Hier mit GitHub findest Du immer die aktuellen XML Files:

https://github.com/eq-3/occu/tree/master/firmware/rftypes (https://github.com/eq-3/occu/tree/master/firmware/rftypes)
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 14 Februar 2017, 19:34:30
den Link kannte ich schon - war hier schon einmal veröffentlicht worden.
Und mit dem xml sehen die structs schon viel besser aus:

/**
* @brief Channel structs (for developers)
* Within the channel struct you will find the definition of the respective registers per channel and list.
* These information is only needed if you want to develop your own channel module, for pre defined
* channel modules all this definitions enclosed in the pre defined module. 
*/

struct s_cnl0_lst0 {
   uint8_t MASTER_ID                 :24; // 0x0a.0, s:24  d:   
   uint8_t LOCAL_RESET_DISABLE       :1;  // 0x18.0, s:1   d: false 
   uint8_t                           :7;  // 0x18.1, s:7   d:   
   uint8_t BAUDRATE                  :8;  // 0x23.0, s:8   d: 9600 Bd 
   uint8_t SERIAL_FORMAT             :8;  // 0x24.0, s:8   d: 1_7D_1P_E_1S 
   uint8_t METER_POWERMODE           :8;  // 0x25.0, s:8   d: MAINS_POWERED 
   uint8_t METER_PROTOCOLMODE        :8;  // 0x26.0, s:8   d: PROTOKOLL_MODE_D 
   uint8_t SAMPLES_PER_CYCLE         :8;  // 0x27.0, s:8   d: nF 
}; // 9 byte

struct s_cnl1_lst1 {
   uint8_t AES_ACTIVE                :1;  // 0x08.0, s:1   d: false 
   uint8_t                           :7;  // 0x08.1, s:7   d:   
   uint8_t POWER_STRING              :128; // 0x36.0, s:128 d:   
   uint8_t ENERGY_COUNTER_STRING     :128; // 0x46.0, s:128 d:   
   uint8_t TX_THRESHOLD_POWER        :24; // 0x7c.0, s:24  d: 100.00 W
   uint8_t METER_TYPE                :8;  // 0x95.0, s:8   d: UNKOWN 
   uint8_t METER_CONSTANT_IR         :16; // 0x96.0, s:16  d: nF U./kWh
   uint8_t METER_CONSTANT_GAS        :16; // 0x98.0, s:16  d: 0.01 m3/Imp.
   uint8_t METER_CONSTANT_LED        :16; // 0x9a.0, s:16  d: nF Imp./kWh
   uint8_t METER_SENSIBILITY_IR      :8;  // 0x9c.0, s:8   d: nF %
}; // 44 byte

struct s_cnl2_lst1 {
   uint8_t AES_ACTIVE                :1;  // 0x08.0, s:1   d: false 
   uint8_t                           :7;  // 0x08.1, s:7   d:   
   uint8_t POWER_STRING              :128; // 0x36.0, s:128 d:   
   uint8_t ENERGY_COUNTER_STRING     :128; // 0x46.0, s:128 d:   
   uint8_t TX_THRESHOLD_POWER        :24; // 0x7c.0, s:24  d: 100.00 W
   uint8_t METER_TYPE                :8;  // 0x95.0, s:8   d: UNKOWN 
}; // 37 byte
Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 14 Februar 2017, 19:50:21
Ich habe mal eine Branch V1 im GitHub erstellt. Diese stellt den aktuellen, stabilen Stand dar und sollte für eigene Geräte genutzt werden. Hier wird es nur noch Bugfixes geben.
Im Master plane ich einige größere Umbauten, so dass es hier zu Inkompatibilitäten kommen wird.

Hmmm... habe ich bei Git was falsch verstanden?
Sind Branches nicht i.A. die Entwicklungszweige und master der letzte stabile Stand?

Micky
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 Februar 2017, 21:55:19
Hmmm... habe ich bei Git was falsch verstanden?
Sind Branches nicht i.A. die Entwicklungszweige und master der letzte stabile Stand?

Das kann man machen wie man will. Ich gehe davon aus, das es noch kleine Fixes geben wird. Deshalb der Maintenance Branch. Im Master will ich noch ein paar Sachen umbauen, um noch flexibler unterschiedliche Konfigurationen zu unterstützen.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 16 Februar 2017, 22:27:24
habe ein wenig gebastelt - sieht schon ganz gut aus, es bleibt aber noch was zu tun:

class Channel0List0Data {
   uint8_t MASTER_ID                 :24;  // 0x0a.0, s:24   d:   
   uint8_t LOCAL_RESET_DISABLE       :1;   // 0x18.0, s:1    d: false 
   uint8_t BAUDRATE                  :8;   // 0x23.0, s:8    d: 9600 Bd 
   uint8_t SERIAL_FORMAT             :8;   // 0x24.0, s:8    d: 1_7D_1P_E_1S 
   uint8_t METER_POWERMODE           :8;   // 0x25.0, s:8    d: MAINS_POWERED 
   uint8_t METER_PROTOCOLMODE        :8;   // 0x26.0, s:8    d: PROTOKOLL_MODE_D 
   uint8_t SAMPLES_PER_CYCLE         :8;   // 0x27.0, s:8    d: nF 

   // Zugriffe auf Register

};

class Channel0List0Access : public ChannelList<Channel0List0Data> {
public:
   Channel0List0Access(uint16_t a) : ChannelList(a) {}

   uint8_t                 MASTER_ID()  {};
   boolean                 MASTER_ID()  {};
   uint8_t       LOCAL_RESET_DISABLE()  {};
   boolean       LOCAL_RESET_DISABLE()  {};
   uint8_t                  BAUDRATE()  {};
   boolean                  BAUDRATE()  {};
   uint8_t             SERIAL_FORMAT()  {};
   boolean             SERIAL_FORMAT()  {};
   uint8_t           METER_POWERMODE()  {};
   boolean           METER_POWERMODE()  {};
   uint8_t        METER_PROTOCOLMODE()  {};
   boolean        METER_PROTOCOLMODE()  {};
   uint8_t         SAMPLES_PER_CYCLE()  {};
   boolean         SAMPLES_PER_CYCLE()  {};

   void defaults () {
      MASTER_ID (0);
      LOCAL_RESET_DISABLE (0);
      BAUDRATE (5);
      SERIAL_FORMAT (0);
      METER_POWERMODE (0);
      METER_PROTOCOLMODE (3);
   }
};

class Channel1List1Data {
   uint8_t AES_ACTIVE                :1;   // 0x08.0, s:1    d: false 
   uint8_t POWER_STRING              :128; // 0x36.0, s:128  d:   
   uint8_t ENERGY_COUNTER_STRING     :128; // 0x46.0, s:128  d:   
   uint8_t TX_THRESHOLD_POWER        :24;  // 0x7c.0, s:24   d: 100.00 W
   uint8_t METER_TYPE                :8;   // 0x95.0, s:8    d: UNKOWN 
   uint8_t METER_CONSTANT_IR         :16;  // 0x96.0, s:16   d: nF U./kWh
   uint8_t METER_CONSTANT_GAS        :16;  // 0x98.0, s:16   d: 0.01 m3/Imp.
   uint8_t METER_CONSTANT_LED        :16;  // 0x9a.0, s:16   d: nF Imp./kWh
   uint8_t METER_SENSIBILITY_IR      :8;   // 0x9c.0, s:8    d: nF %

   // Zugriffe auf Register

};

class Channel1List1Access : public ChannelList<Channel1List1Data> {
public:
   Channel1List1Access(uint16_t a) : ChannelList(a) {}

   uint8_t                AES_ACTIVE()  {};
   boolean                AES_ACTIVE()  {};
   uint8_t              POWER_STRING()  {};
   boolean              POWER_STRING()  {};
   uint8_t     ENERGY_COUNTER_STRING()  {};
   boolean     ENERGY_COUNTER_STRING()  {};
   uint8_t        TX_THRESHOLD_POWER()  {};
   boolean        TX_THRESHOLD_POWER()  {};
   uint8_t                METER_TYPE()  {};
   boolean                METER_TYPE()  {};
   uint8_t         METER_CONSTANT_IR()  {};
   boolean         METER_CONSTANT_IR()  {};
   uint8_t        METER_CONSTANT_GAS()  {};
   boolean        METER_CONSTANT_GAS()  {};
   uint8_t        METER_CONSTANT_LED()  {};
   boolean        METER_CONSTANT_LED()  {};
   uint8_t      METER_SENSIBILITY_IR()  {};
   boolean      METER_SENSIBILITY_IR()  {};

   void defaults () {
      AES_ACTIVE (0);
      POWER_STRING (0);
      ENERGY_COUNTER_STRING (0);
      TX_THRESHOLD_POWER (10000);
      METER_TYPE (4);
      METER_CONSTANT_GAS (10);
   }
};

class Channel2List1Data {
   uint8_t AES_ACTIVE                :1;   // 0x08.0, s:1    d: false 
   uint8_t POWER_STRING              :128; // 0x36.0, s:128  d:   
   uint8_t ENERGY_COUNTER_STRING     :128; // 0x46.0, s:128  d:   
   uint8_t TX_THRESHOLD_POWER        :24;  // 0x7c.0, s:24   d: 100.00 W
   uint8_t METER_TYPE                :8;   // 0x95.0, s:8    d: UNKOWN 

   // Zugriffe auf Register

};

class Channel2List1Access : public ChannelList<Channel2List1Data> {
public:
   Channel2List1Access(uint16_t a) : ChannelList(a) {}

   uint8_t                AES_ACTIVE()  {};
   boolean                AES_ACTIVE()  {};
   uint8_t              POWER_STRING()  {};
   boolean              POWER_STRING()  {};
   uint8_t     ENERGY_COUNTER_STRING()  {};
   boolean     ENERGY_COUNTER_STRING()  {};
   uint8_t        TX_THRESHOLD_POWER()  {};
   boolean        TX_THRESHOLD_POWER()  {};
   uint8_t                METER_TYPE()  {};
   boolean                METER_TYPE()  {};

   void defaults () {
      AES_ACTIVE (0);
      POWER_STRING (0);
      ENERGY_COUNTER_STRING (0);
      TX_THRESHOLD_POWER (10000);
      METER_TYPE (4);
   }
};
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Februar 2017, 09:05:53
Sieht ja schon gut aus. Aber Bitfelder, die größer als der Datentyp sind, funktionieren nicht.

uint8_t MASTER_ID                 :24;  // 0x0a.0, s:24   d:   

http://en.cppreference.com/w/cpp/language/bit_field (http://en.cppreference.com/w/cpp/language/bit_field)
Zitat
If the specified size of the bit field is greater than the size of its type, the value is limited by the type: a std::uint8_t b : 1000; would still hold values between 0 and 255. the extra bits become unused padding.

Zur Berechnung der Größe könnte es aber funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 17 Februar 2017, 10:27:01
ich bin noch nicht soweit, ist nur ein Zwischenstand - hatte gestern dann keine Lust mehr.

uint8_t LOCAL_RESET_DISABLE       :1;   // 0x18.0, s:1    d: false 
benötigt man diese Felder überhaupt?
Können sie nicht einfach nur als Kommentar eingefügt werden .

Ich habe keine Stelle gefunden, wo sie angesprochen werden. Die Getter und Setter greifen direkt auf das Eprom zu.
Ich habe auch gesehen, dass du die Art und Weise wie du die Klassen gebaut hast, mit der Zeit verändert hast.

Und der Zugriff auf "string" ist mir auch noch unklar. Return "powerstring" dürfte nicht so einfach sein.
Ich denke, dass du nur das codiert hast, was du für notwendig erachtet hast - den Rest kann man wahrscheinlich einfach fortlassen.

Das Ganze ist eine gute Übung um das mit den Registern in HM zu verstehen - ich habe erst seit 12 Wochen Homematik im Einsatz und weiß noch nicht so viel darüber.

Immer der Reihe nach.
Aus AES_ACTIVE() will ich noch aesActive() machen. Dann müssen noch die Rückgabewerte und der Registerzugriff gebastelt werden - alles kein Hexenwerk.

Das Script destillRegs2 ist jedenfalls leicht umzubauen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Februar 2017, 11:29:52
benötigt man diese Felder überhaupt?
Können sie nicht einfach nur als Kommentar eingefügt werden .

Ich habe keine Stelle gefunden, wo sie angesprochen werden. Die Getter und Setter greifen direkt auf das Eprom zu.
Ich habe auch gesehen, dass du die Art und Weise wie du die Klassen gebaut hast, mit der Zeit verändert hast.

Die Felder werden nur für sizeof(Datatype) benötigt, um die benötigte Größe im Eprom zu ermitteln. Man kann aber auch gut eine static Methode sizeof() generieren, die dann einfach die Größe zurückgibt. Ich bin halt zu faul, das mit der Hand auszurechnen.

Und der Zugriff auf "string" ist mir auch noch unklar. Return "powerstring" dürfte nicht so einfach sein.
Ich denke, dass du nur das codiert hast, was du für notwendig erachtet hast - den Rest kann man wahrscheinlich einfach fortlassen.

Da wird es schon interessant, wie man das Notwendige im Script erkennt.

Aus AES_ACTIVE() will ich noch aesActive() machen. Dann müssen noch die Rückgabewerte und der Registerzugriff gebastelt werden - alles kein Hexenwerk.

Die Schreibweise wäre mir auf jeden Fall lieber. Sollte auch nicht allzu schwer sein.
Titel: Antw:AskSin++ Library
Beitrag von: Pelle am 05 März 2017, 13:09:43
Hallo,

ich habe mittlerweile die AskSin++ auf einem PanStamp Avr2 erfolgreich im Betrieb genommen (mit dem HM-WDS10-TH-O example).
Danke für die tolle Library.
Dabei hatte ich das Problem, dass keine Nachrichten gesendet wurden, sobald der Stromsparmodus aktiv wurde. Es wurden also 5 Nachrichten nach einem Pairing gesendet, danach kamen keine mehr in FHEM an. Das entspricht genau der Zeit, die AskSin++ aktiv bleibt ohne zu schlafen nach einem Pairing.

Ich habe den Fehler jetzt behoben. Folgendes ist vermutlich schief gelaufen:

- Ein Paket wird gesendet.
- In der Senderoutine (Radio.cpp CC1101::sndData()) wird nicht korrekt bis zum erfolgreichen Senden gewartet
- hal.radio.setIdle(); wird aufgerufen, bevor das Paket erfolgreich versendet wurde.

Das Problem liegt in Zeile 134 von Radio.cpp:

if( readReg(CC1101_MARCSTATE, CC1101_STATUS) != MARCSTATE_TX) {
break; //neither in RX nor TX, probably some error
}

Hier wird die Warteschleife auch abgebrochen, wenn sich die State-Machine vom CC1101 in einem anderen Status als MARCSTATE_TX befindet. Zu diesem Zeitpunkt befindet sich der CC1101 aber noch im Status 0x08 (Calibrate), so dass die Warteschliefe sofort abgebrochen wird.
Ein entfernen fixt das Problem.

Der zweite Fehle ist nun das CC1101_MCSM1 Register, welches für den TXOFF_MODE Idle setzt, so dass MARCSTATE_RX nie erreicht werden kann.

Abhilfe schafft hier (in Zeile 146 Radio.cpp ersetzen):

if( readReg(CC1101_MARCSTATE, CC1101_STATUS) == MARCSTATE_IDLE)
    break;

oder das Setzen von

CC1101_MCSM1,    0x17

in Zeile 71 (NewAskSin setzt das Register genau so), so dass das Radio nach TX in RX wechselt.


Nach der Fehlersuche habe ich dann auch gesehen, dass in NewAskSin eine geschlossenes Issue steht welche eine ähnliches Phänomen beschreibt: https://github.com/trilu2000/NewAskSin/issues/20
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 März 2017, 22:21:50
Danke für die Fehlermeldung. Nummer 1 ist mir klar. Bei Nummer 2 bin ich mir nicht sicher, wo das hin soll.

Wie ich gesehen habe, verwendest Du den Master Branch. Dieser befindet sich gerade um Umbau, um demnächst STM32/Marple Mini besser unterstützen zu können. Dort wird gerade viel geändert. Für Anwendungen sollte der V1 Branch verwendet werden, da hier nur noch Bugfixes eingespielt werden.

Der Master verwendet jetzt übrigens die EnableInterrupt-Library anstelle der PinChangeInt-Library.
Titel: Antw:AskSin++ Library
Beitrag von: Pelle am 06 März 2017, 16:56:04
Ohh stimmt,

Zeile 146 war falsch. Richtig ist Zeile 132:


if( readReg(CC1101_MARCSTATE, CC1101_STATUS) == MARCSTATE_RX)
    break;

ersetzen durch

if( readReg(CC1101_MARCSTATE, CC1101_STATUS) == MARCSTATE_IDLE)
    break;

wenn das Radio nach dem Senden in Idle wechseln soll, dann kann das CC1101_MCSM1 so bleiben.
Soll nach dem Senden direkt in den Empfangsmodus gewechselt werden, das Register CC1101_MCSM1 auf 0x17 und Zeile 132 kann so bleiben.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 06 März 2017, 22:07:48
Danke - habe ich in beiden Branches geändert.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 12 März 2017, 21:42:55
Ist es eigentlich auch möglich, dass ein Schaltaktor z.B. HM-LC-SW1-SM auch den aktuellen Schaltzustand senden kann?
Die Homematic-Originale haben ja meistens noch Taster zum lokalen Schalten.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 März 2017, 09:31:18
Ist es eigentlich auch möglich, dass ein Schaltaktor z.B. HM-LC-SW1-SM auch den aktuellen Schaltzustand senden kann?
Die Homematic-Originale haben ja meistens noch Taster zum lokalen Schalten.

Das macht er doch.

Die Implementierung der Library sendet bei jedem Umschalten den Status. Außerdem kann der aktuelle Status mit einen StatusRequest abgefragt werden. Lokal mit eine Taster kann auch geschalten werden. Im Beispiel HM-LC-SWX-SM wird bei einem kurzen Druck auf den Config-Taster der erste Kanal umgeschalten.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 13 März 2017, 16:25:24
Ah, super.
Den Configtaster hatte ich mir nicht so genau angeschaut.
Ich denke ich werd den Sketch des Aktors anpassen so dass man alle Kanäle direkt mit einem Eingang schalten kann und dann wieder commiten.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 März 2017, 16:32:09
Ah, super.
Den Configtaster hatte ich mir nicht so genau angeschaut.
Ich denke ich werd den Sketch des Aktors anpassen so dass man alle Kanäle direkt mit einem Eingang schalten kann und dann wieder commiten.

Bitte nicht commiten. Die Beispiele würde ich gern unter meiner Kontrolle behalten :-) Die brauche ich auch, um Änderungen an der Library zu prüfen. Außerdem ist das der Code für die Relay-Platine von Spezialtrick.
Vielleicht macht man ja noch ein Application Verzeichnis mit fertigen Anwendungen. Da sollte dann auch immer ein Schaltplan mit rein, da nicht jeder die Schaltung direkt aus dem Code ablesen kann. Was haltet ihr davon ?
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 13 März 2017, 17:09:57
Habe eben den AES Code eingecheckt. Die Beispiele sind alle entsprechend angepasst. Getestet habe ich hauptsächlich mit dem HM-LC-SWX-SM Code.

AES wird mit "#define USE_AES" aktiviert. Es sind dann auch der Key und der Index zu definieren. Doku werde ich die Tage im Readme ergänzen.

Super, freut mich. Werde es die nächsten Tage einmal ausprobieren. Das ganze läuft schon seit Monaten stabil.

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 14 März 2017, 09:47:36
Du hättest ja immer noch die Kontrolle, kann ja nur Pullrequests erstellen ;-)

Ich finde, dass das ruhig ins Example rein kann, solange es das Example näher ans Verhalten des originalen Aktors etc. bringt.
Das mit den Schaltplänen usw. finde ich super.
Auch ne kurze Beschreibung im Verzeichniss des Examples währe toll.
Also was man im Sketch einstellen kann z.B. die Anzahl der Relais oder aber die LowActive-Funktion usw.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 März 2017, 18:10:53
Du hättest ja immer noch die Kontrolle, kann ja nur Pullrequests erstellen ;-)

Aber ich muss mich trotzdem drum kümmern. Also Review, Nachfragen, Einpflegen ...
Das geht dann alles von meiner eh schon recht knappen Zeit ab :-(

Ich finde, dass das ruhig ins Example rein kann, solange es das Example näher ans Verhalten des originalen Aktors etc. bringt.
Das mit den Schaltplänen usw. finde ich super.
Auch ne kurze Beschreibung im Verzeichniss des Examples währe toll.
Also was man im Sketch einstellen kann z.B. die Anzahl der Relais oder aber die LowActive-Funktion usw.

Das ist aber nicht der Code für den originalen Aktor - sondern hierfür https://forum.fhem.de/index.php/topic,48235.0.html (https://forum.fhem.de/index.php/topic,48235.0.html)

Wie wäre ein extra Devices-Repository. Da könnten dann auch andere direkt einchecken und weitere, richtige Geräte zur Verfügung stellen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 März 2017, 19:15:32
Ja das mit der Zeit kenn ich ;-)

Dass es für den Sketch auch schon die passende Platine gibt wusste ich nicht.
Ich setze bisher direkt Homematic ein und bin nur wenig hie rim Forum unterwegs.

Es soll ja nicht für den originalen Aktor sein, sondern für einen Nachbau.
Nur währ es ganz praktisch, wenn man mit dem Nachbau auch alle Funktionen wie vom Original nutzen kann .
Also auch lokal schalten.

Eigentlich ist es ganz praktisch, dass du die Examples zum testen nimmst.
Dadurch funktionieren sie immer mit der aktuellen Version bzw. man hat einen gemeinsamen Stand wenn die aktuelle Version der Lib gerade nicht tut.
Das ist mir beim NewAskSin aufgefallen, da gibt es zwar auch Beispiele aber die lassen sich nicht mehr compilen weil die Lib umgebaut wurde.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 17 März 2017, 14:17:11
Mal was anderes.
Hat es schon wer hinbekommen ein Gerät mit AskSin++ mit der originalen CCU mit AES zu pairen?

Hab jetzt schon diverse Kombinationen aus Key und KeyIndex versucht.
In der Datei /etc/config/keys stehen ja die Keys drin, wie bei FHEM.
Bei mir sind es 3 und der 3. entspricht auch dem MD5 Hash meines Sicherheitsschlüssels.
Hab jetzt als Index schon 3 und 6 versucht aber das bringt nichts.
Die CCU fragt mich dann nach dem Sicherheitsschlüssel aber auch wenn ich den eingebe funktionierts nicht.

Vielleicht hab ich dadurch auch noch nen Bug gefunden.
Manchmal nach dem 2. Pairingversuch blingt die LED von vom Arduino nur noch wild.
Auch der Resettaster bringt nichts.
Ich muss den Arduino vom Strom trennen damit der sich wieder fängt.
Die letzte Ausgabe ist immer "<- 1A 02 A0 00 78 90 1".
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 März 2017, 15:00:25

Ich habe kein CCU - teste aber mit HM-UART, HM-CFG-USB und CUL (umgeflashter Cube).

Welchen Branch benutzt Du ?
Bitte mal die gesamten Ausgaben der Console posten.

Möglicherweise muss der HM-Standard-Key eincompiliert werden, da ja die CCU bei einem neuen Geräte davon ausgeht, dass es noch den originalen Key hat. Beim Übertragen des "aktuellen" Keys wird dieser dann aber mit dem Standard-Key verschlüsselt - das geht bei einem eigenen Key natürlich nicht.

Den Standard-Key findet man mit Google. Ich habe ihn nicht im Code, da ich nicht weiss, ob ich durch dessen Veröffentlichung gegen irgendwelche Gesetzte verstoße. Das "Knacken" von Verschlüsselung ist ja heutzutage schlimmer als Mord.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 18 März 2017, 09:26:12
Ach mist.
Hatte vergessen, dass die Lib ja im Verzeichniss von der Arduino IDE auch aktualisiert werden muss.
Hatte vorher irgendwas von Anfang des Jahres noch vor dem V1.
Bin jetzt auf V1.
Es reicht wenn man den originalen Homematic Key einträgt und KeyIndex 0 lässt.

Ich denke die Suchworte für Google darf man auf jedenfall posten ansonsten bitte entfernen:

"pastebin homematic"
Direkt der erste Treffer.
Titel: Antw:AskSin++ Library
Beitrag von: xkalle01 am 20 März 2017, 12:07:56
Hallo papa und Dietmar,

Ich lese diesen Threat schon einige Zeit und habe meinen Universalsensor Nachbau mit einem BME280 mit der AskSinPP am Laufen.
Läuft alles soweit prima.

Seit letztem Wochenende läuft auch mein MotionDetector mit der gleichen Platiene des Universalsensor Nachbaus.
Wenn interesse besteht, poste ich gern den Schaltplan.

Mit Interesse habe ich gesehen, dass Dietmar an den Registern arbeitet.
Besonders die List0 währe interessant, dort sind viele Konfigurationen enthalten, die ich gern über FHEM setzten würde.
Oder geht das schon und ich habe es nur noch nicht verstanden?

Viele Grüße
Kalle

Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 20 März 2017, 13:37:07
Ich habe ein Perlscript(+Linuxscipte) angepasst, das aus einer XML-Beschreibung der CCU heraus  die ListKlassen und MessageKlassen für AskSin++ generieren kann(Betaphase).
Da die Universalsensorbeschreibung  vermutlich nicht als XML vorliegt, wird es schwierig sein, da etwas zu generieren.

Beim MotionDetector sollte es aber problemlos möglich sein da etwas zu generieren, wobei ich Stirng-Getter/-Setter zunächst mal generiere, sie aber nicht übersetzbar sind(löschen oder von Hand anpassen). Das will ich in einer späteren Version anpassen. Inwiefern die Register dann zwischen CCU/FHEM und den Sensoren auch korrekt ausgetauscht werden, kann ich nicht sagen, weil ich mich damit nicht beschäftigt habe. Das erledigen die Klassen von papa.

Wenn du willst, kann ich dir den Code generieren. Du musst mir nur sagen welches Gerät(Code) du benötigst.

Die Versionen liegen im Moment bei papa.
Er prüft, ob er sie auch unter Windows zum Laufen bekommt. Wenn es klappt, wird er sie in git einchecken.

Hast du mal eine Messung des Stromverbrauchs durchgeführt?

Einen MotionDetector(auf Basis proMini 3,3V + HC-SR501)  habe ich auch in Arbeit, auch er läuft von der Software her soweit. Ich will den Stromverbrauch(zur Zeit 0,070mA) noch soweit herunterdrücken, dass 2-3 AA(A) Batterien  möglichst lange halten. Ich schätze, dass ich nochmals ca. 0,045 mA einspare, wenn ich den LOD herauslöte.

Dietmar
Titel: Antw:AskSin++ Library
Beitrag von: xkalle01 am 20 März 2017, 15:00:20
Hallo Dietmar,

danke für die schnelle Antwort.

Model für den Universalsensor: 0xF1, 0x01
Subtyp:  0x70.
Dafür gibt es wohl keine XML-Definition (oder?).

Die Klassendefinition für den Universalsensor ist jedoch schnell heruntergeschrieben, nur ist die List0 nicht als Parameter an der Channel Definition zu übergeben.
Das ist wohl eine Änderung in der AkSin++ Lib selbst.

Für den MotionDetector ist es der Type, den papa in seinem Beispiel verwendet.
Model: 0x00,0x4a
SubTyp: 0x81

Ich habe noch keine Strommessung durchgeführt, kann ich aber in den nächsten Tagen einmal machen.
Ich betreibe meinen MotionDetector mit 2xAA, mal sehen wie lange der läuft
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 20 März 2017, 15:55:18
Zitat
Model für den Universalsensor: 0xF1, 0x01
Subtyp:  0x70.
Dafür gibt es wohl keine XML-Definition (oder?).
leider: F101 ist homebrew

Zitat
Die Klassendefinition für den Universalsensor ist jedoch schnell heruntergeschrieben, nur ist die List0 nicht als Parameter an der Channel Definition zu übergeben.
Das ist wohl eine Änderung in der AkSin++ Lib selbst.
vielleicht gibt es keine Einstellungen, die ausgetauscht werden können. Ich habe alles fest programmiert.

Zitat
Für den MotionDetector ist es der Type, den papa in seinem Beispiel verwendet.
Model: 0x00,0x4a
SubTyp: 0x81
dafür liefere ich dir mal die generierten Klassen, dann kannst du prüfen, ob noch etwas umgebaut werden sollte.

Zitat
Ich habe noch keine Strommessung durchgeführt, kann ich aber in den nächsten Tagen einmal machen.
Ich betreibe meinen MotionDetector mit 2xAA, mal sehen wie lange der läuft
Wenn du auch den hc-sr501 verwendest, dann läuft der vielleicht nur bis 3,0V stabil - so steht es jedenfalls im Datenblatt.
Ich überlege, ob ich auf LiPos(ausgediente HandyAkkus 3,5-4,2V) gehe oder 3xAA nehme. 3xAA sollten die bessere Wahl sein - nehmen aber auch gut Platz ein.
Titel: Antw:AskSin++ Library
Beitrag von: xkalle01 am 20 März 2017, 16:21:31
Zitat
Wenn du auch den hc-sr501 verwendest, dann läuft der vielleicht nur bis 3,0V stabil - so steht es jedenfalls im Datenblatt.
Ja, den hc-sr501 benutze ich auch.
Ich habe aber den MAX1724 zur Erzeugung der 3.3V verbaut, wie auch auf dem Universalsensor. Der macht auch aus 1.2V noch 3.3V :)

Deinen generierten Code würde ich gern einmal testen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 März 2017, 21:22:17
Besonders die List0 währe interessant, dort sind viele Konfigurationen enthalten, die ich gern über FHEM setzten würde.
Oder geht das schon und ich habe es nur noch nicht verstanden?

Die List0 kann im Device-Template als letzter Template-Parameter gesetzt werden. Dort wird als Default-Argument immer List0 automatisch gesetzt.
Ich habe die beispiele HM-ES-TX-WM & HM-WDS100-C6-O-2 angepasst, dass diese jetzt auch die erweiterte List0 setzen. Die Register sind dann auch von FHEM aus setzbar.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 20 März 2017, 21:53:39
So hier die versprochenen Klassen generiert durch Perl(aktueller Stand - betaphase) aus den xml:
Ich habe gesehen, dass perl zwischendurch noch einige Fehler ausgeworfen hat - der Code wurde aber trotzdem erzeugt.

Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 März 2017, 22:04:58
Da scheint noch ein Bug drin zu sein. Die MasterID in Liste 0 ist 3 Byte lang. Dein generierter Code betrachtet aber nur das erste Byte.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 März 2017, 22:28:48
Habe eben den Support für ARM genauer für das Maple Mini Board im Master-Branch eingecheckt. Es gibt jetzt auch nen stm32 Verzeichnis für die ARM Examples.

Der HM-LC-SWX-SM funktioniert soweit. Allerdings werden die Listen derzeit nicht dauerhaft gesichert. Da der ARM kein EEProm hat, werden die Listen derzeit nur im Speicher abgelegt. Es ist geplant, diesen Speichern dann nach Änderungen ins Flash zu schreiben. Außerdem läuft die CPU immer voll Kraft. Die Sleep-Funktionen müssen auch noch implementiert werden. Die VCC-Messung im BatterySensor ist noch nicht getestet.

Mit dem Maple Mini können auch größere Geräte umgesetzt werden. Die CPU besitzt 128KB Flash und 20KB RAM. Der Takt ist 72 MHz. Weitere Infos gibt es hier http://wiki.stm32duino.com/index.php?title=Maple_Mini (http://wiki.stm32duino.com/index.php?title=Maple_Mini).

Um den Code zu übersetzen wird eine aktuelle ArduinoIDE benötigt. Ich verwende Version 1.8.1. Außerdem muss der STM32-Support wie hier https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation (https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation) beschrieben installiert sein.

In der IDE sind folgende Einstellungen zu setzen:
  Board: Maple Mini
  CPU Speed: 72 MHz
  Bootloader Version: Original - den anderen Bootloader habe ich noch nicht probiert

Die Hardware gibt es günstig beim China-Man https://de.aliexpress.com/item/STM32F103RCBT6-ARM-Cortex-M3-leaflabs-Leaf-maple-mini-module-for-arduino-STM32/1878982440.html (https://de.aliexpress.com/item/STM32F103RCBT6-ARM-Cortex-M3-leaflabs-Leaf-maple-mini-module-for-arduino-STM32/1878982440.html)

Das CC1101 ist an dem SPI1 anzuschliessen. Der GDO0-Interrupt an PB0. Als Config-Button wird der Button auf dem Board verwendet. Die Debug-Ausgaben kommen über den USB-Anschluß.

Viel Spaß beim Nachbauen.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 21 März 2017, 01:34:57
Da scheint noch ein Bug drin zu sein. Die MasterID in Liste 0 ist 3 Byte lang. Dein generierter Code betrachtet aber nur das erste Byte.

kannst du das mal genauer beschreiben:

   bool       masterId                  (uint32_t v) const {return setByte(0,(v>>16)&0xff) + setByte(1,(v>>8)&0xff) + setByte(2,(v));};
   uint32_t   masterId                  (          ) const {return getByte(0)<<16 + getByte(1)<<8 + getByte(2);};
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 März 2017, 07:17:39
class Channel0List0Data {
/*
   uint8_t masterId                  :24;  // 0x0a.0, s:24   d:   
*/
public:
   static uint8_t avrRegister[1];  <== Hier müsste 3 stehen - 3 Byte

   static uint8_t getOffset  (uint8_t r) {
      for (uint8_t i=0;i<sizeof(avrRegister);i++) {
         if(avrRegister[i]==r) {
            return i;
         }
       return 0xff;
      }
   };
   static uint8_t getRegister(uint8_t o) {
     if (o>=0 && o <= sizeof(avrRegister)) {
        return avrRegister[o];
     };
     return 0xff;
   }
};

uint8_t Channel0List0Data::avrRegister[] = {0x0A};  <== Hier fehlen die Register 0x0B und 0x0C
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 21 März 2017, 15:52:55
Warum - liefert die Routine nicht immer nur die Position des Anfangsbytes?
Dann müsste die Liste ja im Zweifel recht lang sein.

Ich bin mir nicht sicher, aber bei anderen Felder habe ich auch nicht immer n Byte gesehen.

Dietmar
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 März 2017, 19:32:08
Die MasterID ist 3 Byte und in den Registern 0xA,0xB,0xC gespeichert - also müssen auch 3 Register dafür übertragen werden.

static uint8_t avrRegister[3];

uint8_t Channel0List0Data::avrRegister[] = {0x0A,0xB,0xC};

Nur so kann die getRegister-Funktion für jedes Byte der Liste das entsprechende Register zurückgeben.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 21 März 2017, 22:12:50
Welche Klasse/Methode benötigt das genau so?
Warum ist das nicht bei anderen uin32_t Variablen auch?

Welche Klasse/Methode tauscht die Daten mit der Zentrale aus. Vielleicht kann ich dort das warum verstehen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 März 2017, 08:26:27
Welche Klasse/Methode benötigt das genau so?

Das wird zum Lesen und Schreiben der Register von der Zentrale aus benötigt. Es werden hier immer die Paare von Register und Wert übermittelt. Deshalb muss die Firmware in der Lage sein, alle Register in den entsprechenden Offset im Flash umzurechnen bzw. umgekehrt.

Warum ist das nicht bei anderen uin32_t Variablen auch?

Welche ???

Welche Klasse/Methode tauscht die Daten mit der Zentrale aus. Vielleicht kann ich dort das warum verstehen?

z.B.

Device::sendInfoParamResponsePairs
Device::writeList

Titel: Antw:AskSin++ Library
Beitrag von: 0xFFFF am 24 März 2017, 10:15:47
@dietmar: Falls es keine zu großen Umstände bereitet, könntest du mir die messages  für den hm-lc-rgbw-wm generieren?
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 24 März 2017, 10:32:43
@0xFFFF

ja,
Das kann ich machen, Die Generierung der Listklassen muss ich aber nochmals überarbeiten - da hatte ich wohl noch nicht alles verstanden.
Aber daran denken, der Generator ist noch in de Betaphase des Tests.

Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 24 März 2017, 10:56:41
@papa:

ich habe mir den Code der Methoden
Device::sendInfoParamResponsePairs
Device::writeList

angesehen und folgendes verstanden:
Die erste Methode versendet die Daten in 8-Pairchen (Register:Wert) an die Zentrale.
Die Anzahl der zu versendenden Register wird per getSize ermittelt, deshalb muss darauf geachtet werden, dass sizeOf(DataClass) zur Compilezeit den richtigen Wert liefert.
Das erreichst du dadurch, dass die DataKlasse folgende Parameterleise am Anfang enthält. Die Variablen werden nur für sizeOf in getSize() benötigt, selbst jedoch nie angesprochen:

  uint8_t sign             :1;     // 0x08, s:0, e:1
  uint8_t                  :7;     //
  uint8_t transmitTryMax   :8;     // 0x30, s:0, e:8

Jedes Register(1 Byte) muss deshalb von getRegister(pos) ermittelbar sein.

Device::writeList schreibt den ganzen Kram(ConfigWriteIndexMsg), der von einer Zentrale gekommen ist, ins Eprom zurück. Das Parsen erfolgt in der MessageKlasse ConfigWriteIndexMsg.
Ich will das mal ausprobieren. Bei welchem example funktioniert das und welchen Tastendruck muss ich ausführen damit die Daten ausgetauscht werden.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 März 2017, 13:22:41
Das funktioniert bei allen. Schon das Pairen mit der Zentral schreibt und ließt die Liste 0.

Am einfachsten kann man das HM-LC-SWX-WM Example nehmen. Dort werden die geänderten Register der Channel sofort übertragen - z.B. powerUpAction
Titel: Antw:AskSin++ Library
Beitrag von: Sequenzial am 24 März 2017, 22:07:58
Moin,

ich bau mir gerade aus einem alten R2D2 einen Statusmelder für den Zustand meines Hauses (alle Fenster zu/Licht aus/Status Alarmanlage, Sirene für Alarm, usw...).
Das funktioniert mit meinem Nano Clone (5V/16Mhz) als HM-LC-SW4-SM grundsätzlich auch ganz gut, aber weil noch einige Funktionen hinzu kommen sollen, gehen mir in der Planung die digitalen PINs aus.

Also stecke ich gerade fest beim definieren von Buttons über analoge Ports...

Zuerste definiere ich den Channel 2 Knopf PIN (direkt nach dem Config_Button_Pin).
Dieser soll über den A3 PIN laufen:
#define CHANNEL2_BUTTON_PIN A3

Dann setze ich die Klasse (direkt unter dem CfgButton)

class Channel2Button : public Button {
public:
  Channel2Button () {
    setLongPressTime(seconds2ticks(60UL*60*60)); // 1hour
  }
  virtual void state (uint8_t s) {
    Button::state(s);
    if( s == Button::pressed ) {
      sdev.channel(2).toggleState();
    }
  }
};
Channel2Button c2Btn;
void c2BtnISR () { c2Btn.check(); }

Und im Setup() (direkt nach dem cfgBtn.init) setze ich den Interrupt:

c2Btn.init(CHANNEL2_BUTTON_PIN);
attachPinChangeInterrupt(CHANNEL2_BUTTON_PIN,c2BtnISR,CHANGE); 

Sketch compiliert und hochgeladen: ok

Aber egal was ich an A3 anlege (3,3V; 5V; Masse) ... es passiert nichts.
Geht das damit überhaupt?

Wenn ich das ganz auf PIN 9 (digital) durchspiele, funktioniert es.

Hat jemand eine Idee, ob und wie das via analog Ports funktioniert?

Danke!

Gruß
Hajo
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 März 2017, 07:12:01

Schau Dir mal das HM-RC-4 Example an. Werden auch die analog Pins als Eingang für die Taster verwendet. Du musst anstatt A3 die Pin Nummer angeben.

#define CHANNEL2_BUTTON_PIN 17

Damit sollte es funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: Sequenzial am 25 März 2017, 20:48:56
Schau Dir mal das HM-RC-4 Example an. Werden auch die analog Pins als Eingang für die Taster verwendet. Du musst anstatt A3 die Pin Nummer angeben.

#define CHANNEL2_BUTTON_PIN 17

Damit sollte es funktionieren.

Bestätigt. Klappt! Danke!
Titel: Antw:AskSin++ Library
Beitrag von: kadettilac89 am 27 März 2017, 13:19:08
Hallo papa und Dietmar,

Ich lese diesen Threat schon einige Zeit und habe meinen Universalsensor Nachbau mit einem BME280 mit der AskSinPP am Laufen.
Läuft alles soweit prima.


Hört sich interessant an. Du fragst parallel nach List0, d. h. im Sensor fehlen die RegList für Altitude, LowBatLimit, PairCentral ...? DAmit kannst du auch noch nicht sagen ob "Lazy Config" funktioniert, oder verstehe ich den Zusammenhang zu List0 falsch?

Wenn das "irgendwann" funktioniert wäre ich an deinem Beispiel interessiert. Halte uns auf dem Laufenden :)
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 27 März 2017, 13:48:42
Ich bastele immer noch(wenn ich Zeit habe) an dem Generator für die Erzeugung von Messageklassen und Listklassen aus dem XML heraus.
Zur Zeit stecken noch einige Fehler darin - Am Ende wird es aber glaube ich funktionieren.

Die MessageKlassen zu generieren ist einfacher als die Generierung der Listklassen. Das liegt zum einen daran, dass ich mich mit den Reg-Listen nicht auskenne und alles aus dem Code schließen muss oder auf Feedback angewiesen bin.

Bei den MessageKlassen fehlt nicht mehr viel.
Allerdings tue ich mich schwer mit dem Einbau in meine HM-Geräte, weil sie ja im Moment  schon so schön funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 März 2017, 14:12:47
"Lazy Config" sollte funktionieren - soweit wie ich das verstanden habe.  ;D
Hierzu ist das WKMEUP Flag in der Nachricht zu setzen - so wie im HM-SEC-MDIR Example. Mit dem HM-WDS10-TH-O Example habe ich es noch nicht probiert.
Titel: Antw:AskSin++ Library
Beitrag von: east am 09 Mai 2017, 17:16:11
Hallo,

bin seit kurzem von NewAsksin auf AsksinPP umgestiegen, aus Hoffnung mein Unterfangen endlich vollenden zu können. Allerdings bräuchte ich anfängliche Hilfe.

Habe versucht nachzuvollziehen, wie das mit der deklaration der Devices in der V1 funktioniert.

Sprich.... mein Vorhaben ist es, zwei Kanäle des HM-RC... und zwei Kanäle des HM-SW... zu kombinieren.

Ich weiss auch, das so ein Geträtetyp vermutlich nicht in Homematic existiert. Heisst das, dass ich ein XML-file bauen muss, um solch ein Kombigerät entwickeln zu können?

Vielen Dank im Voraus.


Ps.: Hut ab vor den ganzen Schöpfern und nartürlich den Mitwirkenden der Unternehmung!!!!
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Mai 2017, 19:53:15
Hallo,

bin seit kurzem von NewAsksin auf AsksinPP umgestiegen, aus Hoffnung mein Unterfangen endlich vollenden zu können. Allerdings bräuchte ich anfängliche Hilfe.

Habe versucht nachzuvollziehen, wie das mit der deklaration der Devices in der V1 funktioniert.

Sprich.... mein Vorhaben ist es, zwei Kanäle des HM-RC... und zwei Kanäle des HM-SW... zu kombinieren.

Gemischte Kanäle geht leider noch nicht und lässt sich mit dem Templatekonzept auch leidernicht so einfach umsetzen. Das steht aber weit oben auf meiner Liste für die aktuelle Enwicklung.

Ich weiss auch, das so ein Geträtetyp vermutlich nicht in Homematic existiert. Heisst das, dass ich ein XML-file bauen muss, um solch ein Kombigerät entwickeln zu können?

Das ist ein weiteres Problem. Für eine CCU werden (glaube ich) nur entsprechende XML-Files benötigt. Für FHEM muss man glaube ich, eine Erweiterung als Perl-Modul schreiben.
Titel: Antw:AskSin++ Library
Beitrag von: east am 09 Mai 2017, 21:27:12
Schade. Aber vielen Dank für deine Antwort. Habe alternativ dazu in der NewAsksin Branch-DevAES gelesen das trilu einen Mischbetrieb testweise aufbauen konnte. Werde ihn mal, um Hilfe bitten.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Mai 2017, 11:03:21
Im master Branch ist jetzt die Unterstützung für gemischte Kanäle enthalten. Schau Dir mal das HM-SEN-MDIR-WM55 Beispiel an. Da werden 2 Remote-Channel mit einem Motion-Channel kombiniert.

Alerdings plane ich da noch ein paar Umbauten, so dass es sein kann, das sich Schnittstellen auch nochmal ändern.
Titel: Antw:AskSin++ Library
Beitrag von: east am 11 Mai 2017, 22:52:43
Super Arbeit. Vielen Dank für deine so zuvor kommende Hilfe.

Habe aber jetzt eine andere Idee für mich gefunden. Dies habe ich in dem NewAsksin-Thread schon mitgeteilt, aber wie Du schon sagtest..... da kann man lange auf ANtwort warten.



Habe mal versuchsweise mir den ConfButton angeschaut. Wenn ich den zum schalten des ersten Kanals benutze, bekomme ich ja über umwege meine Rückmeldung der CCU. Heisst ich bau mir ein Programm in der CCU, wo ich über den ersten Kanal einen weiteren schalte und schon habe ich meine Rückkopplung.

Wenn ich jetzt nur noch für die übrigen Kanäle jeweils einen Button programmiere, habe ich das was ich wollte. Einmal mit den Buttons eine Remote zur CCU und zum anderen Switch-Kanäle die benötige.

Muss ich einen normalen Button auch in der AS.cpp bzw .h erstellen, um dies zu programmieren, oder gibt es einen einfachen weg?

Das ich den Tastendruck eines neuen Eingangs einfach mit in das Scenario des ConfigButtons packe?

if (mode == 1) {                  // keyShortSingle

     
if (scn == 1) pHM->sendDEVICE_INFO();                                    // send pairing string
     
if (((scn == 2 || btnNew == 1) ) && (modTbl[0].cnl)) modTbl[0].mDlgt(0,1,0,NULL,0);               // send toggle to user


Hoffe ist kein Problem, dass ich hier NewAsksin Fragen stelle. Habe so meine problemchen mit C++. Sorry.
 
Titel: Antw:AskSin++ Library
Beitrag von: east am 11 Mai 2017, 23:51:22
Werde mich trotzdem mal an der Asksin PP versuchen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Mai 2017, 09:29:40
Werde mich trotzdem mal an der Asksin PP versuchen.

Na im Prinzip musst Du ja nur den PIR-Channel durch 2 Switch-Channels ersetzen. Dann noch das DEVICE_MODEL auf etwas eigenes anpassen.

Für die CCU müsstest Du dann noch ein passendes XML machen.


Habe so meine problemchen mit C++.

Da kannst Du hier bestimmt noch was lernen ....  ;) AskSin++ nutzt die Möglichkeiten von C++ schon recht weit aus. Frag einfach nach, wenn Du was nicht verstehst.

Vielleicht gibt es demnächst noch eine einfachere Lösung. Ich habe noch ein cooles Feature auf meiner TODO Liste. Ich würde gern die Möglichkeit einbauen, auf einer Hardware 2 oder auch noch mehr logische Devices zu ermöglichen. Dann könnte man einfach einen 2-Kanal-Switch und eine 2-Kanal-Fernbedienung aus den existierenden Geräten nehmen und zusammen auf eine Hardware bringen. In FHEM & CCU würde das dann wie 2 separate Geräte aussehen.
Titel: Antw:AskSin++ Library
Beitrag von: east am 12 Mai 2017, 09:41:50
Habe schon direkt eine Frage bezüglich der HM-SEN-MDIR-WM55. Atmel Studio ist da für den Anfang sehr hilfreich, um durchs Programm zu kommen.

Gehe ich richtig in der Annahme, das die Klasse "class BtnPirList0Data" nur für die Berechnung des anzuzeigenden Analogwert da ist?

Wenn dann bräuchte ich diese ja für den Switch nicht. Richtig?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Mai 2017, 10:00:35
Habe schon direkt eine Frage bezüglich der HM-SEN-MDIR-WM55. Atmel Studio ist da für den Anfang sehr hilfreich, um durchs Programm zu kommen.

Gehe ich richtig in der Annahme, das die Klasse "class BtnPirList0Data" nur für die Berechnung des anzuzeigenden Analogwert da ist?
Wenn dann bräuchte ich diese ja für den Switch nicht. Richtig?

In der List0 werden die Geräte-spezifischen Settings gespeichert. Die Standard-List0 beinhaltet nur die MasterID. Die BtnPirList0-Klassen erweitern diese um einige Daten. Du kannst BtnPirList0Data & BtnPirList0 einfach weg lassen. Entsprechend musst Du dann auch die Device-Definition anpassen und BtnPirList0 entfernen.
Titel: Antw:AskSin++ Library
Beitrag von: east am 12 Mai 2017, 10:06:46
Ahh Super ok. Danke.


#include <MultiChannelDevice.h>
#include <Remote.h>
#include <SwitchChannel.h>



// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
#define LED_PIN2 6

// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8

// relay output pins compatible to the HM_Relay project
#define RELAY1_PIN 5
#define RELAY2_PIN 7

#define BUTTON1_PIN 14
#define BUTTON2_PIN 15

// number of available peers per channel
#define PEERS_PER_SWCHANNEL 2
#define PEERS_PER_BTNCHANNEL 10

// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef DualStatusLed<6,4> LedType;
typedef BatterySensor<22,19> BatteryType;
typedef AskSin<LedType,BatteryType,RadioType> BaseHal;
class Hal : public BaseHal {
public:
  void init () {
    BaseHal::init();
    // measure battery every 1h
    battery.init(seconds2ticks(60UL*60),sysclock);
  }
} hal;



typedef RemoteChannel<Hal,PEERS_PER_BTNCHANNEL> BtnChannel;
typedef SwitchChannel<Hal,PEERS_PER_SWCHANNEL> SwChannel;

class MixDevice : public ChannelDevice<Hal,VirtBaseChannel<Hal>,4,SwitchList1> {
public:
  VirtChannel<Hal,BtnChannel> c1,c2;
  VirtChannel<Hal,SwChannel> c3,c4;
public:
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal>,4,SwitchList1> DeviceType;
  MixDevice (uint16_t addr) : DeviceType(addr) {
    DeviceType::registerChannel(c1,1);
    DeviceType::registerChannel(c2,2);
    DeviceType::registerChannel(c3,3);
DeviceType::registerChannel(c4,4);
  }
  virtual ~MixDevice () {}

  BtnChannel& btn1Channel () { return c1; }
  BtnChannel& btn2Channel () { return c2; }
  SwChannel&  Sw1Channel  () { return c3; }
  SwChannel&  Sw2Channel  () { return c4; }
};
MixDevice sdev(0x20);

ConfigButton<MixDevice> cfgBtn(sdev);

// map number of channel to pin
// this will be called by the SwitchChannel class
uint8_t SwitchPin (uint8_t number) {
switch( number ) {
case 2: return RELAY2_PIN;

}
return RELAY1_PIN;
}


void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  remoteChannelISR(sdev.btn1Channel(),BUTTON1_PIN);
  remoteChannelISR(sdev.btn2Channel(),BUTTON2_PIN);
 
}

void loop() {
  bool pinchanged = sdev.btn1Channel().checkpin();
  pinchanged |= sdev.btn2Channel().checkpin();

  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( pinchanged == false && worked == false && poll == false ) {
    // deep discharge protection
    // if we drop below critical battery level - switch off all and sleep forever
    if( hal.battery.critical() ) {
      // this call will never return
      hal.activity.sleepForever(hal);
    }
    // if nothing to do - go sleep
    hal.activity.savePower<Sleep<>>(hal);
  }
}

Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Mai 2017, 11:07:41
Sieht gut aus - bis auf das Device-Template. Die SwitchList1 muss weg

class MixDevice : public ChannelDevice<Hal,VirtBaseChannel<Hal>,4,SwitchList1> {
public:
  VirtChannel<Hal,BtnChannel> c1,c2;
  VirtChannel<Hal,SwChannel> c3,c4;
public:
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal>,4,SwitchList1> DeviceType;

muss so

class MixDevice : public ChannelDevice<Hal,VirtBaseChannel<Hal>,4> {
public:
  VirtChannel<Hal,BtnChannel> c1,c2;
  VirtChannel<Hal,SwChannel> c3,c4;
public:
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal>,4> DeviceType;

Es wird dann automatisch die Default List0 verwendet.

Und die SwitchPin-Funktion muss noch abgeändert werden. Die Switches sind als Channel 3 & 4 angemeldet - also muss der Switch/case entsprechend geändert werden.

Wenn das Gerät nicht mit Batterie betrieben wird, kann noch NoBattery als BatterType verwendet werden. Außer dem kann der Batteriecode in der loop-Funktion rausgeschmissen werden. Schau mal in der Switch-Example. Das sollte so passen.
Titel: Antw:AskSin++ Library
Beitrag von: east am 12 Mai 2017, 12:39:29
Ja super. Vielen Dank. Aber nen bisschen rumbasteln ist schon was anderes als richtiges programmieren.... :-[
 Vielen Dank für die geduld.
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 12 Mai 2017, 22:19:28
Hallo papa, danke für deine Library. Damit habe ich schon gute Erfolge erzielt beim Erstellen meines eigenen Universalsensors. Dabei messe ich neben Temperatur und Feuchtigkeit noch die Helligkeit und Bewegungen mit einem PIR. Ich benutze den master tree und übertrage die Messwerte alle 2 Minuten.

Allerdings wäre es bei dem Bewegungssensor natürlich sinnvoll wenn die Erkennung einer Bewegung sofort gesendet wird. Im Prinzip definiere ich mit

attachInterrupt(digitalPinToInterrupt(DIGITAL_MOTION_INPUT_PIN), measureISR, CHANGE);
einen Interrupt und müsste eine measureISR() Funktion erzeugen, welche sofort ohne Wartezeit die Messwerte übermittelt.

Hat jmd. einen Vorschlag wie ich das elegant umsetzen kann? Kann im Prinzip noch nicht wirklich C++ programmieren. Danke :)

Hier mein bisheriges .ino file:

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define all device properties
#define DEVICE_ID HMID(0x11,0x12,0x13) // HM Address
#define DEVICE_SERIAL "USWZ111111" // HM Serial number
#define DEVICE_MODEL  0x00,0x3d
#define DEVICE_FIRMWARE 0x10
#define DEVICE_TYPE DeviceType::THSensor
#define DEVICE_INFO 0x03,0x01,0x00

#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include "HC-SR501.h"
#include "DHT22.h"
#include "LM393-LLS.h"

// Arduino Pro Mini
#define LED_PIN 4
#define CONFIG_BUTTON_PIN 8

// number of available peers per channel
#define PEERS_PER_CHANNEL 6

// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<4> LedType;
typedef BatterySensor<22,19> BatteryType;
typedef AskSin<LedType,BatteryType,RadioType> BaseHal;
class Hal : public BaseHal {
public:
  void init () {
    BaseHal::init();
    // measure battery every 1h
    battery.init(seconds2ticks(60UL*60),sysclock);
  }
} hal;

class WeatherEventMsg : public Message {
public:
  void init(uint8_t msgcnt,int16_t temp,uint8_t humidity, uint8_t luminosity, bool motion, bool batlow) {
    uint8_t t1 = (temp >> 8) & 0x7f;
    uint8_t t2 = temp & 0xff;
    if( batlow == true ) {
      t1 |= 0x80; // set bat low bit
    }
    Message::init(0xe,msgcnt,0x70,Message::BIDI,t1,t2); // first byte determines message length; pload[0] starts at byte 13
    pload[0] = humidity;
    pload[1] = luminosity;
    pload[2] = motion;
  }
};

class WeatherChannel : public Channel<Hal,List1,EmptyList,List4,PEERS_PER_CHANNEL>, public Alarm {

  WeatherEventMsg msg;
  uint8_t         msgcnt;
  int16_t         temp;
  uint8_t         humidity;
  uint8_t         luminosity;
  bool            motion;

public:
  WeatherChannel () : Channel(), Alarm(5), msgcnt(0), temp(0), humidity(50), luminosity(0), motion(0) {}
  virtual ~WeatherChannel () {}

  virtual void trigger (AlarmClock& clock) {
    // reactivate for next measure
    tick = delay();
    clock.add(*this);
    measure();
    msg.init(msgcnt++,temp,humidity,luminosity,motion,false);
    device().sendPeerEvent(msg,*this);
  }

  // here we do the measurement
  void measure () {
    temp = measureTemperature();
    humidity = measureHumidity();
    luminosity = measureLuminosity();
    motion = measureMotion();
  }

  // here we calc when to send next value
  uint32_t delay () {
    return seconds2ticks(120);
  }

  void setup(Device<Hal>* dev,uint8_t number,uint16_t addr) {
    Channel::setup(dev,number,addr);
    sysclock.add(*this);
  }

  uint8_t status () const {
    return 0;
  }

  uint8_t flags () const {
    return 0;
  }

};

typedef MultiChannelDevice<Hal,WeatherChannel,1> WeatherType;
WeatherType sdev(0x20);

ConfigButton<WeatherType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  //attachInterrupt(digitalPinToInterrupt(DIGITAL_MOTION_INPUT_PIN), measureISR, CHANGE);
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<Sleep<>>(hal);
  }
}
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Mai 2017, 22:46:16
Am einfachsten ist es, im Interrupt ein Flag zu setzen und dann im Mainloop bei gesetztem Flag die Nachricht zu senden. Würde dann wie folgt aussehen. Die Funktion measureAndSend() muss dann noch im Channel implementiert werden.

...
ConfigButton<WeatherType> cfgBtn(sdev);

volatile bool pir=false;
void pirISR () {
  pir=true;
}

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  enableInterrupt(DIGITAL_MOTION_INPUT_PIN, pirISR, RISING);
}

void loop() {
  if( pir == true ) {
    pir = false;
    sdev.channel(1).measureAndSend();
  }
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
...
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 13 Mai 2017, 07:11:04
Super, danke schonmal.

Das konnte ich ja jetzt im .ino anlegen. Für measureAndSend() müsste ich aber in die Library oder?
Könntest du das bitte im Github machen? Dann kann ich mir immer die Library Updates ziehen ohne da noch reinpfuschen zu müssen und andere User hätten auch was davon.

Wär sehr nett, danke :)
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 13 Mai 2017, 08:17:29
Ich würde sagen das musst du in deinen Weather Channel hineinbauen
Das Framework ist so aufgebaut, dass Papa normalerweise nichts machen muss
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Mai 2017, 08:56:19
Super, danke schonmal.

Das konnte ich ja jetzt im .ino anlegen. Für measureAndSend() müsste ich aber in die Library oder?
Könntest du das bitte im Github machen? Dann kann ich mir immer die Library Updates ziehen ohne da noch reinpfuschen zu müssen und andere User hätten auch was davon.
r nett, danke :)

Einfach noch folgende Methode in die WeatherChannel Klasse einfügen und gut.

  void measureAndSend() {
    measure();
    msg.init(msgcnt++,temp,humidity,luminosity,motion,false);
    device().sendPeerEvent(msg,*this);
  }
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 13 Mai 2017, 10:27:16
Ah da stand ich ziemlic hauf dem Schlauch.

Danke  8)
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 14 Mai 2017, 15:17:24
@papa:

wie bestellt - habe drei Versionen gefunden - eine hm-sec-rhs war nicht dabei.
Wenn ich den Code anders generieren soll, bitte dann melden.

Dietmar
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 Mai 2017, 18:40:28
Danke
Titel: Antw:AskSin++ Library
Beitrag von: 0xFFFF am 15 Mai 2017, 18:56:48
Ich muss nochmal nachfragen, wie das jetzt mit den Pins zu verstehen ist.
Auf einer Seite zuvor wird gesagt, PIN A3 ist 17...wie kommt man darauf? Oder anders gefragt, worauf bezieht sich die Nummerierung? Sowohl für den ConfigButton als auch für den Anschluss vom CC1101.

In den Beispielen wird der ConfigButton immer als PIN 8 definiert und der CC1101 über PINs 10-13 angesprochen...wobei er ja eigentlich auch 6 anschlüsse hat (und VCC/Masse).
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 15 Mai 2017, 19:45:44

https://forum.arduino.cc/index.php?topic=147582.0
 (https://forum.arduino.cc/index.php?topic=147582.0)

Arduinos basieren auf Atmel Prozessoren. Die Pins des Atmel (es gibt viele verschiedene ) haben von Atmel sBezeichnungen bekommen, die die bit Position in Ports abgebildet hat(PB7) ist bit 7 in PortB. Die Arduinos haben dies Bezeichnungen nicht auf die Nummerierung der Pins übernommen, sonder reihum durchgezählt. Die IDE und die C++ Bibliotheken versuchen diesen Sachverhalt zu verstecken. Du must nur wissen an welchem PIN du etwas anschließen willst, die  bits des passenden Ports ermitteln die Funktionen stellen alles richtig ein.

Unter dem obigem Link sind die verschiedenen Bezeichnungen der Pins eines Nano pro abgebildet. A3=17=pc3=pcint11 und noch viel mehr.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 Mai 2017, 19:49:19
Das ist die Arduino-Pinnummerierung. Siehe auch hier https://playground.arduino.cc/Learning/Pins (https://playground.arduino.cc/Learning/Pins)

Das CC1101 ist über SPI angebunden. Die SPI-Hardware im AVR ist auf den Pins 10-13 herausgeführt. Die restlichen Pins habe ich so festgelegt. Das hängt halt von der Hardware ab. Alle Beispiele haben den Config-Taster am Pin 8 gegen Masse. Die Led(s) an Pin 4 (und 5 - falls zwei). Das könnte man aber auch ganz anders machen.

Hoffe das hilft.
Titel: Antw:AskSin++ Library
Beitrag von: east am 16 Mai 2017, 10:40:11
Habe mal die Pinouts für den Pro Mini angehangen.....



Noch mal ne Frage ......

Wenn ich per eagle Schaltpläne bzw. Platinen bastel, kann ich diese hier auch kund tun?
Habe jetzt ne mini Platine für MixDevices ( HM-SW4 und HM-RC4 ) gebastelt.

Die Platine kann wahlweise mit 12V oder 5V gespeist werden. Benutze dafür Mini Supplies für PCB-Montage von Meanwell.

Bei dem jetzigen Board das ich erstellt habe, entnehme ich die 12V einem Codeschloss, das mit 12V gespeist wird.
Titel: Antw:AskSin++ Library
Beitrag von: east am 16 Mai 2017, 11:09:51
So mache das mal einfach. Wenn die hier nicht erwünscht sind, dann bitte löschen.

Habe extra für die Erstellung eines normalen Codeschlosses für den HM-Funkbetrieb eine Platine entwickelt, die man ganz einfach mit in das Gehäuse packen kann. Platine ist ca. 63x57mm groß.

Habe Parallel zu den RC-Tastern Optokoppler für den Eingang von bis zu 12V gelegt. Die Ausgänge des SW-Switch sind mit Transistoren beschaltet, um 5V-Spulen von beispielsweise Relais zu schalten ( dazu müssen die Widerstände gegen 5V weggelassen werden.)


Das Board kann auch als Testboard benutzt werden.... ;D


Wer die LBR-Dateien benötigt einmal bescheid geben. Sind viele selbst gebaute Libraries.

Ganz unten der benötigte CC1101-868Mhz.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Mai 2017, 13:02:10
Hast Du das auch schon als neuen Device-Type in FHEM oder der CCU eingebunden ?
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 16 Mai 2017, 13:20:07
So mache das mal einfach. Wenn die hier nicht erwünscht sind, dann bitte löschen.

Habe extra für die Erstellung eines normalen Codeschlosses für den HM-Funkbetrieb eine Platine entwickelt, die man ganz einfach mit in das Gehäuse packen kann. Platine ist ca. 63x57mm groß.

Habe Parallel zu den RC-Tastern Optokoppler für den Eingang von bis zu 12V gelegt. Die Ausgänge des SW-Switch sind mit Transistoren beschaltet, um 5V-Spulen von beispielsweise Relais zu schalten ( dazu müssen die Widerstände gegen 5V weggelassen werden.)


Das Board kann auch als Testboard benutzt werden.... ;D


Wer die LBR-Dateien benötigt einmal bescheid geben. Sind viele selbst gebaute Libraries.

Ganz unten der benötigte CC1101-868Mhz.

Ehrlich gesagt habe ich nicht vestanden was das ist.
Für FHEM könnte ich ein User-Device einrichten - das traue ich mir zu.
Titel: Antw:AskSin++ Library
Beitrag von: east am 16 Mai 2017, 15:30:33
Nein eingebunden leider noch nicht. Muss noch den XML-File erstellen. Da bin ich noch dabei.
Titel: Antw:AskSin++ Library
Beitrag von: east am 16 Mai 2017, 15:32:41
Die Platine soll als Addon für ein stinknormales Codeschloss dienen.

Das Codeschloss hat einen Aktivierungsausgang und einen Alarmausgang. Als Rückführung benutze ich die Leds (Grün/Rot) auf der Platine des Codeschlosses, ob die Alarmanlage scharf ist.


http://www.ebay.de/itm/Zutrittssystem-EM410x-Transponder-RFID-PIN-Code-/200887802997?hash=item2ec5d89c75 (http://www.ebay.de/itm/Zutrittssystem-EM410x-Transponder-RFID-PIN-Code-/200887802997?hash=item2ec5d89c75)

Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Mai 2017, 15:46:38
Nein eingebunden leider noch nicht. Muss noch den XML-File erstellen. Da bin ich noch dabei.

Wäre ja super, wenn das (zumindest mit der CCU) funktioniert.
Wir könnten das dann alles zusammen (XML, Code, Schaltplan, Layout) als Beispiel für ein CustomDevice ins Repository einchecken.
Titel: Antw:AskSin++ Library
Beitrag von: east am 16 Mai 2017, 15:59:44
Ja genau. 
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 16 Mai 2017, 18:29:18
Wo ist denn bei dem Teil der Schlüssel hinterlegt, fest verdrahtet im Arduino? Und wie öffnet sich dann die Tür?
Titel: Antw:AskSin++ Library
Beitrag von: 0xFFFF am 16 Mai 2017, 19:29:16
Danke für die Links mit der Pin Nummerierung, das hilft mir sehr.
Irgendwie scheint mein device aber nicht mehr zu funktionieren...gibt eine einfache Möglichkeit zu prüfen, ob die Kommunikation mit dem CC1101 korrekt funktioniert?
Titel: Antw:AskSin++ Library
Beitrag von: east am 16 Mai 2017, 20:00:40
Ja kann man prüfen. Musst aber einen FT232USB Umsetzer haben, um den Arduino mit dem seriellen Monitor in der Arduino-Software benutzen zu können. Musst dazu aber den Debugmodus des C1101 im Sketch aktivieren.

oder

Schau mal auf die kleine grüne LED auf dem Arduino unten in der Ecke. Wenn die aufblitzt wird empfangen bzw. gesendet.
Titel: Antw:AskSin++ Library
Beitrag von: east am 16 Mai 2017, 20:03:57
@Dietmar

der Schlüssel ist im Codeschloss selbst hinterlegt, genau so wie der RFIDkey. Das Gehäuse hat allerdings einen Sensor im Gehäuse sowie einen am Gehäuse. Heisst wenn das Gehäuse von der Wand abgenommen, oder dieses geöffnet wird, kommt sofort der Alarmausgang.

Das Codeschloss hat auch einen Ausgang extra für die Öffnung der Tür.

Die komplette Logik sitzt im Schloss.


Mag sein das der ein oder andere Sicherheitsbedenken bzgl. des Codeschlosses hat, allerdings wer so ein Codeschloss manipulieren kann, der ist auch zu weit aus mehr in der Lage. Und bei Profis kann man die heutzutage Modernste Sicherheitstechnik besitzen. Meiner Meinung knacken Profis auch das.

Soll heißen, das diese Alarmanlage mehr abschrecken soll. Ausserdem braucht der jenige etwas Zeit, um das Schloss zu knacken.....


Anbei die Belegung des Codeschlosses. Allerdings fehlt der Alarmausgang auf dem Bild.

Hier nochmal mit Alarmout....
Titel: Antw:AskSin++ Library
Beitrag von: 0xFFFF am 16 Mai 2017, 20:16:44
Ja kann man prüfen. Musst aber einen FT232USB Umsetzer haben, um den Arduino mit dem seriellen Monitor in der Arduino-Software benutzen zu können. Musst dazu aber den Debugmodus des C1101 im Sketch aktivieren.

oder

Schau mal auf die kleine grüne LED auf dem Arduino unten in der Ecke. Wenn die aufblitzt wird empfangen bzw. gesendet.
Es gibt also nochmal einen debug modus speziell für den C1101? Wo aktiviert man den? Die normale debug-option über den seriellen monitor funktioniert, wenn ich pairen will blinkt auch die led und die ausgehende Nachricht wird angezeigt. Eingehende kommen aber keine und das pairing wird auch nicht durchgeführt.
Titel: Antw:AskSin++ Library
Beitrag von: east am 16 Mai 2017, 20:22:05
@0xFFF

Beschreib mal bitte was Du vorhast.

Hast Du zum ersten Mal die Schaltung aufgebaut. Wenn ja, welchen Sketch hast Du aufgespielt und welche Zentrale hast Du (FHEM/CCU)?

Und zeig mal deinen Schrieb vom seriellen Monitor....

So wie ich das im Programm sehe (Master-Branch), ist der Debugmodus generell aktiviert.


Check aber mal deine Lötstellen und die Belegung. Hatte am Anfang auch problemchen.

Müsstest dann im seriellen Monitor (CC1101..........ready) oder so ähnlich sehen können.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Mai 2017, 20:35:59
Falls Du FHEM nutzt - siehts Du was im Eventmonitor ? Hast Du autocreate an ?
Titel: Antw:AskSin++ Library
Beitrag von: 0xFFFF am 16 Mai 2017, 21:00:38
Also momentan versuche ich einfach nur, das Beispiel HM-LC-Dim1PWM-CV zum laufen zu kriegen :D Von da aus werde ich dann weiter machen mit der Entwicklung eines eigenen devices...
Die Schaltung hat so auch schon mal funktioniert (muss irgendwann im Herbst letzten Jahres gewesen sein, damals auch noch mit NewAskSin).
Ich nutze nicht FHEM sondern openhab2 in Verbindung mit homegear. Wobei man openhab2 mal außen vor lassen kann, da das pairing erstmal nur mit homegear zu tun hat und sich openhab2 dann mit homegear verbindet. Die Konfiguration funktioniert auch zu 100%, ich steure damit bereits meine Heizung.

Hier die Ausgabe von der Konsole vom Starten und dem Pairingversuch:
Zitat
AskSin++ V1.0.3
Address Space: 32 - 843
CC init12...................3 - ready
<- 0F 01 A2 10 111222 000000 06 01 00 00 00 00
<- 0F 02 A2 10 111222 000000 06 02 00 00 00 00
<- 0F 03 A2 10 111222 000000 06 03 00 00 00 00
 debounce
 pressed
 longpressed
 longreleased
<- 1A 04 80 00 111222 000000 25 00 67 70 61 70 61 31 31 31 32 32 32 20 41 01 00

In der Liste in homegear taucht aber nichts neues auf :(

Verlötet ist es wie der selbstbau-cul: https://wiki.fhem.de/wiki/Selbstbau_CUL
Config button ist jetzt auch an dem richtigen pin, funktioniert ja auch offensichtlich...bin inzwischen etwas ratlos :D
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Mai 2017, 21:15:41
Verlötet ist es wie der selbstbau-cul: https://wiki.fhem.de/wiki/Selbstbau_CUL

Dann ist GDO0 nicht correct angeschlossen. Das hatten wir hier schon mal https://forum.fhem.de/index.php/topic,57486.msg497987.html#msg497987 (https://forum.fhem.de/index.php/topic,57486.msg497987.html#msg497987)
Titel: Antw:AskSin++ Library
Beitrag von: 0xFFFF am 16 Mai 2017, 21:34:01
Oh man...danke, das wars. Ich dachte eigentlich ich hätte an der Schaltung nichts mehr geändert, aber offensichtlich doch.
Naja wie auch immer, danke nochmal für eure Hilfe!
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Mai 2017, 21:42:18
Das kann auch einfach im Code geändert werden. Einfach den zweiten Templateparameter in der Typedefinition vom Radio in 3 ändern.

typedef Radio<SPIType,2> RadioType;

Aber bitte beachten, im Master-Branch bin ich gerade kräftig am umbauen. Da können sich APIs nochmal ändern. Stabil sollte es halbwegs sein.
Titel: Antw:AskSin++ Library
Beitrag von: east am 17 Mai 2017, 10:14:21
So hab den XML-Code in der CCU2 geändert. Das MixDevice wird erkannt und auch verarbeitet. Allerdings funktionieren nur die Kanäle 1-3. Der Kanal 4 wird nicht geschaltet und führt zur Kommunikationsstörung mit Fehlermeldung in der CCU2.

Weiter ist mir aufgefallen, das die Kanäle 3 und 4 vom Switch beim anlernen direkt eingschaltet sind.

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2017-05-10 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER

// number of relays - possible values 1,2,4
// will map to HM-LC-SW1-SM, HM-LC-SW2-SM, HM-LC-SW4-SM
#define RELAY_COUNT 2

// define all device properties
#define DEVICE_ID HMID(0x90,0x78,0x90)
#define DEVICE_SERIAL "xms1234567"
#define DEVICE_MODEL  0x00,0xdf
#define DEVICE_FIRMWARE 0x10
#define DEVICE_TYPE DeviceType::Switch
#define DEVICE_INFO 0x04,0x01,0x00

#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include <Remote.h>
#include <SwitchChannel.h>



// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
#define LED_PIN2 6

// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8

// relay output pins compatible to the HM_Relay project
#define RELAY1_PIN 7
#define RELAY2_PIN 9

#define BUTTON1_PIN 3
#define BUTTON2_PIN 5

// number of available peers per channel
#define PEERS_PER_SWCHANNEL 2
#define PEERS_PER_BTNCHANNEL 10

// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef DualStatusLed<6,4> LedType;
typedef AskSin<LedType,NoBattery,RadioType> Hal;
Hal hal;

typedef RemoteChannel<Hal,PEERS_PER_BTNCHANNEL> BtnChannel;
typedef SwitchChannel<Hal,PEERS_PER_SWCHANNEL> SwChannel;

class MixDevice : public ChannelDevice<Hal,VirtBaseChannel<Hal>,4> {
public:
  VirtChannel<Hal,BtnChannel> c1,c2;
  VirtChannel<Hal,SwChannel> c3,c4;
public:
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal>,4> DeviceType;
  MixDevice (uint16_t addr) : DeviceType(addr) {
    DeviceType::registerChannel(c1,1);
    DeviceType::registerChannel(c2,2);
    DeviceType::registerChannel(c3,3);
    DeviceType::registerChannel(c4,4);
  }
  virtual ~MixDevice () {}

  BtnChannel& btn1Channel () { return c1; }
  BtnChannel& btn2Channel () { return c2; }
  SwChannel&  Sw3Channel  () { return c3; }
  SwChannel&  Sw4Channel  () { return c4; }
};
MixDevice sdev(0x20);

ConfigButton<MixDevice> cfgBtn(sdev);

// map number of channel to pin
// this will be called by the SwitchChannel class
uint8_t SwitchPin (uint8_t number) {
  switch( number ) {
   
    case 3: return RELAY1_PIN;
    case 4: return RELAY2_PIN;
   
   
  }
}

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
 
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  remoteChannelISR(sdev.btn1Channel(),BUTTON1_PIN);
  remoteChannelISR(sdev.btn2Channel(),BUTTON2_PIN);
 
}

void loop() {
  bool pinchanged = sdev.btn1Channel().checkpin();
  pinchanged |= sdev.btn2Channel().checkpin();

  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( pinchanged == false && worked == false && poll == false ) {
    // deep discharge protection
    // if we drop below critical battery level - switch off all and sleep forever
    if( hal.battery.critical() ) {
      // this call will never return
      hal.activity.sleepForever(hal);
    }
    // if nothing to do - go sleep
    hal.activity.savePower<Sleep< > >(hal);
  }
}

Aber trotzdem schon mal ein kleiner Erfolg, beim manipulieren der XML-Files..... :D

Anbei der geänderte XML File.
Titel: Antw:AskSin++ Library
Beitrag von: east am 17 Mai 2017, 10:40:00
JUHUUUU.....

Jetzt funzt es!!!!!

Musste Savepower auf Idle setzen, stand vorher auf sleep.

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2017-05-10 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER

// number of relays - possible values 1,2,4
// will map to HM-LC-SW1-SM, HM-LC-SW2-SM, HM-LC-SW4-SM
#define RELAY_COUNT 2

// define all device properties
#define DEVICE_ID HMID(0x90,0x78,0x90)
#define DEVICE_SERIAL "xms1234567"
#define DEVICE_MODEL  0x00,0xdf
#define DEVICE_FIRMWARE 0x10
#define DEVICE_TYPE DeviceType::Switch
#define DEVICE_INFO 0x04,0x01,0x00

#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include <Remote.h>
#include <SwitchChannel.h>



// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
#define LED_PIN2 6

// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8

// relay output pins compatible to the HM_Relay project
#define RELAY1_PIN 7
#define RELAY2_PIN 9

#define BUTTON1_PIN 3
#define BUTTON2_PIN 5

// number of available peers per channel
#define PEERS_PER_SWCHANNEL 2
#define PEERS_PER_BTNCHANNEL 10

// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef DualStatusLed<6,4> LedType;
typedef AskSin<LedType,NoBattery,RadioType> Hal;
Hal hal;

typedef RemoteChannel<Hal,PEERS_PER_BTNCHANNEL> BtnChannel;
typedef SwitchChannel<Hal,PEERS_PER_SWCHANNEL> SwChannel;

class MixDevice : public ChannelDevice<Hal,VirtBaseChannel<Hal>,4> {
public:
  VirtChannel<Hal,BtnChannel> c1,c2;
  VirtChannel<Hal,SwChannel> c3,c4;
public:
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal>,4> DeviceType;
  MixDevice (uint16_t addr) : DeviceType(addr) {
    DeviceType::registerChannel(c1,1);
    DeviceType::registerChannel(c2,2);
    DeviceType::registerChannel(c3,3);
    DeviceType::registerChannel(c4,4);
  }
  virtual ~MixDevice () {}

  BtnChannel& btn1Channel () { return c1; }
  BtnChannel& btn2Channel () { return c2; }
  SwChannel&  Sw3Channel  () { return c3; }
  SwChannel&  Sw4Channel  () { return c4; }
};
MixDevice sdev(0x20);

ConfigButton<MixDevice> cfgBtn(sdev);

// map number of channel to pin
// this will be called by the SwitchChannel class
uint8_t SwitchPin (uint8_t number) {
  switch( number ) {
   
    case 3: return RELAY1_PIN;
    case 4: return RELAY2_PIN;
   
   
  }
}

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
 
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  remoteChannelISR(sdev.btn1Channel(),BUTTON1_PIN);
  remoteChannelISR(sdev.btn2Channel(),BUTTON2_PIN);
 
}

void loop() {
  bool pinchanged = sdev.btn1Channel().checkpin();
  pinchanged |= sdev.btn2Channel().checkpin();

  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( pinchanged == false && worked == false && poll == false ) {
    // deep discharge protection
    // if we drop below critical battery level - switch off all and sleep forever
    if( hal.battery.critical() ) {
      // this call will never return
      hal.activity.sleepForever(hal);
    }

  if( worked == false && poll == false ) {
    hal.activity.savePower<Idle<> >(hal);
  }
  }
}

Brauch jetzt nur noch hilfe, um die Kanäle 3 und 4 standardweise auf "aus" zu setzen. Die sind sonst beim neustart auf "ein".


Hier noch meine Änderungen im vorhandenen XML in der CCU2......

Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Mai 2017, 11:00:28
Cooool

Die Switch-Channels müssen noch im setup() initialisiert werden:

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  sdev.Sw3Channel().lowactive(false);
  sdev.Sw4Channel().lowactive(false);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  remoteChannelISR(sdev.btn1Channel(),BUTTON1_PIN);
  remoteChannelISR(sdev.btn2Channel(),BUTTON2_PIN);
 
}

Dabei wird dann die Switch-Statemachine initialisiert und die Switches schicken auch den aktuellen Zustand an die Zentrale. Und beachten die powerOn Einstellung.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Mai 2017, 11:03:30
Ach so - noch vergessen. 0x00df als Devicetype finde ich etwas gefährlich. Keine Ahnung, ob es das nicht schon mal gibt. Mach mal lieber einen größeren Wert in das erste Byte.
Titel: Antw:AskSin++ Library
Beitrag von: east am 17 Mai 2017, 11:05:28
Ok. Mache ich .....

Aber im ersten Byte steht bei keinem Device etwas. Also nur 0x00.

Habe nochmal meine Änderungen im XML verdeutlicht. Hoffe es hilft ein wenig.


Nochmal vielen Dank für die super Hilfe!!!
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Mai 2017, 11:13:08
Ok. Mache ich .....

Aber im ersten Byte steht bei keinem Device etwas. Also nur 0x00.

Genau - soweit ich bisher gesehen habe, ist das immer 0x00. Damit sollte ein anderer Wert eine Kollision mit existierenden oder zukünftigen Geräten vermeiden. Der Universal-Wetter-Sensor von Dirk hat zum Beispiel 0xF1 gesetzt.

Habe nochmal meine Änderungen im XML verdeutlicht. Hoffe es hilft ein wenig.

Hm - Du hast zweimal Channel mit index=1. Ist das so richtig? Die Switch-Channels müssten doch 3 & 4 sein bzw. index=3 count=2. Aber meine Kenntnisse der XML-Files beruhen hauptsächlich auf Vermutungen.
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 17 Mai 2017, 13:39:27
Ich kenne den FHEM-Code des Universalsensors. Dort sind die Codes F101 (innen) und F102 (außen) hinterlegt. Ich meine mal gelesen zu haben, dass DIY Geräte größer 0100 oder so beginnen sollen. Vielleicht war es auch > F100.

https://wiki.fhem.de/wiki/Universalsensor (https://wiki.fhem.de/wiki/Universalsensor)
Unter Firmware findet man den FHEM-Code und XML-Code der CCU.

Ich weiß nicht ob es noch weitere Geräte gibt.
Man müsste auf dem FHEM-Code vielleicht mal ein grep nach  HMConfig::culHmModel durchführen. Ich habe im Moment keinen Zugriff.
Titel: Antw:AskSin++ Library
Beitrag von: east am 17 Mai 2017, 13:46:29
Hab nochmal nachgesehen. Hast recht mit dem Index....

Muss ich wohl korrigieren.
Titel: Antw:AskSin++ Library
Beitrag von: east am 18 Mai 2017, 11:30:54
So hab jetzt nochmal getestet mit dem Index. Komischerweise funktioniert das nicht, wenn ich den Switch auf Index 2 oder 3 stelle.
Wenn ich das mache, geht die CCU2 in Störung und zeigt mir 4 anstatt 2 Switch Kanäle an. Und dann funktioniert auch nix.

Habe das jetzt komischerweise so realisieren müssen..... :o

/- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2017-05-10 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER

// number of relays - possible values 1,2,4
// will map to HM-LC-SW1-SM, HM-LC-SW2-SM, HM-LC-SW4-SM
#define RELAY_COUNT 2

// define all device properties
#define DEVICE_ID HMID(0x90,0x78,0x90)
#define DEVICE_SERIAL "xms1234567"
#define DEVICE_MODEL  0xF1,0xDF
#define DEVICE_FIRMWARE 0x10
#define DEVICE_TYPE DeviceType::Switch
#define DEVICE_INFO 0x04,0x01,0x00

#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include <Remote.h>
#include <SwitchChannel.h>



// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
#define LED_PIN2 6

// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8

// relay output pins compatible to the HM_Relay project
#define RELAY1_PIN 7
#define RELAY2_PIN 9

#define BUTTON1_PIN 3
#define BUTTON2_PIN 5

// number of available peers per channel
#define PEERS_PER_SWCHANNEL 2
#define PEERS_PER_BTNCHANNEL 10

// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef DualStatusLed<6,4> LedType;
typedef AskSin<LedType,NoBattery,RadioType> Hal;
Hal hal;

typedef RemoteChannel<Hal,PEERS_PER_BTNCHANNEL> BtnChannel;
typedef SwitchChannel<Hal,PEERS_PER_SWCHANNEL> SwChannel;

class MixDevice : public ChannelDevice<Hal,VirtBaseChannel<Hal>,4> {
public:
  VirtChannel<Hal,BtnChannel> c1,c2;
  VirtChannel<Hal,SwChannel> c3,c4;
public:
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal>,4> DeviceType;
  MixDevice (uint16_t addr) : DeviceType(addr) {
    DeviceType::registerChannel(c1,1);
    DeviceType::registerChannel(c2,2);
    DeviceType::registerChannel(c3,3);
    DeviceType::registerChannel(c4,4);
  }
  virtual ~MixDevice () {}

  BtnChannel& btn1Channel () { return c1; }
  BtnChannel& btn2Channel () { return c2; }
  SwChannel&  Sw3Channel  () { return c3; }
  SwChannel&  Sw4Channel  () { return c4; }
};
MixDevice sdev(0x20);

ConfigButton<MixDevice> cfgBtn(sdev);

// map number of channel to pin
// this will be called by the SwitchChannel class
uint8_t SwitchPin (uint8_t number) {
  switch( number ) {
   
    case 3: return RELAY1_PIN;
    case 4: return RELAY2_PIN;
   
   
  }
}

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  sdev.Sw3Channel().lowactive(false);
  sdev.Sw4Channel().lowactive(false);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  remoteChannelISR(sdev.btn1Channel(),BUTTON1_PIN);
  remoteChannelISR(sdev.btn2Channel(),BUTTON2_PIN);
 
}

void loop() {
  bool pinchanged = sdev.btn1Channel().checkpin();
  pinchanged |= sdev.btn2Channel().checkpin();

  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( pinchanged == false && worked == false && poll == false ) {
    // deep discharge protection
    // if we drop below critical battery level - switch off all and sleep forever
    if( hal.battery.critical() ) {
      // this call will never return
      hal.activity.sleepForever(hal);
    }

  if( worked == false && poll == false ) {
    hal.activity.savePower<Idle<> >(hal);
  }
  }
}
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Mai 2017, 11:45:21
Ich habe da eine Vermutung. Du hast bei dem SwitchChannel ja das Attribute count_from_sysinfo="23.0:1.0" drin. Das wird sicherlich bedeuten, dass die CCU die Anzahl der Kanäle aus der während des Pairen bereitgestellten SysInfo-Struktur bezieht. Kannst Du mal mit dem ersten Byte im DEVICE_INFO experimentieren. Da steht ja jetzt 4 - also insgesamt 4 Kanäle.

Nur mal um zu Lernen - kannst Du da mal 3 eintragen. Würde mich echt interessieren, was dann passiert.

Vermutung: Es werden dann 2 RemoteChannels und 1 SwitchChannel. Es werden also 3 SwitchChannels (1-3) angelegt und dann mit den 2 Remotes (1-2) überschrieben.

Im XML muss dann wahrscheinlich die Reihenfolge korrect sein. Also zuerst Channel index=1 count=2 type=Remote und dann Channel index=3 count=2 type=Switch. Das count_from_sysinfo Attribute darf dann nicht verwendet werden.

Aber es könnte auch alles ganz anders funktionieren  :(
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Mai 2017, 11:47:38
Kannst Du vielleicht auch mal eine separate XML-Datei verwenden. In Deiner sind ja auch noch originale Geräte defineirt. Nicht das da was durcheinander kommt.
Titel: Antw:AskSin++ Library
Beitrag von: east am 18 Mai 2017, 12:04:59
jo. klingt logisch. Wenn ich in der Device Info 0x04 Kanäle drin habe und in der XML der Index 3 auftaucht, werden ab den 2.ten Kanal vier Switchkanäle erstellt. Durch Index 1, so wie jetzt werden die 4 switchkanäle durch 2 Remotekanäle überschrieben. OK probiere mal ein wenig und mache mal ne neue XML-Datei.

Da aber im Arduino nur jeweils 2 Kanäle erstellt sind, kommt der Arduino wahrscheinlich nicht mehr klar und hängt sich auf. (Grüne LED leuchtet ständig)
Titel: Antw:AskSin++ Library
Beitrag von: east am 21 Mai 2017, 10:58:40
So. Jetzt mal ein bissel getestet und hier die Lösung, mit einer eigenen XML für die CCU....
//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2017-05-10 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER

// number of relays - possible values 1,2,4
// will map to HM-LC-SW1-SM, HM-LC-SW2-SM, HM-LC-SW4-SM
#define RELAY_COUNT 2

// define all device properties
#define DEVICE_ID HMID(0x90,0x78,0x90)
#define DEVICE_SERIAL "xms1234567"
#define DEVICE_MODEL  0xF1,0xDF
#define DEVICE_FIRMWARE 0x10
#define DEVICE_TYPE DeviceType::Switch
#define DEVICE_INFO 0x02,0x01,0x00

#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include <Remote.h>
#include <SwitchChannel.h>



// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
#define LED_PIN2 6

// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8

// relay output pins compatible to the HM_Relay project
#define RELAY1_PIN 7
#define RELAY2_PIN 9

#define BUTTON1_PIN 3
#define BUTTON2_PIN 5

// number of available peers per channel
#define PEERS_PER_SWCHANNEL 2
#define PEERS_PER_BTNCHANNEL 10

// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef DualStatusLed<6,4> LedType;
typedef AskSin<LedType,NoBattery,RadioType> Hal;
Hal hal;

typedef RemoteChannel<Hal,PEERS_PER_BTNCHANNEL> BtnChannel;
typedef SwitchChannel<Hal,PEERS_PER_SWCHANNEL> SwChannel;

class MixDevice : public ChannelDevice<Hal,VirtBaseChannel<Hal>,4> {
public:
  VirtChannel<Hal,BtnChannel> c1,c2;
  VirtChannel<Hal,SwChannel> c3,c4;
public:
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal>,4> DeviceType;
  MixDevice (uint16_t addr) : DeviceType(addr) {
    DeviceType::registerChannel(c1,1);
    DeviceType::registerChannel(c2,2);
    DeviceType::registerChannel(c3,3);
    DeviceType::registerChannel(c4,4);
  }
  virtual ~MixDevice () {}

  BtnChannel& btn1Channel () { return c1; }
  BtnChannel& btn2Channel () { return c2; }
  SwChannel&  Sw3Channel  () { return c3; }
  SwChannel&  Sw4Channel  () { return c4; }
};
MixDevice sdev(0x20);

ConfigButton<MixDevice> cfgBtn(sdev);

// map number of channel to pin
// this will be called by the SwitchChannel class
uint8_t SwitchPin (uint8_t number) {
  switch( number ) {
   
    case 3: return RELAY1_PIN;
    case 4: return RELAY2_PIN;
   
   
  }
}

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  sdev.Sw3Channel().lowactive(false);
  sdev.Sw4Channel().lowactive(false);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  remoteChannelISR(sdev.btn1Channel(),BUTTON1_PIN);
  remoteChannelISR(sdev.btn2Channel(),BUTTON2_PIN);
 
}

void loop() {
  bool pinchanged = sdev.btn1Channel().checkpin();
  pinchanged |= sdev.btn2Channel().checkpin();

  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( pinchanged == false && worked == false && poll == false ) {
    // deep discharge protection
    // if we drop below critical battery level - switch off all and sleep forever
    if( hal.battery.critical() ) {
      // this call will never return
      hal.activity.sleepForever(hal);
    }

  if( worked == false && poll == false ) {
    hal.activity.savePower<Idle<> >(hal);
  }
  }
}
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Mai 2017, 22:24:26
Na das sind ja gute Nachrichten. Willst Du das Device auch in FHEM einbinden ?
Titel: Antw:AskSin++ Library
Beitrag von: east am 21 Mai 2017, 22:42:24
Leider habe ich bis dato noch gar keine Erfahrung mit FHEM. Hatte es auch noch nie getestet. Brauche glaube dann einen CUL, oder?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 25 Mai 2017, 18:12:27
Ich würde gerne das Gerät HM-LC-RGBW-WM nachbauen.
Gibts dafür schon alles in der Lib oder muss da noch was aus der XML generiert werden?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 Mai 2017, 23:10:50
Ich habe mal jetzt so auf die Schnelle in das XML reingesehen - im Prinzip scheint es ja wie ein Dimmer zu funktionieren - aber die Listen unterscheiden sich schon. Da muss wohl noch etwas Aufwand in die Channel-Listen gesteckt werden.

@Dietmar kannst Du die mal generieren ?
Titel: Antw:AskSin++ Library
Beitrag von: Dietmar63 am 26 Mai 2017, 01:29:56
Gleicher Code wie beim letzten Mal?
Habe gesehen, dass du nur einen Teil der List Klassen verwendet hast.

Die Message Klassen hattest du nicht nötig.

Vielleicht schaffe ich es erst morgen Abend.
Morgen früh geht es leider schon  früh los.

Die Nachricht habe ich leider erst jetzt gelesen.

Titel: Antw:AskSin++ Library
Beitrag von: Xent am 30 Mai 2017, 20:27:47
Vielen Dank fürs generieren leider weiß ich nicht so recht, was ich davon brauche und wie ich es einbauen müsste.
Ich denke da weiß papa eher bescheid was getan werden muss.

Ich würde dann schauen, dass ich die Ausgabe als PWM etc. einbaue.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 30 Mai 2017, 21:47:51
Bei mir ist die Zeit gerade echt knapp. Du könntest ja auch erst mal den Dimmer nehmen und die 3 Kanäle für RGB missbrauchen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 30 Mai 2017, 22:33:03
Kenn ich ;-)
Meinst du nen neues Gerät definieren mit 3 Kanälen und dann auch ne neue XML für die CCU anlegen (da es maximal nen 2 Kanal-Dimmer gibt)
oder das Modell auf den RGB ändern und 3 Dimmerkanäle definieren?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 30 Mai 2017, 23:02:25
Es gibt das HM-LC-Dim1PWM-CV Example. Das ist ein Dimmer mit 3 Kanälen. 2 sind virtuell. Aber das muss ja so nicht sein.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 31 Mai 2017, 05:26:08
Ah ok, ich werd mich mal dran versuchen.
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 02 Juni 2017, 20:53:40
Hallo zusammen, ich hoffe jmd. kann mir nochmal weiterhelfen.
Ich bin gerade dabei das xml file für meinen Universalsensor zu basteln.
Ich bekomme die Helligkeit (vorletzter Teil der Nachricht "24") noch erfolgreich eingebunden, aber beim letzten Teil "01" welcher ein bool für "Bewegung erkannt" darstellt nicht mehr.

So sieht die Nachricht aus, die an die Homematic Zentrale gesandt wird.
0E 01 A0 70 212223 FD4365 00 19 31 24 01
Und so das xml File (abgeändert vom WDS10THO)
<homegearDevice version="1">
<supportedDevices>
<device id="HM-UniSen">
<description>HM-UniSen</description>
<typeNumber>0x99</typeNumber>
</device>
</supportedDevices>
<properties>
<receiveMode>config</receiveMode>
<receiveMode>wakeUp</receiveMode>
<timeout>600</timeout>
<hasBattery>true</hasBattery>
</properties>
<functions>
<function channel="0" type="MAINTENANCE">
<properties>
<internal>true</internal>
</properties>
<configParameters>ash550_dev_master--0</configParameters>
<variables>maint_ch_values--0</variables>
</function>
<function channel="1" type="WEATHER">
<properties>
<linkSenderFunctionTypes>
<type>WEATHER_TH</type>
</linkSenderFunctionTypes>
</properties>
<configParameters>ash550_ch_master--1</configParameters>
<variables>ash550_ch_values--1</variables>
<linkParameters>ash550_ch_link--1</linkParameters>
</function>
</functions>
<packets>
<packet id="WEATHER_EVENT">
<direction>toCentral</direction>
<type>0x70</type>
<channel>1</channel>
<binaryPayload>
<element>
<index>9.0</index>
<size>1.7</size>
<parameterId>TEMPERATURE</parameterId>
<isSigned>true</isSigned>
</element>
<element>
<index>11.0</index>
<parameterId>HUMIDITY</parameterId>
</element>
<element>
<index>12.0</index>
<parameterId>BRIGHTNESS</parameterId>
</element>
<element>
<index>13.0</index>
<parameterId>MOTION</parameterId>
</element>
</binaryPayload>
</packet>
</packets>
<parameterGroups>
<configParameters id="ash550_ch_master--1"/>
<configParameters id="ash550_dev_master--0">
<parameter id="BURST_RX">
<properties/>
<logicalBoolean>
<defaultValue>false</defaultValue>
</logicalBoolean>
<physicalInteger>
<index>1.0</index>
<size>1.0</size>
<list>0</list>
<operationType>config</operationType>
</physicalInteger>
</parameter>
<parameter id="ROAMING">
<properties>
<internal>true</internal>
</properties>
<logicalBoolean>
<defaultValue>false</defaultValue>
</logicalBoolean>
<physicalInteger>
<operationType>store</operationType>
</physicalInteger>
</parameter>
</configParameters>
<variables id="ash550_ch_values--1">
<parameter id="TEMPERATURE">
<properties>
<writeable>false</writeable>
<signed>true</signed>
<unit>°C</unit>
<casts>
<decimalIntegerScale>
<factor>1.000000</factor>
</decimalIntegerScale>
</casts>
</properties>
<logicalDecimal>
<minimumValue>-40.000000</minimumValue>
<maximumValue>80.000000</maximumValue>
</logicalDecimal>
<physicalInteger groupId="TEMPERATURE">
<size>1.7</size>
<operationType>command</operationType>
</physicalInteger>
<packets>
<packet id="WEATHER_EVENT">
<type>event</type>
</packet>
</packets>
</parameter>
<parameter id="HUMIDITY">
<properties>
<writeable>false</writeable>
<unit>%</unit>
</properties>
<logicalInteger>
<minimumValue>0</minimumValue>
<maximumValue>100</maximumValue>
</logicalInteger>
<physicalInteger groupId="HUMIDITY">
<size>1.0</size>
<operationType>command</operationType>
</physicalInteger>
<packets>
<packet id="WEATHER_EVENT">
<type>event</type>
</packet>
</packets>
</parameter>
<parameter id="BRIGHTNESS">
<properties>
<writeable>false</writeable>
<unit>%</unit>
</properties>
<logicalInteger>
<minimumValue>0</minimumValue>
<maximumValue>100</maximumValue>
</logicalInteger>
<physicalInteger groupId="BRIGHTNESS">
<size>1.0</size>
<operationType>command</operationType>
</physicalInteger>
<packets>
<packet id="WEATHER_EVENT">
<type>event</type>
</packet>
</packets>
</parameter>
<parameter id="MOTION">
<properties>
<writeable>false</writeable>
<unit>-</unit>
</properties>
<logicalInteger>
<minimumValue>0</minimumValue>
<maximumValue>1</maximumValue>
</logicalInteger>
<physicalInteger groupId="MOTION">
<size>1.0</size>
<operationType>command</operationType>
</physicalInteger>
<packets>
<packet id="WEATHER_EVENT">
<type>event</type>
</packet>
</packets>
</parameter>
</variables>
<variables id="maint_ch_values--0">
<parameter id="UNREACH">
<properties>
<writeable>false</writeable>
<service>true</service>
</properties>
<logicalBoolean/>
<physicalInteger groupId="UNREACH">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="STICKY_UNREACH">
<properties>
<service>true</service>
<sticky>true</sticky>
</properties>
<logicalBoolean/>
<physicalInteger groupId="STICKY_UNREACH">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="CONFIG_PENDING">
<properties>
<writeable>false</writeable>
<service>true</service>
</properties>
<logicalBoolean/>
<physicalInteger groupId="CONFIG_PENDING">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="LOWBAT">
<properties>
<writeable>false</writeable>
<service>true</service>
</properties>
<logicalBoolean/>
<physicalInteger groupId="LOWBAT">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="RSSI_DEVICE">
<properties>
<writeable>false</writeable>
</properties>
<logicalInteger/>
<physicalInteger groupId="RSSI_DEVICE">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="RSSI_PEER">
<properties>
<writeable>false</writeable>
</properties>
<logicalInteger/>
<physicalInteger groupId="RSSI_PEER">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="CENTRAL_ADDRESS_SPOOFED">
<properties>
<service>true</service>
<sticky>true</sticky>
<control>NONE</control>
</properties>
<logicalEnumeration>
<defaultValue>0</defaultValue>
<value>
<id>UNSET</id>
<index>0</index>
</value>
<value>
<id>CENTRAL_ADDRESS_SPOOFED</id>
<index>1</index>
</value>
</logicalEnumeration>
<physicalInteger groupId="CENTRAL_ADDRESS_SPOOFED">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
</variables>
<linkParameters id="ash550_ch_link--1"/>
</parameterGroups>
</homegearDevice>

Kann mir jmd. sagen worans liegt? Ich muss leider gestehen, dass ich die Syntax überhaupt nicht verstehe und nichtmal verstehe was "size", "index" etc. sind. Bei der Brightness scheine ich aber immerhin richtig geraten zu haben :)

Ich habe es jetzt erst garnicht als Switch versucht sondern erstmal auch als Zahl.

Danke.

EDIT: Habe es jetzt selber hinbekommen. Btw. gibt es irgendwo eine Anleitung zum Thema?
Habe diesen Thread https://forum.fhem.de/index.php?topic=61780.0 (https://forum.fhem.de/index.php?topic=61780.0) gefunden, allerdings scheint HM Wired nicht wirklich mit HM BidCos übereinander zu passen...
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Juni 2017, 14:44:12
Ich kenne auch nur die Anleitung von Thorsten für HM-Wired. Aber das scheint leider nicht gleich zu sein.

Könntest Du bitte die Lösung noch posten, falls jamand mal etwas ähnliches bauen will. Soweit ich das verstanden habe, hast Du das Weather-Event um einen Motion-Status erweitert. Richtig ? Und mit deinem XML läuft es mit der CCU. Korrekt ?
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 04 Juni 2017, 07:24:21
Ich habe das Weather Event um eine Meldung zur Helligkeit und Bewegung erweitert.
Hier die xml Datei

<homegearDevice version="1">
<supportedDevices>
<device id="HM-UniSen">
<description>HM-UniSen</description>
<typeNumber>0x99</typeNumber>
</device>
</supportedDevices>
<properties>
<receiveMode>config</receiveMode>
<receiveMode>wakeUp</receiveMode>
<timeout>600</timeout>
<hasBattery>true</hasBattery>
</properties>
<functions>
<function channel="0" type="MAINTENANCE">
<properties>
<internal>true</internal>
</properties>
<configParameters>ash550_dev_master--0</configParameters>
<variables>maint_ch_values--0</variables>
</function>
<function channel="1" type="WEATHER">
<properties>
<linkSenderFunctionTypes>
<type>WEATHER_TH</type>
</linkSenderFunctionTypes>
</properties>
<configParameters>ash550_ch_master--1</configParameters>
<variables>ash550_ch_values--1</variables>
<linkParameters>ash550_ch_link--1</linkParameters>
</function>
</functions>
<packets>
<packet id="WEATHER_EVENT">
<direction>toCentral</direction>
<type>0x70</type>
<channel>1</channel>
<binaryPayload>
<element>
<index>9.0</index>
<size>1.7</size>
<parameterId>TEMPERATURE</parameterId>
<isSigned>true</isSigned>
</element>
<element>
<index>11.0</index>
<size>1.0</size>
<parameterId>HUMIDITY</parameterId>
</element>
<element>
<index>12.0</index>
<size>1.0</size>
<parameterId>BRIGHTNESS</parameterId>
</element>
<element>
<index>13.0</index>
<size>1.0</size>
<parameterId>MOTION</parameterId>
</element>
</binaryPayload>
</packet>
</packets>
<parameterGroups>
<configParameters id="ash550_ch_master--1"/>
<configParameters id="ash550_dev_master--0">
<parameter id="BURST_RX">
<properties/>
<logicalBoolean>
<defaultValue>false</defaultValue>
</logicalBoolean>
<physicalInteger>
<index>1.0</index>
<size>1.0</size>
<list>0</list>
<operationType>config</operationType>
</physicalInteger>
</parameter>
<parameter id="ROAMING">
<properties>
<internal>true</internal>
</properties>
<logicalBoolean>
<defaultValue>false</defaultValue>
</logicalBoolean>
<physicalInteger>
<operationType>store</operationType>
</physicalInteger>
</parameter>
</configParameters>
<variables id="ash550_ch_values--1">
<parameter id="TEMPERATURE">
<properties>
<writeable>false</writeable>
<signed>true</signed>
<unit>°C</unit>
<casts>
<decimalIntegerScale>
<factor>10.000000</factor>
</decimalIntegerScale>
</casts>
</properties>
<logicalDecimal>
<minimumValue>-40.000000</minimumValue>
<maximumValue>80.000000</maximumValue>
</logicalDecimal>
<physicalInteger groupId="TEMPERATURE">
<size>1.7</size>
<operationType>command</operationType>
</physicalInteger>
<packets>
<packet id="WEATHER_EVENT">
<type>event</type>
</packet>
</packets>
</parameter>
<parameter id="HUMIDITY">
<properties>
<writeable>false</writeable>
<unit>%</unit>
</properties>
<logicalInteger>
<minimumValue>0</minimumValue>
<maximumValue>100</maximumValue>
</logicalInteger>
<physicalInteger groupId="HUMIDITY">
<size>1.0</size>
<operationType>command</operationType>
</physicalInteger>
<packets>
<packet id="WEATHER_EVENT">
<type>event</type>
</packet>
</packets>
</parameter>
<parameter id="BRIGHTNESS">
<properties>
<writeable>false</writeable>
<unit>%</unit>
</properties>
<logicalInteger>
<minimumValue>0</minimumValue>
<maximumValue>100</maximumValue>
</logicalInteger>
<physicalInteger groupId="BRIGHTNESS">
<size>1.0</size>
<operationType>command</operationType>
</physicalInteger>
<packets>
<packet id="WEATHER_EVENT">
<type>event</type>
</packet>
</packets>
</parameter>
<parameter id="MOTION">
<properties>
<writeable>false</writeable>
</properties>
<logicalBoolean/>
<physicalInteger groupId="MOTION">
<operationType>command</operationType>
</physicalInteger>
<packets>
<packet id="WEATHER_EVENT">
<type>event</type>
</packet>
</packets>
</parameter>
</variables>
<variables id="maint_ch_values--0">
<parameter id="UNREACH">
<properties>
<writeable>false</writeable>
<service>true</service>
</properties>
<logicalBoolean/>
<physicalInteger groupId="UNREACH">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="STICKY_UNREACH">
<properties>
<service>true</service>
<sticky>true</sticky>
</properties>
<logicalBoolean/>
<physicalInteger groupId="STICKY_UNREACH">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="CONFIG_PENDING">
<properties>
<writeable>false</writeable>
<service>true</service>
</properties>
<logicalBoolean/>
<physicalInteger groupId="CONFIG_PENDING">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="LOWBAT">
<properties>
<writeable>false</writeable>
<service>true</service>
</properties>
<logicalBoolean/>
<physicalInteger groupId="LOWBAT">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="RSSI_DEVICE">
<properties>
<writeable>false</writeable>
</properties>
<logicalInteger/>
<physicalInteger groupId="RSSI_DEVICE">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="RSSI_PEER">
<properties>
<writeable>false</writeable>
</properties>
<logicalInteger/>
<physicalInteger groupId="RSSI_PEER">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
<parameter id="CENTRAL_ADDRESS_SPOOFED">
<properties>
<service>true</service>
<sticky>true</sticky>
<control>NONE</control>
</properties>
<logicalEnumeration>
<defaultValue>0</defaultValue>
<value>
<id>UNSET</id>
<index>0</index>
</value>
<value>
<id>CENTRAL_ADDRESS_SPOOFED</id>
<index>1</index>
</value>
</logicalEnumeration>
<physicalInteger groupId="CENTRAL_ADDRESS_SPOOFED">
<operationType>internal</operationType>
</physicalInteger>
</parameter>
</variables>
<linkParameters id="ash550_ch_link--1"/>
</parameterGroups>
</homegearDevice>

Allerdings habe ich ein neues Problem, welches ich nicht gelöst bekomme.
Eigentlich wurde im seriellen Monitor immer noch die Antwort von der Zentrale angezeigt und ob das Ganze "ACK"ed wurde. Da hat alles super funktioniert. Das ist jetzt aber plötzlich weg (ohne dass ich denke etwas relevantes geändert zu haben) und nur erste die Nachrichten kommt an, danach dem 600s Timeout wird das Gerät dann als offline angezeigt.

AskSin++ V1.0.4
Address Space: 32 - 73
CC init12..........3 - ready
Bat: 33
<- 0E 00 A0 70 212223 000000 01 11 3C 5B 00
<- 0E 01 A0 70 212223 000000 01 13 3B 5C 01
<- 0E 02 A0 70 212223 000000 01 0C 3C 58 00
<- 0E 03 A0 70 212223 000000 01 14 3B 5D 01
<- 0E 04 A0 70 212223 000000 01 14 3C 41 00
<- 0E 05 A0 70 212223 000000 01 14 41 3A 01
<- 0E 06 A0 70 212223 000000 01 14 3E 4C 00

Kannst du mir sagen, woran das liegen könnte?
Vielen Dank
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 Juni 2017, 11:42:55
Du sendest an 000000 - anstatt zur Zentrale. Das Gerät ist nicht korrekt gepairet.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 04 Juni 2017, 17:23:59
Das passt aber schon. Auch gepairte Sensoren senden an 000000.
Das funktioniert bei meinen eigenen Temperatursensoren (mit NewAskSin), als auch z.B. bei meinem PowerMeter von EQ3.
Sowohl die FHEM-Zentrale also auch gepeerte Aktoren werten so ein "gebroadcastetes" Telegramm aus.

Es funktioniert sogar eher _nicht_, wenn der Sensor an jedes Ziel einzeln sendet - da hatten meine RT-DNs massive Probleme.

Martin
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 Juni 2017, 23:13:29
Also ein Ack wird nur angefordert, wenn nicht an die Broadcast-Adresse gesendet wird. Wenn nicht gepaired ist und an 000000 gesendet wird, kommt also auch keine Ack. Wer soll denn da antworten ?
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 05 Juni 2017, 00:32:22
Acks bei Sensoren sind eher unüblich. Hatte ich am Anfang auch - lief dann allerdings in Probleme damit rein. Weiss aber nicht mehr genau, wo das Problem war.

martinp876 hat mir dann davon abgeraten, bei Sensoren Acks zu verwenden. Seitdem sende ich grundsätzlich ohne Acks.

Anfangs hatte ich noch bei gepeerten Devices als Zieladresse den Peer drin, bekam dann allerdings bei zwei Peers (und damit zwei hintereinander gesendeten Messages) Probleme: mein zweiter RT-DN reagierte auf die zweite, an ihn gerichtete Message nicht mehr. Nur der jeweils zuerst angesprochene RT-DN empfing die Temperatur.

Seitdem sende ich vom Sensor aus _immer_ an 000000 - egal, ob mit der Zentrale gepairt oder nicht, oder mit weiteren Peers gepeert. Und das immer ohne Anforderung eines Acks. Was interessiert auch den Sensor, ob seine Sensordaten irgendwo angekommen sind? In 2-3 Minuten kommt ja eh die nächste Ladung an Daten... Wer die Daten braucht, soll sie auswerten, wer nicht - halt nicht. Und ob ein Aktor Daten von diesem Sensor entgegennimmt, steht eh in dessen Peer-Tabelle.

Es geht hier aber nur um die regelmäßig gesendeten Sensordaten (Messagetyp 0x70).
Die sonstige Kommunikation (Pairing, getConfig, Register setzen) läuft natürlich schon mit Acks und entsprechender Zieladresse.

Gruss,
Martin
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 Juni 2017, 19:48:53
Ok - das klinkt auch irgendwie logisch logisch.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2017, 07:54:19
Ich verscuche gerade beim HM-LC-SWX-SM die Methode switchState zu überschreiben, da ich da ein eigenes Verhalten implementieren möchte.
Leider bin ich in C++ nicht ganz so weit, dass ich direkt den richtigen Weg gefunden habe.

Ich habe mich aktuell durch Try&Error durch die Fehler durchgearbeitet.

Das ist meine neue Klasse SwitchChannel1
namespace as {
template <class HalType,int PeerCount>
class SwitchChannel1 : public SwitchChannel<HalType,PeerCount>{

protected:
  typedef SwitchChannel1<HalType,PeerCount> SwitchChannel;

public:
  SwitchChannel1 () : SwitchChannel {}

  void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate) {
    uint8_t pin = SwitchPin(SwitchChannel::BaseChannel::number());
    if( newstate == AS_CM_JT_ON ) {
      digitalWrite(pin,lowact ? LOW : HIGH);
    }
    else if ( newstate == AS_CM_JT_OFF ) {
      digitalWrite(pin,lowact ? HIGH : LOW);
    }
    SwitchChannel::BaseChannel::changed(true);
  }
};
};

aktuell kommen folgende Fehler:
E:\Eigene Dokumente\GitHub\AskSinPP\examples\HM-LC-SWX-SM\HM-LC-SWX-SM.ino: In constructor 'as::SwitchChannel1<HalType, PeerCount>::SwitchChannel1()':

HM-LC-SWX-SM:79: error: expected '{' before 'void'

   void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate) {

   ^

E:\Eigene Dokumente\GitHub\AskSinPP\examples\HM-LC-SWX-SM\HM-LC-SWX-SM.ino: In instantiation of 'as::SwitchChannel1<HalType, PeerCount>::SwitchChannel1() [with HalType = as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >; int PeerCount = 2]':

C:\Program Files (x86)\Arduino\libraries\AskSinPP/MultiChannelDevice.h:474:102:   required from 'as::MultiChannelDevice<HalType, ChannelType, ChannelCount, List0Type>::MultiChannelDevice(uint16_t) [with HalType = as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >; ChannelType = as::SwitchChannel1<as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >, 2>; int ChannelCount = 4; List0Type = as::List0; uint16_t = unsigned int]'

E:\Eigene Dokumente\GitHub\AskSinPP\examples\HM-LC-SWX-SM\HM-LC-SWX-SM.ino:95:21:   required from here

HM-LC-SWX-SM:77: error: constructor delegates to itself

   SwitchChannel1 () : SwitchChannel {}

                                      ^

exit status 1
expected '{' before 'void'

Damit dann die neue Klasse benutzt wird reicht es ja bei der Definition des MultiChannelDevices die neue Klasse einzutragen oder?
// setup the device with channel type and number of channels
typedef MultiChannelDevice<Hal,SwitchChannel1<Hal,PEERS_PER_CHANNEL>,4> SwitchType;

Vielen Dank schonmal
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 Juni 2017, 14:05:12
Jetzt mal ohne den Compiler anzuwerfen:

class SwitchChannel1 : public SwitchChannel<HalType,PeerCount>{

protected:
  typedef SwitchChannel<HalType,PeerCount> BaseChannel;

public:
  SwitchChannel1 () : BaseChannel()  {}

 

Ja genau einfach die Klasse bei der Definition des Devices austauschen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2017, 16:35:31
Super, damit gehts.
Vielen Dank.

Will damit den Motor einer Katzenklappe ansteuern und damit ich den Status weiß, soll beim einschalten und ausschalten der Motor für die Verriegelung kurz in die eine oder die andere Richtung drehen und dann wieder stoppen ;-)
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 26 Juni 2017, 21:56:19
Nochmal ich xD

Ich möchte, dass der Kanal 1 nach dem einschalten des Arduino ausgeschaltet wird (Katzenklappe verschließen).

Aktuell mache ich dies so:

sdev.channel(1).switchState(AS_CM_JT_ON, AS_CM_JT_OFF);

Das schaltet den Kanal aus, aber sendet kein Statusupdate an Homematic.
Wie mache ich es richtig?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 26 Juni 2017, 22:30:45
Der Einschaltstatus jedes Kanales wird mit dem "powerUpAction" Regsiter bestimmt. Da brauchst Du gar nichts weiter tun.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 27 Juni 2017, 05:24:56
Hmm, bei mir passiert da nichts ...

Vielleicht ist das Pairing auch nicht ganz richtig.
Kann nur Kanal 1 konfigurieren, bei den andere steht, ich soll in den Servicemeldungen schauen.
Ich werd heut Nachmittag das Pairing nochmal neu machen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Juni 2017, 08:37:14
Kannst Du mal den ganzen Sketch zeigen
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 27 Juni 2017, 11:18:56
Hier ist der Sketch.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Juni 2017, 12:28:41
Hm - das macht für mich irgendwie alles keinen richtigen Sinn.

Was soll das Geräte wie steuern ? Vielleicht kann ich Dir besser helfen, wenn ich weiss, was Du vor hast.

Ich habe bisher verstanden, dass eine Katzenklappe gesteuert werden soll. Dazu soll der Kanal 1 angeschalten werden und das führt dazu, dass ein Pin für eine bestimmte Zeit auf HIGH gesetzt wird. Wird der Kanal 1 wieder ausgeschalten, soll ein Pin (ein anderer ??? ) ebenfalls für eine bestimmte Zeit auf HIGH gestelt werden. Das soll dann sicherlich die Klappe hoch bzw. runter fahren.

Das wird sich schwer mit dem Switch abbilden lassen. Genau dafür gibt es Blind-Aktoren. Dazu fehlt aber leider noch ein Example in der Lib.

Mit den Standard-Switch könntest Du das auch machen, indem Du Kanal 1 für hoch und Kanal 2 für runter nimmst. Dann kannst Du set on-for-timer benutzen, um einen Kanal nur eine bestimmte Zeit an zu lassen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 27 Juni 2017, 12:47:48
Also eigentlich klappt das steuern über die GUI ganz gut.

Dieser Code sorgt dafür, dass wenn Kanal 1 eingeschaltet wird, der Motor für 250ms eingeschaltet.
Entweder nach Links oder nach Rechts drehend.

Jetzt ist es aber so, dass wenn ich den Kanal über die GUI einschalte und dann den Arduino resette oder aber neu flashe, dass die GUI immer noch auf "An" steht.
Wenn ich die letzte Zeile in der Setup-Methode einkommentiere, dann wird die Klappe wieder verriegelt, aber es wird scheinbar kein Statusupdate gesendet.

if( newstate == AS_CM_JT_ON ) {
         PORTC &= ~B00000011;
         PORTD |= B11000000;
         delay(250);
         PORTD &= ~B11000000;
      }
      else if ( newstate == AS_CM_JT_OFF ) {
         PORTD &= ~B11000000;
         PORTC |= B00000011;
         delay(250);
         PORTC &= ~B00000011;
      }
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Juni 2017, 13:08:34
Du darfst den init-Code (ja - lowactive() ist ein blöder Name) nicht rausnehmen. Der initialisiert den Channel. Es wird der gespeicherte  PowerOn-Zustand hergestellt und dann der Status gesendet.

  sdev.init(hal);

  for( uint8_t i=1; i<=sdev.channels(); ++i ) {
    sdev.channel(i).lowactive(false);
  }

  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 27 Juni 2017, 14:23:53
Ahhh, ok.
Dachte vom Namen her dass ich das nicht brauche xD

Mir ist übrigens noch aufgefallen, dass du zwar den LED_PIN definierst, diesen aber dann die Konstante nicht verwendest.
Hatte am Anfang auf Pin 4 auch nen Ausgang drauf und hab mich immer gewundert, warum der was macht obwohl ich den LED_PIN geändert hatte ;-)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Juni 2017, 14:54:58
Hm, ja - die Defines sollen noch weg. Die Konfiguration erfolgt ja direkt durch die Template-Argumente in den TypeDefs.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 27 Juni 2017, 21:57:47
Soo, nun funktioniert erstmal alles.
Nur ist der Arduino nach kurzer Zeit nicht mehr erreichbar, also reagiert nicht mehr.
Angeschlossen ist er direkt an nen USB-Netzteil.

Muss ich morgen abend mal schauen.
Die aktuelle Version des Sketches ist im Anhang.
Das ganze läuft auf einem Arduino Nano.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Juni 2017, 22:42:18
Es gibt gerade im Master ein Problem, dass nach einiger Zeit keine nachrichten mehr empfangen werden. Könnte mir vorstellen, dass Du auch dieses Problem hast.
Ich habe gerade ein paar Änderungen im Radio.h eingecheckt. Hoffe, dass der Empfang nun wieder robuster ist. Bitte mal die Lib aktualisieren und testen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Juni 2017, 22:44:43
Wenn Du nur einen Kanal hast, solltest Du auch die richtige ModelID setzen

#define DEVICE_MODEL  HM_LC_SW1_SM

Und was passiert auf Kanal 6 ????
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 28 Juni 2017, 11:22:15
Hört sich nach meinem Problem an xD

Am 2. Kanal ist auch ein Relais mit dem ich den Motor für die Verriegelung zum rein kommen sperren kann, falls einer der Kater mit ner Beute rein will und ich das sehe xD

Das noch 4 Kanäle eingetragen sind liegt einfach daran, dass ich noch nicht ganz fertig bin.
Will auch noch 3  LEDs für den Status einbauen.

Ich werd heut abend mal die neue Version probieren.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Juni 2017, 11:37:34
Für 6 Kanäle gibt es leider keine extistierendes Gerät. Dann müsstest Du Dir ein eigenes definieren. Für eine CCU hat das jemand schon mal vor einiger Zeit gemacht. Musst Du mal rückwärts suchen. Für FHEM muss ein Erweiterungsmodul geschrieben werden.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Juni 2017, 11:39:20
Hört sich nach meinem Problem an xD

Ich werd heut abend mal die neue Version probieren.

Bin über jeden Feedback erfreut. Bei mir tritt das Problem "leider" nicht bzw. ganz selten auf. Wahrscheinlich hängt es mit dem benutzen IO zusammen. Kann es sein, dass Du einen CUL/NanoCUL verwendest ?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 28 Juni 2017, 11:43:24
Ich benutze nur die CCU2 ;-)
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 29 Juni 2017, 21:27:55
Reagiert auch mit der aktuell Lib manchmal nicht mehr.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 Juni 2017, 22:07:41
Mist - gibt es irgendwelche Muster ? Wann es nicht mehr geht ? Was passiert vorher auf der Console ?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 30 Juni 2017, 08:10:42
Was auf der Konsole los ist, kann ich gerade leider nicht sagen, da ich den aktuell einfach nur an nem USB Netzteil habe.
Heute morgen hat er wieder nicht mehr reagiert.
Gestern Abend habe ich nur einmal neu eingesteckt, da er nicht reagierte.
Danach habe ich nichts mehr zu ihm gesendet, da die Klappe ja beim Neustart verriegelt.

Wenn man der Arduino neugestartet wurde, dann reagiert er auf Befehle nur nach einiger Zeit des nichts tun reagiert dann nichts mehr.
Ich werde heut Nachmittag mal eine Version des Sketches mit der V1 fertig machen, da sollte der Fehler ja nicht auftreten oder?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 30 Juni 2017, 08:40:26
Schwer zu sagen. Einen Versuch ist es wert.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 01 Juli 2017, 07:38:58
Hatte gestern kurz die alte Version drauf, allerdings hab ichs nicht neu gepairt.
Daher kamen wohl die Rückmeldungen nicht richtig an und das automatische Abschalten nach dem Start ging nicht.

Hab dann wieder die aktuelle Version drauf gemacht und extra den Laptop dran gelassen damit ich die Konsole sehe.
Heut morgen funktionierte der Schalter dann doch noch.
Ich werd das mal weiter in Beobachtung lassen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 Juli 2017, 13:53:32
Habe jetzt mal den Laptop dran und die Konsole offen gelassen.

Hier ist die Ausgabe der Konsole:
<- 0E 01 A2 10 123456 000000 06 01 00 00 00
<- 0E 02 A2 10 123456 000000 06 02 00 00 00
<- 0E 03 A2 10 123456 000000 06 03 00 00 00
<- 0E 04 A2 10 123456 000000 06 04 00 00 00
-> 0B 43 A0 01 473071 123456 02 0E
<- 0E 43 82 10 123456 473071 06 02 00 00 5E
-> 0B 43 A0 01 473071 123456 02 0E
<- 0E 43 82 10 123456 473071 06 02 00 00 5E
-> 0B 4C A0 01 473071 123456 03 0E
<- 0E 4C 82 10 123456 473071 06 03 00 00 5E
-> 0B 4C A0 01 473071 123456 03 0E
<- 0E 4C 82 10 123456 473071 06 03 00 00 5E
-> 0B 55 A0 01 473071 123456 04 0E
<- 0E 55 82 10 123456 473071 06 04 00 00 5E
-> 0B 5E A0 01 473071 123456 02 0E
<- 0E 5E 82 10 123456 473071 06 02 00 00 5E
-> 0B 67 A0 01 473071 123456 03 0E
<- 0E 67 82 10 123456 473071 06 03 00 00 5E
-> 0B 70 A0 01 473071 123456 04 0E
<- 0E 70 82 10 123456 473071 06 04 00 00 5D
-> 0E 79 A0 11 473071 123456 02 01 C8 00 00
<- 0E 79 80 02 123456 473071 01 01 C8 00 62
-> 0E 79 A0 11 473071 123456 02 01 C8 00 00
<- 0E 79 80 02 123456 473071 01 01 C8 00 62
-> 0E 79 A0 11 473071 123456 02 01 C8 00 00
<- 0E 79 80 02 123456 473071 01 01 C8 00 62
-> 0E 02 A0 11 473071 123456 02 01 00 00 00
<- 0E 02 80 02 123456 473071 01 01 00 00 62
-> 0E 02 A0 11 473071 123456 02 01 00 00 00
<- 0E 02 80 02 123456 473071 01 01 00 00 60
-> 0E 0B A0 11 473071 123456 02 01 C8 00 00
<- 0E 0B 80 02 123456 473071 01 01 C8 00 60
-> 0E 0B A0 11 473071 123456 02 01 C8 00 00
<- 0E 0B 80 02 123456 473071 01 01 C8 00 5F
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Juli 2017, 15:08:53
Komisch. Da kommt die gleiche Nachricht 2-3 mal.
Irgendwas scheint da mit dem Timing nicht zu stimmen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 06 Juli 2017, 09:48:03
Ich habe den Messagebuffer mal vergrößert. Vielleicht hilft das ja.
Kannst Du bitte nochmal die Firmware Aktualisieren. Falls es Probleme beim Empfang gibt, wird jetzt auch eine Message auf der Console ausgegeben.
Titel: Antw:AskSin++ Library
Beitrag von: StefanH am 08 Juli 2017, 15:52:06
Hallo zusammen,

erst einmal großes Lob @papa und alle die hier helfen. Ich habe mir mit der AskSin++ Library sehr viel Geld sparen können und habe sehr viel Spaß beim implementieren meiner neuen Hausautomatisieren.

AskSin++ läuft bei mir bereits als 4-Kanal Switch (HM-LC-SW4-SM). Anfangs hatte ich Probleme, da ich das C1101 entsprechend nach nanoCUL angelötet hatte, aber jetzt passt alles.

Jetzt zu meinem Problem: Ich würde das HM-LC-SW4-SM gerne als Rollladensteuerung verwenden. Dazu habe ich das Rollo-Modul in FHEM eingebunden. Das klappt soweit auch. Mein Rollladen soll aber auch von Hand bedientbar sein und nicht nur das Webinterface. Mit dem Config-Taster klappt das ja auch. Wenn ich diesen drücke, wird Kanal 1 eingeschaltet, der Rollladen fährt hoch. Drücke ich den Taster nochmal, bleibt er wieder stehen. Da es aber nur einen Taster gibt, bekomme ich ihn nicht mehr hoch. Gibt es eine einfache Möglichkeit einen zweiten Taster in den Code mit unterzubringen? Eigentlich müsste man ja nur eine zweite ISR verwenden, die dann channel.toggle aufruft, oder nicht?
Auch wenn ich recht gut C programmieren kann, sind meine Fähigkeiten mit C++ noch etwas beschränkt, vor allem da hier  alles mit Templates programmiert ist.

Kann mir jemand ein einfache Lösung zeigen? Eigentlich müssten entsprechende Funktionen für den Sender ja bereits implementiert sein, Bsp. in .h.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Juli 2017, 21:45:58
Einfach eine eigene Button-Klasse ableiten und dann im setup() mit dem entsprechenden Pin verbinden. Könne in etwa so aussehen (nicht getestet):

class Btn2 : public Button {
public:
  Btn2 () {}
  virtual ~Btn2 () {}
  virtual void state (uint8_t s) {
    Button::state(s);
    if( s == Button::released ) {
      // short press action
    }
    else if( s == Button::longreleased ) {
      // long press action
    }
  }
} btn2;

void setup () {
   ....
  buttonISR(btn2,BUTTON2_PIN);
}
Titel: Antw:AskSin++ Library
Beitrag von: StefanH am 09 Juli 2017, 15:36:54
Vielen Dank!

Hat bestens funktioniert!
Titel: Antw:AskSin++ Library
Beitrag von: capt_bluebaer am 09 Juli 2017, 19:24:41
Hallo Leute,

zuerst möchte ich mich 'mal dem Dank meines Vorredners anschließen, tolles Projekt.
Mit meinen bescheidenen Kenntnissen in C++ war ich in der Lage, mir einen HM-WDS-SEC Wassermelder softwareseitig zusammenzufriemeln, er geht demnächst in die Hardware Produktion.
Aktuell bin ich dabei, den HM-LC-Dim1PWM-CV aus den Examples einzusetzen, er soll in Vollendung mit einem PWM-DA Wandler nach diesem Vorbild https://www.cctools.eu/ext_index.php/artikel/1420 (https://www.cctools.eu/ext_index.php/artikel/1420) als Ansteuerung eines Vorschaltgerätes 0-10V für Leuchtstoffröhren (Aquarium) eingesetzt werden, die Hardware funktioniert soweit.
Mein Problem ist das Verhalten des Dimmers, wenn er durch einen gepeerten Pushbutton getoggelt (short pressed) wird. FHEM zeigt den Status on/off danach immer invertiert an. Das passiert wirklich nur mit dem gepeerten Device, ein Toggeln im Webinterface als auch mit dem Config-Button führt zur richtigen Status-Anzeige. Die Long-pressed Aktionen wiederum funktionieren richtig.
Hier mal ein paar Kommunikations-Beispiele (Push-Button Device ID 518FBC):
Config-Button toggle on:
 debounce
 released
<- 0F 08 A6 10 111222 000000 06 01 C8 00 52 C8  - 613

Config-Button toggle off:
 debounce
 released
<- 0F 09 A6 10 111222 000000 06 01 00 00 52 00  - 728

Push-Button toggle on:
-> 0B 82 A4 40 518FBC 111222 02 28  - 832
<- 0F 82 80 02 111222 518FBC 01 01 00 10 78 00  - 835
<- 0F 0A A6 10 111222 000000 06 01 C8 00 78 C8  - 846

Push-Button toggle off:
-> 0B 83 A4 40 518FBC 111222 02 29  - 1082
<- 0F 83 80 02 111222 518FBC 01 01 C8 20 78 C8  - 1086
<- 0F 0B A6 10 111222 000000 06 01 00 00 78 00  - 1097

In allen Fällen erfolgt eine Broadcast Meldung mit dem richtigen Status, dem Pushbutton wird explizit allerdings ein falscher Status nur an seine Adresse gemeldet.
Könnte es sein, das FHEM da schon mitliest und die Broadcast-Meldung z.B. aus Timing-Gründen verschluckt?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 09 Juli 2017, 19:51:52
@capt_bluebaer: Könntest du deine Implementierung des HM-WDS-SEC mit uns Teilen?
Hätte großes Interesse daran, das nachzubauen.

@papa:
Hier die Ausgabe der neuen Version.
Habe einmal auf und wieder zugeschlossen:
AskSin++ V1.0.6 (Jul  9 2017 19:45:00)
Address Space: 32 - 268
CC init12...................3 - ready
Invert active
HM-LC-SW4-SM
<- 0E 01 A6 10 123456 000000 06 01 00 00 00  - 266
<- 0E 02 A6 10 123456 000000 06 02 00 00 00  - 276
<- 0E 03 A6 10 123456 000000 06 03 00 00 00  - 373
<- 0E 04 A6 10 123456 000000 06 04 00 00 00  - 474
-> 0E 1F A0 11 473071 123456 02 01 C8 00 00  - 619
<- 0E 1F 80 02 123456 473071 01 01 C8 00 53  - 871
-> 0E 1F A0 11 473071 123456 02 01 C8 00 00  - 882
<- 0E 1F 80 02 123456 473071 01 01 C8 00 52  - 886
-> 0E 28 A0 11 473071 123456 02 01 00 00 00  - 918
<- 0E 28 80 02 123456 473071 01 01 00 00 56  - 1169
-> 0E 28 A0 11 473071 123456 02 01 00 00 00  - 1181
<- 0E 28 80 02 123456 473071 01 01 00 00 55  - 1185


Hier meine Umsetzung der Katzenklappe, jetzt sogar mit einer Statusanzeige.
Hätte auch nen Motorsteuer IC nehmen können, aber die Relais hatte ich gerade da.
Damit sie den Mikrocontroller nicht überlasten hängen sie an jeweils zwei Ausgängen die gleichzeitig geschaltet werden.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 09 Juli 2017, 20:22:04
Damit sie den Mikrocontroller nicht überlasten hängen sie an jeweils zwei Ausgängen die gleichzeitig geschaltet werden.

Ähh du hast Relais direkt an den µC gehangen ohne Transistoren zwischen? Du weißt schon das mehr als 10(20) mA nicht gehen, auch wenn du da versuchst zwei Ausgänge Parallel zu schalten und die dann auch noch zu verbinden...

Oder habe ich da jetzt etwas falsch verstanden?!?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 09 Juli 2017, 20:27:42
Also im Datenblatt steht:
DC Current per I/O Pin 40 mA
Auf nem anderen Datenblatt wo das Pinout ganz schön dargestellt ist, steht 40mA max und empfohlen 20mA.
Das Relais braucht nur knapp unter 40mA.
Ich habe die verbundenen Pins am gleichen Port und schalte diese direkt durch schreiben in die Register.
Das Relais ist auch nur für 250ms eingeschaltet.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 09 Juli 2017, 20:48:33
Mhh naja, haste die Freilaufdiode wenigstens drin? Ansonsten fällt mir dazu nichts mehr ein ;-)

/Daniel

Titel: Antw:AskSin++ Library
Beitrag von: Xent am 09 Juli 2017, 21:20:14
Noch nicht.
Wollte ich aber wahrscheinlich noch machen.

Bräuchte ich für die Relais auch noch welche?
Der Motor ist nicht freidrehen, also er dreht sich in den 250ms nur bis zu einem Anschlag.
Also kann keine Induktion durchs nachdrehen entstehen.
Braucht der auch welche, wenn der dann direkt steht?

Einige Arduino Shields für Schrittmotoren haben doch auch nur nen ULN2003 drin.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Juli 2017, 22:04:30
In allen Fällen erfolgt eine Broadcast Meldung mit dem richtigen Status, dem Pushbutton wird explizit allerdings ein falscher Status nur an seine Adresse gemeldet.
Könnte es sein, das FHEM da schon mitliest und die Broadcast-Meldung z.B. aus Timing-Gründen verschluckt?

Hm - Toggle vom Peer habe ich gar nicht probiert - nur On/Off bzw DimUp/Down. Muss ich mal machen. Wird aber frühestens in 2 Wochen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Juli 2017, 22:09:18
Hier meine Umsetzung der Katzenklappe, jetzt sogar mit einer Statusanzeige.

Hast Du da gar keine Antenne dran ?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 09 Juli 2017, 22:12:58
Doch, nur ist die beim Prototypen ohne Gehäuse abgebrochen, da die Platine leider nur halbe Löcher hatte.
Jetzt ist wieder eine dran direkt an den Kondensator gelötet.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Juli 2017, 22:16:05
Kannst Du auch mal die Ausgaben vom FHEM für das Gerät aufzeichnen.
Titel: Antw:AskSin++ Library
Beitrag von: capt_bluebaer am 10 Juli 2017, 00:26:45
Hm - Toggle vom Peer habe ich gar nicht probiert - nur On/Off bzw DimUp/Down. Muss ich mal machen. Wird aber frühestens in 2 Wochen.
@papa: Macht nichts, für eine Lösung warte ich gerne.
In den Readings des FHEM Webinterface wird tatsächlich die Meldung an das Peer Device als Status angezeigt. Man könnte diese doch einfach weglassen, macht doch auch irgendwie keinen Sinn. Was interessiert dem Button der Zustand des Dimmers?

@Xent: Ich muss den HM-SC-WDS noch an die aktuelle Revision anpassen, kann aber noch ein paar Tage dauern.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 10 Juli 2017, 19:19:22
@papa: Die aktuelle Version scheint etwas stabiler zu sein.
Es kommt schon noch vor, dass der Arduino nicht reagiert, allerdings gehts dann nach ner Zeit wieder.
Vorher war der komplett weg.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Juli 2017, 22:23:30
Ich glaube, dass sich der CC1101 Code beim Empfang eines defekten Paketes verschluckt. Aber ich habe keine Ahnung warum oder wie ich das besser machen kann.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 11 Juli 2017, 05:30:14
Hat NewAskin von Trilu das gleiche Problem?
Vielleicht könnte man sich da was abschauen, wenn es da nicht auftritt.

Wenn ich heute Abend Zeit habe, schaue ich mal ob der Sketch von Trilu für das HM_LC_SW1_BA_PCB sich compilen lässt.
Dann würde ich das mal testen.
Bis dahin mache ich nochmal die V1 von dir drauf.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Juli 2017, 12:58:13
Keine Ahnung. Wichtig wäre es herauszufinden, was dazu führt, dass nichts mehr empfangen wird. Dann kann man auch Schlüsse daraus ziehen und den Code fixen. Deshalb frage ich ja immer wie wild nach Ausgaben. Hatte letztens auch noch welche im Receive-Code eingefügt.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 11 Juli 2017, 19:30:48
Hab den Arduino gerade wieder am PC dran.
Konnte es jetzt noch nicht wieder reproduzieren.
Allerdings werden die Messages immer noch doppelt gesendet:
AskSin++ V1.0.6 (Jul 11 2017 17:16:31)
Address Space: 32 - 268
CC init12...................3 - ready
Invert active
HM-LC-SW4-SM
<- 0E 01 A6 10 123456 000000 06 01 00 00 00  - 266
<- 0E 02 A6 10 123456 000000 06 02 00 00 00  - 276
<- 0E 03 A6 10 123456 000000 06 03 00 00 00  - 373
<- 0E 04 A6 10 123456 000000 06 04 00 00 00  - 474
-> 0E 19 A0 11 473071 123456 02 01 C8 00 00  - 625
<- 0E 19 80 02 123456 473071 01 01 C8 00 5C  - 877
-> 0E 19 A0 11 473071 123456 02 01 C8 00 00  - 889
<- 0E 19 80 02 123456 473071 01 01 C8 00 5C  - 893
-> 0E 22 A0 11 473071 123456 02 01 00 00 00  - 917
<- 0E 22 80 02 123456 473071 01 01 00 00 58  - 1169
-> 0E 22 A0 11 473071 123456 02 01 00 00 00  - 1181
<- 0E 22 80 02 123456 473071 01 01 00 00 59  - 1185
-> 0E 2B A0 11 473071 123456 02 01 C8 00 00  - 1247
<- 0E 2B 80 02 123456 473071 01 01 C8 00 5F  - 1499
-> 0E 2B A0 11 473071 123456 02 01 C8 00 00  - 1510
<- 0E 2B 80 02 123456 473071 01 01 C8 00 60  - 1515
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 12 Juli 2017, 06:08:38
Soo, hab das ganze mal über Nacht laufen lassen.
Heute morgen ging wieder nichts.

AskSin++ V1.0.6 (Jul 11 2017 17:16:31)
Address Space: 32 - 268
CC init12...................3 - ready
Invert active
HM-LC-SW4-SM
<- 0E 01 A6 10 123456 000000 06 01 00 00 00  - 266
<- 0E 02 A6 10 123456 000000 06 02 00 00 00  - 276
<- 0E 03 A6 10 123456 000000 06 03 00 00 00  - 373
<- 0E 04 A6 10 123456 000000 06 04 00 00 00  - 474
 debounce
 released

<- 0E 05 A6 10 123456 000000 06 01 C8 00 5E  - 23938

Das komische ist, dass aus irgendeinem Grund die Taste gedrückt wurde.
Habe da aber nichts dran nur zwei Drähte die sich nicht selbständig berühren können.
Fehlt mir da noch nen Pullup oderso?
Dachte der Interne währe aktiv auf Pin 8.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 12 Juli 2017, 19:26:33
Wieder reagierte der Arduino nicht auf Befehle.
Diesmal war nur die Startausgabe vorhanden.

Nachdem ich Kanal 1 über den Config-Button geschaltet habe wurden auch wieder Nachrichten empfangen.
Sieht irgendwie so aus alsob der CC1101 irgendwann einfach nichts mehr empfängt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Juli 2017, 21:51:51
Wieder reagierte der Arduino nicht auf Befehle.
Diesmal war nur die Startausgabe vorhanden.

Nachdem ich Kanal 1 über den Config-Button geschaltet habe wurden auch wieder Nachrichten empfangen.
Sieht irgendwie so aus alsob der CC1101 irgendwann einfach nichts mehr empfängt.
Das vermute ich auch. Kann es leider nur nicht provozieren. Scheint auch mit den timing von CUL zusammen zu hängen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 13 Juli 2017, 05:40:42
Vielleicht könnte man zum debuggen mal regelmäßig den status des CC1101 abfragen lassen oderso.
Nicht dass der aus irgendeinem Grund aus dem Empfangsmodus raus springt.
Als Workaround für mein akutes Problem hatte ich schon daran gedacht, dass der Arduino seinen Status von selbst periodisch sendet.
Das entspricht dann zwar nicht mehr dem normalem Verhalten, würde aber wahrscheinlich mein Problem lösen.

Bei der NewAsksin Lib scheint das Beispiel aktuell nur mit dem master zu funktionieren.
Habs noch nicht hinbekommen es für den DevAES Branch anzupassen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 13 Juli 2017, 10:52:42
Soo, jetzt haben die Relais und der Motor auch Freilaufdioden.
Zusätzlich hat der Configbutton noch nen 10K Pullup Widerstand.
Titel: Antw:AskSin++ Library
Beitrag von: frank am 13 Juli 2017, 10:53:16
Scheint auch mit den timing von CUL zusammen zu hängen.
schon mal die ts_culfw probiert?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 13 Juli 2017, 11:19:19
Ich nutze ja keinen CUL sondern die originale CCU2.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Juli 2017, 13:44:30
Ich nutze ja keinen CUL sondern die originale CCU2.
Kann die irgendwie Logs schreiben ? Vielleicht sieht man ja da was.
Titel: Antw:AskSin++ Library
Beitrag von: capt_bluebaer am 13 Juli 2017, 18:24:58
Zusätzlich hat der Configbutton noch nen 10K Pullup Widerstand.
Genau das Problem hatte ich bei meinem PWM-Dimmer auch und durch diese Maßnahme beseitigt.
Muß dazu sagen, dass ich zusäztlich an D5 ein Relais (mit Feilaufdiode) über einen Transistor ansteuere, das die 230V für das Vorschaltgerät bei einem Dim-Level > 0 zuschaltet.
Sporadisch verhielt es sich nach Einschalten so als wenn die Config-Taste gedrückt wurde, manchmal kam es zu einem Reset. Ohne Relais auf dem Breadboard hatte ich diesen Effekt nie. Der 10k Resi war meine Rettung.

@papa, mein Toggle-vom-peer-Problem hat sich erstmal erledigt, Habe den Dimmer jetzt mit einem HM  Funk-Wandsender gepeert, damit wird der Status bei short-toggle als auch bei long-toggle richtig gemeldet.
Vorher hatte ich es mit dem 8 Bit Funksendemodul von ELV versucht, welches wiederum mit einem HM Dimmer richtig kooperiert. Keine Ahnung, was da nun wieder der Unterschied ist.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 13 Juli 2017, 19:31:52
Ich glaube schon, müsste ich mal nachschauen.
Denke das könnte höchstens bei den doppelten Messages helfen.
Aber bei dem Problem, das nichts mehr empfangen wird, wird das wohl wenig helfen, da das Empfangsproblem ja auch auftritt ohne dass ich was gesendet habe.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 13 Juli 2017, 20:52:47
Ich versuche gerade ein periodisches Senden des Status einzubauen.
Allerdings wird in meiner Klasse scheinbar der Trigger nicht ausgelöst ...

template <class HalType,int PeerCount>
class SwitchChannel1 : public SwitchChannel<HalType,PeerCount> , public Alarm {

protected:
  typedef SwitchChannel<HalType,PeerCount> BaseChannel;

public:
  SwitchChannel1 () : BaseChannel(), Alarm(seconds2ticks(10)) {}

  virtual void trigger (AlarmClock& clock) {
    DPRINTLN("trigger");
    tick = seconds2ticks(10);
    clock.add(*this);
    //status(status(), DELAY_INFINITE);
  }

  void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate) {
....

Eigentlich müsste doch jetzt alle 10 Sek "trigger" auf der Konsole erscheinen oder nicht?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Juli 2017, 22:02:21
Da fehlt der initiale Start. Bitte nicht im Constructor machen, da die Reihenfolge der Constructoren in C++ nicht defineirt ist. Somit könnte es passieren, dass man einen Alarm anmelden will, bevor die sysclock fertig aufgebaut wurde. Also am besten im setup() machen.

 
void setup(Device<HalType>* dev,uint8_t number,uint16_t addr) {
  BaseChannel::setup(dev,number,addr);
  sysclock.add(*this);
}

Zum Status senden bitte einfach

changed(true);

aufrufen. Das sollte dann eine StatuInfoMessage auslösen. Also so


virtual void trigger (AlarmClock& clock) {
    DPRINTLN("trigger");
    set(seconds2ticks(10));
    clock.add(*this);
    changed(true);
  }
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 Juli 2017, 08:38:36
Danke, das funktioniert jetzt.
Ich lass jetzt alle 60 Sek die Statusmeldung senden, vielleicht hängt sich dadurch der CC1101 nicht mehr auf.
Da keine Rückmeldung von der CCU kommt sollte das den DutyCycle der Zentrale ja nicht beeinflussen.
In deiner Lib ist ja auch kein DutyCycle eingebaut oder?

Das einzig merkwürdige ist, dass die Ausgabe "trigger" 4 mal kommt aber nur einmal ein Status aller Kanäle gesendet wird:

trigger
trigger
trigger
trigger
<- 0E 15 A6 10 123456 000000 06 01 00 00 4B  - 1944
<- 0E 16 A6 10 123456 000000 06 02 00 00 4B  - 1958
<- 0E 17 A6 10 123456 000000 06 03 00 00 4B  - 2053
<- 0E 18 A6 10 123456 000000 06 04 00 00 4B  - 2152
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Juli 2017, 08:17:18
Das passt schon. Jeder Kanal hat einen Alarm. Der wird ausgelöst und landet in der Run-Queue. Dort wird das "trigger" ausfgerufen. Das macht nicht weiter, als die Ausgabe und das Changed-Flag im Channel zu setzen. Die ChannelDevice-Klasse prüft im "pollRadio" jeden Channel auf "changed" und sendet egebenenfalls den Status.
Man könnte einfach auch einen Alarm machen, der dann alle Channels auf "changed" setzt. Würde etwas Speicher sparen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 Juli 2017, 08:58:19
Heute morgen ging schon wieder nichts ...

Könnte der Fehler vielleicht irgendwo beim pollRadio liegen, dass das nicht mehr richtig aufgerufen wird?
Hatte jetzt leider keinen PC zum Loggen dran und ich hab nicht ausprobiert, ob ein manuelles Auslösen über den Configtaster den Empfang wiederherstellt.
Sendet der ConfigTaster die Änderungen auch über das pollRadio oder triggert das direkt das Senden, Schalten usw.?

Es muss doch möglich sein einen stabilen Empfang herzustellen.
Es gibt ja immer hin die alternative Firmware für den Unterputzschalter und die haben ja auch nur CC1101 drin ...
Mal schauen ob ich in den master-Branch des NewAsksin mal meine Änderungen bezüglich des Schaltverhaltens einbauen kann ...
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 Juli 2017, 11:05:54
Hmm mit der NewAskSin Lib bekomme ichs irgendwie nicht hin.
Mit dem master hab ichs zumindest einbauen können, allerdings will der beim Pairing den Sicherheitsschlüssel ...
Keine Ahnung ob das daran liegt, dass noch irgendwas falsches im EEPROM steht oderso ...

Dann hab ich mich durch die Fehler des DevAES Branch gehangelt und das Example zum compilen gebracht.
Hier bekomme ich allerdings nur "ini" ausgegeben, obwohl eigentlich mehr kommen sollte.
Keine Ahnung woran das liegt, vielleicht werden zwei Ports die ich für die Relais nehme unterschiedlich geschaltet und es kommt daher zu nem kurzen oderso ...

Hab jetzt wieder deine  Lib drauf und werde bei nicht funktionieren schauen, ob man das Teil durch den Config Button wiederbeleben kann.

Mir ist gerade noch aufgefallen, dass beim Pairing scheinbar nicht der richtige Typ übergeben wird.
Bei mir in der CCU wird es als "HM-LC-SwX papa000000" erkannt.
Ich meine das war bei den ersten Versuchen nicht so.
Hab vor dem Pairing auch nen Reset gemacht.

Wenn das alles nichts bringt und der Empfang immer hängen bleibt, dann muss ich wohl ein 8-Fach Empfangsmodul nehmen und das dann an den Arduino hängen...
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 Juli 2017, 13:25:37
Mir ist noch was aufgefallen:

AskSin++ V1.0.6 (Jul 16 2017 13:22:14)
Address Space: 32 - 268
CC init12...................3 - ready
Invert active
HM-LC-SW4-SM
<- 0E 01 A2 10 123456 473071 06 01 00 00 00  - 266
-> 0A 01 80 02 473071 123456 00  - 417
waitAck: 01
<- 0E 02 A2 10 123456 473071 06 02 00 00 57  - 421
-> 0A 02 80 02 473071 123456 00  - 574
waitAck: 01
<- 0E 03 A2 10 123456 473071 06 03 00 00 56  - 578
-> 0A 03 80 02 473071 123456 00  - 731
waitAck: 01
<- 0E 04 A2 10 123456 473071 06 04 00 00 57  - 735
-> 0A 04 80 02 473071 123456 00  - 887

Vorher wurden die Statusnachrichten nicht quittiert.
Nun werden entsprechende Acks gesendet ...
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Juli 2017, 20:57:56
Da war es auch nicht gepairt.
Ich habe derzeit wenig Zeit, mich tiefer mit der Sache zu beschäftigen. Du musst also warten, oder es selber rausfinden. Ich gehe davon aus, dass die Ursache irgendwann erkannt und beseitigt wird.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 Juli 2017, 21:22:08
Vielen Dank für deine bisherige Hilfe ;-)

Also eigentlich war der die ganze Zeit über gepairt.
Möglicherweise nicht ganz richtig.

Ich schau jetzt mal, wie es morgen früh aussieht.
Wenn es dann immer noch funktioniert, werde ich wohl umrüsten müssen.

Ist das mit dem HM-LC-SwX denn richtig?
Sollte die CCU nicht direkt erkennen obs nen HM-LC-SW2 oder HM-LC-SW4 usw ist?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Juli 2017, 21:30:00
Nein - er sollte das ordentlich erkennen. Das Example ist als HM_LC_SW4_SM eingecheckt - DEVICE_MODEL. Wenn Du den OTA-Bootloader verwendest, kommt es drauf an, was im Bootloader abgelegt ist.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 Juli 2017, 21:37:36
Der define für den OTA-Bootloader ist auskommentiert.

// define all device properties
#define DEVICE_ID HMID(0x12,0x34,0x56)
#define DEVICE_SERIAL "papa000000"
#define DEVICE_MODEL  HM_LC_SW4_SM
#define DEVICE_FIRMWARE 0x16
#define DEVICE_TYPE DeviceType::Switch
#define DEVICE_INFO 0x04,0x01,0x00
#define DEVICE_CONFIG CFG_LOWACTIVE_OFF

Ich meine auch, dass das beim vorherigen pairen korrekt erkannt wurde.
Naja funktioniert auch so ...
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Juli 2017, 13:35:38
Mach doch mal im Radio.h in  "void handleInt ()" die Debugausgabe rein. Dann wissen wir wenigstens, ob noch Interrupts vom CC1101 kommen, wenn nicht mehr empfangen wird. Wenn keine Interrupts mehr kommen, liegt es höchst wahrscheinlich am Receive-Code des CC1101 wenn noch Interrupts kommen eher bei pollRadio().
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 17 Juli 2017, 21:36:23
Werde ich machen aber aktuell lief es jetzt ganz gut mit den automatischen Rückmeldungen.
Habe jetzt den Typ in den 2 Kanal geändert und neu gepairt.
Außerdem hab ich das Intervall deaktiviert.

Mal schauen was das Teil morgen früh sagt.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 18 Juli 2017, 21:39:38
Also ich hab jetzt noch nen kleinen Test eingebaut, ob der Arduino noch auf serielle Eingaben reagiert.
Wenn er nicht mehr auf Befehle reagiert, reagiert er trotzdem noch wenn ich was seriell schicke.
Also läuft er noch in den Loop und hat sich nicht komplett aufgehängt.
Es kommt keine Ausgabe mehr von handleInt().

EDIT: jetzt kurz nach meinem Test kamen doch wieder Ausgaben von handleInt und er reagiert wieder.
Habe den Arduino aber nicht resettet oder ähnliches ...
Sehr merkwürdig ...
Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 19 Juli 2017, 07:24:24
Hallo,

hat hier vielleicht noch jemand Probleme mit seinem CUL (a-culfw) bzw. dem CC1101 Funkchip?

Ich habe 2 HM-WDS10-TH-O mit der AskSin++ gebaut und ungefähr seit dem immer wieder mal das Problem, dass der CUL nicht mehr reagiert.
Könnte aber auch Zufall sein...  :-\

Hier habe ich meine Infos zusammen gefasst:
https://forum.fhem.de/index.php/topic,35064.msg661232.html#msg661232

Micky
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 19 Juli 2017, 08:35:40
Könnte sein, aber bei mir ists ja der Arduino + CC1101 bei dem die Probleme auftreten.
Seriell kann ich den Arduino noch ansprechen, nur per Funk geht nichts mehr und dann af einmal doch wieder ...
Ich setzte ja keoin FHEM ein sondern die normale CCU2.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 Juli 2017, 21:03:00
Also läuft er noch in den Loop und hat sich nicht komplett aufgehängt.
Es kommt keine Ausgabe mehr von handleInt().

Also scheint sich das Funkmodul nicht mehr im Empfangsmodus zu befinden.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 19 Juli 2017, 23:26:17
Scheint so
Das komisch war aber, dass er nach meiner seriellen Eingabe wieder reagiert hat ...

Habe jetzt aktuell drin, dass einmal pro Minute der Status des 1. Kanals gesendet wird.
Dadurch scheint er nun stabil zu laufen, zumindest hat die Katzenklappe jetzt bei jedem Tastendruck reagiert.
Werde das auch so lassen und vielleicht noch etwas am Intervall ändern.
Aktuell liegt der Duty Cycle ca bei 5 wenn sonst nichts passiert ...

Wenn ich noch verschiedene Sachen testen soll, sag bescheid.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 23 Juli 2017, 23:28:58
Wenn die Interrupts nicht mehr kommen - passiert das direkt nach einer Sende-Operation oder einfach irgendwann beim Empfang?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juli 2017, 06:07:41
Einfach irgendwann.
Ich kann beliebig oft schalten und wenn ich dann länger nichts gemacht habe gehts irgendwann nicht mehr.
Mit dem automatischen Senden hatte ich bisher keine Probleme mehr.
Entweder es tritt dadurch nicht mehr auf oder korrigiert Sicht automatisch nach 2 Minuten (aktueller Intervall)
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 31 Juli 2017, 18:49:48
Ich nochmal ...

Ich versuche gerade den 2. Kanal über Homematic zu konfigurieren.
Allerdings bekomme ich die Meldung:
    Der Kanal kann zur Zeit nicht konfiguriert werden. Informationen dazu finden Sie in den Servicemeldungen.
Im den Servicemeldungen steht nur, dass es eine Kommunikationsstörung gegeben hat.
Kanal 1 lässt sich konfigurieren.

EDIT:
Nach nen paar Versuchen lässt sich auch Kanal 2 konfigurieren.
Hier ist die Ausgabe von der Konsole von diesem Versuch:
-> 0B 16 A0 01 473071 FE3456 01 0E  - 4259
<- 0E 16 82 10 FE3456 473071 06 01 00 00 57  - 4262
*
*
-> 10 1F A0 01 473071 FE3456 01 04 FE 34 56 01 03  - 4509
*
-> 10 1F A0 01 473071 FE3456 01 04 FE 34 56 01 03  - 4791
*
-> 10 1F A0 01 473071 FE3456 01 04 FE 34 56 01 03  - 5071
*
-> 10 1F A0 01 473071 FE3456 01 04 FE 34 56 01 03  - 5353
*
-> 10 20 A0 01 473071 FE3456 01 04 FE 34 56 01 03  - 5666
*
-> 10 20 A0 01 473071 FE3456 01 04 FE 34 56 01 03  - 5947
*
-> 10 20 A0 01 473071 FE3456 01 04 FE 34 56 01 03  - 6228
*
-> 10 20 A0 01 473071 FE3456 01 04 FE 34 56 01 03  - 6509
<- 0E 03 A2 10 FE3456 473071 06 01 00 00 57  - 6906
*
*
-> 0A 03 80 02 473071 FE3456 00  - 7058
waitAck: 01
*
-> 0B 0C A0 01 473071 FE3456 02 0E  - 7559
<- 0E 0C 82 10 FE3456 473071 06 02 00 00 56  - 7562
*
*
-> 10 15 A0 01 473071 FE3456 02 04 FE 34 56 02 03  - 7728
*
-> 10 15 A0 01 473071 FE3456 02 04 FE 34 56 02 03  - 8008
*
-> 10 15 A0 01 473071 FE3456 02 04 FE 34 56 02 03  - 8290
*
-> 10 15 A0 01 473071 FE3456 02 04 FE 34 56 02 03  - 8570
*
-> 10 16 A0 01 473071 FE3456 02 04 FE 34 56 02 03  - 8931
*
-> 10 16 A0 01 473071 FE3456 02 04 FE 34 56 02 03  - 9212
*
-> 10 16 A0 01 473071 FE3456 02 04 FE 34 56 02 03  - 9493
*
-> 10 16 A0 01 473071 FE3456 02 04 FE 34 56 02 03  - 9775

EDIT2:
Hab die Ursache gefunden. Die Kanäle sind intern nicht mit sich selbst also dem Aktor gepeered.
Sollte das von Haus aus passieren oder muss man das noch manuell machen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 31 Juli 2017, 22:34:58
Hab die Ursache gefunden. Die Kanäle sind intern nicht mit sich selbst also dem Aktor gepeered.
Sollte das von Haus aus passieren oder muss man das noch manuell machen?

Ups -  der HM-LC-SW4-SM hat ja für jeden Kanal nen Knopf. Der interne Peer wird derzeit nicht angelegt. Das hat FHEM auch nicht weiter gestört. Kommt auf die Liste zum Einbauen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 01 August 2017, 08:26:07
Ok ;-)
Wegen dem Empfangsproblem lasse ich jetzt mal alle Pakete die so ankommen ausgeben.
Habe dazu im rcvData die Ausgabe des Buffers wieder aktiviert.

Mal schauen ob man sehen kann nach welchem Paket er stehen bleibt und ob man das rekonstruieren kann.
Habe jetzt mehr Zeit dazu, da ich jetzt für nen Monat in Elternzeit bin.
Wenn du sonst noch Stellen weißt, wo etwas Debugausgabe sinnvoll lass es mich wissen ;-)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 August 2017, 08:44:45
Zum Anlegen der internen Peers bitte setup() am Ende erweitern um:

  HMID devid;
  sdev.getDeviceID(devid);
  for( uint8_t i=1; i<=sdev.channels() ) {
    Peer ipeer(devid,i);
    // create internal peer if not already done
    if( sdev.channel(i).peer(0) != ipeer ) {
      sdev.channel(i).peer(ipeer);
    }
  }

Damit sollte für jeden Channel ein Peer mit DeviceID + ChannelNumber angelegt werden. Das wird allerdings noch nirgendwo benutzt. Müsste dann mal noch den ConfigToggleButton ändern, dass er die entsprechende PeerListe dann auch nutzt.

Der Code ist übrigens nicht getestet - nur so runtergetippt.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 01 August 2017, 11:42:32
Hier mal die letzten Ausgaben vor dem Hängenbleiben.

Das * kommt vom handleInt
Die Ausgabe "RAW -> ...." kommt vom Ende von rcvData

RAW -> 25 A7 C3 D7 96 CC EF FB A6 83 50 00 00 39 00 DD 43 00 D4 44 FF 2C 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 25 81 5F 7C 68 35 59 10 52 80 F6 00 00 39 00 DD 43 00 D4 44 FF 2C 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 2A A6 93 28 34 61 75 4A A1 7F 5A 36 12 00 00 DD 43 00 D4 44 FF 2C 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 2A 86 60 74 4B A0 3B 27 72 4F 2A 5F 1B B5 DA DD 43 00 D4 44 FF 2C 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 13 4F 3A 51 1D 88 2C 13 68 46 23 FF DB 00 5A DD 43 00 D4 *
RAW -> 13 6F 49 6D 52 A9 C2 AE FB D6 B3 A5 A1 3D AE DD 43 00 D4 *
RAW -> 10 48 34 58 2F 8C 2F 3B 66 44 21 FD D9 35 A4 DD *
RAW -> 10 6C 4A 61 0D 98 3C 03 58 80 01 00 00 80 00 DD *
RAW -> 80 DA EC 99 29 AC 88 64 40 7C B2 C5 00 80 00 DD 43 00 D4 44 FF 2C 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 *
RAW -> B3 2F 55 A1 6F 7F 1C C8 D5 BA 0A 37 13 BE C1 DD 43 00 D4 44 FF 2C 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 B5 F5 CD D8 E7 3F *
RAW -> B3 0F E9 82 6E 3B 87 71 79 80 9C D1 00 51 61 DD 43 00 D4 44 FF 2C 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 B5 F5 CD D8 E7 3F *
RAW -> 80 D8 C4 F1 91 C4 A0 7C 58 34 FA C7 00 51 61 DD 43 00 D4 44 FF 2C 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 *
RAW -> AD 0F FB 86 C1 99 75 51 2D 03 BF 71 40 1C 86 DD 43 00 D4 44 FF 2C 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 *
RAW -> E0 3A 45 6A 9A 1B F7 D3 AF 8B 26 03 6E 08 E4 1E B9 95 A2 3A E9 AB 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 B5 F5 CD D8 E7 3F 97 FC 79 FC 5F 7A 7F FF 6F FA 7F 07 91 3A 5E FA 0F 3F 77 99 DF 37 FF 7F F7 FE 9E BF CE DA 6D ED CD 7D 2F 97 B3 FB E3 A6 74 BF 9C 6D F8 *
RAW -> 81 DB ED 98 28 AD 89 65 41 7D B3 C5 B1 42 00 DE 43 00 D3 44 FF 2D 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 *
RAW -> AA 00 CC F9 76 56 32 0E EA CC C8 4E 27 03 86 DE 43 00 D3 44 FF 2D 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 *
RAW -> 81 D9 C5 F0 90 C5 A1 7D 59 35 FB C7 0D 00 00 DE 43 00 D3 44 FF 2D 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 *
RAW -> B0 2C 56 A2 6C 7C 1F CB D6 B9 08 46 22 5C 62 DE 43 00 D3 44 FF 2D 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 B5 F5 CD *
RAW -> B0 0C EA 81 6D 38 84 72 7A 80 9D A2 00 A2 C2 DE 43 00 D3 44 FF 2D 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 B5 F5 CD *
RAW -> E1 3B 44 6B 9B 1A F6 D2 AE 8A 27 02 6F 09 E5 21 BE 9A A7 C7 5C A9 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 B5 F5 CD D8 E7 3F 97 FC 79 FC 5F 7A 7F FF 6F FA 7F 07 91 3A 5E FA 0F 3F 77 99 DF 37 FF 7F F7 FE 9E BF CE DA 6D ED CD 7D 2F 97 B3 FB E3 A6 74 BF 9C 6D F8 BD *
RAW -> 87 C5 B1 C2 0D 01 9A 46 53 29 04 22 A6 42 00 E0 43 00 D1 44 FF 2F 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 *
RAW -> 87 C3 9D 3E 2A 77 1C 6B AF 8F E2 6D 39 5A 02 8C A6 00 D1 44 FF 2F 4F 12 D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 *
RAW -> 87 C3 9C 37 80 B4 D7 83 2E 6B 00 AA A4 0C CE 79 66 87 E9 2E 03 DC 47 18 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 *
RAW -> 87 E3 BD DE 8A 17 BC 0B 0F EB 0D 69 32 B4 26 D3 33 C5 8A EB 09 03 FF 3B A7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 *
RAW -> 8E EC 92 3F 47 8A 66 42 1E 9A 9C C5 77 34 26 D3 33 C5 8A EB 09 03 FF 3B A7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE *
RAW -> AB 01 CD F8 77 57 33 0F EB CD C9 4F 26 02 86 D3 33 C5 8A EB 09 03 FF 3B A7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E *
RAW -> 7A F0 DC F4 F9 55 76 62 4F 2D 08 E4 A6 00 00 D3 33 C5 8A EB 09 03 FF 3B A7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC *
RAW -> 7A F6 D0 EB F7 A2 32 27 83 5B B2 E1 16 67 54 BE A6 C5 8A EB 09 03 FF 3B A7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC *
RAW -> 7A F0 CF E7 EA 46 65 71 3C 29 01 76 03 C4 82 33 BD 98 E1 44 F0 29 EF 63 F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC *
RAW -> 7A D6 B0 CB 97 02 92 47 A3 7F BF 8B E0 E9 22 6D B2 01 95 F9 D0 E5 EA A8 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC *
RAW -> 8E EE BA C7 FF 72 4E 2A 06 E2 54 C7 87 69 22 6D B2 01 95 F9 D0 E5 EA A8 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE *
RAW -> EE 4C 7B 1C 24 6D 49 25 01 DD F8 D5 00 9E 7A B7 D0 AC 58 70 B3 B6 EA A8 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 B5 F5 CD D8 E7 3F 97 FC 79 FC 5F 7A 7F FF 6F FA 7F 07 91 3A 5E FA 0F 3F 77 99 DF 37 FF 7F F7 FE 9E BF CE DA 6D ED CD 7D 2F 97 B3 FB E3 A6 74 BF 9C 6D F8 BD 9F 76 DE FF 1B 2C DB FE 71 11 A8 DD C6 *
RAW -> B1 2D 57 A3 6D 7D 1E CA D7 B8 0A EC C8 F5 C1 E1 43 00 D0 44 FF 30 EA A8 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 B5 F5 CD D8 *
RAW -> B1 0D EB 80 6C 39 85 73 7B 80 9E 0A 00 51 61 E1 43 00 D0 44 FF 30 EA A8 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD 17 DF 5E FA C7 EE FB F1 DB F5 BD FF DE 76 0F 95 BC FC DB D6 F7 FF F7 77 C7 6F CD BF C7 3F F7 CB 8F FD DF DB CE DE AD 5B EB F2 7B AB FA 7A EE 3F F5 ED D0 5F 24 C3 FB FB FB D9 7A 7C F7 7B DF 5E FD D7 7E BF D5 B5 F5 CD D8 *
RAW -> 68 E2 FE E1 04 E1 FA E6 B3 8E 7F 0A 00 51 61 E1 43 00 D0 44 FF 30 EA A8 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 C8 ED 99 F3 DD AF 79 BE EC 7B F3 D2 79 4C D7 1B FF 6D F4 7B 9F CF DF 5F 86 EE F6 6E FD

EDIT:
Dein Code funktioniert, hat nur das "; i++" gefehlt in der Schleife.
Habe noch den peercount angepasst, da ich schon ein peering über die CCU vorgenommen habe und daher die 2 Slots schon belegt waren.
Ich finde man könnte noch etwas mehr Debugoutput bei solchen Funktionen einbauen.
Also zumindest irgendwie Ausgabelevel gesteuert.
Hier könnte man z.B, ausgeben, das keine freien Slots fürs peeren mehr da sind.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 August 2017, 13:13:36
Hier mal die letzten Ausgaben vor dem Hängenbleiben.

Das sieht ja komisch aus. Wird ja immer länger. Kannst Du mal die anderen Ausgaben im rcvData auch rein nehmen und dann noch die HM-Message-Ausgabe im MultiChannelDevice Zeile 426

Tja - Debug-Output kann man nie genug haben.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 01 August 2017, 13:53:11
Spiel jetzt gleich den Sketch mit den Änderungen auf.
Hier nochmal ne Ausgabe vor dem Problem.
Vielleicht erkennt man ja ne Regelmäßigkeit.
RAW -> 6C F8 C5 E6 F2 BF AE 72 07 E1 BF 53 2F 0B E6 F0 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 FC DB D6 F7 FF F7 77 C7 6F CD BF F7 7F F7 CB 8F DD DE 5B CE DE AD 5B EB F2 FB 2B FA 7A EE 3F F5 ED *
RAW -> 6C C8 A6 B7 6B 0E AD B9 E4 C1 9F 7B 57 80 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 FC DB D6 F7 FF F7 77 C7 6F CD BF F7 7F F7 CB 8F DD DE 5B CE DE AD 5B EB F2 FB 2B FA 7A EE 3F F5 ED *
RAW -> 55 91 7C 1F CB D6 87 9B 3E 18 F6 1A F6 D2 AF E0 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 FC DB D6 F7 FF F7 77 C7 6F CD *
RAW -> 55 B1 8F 5E C2 D7 F4 E0 CD A8 86 AA C6 80 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 FC DB D6 F7 FF F7 77 C7 6F CD *
RAW -> 5A 96 63 78 64 31 38 EC 81 5F 39 DD B9 95 70 E0 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 FC DB D6 F7 FF F7 77 C7 6F CD BF F7 7F F7 CB *
RAW -> 5A B6 90 59 CD E0 FB E7 B2 8F 69 8D 29 80 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 FC DB D6 F7 FF F7 77 C7 6F CD BF F7 7F F7 CB *
RAW -> 43 BF 8A 21 CD D8 81 A5 C8 A6 80 94 70 4C 29 E0 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 *
RAW -> 4D AF D1 FC 84 C9 A5 81 5D 91 81 C3 00 00 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 FC DB *
RAW -> 43 9F 79 60 C4 E9 82 6E 3B 16 F0 04 A0 80 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 *
RAW -> 48 84 71 0A D6 C3 AA 7E 13 ED CB 6F 4B 27 02 E0 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 *
RAW -> 48 A4 82 6B BF D2 E9 F5 A0 7D 5B FF 9B 80 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 *
RAW -> 31 AD 98 33 3F 6A 73 B7 DA B4 92 A6 82 5E 3B E0 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 31 8D 6B 72 B6 DB F0 FC A9 84 62 F6 92 80 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 26 A2 6F 0C D8 C5 94 88 2D 0B E5 09 E5 C1 9C E0 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 26 82 5C 0D 11 A4 C7 93 1E FB D5 79 15 80 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 2F AB 96 35 21 8C 5D C1 D4 B2 8C A0 7C 58 35 E0 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 2F 8B 65 74 A8 CD EE FA A7 82 5C F0 8C 80 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 14 50 3D 5E 0A 97 46 DA FF D9 B7 5B 37 13 EE E0 02 8F D2 8C *
RAW -> 14 70 4E 1F 03 96 35 21 8C 69 47 EB 87 80 01 40 02 8F D2 8C *
RAW -> 1D 59 24 47 13 9E 4F D3 E6 C0 9E B2 8E 6A 47 E0 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 *
RAW -> 1D 79 57 06 1A BF DC 88 15 F0 CE 62 7E 80 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 *
RAW -> 1A 52 3E 2F F3 86 25 31 7C 5E 38 14 A4 00 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 *
RAW -> 1A 76 50 6B 77 22 CB 5F 72 80 02 00 00 00 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 *
RAW -> 4D AD F9 84 3C B1 8D 69 45 21 11 C1 00 00 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 FC DB *
RAW -> 28 84 62 79 65 30 74 C0 8E 80 EC 45 00 00 01 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *
RAW -> 57 B5 81 0C 4B 23 FF DB B7 99 DD 55 3C 18 86 40 02 8F D2 8C 1D D6 9A D0 AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 FC DB D6 F7 FF F7 77 C7 6F CD BF F7
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 August 2017, 14:02:40
Hm - die Nachrichten dürften eigentlich nie länger als 25 Bytes sein

Sehr komisch

Ändere bitte mal die Debugausgabe in

DHEX(buf,rxBytes);

buf[0] ist schlicht falsch.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 01 August 2017, 18:33:15
Hier nochmal mit dem erweiterten.
Den Fix vom buf[0] bau ich jetzt ein.

RX FIFO: 0F
Start Packet: 0C
CRC OK
RAW -> F9 53 75 00 80 F5 D1 AD 89 CD 45 C2 00 51 61 9A D2 0C 1A 22 C8 38 E3 40 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 ED D0 5F 24 83 FB FB FB F9 7A 5E F7 7B CF DE FD D7 7E BF D5 BD F5 CD D0 E7 3F B7 FC 78 FC 5F 7A 7F FF 6F FA 7F 07 B1 3A 5E FA 0F 3F 75 99 DF 37 DF 7F FF FE DE BF C6 DA 6D FD CD 7C 2F 97 B3 FB E3 A6 74 BF 9E 7D F8 BD 9F 76 DE FF 1B 2C DB FE 71 11 A8 DD C6 BF 1A DD EF 6D B0 78 FF 7F CE CD BF B5 FB BB 3E 5F BE 3E 3B F7 EE 4C BF 3E CF DF F9 AE BB 49 FF 4D FE 77 DD B7 FF DD BF 5C EC FF AF 77 30 7F AE FE EF DF 72 7F 26 CA C7 4C 6F 77 AF FF FB FB BD FD 2B DF FA AB FB DF FF 47 DF 3B D5 EE AB 22 DD FE 2E 6B BA 58 FF ED 3B F2
ignore 0C 8F 86 5A 515CA9 000000 A8 EC 44  - 74956
*
RX FIFO: 0F
Start Packet: 0C
CRC OK
RAW -> F9 51 5D 68 18 5D 39 15 F1 CD 45 C0 00 51 61 9A D2 0C 1A 22 C8 38 E3 40 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 ED D0 5F 24 83 FB FB FB F9 7A 5E F7 7B CF DE FD D7 7E BF D5 BD F5 CD D0 E7 3F B7 FC 78 FC 5F 7A 7F FF 6F FA 7F 07 B1 3A 5E FA 0F 3F 75 99 DF 37 DF 7F FF FE DE BF C6 DA 6D FD CD 7C 2F 97 B3 FB E3 A6 74 BF 9E 7D F8 BD 9F 76 DE FF 1B 2C DB FE 71 11 A8 DD C6 BF 1A DD EF 6D B0 78 FF 7F CE CD BF B5 FB BB 3E 5F BE 3E 3B F7 EE 4C BF 3E CF DF F9 AE BB 49 FF 4D FE 77 DD B7 FF DD BF 5C EC FF AF 77 30 7F AE FE EF DF 72 7F 26 CA C7 4C 6F 77 AF FF FB FB BD FD 2B DF FA AB FB DF FF 47 DF 3B D5 EE AB 22 DD FE 2E 6B BA 58 FF ED 3B F2
ignore 0C 8F 84 70 515CA9 000000 00 EC 44  - 75149
*
RX FIFO: 12
Start Packet: 0F
CRC OK
RAW -> 03 59 25
ignore 0F 75 86 10 51A304 000000 0A A8 EC 0D 00 00  - 75266
*
RX FIFO: 19
Start Packet: 16
CRC OK
RAW -> 59 B3 DC F3 13 82 5E 3A 16 F2 8F 6A F0 8E 6A A6 C1 9D AF CF 54 AC E3 40 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B0 01 00 00 01 00 00 00 00 00 00 00 00 00 ED D0 5F 24 83 FB FB FB F9 7A 5E F7 7B CF
ignore 16 2F 86 53 4BDC6D 000000 00 41 01 B6 42 00 E0 43 00 D6 44 FF 2A  - 75385

EDIT:
Hier ne Ausgabe mit Fix:
RX FIFO: 11
Start Packet: 0E
CRC OK
RAW -> 23 7F 59 72 7E 2B 48 B7 7B 57 01 FE CC FE
ignore 0E 55 80 02 473071 4F93E8 00 32 23 16 7E  - 21266
*
RX FIFO: 0F
Start Packet: 0C
CRC OK
RAW -> BA 10 B6 C3 C3 36 12 EE CA C6 4E C4
ignore 0C CC 86 5A 515CA9 000000 60 EC 42  - 21331
*
RX FIFO: 12
Start Packet: 0F
CRC OK
RAW -> C2 18 E4 91 CE AE 8A 66 42 14 90 80 51 2D 86
ignore 0F B4 86 10 51A304 000000 0A 60 EC 0D 00 00  - 21393
*
RX FIFO: 0F
Start Packet: 0C
CRC OK
RAW -> BA 12 9E 2B 5B 9E 7A 56 32 0E 06 C6
ignore 0C CC 84 70 515CA9 000000 00 EC 42  - 21430
*
RX FIFO: 12
Start Packet: 0F
CRC OK
RAW -> 0C 48 7A C6 B0 B8 D3 9F 0A EA D8 82 5E 6B C1
ignore 0F 7A A0 5E 901234 473071 0C 1E 36 00 51 61  - 21604
*
RX FIFO: 0D
Start Packet: 0A
CRC OK
RAW -> 0C 68 46 65 71 3C 88 76 66 80
ignore 0A 7A 80 02 473071 901234 00  - 21625
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 August 2017, 20:39:09
Das sieht jetzt besser aus. Nun müssen wir mal warten, bis es stehen bleibt.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 01 August 2017, 20:45:03
Das ist eine Ausgabe bis zum Stehenbleiben.
Hab mir extra ne kleine Abfrage in den loop gebaut die auf serielle Eingaben wartet und dann einfach was ausgibt.
So kann ich prüfen, ob die Serielleverbindung noch steht.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 August 2017, 22:33:29
Ups - hm - da ist auch nicht viel zuerkennen.
Ich habe mich mal von der a-culfw inspirieren lassen und ein paar Änderungen gemacht. Kannst Du das bitte mal Testen ?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 02 August 2017, 09:58:55
Moin,
auch mit den Änderungen klappts leider nicht:
*
RX FIFO: 0D
Start Packet: 0A
CRC OK
RAW -> F0 4C 2A 41 2D 78 C4 B2 BA 80
ignore 0A 86 80 02 473071 901234 00  - 2034
RX FIFO: 00
RAW ->
*
RX FIFO: 10
Start Packet: 0D
CRC OK
RAW -> 9F DD A9 CA 35 F9 92 5E 4B 21 FC 78 A6
ignore 0D E9 A6 10 4F93E8 473071 06 01 A0 00  - 2131
RX FIFO: 00
RAW ->
*
RX FIFO: 14
Start Packet: 11
CRC OK
RAW -> 9F DB B5 D6 82 2F 44 B3 67 47 42 3E 86 55 46 7A A6
ignore 11 E9 A0 02 473071 4F93E8 04 61 20 9C 37 77 58 06  - 2164
RX FIFO: 00
RAW ->
*
RX FIFO: 1C
Start Packet: 19
CRC OK
RAW -> 9F DB B4 DF 28 EC 8F 5B 46 D9 7E 0C 4A 96 9F 58 94 14 7D 8E 06 4C 52 59 D0
ignore 19 E9 A0 03 4F93E8 473071 FB CB 56 A2 B0 ED 23 A0 64 8D D7 6C AE 7A 77 70  - 2204
RX FIFO: 00
RAW ->
*
RX FIFO: 11
Start Packet: 0E
CRC OK
RAW -> 9F FB D5 F6 E2 CF E4 53 C7 A3 AC BF 29 71
ignore 0E E9 80 02 473071 4F93E8 00 D3 37 B2 F1  - 2234
RX FIFO: 00
RAW ->
*
RX FIFO: 19
Start Packet: 16
CRC OK
RAW -> DC 3E 49 6E 96 1F FB D7 B3 8F 2A 07 56 70 4C 9D 3A 17 F3 8B 98 86
ignore 16 AA 86 53 4BDC6D 000000 00 41 01 B5 42 00 B5 43 01 00 44 FF 00  - 2375
RX FIFO: 00
RAW ->

EDIT:
Habe jetzt mal eingebaut, dass der Status des CC1101 ausgegeben wird, wenn ich was per Seriell schicke.
Vielleicht bekommt man so infos in welchem Zustand er hängt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 August 2017, 11:17:50
Habe gerade was gefunden (https://e2e.ti.com/support/wireless_connectivity/low_power_rf_tools/f/155/p/187952/677634#677634), dass PacketLength immer auf 61 byte gesetzt werden muss, da es sonst zu einem internen Fehler im CC1101 kommen kann und keine Interrupts mehr kommen.

Habe es gerade eingecheckt. Vielleicht hilft das ja wirklich weiter.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 02 August 2017, 11:25:49
Ok, Test läuft.
Als er gerade wieder hängen geblieben ist, war er noch im RX Modus.

EDIT:
hat leider nichts gebracht:
*
RX FIFO: 0D
Start Packet: 0A
CRC OK
RAW -> 3C 98 76 03 7C 5C 6E E5 7B 80
ignore 0A 4A 80 02 51A304 56AFBA 00  - 9906
RX FIFO: 00
RAW ->
*
RX FIFO: 0F
Start Packet: 0C
CRC OK
RAW -> 3D BF DA E0 13 55 76 62 4F 2A 8C A6
ignore 0C 4B A6 41 56AFBA 473071 01 8A 00  - 9932
RX FIFO: 00
RAW ->
*
RX FIFO: 14
Start Packet: 11
CRC OK
RAW -> 3D B9 97 34 20 8D 3F B4 2A 02 02 C8 A3 C1 31 25 A6
ignore 11 4B A0 02 473071 56AFBA 04 DC 16 07 BE AC 28 06  - 9965
RX FIFO: 00
RAW ->
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 August 2017, 12:46:02
 >:(

Kannst Du rcvData wieder zurückbauen auf:

  uint8_t rcvData(uint8_t *buf, uint8_t size) {
    uint8_t packetBytes = 0;
    uint8_t rxBytes = 0;
    uint8_t fifoBytes = spi.readReg(CC1101_RXBYTES, CC1101_STATUS);             // how many bytes are in the buffer
    // DPRINT("RX FIFO: ");DHEXLN(fifoBytes);
    // overflow detected - flush the FIFO
    if( fifoBytes > 0 && (fifoBytes & 0x80) != 0x80 ) {
      packetBytes = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG); // read packet length
      // DPRINT("Start Packet: ");DHEXLN(packetBytes);
      // check that packet fits into the buffer
      if (packetBytes <= size) {
        spi.readBurst(buf, CC1101_RXFIFO, packetBytes);          // read data packet
        rss = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG);         // read RSSI
        if (rss >= 128) rss = 255 - rss;
        rss /= 2; rss += 72;
        uint8_t val = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG); // read LQI and CRC_OK
        lqi = val & 0x7F;
        if( (val & 0x80) == 0x80 ) { // check crc_ok
          // DPRINTLN("CRC OK");
          rxBytes = packetBytes;
        }
        else {
          DPRINTLN("CRC Failed");
        }
      }
      else {
        DPRINT("Packet too big: ");DDECLN(packetBytes);
      }
    }
  //  DPRINT("-> ");
  //  DHEX(buf,buf[0]);
    flushrx();
    return rxBytes; // return number of byte in buffer
  }

Da steht ja auch, man muss immer den FIFO löschen
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 02 August 2017, 20:19:45
Also erstmal sieht es gut aus.
Zumindest ist er noch nicht wieder hängen geblieben.
Mal schauen, wie es morgen früh aussieht.

Ich musste allerdings noch einige Änderungen machen damit auch der Status bei der Zentrale wieder korrekt ankommt.

intread = 0;Habe ich in beiden Funktionen wieder wie ursprünglich eingebaut

und
// Going from RX to TX does not work if there was a reception less than 0.5
    // sec ago. Due to CCA? Using IDLE helps to shorten this period(?)
    spi.strobe(CC1101_SIDLE);                               // go to idle mode
    spi.strobe(CC1101_SFTX );

Habe ich auch vor der Schleife für den TX Modus eingebaut.

Ohne diese Änderungen sieht es auf den Konsole zwar so aus alsob die Meldungen gesendet werden, aber sie kommen scheinbar nicht richtig an.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 August 2017, 07:47:15
Das hört sich ja schon mal gut an. Und geht es heute auch noch ?
Hab den Code schon mal entsprechend bei mir angepasst.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 August 2017, 08:03:51
Ne leider wieder hängen geblieben ...

Habe jetzt noch eingebaut, das ich nen flushrx über die Konsole auslösen kann.
Danach werden wieder Nachrichten empfangen.
Vorher hab ich mir noch den Status und den Inhalt des RX Buffers ausgeben lassen.
Sah alles gut aus ...
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 August 2017, 09:19:35
Lese doch mal den Status von GDO0 mit aus
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 August 2017, 09:54:52
Hab ich jetzt mit eingebaut.
Habe jetzt die Empfangsroutine komplett der, der vom culf-a angepasst.
Funktionieren tut sie so, mal schauen obs was bringt.

EDIT:
Leider bringt das auch nichts ...
Ist echt zum verrückt werden.

RX FIFO: 00
Status: 0D
GDO: 00

Ich werd heut Nachmittag noch etwas rumbasteln.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 August 2017, 10:50:08
Ich verstehe es auch nicht. Bei mir tritt es auch nur sehr, sehr selten auf.

Eine weitere Quelle könnte noch der Code (https://github.com/panStamp/arduino_avr/blob/master/cores/panstamp/cc1101.cpp) vom Panstamp sein
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 August 2017, 13:53:02
Ich habe mal das "autoflush on invalid CRC" abgeschalten und alles eingecheckt. Vielleicht bringt das ja was.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 August 2017, 20:38:46
Brachte auch alles nichts ...
Hab jetzt mal den Modus von GD0 geändert, dass er auf HIGH gesetzt wird, wenn ein Paket mit CRC Ok rein kommt.
Dazu hab ich noch den Trigger auf Rising geändert und natürlich den autoflush wieder aktiviert.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 August 2017, 21:30:50
Kannst Du mal Seine RSSI Werte mit ausgeben.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 August 2017, 21:39:12
Hab ich jetzt mal eingebaut.
Der Empfang funktioniert so eigentlich.
Nur war der CC1101 gerade auf einmal im Idle-State.
Hatte aber auch was an den RX-Timeout Registern geändert.

EDIT:
Der RSSI bei den aktuellen Paketen ist 0x5D
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 August 2017, 21:45:10
Hm - das sind ja -93 - das ist aber schon arg schlecht.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 August 2017, 22:07:10
Vielleicht hab ich die Antenne doch nicht richtig wieder angelötet.
Leider ist mir der Lötpin mit Leiterbahn abgebrochen ...

Hab nochmal was CC1101_MCSM1 geändert, so dass auch bei RXOFF_MODE im RX bleibt und nicht in den IDLE geht.

EDIT:
Kann es sein, dass die Umrechnung in dbm bei dir fehlerhaft ist?

rss = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG);         // read RSSI
        if (rss >= 128) rss = 255 - rss;
rss /= 2; rss += 72;

Habe sie jetzt umgebaut in:
int8_t rssi = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG);         // read RSSI

        if (rssi >= 128) {
rssi = (rssi - 256) / 2 -74;
}
else {
rssi = rssi / 2 -74;
}

rss = rssi * (-1);

DPRINT("RSSI: -");DPRINTLN(rss);

So bekomme ich jetzt auf -48 dbm bei Paketen von meiner Zentrale.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 04 August 2017, 09:18:59
Hab jetzt nochmal was umgebaut.
Der Cul-a prüft quasi bei jedem "read" ob der GD0 high ist, wenn ja, wird gelesen, wenn nein, wird der Status geprüft und wieder auf RX gesetzt wenn dem nicht so ist.
Dies habe ich nun auch so eingebaut, ich bin jetzt erstmal ziehmlich zuverlässig, dass es so funktioniert.


Es gibt ja noch das Timingproblem ...
Dem bin ich glaub ich auch auf der Spur.
Habe dazu beim Trigger für GD0 auch mal die Zeitausgabe eingebaut:

* - 3974
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 3976
* - 4252
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4478
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 4508
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4512
* - 4535
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 4604
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4609

Wenn man das ganze aufschlüsselt komme ich auf folgenden Ablauf:

1. Paket kommt rein
* - 3974
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 3976

2. Antwort dauert zu lange, CCU sendet Befehl erneut
* - 4252
3. Aktor Antwortet auf den ersten Befehl (Dauer 500ms)
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4478
4. Aktor liest Paket von 2.
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 4508
5. Aktor sendet Antwort (Dauer 260 ms)
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4512
6. CCU sendet nochmal den Befehl und diesmal klappt die Kommunikation (Dauer 74ms)
* - 4535
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 4604
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4609

Ist nur die Frage, warum dauert der Empfang bzw. die Verarbeitung und Antwort beim ersten mal so lange ...

Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 August 2017, 09:22:13
Kann es sein, dass die Umrechnung in dbm bei dir fehlerhaft ist?

Das kann schon sein, habe das eigentlich nur einfach übernommen. Aber Dein Code hat auch ein entscheidenes Problem:

int8_t rssi = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG);         // read RSSI
if (rssi >= 128) {
  .....

kann niemals wahr werden, da rssi als "8bit signed" deklariert ist und somit maximal den Wert 127 annehmen kann.

Ich habe aber noch eine andere Idee wegen des Empfang-Problems. Könntest Du einfach mal den Power-Save-Mode deaktivieren. Dazu einfach mal die loop() Funktion den If-Block rausnehmen:

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
//  if( worked == false && poll == false ) {
//    hal.activity.savePower<Idle<>>(hal);
//  }
}

Vielleicht suchen wir ja auch an der falschen Stelle.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 August 2017, 09:46:21
Ist nur die Frage, warum dauert der Empfang bzw. die Verarbeitung und Antwort beim ersten mal so lange ...

Kann ich dir sagen - Deine switchState-Implementierung hat wartet 250 ms.

  void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate) {
    uint8_t pin = SwitchPin(BaseChannel::number());

    if(BaseChannel::number() == 1) {
      if( newstate == AS_CM_JT_ON ) {
         PORTC &= ~B00000011;
         PORTD |= B11000000;
         delay(250);
         PORTD &= ~B11000000;
      }
 .......

Du solltest hier einen Alarm nutzen, der zeitverzögert wieder abschaltet.


class PortDOffAlarm : public Alarm {
public:
  PortDOffAlarm () : Alarm(0) { async(true); }
  virtual void trigger (AlarmClock& clock) {
    PORTD &= ~B11000000;
  }
}

Und dann im SwitchChannel
  PortDOffAlarm dalarm;

  void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate) {
    uint8_t pin = SwitchPin(BaseChannel::number());

    if(BaseChannel::number() == 1) {
      if( newstate == AS_CM_JT_ON ) {
         PORTC &= ~B00000011;
         PORTD |= B11000000;
         dalarm.set(millis2ticks(250));
         sysclock.add(dalarm);
      }
 .......

Da Du nur ein Register änders, kannst Du den Alarm ruhig "async" machen - sprich er wird direkt im TimerInterrupt ausgeführt.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 04 August 2017, 09:48:08
Ach jau, war wohl schon etwas zu spät gestern abend xD
Hab jetzt nen int16 draus gemacht.
Habe mir aber zum überprüfen der Rechenwege den ausgelesenen Wert vor der Umwandlung ausgeben lassen.
Da kam der nicht über 128.

Hier der Auszug aus dem Datenblatt:
The RSSI value read from the RSSI status
register is a 2’s complement number. The
following procedure can be used to convert the
RSSI reading to an absolute power level
(RSSI_dBm)
1) Read the RSSI status register
2) Convert the reading from a hexadecimal
number to a decimal number (RSSI_dec)
3) If RSSI_dec ≥ 128 then RSSI_dBm =
(RSSI_dec - 256)/2 – RSSI_offset
Note: It takes some time from the radio
enters RX mode until a valid RSSI value is
present in the RSSI register. Please see
DN505 [12] for details on how the RSSI
response time can be estimated.
CC1101
SWRS061I Page 45 of 98
4) Else if RSSI_dec < 128 then RSSI_dBm =
(RSSI_dec)/2 – RSSI_offset

Ich teste jetzt noch etwas meine Variante.
Ich glaub irgendwie nicht so recht daran, dass es am Powersave liegt.
Habe ja ne Ausgabe des Status eingebaut und über nen anderen Buchstaben den Reset.
Wenn ich den Status Ausgeben lasse, dann liest der ja auch vom SPI usw und danach gehts dann immer noch nicht.
Erst wenn ich den flushrx() ausführe gehts wieder.

EDIT:
Ahh, ok.
Werd ich mal umbauen ...
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 04 August 2017, 19:54:47
Vielleicht kämpfe ich hier auch mit einem CC1101 der einen weg hat ...
Auch ohne das Powersave macht er die Probleme.

Der der die Probleme macht, hängt an einem Ardunio Nano, direkt an den IOs also ohne Spannungsteiler.
Aber eigentlich sollte es daran ja nicht liegen, da beim Nano CUL auch bei steht, dass es auch so funktioniert.

Hatte jetzt noch einen Arduino Pro Mini 3,3v mit dem gleichen Sketch bespielt und hab den mal mit laufen lassen.
Dieser scheint sich nicht aufzuhängen ...

Ich hab jetzt noch nen Alarm eingebaut, der einmal pro Minute die Funktion flushrx aufruft.
Somit sollte es erstmal laufen ...
Aufjedenfall hab ich wieder was über den CC1101 und die AsksinPP Lib gelernt xD.

Vielleicht könntest du ja noch die korrigierte Berechnung des RSSI einbauen, falls das wiedermal gebraucht wird.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 05 August 2017, 16:43:46
Schaut mal in die Errata-Notes des CC1101.
Trilu musste da auch was einbauen, da bei ihm der CC1101 immer mal wieder hing...

Martin
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 05 August 2017, 18:28:10
Ich denke du meinst diesen Bug:

RXFIFO_OVERFLOW Issue —Radio stays in RX state instead of entering RXFIFO_OVERFLOW state

Deswegen hatten wir auch schon die max Paketlänge auf 61 gesetzt.
Außerdem war GD0 nicht auf High, so wie es in der Fehlerbeschreibung sein sollte.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 06 August 2017, 14:34:57
Ja, könnte der Bug gewesen sein.
Jedenfalls ist im aktuellen Code ein Hinweis drin, daß noch Bytes im Puffer stehen könnten und die zu löschen sind.

Deshalb wird nach dem regulären Auslesen des Empfangsbuffers in den Idle-Modus gewechselt (SIDLE), der Puffer gelöscht (SFRX), und dann wieder in den Empfangsmodus gewechselt (SRX).

Martin
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 August 2017, 10:41:03
Könnte sein, dass ich das Problem mit dem Empfang nun richtig gelöst habe.

Habe mir 3 meiner Homematic Geräte vorgenommen und dort den SPI-Verkehr mitgelesen.
Es gibt leichte Unterschiede bei der Art wie der CC1101 genau angesprochen wird.
Liegt wohl daran, dass die Geräte in verschiedenen Jahren auf den Markt gebracht wurden und daher immer nen etwas anderen Firmwarestand haben.

Ich habe nun die Init-Sequenz und die Register angepasst.
Außerdem habe ich das Schreiben der Register optimiert, indem diese nochmal ausgelesen werden so wie es die Homematic Geräte machen.
Ich werd das ganze noch etwas testen ob es wieder ausfällt, dann mach ich aus den einzelnen Schritten der Optimierung mal Commits.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 August 2017, 10:50:27
Das wäre ja wirklich super. Womit hast Du die SPI Kommunikation mitgelesen ?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 August 2017, 11:03:36
Mit diesem Teil hier: http://www.ebay.de/itm/24MHz-8CH-USB-Logic-Analyzer-8-Channel-Logic-Analyzer-Compatible-to-Saleae-/171202927182?hash=item27dc7d5a4e:g:M-8AAOSwyQtV6XEJ

Will auch nochmal den Differenz Tempsensor mitlesen, wie der das mit dem Aufwachen macht.
Der 6-Fachtaster macht nen komplettes init in nen paar ms, wenn man ne Taste drückt.
Die Lib macht ja nur nen Aufwecken.
Man müsste bei der Lib zumindest noch die Testregister nach dem Aufwecken schreiben, da diese wieder auf Default sind nachm Sleep.

Auch will ich nach den Optimierungen mal den SPI-Verkehr der Lib mitlesen, und die Timings vergleichen.

Ich kann nacher ja mal die gespeicherten Sequenzen anhängen, dann kannst du dir die auch mit dem kostenlosen Programm anschauen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 August 2017, 12:07:49
Den hab ich auch. Finde die Bedienung nur etwas gewöhnungsbedürftig.

Also der Switch-Sketch versetzt das Funkmodul nie in den Sleep - sollte damit auch kein neues Init brauchen. Na mal sehen, was nach Deinen Änderungen raus kommt.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 August 2017, 12:46:34
Die Bedienung ist doch echt einfach ...
Das mit dem sleep war nicht auf den Switch sondern auf den pir bezogen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 17 August 2017, 14:01:41
Soo, ich hab mal die Änderungen commited und Pullrequests erstellt.
Ich hab versucht die unabhängigen Änderungen in eigene branches zu packen, damit man das bei den Pullrequests besser unterscheiden kann.

Im Anhang sind auch die mitgenifften SPI Befehle.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 August 2017, 15:15:02
Na da habe ich ja was zu tun. Schaue ich mir die Tage an.
Wie sieht es denn jetzt bei Dir mit der Stabilität des Empfanges aus ?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 17 August 2017, 16:18:02
Also bisher ist es 1a.
Keine weitere Störung.

Falls du Hilfe beim Programm Logic brauchst sag bescheid ;-)
Ich weiß gerade nicht ob der auch die Kanaleinstellungen mit speichert.
Also welcher Kanal was ist.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 August 2017, 21:47:07
Ich habe heute Deine Änderungen übernommen. Dannach ging gar nichts mehr.
Habe es erst mal wieder zurückgebaut. Muss ich mir nochmal in Ruhe ansehen :-(
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 21 August 2017, 07:25:42
Moin,
ich hab gerade gesehn, dass bei der sndData Funktion das spi.strobe(CC1101_SIDLE ); bei meinem Commit abhanden gekommen ist.
Eigentlich sollte der Delay zwischen das Idle und das Buffer flushen kommen.
Vielleicht ists das auch schon.

Ich hab mal meine Radio.h wie sie aktuell funktioniert angehängt.
Da sind aber noch nen paar Änderungen drin die wieder weg können.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 August 2017, 08:32:21
Das ist gut - dann kann ich Stück für Stück probieren.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 21 August 2017, 20:27:15
@papa, ist es mit deinem schönen HM Baukasten auch möglich HM Geräte zu erzeugen die es so eigentlich von HM gar nicht gibt ?
Konkretes Beispiel : Gargentor Öffner + Tor Endlagen Melder . Nach HM Stand bräuchte ich dafür zwei Geräte z.B. den HM-LC-SW1 um das Relais des Antriebs zu schalten
und zum melden der Endlage(n) z.B. einen HM-RC-4 (oder HM-SEC-RHS, oder, oder ) Wäre es auch möglich mit nur einem Hybridgerät auszukommen , also z.B. den HM-LC-SW2 als Basis und das Motor Relais an Channel 1 und den Ausgang des Channel 2 als Eingang definieren für den Endlagenschalter ? Für FHEM sollte das ein ganz normaler Switch mit 2 Kanälen sein, natürlich wäre  der Channel 2 nicht schaltbar, aber das Ding muss ja nur den aktuellen H/L Status des Eingangs zurückmelden.
Das würde der Switch doch sowieso machen wenn sich durch ein anderes Senderdevice sein Zustand ändert.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 August 2017, 22:45:33
@papa, ist es mit deinem schönen HM Baukasten auch möglich HM Geräte zu erzeugen die es so eigentlich von HM gar nicht gibt ?
Konkretes Beispiel : Gargentor Öffner + Tor Endlagen Melder . Nach HM Stand bräuchte ich dafür zwei Geräte z.B. den HM-LC-SW1 um das Relais des Antriebs zu schalten
und zum melden der Endlage(n) z.B. einen HM-RC-4 (oder HM-SEC-RHS, oder, oder ) Wäre es auch möglich mit nur einem Hybridgerät auszukommen , also z.B. den HM-LC-SW2 als Basis und das Motor Relais an Channel 1 und den Ausgang des Channel 2 als Eingang definieren für den Endlagenschalter ? Für FHEM sollte das ein ganz normaler Switch mit 2 Kanälen sein, natürlich wäre  der Channel 2 nicht schaltbar, aber das Ding muss ja nur den aktuellen H/L Status des Eingangs zurückmelden.
Das würde der Switch doch sowieso machen wenn sich durch ein anderes Senderdevice sein Zustand ändert.

Im Prinzip ja. Dazu müsste man sich einen DummySwitchChannel basteln, der mit einem Eingang verbunden wird und dessen Status zurück gibt. Das ganze dann in ein HM-LC-SW2 Device.

Eine Alternative - die leider noch nicht geht - wäre, dass man 2 logische Geräte auf eine Hardware bringt. Also ein HM-LC-SW1 und einen HM-Sec-SC-2 auf eine Hardware. Dazu müsste noch ein Message-Routing in die Lib eingebaut werden.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 24 August 2017, 16:04:40
Ich habe gestern Abend mal einen Arduino Micro als HM-LC-SW2 auf dem Steckbrett in Betrieb genommen.
Ein echter HM-LC-SW2 hat ja noch die internen Taster self01 & self02
Wäre das vllt. auch eine mögliche Lösung wenn man zumindest für einen den extern Pin zusätzlich definieren könnte und später einfach mit einem Channel peert und die Register so setzt das H/L am Eingang direkt auf dem Status des Channel abgebildet wird ?   
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 August 2017, 17:12:46
Sowas habe ich letztens in die ConfigToggleButton Klasse (Button.h) eingebaut.
Die internen Peers werden jetzt beim Switch Example auch immer angelegt.
Titel: Antw:AskSin++ Library
Beitrag von: Stütti am 24 August 2017, 21:37:54
Ich versuche gerade gerade das HM-RC-4 Sketch aus den Examples des V1-Branchs für einen Arduino Pro Mini (ATmega168) zu kompilieren.
Leider bekomme ich eine Fehlermeldung:

Arduino: 1.8.4 (Linux), Board: "Arduino Mini, ATmega168"

In file included from /home/benjamin/Arduino/libraries/LowPower/LowPower.cpp:32:0:
/home/benjamin/Arduino/libraries/LowPower/LowPower.cpp: In member function 'void LowPowerClass::powerExtStandby(period_t, adc_t, bod_t, timer2_t)':
/home/benjamin/Arduino/libraries/LowPower/LowPower.cpp:980:18: error: 'SLEEP_MODE_EXT_STANDBY' was not declared in this scope
    lowPowerBodOn(SLEEP_MODE_EXT_STANDBY);
                  ^
/home/benjamin/Arduino/libraries/LowPower/LowPower.cpp:980:4: note: in expansion of macro 'lowPowerBodOn'
    lowPowerBodOn(SLEEP_MODE_EXT_STANDBY);
    ^
/home/benjamin/Arduino/libraries/LowPower/LowPower.cpp:985:17: error: 'SLEEP_MODE_EXT_STANDBY' was not declared in this scope
   lowPowerBodOn(SLEEP_MODE_EXT_STANDBY);
                 ^
/home/benjamin/Arduino/libraries/LowPower/LowPower.cpp:985:3: note: in expansion of macro 'lowPowerBodOn'
   lowPowerBodOn(SLEEP_MODE_EXT_STANDBY);
   ^
exit status 1
Fehler beim Kompilieren für das Board Arduino Mini.

Funktioniert die LowPower Lib nicht auf dem ATmega168?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 August 2017, 22:00:35
Scheinbar nicht - aber auf nem Pro Mini ist doch nen 328 drauf.
Titel: Antw:AskSin++ Library
Beitrag von: Stütti am 24 August 2017, 22:22:04
Nein, es gibt auch Minis mit 168. Schade, da habe ich noch ne Handvoll von.
Oder hast du eine Idee für einen Workaround?
Angeblich konnten ältere IDE-Versionen das. Habe es gerade mit einer 1.0.6 versucht, da machen aber noch mehr der anderen Libs Schwierigkeiten.

Edit: Habe bei rocketstream eine Lösung gefunden:
https://github.com/rocketscream/Low-Power/issues/14#issuecomment-260173243 (https://github.com/rocketscream/Low-Power/issues/14#issuecomment-260173243)
Leider ist der Sketch ohnehin zu groß (135%) für den kleinen ATmega.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 August 2017, 10:53:24
Also da geht noch was :-)

Ohne AES, SPI-Library, einfache Status-LED und Debug-Ausgaben abgeschalten - komme ich knapp drunter. Keine Ahnung, ob dass dann noch richtig tut ?

Device: atmega328p

Program:   16214 bytes (49.5% Full)
(.text + .data + .bootloader)

Data:        713 bytes (34.8% Full)
(.data + .bss + .noinit)


Finished building target: HM_RC_4

Ich hänge den angepassten Sketch hier mal an. Funktioniert nur im Master.
Titel: Antw:AskSin++ Library
Beitrag von: Stütti am 25 August 2017, 12:04:02
Wow, sehr cool. Danke!

Habe gestern auch noch denselben Branch für einen ATmega328p kompiliert und mal testweise auf einen neueren Arduino aufgespielt. Lief ohne Probleme durch!
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 26 August 2017, 07:35:07
Moin,
wie schauts mit meinen Änderungen aus?
Konntest du schon weiter testen?

Ich kann nur berichten, dass es seitdem 1a läuft  ;D
Titel: Antw:AskSin++ Library
Beitrag von: papa am 26 August 2017, 21:41:02
Moin,
wie schauts mit meinen Änderungen aus?
Konntest du schon weiter testen?

Nein -leider noch nicht.

Ich kann nur berichten, dass es seitdem 1a läuft  ;D

Ein Grund mehr, mich mal dran zu machen.
Titel: Antw:AskSin++ Library
Beitrag von: rippi46 am 27 August 2017, 14:10:14
Hallo,

erst einmal ein dickes Lob für die tolle Arbeit hier.

Versuche schon seit Tagen mit der Asksin++ einen HM-Motion-Detector zu bauen.
In der Zwischenzeit habe ich ein HM-Devices das so einigermaßen funktioniert.

Habe mir die Asksin++-V1 runter geladen, dann diverse Libraries besorgt und nach vielen Fehlversuchen es geschafft ein HM-Motionsdetector in Fhem zu integrieren.
Habe dann versucht einen Bootloader zu erzeugen, damit ich die Firmware besser updaten kann. Mit der makeota.html vom "Relay Platine auf HM, MySensors, ZWave Basis" habe ich einen Bootloader geflasht (mit angepasstem  HM-Typ 004A für HM-SEC-MDIR).

Beim Versuch die Firmware zu flashen bricht es mit einem missing Ack ab. Flashe ich dagegen die Relayplatinen-Firmware funktioniert das OTA-Flashen.

hier das Listing meines Motiondetector:

Internals:
   CFGFN
   DEF        567890
   IODev      cul868_HM
   LASTInputDev cul868_HM
   MSGCNT     90
   NAME       HM_567890
   NOTIFYDEV  global
   NR         1066
   STATE      motion
   TYPE       CUL_HM
   cul868_HM_MSGCNT 90
   cul868_HM_RAWMSG A0D46A241567890F11324013E0080::-22:cul868_HM
   cul868_HM_RSSI -22
   cul868_HM_TIME 2017-08-27 13:43:00
   lastMsg    No:46 - t:41 s:567890 d:F11324 013E0080
   protCmdDel 9
   protLastRcv 2017-08-27 13:43:00
   protResnd  7 last_at:2017-08-27 13:34:41
   protResndFail 2 last_at:2017-08-27 13:35:17
   protSnd    155 last_at:2017-08-27 13:43:00
   protState  CMDs_done
   rssi_at_cul868_HM lst:-22 cnt:90 avg:-22.86 max:-20 min:-35
   rssi_cul868_HM avg:-119.6 max:-104 min:-123 lst:-121 cnt:10
   READINGS:
     2017-08-27 13:00:05   Activity        alive
     2017-08-27 13:00:06   CommandAccepted yes
     2017-08-27 13:00:05   D-firmware      1.6
     2017-08-27 13:00:05   D-serialNr      SW9K9TYC3I
     2017-08-27 13:00:06   PairedTo        0xF11324
     2017-08-27 13:00:06   R-brightFilter  7
     2017-08-27 13:00:06   R-captInInterval off
     2017-08-27 13:00:06   R-evtFltrNum    1
     2017-08-27 13:00:06   R-evtFltrPeriod 4.5 s
     2017-08-27 13:00:06   R-minInterval   240
     2017-08-27 13:00:06   R-pairCentral   0xF11324
     2017-08-27 13:00:06   R-sign          off
     2017-08-27 13:39:27   battery         ok
     2017-08-27 13:43:00   brightness      0
     2017-08-27 13:39:27   cover           closed
     2017-08-27 13:43:00   motion          on (to cul868_HM)
     2017-08-27 13:43:00   motionCount     62_next:240s
     2017-08-27 13:39:16   motionDuration  851
     2017-08-27 13:25:18   powerOn         2017-08-27 13:25:18
     2017-08-27 13:39:27   recentStateType info
     2017-08-27 13:43:00   state           motion
     2017-08-27 13:43:00   trigDst_F11324  noConfig
     2017-08-27 13:43:00   trigger_cnt     62
     RegL_00.:
       VAL
   helper:
     HM_CMDNR   70
     PONtest    0
     cSnd       01F1132456789000040000000000,01F1132456789000040000000000
     cfgChkResult No regs found for:HM_567890


     getCfgList all
     getCfgListNo ,4
     mId        004A
     moStart    1503833967.79771
     peerIDsRaw ,00000000
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +567890,00,00,00
       nextSend   1503834180.32141
       prefIO
       rxt        2
       vccu
       p:
         567890
         00
         00
         00
     mRssi:
       mNo        46
       io:
         cul868_HM  -20
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
     rpt:
       IO         cul868_HM
       flg        A
       ts         1503834180.22294
       ack:
         HASH(0x7e75378)
         468002F1132456789001010000
         HASH(0x7e75378)
         468002F1132456789000
     rssi:
       at_cul868_HM:
         avg        -22.8666666666667
         cnt        90
         lst        -22
         max        -20
         min        -35
       cul868_HM:
         avg        -119.6
         cnt        10
         lst        -121
         max        -104
         min        -123
     shadowReg:
       RegL_01.    22:C8
     tmpl:
   nb:
     cnt        1
Attributes:
   IODev      cul868_HM
   actCycle   000:20
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.6
   model      HM-SEC-MDIR
   peerIDs    00000000,
   room       CUL_HM
   serialNr   SW9K9TYC3I
   subType    motionDetector

Versuche jetzt seit Stunden sämtliche Tools aus um einen funtionioerenden Bootloader zu erzeugen - leider ohne Erfolg.

Meine Vorgehensweise:

Ich Erzeuge mit der makeote.html einen Bootloader. Diesen flashe ich mit:
avrdude -p m328p -c usbtiny
avrdude -p m328p -c usbtiny -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m -e -Uflash:w:SW9K9TYC3I.hex:i

anschließend erzeuge ich mit der Arduino IDE ein Hex-File der Firmware und wandle diese mit hex2eq3.php in ein Firmwarefile für flash-ota um.

sudo ./flash-ota -f HM-SEC-MDIR.eq3 -s SW9K9TYC3I -c /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103U5MA-if00-port0
Beim Versuch diese über OTA zu flashen bricht der ganze Vorgang mit "missing Ack" ab.

Vielleicht kann mir jemand etwas Licht ins Dunkel bringen, was ich vielleicht vergessen oder falsch gemacht habe.

Desweiteren wollte ich diverse Parameter unter fhem vom Motiondetector verändern, kann aber nur "ledOnTime" als einzigen Wert verändern.


Gruß rippi

das sind die Libraries und der Sketch, den ich verwende:


Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 August 2017, 17:46:44
Schau Dir bitte mal das Readme im bootloader/avr im Master Branch an. Da stehen die einzelnen Schritte alle drin. Da ist auc ein generisches makeota.html drin. Manche Example bringen auch eine eigene Version mit, da dort extra Optionen gesetzt werden können.

Wenn beim OTA-Flashen "Missing ACK" Fehler kommen, so liegt das nicht am Image, sondern an der Funkverbindung. Am besten den Abstand zwischen Sender und Empfänger mal verändern.

Wenn Du die Parameter nicht ändern kannst, könnten Bootloader und Firmware nicht passen.
Titel: Antw:AskSin++ Library
Beitrag von: rippi46 am 27 August 2017, 18:39:22
Hallo

habe jetzt mit der generischen makeota.html den Bootloader erzeugt und mit:

avrdude -p m328p -c usbtiny -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m -e -Uflash:w:SW9K9TYC3I.hex:i
auf den arduino geflasht.

dann mit der Arduino  IDE mit:

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

/*
 * Setup defines to configure the library.
 * Note: If you are using the Eclipse Arduino IDE you will need to set the
 * defines in the project properties.
 */
#ifndef __IN_ECLIPSE__
  #define USE_AES
  #define HM_DEF_KEY 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10
  #define HM_DEF_KEY_INDEX 0
#endif

#include <AskSinPP.h>
#include <PinChangeInt.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include <BatterySensor.h>

#include <TSL2561.h>
#include <Wire.h>

// define this to read the device id, serial and device type from bootloader section
#define USE_OTA_BOOTLOADER

#ifdef USE_OTA_BOOTLOADER
  #define OTA_MODEL_START  0x7ff0 // start address of 2 byte model id in bootloader
  #define OTA_SERIAL_START 0x7ff2 // start address of 10 byte serial number in bootloader
  #define OTA_HMID_START   0x7ffc // start address of 3 byte device id in bootloader
#else
  // device ID
  #define DEVICE_ID HMID(0x56,0x78,0x90)
  // serial number
  #define DEVICE_SERIAL "SW9K9TYC3I"
#endif

// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8
// Arduino pin for the PIR
// A0 == PIN 14 on Pro Mini
#define PIR_PIN 3


#define BATTERY_LOW 22
#define BATTERY_CRITICAL 19


// number of available peers per channel
#define PEERS_PER_CHANNEL 6

// all library classes are placed in the namespace 'as'
using namespace as;

// Create an SFE_TSL2561 object, here called "light":
TSL2561 light;

void motionISR ();

class MotionList1Data {
public:
  uint8_t EventFilterPeriod : 4;     // 0x01
  uint8_t EventFilterNumber : 4;     // 0x01
  uint8_t MinInterval       : 3;     // 0x02
  uint8_t CaptureWithinInterval : 1; // 0x02
  uint8_t BrightnessFilter  : 4;     // 0x02
  uint8_t AesActive         :1;      // 0x08, s:0, e:1
  uint8_t LedOntime;                 // 0x20

  static uint8_t getOffset(uint8_t reg) {
    switch (reg) {
      case 0x01: return 0;
      case 0x02: return 1;
      case 0x08: return 2;
      case 0x20: return 3;
      default: break;
    }
    return 0xff;
  }

  static uint8_t getRegister(uint8_t offset) {
    switch (offset) {
      case 0:  return 0x01;
      case 1:  return 0x02;
      case 2:  return 0x08;
      case 3:  return 0x20;
      default: break;
    }
    return 0xff;
  }
};

class MotionList1 : public ChannelList<MotionList1Data> {
public:
  MotionList1(uint16_t a) : ChannelList(a) {}

  uint8_t eventFilterPeriod () const { return getByte(0,0x0f,0); }
  bool eventFilterPeriod (uint8_t value) const { return setByte(0,value,0x0f,0); }
  uint8_t eventFilterNumber () const { return getByte(0,0xf0,4); }
  bool eventFilterNumber (uint8_t value) const { return setByte(0,value,0xf0,4); }

  uint8_t minInterval () const { return getByte(1,0x07,0); }
  bool minInterval (uint8_t value) const { return setByte(1,value,0x07,0); }
  bool captureWithinInterval () const { return isBitSet(1,0x08); }
  bool captureWithinInterval (bool value) const { return setBit(1,0x08,value); }
  uint8_t brightnessFilter () const { return getByte(1,0xf0,4); }
  bool brightnessFilter (uint8_t value) const { return setByte(1,value,0xf0,4); }

  bool aesActive () const { return isBitSet(2,0x01); }
  bool aesActive (bool s) const { return setBit(2,0x01,s); }

  uint8_t ledOntime () const { return getByte(3); }
  bool ledOntime (uint8_t value) const { return setByte(3,value); }

  void defaults () {
    eventFilterPeriod(1);
    eventFilterNumber(1);
    minInterval(4);
    captureWithinInterval(false);
    brightnessFilter(4);
    aesActive(false);
    ledOntime(100);
  }
};

BatterySensor battery;
// BatterySensorExt battery;
// BatterySensorUni battery(16,7); // A2 & D7

class MotionEventMsg : public Message {
public:
  void init(uint8_t msgcnt,uint8_t ch,uint8_t counter,uint8_t brightness,uint8_t next) {
    Message::init(0xd,msgcnt,0x41,Message::BIDI|Message::WKMEUP,ch & 0x3f,counter);
    pload[0] = brightness;
    pload[1] = (next+4) << 4;
  }
};

class MotionChannel : public Channel<MotionList1,EmptyList,List4,PEERS_PER_CHANNEL>, public Alarm {

  class QuietMode : public Alarm {
  public:
    bool  enabled;
    bool  motion;
    MotionChannel& channel;
    QuietMode (MotionChannel& c) : Alarm(0), enabled(false), motion(false), channel(c) {}
    virtual ~QuietMode () {}
    virtual void trigger (AlarmClock& clock) {
      DPRINTLN(F("minInterval End"));
      enabled = false;
      if( motion == true ) {
        motion = false;
        channel.motionDetected();
      }
    }
  };

  // send the brightness every 4 minutes to the master
  #define LIGHTCYCLE seconds2ticks(4*60)
  class Cycle : public Alarm {
  public:
    MotionChannel& channel;
    Cycle (MotionChannel& c) : Alarm(LIGHTCYCLE), channel(c) {}
    virtual ~Cycle () {}
    virtual void trigger (AlarmClock& clock) {
      tick = LIGHTCYCLE;
      clock.add(*this);
      channel.sendState();
    }
  };

  // return timer ticks
  uint32_t getMinInterval () {
    switch( getList1().minInterval() ) {
      case 0: return seconds2ticks(15);
      case 1: return seconds2ticks(30);
      case 2: return seconds2ticks(60);
      case 3: return seconds2ticks(120);
    }
    return seconds2ticks(15);
  }

private:
  MotionEventMsg   msg;
  uint8_t          counter;
  QuietMode        quiet;
  Cycle            cycle;

public:
  MotionChannel () : Channel(), Alarm(0), counter(0), quiet(*this), cycle(*this) {
    aclock.add(cycle);
    pinMode(PIR_PIN,INPUT);
    pirInterruptOn();
  }
  virtual ~MotionChannel () {}

  uint8_t status () const {
    return brightness();
  }

  uint8_t flags () const {
    return battery.low() ? 0x80 : 0x00;
  }

  void sendState () {
    pirInterruptOff();
    Device& d = device();
    d.sendInfoActuatorStatus(d.getMasterID(),d.nextcount(),*this);
    pirInterruptOn();
  }

  uint8_t brightness () const {
    static uint16_t maxvalue = 0;
    uint8_t value = 0;
    unsigned int data0, data1;
    if (light.getData(data0,data1)) {
      double lux;    // Resulting lux value
      light.getLux (data0,data1,lux);
      uint16_t current = (uint16_t)lux;
      DPRINT(F("light: ")); DHEXLN(current);
      if( maxvalue < current ) {
        maxvalue = current;
      }
      value = 200UL * current / maxvalue;
    }
    return value;
  }

  void pirInterruptOn () {
#if PIR_PIN == 3
    attachInterrupt(digitalPinToInterrupt(3), motionISR, RISING);
#else
    attachPinChangeInterrupt(PIR_PIN,motionISR,RISING);
#endif
  }

  void pirInterruptOff () {
#if PIR_PIN == 3
    detachInterrupt(digitalPinToInterrupt(3));
#else
    detachPinChangeInterrupt(PIR_PIN);
#endif
  }

  // this runs synch to application
  virtual void trigger (AlarmClock& clock) {
    if( quiet.enabled == false ) {
      DPRINTLN(F("Motion"));
      // start timer to end quiet interval
      quiet.tick = getMinInterval();
      quiet.enabled = true;
      aclock.add(quiet);
      // blink led
      if( sled.active() == false ) {
        sled.ledOn( centis2ticks(getList1().ledOntime()) / 2);
      }
      msg.init(device().nextcount(),number(),++counter,brightness(),getList1().minInterval());
      device().sendPeerEvent(msg,*this);
    }
    else if ( getList1().captureWithinInterval() == true ) {
      // we have had a motion during quiet interval
      quiet.motion = true;
    }
  }

  // runs in interrupt
  void motionDetected () {
    // cancel may not needed but anyway
    aclock.cancel(*this);
    // activate motion message handler
    aclock.add(*this);
    }
};


MultiChannelDevice<MotionChannel,1> sdev(0x20);
void motionISR () { sdev.channel(1).motionDetected(); }


class CfgButton : public Button {
public:
  CfgButton () {
    setLongPressTime(seconds2ticks(3));
  }
  virtual void state (uint8_t s) {
    uint8_t old = Button::state();
    Button::state(s);
    if( s == Button::released ) {
      sdev.startPairing();
    }
    else if( s == longpressed ) {
      if( old == longpressed ) {
        sdev.reset(); // long pressed again - reset
      }
      else {
        sled.set(StatusLed::key_long);
      }
    }
  }
};

CfgButton cfgBtn;
void cfgBtnISR () { cfgBtn.check(); }

void setup () {
#ifndef NDEBUG
  Serial.begin(57600);
  DPRINTLN(ASKSIN_PLUS_PLUS_IDENTIFIER);
#endif
  if( eeprom.setup(sdev.checksum()) == true ) {
    sdev.firstinit();
  }

  light.begin();
  // If gain = false (0), device is set to low gain (1X)
  // If gain = high (1), device is set to high gain (16X)
  // If time = 0, integration will be 13.7ms
  // If time = 1, integration will be 101ms
  // If time = 2, integration will be 402ms
  // If time = 3, use manual start / stop to perform your own integration
  light.setTiming(0,2); //gain,time);
  light.setPowerUp();

  sled.init(LED_PIN);

  cfgBtn.init(CONFIG_BUTTON_PIN);
  attachPinChangeInterrupt(CONFIG_BUTTON_PIN,cfgBtnISR,CHANGE);
  radio.init();

#ifdef USE_OTA_BOOTLOADER
  sdev.init(radio,OTA_HMID_START,OTA_SERIAL_START);
  sdev.setModel(OTA_MODEL_START);
#else
  sdev.init(radio,DEVICE_ID,DEVICE_SERIAL);
  sdev.setModel(0x00,0x4a);
#endif
  sdev.setFirmwareVersion(0x16);
  // TODO check sub type and infos
  sdev.setSubType(Device::MotionDetector);
  sdev.setInfo(0x01,0x01,0x00);

  radio.enableGDO0Int();
  aclock.init();

  sled.set(StatusLed::welcome);
  // set low voltage to 2.2V
  // measure battery every 1h
  //battery.init(BATTERY_LOW,seconds2ticks(60UL*60));
  // init for external measurement
  //battery.init(BATTERY_LOW,seconds2ticks(60UL*60),refvoltage,divider);
  // UniversalSensor setup
  battery.init(BATTERY_LOW,seconds2ticks(60UL*60));
  battery.critical(BATTERY_CRITICAL);
}

void loop() {
  bool worked = aclock.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    // deep discharge protection
    // if we drop below critical battery level - switch off all and sleep forever
    if( battery.critical() ) {
      radio.setIdle();
      // this call will never return
      activity.sleepForever();
    }
    // if nothing to do - go sleep
    activity.savePower<Sleep>();
  }
}

das Hex-File für die Firmware erzeugt.

Mit :

php hex2eq3.php --inFile HM-SEC-MDIR.hex --outFile HM-SEC-MDIR.eq3 --spmPageSize 256 --hexEndAddress 0xDFFE --outFormat eq3 --pathTo-srec_cat /usr/bin/srec_cat
das eq3-File erzeugt und mit:

sudo ./flash-ota -f HM-SEC-MDIR.eq3 -s SW9K9TYC3I -c /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103U5MA-if00-port0
versucht auf den Arduino zu flashen.
Bekomme aber diese Ausgabe:

vdr@vdr-media:~/hmcfgusb$ sudo ./flash-ota -f HM-SEC-MDIR.eq3 -s SW9K9TYC3I -c /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103U5MA-if00-port0
HomeMatic OTA flasher version 0.102-git

Reading firmware from HM-SEC-MDIR.eq3...
Firmware with 224 blocks successfully read.
Opening culfw-device at path /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103U5MA-if00-port0 with speed 38400
Requesting firmware version
culfw-device firmware version: a-culfw
Entering 10k-mode
Waiting for device with serial SW9K9TYC3I
Device with serial SW9K9TYC3I (HMID: 567890) entered firmware-update-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0001/0224 /
Missing ACK!
Flashing 224 blocks: 0001/0224 /
Missing ACK!

Too many errors, giving up!

wenn ich aber das angebe:

sudo ./flash-ota -f HM-Relay-Universal.eq3 -s SW9K9TYC3I -c /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103U5MA-if00-port0
wir die Firmware geflasht, obwohl ich einen Bootloader für einen Motiondetektor geflasht habe.

Muß ich noch beim *.ino-File etwas spezielles beachten?

Danke für deine Hilfe!

Gruß rippi

Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 August 2017, 18:47:20
Du hast das Readme immer noch nicht gelesen. Sonst hätest Du prepareforota.sh benutzt, um das eq3 zu erzeugen. Bitte nochmal lesen und diesen Schritten folgen.

Dem Bootloader ist es egal, welche Software geflasht wird, solange die Daten richtig angeliefert werden.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 27 August 2017, 20:07:38
@rippi46 , muss es denn unbedingt OTA sein ?
Du kannst auch den einfachen Weg gehen (ohne OTA Unterstützung) und in der Arduino IDE direkt "Hochladen mit Programmer" ausführen.
Titel: Antw:AskSin++ Library
Beitrag von: rippi46 am 27 August 2017, 21:42:21
@Wzut mit der arduino IDE habe ich es schon geschafft, sonst hätte ich kein fhem-device das so einigermaßen funktioniert.

Da ich relativ viele Geräte und Sensoren im Haus verteilt habe, wäre es schön es würde über OTA funktionieren. Leider funktionieren noch nicht alle Tools unter Windows oder unter Ubuntu, sodass ich zuerst meine Entwicklungsumgebung anpassen muss.

@papa was muss ich in fhem anpassen, das ich die Parameter des Motionsdetector verändern kann?

Habe das Readme gelesen, bekomme aber leider nicht alle Files erzeugt . Bekomme unter Windows einfach das eq3-File nicht hin unt unter Ubuntu bekomme ich den Usbtiny nicht zum laufen.

Ich glaube das wird heute nichts mehr.

Gruss rippi
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 August 2017, 08:54:58
@papa was muss ich in fhem anpassen, das ich die Parameter des Motionsdetector verändern kann?

Nichts. Funktioniert so wie bei allen HM Geräten. Nach dem Pairen ein getConfig. Dann geht set DEVICE regSet Register Wert.

Habe das Readme gelesen, bekomme aber leider nicht alle Files erzeugt . Bekomme unter Windows einfach das eq3-File nicht hin unt unter Ubuntu bekomme ich den Usbtiny nicht zum laufen.

Hast Du das srecord aus dem Git verwendet ? Am besten das Respository clonen und dann direkt im avr/bootloader Verzeichnis das prepareforota.sh aufrufen. Wie auch im Readme geschrieben muss dafür eine Cygwin-Umgebung installiert sein, damit die Shell-Skripte ausgeführt werden können.
Titel: Antw:AskSin++ Library
Beitrag von: rippi46 am 28 August 2017, 12:29:28
Hallo,

habe es jetzt endlich geschafft die Firmware zu erzeugen und OTA zu flashen.

Wollte das ganze halt unter Linux zum Laufen bringen. So muss ich für das erzeugen der Firmware den Windowsrechner bemühen.

Hatte ursprünglich ein MinGW-Shell, mit der die php-Scripte nicht liefen. Nach der Installation von Cygwin mit bash und php konnte ich die Firmware nach anfänglichen Schwierigkeiten(die Hex-Datei darf nicht im gleichen Verzeichnis liegen) erzeugen.

Das Setzen der Register werde ich dann heute Abend testen.

Danke nochmal für eure Hilfe.


Gruss rippi
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 August 2017, 13:01:16
Na das klingt doch schon mal gut. Ich bin gerade dabei, ein prepare-Script zu machen, welches keine weiteren installierten Tools benötigt - also komplett in der bash läuft. Ich hänge das hier mal an. Kannst Du auch gerne mal ausprobieren. Ist allerdings noch nicht gut getestet und etwas langsam.
Titel: Antw:AskSin++ Library
Beitrag von: rippi46 am 28 August 2017, 13:57:37
Aufrufen mit:

./prepota HM-SEC-MDIR.ino.hex
erzeugt als Ausgabe eine Art HEXDump für ca 18s-20s, aber es wird keine eq3-Datei erzeugt.

oder mache ich etwas falsch?

Gruss rippi


PS: wollte einen alten 868er Cul zu einem HM-Device umbauen und habe den Sketch des Motion-detector aus dem Master-Branch genommen.
und im Sketch die Zeile typedef Radio<SPIType,2> RadioType; in typedef Radio<SPIType,3> RadioType; geändert.

Leider kann ich den Sketch nicht compilieren.
In file included from C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:17:0:

E:\Arduino\libraries\EnableInterrupt-0.9.7/EnableInterrupt.h:22:130: note: #pragma message: NOTICE: *** EnableInterrupt library PRIOR TO version 0.9.6. This is not a problem. Keep calm, and carry on. ***

 #pragma message("NOTICE: *** EnableInterrupt library PRIOR TO version 0.9.6. This is not a problem. Keep calm, and carry on. ***")

                                                                                                                                  ^

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino: In member function 'void Hal::init()':

HM-SEC-MDIR:56: error: no matching function for call to 'Hal::init()'

     BaseHal::init();

                   ^

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:56:19: note: candidate is:

In file included from C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:18:0:

E:\Arduino\libraries\AskSinPP-master/AskSinPP.h:46:8: note: void as::AskSin<StatusLed, Battery, Radio>::init(const as::HMID&) [with StatusLed = as::StatusLed<4u>; Battery = as::BatterySensor; Radio = as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 3u>]

   void init (const HMID& id) {

        ^

E:\Arduino\libraries\AskSinPP-master/AskSinPP.h:46:8: note:   candidate expects 1 argument, 0 provided

In file included from C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:22:0:

E:\Arduino\libraries\AskSinPP-master/MultiChannelDevice.h: In instantiation of 'void as::ChannelDevice<HalType, ChannelType, ChannelCount, List0Type>::init(HalType&) [with HalType = Hal; ChannelType = as::MotionChannel<Hal, 6>; int ChannelCount = 1; List0Type = as::List0]':

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:96:16:   required from here

E:\Arduino\libraries\AskSinPP-master/MultiChannelDevice.h:126:5: error: no matching function for call to 'Hal::init(as::HMID&)'

     hal.init(id);

     ^

E:\Arduino\libraries\AskSinPP-master/MultiChannelDevice.h:126:5: note: candidate is:

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:55:8: note: void Hal::init()

   void init () {

        ^

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:55:8: note:   candidate expects 0 arguments, 1 provided

Mehrere Bibliotheken wurden für "Wire.h" gefunden
 Benutzt: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire
 Nicht benutzt: E:\Arduino\libraries\Wire
Bibliothek EnableInterrupt-0.9.7 in Version 0.9.5 im Ordner: E:\Arduino\libraries\EnableInterrupt-0.9.7  wird verwendet
Bibliothek AskSinPP-master im Ordner: E:\Arduino\libraries\AskSinPP-master (legacy) wird verwendet
Bibliothek TimerOne in Version 1.1 im Ordner: E:\Arduino\libraries\TimerOne  wird verwendet
Bibliothek Low-Power-master in Version 1.6 im Ordner: E:\Arduino\libraries\Low-Power-master  wird verwendet
Bibliothek TSL2561 im Ordner: E:\Arduino\libraries\TSL2561 (legacy) wird verwendet
Bibliothek Wire in Version 1.0 im Ordner: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire  wird verwendet
exit status 1
no matching function for call to 'Hal::init()'

Fehlen da noch spezielle Libraries?


Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 August 2017, 15:20:29
Aufrufen mit:

./prepota HM-SEC-MDIR.ino.hex
erzeugt als Ausgabe eine Art HEXDump für ca 18s-20s, aber es wird keine eq3-Datei erzeugt.

oder mache ich etwas falsch?

Nein - einfach in eine Datei umleiten

./prepota HM-SEC-MDIR.ino.hex > HM-SEC-MDIR.ino.hex.eq3

PS: wollte einen alten 868er Cul zu einem HM-Device umbauen und habe den Sketch des Motion-detector aus dem Master-Branch genommen.
und im Sketch die Zeile typedef Radio<SPIType,2> RadioType; in typedef Radio<SPIType,3> RadioType; geändert.

Leider kann ich den Sketch nicht compilieren.
In file included from C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:17:0:

E:\Arduino\libraries\EnableInterrupt-0.9.7/EnableInterrupt.h:22:130: note: #pragma message: NOTICE: *** EnableInterrupt library PRIOR TO version 0.9.6. This is not a problem. Keep calm, and carry on. ***

 #pragma message("NOTICE: *** EnableInterrupt library PRIOR TO version 0.9.6. This is not a problem. Keep calm, and carry on. ***")

                                                                                                                                  ^

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino: In member function 'void Hal::init()':

HM-SEC-MDIR:56: error: no matching function for call to 'Hal::init()'

     BaseHal::init();

                   ^

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:56:19: note: candidate is:

In file included from C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:18:0:

E:\Arduino\libraries\AskSinPP-master/AskSinPP.h:46:8: note: void as::AskSin<StatusLed, Battery, Radio>::init(const as::HMID&) [with StatusLed = as::StatusLed<4u>; Battery = as::BatterySensor; Radio = as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 3u>]

   void init (const HMID& id) {

        ^

E:\Arduino\libraries\AskSinPP-master/AskSinPP.h:46:8: note:   candidate expects 1 argument, 0 provided

In file included from C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:22:0:

E:\Arduino\libraries\AskSinPP-master/MultiChannelDevice.h: In instantiation of 'void as::ChannelDevice<HalType, ChannelType, ChannelCount, List0Type>::init(HalType&) [with HalType = Hal; ChannelType = as::MotionChannel<Hal, 6>; int ChannelCount = 1; List0Type = as::List0]':

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:96:16:   required from here

E:\Arduino\libraries\AskSinPP-master/MultiChannelDevice.h:126:5: error: no matching function for call to 'Hal::init(as::HMID&)'

     hal.init(id);

     ^

E:\Arduino\libraries\AskSinPP-master/MultiChannelDevice.h:126:5: note: candidate is:

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:55:8: note: void Hal::init()

   void init () {

        ^

C:\Users\breger\AppData\Local\Temp\arduino_modified_sketch_657701\HM-SEC-MDIR.ino:55:8: note:   candidate expects 0 arguments, 1 provided

Mehrere Bibliotheken wurden für "Wire.h" gefunden
 Benutzt: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire
 Nicht benutzt: E:\Arduino\libraries\Wire
Bibliothek EnableInterrupt-0.9.7 in Version 0.9.5 im Ordner: E:\Arduino\libraries\EnableInterrupt-0.9.7  wird verwendet
Bibliothek AskSinPP-master im Ordner: E:\Arduino\libraries\AskSinPP-master (legacy) wird verwendet
Bibliothek TimerOne in Version 1.1 im Ordner: E:\Arduino\libraries\TimerOne  wird verwendet
Bibliothek Low-Power-master in Version 1.6 im Ordner: E:\Arduino\libraries\Low-Power-master  wird verwendet
Bibliothek TSL2561 im Ordner: E:\Arduino\libraries\TSL2561 (legacy) wird verwendet
Bibliothek Wire in Version 1.0 im Ordner: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire  wird verwendet
exit status 1
no matching function for call to 'Hal::init()'

Fehlen da noch spezielle Libraries?

Bitte das Example nochmal updaten. Da habe ich in der Lib noch eine Kleinigkeit umgebaut.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 28 August 2017, 21:14:24
Hallo,

ich versuche einen Temp Sensor zu bauen. Das AskSin++ Library Thema habe ich durchgelesen, aber wenn ich ehrlich bin: Ich habe keine Ahnung von der C++.
Mit dem Beispiel zur DHT.h und dem HM-WDS10-TH-O Sketch habe ich versucht es in gang zu bekommen. Aber es gelingt mir nicht. Vielleicht könnte mal jemand der Ahnung hat über den Code schauen. Ich weiß noch nichtmal ob der Pin für den DHT22 den ich angegeben habe der richtige ist.

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER

// define all device properties
#define DEVICE_ID HMID(0x34,0x56,0x78)
#define DEVICE_SERIAL "papa111111"
#define DEVICE_MODEL  0x00,0x3d
#define DEVICE_FIRMWARE 0x10
#define DEVICE_TYPE DeviceType::THSensor
#define DEVICE_INFO 0x01,0x01,0x00

#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include "DHT.h"

// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8
#define DHTPIN 6     // what digital pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302), AM2321
// Connect pin 1 (on the left) of the sensor to +5V
// NOTE: If using a board with 3.3V logic like an Arduino Due connect pin 1
// to 3.3V instead of 5V!
// Connect pin 2 of the sensor to whatever your DHTPIN is
// Connect pin 4 (on the right) of the sensor to GROUND
// Connect a 10K resistor from pin 2 (data) to pin 1 (power) of the sensor

// Initialize DHT sensor.
// Note that older versions of this library took an optional third parameter to
// tweak the timings for faster processors.  This parameter is no longer needed
// as the current DHT reading algorithm adjusts itself to work on faster procs.
DHT dht(DHTPIN, DHTTYPE);

// number of available peers per channel
#define PEERS_PER_CHANNEL 6


// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<4> LedType;
typedef AskSin<LedType,BatterySensor,RadioType> BaseHal;
class Hal : public BaseHal {
public:
  void init (const HMID& id) {
    BaseHal::init(id);
    // init real time clock - 1 tick per second
    rtc.init();
    // measure battery every 1h
    battery.init(60UL*60,rtc);
    battery.low(22);
    battery.critical(19);
  }

  bool runready () {
    return rtc.runready() || BaseHal::runready();
  }
} hal;

class WeatherEventMsg : public Message {
public:
  void init(uint8_t msgcnt,uint8_t temp,uint8_t humidity, bool batlow) {
    uint8_t t1 = (temp >> 8) & 0x7f;
    uint8_t t2 = temp & 0xff;
    if( batlow == true ) {
      t1 |= 0x80; // set bat low bit
    }
    Message::init(0xc,msgcnt,0x70,BIDI,t1,t2);
    pload[0] = humidity;
  }
};

class WeatherChannel : public Channel<Hal,List1,EmptyList,List4,PEERS_PER_CHANNEL>, public Alarm {

  WeatherEventMsg msg;
  int16_t         temp;
  uint8_t         humidity;
  uint16_t        millis;

public:
  WeatherChannel () : Channel(), Alarm(5), temp(0), humidity(0), millis(0) {}
  virtual ~WeatherChannel () {}

  virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
    // wait also for the millis
    if( millis != 0 ) {
      tick = millis2ticks(millis);
      millis = 0; // reset millis
      sysclock.add(*this); // millis with sysclock
    }
    else {
      uint8_t msgcnt = device().nextcount();
      measure();
      msg.init(msgcnt,temp,humidity,device().battery().low());
      device().sendPeerEvent(msg,*this);
//      device().send(msg,device().getMasterID());

      // reactivate for next measure
      HMID id;
      device().getDeviceID(id);
      uint32_t nextsend = delay(id,msgcnt);
      tick = nextsend / 1000; // seconds to wait
      millis = nextsend % 1000; // millis to wait
      rtc.add(*this);
    }
  }

  // here we do the measurement
  void measure () {
    temp = dht.readTemperature();
    humidity = dht.readHumidity();
  }
//  void measure () {
//    DPRINT("Measure...\n");
//    uint8_t;
//        float h = dht.readHumidity();
//  // Read temperature as Celsius (the default)
//  float t = dht.readTemperature();
//  temp = t;
//  humidity = h;
// 
//  }

  // here we calc when to send next value
  uint32_t delay (const HMID& id,uint8_t msgcnt) {
    uint32_t value = ((uint32_t)id) << 8 | msgcnt;
    value = (value * 1103515245 + 12345) >> 16;
    value = (value & 0xFF) + 480;
    value *= 250;

    DDEC(value / 1000);DPRINT(".");DDECLN(value % 1000);

    return value;
  }

  void setup(Device<Hal>* dev,uint8_t number,uint16_t addr) {
    Channel::setup(dev,number,addr);
    rtc.add(*this);
  Serial.begin(9600); //Serielle Verbindung starten
  dht.begin(); //DHT22 Sensor starten
  }

  uint8_t status () const {
    return 0;
  }

  uint8_t flags () const {
    return 0;
  }

};


typedef MultiChannelDevice<Hal,WeatherChannel,1> WeatherType;
WeatherType sdev(0x20);

ConfigButton<WeatherType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<SleepRTC>(hal);
  }
}

Auf einem Arduino habe ich über die Serielle Konsole mit dem Beispiel zur DHT.h eine Temp Ausgabe bekommen. Das war schon fast mein größter Erfolg.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 August 2017, 21:33:08
Hallo,

ich versuche einen Temp Sensor zu bauen. Das AskSin++ Library Thema habe ich durchgelesen, aber wenn ich ehrlich bin: Ich habe keine Ahnung von der C++.
Mit dem Beispiel zur DHT.h und dem HM-WDS10-TH-O Sketch habe ich versucht es in gang zu bekommen. Aber es gelingt mir nicht. Vielleicht könnte mal jemand der Ahnung hat über den Code schauen. Ich weiß noch nichtmal ob der Pin für den DHT22 den ich angegeben habe der richtige ist.

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER

// define all device properties
#define DEVICE_ID HMID(0x34,0x56,0x78)
#define DEVICE_SERIAL "papa111111"
#define DEVICE_MODEL  0x00,0x3d
#define DEVICE_FIRMWARE 0x10
#define DEVICE_TYPE DeviceType::THSensor
#define DEVICE_INFO 0x01,0x01,0x00

#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include "DHT.h"

// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8
#define DHTPIN 6     // what digital pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302), AM2321
// Connect pin 1 (on the left) of the sensor to +5V
// NOTE: If using a board with 3.3V logic like an Arduino Due connect pin 1
// to 3.3V instead of 5V!
// Connect pin 2 of the sensor to whatever your DHTPIN is
// Connect pin 4 (on the right) of the sensor to GROUND
// Connect a 10K resistor from pin 2 (data) to pin 1 (power) of the sensor

// Initialize DHT sensor.
// Note that older versions of this library took an optional third parameter to
// tweak the timings for faster processors.  This parameter is no longer needed
// as the current DHT reading algorithm adjusts itself to work on faster procs.
DHT dht(DHTPIN, DHTTYPE);

// number of available peers per channel
#define PEERS_PER_CHANNEL 6


// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<4> LedType;
typedef AskSin<LedType,BatterySensor,RadioType> BaseHal;
class Hal : public BaseHal {
public:
  void init (const HMID& id) {
    BaseHal::init(id);
    // init real time clock - 1 tick per second
    rtc.init();
    // measure battery every 1h
    battery.init(60UL*60,rtc);
    battery.low(22);
    battery.critical(19);
  }

  bool runready () {
    return rtc.runready() || BaseHal::runready();
  }
} hal;

class WeatherEventMsg : public Message {
public:
  void init(uint8_t msgcnt,uint8_t temp,uint8_t humidity, bool batlow) {
    uint8_t t1 = (temp >> 8) & 0x7f;
    uint8_t t2 = temp & 0xff;
    if( batlow == true ) {
      t1 |= 0x80; // set bat low bit
    }
    Message::init(0xc,msgcnt,0x70,BIDI,t1,t2);
    pload[0] = humidity;
  }
};

class WeatherChannel : public Channel<Hal,List1,EmptyList,List4,PEERS_PER_CHANNEL>, public Alarm {

  WeatherEventMsg msg;
  int16_t         temp;
  uint8_t         humidity;
  uint16_t        millis;

public:
  WeatherChannel () : Channel(), Alarm(5), temp(0), humidity(0), millis(0) {}
  virtual ~WeatherChannel () {}

  virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
    // wait also for the millis
    if( millis != 0 ) {
      tick = millis2ticks(millis);
      millis = 0; // reset millis
      sysclock.add(*this); // millis with sysclock
    }
    else {
      uint8_t msgcnt = device().nextcount();
      measure();
      msg.init(msgcnt,temp,humidity,device().battery().low());
      device().sendPeerEvent(msg,*this);
//      device().send(msg,device().getMasterID());

      // reactivate for next measure
      HMID id;
      device().getDeviceID(id);
      uint32_t nextsend = delay(id,msgcnt);
      tick = nextsend / 1000; // seconds to wait
      millis = nextsend % 1000; // millis to wait
      rtc.add(*this);
    }
  }

  // here we do the measurement
  void measure () {
    temp = dht.readTemperature();
    humidity = dht.readHumidity();
  }
//  void measure () {
//    DPRINT("Measure...\n");
//    uint8_t;
//        float h = dht.readHumidity();
//  // Read temperature as Celsius (the default)
//  float t = dht.readTemperature();
//  temp = t;
//  humidity = h;
// 
//  }

  // here we calc when to send next value
  uint32_t delay (const HMID& id,uint8_t msgcnt) {
    uint32_t value = ((uint32_t)id) << 8 | msgcnt;
    value = (value * 1103515245 + 12345) >> 16;
    value = (value & 0xFF) + 480;
    value *= 250;

    DDEC(value / 1000);DPRINT(".");DDECLN(value % 1000);

    return value;
  }

  void setup(Device<Hal>* dev,uint8_t number,uint16_t addr) {
    Channel::setup(dev,number,addr);
    rtc.add(*this);
  Serial.begin(9600); //Serielle Verbindung starten
  dht.begin(); //DHT22 Sensor starten
  }

  uint8_t status () const {
    return 0;
  }

  uint8_t flags () const {
    return 0;
  }

};


typedef MultiChannelDevice<Hal,WeatherChannel,1> WeatherType;
WeatherType sdev(0x20);

ConfigButton<WeatherType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<SleepRTC>(hal);
  }
}

Auf einem Arduino habe ich über die Serielle Konsole mit dem Beispiel zur DHT.h eine Temp Ausgabe bekommen. Das war schon fast mein größter Erfolg.

Ohne C++ Kenntinisse wird es natürlich schwer.
Ohne jetzt zu wissen, wie Deine Hardware aussieht, ist es schwer zu helfen. Vor allem wenn es um die Pinbelegung geht.

Aber das Example setzt einen externen 32,768kHz Quarz voraus, um damit das genaue Timing für die Nachrichten zu berechnen. Ich nehme mal an, der ist bei Dir nicht vorhanden. Es müssen somit alle "rtc" Objecte durch "sysclock" ersetzt werden. Sonst wäre es auch sehr praktisch, die Ausgaben der Serial-Console zu sehen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 August 2017, 21:35:44
Moin,
wie schauts mit meinen Änderungen aus?
Konntest du schon weiter testen?

Ich kann nur berichten, dass es seitdem 1a läuft  ;D

Ich habe jetzt mal Deine Radio.h eingespielt. Sieht erst mal soweit ganz gut aus. Lasse das mal ein paar Tage laufen. Dann muss ich noch prüfen (also den Stromverbrauch messen), ob das Funkmodul noch ordentlich in den Sleep geht.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 28 August 2017, 21:37:55
Hallo,

ich verwende die Platine des Fensterdrehgriffkontaktes und einen DHT22 Temp Sensor. Der Sensor ist an D6 der Platine angeschlossen, erstmal nur auf einem Steckbrett.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 August 2017, 21:51:32
ich verwende die Platine des Fensterdrehgriffkontaktes und einen DHT22 Temp Sensor. Der Sensor ist an D6 der Platine angeschlossen, erstmal nur auf einem Steckbrett.

Wenn das der extra Quarz nicht bestücjt ist, muss rtc durch sysclock ausgetauscht werden.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 28 August 2017, 22:01:43
Das ist doch schön zu hören.
An dem Sleepteil war ich aber glaub ich garnicht dran.
Da ging es eher darum, was passiert, wenn der CC1101 wieder aufgeweckt wird, weil alle Test-Register im Sleep ihren Wert verlieren und wieder neu geschrieben werden müssen.
Das einzige was man beim Sleep optimieren könnte, währe das flushen des RX da dies eh beim Sleep passiert.
Die Homematic Geräte warten ca 900ms vom Idle-Befehl zum Sleep-Befehl.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 August 2017, 09:22:56
Das ist doch schön zu hören.
An dem Sleepteil war ich aber glaub ich garnicht dran.
Da ging es eher darum, was passiert, wenn der CC1101 wieder aufgeweckt wird, weil alle Test-Register im Sleep ihren Wert verlieren und wieder neu geschrieben werden müssen.
Das einzige was man beim Sleep optimieren könnte, währe das flushen des RX da dies eh beim Sleep passiert.
Die Homematic Geräte warten ca 900ms vom Idle-Befehl zum Sleep-Befehl.

Naja - die Konfig-Register haben sich ja auch geändert. Und da weiss man dann nie, was da so noch passiert  :)
Auf jeden Fall lief gestern alles stabil. Muss ,a sehen, wann ich zum Messen komme.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 August 2017, 09:25:42
ich verwende die Platine des Fensterdrehgriffkontaktes und einen DHT22 Temp Sensor. Der Sensor ist an D6 der Platine angeschlossen, erstmal nur auf einem Steckbrett.

Du könntest aber auch das HM-WDS100-C6-O als Basis nehmen. Das hat ja auch Temperaturmessung und nutzt nur den "normalen" Timer.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 29 August 2017, 15:09:06
Hallo,

ich habe jetzt die Platine mit dem Quartz und den 2 Kondensatoren bestückt so das er diesen benutzen kann (ich hoffe der Funktioniert, kann man das irgendwie testen)
Ein list des Gerätes habe ich mal mit angehangen. Ca. alle 2,5 Min werden battery, state und temperature aktualisiert leider die beiden letzteren nur mit Wert 0.

Internals:
   CFGFN
   DEF        345678
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     1292
   NAME       HM_345678
   NOTIFYDEV  global
   NR         7770
   STATE      T: 0.0
   TYPE       CUL_HM
   lastMsg    No:07 - t:70 s:345678 d:190465 000000
   myHmUART_MSGCNT 1292
   myHmUART_RAWMSG 0501003D07A070345678190465000000
   myHmUART_RSSI -61
   myHmUART_TIME 2017-08-29 14:47:27
   protLastRcv 2017-08-29 14:47:27
   protResnd  1 last_at:2017-08-26 00:06:20
   protSnd    1244 last_at:2017-08-29 14:47:27
   protState  CMDs_done
   rssi_at_myHmUART avg:-52.85 cnt:1288 lst:-61 min:-81 max:-43
   READINGS:
     2017-08-29 14:36:04   Activity        alive
     2017-08-28 22:12:04   CommandAccepted yes
     2017-08-29 14:36:04   D-firmware      1.0
     2017-08-29 14:36:04   D-serialNr      papa111111
     2017-08-29 14:36:05   PairedTo        0x190465
     2017-08-28 22:12:04   R-pairCentral   0x190465
     2017-08-29 14:36:05   RegL_00.          02:01 0A:19 0B:04 0C:65 00:00
     2017-08-29 14:47:27   battery         ok
     2017-08-29 14:47:27   state           T: 0.0
     2017-08-29 14:47:27   temperature     0.0
   helper:
     HM_CMDNR   7
     PONtest    1
     cSnd       0119046534567800040000000000,011904653456780103
     mId        003D
     peerIDsRaw ,00000000
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +345678,00,00,00
       nextSend   1504010848.03751
       prefIO
       rxt        2
       vccu
       p:
         345678
         00
         00
         00
     mRssi:
       mNo        07
       io:
         myHmUART   -59
     prt:
       bErr       0
       sProc      0
       sleeping   1
       try        1
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
     rpt:
       IO         myHmUART
       flg        A
       ts         1504010847.74873
       ack:
         HASH(0x447f748)
         07800219046534567800
     rssi:
       at_myHmUART:
         avg        -52.8594720496894
         cnt        1288
         lst        -61
         max        -43
         min        -81
     shadowReg:
     tmpl:
Attributes:
   IODev      myHmUART
   IOgrp      vccu:myHmUART
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-WDS10-TH-O
   peerIDs    00000000,
   room       CUL_HM
   serialNr   papa111111
   subType    THSensor

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 August 2017, 16:42:09
Also wenn ca. alle 2,5 min die Werte aktualisiert werden, scheint doch schon mal das Grundgerüst zu funktionieren. Ich kenne die DHT Library nicht und kann deshalb nur schelcht sagen, warum die Temperatur immer 0 ist. Mach doch mal ein paar Ausgaben direkt nach der Messung in den Code und prüfe mit der Serial-Console, ob die Messung funktioniert.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 29 August 2017, 20:34:30
Hallo,

wie kann ich denn bei diesem Bord an die serielle Konsole kommen? wenn ich die in der Arduino IDE aufrufe bekomme ich nur folgende Meldung:
Das Board an /dev/cu.wchusbserial142140 ist nicht verfügbar
Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 August 2017, 20:48:22
An der linken, oberen Seite ist am ISP-Anschluß Tx & Rx sowie GND vorhanden.

Bei Dir im Code steht:
#define CONFIG_BUTTON_PIN 8
#define DHTPIN 6     // what digital pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302), AM2321
// Connect pin 1 (on the left) of the sensor to +5V
// NOTE: If using a board with 3.3V logic like an Arduino Due connect pin 1
// to 3.3V instead of 5V!
// Connect pin 2 of the sensor to whatever your DHTPIN is
// Connect pin 4 (on the right) of the sensor to GROUND
// Connect a 10K resistor from pin 2 (data) to pin 1 (power) of the sensor

Hast Du auch den 10K Widerstand zwischen Data & Power ? Möglicherweise gibt es Probleme mit der Kommunikation.
Wie ist die Spannungsversorgung ?
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 29 August 2017, 21:23:23
Hallo,

ich habe noch etwas probiert und eine Zeile die ich auskommentiert hatte wieder aktiviert.
DPRINT("Measure...\n");jetzt kommen werte für temp und humidity aber bei der Temp zeigt er 2,5 grad wo es eher 25 sein sollten.
Den Widerstand habe ich und Spannung kommt vom Bord.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 August 2017, 21:44:27
ich habe noch etwas probiert und eine Zeile die ich auskommentiert hatte wieder aktiviert.
DPRINT("Measure...\n");jetzt kommen werte für temp und humidity aber bei der Temp zeigt er 2,5 grad wo es eher 25 sein sollten.
Den Widerstand habe ich und Spannung kommt vom Bord.

Das ist aber nur eine Debug-Ausgabe auf der Serial-Console. Vielleicht gibt es irgendein Timing-Problem.
Die Werte werden in 0,1° übertragen. Du musst also den gemessenen Wert noch mit 10 multiplizieren.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 31 August 2017, 18:46:59
Hallo,

ich habe nun verschiedenes probiert, und bekomme Daten angezeigt. Aber immer wieder zwischendurch ist die Temp 0 in unregelmäßigen abständen.
Hier der jetzt verwendete Sketch.
//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER

// define all device properties
#define DEVICE_ID HMID(0x34,0x56,0x78)
#define DEVICE_SERIAL "papa111111"
#define DEVICE_MODEL  0x00,0x3d
#define DEVICE_FIRMWARE 0x10
#define DEVICE_TYPE DeviceType::THSensor
#define DEVICE_INFO 0x01,0x01,0x00

#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include "DHT.h"

// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8
#define DHTPIN 6     // what digital pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302), AM2321
// Connect pin 1 (on the left) of the sensor to +5V
// NOTE: If using a board with 3.3V logic like an Arduino Due connect pin 1
// to 3.3V instead of 5V!
// Connect pin 2 of the sensor to whatever your DHTPIN is
// Connect pin 4 (on the right) of the sensor to GROUND
// Connect a 10K resistor from pin 2 (data) to pin 1 (power) of the sensor

// Initialize DHT sensor.
// Note that older versions of this library took an optional third parameter to
// tweak the timings for faster processors.  This parameter is no longer needed
// as the current DHT reading algorithm adjusts itself to work on faster procs.
DHT dht(DHTPIN, DHTTYPE);

// number of available peers per channel
#define PEERS_PER_CHANNEL 6


// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<4> LedType;
typedef AskSin<LedType,BatterySensor,RadioType> BaseHal;
class Hal : public BaseHal {
public:
  void init (const HMID& id) {
    BaseHal::init(id);
    // init real time clock - 1 tick per second
    rtc.init();
    // measure battery every 1h
    battery.init(60UL*60,rtc);
    battery.low(22);
    battery.critical(19);
  }

  bool runready () {
    return rtc.runready() || BaseHal::runready();
  }
} hal;

class WeatherEventMsg : public Message {
public:
  void init(uint8_t msgcnt,uint16_t temp,uint8_t humidity, bool batlow) {
    uint8_t t1 = (temp >> 8) & 0x7f;
    uint8_t t2 = temp & 0xff;
    if( batlow == true ) {
      t1 |= 0x80; // set bat low bit
    }
    Message::init(0xc,msgcnt,0x70,BIDI,t1,t2);
    pload[0] = humidity;
  }
};

class WeatherChannel : public Channel<Hal,List1,EmptyList,List4,PEERS_PER_CHANNEL>, public Alarm {

  WeatherEventMsg msg;
uint16_t        temp;
uint8_t         humidity;
  uint16_t        millis;

public:
  WeatherChannel () : Channel(), Alarm(5), temp(0), humidity(0), millis(0) {}
  virtual ~WeatherChannel () {}

  virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
    // wait also for the millis
    if( millis != 0 ) {
      tick = millis2ticks(millis);
      millis = 0; // reset millis
      sysclock.add(*this); // millis with sysclock
    }
    else {
      uint8_t msgcnt = device().nextcount();
      measure();
      msg.init(msgcnt,temp,humidity,device().battery().low());
      device().sendPeerEvent(msg,*this);
//      device().send(msg,device().getMasterID());

      // reactivate for next measure
      HMID id;
      device().getDeviceID(id);
      uint32_t nextsend = delay(id,msgcnt);
      tick = nextsend / 2000; // seconds to wait
      millis = nextsend % 1000; // millis to wait
      rtc.add(*this);
    }
  }

  // here we do the measurement
void measure () {
  Serial.begin(9600); //Serielle Verbindung starten
  dht.begin(); //DHT22 Sensor starten
    DPRINT("Measure...\n");
   float temperature = 0;
  float humidity = 0;
  float h = dht.readHumidity();
  // Read temperature as Celsius (the default)
  float t = dht.readTemperature();
   if (isnan(h) || isnan(t)){
    Serial.println("Failed to read from DHT sensor!");
    float h = dht.readHumidity();
  // Read temperature as Celsius (the default)
  float t = dht.readTemperature();
//    loop ();
  }
  temp = t*10;
  humidity = h;
}
  // here we calc when to send next value
  uint32_t delay (const HMID& id,uint8_t msgcnt) {
    uint32_t value = ((uint32_t)id) << 8 | msgcnt;
    value = (value * 1103515245 + 12345) >> 16;
    value = (value & 0xFF) + 480;
    value *= 250;

    DDEC(value / 1000);DPRINT(".");DDECLN(value % 1000);

    return value;
  }

  void setup(Device<Hal>* dev,uint8_t number,uint16_t addr) {
    Channel::setup(dev,number,addr);
    rtc.add(*this);
  }

  uint8_t status () const {
    return 0;
  }

  uint8_t flags () const {
    return 0;
  }

};


typedef MultiChannelDevice<Hal,WeatherChannel,1> WeatherType;
WeatherType sdev(0x20);

ConfigButton<WeatherType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<SleepRTC>(hal);
  }
 
}

Bei der DHT.h Bibliotek ist zb. folgender Sketch als Beispiel dabei aus dem ich mich bedient habe.
// DHT Temperature & Humidity Sensor
// Unified Sensor Library Example
// Written by Tony DiCola for Adafruit Industries
// Released under an MIT license.

// Depends on the following Arduino libraries:
// - Adafruit Unified Sensor Library: https://github.com/adafruit/Adafruit_Sensor
// - DHT Sensor Library: https://github.com/adafruit/DHT-sensor-library

#include <Adafruit_Sensor.h>
#include <DHT.h>
#include <DHT_U.h>

#define DHTPIN            2         // Pin which is connected to the DHT sensor.

// Uncomment the type of sensor in use:
//#define DHTTYPE           DHT11     // DHT 11
#define DHTTYPE           DHT22     // DHT 22 (AM2302)
//#define DHTTYPE           DHT21     // DHT 21 (AM2301)

// See guide for details on sensor wiring and usage:
//   https://learn.adafruit.com/dht/overview

DHT_Unified dht(DHTPIN, DHTTYPE);

uint32_t delayMS;

void setup() {
  Serial.begin(9600);
  // Initialize device.
  dht.begin();
  Serial.println("DHTxx Unified Sensor Example");
  // Print temperature sensor details.
  sensor_t sensor;
  dht.temperature().getSensor(&sensor);
  Serial.println("------------------------------------");
  Serial.println("Temperature");
  Serial.print  ("Sensor:       "); Serial.println(sensor.name);
  Serial.print  ("Driver Ver:   "); Serial.println(sensor.version);
  Serial.print  ("Unique ID:    "); Serial.println(sensor.sensor_id);
  Serial.print  ("Max Value:    "); Serial.print(sensor.max_value); Serial.println(" *C");
  Serial.print  ("Min Value:    "); Serial.print(sensor.min_value); Serial.println(" *C");
  Serial.print  ("Resolution:   "); Serial.print(sensor.resolution); Serial.println(" *C"); 
  Serial.println("------------------------------------");
  // Print humidity sensor details.
  dht.humidity().getSensor(&sensor);
  Serial.println("------------------------------------");
  Serial.println("Humidity");
  Serial.print  ("Sensor:       "); Serial.println(sensor.name);
  Serial.print  ("Driver Ver:   "); Serial.println(sensor.version);
  Serial.print  ("Unique ID:    "); Serial.println(sensor.sensor_id);
  Serial.print  ("Max Value:    "); Serial.print(sensor.max_value); Serial.println("%");
  Serial.print  ("Min Value:    "); Serial.print(sensor.min_value); Serial.println("%");
  Serial.print  ("Resolution:   "); Serial.print(sensor.resolution); Serial.println("%"); 
  Serial.println("------------------------------------");
  // Set delay between sensor readings based on sensor details.
  delayMS = sensor.min_delay / 1000;
}

void loop() {
  // Delay between measurements.
  delay(delayMS);
  // Get temperature event and print its value.
  sensors_event_t event; 
  dht.temperature().getEvent(&event);
  if (isnan(event.temperature)) {
    Serial.println("Error reading temperature!");
  }
  else {
    Serial.print("Temperature: ");
    Serial.print(event.temperature);
    Serial.println(" *C");
  }
  // Get humidity event and print its value.
  dht.humidity().getEvent(&event);
  if (isnan(event.relative_humidity)) {
    Serial.println("Error reading humidity!");
  }
  else {
    Serial.print("Humidity: ");
    Serial.print(event.relative_humidity);
    Serial.println("%");
  }
}

Die Serielle Konsole habe ich noch nicht geprüft da ich noch auf den Bestellten Adapter warte.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 31 August 2017, 20:18:50
Zeigt denn das Beispiel immer Werte an ?
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 31 August 2017, 20:25:36
Hallo,

Das habe ich leider noch nicht ausprobiert, aber das habe ich noch vor aber da muß der Computer die ganze Zeit laufen da ja kein Log geschrieben wird.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 September 2017, 09:30:53
Ich habe im Git einen V2 Branch eröffnet. Diese sollte jetzt für Eigenentwicklungen genutzt werden. Im Master werde ich wohl noch ein paar größere Umbauten machen. Dabei wird es sicherlich auch zu Inkompatibilitäten mit den existierenden Sketches kommen.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 01 September 2017, 10:08:15
Aber immer wieder zwischendurch ist die Temp 0 in unregelmäßigen abständen.
wundert mich nicht ... du gibst zwar ne Meldung auf der Seriellen aus das der Wert nicht gelesen werden konnte, reagierst aber nicht darauf und überschreibst trotzdem die alten Variablen. Ich würde das Messen so machen (ungetestet da ich hier keinen Compiler habe )
void measure ()
{
  DPRINT("Measure...\n");
  float t = dht.readTemperature();
  if  (isnan(t))
  {
    DPRINT("Failed to read Temperature\n");
    // warten und nochmal versuchen
    delay(5);
    t = dht.readTemperature();
    if  (isnan(t)) { DPRINT("No new Temperature\n"); }
    else { temp = t*10; }
   } else { temp = t*10; }
   
  float h = dht.readHumidity();
   if  (isnan(h))
   {
    DPRINT("Failed to read Humidity\n");
    // warten und nochmal versuchen
    delay(5);
    h = dht.readHumidity();
    if  (isnan(h)) { DPRINT("No new Humidity\n"); }
    else { humidity = h; }
   } else { humidity = h; }
}
D.h. lieber den alten Wert wieder schicken als einen falschen bzw. 0

Als Zweites suche mal im Netz nach der DHT lib. Es gibt davon verschiedene Versionen. Ich hatte irgendwann mal eine recht neue gefunden die intern andere Timingwerte benutzte.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 03 September 2017, 14:22:20
Hallo,

ich habe noch etwas mit der Firmware für den Temp.Sensor probiert. Wie gesagt ich habe von c++ so gut wie keine Ahnung. Ich bin auch auf ein paar Probleme gestoßen die ich mir nicht erklären kann.
//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER

// define all device properties
#define DEVICE_ID HMID(0x34,0x56,0x78)
#define DEVICE_SERIAL "papa111111"
#define DEVICE_MODEL  0x00,0x3d
#define DEVICE_FIRMWARE 0x10
#define DEVICE_TYPE DeviceType::THSensor
#define DEVICE_INFO 0x01,0x01,0x00

#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <TimerOne.h>
#include <LowPower.h>

#include <MultiChannelDevice.h>
#include <DHT.h>

// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED_PIN 4
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8
#define DHTPIN 6     // what digital pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302), AM2321
// Connect pin 1 (on the left) of the sensor to +5V
// NOTE: If using a board with 3.3V logic like an Arduino Due connect pin 1
// to 3.3V instead of 5V!
// Connect pin 2 of the sensor to whatever your DHTPIN is
// Connect pin 4 (on the right) of the sensor to GROUND
// Connect a 10K resistor from pin 2 (data) to pin 1 (power) of the sensor

// Initialize DHT sensor.
// Note that older versions of this library took an optional third parameter to
// tweak the timings for faster processors.  This parameter is no longer needed
// as the current DHT reading algorithm adjusts itself to work on faster procs.
DHT dht(DHTPIN, DHTTYPE);

// number of available peers per channel
#define PEERS_PER_CHANNEL 6


// all library classes are placed in the namespace 'as'
using namespace as;

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<4> LedType;
typedef AskSin<LedType,BatterySensor,RadioType> BaseHal;
class Hal : public BaseHal {
public:
  void init (const HMID& id) {
    BaseHal::init(id);
    // init real time clock - 1 tick per second
    rtc.init();
    // measure battery every 1h
    battery.init(60UL*60,rtc);
    battery.low(22);
    battery.critical(19);
  }

  bool runready () {
    return rtc.runready() || BaseHal::runready();
  }
} hal;

class WeatherEventMsg : public Message {
public:
  void init(uint8_t msgcnt,uint16_t temp,uint8_t humidity, bool batlow) {
    uint8_t t1 = (temp >> 8) & 0x7f;
    uint8_t t2 = temp & 0xff;
    if( batlow == true ) {
      t1 |= 0x80; // set bat low bit
    }
    Message::init(0xc,msgcnt,0x70,BIDI,t1,t2);
    pload[0] = humidity;
  }
};

class WeatherChannel : public Channel<Hal,List1,EmptyList,List4,PEERS_PER_CHANNEL>, public Alarm {

  WeatherEventMsg msg;
uint16_t        temp;
uint8_t         humidity;
  uint16_t        millis;

public:
  WeatherChannel () : Channel(), Alarm(5), temp(0), humidity(0), millis(0) {}
  virtual ~WeatherChannel () {}

  virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
    // wait also for the millis
    if( millis != 0 ) {
      tick = millis2ticks(millis);
      millis = 0; // reset millis
      sysclock.add(*this); // millis with sysclock
    }
    else {
      uint8_t msgcnt = device().nextcount();
      measure();
      msg.init(msgcnt,temp,humidity,device().battery().low());
      device().sendPeerEvent(msg,*this);
//      device().send(msg,device().getMasterID());

      // reactivate for next measure
      HMID id;
      device().getDeviceID(id);
      uint32_t nextsend = delay1(id,msgcnt);
      tick = nextsend / 2000; // seconds to wait
      millis = nextsend % 1000; // millis to wait
      rtc.add(*this);
    }
  }

//   here we do the measurement
void measure () {
  Neumessen:
    DPRINT("Measure...\n");
  float h = dht.readHumidity();
  // Read temperature as Celsius (the default)
  float t = dht.readTemperature();
  delay(2000);
  if (isnan(h) || isnan(t)){
    DPRINT("Fehler Measure...neu\n");
  goto Neumessen;
  }
  temp = t*10;
  humidity = h;
  Serial.print("Humidity: ");
  Serial.print(h);
  Serial.print(" %\t");
  Serial.print("Temperature: ");
  Serial.print(t);
  }
   

  // here we calc when to send next value
  uint32_t delay1 (const HMID& id,uint8_t msgcnt) {
    uint32_t value = ((uint32_t)id) << 8 | msgcnt;
    value = (value * 1103515245 + 12345) >> 16;
    value = (value & 0xFF) + 480;
    value *= 250;

    DDEC(value / 1000);DPRINT(".");DDECLN(value % 1000);

    return value;
  }

  void setup(Device<Hal>* dev,uint8_t number,uint16_t addr) {
    Channel::setup(dev,number,addr);
    rtc.add(*this);
  Serial.begin(9600); //Serielle Verbindung starten
  dht.begin(); //DHT22 Sensor starten
  }

  uint8_t status () const {
    return 0;
  }

  uint8_t flags () const {
    return 0;
  }

};


typedef MultiChannelDevice<Hal,WeatherChannel,1> WeatherType;
WeatherType sdev(0x20);

ConfigButton<WeatherType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
}

void loop() {
 
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<SleepRTC>(hal);
  }
 
}
Das ist die jetzige Variante die halbwegs Funktioniert. Bei der Messung habe ich nach der Auswertung und feststellen eines Fehlers einen Sprung zurück eingefügt. Da wird dann aber sehr oft hintereinander gemessen (10-12 mal) laut Beschreibung ist der Sensor aber nur alle 2 Sekunden bereit. Also wollte ich eine Verzögerung einbauen, aber der Name für die Funktion delay() wurde im code schon für irgend eine andere Sache benutzt so das ich immer nur einen Fehler bekam. Dann habe ich den Namen an den anderen Stellen im Code geändert so das er jetzt delay benutzt. Es scheint soweit alles zu gehen aber vielleicht habe ich auch etwas anders gestört ist mir aber noch nicht aufgefallen. Die Messungen werden jetzt noch max. 1-2 mal wiederholt. Über die Serielle Schnittstelle kann ich das gut beobachten.

Vielleicht könnte ja noch mal jemand schauen das ich nicht doch einen groben Schnitzer gemacht habe.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 September 2017, 19:29:23
Damit machst DU das ganze Timing kaputt. Der HM-WDS10-TH-O sendet zu festen Zeitfenstern, welche durch die ID bestimmt werden. Wenn Du das nicht brauchst, dsa Du z.B kein Thermostat gepeert hast, kannst Du natürlich die Messung nach einer kurzen Zeit wiederholen. Ich würde es dann aber wie folgt machen:

measure() gibt TRUE oder FALSE zurück, je nachdem, ob es geklappt hat oder nicht. Bei TRUE wird die Nachricht geschickt und der Timer neu berechnet. Bei FALSE wird keine Nachricht geschickt und der Timer wird auf 2 Sekunden gesetzt.

virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
    // wait also for the millis
    if( millis != 0 ) {
      tick = millis2ticks(millis);
      millis = 0; // reset millis
      sysclock.add(*this); // millis with sysclock
    }
    else {
      if( measure() == true ) {
        uint8_t msgcnt = device().nextcount();
        msg.init(msgcnt,temp,humidity,device().battery().low());
        device().sendPeerEvent(msg,*this);
//        device().send(msg,device().getMasterID());

        // reactivate for next measure
        HMID id;
        device().getDeviceID(id);
        uint32_t nextsend = delay(id,msgcnt);
        tick = nextsend / 1000; // seconds to wait
        millis = nextsend % 1000; // millis to wait
      }
      else {
        tick = 2; // 2 seconds
        millis = 0;
      }
      rtc.add(*this);
    }
  }

//   here we do the measurement
void measure () {
  DPRINT("Measure...\n");
  float h = dht.readHumidity();
  // Read temperature as Celsius (the default)
  float t = dht.readTemperature();
  if (isnan(h) || isnan(t)){
    DPRINT("Fehler Measure...neu\n");
    return false;
  }
  temp = t*10;
  humidity = h;
  Serial.print("Humidity: ");
  Serial.print(h);
  Serial.print(" %\t");
  Serial.print("Temperature: ");
  Serial.print(t);
  return true;
  }
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 03 September 2017, 20:07:44
Hallo,

leider bricht er mit Fehlermeldung ab:
invalid operands of types 'void' and 'bool' to binary 'operator=='auf die Zeileif( measure() == true ) {bezogen.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 September 2017, 20:58:20
Ups

//   here we do the measurement
bool measure () {
  DPRINT("Measure...\n");
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 03 September 2017, 21:20:12
Hallo,

leider nicht viel besser.

too many arguments to function 'void delay(long unsigned int)'
Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 September 2017, 22:06:23
Du hast mein delay umbenannt. Bitte zurück änderm.

Sei mir nicht böse, aber ich habe keine Zeit um bei trivialen C++ Fehlern zu helfen. Bitte verusche Dich in die Sprache einzuarbeiten. Es gibt genug Quellen.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 03 September 2017, 22:40:18
Ups,

da hast Du natürlich recht. Noch mal Danke.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 September 2017, 07:51:51
Geht es denn jetzt ?
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 04 September 2017, 14:54:14
Hallo,

Es geht, aber zufrieden bin ich noch nicht so richtig. Wenn der Fehler beim Datenholen auftritt dann sind meist 10 oder mehr Wiederholungen nötig. Auch Zweifel ich manchmal an den Daten, aber vielleicht liegt es auch an meinem Versuchsaufbau mit Steckbrett.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 06 September 2017, 21:08:25
Hallo,

ich habe versucht ein OTA-Firmware zu erstellen, aber leider bricht er immer ab.
/Users/rolf2/Downloads/ota/prepareforota.sh /Users/rolf2/Documents/Arduino/HM-WDS10-TH-O-DHT22-neu/HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.hex
++ date +%Y%m%d%H%M
+ QUAL=201709062105
+ FILE=/Users/rolf2/Documents/Arduino/HM-WDS10-TH-O-DHT22-neu/HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.hex
++ basename /Users/rolf2/Documents/Arduino/HM-WDS10-TH-O-DHT22-neu/HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.hex
+ NAME=HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.hex
++ basename /Users/rolf2/Documents/Arduino/HM-WDS10-TH-O-DHT22-neu/HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.hex .hex
+ BIN=HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.bin
++ basename /Users/rolf2/Documents/Arduino/HM-WDS10-TH-O-DHT22-neu/HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.hex .hex
+ EQ3=HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard_201709062105.eq3
+ cp /Users/rolf2/Documents/Arduino/HM-WDS10-TH-O-DHT22-neu/HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.hex HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.hex
+ ./srecord/srec_cat.exe HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.hex -intel -fill 0xFF 0x0000 0x6FFE -Cyclic_Redundancy_Check_16_Little_Endian 0x6FFE -o HM-WDS10-TH-O-DHT22-neu.ino.32PinBoard.bin -binary
/Users/rolf2/Downloads/ota/prepareforota.sh: line 10: ./srecord/srec_cat.exe: No such file or directory

funktioniert das auf dem Mac nicht, muss ich das unter windows ausführen?

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 06 September 2017, 21:59:08
Ja - das "srec_cat" Tool wird benötigt. Für Windows ist es mit eingecheckt.

Du kannst aber auch das neue prepota.sh verwenden. Das läuft komplett in der bash - ist aber sehr langsam.

prepota.sh your.hex > your.eq3
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 06 September 2017, 22:43:42
Ja danke, scheint zu funktionieren ist Durchgelaufen und hat eine Datei erstellt.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 11 September 2017, 12:58:11
Hallo,

wäre es denkbar, die Library auf dem ESP8266 laufen zu lassen?

Hintergrund:
Es gibt sehr günstig diese SONOFF Wifi Module bzw. 433Mhz Aktoren (welche freie IO´s zum 433Mhz Platinchen hätten).
Diese enthalten schon ein 230V Netzteil und ein 10A? Relais, den ESP8266 Wifi Chip, welcher von Arduino unterstützt wird, eine interne 3,3V Versorgung ist auch vorhanden.
Nun könnte man ein CC1101 Modul an freien I/O´s anschliessen und fertig wäre der Homematic Aktor für 10€ ;D.

Diverse inc. Schaltpläne usw.: https://wiki.fhem.de/wiki/Sonoff
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 September 2017, 13:48:15
Hallo,

wäre es denkbar, die Library auf dem ESP8266 laufen zu lassen?

Hintergrund:
Es gibt sehr günstig diese SONOFF Wifi Module bzw. 433Mhz Aktoren (welche freie IO´s zum 433Mhz Platinchen hätten).
Diese enthalten schon ein 230V Netzteil und ein 10A? Relais, den ESP8266 Wifi Chip, welcher von Arduino unterstützt wird, eine interne 3,3V Versorgung ist auch vorhanden.
Nun könnte man ein CC1101 Modul an freien I/O´s anschliessen und fertig wäre der Homematic Aktor für 10€ ;D.

Diverse inc. Schaltpläne usw.: https://wiki.fhem.de/wiki/Sonoff

Theoretisch geht das bestimmt, wenn die Libraries verfügbar sind. Außerdem müssen die IO-Pins für das Funkmodul SPI können.
Aber die Teile lassen sich doch schon sehr schön in FHEM einbinden.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 11 September 2017, 18:07:30
Also ich fände das schon interessant.
Habe 2 Stück bestellt und wollte da dann das EasyESP installieren und die Dosen über HTTP steuern.
Direkt im Homematic währe natürlich noch besser.

Sobald die da sind kann ich das ja mal ausprobieren.
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 13 September 2017, 12:39:07
Ich habe nun mal den LC-SW4 ausprobiert auf dem Arduino. Das funktioniert soweit.
Problem war, dass ich schwierigkeiten hatten einen zweiten anzumelden. Beide hatten unterschiedliche "DEVICE_SERIAL" Nummern.
Erst nach dem löchen des ersten konnte ich den zweiten anmelden.

#define DEVICE_ID HMID(0x12,0x34,0x56)
#define DEVICE_SERIAL "papa000000"
#define DEVICE_MODEL  HM_LC_SW4_SM
#define DEVICE_FIRMWARE 0x16
#define DEVICE_TYPE DeviceType::Switch
#define DEVICE_INFO 0x04,0x01,0x00
#define DEVICE_CONFIG CFG_LOWACTIVE_OFF

Frage: Was muss ggf. neben der DEVICE_SERIAL ggf. noch geändert werden um eindeutige Geräte zu erzeugen?
Gibt es eine Anleitung wie der Bootloader und die "makeota.html" zu verwenden ist?

Grüße,
Jochen
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 September 2017, 13:18:28
Die DEVICE_ID muss ebenfalls unterschiedlich sein.

Im Verzeichnis bootloader/avr gibt es ein Readme
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 14 September 2017, 12:18:04
Mit der geänderten DEVICE_ID HMID funktionieren beide nebeneinander.

Um Eingänge einzulesen (PIR, Türkontakte usw.) wollte ich mir noch einen MH-RC-8 aufbauen und habe den Code aus dem V2 Branch geflasht.
Die Anmeldung in der CCU2 hat funktioniert, jedoch habe ich keine Tastendrücke auf der CCU2 Gui angezeigt bekommen.
Die Status LED hat beim Tastendrücken aufgeblitzt, d.h. es sollte auch etwas gesendet worden sein.

Was kann ich hier noch überprüfen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 September 2017, 15:46:07
Mit der geänderten DEVICE_ID HMID funktionieren beide nebeneinander.

Um Eingänge einzulesen (PIR, Türkontakte usw.) wollte ich mir noch einen MH-RC-8 aufbauen und habe den Code aus dem V2 Branch geflasht.
Die Anmeldung in der CCU2 hat funktioniert, jedoch habe ich keine Tastendrücke auf der CCU2 Gui angezeigt bekommen.
Die Status LED hat beim Tastendrücken aufgeblitzt, d.h. es sollte auch etwas gesendet worden sein.

Was kann ich hier noch überprüfen?

Bitte mal die seriellen Ausgaben ansehen. Dort sollte eigentlich zu sehen sein, was gesendet und empfangen wird.
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 14 September 2017, 21:06:41
Bitte mal die seriellen Ausgaben ansehen. Dort sollte eigentlich zu sehen sein, was gesendet und empfangen wird.

Hallo,

hier die serielle Ausgabe:

AskSin++ V2.0.0 (Sep 14 2017 20:56:44)
Address Space: 32 - 540
CC init1
CC Version: 14
 - ready
Bat: 34
05 debounce
05 pressed
05 longpressed
<- 0B 01 A2 40 00DA00 298A57 45 00  - 401
-> 11 01 A0 02 298A57 00DA00 04 BC 13 28 C9 98 CF 00  - 571
waitAck: 01
05 longreleased
05
05 debounce
05 pressed
05 released
<- 0B 02 A2 40 00DA00 298A57 05 01  - 1081
-> 11 02 A0 02 298A57 00DA00 04 48 CE 67 82 D3 32 00  - 1247
waitAck: 01
05
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 September 2017, 22:28:34
Die Antwort von der CCU2 sieht komisch aus. Vielleicht ist das Gerät noch nicht vollständig gepairt. Drück doch mal den Konfig-Button.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 September 2017, 05:36:52
Könnte es vielleicht sein dass in der CCU die Kanäle noch auf Gesichert stehen?
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 15 September 2017, 09:05:59
So, ich habe gestern noch etwas rumprobiert:

RC8: Habe das Device aus der CCU gelöscht und neu angemeldet, anmelden geht, Tastendrücke bekomme ich keine.
SW4: Anmelden geht, Schalten geht.
MDIR: Fehler beim kompilieren an der Stelle "TSL2561 light;" - habe die TSL Library von Adafruit und die von Sparkfun installiert, welche wäre hier die richtige?
MDIR-WM55: keine Anmeldung möglich, nicht über den Button und nicht über die Seriennummer... (TSLxx wird hier für die Helligkeit nicht verwendet ?)



 
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 September 2017, 09:16:09
Schau mal in der CCU nach ob die Kanäle für die Taster noch auf "Gesichert" stehen.
Das gleiche musst du dann auch bei dem PiR machen.

Wegen des Compilerfehlers hatte ich schonmal nen Pullrequest gemacht.
Hab jetzt auch einen Lichtsensor hier. Könnte das also auch mal testen ob das so funktioniert.

Hab jetzt auch meine Sonoff Stecker hier und hab mir auch schon das Datenblatt angeschaut.
Soweit ich das richtig gesehen habe werden zwei Ausgänge vom SPI schon verwendet. Einmal als Tastereingang und einen als Ausgang für die grüne LED.
Denke mal dass die LED kein Problem ist.
Beim Taster könnte man vielleicht vorm senden oder empfangen den Modus des Pins ändern.
Weiß nicht wie es damit aussieht das der PIN auf High gezogen wird mit nem Widerstand. 
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 September 2017, 09:37:12
Das Zusammenspiel mit der CCU kann ich nicht testen. Ich verwende nur FHEM.

Es kann schon sein, dass in der einen oder anderen DeviceInfo-Message eines Examples irgendwas nicht passt. FHEM ist da glaube ich sehr großzügig. Die CCU könnte da etwas genauer sein. Gegebenenfalls bräuchten wir hierfür mal ein paar Datenmitschnitte der originalen Sensoren. Zur Entwicklung habe ich nur die XML-Beschreibungen, welche diese Infos nicht beinhalten.

Wegen dem Lichtsensor musst Du mal in den Pullrequest von Xent schauen. Ich habe hier irgend eine alte Version der TSL-Lib, welche aus einem anderen Projekt (Universalsensor) stammt. Für Sensoren habe ich schon ein paar Ideen, wie diese möglichst flexibel in die Lib zu integrieren sind. Das dauert aber sicherlich noch etwas und wird dann auch nicht mehr für V2 gemacht.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 September 2017, 10:30:16
Hab jetzt auch meine Sonoff Stecker hier und hab mir auch schon das Datenblatt angeschaut.
Soweit ich das richtig gesehen habe werden zwei Ausgänge vom SPI schon verwendet. Einmal als Tastereingang und einen als Ausgang für die grüne LED.
Denke mal dass die LED kein Problem ist.
Beim Taster könnte man vielleicht vorm senden oder empfangen den Modus des Pins ändern.
Weiß nicht wie es damit aussieht das der PIN auf High gezogen wird mit nem Widerstand.

Also wenn ich das richtig sehen, kann die Arduino ESP8266 SPI-Lib mit 2 unterschiedlichen Pin-Konfigurationen arbeiten. Vielleicht passt es ja doch.

https://github.com/esp8266/Arduino/blob/master/libraries/SPI/SPI.cpp (https://github.com/esp8266/Arduino/blob/master/libraries/SPI/SPI.cpp)
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 September 2017, 10:48:01
Beim SPI_PINS_HSPI_OVERLAP sollten ja die Pins verwendet werden, die auch den Flash ansprechen.
Dort könnte man auch einfacher dran als an die anderen.
Müsste man sich nur noch einen Pin für den CSn raussuchen.
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 16 September 2017, 19:33:55
Das Zusammenspiel mit der CCU kann ich nicht testen. Ich verwende nur FHEM.

Es kann schon sein, dass in der einen oder anderen DeviceInfo-Message eines Examples irgendwas nicht passt. FHEM ist da glaube ich sehr großzügig. Die CCU könnte da etwas genauer sein. Gegebenenfalls bräuchten wir hierfür mal ein paar Datenmitschnitte der originalen Sensoren. Zur Entwicklung habe ich nur die XML-Beschreibungen, welche diese Infos nicht beinhalten.

Wegen dem Lichtsensor musst Du mal in den Pullrequest von Xent schauen. Ich habe hier irgend eine alte Version der TSL-Lib, welche aus einem anderen Projekt (Universalsensor) stammt. Für Sensoren habe ich schon ein paar Ideen, wie diese möglichst flexibel in die Lib zu integrieren sind. Das dauert aber sicherlich noch etwas und wird dann auch nicht mehr für V2 gemacht.

Gibt es eine Möglichkeit an die Deviceinfos heranzukommen? Liegen die evtl. als XML Dateien vor, welche evtl. im CCU2 Image oder im RaspberryMatic Image / Source enthalten sind?

Die RC-8 habe ich zwar nicht aber z.B. ein original 8-fach Sendemodul. Wie könnte man einen Datenmitschnitt erstellen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 September 2017, 19:59:32
Ich habe mir die Antwort gerade nochmal in Ruhe angesehen. Die CCU antwortet mit einer AES-Challange. Die CCU hat scheinbar AES standardmäßig für den HM.RC-8 aktiviert, Du musst so wir im Readme geschrieben AES beim kompilieren aktivieren.

Wie man den Key kriegt, steht hier (https://forum.fhem.de/index.php/topic,57486.msg607157.html#msg607157).

Für die anderen Geräte bräuchte man mal die Pair-Messages von einem originalen Gerät. Möglicherweise hilft hier aber auch AES an.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 September 2017, 20:25:00
Entweder mit AES Compiler oder wie ich schon geschrieben hatte für den Kanal die Gesicherteübertragung deaktivieren.
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 16 September 2017, 22:38:57
..bin jetzt erst zum ausprobieren gekommen.

Beides funktioniert mit dem RC-8, mit AES compilieren bzw. das Ausschalten der gesicherten Übertragung!  ;D

Danke!
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 September 2017, 23:07:14
Ich hab gerade mal geschaut was man alles für AsksinPP auf ESP8266 machen muss.
1. pgmspace.h anpassen --> kein Problem gibts auch für den ESP müssen nur die Includes angepasst werden
2. EnableInterrupt --> soweit ich gesehen habe wird beim AVR eh nur das AttachInterrupt verwendet. Dies kann der ESP auch nur dass man dort noch den PIN "übersetzen" muss.
3. Timer1 --> hier müsste etwas mehr gemacht werden. Der ESP hat auch nen Timer der bis zu 80 mal pro Mikrosekunde auslösen kann. Vielleicht könnte man das in die Timer1 Lib integrieren.
4. SPI Lib für den ESP damit auf den CC1101 und den Flash gleichzeitig zugegriffen werden kann.
5. EERPROM Lib für den ESP da dieser keinen EEPROM hat und dieser nur im Flash simuliert wird.

Weiter bin ich noch nicht gekommen.

Werd aber morgen versuchen nen Pro Mini und Funkmodul in die Dose zu Quetschen.
Der 1€ mehr tut auch nicht weh und vom Löten macht es auch keinen großen Unterschied.
Will dann den Taster auch für AsksinPP verwenden und den Status des Relais auslesen damit auch der richtige Status gesendet wird wenn es vom ESP geschaltet wird.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 September 2017, 23:19:38
Schau mal in Master ist der Timer1 schon wegen dem ATMega32 raus geflogen. Und für STM32 habe ich auch schon Macros für enableInterrupt() in AskSinPP.h drin.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 17 September 2017, 22:21:28
Soo, habe jetzt mal die Variante mit dem Pro Mini umgesetzt.
Morgen lad ich noch nen paar Bilder und den Sketch hoch.#
Irgendwer steht bei mir gerade auf der Leitung ...
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 18 September 2017, 17:41:34
Soo, hier sind die anderen Bilder und der passende Sketch.

Zur Funktion:
Die Funktion der originalen Firmware bleibt erhalten bzw. es kann auch eine alternative auf den ESP geflasht werden, dann muss die Steckdose aber auch noch durch den Knopf schaltbar sein.

Pin 6 am Arduino ist als Input ohne Pullup konfiguriert und überwacht den Pegel am Transistor der das Relais schaltet.
Wenn das Relais über den ESP ein/ausgeschaltet wird, sendet der Arduino den neuen Status an Homematic.

An Pin 7 und 8 des Arduino ist der Taster der Steckdose angebunden.
Pin 7 und 8 deswegen, da ich nicht so tief in die Buttonklasse eingreifen wollte, da ich den Taster ja auch über den Arduino "betätigen" will und dazu der Modus des Pins umgeschaltet werden muss und der Interrupt entfernt / wieder hinzugefügt werden muss.
Ich habe lediglich eine eigene ConfigButtonKlasse erstellt, die nur auf lange Tastendrücke fürs pairen und resetten reagiert.

Der Pin 7 ist als Input ohne Pullup konfiguriert.
Nur wenn über Homematic geschaltet werden soll, dann wird der Pin für 50ms als Ausgang konfiguriert und auf LOW gezogen.
Dadurch wird für den ESP ein Tastendruck simuliert und das Relais wird ein/aus geschaltet.
Natürlich wird beim Einschalten vorher geprüft, ob es nicht schon eingeschaltet ist.
Die 50ms sind die kleinste Verzögerung ab der der ESP auf einen Tastendruck reagiert.
Aktuell mache ich das alles direkt in der SwitchChannelKlasse, daher verzögert sich die Statusmeldung an Homematic um 50ms, was aber kein Problem ist.


Der Arduino und das Funkmodul sind auf der Niederspannungsseite der Platine untergebracht und haben genug Abstand zu den spannungsführenden Teilen der Platine.
Dadurch, dass nichts nach außen geführt ist, braucht man sich darum auch keine Sorgen machen.
Nur beim Programmieren des Arduino sollte man die ganze Platine direkt mit einem anderen Netzteil als dem Programmieradapter mit 3,3V versorgen und nicht über das interne Netzteil.

Was haltet ihr von dieser Variante?
Gibts noch Tipps oder Verbesserungsvorschläge?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 September 2017, 19:15:26
Nicht schlecht. Könntest Du noch die Pins ändern ? Wenn Du D3 anstatt D7 nimmst, dann geht es auch mit der HM-Universal-Platine.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 18 September 2017, 20:02:38
Ich hab Pin 7 genommen, da ich dann nur noch ne Brücke nach Pin 8 auf dem Arduino selbst gemacht habe.
Wenn das Schalten des Tasters über Pin 3 erfolgen soll, muss man nur das Define RELAY1_PIN ändern und den natürlich mit dem Taster verbinden.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 19 September 2017, 16:07:52
Wie genau funktioniert das eigentlich mit dem OTA?
Bezieht der Arduino das Update nur von der gepairten Zentrale bzw. FEHM?
Ich nutz ja nur die CCU aktuell, könnte ich das Update auch direkt über einen anderen Arduino mit CC1101 z.B. über die Arduino GUI aufspielen?
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 19 September 2017, 16:28:29
Also das mit der Steckdose ist schon ganz nett, aber so ganz leuchtet mir das nicht ein noch eine HM Anbindung einzubauen wenn das Teil doch schon WLAN kann? Wenn du nur eine billige HM Steckdose brauchst kannst du doch auch die billigen Baumarkt Steckdosen nehmen und dort dein Arduino+CC1101 einbauen, das spart dann auch ne ganze Menge Energy, der ESP schluckt ja doch einiges. Man muss halt wegen der Spannungsversorgung schauen, aber wenn du nur ein Arduino ran klemmst reicht die aus den billig Steckdosen auch aus. Da ist kein richtiges Netzteil drin und wenn dann auch nur 5-12V aber mit einem DCDC Wandler bekommt man das auch hin. Und viel unsicherer als diese gern abbrennenden China Schachteln ist es auch nicht ;-) Ich hab es mir abgewöhnt das Zeug zu kaufen wo kein Deutscher Ing. drüber geschaut hat. Mir sind schon so viele von den Teilen um die Ohren geflogen, das ich heil froh bin immer daneben gestanden zu haben zum löschen.

Aber mal eine andere Frage, dieses POW bzw. die S20 von denen, wie messen die die Energy? Auch nur über einen Shunt oder? Weil ich das mit dem Kalibrieren und der Frequenz nicht so ganz verstehe was im Wiki steht.

Irgendwie juckt es mich ja schon da mal ein Exemplar zu bestellen, aber wenn dann eine um die Energy zu messen.

Gruß
Daniel

Titel: Antw:AskSin++ Library
Beitrag von: Xent am 19 September 2017, 17:53:15
Eigentlich hatte ich auch geplant auf die Teile EasyESP aufzuspielen und über CuxD and die Zentrale anzubinden.

Die S20 sind doch eigentlich ganz gut aufgebaut oder gabs mit denen schonmal Probleme?

Das mit den Baumarktsteckdosen hatte ich eigentlich verworfen.
Habe hier noch einige HomeEasy-Steckdosen, die ich umbauen könnte.
Als ich mich dann über Kondensatornetzteile informiert habe, hab ichs mir dann anders überlegt, da ich ja nicht weiß wieviel mA die liefern können und ob das ausreicht.
Die HomeEasy Dosen haben einmal 24V fürs Relais und 5V für die Elektronik.
Nen 3,3V Pro Mini könnte ich ja an die 5V klemmen.
Vom Platz her müsste dort auch alles rein passen.

Was kann denn alles passieren wenn man aus dem Netzteil zuviel zieht?
Soweit ich das in Erinnerung geht auf jedenfall die Spannung in den Keller. War das alles oder kann da was durch Überlastung abrauchen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 September 2017, 20:34:53
Wie genau funktioniert das eigentlich mit dem OTA?
Bezieht der Arduino das Update nur von der gepairten Zentrale bzw. FEHM?
Ich nutz ja nur die CCU aktuell, könnte ich das Update auch direkt über einen anderen Arduino mit CC1101 z.B. über die Arduino GUI aufspielen?

Der OTA-Bootloader ermöglicht das Update der Firmware über FUnk. Das geht von FHEM, der CCU2 oder einen HM-CFG-USB. Ich verwende den HM-CFG-USB und flash-ota (https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb). Da die ID und die Serial im Bootloader stehen, kann auch eine entsprechend kopilierte Firemware für alle Geräte des selben Types verwendet werden.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 September 2017, 20:42:25
Was kann denn alles passieren wenn man aus dem Netzteil zuviel zieht?
Soweit ich das in Erinnerung geht auf jedenfall die Spannung in den Keller. War das alles oder kann da was durch Überlastung abrauchen?

Die üblicherweise verbauten Kondensatornetzteile liefern nicht genug Leistung für den AVR & CC1101. Ich nehem gern so ein Netzteil (https://de.aliexpress.com/item/5-pcs-HLK-PM01-AC-DC-220V-to-5V-Step-Down-Power-Supply-Module-Intelligent-Household/32319202093.html?spm=a2g0s.9042311.0.0.bfmJ8X).
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 19 September 2017, 20:50:58
Ah ok, muss ich mir irgendwann mal näher anschauen.
Währe cool wenn das auch ausm Windows herraus gehen würde.


Hab gerade noch den Artikel gefunden, der mich dazu gebracht hat erstmal nach anderen Möglichkeiten zu suchen:
https://blog.thesen.eu/umbau-einer-elro-ab440s-funksteckdose-auf-arduino/

Hab ich auch schon bestellt, dauert aber noch bis die ankommen.
Muss dann schauen wie ich das alles in der Dose unterbringen kann, das Teil ist ja doch schon relativ groß im Vergleich zum Kondensatornetzteil.
Vielleicht berechne ich wenn ich mal Zeit hab nen neues Kondensatornetzteil und pass die Teile dafür auf der Platine an, wenn es drauf passt.

Vielleicht könnte man auch noch nen Kondensator zum Puffern einbauen und dann den Sketch auf "Batteriebetrieb" umstellen so dass die Zeit beim Senden und Empfangen usw. vom Kondensator überbrückt werden kann.
Titel: Antw:AskSin++ Library
Beitrag von: rippi46 am 19 September 2017, 21:18:51
Hallo

Zitat
Hab gerade noch den Artikel gefunden, der mich dazu gebracht hat erstmal nach anderen Möglichkeiten zu suchen:
https://blog.thesen.eu/umbau-einer-elro-ab440s-funksteckdose-auf-arduino/

vielleicht könnte man das Ganze auch mit einem attiny84 lösen (sofern der Speicher reicht).
Zum Einen ist der nicht ganz so groß und zum Anderen belastet er das Kondensatornetzteil nicht so stark.

Den Empfang und das Programmieren mit dem vorhandenen Empfangmodul hatte ich schon einmal realisiert(allerdings mit einem attiny85).

Gruß rippi
Titel: Antw:AskSin++ Library
Beitrag von: ahlermi am 02 Oktober 2017, 10:34:04
Ist eine Kombination von unterschiedlichen HM devices möglich?

Ich habe vor Belüftungssysteme als Dimmer zu betreiben und dabei wäre es super wenn Temperatur und Feuchtigkeitsdaten zurückgesendet würden.
Am besten von vier Sensoren.

Gruß Michael
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 02 Oktober 2017, 18:51:09
ein paar Seiten zurück hatte ich papa ne ähnliche Frage nach so einem Hybriddevice gestellt, d.h. ein HM Gerät was es so von e3Q gar nicht gibt.
Z.Z. wohl noch nicht machbar, aber ich glaube papa steht kurz davor das Problem zu lösen.
Titel: Antw:AskSin++ Library
Beitrag von: martins am 03 Oktober 2017, 12:42:34
Ich bin dabei den HM-SEC-MDIR nach zubauen.
Habe derzeit erstmal alles auf ein Breadboard gepackt. Den Lichtsensor verwende ich nicht und für den Pir PIN habe ich zum Testen erst einmal einen Taster genommen.

Leider habe ich nun ein EMV Problem, sobald ich mit der Hand nur in die nähe (Abstand ca. 10cm) komme, löst der Sensor aus. Ich habe schon versucht einen 100nF Kondensator parallel zu dem Taster und GND zu Packen, hat leider auch nicht funktioniert, dann wird nämlich noch genau einmal ausgelöst und dann gar nicht mehr.
Hat jemand noch einen Tipp was ich sonst noch probieren könnte?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Oktober 2017, 20:03:07
Ich bin dabei den HM-SEC-MDIR nach zubauen.
Habe derzeit erstmal alles auf ein Breadboard gepackt. Den Lichtsensor verwende ich nicht und für den Pir PIN habe ich zum Testen erst einmal einen Taster genommen.

Leider habe ich nun ein EMV Problem, sobald ich mit der Hand nur in die nähe (Abstand ca. 10cm) komme, löst der Sensor aus. Ich habe schon versucht einen 100nF Kondensator parallel zu dem Taster und GND zu Packen, hat leider auch nicht funktioniert, dann wird nämlich noch genau einmal ausgelöst und dann gar nicht mehr.
Hat jemand noch einen Tipp was ich sonst noch probieren könnte?

Du musst den Taster gegen Vcc schalten und den Pin mit einen Widerstand - sagen wir mal 10k - auf Masse ziehen, um ein stabiles LOW sicherzustellen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Oktober 2017, 20:05:07
Ist eine Kombination von unterschiedlichen HM devices möglich?

Ich habe vor Belüftungssysteme als Dimmer zu betreiben und dabei wäre es super wenn Temperatur und Feuchtigkeitsdaten zurückgesendet würden.
Am besten von vier Sensoren.

Auf dem Mega ist das kein Problem. Derzeit ist die FHEM-Seite noch etwas aufwändig. Da bin ich gerade dran, um zu verhindern, dass immer das gleiche Code kopiert werden muss.
Titel: Antw:AskSin++ Library
Beitrag von: martins am 03 Oktober 2017, 20:24:07
Du musst den Taster gegen Vcc schalten und den Pin mit einen Widerstand - sagen wir mal 10k - auf Masse ziehen, um ein stabiles LOW sicherzustellen.

Danke, das war es gewesen.
Titel: Antw:AskSin++ Library
Beitrag von: StefanH am 07 Oktober 2017, 23:32:41
Ich habe es mittlerweile geschafft eine Fernbedienung mit 19 Tasten (HM-RC-19) aufzubauen und in einer Standard Fernbedienung zu verpacken. Diese läuft mit zwei AA Batterien auf einem Arduino Nano Import.
Heute kam ich das erste mal dazu das Gesamtsystem in Betrieb zu nehmen und bin auf einen Stromverbrauch von 4.3mA gekommen. Dies würde bei der Annahme von 2000mAh zu ca. 20 Tagen Laufzeit kommen.

Gibt es im Code noch Möglichkeiten den Energieverbrauch zu minimieren? Gerade in der Anwendung der Fernbedienung, die nie Kommandos entgegen nehmen muss? Hat jemand Vorschläge in welcher Datei was geändert werden müsste?
Titel: Antw:AskSin++ Library
Beitrag von: StefanH am 08 Oktober 2017, 11:47:12
Entschuldigung für meine vorschnelle Folgerung.
Ich habe noch einmalmal mein Anschlusskonzept überdacht. Hatte die Batterien einfach an den 3.3V Anschluss des Arduinos angehängt. Dadurch hat der FTDI-Chip rückwärts den Atmega versorgt. Soweit kein Problem, macht ein paar mV Abfall über den FTDI. Viel schlimmer war, dass der Festspannungsregler nach hinten offen war und somit auch rückwärts den Vin Pin versorgt hat. Habe jetzt den Festspannungsregler ausgelötet und die Diode zwischen USB und interner Versorgung entfernt. Die Batterien hängen jetzt am 5V Anschluss, genauso wie der C1101. Da die 5V jetzt ca. 3,3V sind, ist das kein Problem. Auch der FTDI-Chip wird mit 3,3V versorgt. Wenn ich jetzt den USB anhänge, versorgt dieser nicht mehr die Platine, aber die Kommunikation funktioniert trotzdem.

In dieser Konfiguration komme ich auf einen Stromverbrauch von 0,5mA. Somit kann ich das ganze im Standby ca. ein halbes Jahr betreiben. Würde der FTDI Chip noch abgeklemmt werden bestimmt noch ein bisschen länger. Für Debugzwecke würde ich ihn aber erstmal noch behalten.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Oktober 2017, 12:18:23
Der Nano ist nicht die beste Basis für Batterieprojekte. Vielleicht ist das Homeatic Hardware Projekt (https://forum.fhem.de/index.php/topic,73954.msg656384.html#msg656384) ja was für Dich. Eine Platine für eine Fernbedienung (https://forum.fhem.de/index.php/topic,67746.msg592139.html#msg592139) hatte ich auch schon mal gemacht. Aber nur 10 Tasten.
Titel: Antw:AskSin++ Library
Beitrag von: kadettilac89 am 08 Oktober 2017, 15:13:24
Ich habe es mittlerweile geschafft eine Fernbedienung mit 19 Tasten (HM-RC-19) aufzubauen und in einer Standard Fernbedienung zu verpacken. Diese läuft mit zwei AA Batterien auf einem Arduino Nano Import.
Heute kam ich das erste mal dazu das Gesamtsystem in Betrieb zu nehmen und bin auf einen Stromverbrauch von 4.3mA gekommen. Dies würde bei der Annahme von 2000mAh zu ca. 20 Tagen Laufzeit kommen.

Hi StefanH,

hört sich interessant an, wie leitest du die 19 Tasten zu den Arduino Eingängen weiter? Gibst du Schaltplan und modifizierte Software weiter?

Zum Stromverbrauch ... ich habe nichts mit der AskSin++ im Einsatz. In der (New)-Asksin kannst du den Powermode setzen, d. h. wie oft der Arduiono aufwacht. Entweder permanent on, wakeup alle 8 Sekunden, wake alle 250 ms, oder nur wenn an einem Eingang ein Schaltsignal liegt. Hast du das in der Asksin++ gesehen, ggf. auf die letzte Option eingestellt? Damit wacht Arduino wirklich nur auf wenn du eine Taste drückst.
Titel: Antw:AskSin++ Library
Beitrag von: kadettilac89 am 08 Oktober 2017, 15:15:00
Der Nano ist nicht die beste Basis für Batterieprojekte.

Hi Papa, meinst du einen "normalen" nano, oder die Modifikation die StefanH beschreibt ... LED und Spannungsregler raus?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Oktober 2017, 18:36:34
Zum einen ist der Nano für 5V gebaut. Das geht aber nicht mit dem CC1101. Wird nur eine Spannung von 3,3V benutzt, dann liegt die CPU mit 16MHz nicht mehr im spezifizierten Bereich. Also sollte der Quarz getauscht oder der Takt auf intern 8MHz gestellt werden. Dann verbraucht der FDTI Leistung, der Spannungsregeler und die PowerLED. All das muss runter, um wirklich effizient im Batteriebetrieb zu sein.
Wenn man diesen ganzen Umbau betrachtet, kann man sich auch gleich was passendes zusammen löten. Mit der oben verlinken Hardware kommt man im Deep Sleep auf wenige µA. Der Fensterdrehgriffkontakt (https://forum.fhem.de/index.php/topic,71413.0.html) wird zum Beispiel nur von einer CR2032 versorgt.
Titel: Antw:AskSin++ Library
Beitrag von: kadettilac89 am 08 Oktober 2017, 18:52:59


Zum einen ist der Nano für 5V gebaut. Das geht aber nicht mit dem CC1101. Wird nur eine Spannung von 3,3V benutzt, ...

Du hast völlig Recht. Ich habe Nano mit den pro Mini 8 MHz verwechselt. Die pro Mini kann man ganz einfach modifizieren.

Kaum lötet man eine Weile nicht mehr an den Dingen rum, schon vergisst man ...
Titel: Antw:AskSin++ Library
Beitrag von: StefanH am 09 Oktober 2017, 22:25:55
papa hat natürlich vollkommen recht. Der Arduino Nano ist eigentlich nicht dafür geschaffen. Habe zwar den ATmega328p (p!), der extra energiesparend sein soll, aber bei 16MHz läuft er außerhalb seines spezifizierten Bereichs. Eigentlich wollte ich den Bootloader verändern, sodass er mit einem Prescaller von 2 läuft und somit mit 8MHz taktet, habe es aber leider nicht hinbekommen. Habe vorher noch nie einen Bootloader compiliert und bin vorerst daran gescheitert. Sonst hätte ich ihn als Arduino Mini programmieren können.
Das Homatic Hardware Projekt habe ich bereits vorher gesehen, wollte aber keinem die Mühe machen mir Platinen zu bestellen oder sie selbst zu bestücken, da mein FHEM noch ziemlich am Anfang steht. Dachte ein 3€ Arduino wäre erst einmal besser und mit weniger Aufwand verbunden.

@kadettilac89
eine Fernbedienung ist so aufgebaut, dass sie - in meinem Fall - 4 Outputs hat, welche dann über die Tasten auf die 8 Inputs geschaltet werden. Im Schlafmodus sind alle Outputs des Arduinos auf LOW geschaltet. Die 8 Inputs sind über Pin Change Interrupts überwacht. Wird eine Taster gedrückt, ändert sich einer der acht Inputpins auf LOW. Jetzt laufe ich in die ISR und schalte nach einander einen der vier Outputs auf LOW die anderen HIGH und überprüfe weiterhin den entsprechenden Inputpin. Damit bekomme ich heraus, welche Taster wirklich gedrückt wurde und rufe anschließend den Debouncing Algorithmus auf.
Den Code dazu kann ich gerne zur Verfügung stellen, ich bin aber kein besonders guter C++ Programmierer. Deswegen habe ich einfach nur das vorhandene Template erweitert... Somit ist mein Code jetzt nicht mehr kompatibel zu anderen Projekten.
Schick mir einfach eine PN, dann sende ich dir den Code zu inkl. einem Excel Blatt, in dem steht, wie  meine Knöpfe der Fernbedienung den einzelnen In- und Outputs zugeordnet sind.



Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Oktober 2017, 22:49:44
Könntest Du dafür nicht auch die Matrx Keypad Library (https://playground.arduino.cc/Main/KeypadTutorial) verwenden ?
Titel: Antw:AskSin++ Library
Beitrag von: StefanH am 10 Oktober 2017, 23:20:29
Ja, die library scheint genau dafür gemacht zu sein. Kannte die noch gar nicht. Ich bin mir trotzdem nicht sicher ob es einfacher ist das Projekt so zu ändern dass man die library nutzen kann oder einfach die Funktionalität ins Projekt einbaut.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 14 Oktober 2017, 09:02:08
Ich hab gerade nen BUG gefunden, bin aber noch nicht dazu gekommen mir das mal anzuschauen ob ich das selbst fixen kann.

Ich habe den HM-LC-SWX-SM mit einem Taster direkt verknüpft.
Wenn ich nun den Taster lange drücke, sollte dies wie ein kurzer Tastendruck empfangen werden, egal wie lange ich auf den langen Taster drücke.
Da ich in der Verknüpfung aber eingestellt habe, dass getoggelt werden soll ist mir aufgefallen, dass der Aktor beim lange Drücken immer an und aus geht.
Der Taster sendet beim lange Drücken immer die gleiche Message mit dem gleichen Counter raus.
Darauf wird aktuell scheinbar nicht geprüft und die Message immer als neu interpretiert.

Hier mal die Messages:
-> 0B 4B 84 40 3B1630 FE3456 45 69  - 464655
<- 0E 4B 80 02 FE3456 3B1630 01 01 C8 00 5C  - 464659
-> 0B 4C 84 40 3B1630 FE3456 45 69  - 464922
<- 0E 4C 80 02 FE3456 3B1630 01 01 00 00 5C  - 464925
-> 0B 4D 84 40 3B1630 FE3456 45 69  - 465189
<- 0E 4D 80 02 FE3456 3B1630 01 01 C8 00 5D  - 465192
-> 0B 4E A0 40 3B1630 FE3456 45 69  - 465457
<- 0E 4E 80 02 FE3456 3B1630 01 01 00 00 5B  - 465460


Zusätzlich wollte ich dich mal fragen, ob es ne Möglichkeit gibt den empfangenen LongPress zu überschreiben.
Also z.B. dass man bei kurz drücken Kanal 1 schaltet und beim lange Drücken Kanal 2.
Aktuell habe ich das über nen Programm in der CCU gemacht.

EDIT:
Irgendwie war scheinbar das Pairing defekt.
Nachdem ich jetzt noch etwas rumgespielt habe und ne Deckenlampe gepairt habe und wieder gelöscht habe usw.
Wird nur noch beim Loslassen der Taste ein Befehl zum FE3456 gesendet.
Allerdings wird nun das Halten der Taste zur Deckenlampe gesendet und diese schaltet sofort also schon vor dem Loslassen der Taste.

Vielleicht hast du ja was beim Pairing umgebaut oderso.
Ich weiß ja nicht ob man nem anderen Aktor mitteilen kann, dass der auch das Halten der Taste senden soll oder nur das Loslassen.

So sieht es mit Deckenlampe aus:
ignore 0B 78 84 40 3B1630 46B031 45 19  - 413558
ignore 0B 79 84 40 3B1630 46B031 45 19  - 413826
ignore 0B 7A 84 40 3B1630 46B031 45 19  - 414093
ignore 0B 7B 84 40 3B1630 46B031 45 19  - 414360
ignore 0B 7C 84 40 3B1630 46B031 45 19  - 414627
ignore 0B 7D A0 40 3B1630 46B031 45 19  - 415044
ignore 0E 7D 80 02 46B031 3B1630 01 01 00 00 34  - 415171
-> 0B 7E A0 40 3B1630 FE3456 45 19  - 415341
<- 0E 7E 80 02 FE3456 3B1630 01 01 00 00 5C  - 415345

EDIT2:
Ich glaub ich komm so langsam dahinter wie das ganze tickt ...
Jenachdem welcher Aktor zuerst gepairt wurde, bekommt dieser die Meldungen für Taste lange gehalten.
Der andere bekommt nur die Meldung Taste lange losgelassen.

EDIT3:
Hab jetzt noch 1 Rollos auf den Taster gelegt.
Dieses reagiert gleichzeitig auf lange drücken, also muss der Aktor mitgeteilt bekommen dass er auch auf die andere Adresse hören soll.
Dies macht Asksin++ bisher noch nicht oder?

EDIT4:
Der Punkt mit dem Antworten auf die Gedrückt-Meldungen hat sich erledigt, ist im aktuellen master gefixt.
Allerdings toggled der Aktor noch beim Gedrückthalten.
Werd da mal nen Fix für commiten, damit der SwitchChannel die Messages ignoriert nach dem ersten Ausführen.
Für denk Punkt, dass man die LongPressAction überschreiben kann werd ich auch was bauen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 Oktober 2017, 19:19:15
Du kannst das Toggeln bei Long einfach abstellen, indem Du das lgActionType Register vom self auf inactive stellst. Dann sollte der SwitchChannel auf Long-Messages nicht mehr reagieren.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 14 Oktober 2017, 20:29:58
Daran hab ich noch garnicht gedacht.
Über den Expertenmodus der direkten Verknüpfung kann ich beim Kanal 1 einstellen dass er nicht auf Long reagieren soll und dann bei der 2. Verknüpfung mit dem 2. Kanal einstellen dass er nicht auf Short reagieren soll.
Aber ich fänds trotzdem ganz praktisch wenn man feststellen könnte ob der Status durch nen kurzen oder langen Tastendruck geändert wurde.
Vielleicht kann man bei dem switchState ja noch nen Flag hinzufügen oderso.


Zu dem Bug mit dem Toggeln, ich hatte folgendes im SwitchChannel umgebaut.
Natürlich noch die Variable in der Klasse hinzugefügt.
Dadurch toggled der Kanal nicht mehr beim Gedrückthalten so wie es der originale Aktor macht.
  bool process (const RemoteEventMsg& msg) {
    bool lg = msg.isLong();
    Peer p(msg.peer());
    uint8_t cnt = msg.counter();
    typename BaseChannel::List3 l3 = BaseChannel::getList3(p);
    if( l3.valid() == true && cnt != messageCounter) {
  messageCounter = cnt;
      // l3.dump();
      typename BaseChannel::List3::PeerList pl = lg ? l3.lg() : l3.sh();
      // pl.dump();
      remote(pl,cnt);
      return true;
    }
else if(messageCounter == cnt) {
       return true;
}

    return false;
  }

Aktuell kann ich das Problem umgehen indem ich die Verknüpfung auf Togglen über den Counter umstelle.


Zum 3. Punkt
Könntest du das auch noch implementieren?
Damit könnte man zwei Dimmer oder Rolladen synchron per Longpress steuern.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 Oktober 2017, 20:46:23
Ich kann auch einfach die default Initialisierung ändern und bei single-Peer bei Long einfach nichts machen - sprich lgActionType = 0.

Kannst Du mir das Problem für 3. nochmal genau beschreiben. Es sollte eigentlich keine Einschränkungen geben.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 14 Oktober 2017, 21:33:14
Meinste jetzt bezüglich des togglens?
Der originale Aktor reagiert sofort auf die erste LongPress Nachricht und man kann ihn solange gedrückt halten wie man möchte ohne dass er hin und her springt.
Nur beim nächsten LongPress reagiert er wieder.


Zu dem 3.
Also folgende Situation:
1 x Taster
2 x Dimmer
Beide Dimmer sind mit dem Taster gepairt.
Jetzt drückt man lange auf den Taster und dieser sendet das Gedrückthalten an Dimmer 1.
Nun reagiert aber nicht nur der Dimmer 1 sondern auch der Dimmer 2.
So wie es aussieht wurde dem Dimmer 2 beim Pairing mit dem Taster gesagt, dass er auf auf LongPress an Dimmer 1 reagieren soll.

Ich hab das ganze hier mal mit zwei Schaltern gemacht.

Die Schalter waren eingeschaltet und sind auf Togglen gestellt.
Taster an Aktor 2 (Aktor 1 und 2 gehen aus)
ignore 0B 57 84 40 3B1630 442D73 46 52  - 2963261
ignore 0B 58 84 40 3B1630 442D73 46 52  - 2963528
ignore 0B 59 84 40 3B1630 442D73 46 52  - 2963795
ignore 0B 5A A0 40 3B1630 442D73 46 52  - 2964212

Taster an Aktor 1
ignore 0B 5B A0 40 3B1630 442D21 46 52  - 2964570
ignore 0E 5B 80 02 442D21 3B1630 01 01 00 00 42  - 2964697

Taster an Aktor 2
ignore 0B 5A A0 40 3B1630 442D73 46 52  - 2964868
ignore 0E 5A 80 02 442D73 3B1630 01 01 00 00 5F  - 2964996

Aktor 2 an Zentrale
ignore 0D 5B A4 10 442D73 473071 06 01 00 00  - 2966599
ignore 0A 5B 80 02 473071 442D73 00  - 2966723

Aktor 1 an Zentrale
ignore 0D 5C A4 10 442D21 473071 06 01 00 00  - 2967036
ignore 0A 5C 80 02 473071 442D21 00  - 2967160



Zum Versuch mit dem deaktivieren des Short und Long Press bei zwei Verküpfungen:
Scheinbar wird die Message nicht an den zweiten Kanal weitergeleitet wenn der erste bereits darauf reagiert.
Folgender Aufbau:
Taster 1 an Kanal 1, LONG_ACTION_TYPE --> INACTIVE
Taster 1 an Kanal 2, SHORT_ACTION_TYPE --> INACTIVE

Jetzt sollte ja Kanal 1 bei Short und Kanal 2 bei Long reagieren.
Es reagiert aber immer nur Kanal 1 bzw. macht bei Long halt nichts.

Hier mal die Messages.
Die mit Ignore gehen an einen originalen 2 Kanal Aktor.
Man sieht auch nen Unterschied bei dem ACK.
Taster 6 an Kanal 1 Short
ignore 0B 0D A4 40 3B1630 442D73 06 42  - 1456382
ignore 0A 0D 80 02 442D73 3B1630 00  - 1456506

Taster 6 an Kanal 2 Long
ignore 0B 14 84 40 3B1630 442D73 46 45  - 1493389
ignore 0B 15 84 40 3B1630 442D73 46 45  - 1493656
ignore 0B 16 A0 40 3B1630 442D73 46 45  - 1493923
ignore 0A 16 80 02 442D73 3B1630 00  - 1494048

Taster 5 an Kanal 1 Short
-> 0B 17 A4 40 3B1630 FE3456 05 89  - 1524499
<- 0E 17 80 02 FE3456 3B1630 01 01 C8 00 51  - 1524598

Taster 5 an Kanal 2 Long
-> 0B 18 84 40 3B1630 FE3456 45 8A  - 1568027
-> 0B 19 A0 40 3B1630 FE3456 45 8A  - 1568294
<- 0E 19 80 02 FE3456 3B1630 01 01 C8 00 50  - 1568389
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 Oktober 2017, 12:56:58
Soo, ich hab mal nen paar PullRequests erstellt.

Das Problem zu 3. habe ich nun auch verstanden wie es funktioniert.
Das bei diesen Nachrichten das Flag BCAST gesetzt ist, wird die Empfängeradresse nicht überprüft, da diese die erste ist mit dem der Taster gepairt wurde.
Wenn weitere Geräte gepairt werden, dann bleibt sie gleich.

Habe nun in MultiChannelDevice.h folgende Zeile geändert:
if( msg.to() == devid || (msg.to() == HMID::broadcast && this->isBoardcastMsg(msg)) || msg.isBroadcast() ) {Die Funktion isBroadcast habe ich bereits im Commit für den LongPress-Fix drin allerdings hab ich sie nun direkt in die Message Klasse gepackt.
Man könnte das msg.isBroadcast noch mit ner Abfrage auf den Messagetype kombinieren (Remote und Sensor).
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 Oktober 2017, 13:27:24
Soo, ich hab mal nen paar PullRequests erstellt.

Das Problem zu 3. habe ich nun auch verstanden wie es funktioniert.
Das bei diesen Nachrichten das Flag BCAST gesetzt ist, wird die Empfängeradresse nicht überprüft, da diese die erste ist mit dem der Taster gepairt wurde.
Wenn weitere Geräte gepairt werden, dann bleibt sie gleich.

Habe nun in MultiChannelDevice.h folgende Zeile geändert:
if( msg.to() == devid || (msg.to() == HMID::broadcast && this->isBoardcastMsg(msg)) || msg.isBroadcast() ) {Die Funktion isBroadcast habe ich bereits im Commit für den LongPress-Fix drin allerdings hab ich sie nun direkt in die Message Klasse gepackt.
Man könnte das msg.isBroadcast noch mit ner Abfrage auf den Messagetype kombinieren (Remote und Sensor).

Aha, so ganz habe ich die Logik immer noch nicht verstanden. Ich würde gern erts mal alle Kombinationen analysieren und dann den Code entsprechend anpassen.

1) 1 Taster gepeert mit 1 Switchchannel

Es wird direkt eine Nachricht an den Peer geschickt. Es ist kein BCAST gesetzt. Der Peer antwortet mit eine Ack.

1) 1 Taster gepeert mit 2 Switchchannel vom gleichen Gerät

Es wird eine Nachricht an den ersten Channel gesendet. Der zweite Channel reagiert ebenfalls auf die Nachricht. Das Gerät sendet einen Ack zurück. Was ist mit dem BCAST Flag ?

1) 1 Taster gepeert mit 2 Switchchannel vom unterschiedlichen Geräten

Es wird eine Nachricht an den ersten Peer gesendet. Zusätzlich ist das BCAST Flag gesetzt. Beide Geräte reagieren auf die Nachricht - also auch das, was gar nicht direkt adressiert ist. Wie ist es mit dem Ack ? Sende jetzt beide einen - oder nur der direkt adressierte ?


Für welche Nachrichten trifft dieses Verhalten zu ? Nur Remote-Events (0x40) oder auch Sensor-Events (0x41) ?

Wir können auf jeden Fall die isBoardcastMsg der Device-Klasse anpassen, um die entsprechenden Nachrichten zur Verarbeitung durchzulassen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 Oktober 2017, 14:14:51
1) 1 Taster gepeert mit 2 Switchchannel vom gleichen Gerät

Es wird eine Nachricht an den ersten Channel gesendet. Der zweite Channel reagiert ebenfalls auf die Nachricht. Das Gerät sendet einen Ack zurück. Was ist mit dem BCAST Flag ?

Dieser Punkt hat nichts mit dem Broadcast zutun.
In Taster sendet keine Befehle direkt zu einem Channel sondern nur zum Gerät und gibt dabei an welche Taste gedrückt wurde.
0B 15 A4 40 3B1630 46B02D 06 88Hier jetzt der 6. Taster.

Die bisherige channelForPeer Funktion liefert aber immer nur den 1. Kanal der gepeered ist zurück.
In diesem Pullrequest https://github.com/pa-pa/AskSinPP/pull/20 (https://github.com/pa-pa/AskSinPP/pull/20) habe ich das gefixt.
Wenn nur ein Kanal gepeered ist, bekommt der Sender den Status zurück.
Wenn zwei Kanäle gepeered sind, kommt nur ein ACK ohne Status zurück.



Was den Broadcast angeht, so sind dort nur die Nachrichten beim Gedrückthalten betroffen.
Beim loslassen bekommt jedes Geräte ne eigene Nachricht.
Da muss ich nochmal ran und das optimieren da das Flag noch bei mehr Nachrichten gesetzt ist.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 Oktober 2017, 19:24:38
Hab das ganze jetzt eigentlich genau auf die richtigen Messages eingegrenzt:
     if( msg.to() == devid || (msg.to() == HMID::broadcast && this->isBoardcastMsg(msg)) || (msg.isBroadcast() && (msg.command() & 0x40) == 0x40 && msg.type() == AS_MESSAGE_REMOTE_EVENT)) {

Somit werden die Remote_Event Messages die per Broadcast gesendet wurden und vom LongPress ausgelöst wurden weitergeleitet.
Dann prüft der Aktor ob ein Kanal gepeered ist und verarbeitet die Meldung oder macht halt garnichts, da diese Messages kein Ack benötigen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 Oktober 2017, 20:50:00
Nun mal langsam mit dem Code, ich versuche gerade aus Dir rauszukriegen, wie die genaue Kommunikation bei dem unterschiedlichen Fällen aussieht. Wenn wir das alles zusammen haben, gehen wir an die Implementierung.

Könntest Du bitte nochmal das Verhalten bei mehreren unterschiedlichen gepeerten Geräten bei Short- & Long-Press beschreiben. Am besten inklusive der Nachrichten der originalen Geräte.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 Oktober 2017, 21:05:10
Also Shortpress ist kein Problem.
Beim LongPress gibt es zwei Messages.
Einmal beim halten und eine beim Loslassen.

Die beim Halten hat die Zieladresse des ersten gepeerten Gerätes, das Broadcast-Flag und als Command Long.
Diese Nachrichten werden solange gesendet bis man den Taster loslässt.
Darauf reagieren alle mit diesem Taster gepeerten Geräte.

Beim loslassen bekommen alle gepeerten Geräte eine eigene Nachricht, dies funktioniert auch ohne Probleme.


Könnten auch mal Telefonieren oderso, geht dann vielleicht einfacher als immer hier zu schreiben ;-)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Oktober 2017, 19:35:38
Ja können wir mal machen.

Ich werde nachher noch den Code für das Schalten von mehreren Channels einchecken. Habe das ein wenig umgeschrieben. So ganz bin ich immer noch nicht zufrieden, da immer noch 2mal der Peer gesucht wird, obwohl auch einmal reichen würde. Aber egal - es geht erstmal.

Jetzt will ich mich erst mal um den HM-LC-Sw2-Costum Umbau kümmern. Dann sind die Long-Messages dran. Da muss ich ja auch noch die Senderseite - sprich Remotes entsprechend anpassen.

Ich habe heute mal den Long-Press von einem HM-Sen-MDIR-WM55 mitgeschnitten. Allerdings war der nur mit einem Gerät gepeert und hat AES an. Da war zumindest auch das BCAST-Flag gesetzt. Allerdings fordert er auch einen Ack an.

ignore 0D 57 B4 41 4E6BFE 54A178 03 25 6F 70  - 18814
ignore 0E 57 80 02 54A178 4E6BFE 01 02 00 04 00  - 18827
ignore 0B 58 B4 40 4E6BFE 54A178 42 05  - 18843
ignore 11 58 A0 02 54A178 4E6BFE 04 64 0B F3 41 99 CD 02  - 18853
ignore 19 58 A0 03 4E6BFE 54A178 76 33 AE 49 E8 16 09 A9 C9 E3 86 E1 4A 7E 35 90  - 18868
ignore 12 58 80 02 54A178 4E6BFE 01 04 00 04 00 1A EE D0 3A  - 18882
ignore 0B 59 B4 40 4E6BFE 54A178 42 06  - 18896
ignore 11 59 A0 02 54A178 4E6BFE 04 35 29 AD CB 77 5E 02  - 18907
ignore 0B 59 B0 40 4E6BFE 54A178 42 06  - 18923
ignore 11 59 A0 02 54A178 4E6BFE 04 04 71 03 36 92 60 02  - 18933
ignore 19 59 A0 03 4E6BFE 54A178 C4 07 D6 E8 EF 45 11 7F AC 8F 8B 2F C9 05 B0 00  - 18948
ignore 12 59 80 02 54A178 4E6BFE 01 04 00 04 00 49 C4 85 24  - 18964
ignore 0B 5A B4 40 4E6BFE 54A178 42 07  - 18976
ignore 11 5A A0 02 54A178 4E6BFE 04 19 48 96 62 53 6B 02  - 18987
ignore 19 5A A0 03 4E6BFE 54A178 24 AC 37 F6 C1 F1 D0 F1 4B 99 DF 2E 7E A2 37 8B  - 19003
ignore 12 5A 80 02 54A178 4E6BFE 01 04 00 04 00 57 C5 63 16  - 19017

Könnest Du mal so einen Mitschnitt bei 2 Peers machen. Am besten mit und ohne AES. Meine original Geräte sind alle im Produktivbetrieb und können leider nicht so einfach mal umkonfiguriert werden.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 Oktober 2017, 21:10:04
Soo hier jetzt 2 Kanäle mit AES.
Die Schalter lösen erst beim Loslassen der Taste aus.
0B C0 84 40 3B1630 46B021 46 9D  - 16548
 0B C1 84 40 3B1630 46B021 46 9D  - 16816
 0B C2 84 40 3B1630 46B021 46 9D  - 17083
 0B C3 84 40 3B1630 46B021 46 9D  - 17349
 0B C4 84 40 3B1630 46B021 46 9D  - 17616
 0B C5 84 40 3B1630 46B021 46 9D  - 17884
 0B C6 A0 40 3B1630 46B021 46 9D  - 18300
 11 C6 A0 02 46B021 3B1630 04 46 45 D5 AC B2 F7 06  - 18430
 19 C6 A0 03 3B1630 46B021 F1 BB 4E F8 6C 02 D7 19 B5 7E 2A FF 7C 14 67 FB  - 18564
 12 C6 80 02 46B021 3B1630 01 01 C8 00 3B 18 BD 25 66  - 18681
 0B C7 A0 40 3B1630 46B02D 46 9D  - 18851
 11 C7 A0 02 46B02D 3B1630 04 19 60 CF 02 74 F0 06  - 18981
 19 C7 A0 03 3B1630 46B02D FC 4B 3F BA AE 4D 81 06 2E 6C D1 0D 1A 91 0F 19  - 19113
 12 C7 80 02 46B02D 3B1630 01 01 C8 00 4D 37 6E 7B F1  - 19231


Die gleichen Aktoren ohne AES.
Diesmal schalten sie bereits beim ersten Befehl.
0B D5 84 40 3B1630 46B021 46 9F  - 351684
 0B D6 84 40 3B1630 46B021 46 9F  - 351951
 0B D7 84 40 3B1630 46B021 46 9F  - 352219
 0B D8 84 40 3B1630 46B021 46 9F  - 352486
 0B D9 84 40 3B1630 46B021 46 9F  - 352753
 0B DA 84 40 3B1630 46B021 46 9F  - 353020
 0B DB A0 40 3B1630 46B021 46 9F  - 353437
 0E DB 80 02 46B021 3B1630 01 01 C8 00 3A  - 353564
 0B DC A0 40 3B1630 46B02D 46 9F  - 353735
 0E DC 80 02 46B02D 3B1630 01 01 C8 00 40  - 353862
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Oktober 2017, 09:20:12
Hast Du auch nen Dimmer verfügbar ? Wie reagiert der denn, wenn noch ein anderes Gerät mit angesprochen wird und AES an ist. Der müsste ja eigentlich jede einzelne Nachricht prüfen, bevor er den Helligkeitswert ändert.

Fragen über Fragen .....
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 17 Oktober 2017, 09:28:50
Ja hab ich auch da.
Mache ich heut Abend fertig. 
Titel: Antw:AskSin++ Library
Beitrag von: oli82 am 18 Oktober 2017, 11:29:34
Guten Morgen.
Hat sich schon jemand an dem HM-LC-Bl1-FM, bzw. einem Rolladenaktor versucht?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Oktober 2017, 12:54:03
Soweit ich weiss nicht. Hatte auch noch keine Zeit dafür. Aber meine FS20 RSUs sollen auch mal einer Homematic-Lösung weichen.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 18 Oktober 2017, 13:11:15
Hatte auch noch keine Zeit dafür.
Achh geh , lass uns ( und dich ) nicht soooo hängen :) 
Rollo wäre fein, dann könnte ich das Ding für die 24V Velux Dachflächenrollos meines Kollegen bauen   
Titel: Antw:AskSin++ Library
Beitrag von: oli82 am 18 Oktober 2017, 13:45:36
Hatte auch noch keine Zeit dafür.

So geht es mir leider auch. Hardwaredesign wäre das geringste Problem.
Evtl mache ich mal ein Layout und suche das passende Gehäuse.
Wollte nur das Rad nicht neu erfinden
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Oktober 2017, 19:33:29
Richtig cool wäre es, wenn alles auch wieder in das Gehäuse der alten RSU geht.
Titel: Antw:AskSin++ Library
Beitrag von: oli82 am 18 Oktober 2017, 20:24:07
Habe leider nur UP Aktoren.
Denkbar wäre natürlich ein Addon-Board wie das vorhandene in den RSU. Also das Netzteil bleibt wie es ist und man macht nur die Platine mit dem Atmega + Funk.
Wäre dann eine Art "Umrüstung".
Vorrang hätte aber die UP Variante ;)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Oktober 2017, 20:30:47
Ich meine den hier https://www.elv.de/FS20-Funk-Rollladenschalter-FS20-RSU/x.aspx/cid_726/detail_31420 (https://www.elv.de/FS20-Funk-Rollladenschalter-FS20-RSU/x.aspx/cid_726/detail_31420)
Titel: Antw:AskSin++ Library
Beitrag von: oli82 am 18 Oktober 2017, 20:32:54
Ah. Okay.
Den kannte ich garnicht.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 18 Oktober 2017, 22:47:43
Soo, jetzt bin ich endlich dazu gekommen alles mal zu testen.

Ein Dimmer mit AES:
0B 34 A4 40 3B1630 481B87 46 B8  - 324108
 11 34 A0 02 481B87 3B1630 04 60 C6 ED 08 81 11 06  - 324238
 19 34 A0 03 3B1630 481B87 59 37 29 B7 AF B1 6A 8E 6B 29 9E C3 0B E4 A7 83  - 324371
 12 34 80 02 481B87 3B1630 01 01 3C 10 4E 17 B6 67 75  - 324489
 0B 35 A4 40 3B1630 481B87 46 B8  - 324659
 11 35 A0 02 481B87 3B1630 04 1D 66 4F 15 BE 12 06  - 324789
 19 35 A0 03 3B1630 481B87 60 2D 89 B1 98 81 0B 4D 75 E7 75 94 CC 2B 00 56  - 324920
 12 35 80 02 481B87 3B1630 01 01 46 10 4C D5 EC 59 31  - 325038
 0B 36 A4 40 3B1630 481B87 46 B8  - 325208
 11 36 A0 02 481B87 3B1630 04 04 3F CC B9 3E 25 06  - 325338
 19 36 A0 03 3B1630 481B87 C9 DE 86 C1 D3 43 D5 E5 29 D3 AA 7A E8 C3 27 E9  - 325471
 12 36 80 02 481B87 3B1630 01 01 51 10 4E E4 24 69 D3  - 325587
 0B 37 A4 40 3B1630 481B87 46 B8  - 325758
 11 37 A0 02 481B87 3B1630 04 AC 1F BD 0C AC 42 06  - 325888
 19 37 A0 03 3B1630 481B87 36 EE F9 3C 8E AA 76 33 1F 8C 1A 99 F3 16 C2 A6  - 326020
 12 37 80 02 481B87 3B1630 01 01 5A 10 4C 3E 16 92 E8  - 326137
 0B 38 A0 40 3B1630 481B87 46 B8  - 326307
 11 38 A0 02 481B87 3B1630 04 B4 23 54 F8 2F 92 06  - 326437
 19 38 A0 03 3B1630 481B87 F3 0C C9 D6 8C B8 71 31 92 46 75 61 FF 21 BA 9B  - 326569
 12 38 80 02 481B87 3B1630 01 01 64 10 4E F9 10 73 B9  - 326687



Dimmer mit AES und Schalter mit AES
-> 0B 57 84 40 3B1630 481B87 46 BE  - 9558
-> 0B 58 84 40 3B1630 481B87 46 BE  - 9826
-> 0B 59 84 40 3B1630 481B87 46 BE  - 10093
-> 0B 5A 84 40 3B1630 481B87 46 BE  - 10360
-> 0B 5B 84 40 3B1630 481B87 46 BE  - 10628
-> 0B 5C 84 40 3B1630 481B87 46 BE  - 10895
-> 0B 5D 84 40 3B1630 481B87 46 BE  - 11161
-> 0B 5E 84 40 3B1630 481B87 46 BE  - 11428
ignore 0B 5F A0 40 3B1630 481B87 46 BE  - 11845
ignore 11 5F A0 02 481B87 3B1630 04 48 53 8D 14 E7 83 06  - 11975
ignore 19 5F A0 03 3B1630 481B87 67 9A 3A F0 8F 35 C6 7F 3E 2F AE 2B D9 E6 EB 2C  - 12107
ignore 12 5F 80 02 481B87 3B1630 01 01 C8 00 4F 2D 10 38 7D  - 12225
ignore 0B 60 A0 40 3B1630 46AFEE 46 BE  - 12395
ignore 11 60 A0 02 46AFEE 3B1630 04 7D 9B BC 9D 07 4C 06  - 12526
ignore 19 60 A0 03 3B1630 46AFEE C8 27 82 54 FA 5A 5B F7 60 99 CA A4 A0 ED 93 67  - 12657
ignore 12 60 80 02 46AFEE 3B1630 01 01 C8 00 4F E6 72 9F DA  - 12776


zwei Rolladen mit AES
0B F3 84 40 3B1630 4AA8CC 44 11  - 4934
 0B F4 84 40 3B1630 4AA8CC 44 11  - 5201
 0B F5 84 40 3B1630 4AA8CC 44 11  - 5469
 0B F6 84 40 3B1630 4AA8CC 44 11  - 5736
 0B F7 84 40 3B1630 4AA8CC 44 11  - 6003
 0B F8 84 40 3B1630 4AA8CC 44 11  - 6270
 0B F9 84 40 3B1630 4AA8CC 44 11  - 6538
 0B FA 84 40 3B1630 4AA8CC 44 11  - 6805
 0B FB 84 40 3B1630 4AA8CC 44 11  - 7072
 0B FC A0 40 3B1630 4AA8CC 44 11  - 7489
 11 FC A0 02 4AA8CC 3B1630 04 78 D2 92 74 76 8F 06  - 7619
 19 FC A0 03 3B1630 4AA8CC 65 3C EA 20 B4 54 43 5A 05 79 9F 87 06 37 C2 58  - 7751
 12 FC 80 02 4AA8CC 3B1630 01 01 06 10 45 C5 C7 D0 6B  - 7869
 0B FD A0 40 3B1630 4AA77D 44 11  - 8039
 11 FD A0 02 4AA77D 3B1630 04 C9 81 E8 A5 21 85 06  - 8169
 19 FD A0 03 3B1630 4AA77D 01 18 71 14 96 18 9F 24 9A AA EB FB 57 A3 8D 3A  - 8302
 12 FD 80 02 4AA77D 3B1630 01 01 04 10 41 6E 1E EC CD  - 8420


Wie man sieht, wird bei einem Aktor das gedrückthalten gesendet und vom Aktor verifiziert.
Wenn zwei Aktoren gepeerd sind, dann wird das normale Signal ohne AES gesendet und die Aktoren mit aktivierem AES reagieren erst beim loslassen der Taste, da dann die einzel Messages an die Aktoren rausgehen.


Bytheway, vielleicht hab ich wieder nen kleinen Bug gefunden.
Ich habe die Firmware auf den Aktor einige male geflascht und auch die Anzahl der Kanäle geändert.
Jetzt war es so, dass der Aktor beim einschalten den Status an 000000 gesendet hat.
Auch wenn er vom Peer geschaltet wurde hat er den Status auch an 000000 gesendet.
Deswegen hat die Zentrale davon nichts mitbekommen.
Wenn ich den Aktor aber über die Zentrale geschaltet habe (ja das ging noch) wurde auch wieder mit dem Status an die Zentrale geantwortet.
Hätte jetzt erwartet, dass er entweder die Zentrale noch kennt und alles an die Zentrale schickt oder aber garnicht mehr kennt und auch nicht mehr auf die Zentrale reagiert.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 Oktober 2017, 09:38:13
Erst mal vielen Dank für die Message-Logs.

Wie man sieht, wird bei einem Aktor das gedrückthalten gesendet und vom Aktor verifiziert.
Wenn zwei Aktoren gepeerd sind, dann wird das normale Signal ohne AES gesendet und die Aktoren mit aktivierem AES reagieren erst beim loslassen der Taste, da dann die einzel Messages an die Aktoren rausgehen.

Also das BCAST-Flag ist immer gesetzt. Das BIDI-Falg ist gesetzt, wenn die Nachricht nur für einen Aktor ist (nur ein Peer oder LongRelease). Nur wenn das BIDI-Flag gesetzt ist, reagieren die Aktoren bei aktiviertem AES - sprich fordern die Signatur an und führen bei gültiger Antwort die Aktion aus.

Um wieviele Schritte ändert der Dimmer dann eigentlich das Licht ? Dürfte ja nur ein Step sein. Das macht die Verknüpfung von mehreren Dimmern für einen Button doch eigentlich sinnlos - zumindest das Long-Press.

Für Long-Messages gibt es auch noch das MultiExec-Register. Hier kann man einstellen, ob jede Long-Nachricht vom Aktor ausgewertet werden soll. Das beachtet die Lib bisher boch gar nicht.

Bytheway, vielleicht hab ich wieder nen kleinen Bug gefunden.
Ich habe die Firmware auf den Aktor einige male geflascht und auch die Anzahl der Kanäle geändert.
Jetzt war es so, dass der Aktor beim einschalten den Status an 000000 gesendet hat.
Auch wenn er vom Peer geschaltet wurde hat er den Status auch an 000000 gesendet.
Deswegen hat die Zentrale davon nichts mitbekommen.
Wenn ich den Aktor aber über die Zentrale geschaltet habe (ja das ging noch) wurde auch wieder mit dem Status an die Zentrale geantwortet.
Hätte jetzt erwartet, dass er entweder die Zentrale noch kennt und alles an die Zentrale schickt oder aber garnicht mehr kennt und auch nicht mehr auf die Zentrale reagiert.

Hm - eigentlich sollte bei Änderung der Kanalanzahl alles neu initialisiert werden. Dann sollte ein Schalten von (alten) Peer gar nicht mehr funktionieren. Für die Zentrale sieht das etwas anders aus - ich glaube die Set-Action prüft auch noch nicht, woher die Nachricht kam. Die wird einfach ausgeführt  :)
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 19 Oktober 2017, 09:50:29
Um wieviele Schritte ändert der Dimmer dann eigentlich das Licht ? Dürfte ja nur ein Step sein. Das macht die Verknüpfung von mehreren Dimmern für einen Button doch eigentlich sinnlos - zumindest das Long-Press.

Man kann die Schritte und auch das maximal erreichbare Level in der direkten Verknüpfung einstellen.
Ich schau gleich mal nach ob ich das in der Experten-Ansicht sehen kann was des Standard ist.
Naja zumindest wenn man AES auf den Dimmern aktiviert hat.
Hatte das ja auch mit zwei Rolladenaktoren getestet und da lief da Fahren auch nicht einwandfrei.
Man konnte genau sehen wie oft die Messages kamen, da die Verzögerung nach jeder LongPress-Message so lang war, dass das Rollo wieder angehalten hatte xD


Für Long-Messages gibt es auch noch das MultiExec-Register. Hier kann man einstellen, ob jede Long-Nachricht vom Aktor ausgewertet werden soll. Das beachtet die Lib bisher boch gar nicht.

Schaltaktoren beachten es auch nicht.
Ich werds gleich mal mit dem Dimmer testen, was passiert wenn ich es deaktiviere.


EDIT:
Ich hab mal Screenshots von der Einstellung "An / hoch dimmen / Aus / runter dimmen" angehängt.

Ich hab auch ne Beschreibung des Multiexec gefunden:
Zitat
Fernbedienungen senden bei langem Tastendruck in kurzen Abständen Telegramme mit gleichem Ereigniszähler. Im Aktor kann mit LONG_MULTIEXECUTE ausgewählt werden, ob jedes dieser Telegramme ausgeführt werden soll oder ob jeder lange Tastendruck nur genau einmal ausgeführt wird. Das mehrfache Ausführen ist z. B. für das manuelle Dimmen nötig oder um z. B. mit einem Schaltaktor eine Türöffnerfunktion zu realisieren, die den Öffner nur so lange betätigt, wie auch die Fernbedienungstaste betätigt wird.

Damit es wie ein Türöffner funktioniert muss man wahrscheinlich noch andere Expertenparameter ändern.
Könnte mir vorstellen, dass man dann nen OffDelay einbauen mus, dass der nach dem letzten Empfang des LongPress automatisch aus geht.
Mit diesen ganzen Experteneinstellungen hab ich mich noch nicht so ganz beschäftigt.
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 12 November 2017, 00:34:10
Hallo,

ich habe mir gerade einen RC8 (8-fach Fernbedienung) Arduino mit Asksin++ V2 aufgebaut und mit einer "haus-bus.de" Gira Tasterplatine verbunden.
Wenn ich in der CCU2 unter Geräte die Tastendrücke ansehe bekomme ich beim entsprechenden Tastendruck einen Zeitstempel.
Nun habe ich ein Programm erstellt, welches bei dem Druck einer Taste zwei Rolläden nach oben fahren soll, beim Druck einer anderen Taste die Rolläden nach unten.
Das Programm reagiert nciht auf die Tastendrücke der RC8 ?!?  Betätige ich aber in der CCU2 Gui den jeweiligen Button für "Taste kurz" fahren meine Rolläden wie gewünscht.

Nun bin ich ratlos... :-\

Grüße,
Jochen
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 November 2017, 06:50:47
Bei der CU2 kann ich leider nicht helfen. Wenn die tastdrücke so ankommen, scheint zumindest bei der RC-8 ja erst mal alles zu funktionieren.
Hast Du schon mal versucht die Rollädeb direkt mit der RC-8 zu verbinden ?
Du könnest auch mal den Master-Branch ausprobieren. Da gibt es auch ein paar Verbesserungen hinsichtilich der Tasten-Events.
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 12 November 2017, 10:14:49
Habe gerade versucht zwei weitere Tasten per Direktverbingung über die CCU2 mit einem anderen Aktor zu verbinden. Das Verhalten ist gleich: Tasten an der RC8 funktionieren nciht, Tasten in der CCU2 Gui schon.
Problem ist vermutlich, dass keine Konfigurationsdateien an die RC8 übertragen werden können. Zuerst kam eine Fehlermeldung (bei beiden Versuchen) und in den Servicemeldungen steht noch der Eintrag für die RC8: "Daten stehen zur Übertragung an".

Kann das wieder irgendwas mit der Verschlüsselten Übertragung der RC8 zu tun haben? Meine "SW4 Asksin++ Aktoren" funktionieren einwandfrei. 
Andere Version Flashen dauert etwas, da alles schon eingebaut ist.

Könnte man ein "HM 8-Kanal Sendemodul" auf Asksin++ abbilden, da dies ohne Verschlüsselung auskommt?
 
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 November 2017, 12:28:52
Du musst den Konfig-Taster drücken, um die Einstellungen an die RC-8 zu übertragen. AES funktioniert, wenn die Defines entsprechend gesetzt sind.
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 12 November 2017, 15:13:33
Ok, mit dem Konfig-Taster habe ich die direkt verknüpftern Aktoren zum laufen gebracht.

Habe dann "master" geflasht, jedoch ohne Unterschied. Dann mal die Übertragung für die Taster die an die CCU2 gehen auf "ungesichert" gestellt - siehe siehe da es geht.

Komisch ist nur, dass im Master-Branch nun mein "Taster2" welcher auf Arduino "3 / PD3" geht nicht mehr funktioniert ??? Die Konfiguration hat sich im Code zwischen V2 und master im .ino file nicht geändert....
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 November 2017, 00:11:21
Ok, mit dem Konfig-Taster habe ich die direkt verknüpftern Aktoren zum laufen gebracht.

Habe dann "master" geflasht, jedoch ohne Unterschied. Dann mal die Übertragung für die Taster die an die CCU2 gehen auf "ungesichert" gestellt - siehe siehe da es geht.

Komisch ist nur, dass im Master-Branch nun mein "Taster2" welcher auf Arduino "3 / PD3" geht nicht mehr funktioniert ??? Die Konfiguration hat sich im Code zwischen V2 und master im .ino file nicht geändert....

Kann durchaus sein, dass ich da mal wieder nen Bug eingebaut habe.
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 17 November 2017, 21:50:02
Hallo,

ich bräuchte da mal ein wenig hilfe von Euch. Ich habe versucht mir eine RC-8 aufzubauen. Leider funktioniert es bei mir nicht wirklich.
Ich konnte auch leider keine Schritt für Schritt Anleitung finden wie das mit der AskSin++ Library und den verschiedenen Examples überhaupt funktioniert. ich hoffe das habe ich mir richtig hingefriemelt.
Jedenfalls benutze ich einen Arduino-pro-mini (5V) und ein CC1101 Modul.
Ich komme soweit das ich an der Konsole zumindest folgendes sehe:
AskSin++ V2.0.0 (Nov 17 2017 20:54:36)
Address Space: 32 - 540
CC init1
CC Version: 17
 - ready
Bat: 51

Soweit ich es verstanden habe muss man den PIN8 kurz auf Masse ziehen um das Pairn auszulösen.
In FHEM bekomme ich dann zumindest folgendes Device angelegt:
Internals:
   CFGFN
   DEF        00DA00
   IODev      nanoCUL_868MHz
   LASTInputDev nanoCUL_868MHz
   MSGCNT     1
   NAME       HM_00DA00
   NOTIFYDEV  global
   NR         1401
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_00DA00_Btn_01
   channel_02 HM_00DA00_Btn_02
   channel_03 HM_00DA00_Btn_03
   channel_04 HM_00DA00_Btn_04
   channel_05 HM_00DA00_Btn_05
   channel_06 HM_00DA00_Btn_06
   channel_07 HM_00DA00_Btn_07
   channel_08 HM_00DA00_Btn_08
   nanoCUL_868MHz_MSGCNT 1
   nanoCUL_868MHz_RAWMSG A1A01840000DA000000000100DA484D524330306461303040080000::-68:nanoCUL_868MHz
   nanoCUL_868MHz_RSSI -68
   nanoCUL_868MHz_TIME 2017-11-17 21:00:41
   protCmdPend 17 CMDs_pending
   protState  CMDs_pending
   rssi_at_nanoCUL_868MHz lst:-68 avg:-68 max:-68 min:-68 cnt:1
   READINGS:
     2017-11-17 21:00:41   D-firmware      0.1
     2017-11-17 21:00:41   D-serialNr      HMRC00da00
     2017-11-17 21:00:41   R-pairCentral   set_0xF11111
     2017-11-17 21:25:53   state           CMDs_pending
   cmdStack:
     ++A001F1111100DA0000040000000000
     ++A001F1111100DA0001040000000001
     ++A001F1111100DA000103
     ++A001F1111100DA0002040000000001
     ++A001F1111100DA000203
     ++A001F1111100DA0003040000000001
     ++A001F1111100DA000303
     ++A001F1111100DA0004040000000001
     ++A001F1111100DA000403
     ++A001F1111100DA0005040000000001
     ++A001F1111100DA000503
     ++A001F1111100DA0006040000000001
     ++A001F1111100DA000603
     ++A001F1111100DA0007040000000001
     ++A001F1111100DA000703
     ++A001F1111100DA0008040000000001
     ++A001F1111100DA000803
   helper:
     HM_CMDNR   41
     PONtest    1
     cSnd       ,01F1111100DA0000050000000000
     cfgChkResult No regs found for:

HM_00DA00 type:remote -
list:peer register         :value
   0:      pairCentral      :set_0xF11111



     mId        00DA
     rxType     28
     supp_Pair_Rep 1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +00DA00,02,00,00
       nextSend   1510948841.36815
       prefIO
       rxt        2
       vccu
       p:
         00DA00
         00
         00
         00
     mRssi:
       mNo        01
       io:
         nanoCUL_868MHz -66
     prt:
       bErr       0
       sProc      2
     q:
       qReqConf
       qReqStat
     role:
       dev        1
     rssi:
       at_nanoCUL_868MHz:
         avg        -68
         cnt        1
         lst        -68
         max        -68
         min        -68
     shadowReg:
       RegL_00.    02:01 0A:F1 0B:11 0C:11
     tmpl:
   nb:
     cnt        1
Attributes:
   IODev      nanoCUL_868MHz
   IOgrp      VCCU1:nanoCUL_868MHz
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   0.1
   model      HM-RC-8
   room       CUL_HM
   serialNr   HMRC00da00
   subType    remote
   webCmd     getConfig:clear msgEvents

So, und jetzt gehts nicht weiter.
Ich kann tasten drücken was ich will und in Fhem kommt nichts an. Es geht auch kein GetConfig. Das einzige was im State steht, xx pendingCMD....
Ich sehe auf der Console das der Arduino zumindest beim tastendruck etwas tut:
01 debounce
01 pressed
01 released
<- 0B 03 86 40 00DA00 000000 01 01  - 442
01
01 debounce
01 pressed
01 released
<- 0B 04 86 40 00DA00 000000 01 02  - 465
Es kommt aber anscheinend in Fhem nichts an.

Kann mir jemand sagen wie ich dem Fehler auf die Spur komme? Ich wollte mit dem RC-8 starten weil ich dachte das es ein gutes Projekt zum Einstieg ist, aber das stellt sich ja nun als anders heraus :)

Danke
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 17 November 2017, 22:11:03
Hallo,

ich denke du musst erst die CMDs_pending abarbeiten lassen, immer wieder den config taster kurz betätigen.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 18 November 2017, 08:16:45
Das hab ich schon probiert, aber da tut sich überhaupt nichts. Ich habe das Gefühl das nur kurz nach dem reset etwas empfangen und gesendet wird und dann nichts mehr. Ich werde mal versuchen noch mal das pairing zu machen und den Abstand zur Antenne verringern. Obwohl der rssi bei - 61 liegt. Wäre ja eigentlich noch OK.
Titel: Antw:AskSin++ Library
Beitrag von: LuBeDa am 18 November 2017, 11:10:02
Hallo,

ich habe mal eine Frage zur Hardwareunterstützung der Library. Wird auch dieses Sendemodul TRX868-TFK-SL (Si4431) unterstützt oder "nur" CC1101?

Ludger
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 November 2017, 12:57:03
Das hab ich schon probiert, aber da tut sich überhaupt nichts. Ich habe das Gefühl das nur kurz nach dem reset etwas empfangen und gesendet wird und dann nichts mehr. Ich werde mal versuchen noch mal das pairing zu machen und den Abstand zur Antenne verringern. Obwohl der rssi bei - 61 liegt. Wäre ja eigentlich noch OK.

Hast Du dabei auch immer wieder den Konfig-Taster gedrückt ? Die Fernbedienung geht immer wieder "Schlafen" und muss durch den Konfig-Taster aufgeweckt werden.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 November 2017, 12:58:22
ich habe mal eine Frage zur Hardwareunterstützung der Library. Wird auch dieses Sendemodul TRX868-TFK-SL (Si4431) unterstützt oder "nur" CC1101?

Nein es wird nur das CC1101 Modul unterstützt.
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 18 November 2017, 14:41:45
Hallo Papa,

Konfigtatser heisst den pin8 kurz auf Masse setzen, oder?
Das habe ich gemacht.
Aber ich probier es heute Abend nochmal.

Danke erstmal


Gesendet von meinem VTR-L09 mit Tapatalk

Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 November 2017, 14:53:08
Ja - bis alle pendings abgearbeitet sind.
Wie sieht denn Deine Hardware aus ?
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 18 November 2017, 18:46:48
Also ich habe jetzt noch mal neu gepaired. Pairing klappt anscheinend, aber danach ist schluss.
Pairing sieht in der Konsole so aus:
-> 10 29 A0 01 F11111 00DA00 00 05 00 00 00 00 00  - 914
<- 0A 29 80 02 00DA00 F11111 00  - 917

Danach kann ich den Configtaster so oft drücken wie ich möchte, es passiert nichts. Es kommen in Fhem auch keine Events.

Meine Hardware ist wie folgt:
- Arduino mini pro (5V)
- CC1101 868MHz
- CC1101 nach diesem Schema angeschlossen (siehe Bild)
- Die Spannungsversorgung des CC1101 habe ich über einen Spannungsteiler auf 3,3V runter gebracht.
- Ansonsten habe ich den Sketch aus dem V2 branch und den Exapmles genommen.

Edit 19:54
- Mir ist gerade aufgefallen das die Übertragung von Signalen anscheinend nur kurz nach dem Reset funktioniert. Heißt, wenn ich den Reset Button auf dem Arduino board drück, abwarte bis ready in der Konsole steht, und dann einen Taster auf Masse ziehe kommt das Signal auch in Fhem an. Das klappt aber nur genau 1x. Danach geht anscheinend kein Signal mehr raus. Das Verhalten ist reproduzierbar. Empfangen tut der Arduino aber etwas. Ich bekomme nämlich ab und zu solche Meldungen, die von anderen HM-Devices stammen:
ignore 0D E9 A6 10 4A13D9 F11111 06 03 00 00  - 464
ignore 0D E9 80 02 F11111 4A13D9 01 01 00 00  - 474

Gruß
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 November 2017, 20:04:02
Kommen denn noch Ausgaben auf der Console, wenn wiederholt ein Taster gedrückt wird ?
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 19 November 2017, 12:29:53
Ja, die Konsole reagiert immer. Der arduino hängt sich vermutlich nicht auf.
Kann man denn einen debug modus einschalten um zu sehen wo es hängt?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 November 2017, 13:59:46
Bitte nochmal die Verkabelung checken. Vor allem GDO0. Wenn da nichts durch geht, wird nicht empfangen. Außerdem könntest Du auch mejr Consolenausgaben hier posten.
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 19 November 2017, 14:19:44
Hi, ich kann hier gern mehr posten, aber ich weiß ehrlich gesagt nicht so richtig was. Was brauchst Du denn?

Hier mal die KOnsolenausgabe nach dem Reset und mehrfachen Tastendruck. Nur der erste Tastendruck kommt in Fhem an, danach wie gesagt nichts mehr.

AskSin++ V2.0.0 (Nov 18 2017 19:28:30)
Address Space: 32 - 540
CC init1
CC Version: 14
 - ready
Bat: 50
03 debounce
03 released
<- 0B 01 86 40 00DA00 000000 03 00  - 387
03
01 debounce
01 pressed
01 released
<- 0B 02 86 40 00DA00 000000 01 00  - 414
01
ignore 0D AE 84 10 4484F1 F11111 06 01 AD 00  - 434
ignore 0D F0 A6 10 4A13D9 F11111 06 03 7B 00  - 443
ignore 0D F0 80 02 F11111 4A13D9 01 01 7B 00  - 452
08 debounce
08 released
<- 0B 03 86 40 00DA00 000000 08 00  - 463
08
08 debounce
08 released
<- 0B 04 86 40 00DA00 000000 08 01  - 485
08
08 debounce
08 released
<- 0B 05 86 40 00DA00 000000 08 02  - 506
08
03 debounce
03 released
<- 0B 06 86 40 00DA00 000000 03 01  - 528
03
01 debounce
01 pressed
01 released
<- 0B 07 86 40 00DA00 000000 01 01  - 551
01
07 debounce
07 released
<- 0B 08 86 40 00DA00 000000 07 00  - 573
07

Gibt es einen Debugmode den ich einschalten kann um zusätzliche Ausgaben zu bekommen?

EDIT: Ich habe gerade noch mal die Verkabelung gecheckt und alles noch mal mit neuer Hardware aufgebaut. Es stimmt alles.
Kann es daran liegen das ich einen 5V 16MHz Mini pro verwende? Muss ich da noch irgendwo etwas umstellen? Die Beispiele laufen ja auf einen 3,3V 8MHz mini-pro, oder?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 November 2017, 15:55:00
Er sendet an 000000 - ist also nicht richtig gepaired. Wie sieht denn der Pairing-Vorgang auf der Console aus?

Die Hardware sollte eigentlich gehen.

Der V2 sollte eigentlich funktionieren. Kannst ja trotzdem einfach mal den Master-Branch testen.
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 19 November 2017, 18:26:28
Hallo, stimmt. Das ist mir noch gar nicht aufgefallen.

Das Pairing funktioniert auch nur direkt nach dem reset. Allerdings kommt dann auch ein CRC-fail. In Fhem wird das Device aber angelegt.
Konsole sagt folgendes:
AskSin++ V2.0.0 (Nov 19 2017 14:26:40)
Address Space: 32 - 540
CC init1
CC Version: 14
 - ready
Bat: 50
 debounce
 pressed
 released
<- 1A 01 84 00 00DA00 000000 01 00 DA 48 4D 52 43 30 30 64 61 30 30 40 08 00 00  - 386
CRC Failed

-> 10 29 A0 01 F11111 00DA00 00 05 00 00 00 00 00  - 991
<- 0A 29 80 02 00DA00 F11111 00  - 994

Der Masterbranch hängt sich bei mir komplett auf sobald ich die Configtaste drücke. Dann blinkt die LED sehr schnell in Endlosschleife und auch der Konsole kommt nichts mehr. Sogar ein reset bringt Ihn nicht mehr zur Vernunft. Nur ein Abstecken von der Spannungsversorgung bringt etwas.

Gruß und Danke
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 20 November 2017, 06:20:25
@papa: hast du im Master jetzt nen watchdog eingerichtet?
Ich kenne das schnelle blinken und hängen bleiben bis zum Stecker ziehen, im Zusammenhang mit dem Bootloader.
Der vorinstalliert Bootloader kann den Watchdog nicht abschalten und da einige Register beim redet verloren gehen steht der Watchdog auf der kürzesten Zeit.
Daher muss man den Stecker ziehen.
Wenn man nen anderen Bootloader flasht, z.B. Optiboot dann funktioniert der Watchdog.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 November 2017, 08:03:59
@papa: hast du im Master jetzt nen watchdog eingerichtet?

Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 November 2017, 08:39:12
Der Masterbranch hängt sich bei mir komplett auf sobald ich die Configtaste drücke. Dann blinkt die LED sehr schnell in Endlosschleife und auch der Konsole kommt nichts mehr. Sogar ein reset bringt Ihn nicht mehr zur Vernunft. Nur ein Abstecken von der Spannungsversorgung bringt etwas.

Hm - im Master habe ich die Timer-Lib rausgeschmissen. Kann sein, dass das jetzt mit dem Nano nicht mehr funzt :-(

Ok - zurück in den V2 Branch. Ich habe da gerade die Sende-Routine gegen die vom Master ausgetauscht. Da hatten wir eh noch das Problem, dass das Senden von Bursts nicht funktioniert hat. Außerdem wird nicht gewartet, bis der CC1101 wieder von SEND auf RECEIVE geht. Das könnte mit dem Deep-Sleep der Fernbedienung Probleme geben, da unter Umständen der CC1101 in den Sleep geschickt wird, auch wenn das zu sendende Paket noch nicht vollständig übertragen wurde. Ich hatte da Probleme im Master, wenn der DEBUG aus war. Möglicherweise sind diese Probleme bei doppelten Takt viel häufiger. Ich benutze zum Testen immer nur 8MHz Systeme.

Hier mal mein vollständiger Log vom Pairen meiner RC-4 Testhardware:

AskSin++ V2.0.0 (Nov 20 2017 08:15:53)
Address Space: 32 - 305
CC init1
CC Version: 14
 - ready
Bat: 32
 debounce
 pressed
 released
<- 1A 01 80 00 789012 639087 11 00 08 70 61 70 61 33 33 33 33 33 33 40 04 00 00  - 391

-> 10 29 A0 01 639087 789012 00 05 00 00 00 00 00  - 3928
<- 0A 29 80 02 789012 639087 00  - 3930
-> 13 2A A0 01 639087 789012 00 08 02 01 0A 63 0B 90 0C 87  - 4106
<- 0A 2A 80 02 789012 639087 00  - 4120
-> 0B 2B A0 01 639087 789012 00 06  - 4288
<- 0A 2B 82 02 789012 639087 00  - 4290

Und dann ein getConfig hinterher:

debounce
 pressed
 released
<- 1A 02 80 00 789012 639087 11 00 08 70 61 70 61 33 33 33 33 33 33 40 04 00 00  - 20285

-> 10 2A A0 01 639087 789012 00 04 00 00 00 00 00  - 20432
<- 14 2A 80 10 789012 639087 02 02 01 0A 63 0B 90 0C 87 00 00  - 20441
-> 10 2B A0 01 639087 789012 01 04 00 00 00 00 01  - 20627
<- 12 2B 80 10 789012 639087 02 04 10 08 00 09 00 00 00  - 20633
-> 0B 2C A0 01 639087 789012 01 03  - 20815
<- 0E 2C 80 10 789012 639087 01 00 00 00 00  - 20819
-> 10 2D A0 01 639087 789012 02 04 00 00 00 00 01  - 21006
<- 12 2D 80 10 789012 639087 02 04 10 08 00 09 00 00 00  - 21012
-> 0B 2E A0 01 639087 789012 02 03  - 21194
<- 0E 2E 80 10 789012 639087 01 00 00 00 00  - 21198
-> 10 2F A0 01 639087 789012 03 04 00 00 00 00 01  - 21387
<- 12 2F 80 10 789012 639087 02 04 10 08 00 09 00 00 00  - 21391
-> 0B 30 A0 01 639087 789012 03 03  - 21573
<- 0E 30 80 10 789012 639087 01 00 00 00 00  - 21579
-> 10 31 A0 01 639087 789012 04 04 00 00 00 00 01  - 21766
<- 12 31 80 10 789012 639087 02 04 10 08 00 09 00 00 00  - 21770
-> 0B 32 A0 01 639087 789012 04 03  - 21954
<- 0E 32 80 10 789012 639087 01 00 00 00 00  - 21958

Du hast da auch noch das CRC Failed. Das heisst, es wurde ein Paket mit ungültiger CRC empfangen. Das deutet auch auf schlechten Empfang hin.
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 20 November 2017, 10:53:02
Hallo papa,

Meine Verwirrung ist komplett.
Ich habe die RC8 nun ans laufen bekommen, aber ich verstehe nicht wie und wieso es nun geht.
Ich habe spaßeshalber mal in der Arduino IDE das Board von 5V, 16MHz auf 3,3V 8MHz gestellt.
Die Spannungsversorgung vom Mini-pro hab ich dann auch auf 3,3V gestellt.
Und siehe da, es funktioniert jetzt. Ist mir da ein 3,3V anstatt ein 5V Arduino verkauft worden?
Zwischen der RC8 und Fhem funktioniert jetzt alles super  ;D
Jetzt habe ich nur noch das Problem das ich nun nichts vernüftiges mehr in der Konsole zu sehen bekommen. Nur noch seltsame Zeichen. Das heißt ja eigentlich das die Baudrate nicht stimmt, oder. Sie steht auf 57600, so stehts ja auch im Sketch. Das ist doch aber auch die korrekte Baudrate, oder?
Wie bekomme ich jetzt wieder die Ausgabe in der Konsole hin?

Danke
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 November 2017, 11:06:12
Mit welchen Branch hat es jetzt geklappt - Master oder (angepasstem) V2 ?

Damit bestätigt sich zumindest meine Vermutung, dass irgendwas mit dem Timing nicht passt. Das sollte sich aber auch fixen lassen.

Die Konsole ist jetzt wahrschenlich doppelt so schnell, wie angenommen. Die Software denkt 8MHz in Wahrheit ist aber ein 16MHz Quarz dran. Könnte sein, das 115200, in der IDE eingestellt, funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 20 November 2017, 11:20:29
Yap, Du hast recht.
Baudrate auf 115200 eingestellt und es läuft auch in der Konsole wieder richtiger Text auf.
Geklappt hat es jetzt mit dem neuen Branch V2.

Ich frage mich aber zusätzlich wieso denn der Arduino nun auch mit 3,3V läuft? Leider steht auf dem Quarz nichts weiter als "A.D". Somit weiß ich nicht was wirklich verbaut wurde.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 November 2017, 14:34:50
Yap, Du hast recht.
Baudrate auf 115200 eingestellt und es läuft auch in der Konsole wieder richtiger Text auf.
Geklappt hat es jetzt mit dem neuen Branch V2.

Kannst Du bitte nochmal mit 16MHz probieren ? Mich würde schon interessieren, was jetzt der Fix ist - das Umstellen auf 3.3V/8MHz oder die andere Senderoutine.

Ich frage mich aber zusätzlich wieso denn der Arduino nun auch mit 3,3V läuft? Leider steht auf dem Quarz nichts weiter als "A.D". Somit weiß ich nicht was wirklich verbaut wurde.

Mit 3.3V läuft er immer. Ist aber nicht offiziell für 16MHz zugelassen.
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 20 November 2017, 15:45:59
Hallo,

es läuft beides. Mit 5V und 16MHz sowie mit 3,3V und 8MHz, dann jedoch mit der falschen Baudrate in der Konsole.

Gruß
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 November 2017, 16:38:20
Also hat die Umstellung der Senderoutine den gewünschten Erfolg gebracht.
Titel: Antw:AskSin++ Library
Beitrag von: viegener am 20 November 2017, 16:59:38
Also hat die Umstellung der Senderoutine den gewünschten Erfolg gebracht.

Dann muss ich die Version waohl auch ausprobieren, allerdings geht bei mir momentan nur noch der Empfang  ???
ich bekomme kein Senden mehr hin und habe schon die Initialisierung des CC1101 nochmal von Hand gemacht...


Wenn bei der mit 8MhZ-Einstellung die doppelte Baudrate herauskommt, so ist Dein Quarz ein 16Mhz.
Ich habe umgekehrt einen 3,3V mal mit 16Mhz geflasht, dann kommt gar nichts mehr, denn die Hälfte von 57600 ist keine vernünftige baudrate 28800 baud...

Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 20 November 2017, 19:01:13
Ok, dann kann ich ja jetzt weiter experimentieren und rumspielen.
Gibt es eine Übersicht welche Projekte schon realisiert worden sind. Evtl. mit groben Schaltplänen zum Nachbauen?
Mir ist nämlich noch nicht klar wo ich etwas anpassen muss im Code wenn ich ein eigenes Device erstellen möchte.

Danke schon mal für den super Support, papa
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 November 2017, 22:14:09
Ok, dann kann ich ja jetzt weiter experimentieren und rumspielen.
Gibt es eine Übersicht welche Projekte schon realisiert worden sind. Evtl. mit groben Schaltplänen zum Nachbauen?
Mir ist nämlich noch nicht klar wo ich etwas anpassen muss im Code wenn ich ein eigenes Device erstellen möchte.

Danke schon mal für den super Support, papa

Die meisten Sachen sind umgesetzt. Ich will im Master alles so nach und nach auf die HM Universal Hardware (https://forum.fhem.de/index.php/topic,73954.msg656384.html#msg656384) umstellen. Dann lohnt sich sicherlich auch mal ein Wiki, wo alles irgendwie dokumentiert ist. Habe allerdings wenig Zeit und habe noch 1000 Ideen für die Lib  :)
Titel: Antw:AskSin++ Library
Beitrag von: viegener am 21 November 2017, 01:53:20
Also hat die Umstellung der Senderoutine den gewünschten Erfolg gebracht.

Hmm - jetzt habe ich auch die V2 probiert, bei mir gibt es aber leider keine Besserung.
Habe auch einige der Beispiele auf mein promini geflasht (z.B. HM-ES-TX-WM). Empfangen geht auch Homematic-Signale werden empfangen. Er behauptet auch zu senden. Allerdings kommt bei meinen HM-Lans beim Test nichts an.

Kein Absturz oder ähnliches es kommt einfach nichts an...


Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 November 2017, 08:00:39
Hm - komisch. Mal nen anderes CC1101 Modul probieren. Vielleicht hat das ja ne Macke.
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 21 November 2017, 08:49:09
Die meisten Sachen sind umgesetzt. Ich will im Master alles so nach und nach auf die HM Universal Hardware (https://forum.fhem.de/index.php/topic,73954.msg656384.html#msg656384) umstellen. Dann lohnt sich sicherlich auch mal ein Wiki, wo alles irgendwie dokumentiert ist. Habe allerdings wenig Zeit und habe noch 1000 Ideen für die Lib  :)
Danke für deinen super Support. Das mit der Zeit kenne ich leider auch.

Was wäre denn die bessere Wahl für einen eigenen HM sensor. Die asksinpp oder die Hm universal hardware?

Danke

Gesendet von meinem VTR-L09 mit Tapatalk

Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 November 2017, 09:24:22
Was wäre denn die bessere Wahl für einen eigenen HM sensor. Die asksinpp oder die Hm universal hardware?

Die Frage verstehe ich jetzt nicht. Das eine ist Software - das andere Hardware. Das gibt es kein ODER.
Titel: Antw:AskSin++ Library
Beitrag von: FEHMPiDi am 21 November 2017, 19:44:59
Also dann habe ich es falsch verstanden. Es ist also die Hardware zur AsksinPP  software? Dann ist alles klar.
Den Fensterdrehgriff Sensor muss ich auf jeden Fall nachbauen. Danke für den Link :)
Wenn ich das hinkriege brauche ich da auf jeden Fall 10 Sensoren. Erst mal muss ich aber den Thread durchackern um den aktuellen Stand zu wissen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 November 2017, 21:07:00
Da wollte mal jemand nen Wiki machen - aber leider ist da nichts draus geworden.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 November 2017, 21:18:13
Ok, mit dem Konfig-Taster habe ich die direkt verknüpftern Aktoren zum laufen gebracht.

Habe dann "master" geflasht, jedoch ohne Unterschied. Dann mal die Übertragung für die Taster die an die CCU2 gehen auf "ungesichert" gestellt - siehe siehe da es geht.

Komisch ist nur, dass im Master-Branch nun mein "Taster2" welcher auf Arduino "3 / PD3" geht nicht mehr funktioniert ??? Die Konfiguration hat sich im Code zwischen V2 und master im .ino file nicht geändert....

Hallo Jochen222

könntest Du mal probieren, ob mit dem SendFix auch Dein Problem gelöst ist ?
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 24 November 2017, 19:08:13
Hallo papa,

wie kann ich denn der AS++-Lib die Pin-Werte für externe Batteriemessung übergeben?

Also in etwa so (wenn ich die Pins 5 und 6 bei der externen Batteriemessung benutzen will):

typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef DualStatusLed<3,4> LedType;
typedef AskSin<LedType,BatterySensorExt(5,6),RadioType> BaseHal;
class Hal : public BaseHal {
public:
  void init (const HMID& id) {
    BaseHal::init(id);
    // init real time clock - 1 tick per second
    rtc.init();
    // measure battery every 1h
    battery.init(60UL*60,rtc,3300,2);
    battery.low(22);
    battery.critical(19);
  }

Da schmeisst der Compiler aber kräftig mit Fehlern um sich...

Martin
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 November 2017, 21:29:04
Arg . die BatterSensorExt Klasse habe ich irgendwie vergessen auf Templates umzustellen - gefixt und gerade eingecheckt. Wenn Du die Schaltung vom Dirks UniversalSensor nutzt, dann musst Du die BatterySensorUni Klasse verwenden

typedef DualStatusLed<3,4> LedType;
typedef BatterySensorUni<5,6> BatteryType;
typedef AskSin<LedType,BatteryType,RadioType> BaseHal;

oder jetzt auch mit den Ext

typedef DualStatusLed<3,4> LedType;
typedef BatterySensorExt<5,6> BatteryType;
typedef AskSin<LedType,BatteryType,RadioType> BaseHal;
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 24 November 2017, 23:11:16
Ja, ich habe die Schaltung von Dirk nachgebaut.
BatterySensorUni funktioniert damit!

Vielen Dank!
Martin
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 27 November 2017, 08:23:57
Hallo Jochen222

könntest Du mal probieren, ob mit dem SendFix auch Dein Problem gelöst ist ?


Hallo papa,

ja, Pin D3 funktioniert mit der neuen Version jetzt wieder (habe die aktuelle V2 Version getestet).


Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 27 November 2017, 08:28:11
Ich möchte mal den OTA Bootloader ausprobieren, verwende aber kein FHEM, sondern eine CCU2.

Wie das mit dem Flashen bzw. erstellen des HEX Files mit der Device ID funktioniert lt. Readme ist soweit klar. Folgendes ist mir noch nicht klar:

- Reagiert der OTA Bootloader auch noch auf serielle Daten oder nur noch über Funk?

- kann ich die erzeugten .eq3 Dateien als Firmware in die CCU2 hochladen so dass diese dann geflasht werden wie bei den original Geräten?

Grüße,
Jochen
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 November 2017, 10:22:45
Mit dem OTA-Bootloader kann nur über Funk geflasht werden. Ich habe selber keine CCU2 und kann deshalb nur raten, ob das geht. Ich denke schon. Allerdings sind die Firmwarefiles von eq3 normalerweise mit gzip komprimiert. Das müsstest Du vor dem Upload sicherlich noch machen.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 28 November 2017, 19:51:39
Hallo papa,

ist eigentlich geplant, die AS++ Lib auch für Rollos fit zu machen?
Wann in etwa?

Viele Grüße,
Martin
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 November 2017, 20:29:07
Ja auf jeden Fall. Will ja meine alten FS20 RSUs mal endlich gehen Homematic austauschen. Habe nur gerade nicht übermäßig viel Zeit hierfür.
Titel: Antw:AskSin++ Library
Beitrag von: oli82 am 29 November 2017, 08:58:09
Habe nur gerade nicht übermäßig viel Zeit hierfür.

Geht mir auch so. Will ebenfalls meine HM Lösung mit dem 4fach Batterieschalter gegen "was vernünftiges" tauschen
Titel: Antw:AskSin++ Library
Beitrag von: Fanavity am 09 Dezember 2017, 21:26:49
Hi,
Ich hoffe ich bin hier richtig. Ich würde gern folgenden Aktor nachbauen HM-LC-Sw4-SM, denn die uvp von 150€ finde ich echt happig.

Leider finde ich keine fertigen Boards mit Relais die bis 16a bei 230v schalten können.

Ich habe möchte einen Arduino pro, ein CC1101 Modul und einen feuchtraumkasten.

Damit sollen Steckdosen und Lampen geschaltet werden. Der Kasten wird in der Garage verbaut. Die Kabel sind bereits durch den Garten verlegt und können aktuell in der Garage per feuchtraumschalter geschaltet werden.

Würde mich freuen wenn ihr mir ein wenig weiter helfen würdet.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 09 Dezember 2017, 22:51:33
Hallo,

mit dem Universalplatinen Projekt von papa https://forum.fhem.de/index.php/topic,73954.0.html (https://forum.fhem.de/index.php/topic,73954.0.html)
und noch ein paar passende Relais dann kannst Du die den Schalter selbst bauen.
Die Platine habe ich mir schon gebaut und warte jetzt noch auf Relais von Ali. Ich habe mir aber kleinere bestellt da ich nur Beleuchtung schalten will.

Gruß Rolf
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Dezember 2017, 23:03:24
Oder so ein Relais-Board direkt an den Arduino.

https://www.amazon.de/Yizhet-Optokoppler-4-Channel-Modul-Brett-Raspberry-Blau/dp/B076VD1D28/ref=sr_1_2?s=lighting&ie=UTF8&qid=1512856889&sr=8-2&keywords=4+Kanal+5V+Relay (https://www.amazon.de/Yizhet-Optokoppler-4-Channel-Modul-Brett-Raspberry-Blau/dp/B076VD1D28/ref=sr_1_2?s=lighting&ie=UTF8&qid=1512856889&sr=8-2&keywords=4+Kanal+5V+Relay)
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 09 Dezember 2017, 23:06:48
Da muss man aber beachten das die über die masse geschaltet werden und nicht über V+.

Rolf
Titel: Antw:AskSin++ Library
Beitrag von: Fanavity am 09 Dezember 2017, 23:17:25
Vielendank für die schnelle antworten. Ich würde gern ein fertig board für einen ardhino nitzen, allerdings finde ich nur boards mit 10a relais, genau so wie das verlinkte.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 09 Dezember 2017, 23:23:50
Du könntest mit dem Relaisbord auch stärkere Relais schalten, vielleicht brauchen ja auch nicht alle 4 Kanäle 16A?

Rolf
Titel: Antw:AskSin++ Library
Beitrag von: Fanavity am 09 Dezember 2017, 23:30:15
Ich bräuchte lediglich ein 16a relai und drei 10a relais. Dann soll ich ein relai gegen ein 16a relai tauschen ? Ist das unbedenklich, bezüglich der abstände der relais? Kenne mich mit solchen boards leider noch nicht so aus.
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 09 Dezember 2017, 23:33:38
Du kannst doch das eine Relais mit dem auf der Platine schalten und dieses separat in der Box montieren.

Rolf
Titel: Antw:AskSin++ Library
Beitrag von: Horti am 09 Dezember 2017, 23:34:03
Hier https://forum.fhem.de/index.php/topic,48235.0.html (https://forum.fhem.de/index.php/topic,48235.0.html) ist eine Platine für einen Arduino Pro Mini, das Problem mit dem Relais bleibt das gleiche. Auf die Schnelle finde ich nur so was:
https://www.robotshop.com/en/16a-relay-module-arduino-compatible.html (https://www.robotshop.com/en/16a-relay-module-arduino-compatible.html)
Ist halt ne andere Preisklasse als die Relay-Boards mit 10A-Relais, aber in Summe wärest trotzdem deutlich unter 150EUR.
Titel: Antw:AskSin++ Library
Beitrag von: Fanavity am 09 Dezember 2017, 23:46:14
Vielen dank. Genau ao etwas habe ich gesucht. Davon werde ich mir mal 4 stück bestellen  :)
Titel: Antw:AskSin++ Library
Beitrag von: rvideobaer am 09 Dezember 2017, 23:51:19
Das Relais auf dem Bild hat aber auch nur 10A!

Rolf
Titel: Antw:AskSin++ Library
Beitrag von: joschi2009 am 10 Dezember 2017, 01:48:44
und wie wäre es mit einem solchen?
https://www.pollin.de/p/solid-state-relais-xssr-da2420-3-32-v-20-a-240-v-340470?&gclid=Cj0KCQiAsK7RBRDzARIsAM2pTZ-za0u4jlx0eJwRxPMuA542EnVxL8PyAFxGdp_Uqyg3qDREyl-hg90aAhySEALw_wcB (https://www.pollin.de/p/solid-state-relais-xssr-da2420-3-32-v-20-a-240-v-340470?&gclid=Cj0KCQiAsK7RBRDzARIsAM2pTZ-za0u4jlx0eJwRxPMuA542EnVxL8PyAFxGdp_Uqyg3qDREyl-hg90aAhySEALw_wcB)
https://www.amazon.de/Solid-State-Relais-Halbleiterrelais-24-380V/dp/B009SXHJD6 (https://www.amazon.de/Solid-State-Relais-Halbleiterrelais-24-380V/dp/B009SXHJD6)
Titel: Antw:AskSin++ Library
Beitrag von: viegener am 10 Dezember 2017, 11:42:14
@Fanavity: Ich mach hier nicht gern den Spielverderber, aber wenn Du wirklich 230V / 16A schalten willst, und das auch noch in eienr feuchten/potentiell auch staubigen Umgebung, würde ich keine Chinaplatinen (und vermutlich auch kein eigenes Design nehmen) - 3600W zu schalten und auch durch die PLatine/Relais zu führen erfordert etwas Aufwand, damit hier nicht nach einer Woche durch Überlast oder nach einem Jahr durch Kriechstrom ein Brand entsteht. Ohne entsprechende Ausbildung würde ich mich da gar nicht dran wagen, sondern eher eine andere Lösung nehmen.
Titel: Antw:AskSin++ Library
Beitrag von: Fanavity am 11 Dezember 2017, 21:22:09
Vielen dank für die vielen antworten. Aus den zuletzt genannte 'n gründen hab ich mich dazu entschlossen den sonoff 4ch pro zu nehmen. Dieser ist günstig, und kann auf der hutschiene montiert werden. Dabei werde ich mich auf die 2200w beschränken.  Denke aber das es die sicherste Lösung ist.

Bei dem sonoff gibt es keine Möglichkeit eine hm ähnliche fw zu flashen oder ?
Titel: Antw:AskSin++ Library
Beitrag von: oli82 am 31 Januar 2018, 15:53:35
Hat zufällig jemand die library von dem CC1101 Modul für Eagle?
Baue gerade den Rolladenaktor Unterputz und da vereinfacht jedes Bauteil den Schaltplan ungemein ;)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 31 Januar 2018, 22:59:18
Hat zufällig jemand die library von dem CC1101 Modul für Eagle?
Baue gerade den Rolladenaktor Unterputz und da vereinfacht jedes Bauteil den Schaltplan ungemein ;)

Für KiCad hätte ich da was.

Bin auch an einem Rolladenaktor interessiert. Ich habe noch ein paar FS20 RSU, die ersetzt werden wollen. Leider ist mein Versuch, die RSUs auf Homematic zu "updaten" daran gescheitert, dass die Spannungsversorgung der FS20 RSUs zu schwach für den AVR+CC1101 sind. Beim Versuch, das anzupassen, ist mein Bastel-RSU leider durch eine kleine Unachtsamkeit durch mich abgeraucht.
Titel: Antw:AskSin++ Library
Beitrag von: oli82 am 01 Februar 2018, 10:16:03
...ist mein Bastel-RSU leider durch eine kleine Unachtsamkeit durch mich abgeraucht.

Hab mir mittlerweile das Bauteil gezeichnet.
Mein Hauptproblem ist gerade, dass ich so klein wie möglich werde und trotzdem die Richtlinien einhalte (und natürlich nicht zu sehr bei HM abkupfere) ;)
Von fertigen AC/DC Wandlern musste ich schon Abstand gewinnen, weil ich sonst am Ende nicht mehr in eine UP Dose komme.

Kannst du mir mal Bilder von dem RSU offen schicken? Gerne auch PN ;)
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 09 Februar 2018, 12:26:42
Hallo,

ich habe mir mal folgndes MP3 Modul besorgt:

http://www.dx.com/de/p/uart-control-serial-mp3-music-player-module-for-arduino-avr-arm-pic-blue-silver-342439
bzw.:
http://www.amazingtips247.co.uk/2015/11/how-to-play-sound-tracks-with-catalex.html
Datenblatt:
http://geekmatic.in.ua/pdf/Catalex_MP3_board.pdf

Damit kann man über einfach gehaltene serielle Kommandos MP3´s auf einer microSD Karte abspielen. Das funktioniert auch soweit! Cool wäre es jetzt, das Modul mit einem
Homematic Aktor zu verheiraten, so dass verschiedene Ansagen wie z.B. "Alarm scharf" angegesagt werden können.
Im einfachsten Fall könnte man ja einen Schaltaktor z.B. SW4 verwenden für 4 Ansagen. Die AsksinPP Beispiele geben seriell Debugausgaben heraus. Gibt es eine einfache Möglichkeit diese abzuschalten und serielle Kommandos bei einer Aktion zu ersetzten. Sprich statt IO1 zu schalten müsste z.B. "7E FF 06 03 00 00 01 EF" mit 9600 Baud ausgegeben werden. Wenn die Idee Anklang findet könnte man sich auch Gedanken über einen Nachbau des original Moduls machen.

Grüße,
Jochen
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Februar 2018, 19:48:15
Die Debug-Ausgaben lassen sich durch folgenden Code am Anfang des Sketches deaktivieren:
#define NDEBUGAls HM-Gerät würde ich ja eher nen Dimmer oder Blindaktor erst mal zum Testen nehmen. Da kann man die Prozente von 0 bis 100 direkt einstellen. Sprich man kann 100 Samples adressieren.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 17 Februar 2018, 21:11:35
Wie schwierig wäre denn eine Portierung der Library auf einen STM8 ?
Kenne mich mit STM leider überhaupt nicht aus, ist der ähnlich zum STM32?

Grund meiner Frage: Ich habe das 8Kanal-Empfangsmodul HM-MOD-Re-8 verbaut, wollte damit zusammen mit einem 8Kanal-China-Relais-Modul Lampen schalten
Wichtig waren mir die vorhandenen Eingänge, ich will auch Taster direkt anschliessen damit das Ganze ohne Funk, FHEM usw funktioniert.

Leider musste ich aber lernen, das EQ3 nicht zu Ende gedacht hat, man kann das Modul z.B. durch 4 sec Taster drücken in den Konfigurationsmodus bringen.

Wäre das Teil evtl. ein neuer Spielplatz für die AskSin++-Library?  Es wäre mit ca. 20€ rel. günstig wenn man keine Lust zum löten hat
Verbaut ist ein stm8l151c8u6

Viele Grüße
Klaus
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Februar 2018, 21:14:17
Wie schwierig wäre denn eine Portierung der Library auf einen STM8 ?

Unmöglich - für den STM8 gibt es keinen C++ Compiler.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 17 Februar 2018, 21:29:17
schade, habe auf die Schnelle das hier gefunden:
http://www.colecovision.eu/stm8/compilers.shtml (http://www.colecovision.eu/stm8/compilers.shtml)
aber kenne mich wie gesagt null damit aus

Gibt es eine andere Möglichkeit? Wird wohl darauf hinaus laufen, was mit dem STM32 zu basteln?  Beim AtMega328 wird es wohl mehr als eng mit 8 Inputs + 8 Outputs?

Das EQ3 aber auch für jedes neue Teil wieder einen anderen Controller einsetzen muss....

Weiss jemand welcher Controller im HM-LC-Sw4-DR (4fach-Schaltaktor für Hutschienmontage) verbaut ist? Könnte man da Eingänge nachrüsten?

Oder habt ihr andere gute Ideen?

Grüße
Klaus
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 17 Februar 2018, 21:31:33
Beim AtMega328 wird es wohl mehr als eng mit 8 Inputs + 8 Outputs?

Oder habt ihr andere gute Ideen?

Grüße
Klaus

Am Mega328P könntest du mit einem I2C PortExpander noch zusätzliche I/O Ports schaffen...
https://playground.arduino.cc/Code/I2CPortExpander8574 (https://playground.arduino.cc/Code/I2CPortExpander8574)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Februar 2018, 21:33:20
Ach - da warst Du schneller. MCP23008 würde z.B. auch gehen

http://ww1.microchip.com/downloads/en/DeviceDoc/21919e.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/21919e.pdf)
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 17 Februar 2018, 21:38:52