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.github.io/).

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
Zitat von: Dietmar63 am 17 Oktober 2016, 17:30:44
Gibt es eine Möglichkeit die Zeit abzufragen getMillis ()
Ist so eine Funktion geplant?

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

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

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

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

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

Natürlich. Von FHEM aus Schreiben und getConfig.

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

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

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

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

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

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

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

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

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


void WDTEnable (uint8_t period) {

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

}


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

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

micky0867
Könnte vielleicht auch ein Fan von dieser Variante der AskSin werden. Zu NewAskSin gibt es ja kaum Unterstützung.
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 18 Oktober 2016, 00:01:34
Hallo,
ZitatKönnte vielleicht auch ein Fan von dieser Variante der AskSin werden. Zu NewAskSin gibt es ja kaum Unterstützung.

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

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

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

Martin
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
Zitat von: Dietmar63 am 19 Oktober 2016, 20:48:06
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
Zitat 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.

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
Zitat von: Dietmar63 am 19 Oktober 2016, 23:08:37
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
Zitat von: Dietmar63 am 20 Oktober 2016, 01:02:36
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
Zitat von: papa am 20 Oktober 2016, 08:11:43
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
Zitat von: papa am 20 Oktober 2016, 08:19:30
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
Zitat von: papa am 20 Oktober 2016, 22:06:53
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
Zitat von: Dietmar63 am 21 Oktober 2016, 15:36:11
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
Zitat 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

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

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.

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

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.

Zitat von: Dietmar63 am 24 Oktober 2016, 09:03:33
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
Zitat von: MBHG am 24 Oktober 2016, 09:24:14
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"/>

ZitatFü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
Zitat von: Dietmar63 am 25 Oktober 2016, 09:40:47
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.

Zitat von: Dietmar63 am 25 Oktober 2016, 09:40:47
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
Zitat 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

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

Zitat von: lech am 27 Oktober 2016, 19:51:05
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
Zitat von: lech am 27 Oktober 2016, 19:51:05
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
Zitat von: Dietmar63 am 28 Oktober 2016, 01:33:41
  • 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,

ZitatSollte 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
ZitatDie 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 )


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

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

ZitatDas 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
Zitat von: lech am 27 Oktober 2016, 20:54:30
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
ZitatIch 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
Zitat von: lech am 29 Oktober 2016, 09:16: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
Zitat von: Snobs am 29 Oktober 2016, 17:17:29
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.

Zitat von: Snobs am 29 Oktober 2016, 17:17:29
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
Zitat von: svenson08 am 01 November 2016, 19:51:23
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
Zitat 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.

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
Zitat von: Dietmar63 am 28 Oktober 2016, 12:49:56
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
ZitatKannst 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
Zitat von: lech am 03 November 2016, 00:21:37
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
ZitatIch 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
Zitat 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.

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
Zitat von: Dietmar63 am 03 November 2016, 23:42:20
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
ZitatEs 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
ZitatHast 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
Zitat von: lech am 04 November 2016, 15:25:55
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.

Zitat von: lech am 04 November 2016, 15:25:55
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.

Zitat von: lech am 04 November 2016, 15:25:55
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
Zitat 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.

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.

Zitat von: Dietmar63 am 13 November 2016, 18:41:46
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
Zitat 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

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

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
Zitat von: Dietmar63 am 30 Dezember 2016, 16:26:35
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
Zitat von: kadettilac89 am 19 Dezember 2016, 21:41:48
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
Zitat von: plombe am 31 Januar 2017, 20:26:29
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
Zitat 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.

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
Zitat von: plombe am 08 Februar 2017, 22:05:50
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
Zitat1.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
Zitat von: plombe am 10 Februar 2017, 19:14:32
  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
Zitat von: Linef am 10 Februar 2017, 21:28:05
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
Zitat 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.

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
Zitat von: papa am 10 Februar 2017, 22:18:08
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
Zitat 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.

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
Zitat von: Dietmar63 am 11 Februar 2017, 00:22:43
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 ?

Zitat von: Dietmar63 am 11 Februar 2017, 00:22:43
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
Zitat von: papa am 12 Februar 2017, 10:02:38
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
Zitat von: Linef am 12 Februar 2017, 10:18:51
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
Zitat 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?

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

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
ZitatSind denn 2.2 Volt als Minimalspannung realistisch?

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

ZitatOperating 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
Zitat von: plombe am 13 Februar 2017, 10:18:52
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
Zitat 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.

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

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
Zitat von: micky0867 am 14 Februar 2017, 19:50:21
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
Zitat von: Dietmar63 am 17 Februar 2017, 10:27:01
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.

Zitat von: Dietmar63 am 17 Februar 2017, 10:27:01
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.

Zitat von: Dietmar63 am 17 Februar 2017, 10:27:01
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
Zitat 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.

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

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

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
Zitat von: Xent am 14 März 2017, 09:47:36
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 :-(

Zitat von: Xent am 14 März 2017, 09:47:36
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
ZitatModel für den Universalsensor: 0xF1, 0x01
Subtyp:  0x70.
Dafür gibt es wohl keine XML-Definition (oder?).
leider: F101 ist homebrew

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

ZitatFü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.

ZitatIch 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
ZitatWenn 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
Zitat von: xkalle01 am 20 März 2017, 12:07:56
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
Zitat 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.

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
Zitat von: Dietmar63 am 21 März 2017, 22:12:50
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.

Zitat von: Dietmar63 am 21 März 2017, 22:12:50
Warum ist das nicht bei anderen uin32_t Variablen auch?

Welche ???

Zitat von: Dietmar63 am 21 März 2017, 22:12:50
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
Zitat 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.

Bestätigt. Klappt! Danke!
Titel: Antw:AskSin++ Library
Beitrag von: kadettilac89 am 27 März 2017, 13:19:08
Zitat 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.


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

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.

Zitat von: east am 09 Mai 2017, 17:16:11
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
Zitat von: east am 11 Mai 2017, 23:51:22
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.


Zitat von: east am 11 Mai 2017, 23:51:22
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
Zitat 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?

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

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

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
Zitat 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.
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:
ZitatAskSin++ 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
Zitat von: 0xFFFF am 16 Mai 2017, 21:00:38
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
Zitat von: east am 17 Mai 2017, 11:05:28
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.

Zitat von: east am 17 Mai 2017, 11:05:28
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
Zitat von: Xent am 28 Juni 2017, 11:22:15
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
Zitat von: Xent am 09 Juli 2017, 19:51:52
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
Zitat von: capt_bluebaer am 09 Juli 2017, 19:24:41
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
Zitat von: Xent am 09 Juli 2017, 19:51:52
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
Zitat von: papa am 09 Juli 2017, 22:04:30
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
Zitat 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.
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
Zitat von: papa am 12 Juli 2017, 21:51:51
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
Zitat von: Xent am 13 Juli 2017, 11:19:19
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
Zitat von: Xent am 13 Juli 2017, 10:52:42
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
Zitat von: Xent am 18 Juli 2017, 21:39:38
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
Zitat von: Xent am 31 Juli 2017, 18:49:48
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
Zitat von: Xent am 01 August 2017, 11:42:32
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
Zitat von: Xent am 03 August 2017, 22:07:10
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
Zitat von: Xent am 04 August 2017, 09:18:59
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
Zitat 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.

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
Zitat von: Xent am 26 August 2017, 07:35:07
Moin,
wie schauts mit meinen Änderungen aus?
Konntest du schon weiter testen?

Nein -leider noch nicht.

Zitat von: Xent am 26 August 2017, 07:35:07
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
Zitat von: rippi46 am 27 August 2017, 21:42:21
@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.

Zitat von: rippi46 am 27 August 2017, 21:42:21
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
Zitat 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?

Nein - einfach in eine Datei umleiten

./prepota HM-SEC-MDIR.ino.hex > HM-SEC-MDIR.ino.hex.eq3


Zitat von: rippi46 am 28 August 2017, 13:57:37
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
Zitat 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.

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

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
Zitat von: rvideobaer am 28 August 2017, 21:37:55
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
Zitat 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.

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
Zitat von: rvideobaer am 28 August 2017, 21:37:55
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
Zitat von: rvideobaer am 29 August 2017, 21:23:23
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
Zitat von: rvideobaer am 31 August 2017, 18:46:59
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
Zitat 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

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

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
Zitat von: papa am 14 September 2017, 15:46:07
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
Zitat von: Xent am 15 September 2017, 09:16:09
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
Zitat 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.

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

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
Zitat von: Xent am 19 September 2017, 17:53:15
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

ZitatHab 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
Zitat 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?

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

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
Zitat von: papa am 03 Oktober 2017, 20:03: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
Zitat 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.

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
Zitat von: papa am 08 Oktober 2017, 12:18:23
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


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

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

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
Zitat von: papa am 15 Oktober 2017, 13:27:24
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 88
Hier 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
Zitat von: papa am 18 Oktober 2017, 12:54:03
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
Zitat von: papa am 18 Oktober 2017, 12:54:03
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.

Zitat von: Xent am 18 Oktober 2017, 22:47:43
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.

Zitat von: Xent am 18 Oktober 2017, 22:47:43
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
Zitat von: papa am 19 Oktober 2017, 09:38:13
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


Zitat von: papa am 19 Oktober 2017, 09:38:13
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:
ZitatFernbedienungen 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
Zitat 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....

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

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
Zitat von: LuBeDa am 18 November 2017, 11:10:02
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
Zitat von: Xent am 20 November 2017, 06:20:25
@papa: hast du im Master jetzt nen watchdog eingerichtet?

Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 November 2017, 08:39:12
Zitat von: FEHMPiDi am 19 November 2017, 18:26:28
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
Zitat 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.

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.

Zitat von: FEHMPiDi am 20 November 2017, 11:20:29
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
Zitat von: papa am 20 November 2017, 16:38:20
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
Zitat 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

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
Zitat von: papa am 20 November 2017, 16:38: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
Zitat von: papa am 20 November 2017, 22:14: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
Zitat von: FEHMPiDi am 21 November 2017, 08:49:09
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
Zitat 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....

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
Zitat von: papa am 21 November 2017, 21:18:13
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
Zitat von: papa am 28 November 2017, 20:29:07
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
Zitat 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 ;)

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
Zitat von: papa am 31 Januar 2018, 22:59:18
...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 NDEBUG
Als 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
Zitat von: Klaus0815 am 17 Februar 2018, 21:11:35
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
Zitat von: Klaus0815 am 17 Februar 2018, 21:29:17
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
Zitat 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)

Den MCP kannte ich noch gar nicht... Schau ich mir mal an!
Mit dem 8574 hab ich gute (zumindest keine negativen) Erfahrungen gemacht.

Aber stellt sich die Frage, ob jemand  ::) einen 8fach Empfänger (oder auch Sender) coden möchte  ???
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 17 Februar 2018, 22:03:44
ZitatAber stellt sich die Frage, ob jemand  ::) einen 8fach Empfänger (oder auch Sender) coden möchte  ???

Da gehts bei mir leider nicht ums wollen sondern ums können - ich kann es nicht :-(
mit ESP8266 / ESPEasy würde ich es wahrscheinlich hinbekommen, wäre aber gerne bei Homematic geblieben.

Vielleicht kommt ja noch ein guter Vorschlag, 4 2Kanal-Schaltaktoren will ich auf alle Fälle nicht einsetzen :-)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Februar 2018, 09:09:19
Also ein 8 Kanal Schaltaktor wäre sicherlich recht unproblematisch. Die Ausgänge könnten mit dem MCP23008 geschaltet werden. Dafür gibt es auch ne Arduino-Library. Die Taster kommen alle direkt an die Pins des ATMega328 ran. Unter Umständen sollte noch ein externer EEProm für die Peerlisten mit drauf - z.B. at24c32 mit 4k.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 18 Februar 2018, 13:34:31
Wäre es dann nicht einfacher, einen STM32 zu nutzen? Gibt es dazu auch bereits Platinenlayouts?

Muss mal schauen was ich mache, vielleicht läuft es doch auch einfach auf 2 Deiner universal-Basis-Platinen raus, damit müsste es doch auch gehen?

Das ELV-Board wäre halt schön gewesen, da es genügend Ein/Ausgänge mitbringt, die Ausgänge bereits gepuffert sind.
DIe benutzen übrigens auch ein externes EEPROM

Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Februar 2018, 14:15:07
Zitat von: Klaus0815 am 18 Februar 2018, 13:34:31
Wäre es dann nicht einfacher, einen STM32 zu nutzen? Gibt es dazu auch bereits Platinenlayouts?
Wahrscheinlich ja. Nein.
Zitat von: Klaus0815 am 18 Februar 2018, 13:34:31
Muss mal schauen was ich mache, vielleicht läuft es doch auch einfach auf 2 Deiner universal-Basis-Platinen raus, damit müsste es doch auch gehen?
Sollte gehen. Sind dann halt eben 2 Devices.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 18 Februar 2018, 19:44:52
Ich bin kürzlich bei der Suche nach Anleitungen für eigene HomeMatic Sender hier gelandet, ein beeindruckendes Projekt, tolle Arbeit, vielen Dank.

Eine kurze Frage hätte ich. Ich habe mir einige Beispiele in \examples auf github angeschaut. Ich möchte ein paar Geräte wie den HM-SCI-3-FM aufbauen
https://www.elv.de/homematic-kontakt-interface-fuer-oeffner-und-schliesserkontake-komplettbausatz.html (https://www.elv.de/homematic-kontakt-interface-fuer-oeffner-und-schliesserkontake-komplettbausatz.html)
dieser hat ja im WebUI einen Offen- und Geschlossen Zustand.

Ich habe mir z.B. HM-RC-8.ino angeschaut, ich vermute aber das wäre nicht 100% richtig, da dort ein Zustand Taste gedrückt übertragen wird und wahrscheinlich der Befehl wiederholt wird solange die Taste gedrückt ist.
Wie würde ich einen "statischen" Offen/Geschlossen Kontakt wie der HM-SCI-3-FM im Arduino Code konfigurieren? Also einen Kontakt der länger seinen Zustand halten kann und nur bei Änderung das an die Zentrale meldet?

Vielen Dank & Grüße,
Tom
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 18 Februar 2018, 20:24:45
Zitat von: Tom Major am 18 Februar 2018, 19:44:52
Ich möchte ein paar Geräte wie den HM-SCI-3-FM aufbauen

Moin!
Ich habe aus dem ThreeState-Sketch des RHS einen HM-SCI3-FM abgewandelt.
Funktioniert bestens.
Code ist hier: https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples/HM-SCI3-FM (https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples/HM-SCI3-FM)
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 18 Februar 2018, 23:47:02
Vielen Dank, jp112sdl, für den link, das hilft mir weiter.

Ich versuche mir ein grundsätzliches Verständnis über den notwendigen code für so einen sketch zu schaffen,
z.B. sowas hier:
DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)
...

und viele andere Stellen, gibt es da irgendwo Docs um das zu verstehen?
(außer der Variante, die kompletten sourcen zu lesen und versuchen zu begreifen  :-\)
Danke,
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 19 Februar 2018, 06:27:54
Zitat von: Tom Major am 18 Februar 2018, 23:47:02
... gibt es da irgendwo Docs um das zu verstehen?

Nein, gibt es leider nicht. Der Code ist die Doku  :D

Ich bin auch kein Profi-Programmierer und in den Libs steckt ganz viel neue Syntax für mein Hirn... alles keine leichte Kost.
Zumal jeder einen anderen Programmierstil hat und man erstmal durchsteigen muss. So versteht ein Hamburger den Münchner schlecht, auch wenn beide deutsch sprechen.  :)

Ich sag mir halt: Kaputt machen kann ich nichts. Hab viel rumprobiert...
Vieles hat geklappt, ein paar Sachen haben nicht geklappt.

Aber die Zusammenarbeit mit papa klappt sehr gut!
Der HM-Sec-SD Sketch ist erst vor kurzem auf meinen Wunsch entstanden, wobei er den Code geschrieben hat und ich ihn pausenlos mit Log- und Testreihen versorgt habe.

Momentan hänge ich auch noch an einem Sketch fest, den ich nicht zum Laufen bekomme (HM-WDS30-OT2-SM). Aber ich bin hartnäckig und geb nicht auf  8) ;D
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 Februar 2018, 09:44:27
Zitat von: Tom Major am 18 Februar 2018, 23:47:02
Vielen Dank, jp112sdl, für den link, das hilft mir weiter.

Ich versuche mir ein grundsätzliches Verständnis über den notwendigen code für so einen sketch zu schaffen,
z.B. sowas hier:
DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)
...

und viele andere Stellen, gibt es da irgendwo Docs um das zu verstehen?
(außer der Variante, die kompletten sourcen zu lesen und versuchen zu begreifen  :-\)

Tja - da habe ich leider nur eine schlechte Nachricht für Dich. Die Lib nutzt so viel wie möglich von C++ (Vererbung, Templates), C Macros und dem Wissen, wie ein Compiler arbeitet, um auf dem Sketch-Level eine einfache API zu haben. Das bedingt meist aber auch, dass es unterhalb dieser einfachen API recht ordentlich zu Sache geht. Erschwerend kommt noch  hinzu, dass nur begrenzt Resourcen Flash/RAM zur Verfügung stehen, was die Sache nicht unbedingt einfacher macht. Für C++ Anfänger sind die Innereien sicherlich nicht geeignet. Aber ich hoffe, dass auf dem oberen Level, auch eher unerfahrende Entwickler in der Lage sind, die Examples zu verstehen. Da ich immer noch nicht mit allen Sachen so richtig zufrieden bin, lohnt sich eine tiefgreifende Doku auch noch nicht. Ich habe keine Lust/Zeit, ständig die Examples und eine Doku anzupassen. Wobei die Doku ja auch noch erst entstehen muss.

Das oben erwähnte Macro definiert die verfügbaren Register für eine bestimmte Liste und erzeugt eine Klasse mit statischen Funktionen, die dann als Template-Argument in die generische RegisterListen-Klasse kommt und das Mapping zwischen Register-Nummer und relative Position in der Liste im EEProm macht.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 20 Februar 2018, 01:04:46
Hallo papa,
Danke für die Info und großen Respekt für Deine Arbeit. Habe mir den code (etwas) näher angeschaut, da steckt wahnsinnig viel Arbeit und know-how drin.
Bin selber u.a. ein C++ Programmierer, aber nicht auf dem Templates Niveau, welches Du betreibst, dazu mache ich das dann doch nicht oft genug.

ZitatAber ich hoffe, dass auf dem oberen Level, auch eher unerfahrende Entwickler in der Lage sind, die Examples zu verstehen.
Da habe ich etwas Zweifel, vielleicht ein rudimentäres Verständnis, aber wenn's ans Nachbauen oder Modifizieren geht, ich glaube da wirst Du ohne Doku mehr oder weniger immer gefragt sein.

Ich habe mich z.B. mit dem HM-SEC-WDS beschäftigt, den ich vielleicht als erstes mal testweise baue weil ich so ein Gerät sowie so anschaffen wollte.
Ich habe auf obersten Level verstanden:
- das Pining vom Arduino (außer den Sensor Pins)
- dass die beiden low Batt Schwellen auf 2,2V und 1,9V gesetzt werden und die Batt jede Stunde gemessen wird.  :)

Ich habe auf obersten Level nicht verstanden, wäre aber m.E. für den Nachbau wichtig:
- wie werden die Pins Sensor Pins 1 und 2 angeschlossen, dass die Zuordnung Dry/Wet korrekt ist?
- Wie ist die Beschaltung der Sensor Pins?
- Wie oft werden die Sensor Pins gemessen?
Ich vermute diese Info wird man auf obersten Level nicht finden und dann z.B. das Messintervall für dieses device in den sourcen zu finden habe ich nicht geschafft..

Danke,
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 20 Februar 2018, 06:37:26
Moin!
Ich häng mich mal kurz mit rein... wenn ich falsch liege, möge papa es korrigieren  :)

Soweit ich [bin auch nur Freizeitprogrammierer mit rudimentärsten C(++) Kenntnissen] verstanden habe:

Zitat von: Tom Major am 20 Februar 2018, 01:04:46
- Wie oft werden die Sensor Pins gemessen?
Ich vermute diese Info wird man auf obersten Level nicht finden und dann z.B. das Messintervall für dieses device in den sourcen zu finden habe ich nicht geschafft..

In der ThreeState.h (Master-Branch, Stand: jetzt) Zeile 68:

    // start polling
    set(seconds2ticks(1));


Heißt: Mit jedem Takt werden auch die Pins abgefragt. Nun liegt es an dir - je nachdem was du am 328 angeschlossen hast... 32.768khz, 8MHz, 16MHz, ... - wie oft die Pins abgefragt werden.


Zitat von: Tom Major am 20 Februar 2018, 01:04:46
- wie werden die Pins Sensor Pins 1 und 2 angeschlossen, dass die Zuordnung Dry/Wet korrekt ist?


#define SENS1_PIN 6 //14
#define SENS2_PIN 3 //15

...

msgForPosA(1); // DRY
msgForPosB(3); // WET
msgForPosC(2); // WATER


Das (default)-mapping ist in der ThreeState.h zu finden

  // map pins to pos     00   01   10   11
  uint8_t posmap[4] = {Positions::PosC,Positions::PosC,Positions::PosB,Positions::PosA};


Heißt:






SENS1_PINSENS2_PIN
TrockenHH
FeuchtHL
NassLL
NassLH


Zitat von: Tom Major am 20 Februar 2018, 01:04:46
- Wie ist die Beschaltung der Sensor Pins?

Die Pins werden durch eine (von dir bereit gestellte) externe Schaltung auf H oder L gesetzt.
Es wird hier keine Feuchtigkeit gemessen!

Güßlies,
JP
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Februar 2018, 08:05:47
Zitat von: jp112sdl am 20 Februar 2018, 06:37:26
Moin!
Ich häng mich mal kurz mit rein... wenn ich falsch liege, möge papa es korrigieren  :)

Soweit ich [bin auch nur Freizeitprogrammierer mit rudimentärsten C(++) Kenntnissen] verstanden habe:

In der ThreeState.h (Master-Branch, Stand: jetzt) Zeile 68:

    // start polling
    set(seconds2ticks(1));


Heißt: Mit jedem Takt werden auch die Pins abgefragt. Nun liegt es an dir - je nachdem was du am 328 angeschlossen hast... 32.768khz, 8MHz, 16MHz, ... - wie oft die Pins abgefragt werden.

Nicht ganz. Der ThreeStateChannel ist von Alarm abheleitet. Alarme werden in der Lib genutzt, um Aktionen nach einer bestimmten Zeit auszuführen. Hierzu wird im Alarm die Wartezeit in Ticks (komme ich gleich noch zu) gespeichert und der Alarm einer AlarmClock (sysclock) hinzugefügt. Diese verwaltet beliebig viele Alarme und nutzt einen Timer der CPU zum zählen. Die Auflösung des Timers wind durch das Define TICKS_PER_SECOND (default 100) bestimmt. Damit man nun nicht immer rechnen muss, gibt es die irgendwas2ticks Macros. Der Code oben stetzt also einen Timeout von 1 Sekunde - sprich es wird sekündlich gemessen, da in der trigger Methode, der Alarm wieder reaktiviert wird.
Da der Timer durch die Verwendung der unterschiedlichen Sleep-Modes der ATMega mehr oder weniger ungenau ist, besteht die Möglichkeit einen 32,768kHz Quarz anzuschliessen und die RTC Klasse zu verwenden. Diese nutzt den Timer2 (beim ATMega) und programmiert ihn auf einen Sekundentakt. Dieser Timer ist auch bei Verwendung der Sleep-Modes noch genau. Hier wird dann der Alarm in Sekunden angegeben und es wird rtc anstatt sysclock verwendet.

Zitat von: jp112sdl am 20 Februar 2018, 06:37:26

#define SENS1_PIN 6 //14
#define SENS2_PIN 3 //15

...

msgForPosA(1); // DRY
msgForPosB(3); // WET
msgForPosC(2); // WATER


Das (default)-mapping ist in der ThreeState.h zu finden

  // map pins to pos     00   01   10   11
  uint8_t posmap[4] = {Positions::PosC,Positions::PosC,Positions::PosB,Positions::PosA};


Heißt:






SENS1_PINSENS2_PIN
TrockenHH
FeuchtHL
NassLL
NassLH

Genau das Mapping Pinstatus zu Position ist fest verdrahtet. Die msgForPosX Register bestimmen dann, was wirklich gesendet wird. Das kann dann von außen eingestellt werden.

Zitat von: jp112sdl am 20 Februar 2018, 06:37:26
Die Pins werden durch eine (von dir bereit gestellte) externe Schaltung auf H oder L gesetzt.
Es wird hier keine Feuchtigkeit gemessen!

Die Pins werden nur während der Messung kurz aktiviert - als Input mit PULLUP - ThreeStateChannel::readPin. Zum Auslösen muss also der Pin nach Masse kurz geschlossen werden - z.B. durch Wasser.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 20 Februar 2018, 08:39:29
Ahh, jetzt hab ich das auch verstanden, wie das mit der Taktung funktioniert!

Zitat von: papa am 20 Februar 2018, 08:05:47
Die Pins werden nur während der Messung kurz aktiviert - als Input mit PULLUP - ThreeStateChannel::readPin. Zum Auslösen muss also der Pin nach Masse kurz geschlossen werden - z.B. durch Wasser.
Ich bin da immer skeptisch... ob Wasser eine so hohe Leitfähigkeit hat, um den gepullten Pin runterzuziehen.
Es hängt sicher auch davon ab, wie weit Pin und GND auseinander liegen... aus dem Bauch heraus hätte ich evtl. mit einem Tiny85 analoge Werte gemessen und bei bestimmten Schwellwerten dann digitale Pins entsprechend gesetzt.
Dann könnte man nicht nur erfassen, ob sich der Pin tatsächlich voll im Wasser befindet, sondern auch ob bspw. der Kellerboden durch aufsteigende Nässe aus dem Erdreich den Betonboden durchfeuchtet.

Aber gut... ich schweife vom Thema ab. :)

Ich hab dann aber auch noch eine Frage:
class BatSensor : public BatterySensorUni<17,7,3000> {
  bool m_Extern;
public:
  // sense pin = A3 = 17, activation pin = D7 = 7
  BatSensor () : BatterySensorUni(), m_Extern(false) {}
  virtual ~BatSensor () {}

  void hasStepUp (bool value) {
    m_Extern = value;
    voltage();
  }

  virtual uint8_t voltage () {
    if( m_Extern == true ) {
      return BatterySensorUni<17,7,3000>::voltage();
    }
    return BatterySensor::voltage();
  }
};


Wenn ich diese Klasse in den HM-WDS10-TH-O hole und in
typedef AskSin<LedType, BatterySensorUni,RadioType> BaseHal;
übergebe sowie

    battery.low(22);
    battery.critical(19);
entsprechend wie gehabt mit fixen Werten belege, reicht das dann aus?

Der WeatherChannel hat kein virtual void configChanged () wie der ThreeStateChannel... Ich weiß nicht, ob das wirklich notwendig ist, wenn ich es für mich einfach statisch festlege.

Ich würde auch gern statt des A3 den A7 des Mega328P für die Messung benutzen. Spricht da deiner Meinung nach aus technischer Sicht was dagegen?
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 20 Februar 2018, 09:59:22
Danke an Euch jp112sdl und papa, habe Messintervall und sensor pin mapping verstanden glaub ich und weiß auch jetzt wo ich nachschauen muss (ThreeState.h)

Zitat
// map pins to pos     00   01   10   11
  uint8_t posmap[4] = {Positions::PosC,Positions::PosC,Positions::PosB,Positions::PosA};
Heißt:
SENS1_PIN   SENS2_PIN
Trocken   H   H
Feucht   H   L
Nass   L   L
Nass   L   H

Wenn ich das richtig sehe
uint8_t pinstate = readPin(sens2) << 1 | readPin(sens1);
steht Sensor pin 2 als höherwertiges Bit links, muss dann nicht die Tabelle eigentlich so lauten (z.B. Feucht wäre nicht SENS1_PIN high sondern SENS2_PIN high)

        SENS2_PIN  SENS1_PIN
Nass L    L
Nass L    H
Feucht H    L
Trocken H    H



Ich möchte die Wasserdetektion mit ADC machen, ich habe da letztes Jahr schon Experimente mit einer Spannungsteilerschaltung gemacht und habe Messwerte. Kann ich dafür die Funktion
void trigger (__attribute__ ((unused)) AlarmClock& clock)  {
im Sketch einfach anlegen, dort mein custom ADC handling machen und diese überschreibt dann die originale trigger Funktion in ThreeState.h?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Februar 2018, 16:49:23
Zitat von: Tom Major am 20 Februar 2018, 09:59:22
Ich möchte die Wasserdetektion mit ADC machen, ich habe da letztes Jahr schon Experimente mit einer Spannungsteilerschaltung gemacht und habe Messwerte. Kann ich dafür die Funktion
void trigger (__attribute__ ((unused)) AlarmClock& clock)  {
im Sketch einfach anlegen, dort mein custom ADC handling machen und diese überschreibt dann die originale trigger Funktion in ThreeState.h?

Naja - nicht ganz. Du musst eine neue Klasse vom ThreeStateChannel ableiten und dort die trigger Methode überschreiben. Dann kommt diese neue Channelklasse in das ThreeStateDevice-Template.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Februar 2018, 17:00:09
Zitat von: jp112sdl am 20 Februar 2018, 08:39:29
Ich hab dann aber auch noch eine Frage:
class BatSensor : public BatterySensorUni<17,7,3000> {
  bool m_Extern;
public:
  // sense pin = A3 = 17, activation pin = D7 = 7
  BatSensor () : BatterySensorUni(), m_Extern(false) {}
  virtual ~BatSensor () {}

  void hasStepUp (bool value) {
    m_Extern = value;
    voltage();
  }

  virtual uint8_t voltage () {
    if( m_Extern == true ) {
      return BatterySensorUni<17,7,3000>::voltage();
    }
    return BatterySensor::voltage();
  }
};


Wenn ich diese Klasse in den HM-WDS10-TH-O hole und in
typedef AskSin<LedType, BatterySensorUni,RadioType> BaseHal;
übergebe sowie

    battery.low(22);
    battery.critical(19);
entsprechend wie gehabt mit fixen Werten belege, reicht das dann aus?

Der WeatherChannel hat kein virtual void configChanged () wie der ThreeStateChannel... Ich weiß nicht, ob das wirklich notwendig ist, wenn ich es für mich einfach statisch festlege.

Ich würde auch gern statt des A3 den A7 des Mega328P für die Messung benutzen. Spricht da deiner Meinung nach aus technischer Sicht was dagegen?

Eigentlich brauchts Du diese Klasse gar nicht. Sie ist dafür gemacht worden, um im HM-Sec-RHS sowohl Hardware mit und ohne Stepup-Wandler verwenden zu können. Die Lib kennt unterschiedliche Implementierung für die Batteriemessung (siehe BatterySensor.h):

NoBattery - keine Funktion, einfach leer, bei Netzversorgung
BatterySensor - interne Spannungsmessung des ATMega, bei Betrieb ohne Stepup
BatterySensorUni - Messungs über Spannungsteiler und AD-Wandler, für Stepup, kompatibel zur UniversalSensor von Dirk
BatterySensorExt - Messungs über Spannungsteiler und AD-Wandler, für Stepup, https://github.com/rlogiacco/BatterySense (https://github.com/rlogiacco/BatterySense)

Je nachdem wie Deine Hardware aussieht, wird die entsprechende Klasse in das HAL-Template gesteckt. Du kannst natürlich auch andere Pins verwenden. Dann muss Deine Hardware auch entsprechend aufgebaut sein.

configChanged() ist in der Channel-Klasse leer implementiert und kann einfach überschrieben werden. Es braucht nicht virtual zu sein, da der Aufruf über die im Device-Template angegebene Klasse erfolgt.

Da virtuelle Methoden auf dem 8-bit AVR sehr teuer sind, habe ich versucht diese wo immer möglich zu vermeiden.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 20 Februar 2018, 17:25:39
Zitat von: papa am 20 Februar 2018, 17:00:09
Du kannst natürlich auch andere Pins verwenden.
...wobei ich dann aber wieder die gesamte Klasse neu definieren muss?
Oder gibt eine "Kurzversion", wenn ich lediglich andere Pins nutzen möchte?

Und noch mal zum Energiesparen...

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

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

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

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

Danke für deine Geduld und ausführlichen Erklärungen!
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Februar 2018, 17:40:42
Zitat von: jp112sdl am 20 Februar 2018, 17:25:39
...wobei ich dann aber wieder die gesamte Klasse neu definieren muss?
Oder gibt eine "Kurzversion", wenn ich lediglich andere Pins nutzen möchte?

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

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

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

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

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

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

Ist in Activity.h implementiert:

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

Je mehr an bleibt, um so mehr Power wird benötigt. Hängt natürlich auch von der restlichen Beschaltung ab. Da wird man immer das entsprechende Desgin untersuchen müssen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 20 Februar 2018, 19:40:45
ZitatNaja - nicht ganz. Du musst eine neue Klasse vom ThreeStateChannel ableiten und dort die trigger Methode überschreiben. Dann kommt diese neue Channelklasse in das ThreeStateDevice-Template.
Ok, probiere ich die nächsten Tage aus wenn mein CC1101 kommt, ich werde berichten - oder vorher weiter nerven falls ich es mit der Ableitung von ThreeStateChannel / trigger nicht hinbekomme.

ZitatGibt es praktische Erfahrungs- / Messwerte der Ruheströme zwischen den beiden Sleep-Modes?
Ich hatte vor einigen Wochen einen Wassermelder mit ATmega328P und RFM69 als Prototyp designed, den wollte ich an meinen JeeLink anbinden.
Da ich parallel die ccu2 auf RPi laufen habe und kürzlich die HM Selbstbau Sensoren sowie papas AskSin++ entdeckt habe werde ich jetzt erstmal den Wassermelder a la HM-SEC-WDS an ccu2 testen.
Mit meinem Prototyp ATmega328P und RFM69 erreiche ich bei 2,6V (2x NiMH) jedenfalls traumhafte 4 uA im Sleep (run clock 1MHz RC OSC, WD enabled, BOD disabled, RFM69 im sleep).
Mal sehen wie sich da der HM-SEC-WDS Nachbau schlägt..
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 21 Februar 2018, 09:35:26
@papa, jetzt hast schon so viel zum Thema Batterie verraten, dann kannst du bestimmt auch noch was zur untergegangen Frage im FensterDrehgriff Thread sagen :
Wird der Batterie Status ok,low,critical jedesmal neu ermittelt ohne Rücksicht auf den zuletzt gemeldeten Wert ?
Die Frage ist eigentlich zuerst im Batterie Monitoring Thread aufgetaucht, die User die HM schon länger einsetzen sind der Meinung das HM Geräte ein einmal erkanntes low/critical  erst wieder zurücksetzen wenn das Gerät spannungslos gemacht wurde, d.h. eigentlich nur wenn die Batterien getauscht wurden (IMHO machen das die LaCrosse Sensoren auch so).
Mein erster FensterDrehgriff Sensor zeigte aber ein Verhalten wie es eigentlich sonst nur typisch für MAX! Geräte ist. D.h. es wurde mal low gemeldet, dann wieder etliche Male ok und ab und an wieder low.
Ich selbst habe HM noch nicht lange genug im Einsatz um das Verhalten mit Original HM Geräten vergleichen zu können. 
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Februar 2018, 11:56:33
Zitat von: Wzut am 21 Februar 2018, 09:35:26
@papa, jetzt hast schon so viel zum Thema Batterie verraten, dann kannst du bestimmt auch noch was zur untergegangen Frage im FensterDrehgriff Thread sagen :
Wird der Batterie Status ok,low,critical jedesmal neu ermittelt ohne Rücksicht auf den zuletzt gemeldeten Wert ?
Die Frage ist eigentlich zuerst im Batterie Monitoring Thread aufgetaucht, die User die HM schon länger einsetzen sind der Meinung das HM Geräte ein einmal erkanntes low/critical  erst wieder zurücksetzen wenn das Gerät spannungslos gemacht wurde, d.h. eigentlich nur wenn die Batterien getauscht wurden (IMHO machen das die LaCrosse Sensoren auch so).
Mein erster FensterDrehgriff Sensor zeigte aber ein Verhalten wie es eigentlich sonst nur typisch für MAX! Geräte ist. D.h. es wurde mal low gemeldet, dann wieder etliche Male ok und ab und an wieder low.
Ich selbst habe HM noch nicht lange genug im Einsatz um das Verhalten mit Original HM Geräten vergleichen zu können.

Das Handling ist derzeit sehr einfach. Es wird in regelmäßigen Abständen gemessen und der gemessene Wert abgespeichert. Wenn der Batteriestatus abgefragt wird, wird der gemessene Wert mit dem Low- bzw. Critical-Wert verglichen. Deshalb kann es auch zu dem beschriebenen Verhalten kommen, dass Low und Ok sich abwechseln. Man könnte sich auch merken, wenn man einmal Low gemeldet hat und dann immer Low melden. Der Batteriewechsel/Neustart würde das dann zurücksetzen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 21 Februar 2018, 18:17:56
Hallo papa,

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

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

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

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

class MyThreeStateChannel : public ThreeStateChannel <???> {

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

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


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


Danke,
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 Februar 2018, 08:19:42
Du brauchst die Template-Argumente doch nur durchreichen.


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

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

typedef MyThreeStateChannel<HalType,WDSList0,WDSList1,DefList4,PEERS_PER_CHANNEL> ChannelType;
typedef ThreeStateDevice<HalType,ChannelType,1,WDSList0> DevType;
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 22 Februar 2018, 11:06:56
Zitat von: papa am 21 Februar 2018, 11:56:33
Man könnte sich auch merken, wenn man einmal Low gemeldet hat und dann immer Low melden. Der Batteriewechsel/Neustart würde das dann zurücksetzen.
Mir persönlich ist das relativ wurscht, ich kann gut mit der heutigen Version leben. Mir ging es in erster Linie erst einmal "nur" um die Klärung des bestehendes Sachrverhalts. 
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 22 Februar 2018, 19:59:10
Zitat von: papa am 22 Februar 2018, 08:19:42
Du brauchst die Template-Argumente doch nur durchreichen.

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

Ansonsten könnte ich natürlich alternativ ThreeState.h kopieren und dort meinen trigger code direkt einfügen, dann verzichte ich auf das Konzept mit dem Ableiten, ist nicht so elegant, wäre aber wahrscheinlich einfacher zum Laufen zu bekommen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 Februar 2018, 20:27:58
Die Membervariablen sind all private. die müsste man dann protected machen, damit die abgeleutete Klasse darauf zugreifen kann. Das beste wäre wahrscheinlich, das trigger() im ThreeStateChannel nochmal aufzuteilen und das Ermitteln der Position auszulagern.
Kopieren und ändern geht natürlich auch erst mal. Der Name muss aber trotzdem geändert werden.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 23 Februar 2018, 00:17:59
Zitat von: papa am 22 Februar 2018, 20:27:58
Die Membervariablen sind all private. die müsste man dann protected machen, damit die abgeleutete Klasse darauf zugreifen kann. Das beste wäre wahrscheinlich, das trigger() im ThreeStateChannel nochmal aufzuteilen und das Ermitteln der Position auszulagern.
Kopieren und ändern geht natürlich auch erst mal. Der Name muss aber trotzdem geändert werden.
Sehr gute Idee den trigger() nochmal aufzuteilen, so wäre man viel flexibler. Bei der Kopie gibt es immer die Gefahr dass man out of sync zum Repo kommt.
Akzeptierst Du pull requests? Dann würde ich das mit der Aufteilung mal versuchen.

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

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

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

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

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

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

Flash wirst Du damit nicht sparen. Die Peer-Listen kommen ins EEProm.
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 25 Februar 2018, 14:10:45
Hallo, wie bekomme ich denn ein erstelltes Gerät mit dem aktuellen aktuellen Master-branch angelernt?
Beim kurzen Drücken der Configtaste gibt der ser. Monitor folgendes aus:

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


Auf längere Tastendrücke reagiert es garnicht.

Danke  :)
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 25 Februar 2018, 14:12:59
Zitat von: andirs am 25 Februar 2018, 14:10:45
Hallo, wie bekomme ich denn ein erstelltes Gerät mit dem aktuellen aktuellen Master-branch angelernt?
Beim kurzen Drücken der Configtaste gibt der ser. Monitor folgendes aus:

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


Auf längere Tastendrücke reagiert es garnicht.

Danke  :)

Nutzt du nen 16 MHz Pro Mini?


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 25 Februar 2018, 14:21:23
Sorry hätte mehr infos geben können:

Pro mini 8Mhz mit CC1101 Funke
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 25 Februar 2018, 14:23:50
Zitat von: andirs am 25 Februar 2018, 14:21:23
Sorry hätte mehr infos geben können:

Pro mini 8Mhz mit CC1101 Funke

Und auch 8 MHz als Board ausgewählt beim Upload? Ich hatte dein beschriebenes Phänomen auch mal. Lag irgendwie an falscher Frequenzauswahl


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 25 Februar 2018, 14:41:50
In der Arduino IDE ist auch 8 Mhz ausgewählt, trotzdem danke :)

Edit: Ah schon gut, hatte ein paar Zeilen in der .ino auskommentiert von denen ich dachte dass Sie nichts mit dem Anlernen zu tun haben. Habe diese wieder einkommentiert und jetzt gehts :)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 Februar 2018, 18:39:07
Wenn Du uns jetzt noch verräts, wie der Code aussieht oder welches Example Du nutzt, könnten wir Dir auch vielleicht helfen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 25 Februar 2018, 19:15:28
Ich habe jetzt meine CC1101 bekommen und als erstes das Wassermelder example (HM-SEC-WDS) mal aufgebaut und getestet. Was soll ich sagen, funktionierte auf Anhieb, screenshots vom Prototyp und CCU2 Gerät im Anhang. Die Ruhestromaufnahme liegt bei sehr guten 4 uA.

Vielen Dank an papa und natürlich auch an die Ersteller der vorherigen AskSin libraries für diese Arbeit! Ein ganz toller HomeMatic Baukasten. Eigene Modifikationen sind, wenn man nicht so der C++ class template Programmierer crack ist, am Anfang etwas schwierig, aber man findet sich rein.

Bin auch aktuell mit papa im Kontakt, um die ThreeStateChannel Klasse etwas universeller zu gestalten, ich möchte für den Wassermelder Erkennung ADC statt GPIO verwenden und das meassure Intervall braucht bei mir auch nicht 1sec zu sein, sondern z.B. 1min, das reicht auch und spart Batteriestrom.
Titel: Antw:AskSin++ Library
Beitrag von: LuBeDa am 25 Februar 2018, 20:02:18
AskSin++ Library oder nur MySensors

Hallo,
ich möchte mir einen 4fach Sensor bauen, er soll einen BME280 für Temperatur, Luftfeuchte und Luftdruck haben und einen PIR Bewegungsmelder.

Für mein Project fände ich eine "Homematic" Lösung sehr cool, weil man den PIR z.B. direkt mit meinen Homematic Aktoren peeren könnte.

Leider gibt es außer dem Sourcecode von pa-pa und jp112sdl auf github scheinbar noch keine Doku.

Weil ich quasi einen neuen Gerätetyp erzeuge ("Wettersensor" mit PIR) gibt es auch kein Source-Beispiel auf dem man aufbauen kann.

Da gibt es zwei Baustellen. Einmal muss man einen Arduino Sketch erstellen der drei Messwerte und einen "Schalter" nach FHEM übermittelt
und zweitens fehlt dann das passende Modul in FHEM oder in CCU2/RaspberryMatic.

Sehe ich das so richtig?

Gibt es vielleicht irgendwelche Wikis, Blogs oder ausgewählte Foreneinträge die den Einstieg der AskSin++ Programmierung etwas ausführlicher beschreiben?

Danke Ludger
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 Februar 2018, 21:03:00
Zitat von: LuBeDa am 25 Februar 2018, 20:02:18
AskSin++ Library oder nur MySensors

Hallo,
ich möchte mir einen 4fach Sensor bauen, er soll einen BME280 für Temperatur, Luftfeuchte und Luftdruck haben und einen PIR Bewegungsmelder.

Für mein Project fände ich eine "Homematic" Lösung sehr cool, weil man den PIR z.B. direkt mit meinen Homematic Aktoren peeren könnte.

Leider gibt es außer dem Sourcecode von pa-pa und jp112sdl auf github scheinbar noch keine Doku.

Weil ich quasi einen neuen Gerätetyp erzeuge ("Wettersensor" mit PIR) gibt es auch kein Source-Beispiel auf dem man aufbauen kann.

Da gibt es zwei Baustellen. Einmal muss man einen Arduino Sketch erstellen der drei Messwerte und einen "Schalter" nach FHEM übermittelt
und zweitens fehlt dann das passende Modul in FHEM oder in CCU2/RaspberryMatic.

Sehe ich das so richtig?

Ja

Zitat von: LuBeDa am 25 Februar 2018, 20:02:18
Gibt es vielleicht irgendwelche Wikis, Blogs oder ausgewählte Foreneinträge die den Einstieg der AskSin++ Programmierung etwas ausführlicher beschreiben?

Nein - nur was hier steht
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 26 Februar 2018, 01:30:34
Zitat von: Tom Major am 25 Februar 2018, 19:15:28
Bin auch aktuell mit papa im Kontakt, um die ThreeStateChannel Klasse etwas universeller zu gestalten, ich möchte für den Wassermelder Erkennung ADC statt GPIO verwenden und das meassure Intervall braucht bei mir auch nicht 1sec zu sein, sondern z.B. 1min, das reicht auch und spart Batteriestrom.
wow, das ging schnell, papa hat sich meinen pull-request angeschaut, das ganze so geändert das es rückwärtskompatibel ist und eingecheckt. Habe es gerade getestet, ich kann jetzt nur mit Änderungen im sketch den Wassermelder mit ADC Messwerten füttern und das Messintervall auch vom sketch aus konfigurieren.
Danke für die schnelle Bearbeitung. Bei Interesse kann ich das erweiterte sketch für die examples im Repo anbieten.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 26 Februar 2018, 01:42:02
Zitat von: LuBeDa am 25 Februar 2018, 20:02:18
AskSin++ Library oder nur MySensors
Hallo,
ich möchte mir einen 4fach Sensor bauen, er soll einen BME280 für Temperatur, Luftfeuchte und Luftdruck haben und einen PIR Bewegungsmelder.
Da gibt es zwei Baustellen. Einmal muss man einen Arduino Sketch erstellen der drei Messwerte und einen "Schalter" nach FHEM übermittelt
und zweitens fehlt dann das passende Modul in FHEM oder in CCU2/RaspberryMatic.

Die erste Baustelle erscheint mir machbar. Du nimmst z.B. das HM-WDS100-C6-O-2 example, implementierst deine PIR Messungen im sketch und passt dann die payload so an dass der PIR in einem von dir nicht benötigten Datenfeld übertragen wird. Dann hättest Du ein kompatibles Gerät in der ccu2 oder FHEM mit teilweise geänderten Messgrößen. Und die 2. Baustelle fällt erst mal weg.

Wenn das funktioniert könnte man sich später an das neu generieren (über eine xml Datei glaub ich) eines HM devices machen, ob das aber von der ccu2 problemlos akzeptiert wird bin ich überfragt.
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 26 Februar 2018, 15:58:17
Hallo danke nochmal papa, wie ich im Edit geschrieben hatte habe ich das Problem lösen können.
Allerdings habe ich eine neue Frage/Verständnisproblem:

Ich habe mir mit deiner Library und einem Arduino Pro mini 8 Mhz und dem CC1101 modul einen eigenen UniSensor gebaut, welcher Temp/Feuchte über einen DHT22 und die Helligkeit über einen analogen Sensor misst. Soweit klappt die Messwerterfassung und das Anlernen und Übermitteln der Messages an die Zentrale.

Problematisch ist die Häufigkeit mit der die Nachrichten gesendet werden. Ich habe das Example vom HM-WDS10-TH-O herangezogen und dort finden sich folgende Zeilen, die die Zeit zur nächsten Nachricht bestimmen (zumindest verstehe ich das so):

 
    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,dht11.temperature(),dht11.humidity(),device().battery().low());
      device().sendPeerEvent(msg,*this);

      // 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 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;
}


Wenn ich das richtig recherchiert habe kommt das daher um den HM-CC-RT-DN pairen zu können. Bei mir führt das allerdings dazu, dass etwa alle 1-2 s eine Nachricht gesendet wird. Das ist denke ich beim Batteriebetrieb viel zu oft. Einen HM-CC-RT-DN würde ich auch gerne pairen, das schlägt aber (noch) fehl. Liegt das ggf. an einer schlecht gewählten ID? Am messagecount kann ich ja nichts ändern.


// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x11,0x12,0x13},          // Device ID
    "USLR111111",              // Device Serial
    {0xF1,0x01},              // Device Model
    0x10,                      // Firmware Version
    as::DeviceType::THSensor, // Device Type
    {0x01,0x01}                // Info Bytes
};


Wie oft in etwa sollte denn eine Nachricht normalerweise gesendet werden?

Was mir auch noch aufgefallen ist, dass in meinem Code Allg. ein Zeit Problem existiert. Der folgende Code sagt ja dass die Batt einmal pro Stunde gemessen werden soll. Laut meinem ser. Monitor passiert das aber eher alle paar Sekunden.


// measure battery every 1h
battery.init(60UL*60,rtc);


Hier ein Ausschnitt aus dem Seriellen Monitor:


AskSin++ V2.1.4 (Feb 26 2018 15:37:02)
Address Space: 32 - 70
CC init1
CC Version: 14
- ready
Bat: 74
Try #: 1
T: 212 H: 44 B: 79
<- 0D 01 84 70 111213 000000 00 D4 2C 4F  - 3428
136.500
T: 212 H: 44 B: 78
<- 0D 02 84 70 111213 000000 00 D4 2C 4E  - 3756
122.0
T: 211 H: 44 B: 78
<- 0D 03 84 70 111213 000000 00 D3 2C 4E  - 4081
171.750
T: 211 H: 44 B: 77
<- 0D 04 84 70 111213 000000 00 D3 2C 4D  - 4413
157.250
T: 211 H: 44 B: 78
<- 0D 05 84 70 111213 000000 00 D3 2C 4E  - 4743
142.750
T: 211 H: 44 B: 78
<- 0D 06 84 70 111213 000000 00 D3 2C 4E  - 5070
128.500
T: 211 H: 44 B: 77
<- 0D 07 84 70 111213 000000 00 D3 2C 4D  - 5398
178.0
T: 211 H: 44 B: 77
<- 0D 08 84 70 111213 000000 00 D3 2C 4D  - 5730
163.500
T: 212 H: 44 B: 77
<- 0D 09 84 70 111213 000000 00 D4 2C 4D  - 7008
149.250
T: 211 H: 43 B: 76
<- 0D 0A 84 70 111213 000000 00 D3 2B 4C  - 7335
134.750
T: 211 H: 43 B: 76
<- 0D 0B 84 70 111213 000000 00 D3 2B 4C  - 7663
120.250
T: 211 H: 43 B: 76
<- 0D 0C 84 70 111213 000000 00 D3 2B 4C  - 7989
169.750
Bat: 89
T: 211 H: 43 B: 76
<- 0D 0D 84 70 111213 000000 00 D3 2B 4C  - 8325
155.500
T: 211 H: 43 B: 75
<- 0D 0E 84 70 111213 000000 00 D3 2B 4B  - 9601
141.0
T: 211 H: 43 B: 75
<- 0D 0F 84 70 111213 000000 00 D3 2B 4B  - 9930
126.500
T: 211 H: 43 B: 76
<- 0D 10 84 70 111213 000000 00 D3 2B 4C  - 10256
176.250
T: 210 H: 43 B: 79
<- 0D 11 84 70 111213 000000 00 D2 2B 4F  - 10590
161.750


Mein .ino hab ich mal mit angehangen.

Vielen Dank.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 26 Februar 2018, 16:32:44
Hast Du einen 32kHz Quarz an XTAL? Weil dein sketch mit rtc arbeitet.

Alternativ könntest Du die rtc testweise aus dem sketch rausnehmen und in trigger mal sowas mit sysclock versuchen, um z.B. alle 2min zu senden:

set(seconds2ticks(60UL*2));
clock.add(*this);
// und hal.activity.savePower anpassen nicht vergessen

Titel: Antw:AskSin++ Library
Beitrag von: andirs am 26 Februar 2018, 18:19:05
Danke für den Tipp, einen 32khz quarz habe ich nicht. Nach ein wenig recherche werde ich mir wohl mal welche aus China bestellen (müssen) :)

Brauche ich dazu noch etwas? Würden es diese tun? https://de.aliexpress.com/item/Free-shipping-10PCS-32-000MHZ-32-000M-32M-32MHZ-32-MHZ-Crystal-Oscillator-49S-NEW-and/32720698559.html?isOrigTitle=true (https://de.aliexpress.com/item/Free-shipping-10PCS-32-000MHZ-32-000M-32M-32MHZ-32-MHZ-Crystal-Oscillator-49S-NEW-and/32720698559.html?isOrigTitle=true)

Danke
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 26 Februar 2018, 18:24:03
Du hast einen 32 MHz referenziert, benötigt wird ein 32,768 kHz für die RTC. Den bekommt man ohne Schwierigkeiten bei conrad, reichelt ebay usw.
Ich würde es erst mal ohne RTC nur mit sysclock testen. Für einen Temperatursender der alle paar Minuten aufwacht braucht man wirklich keine RTC, aus meiner Sicht.
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 26 Februar 2018, 19:29:13
so wie ich das gelesen habe ist das timing beim pairen mit dem HM-CC-RT-DN schwierig werden könnte ohne den quarz :)
dazu muss wohl auch die berechnung wann der nächste wert gesendet wird beibehalten werden, statt einfach alle 2min zu senden.

Kannst du meinen angehangenen sketch ggf. mal umändern sodass die interne uhr verwendet wird?
ich selbst habs grad kaputt gemacht und jetzt sendet es garnichts mehr :D da ich den sketch inkl. library im prinzip garnicht verstehe (nur wie ich eigene sensoren einbinde) ist das ein schwieriges unterfangen.

danke
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 26 Februar 2018, 19:39:38
Zitat von: andirs am 26 Februar 2018, 19:29:13
so wie ich das gelesen habe ist das timing beim pairen mit dem HM-CC-RT-DN schwierig werden könnte ohne den quarz :)
dazu muss wohl auch die berechnung wann der nächste wert gesendet wird beibehalten werden, statt einfach alle 2min zu senden.
Ja, was ich gelesen habe können die HM-CC-RT-DN eine Menge Funkverkehr erzeugen, Burst mode usw.
Aber ich dachte Du wolltest einen HM-WDS10-TH-O nachbauen? Wieso glaubst Du wenn der alle 2min sendet wird das nicht akzeptiert? Hast Du dafür irgendwo einen link zum Nachlesen?

Ich hatte sowie so vor nach dem Wassermelder den HM-WDS10-TH-O als nächstes nachzubauen. Also ich schaue mir das mal heute abend oder morgen an, mit sysclock statt rtc.
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 26 Februar 2018, 19:58:21
Danke dir.

Den HM-WDS10-TH-O wollte ich nicht 1zu1 nachbauen, sondern habe den als Vorlage für meinen Sensor genutzt.
Worauf ich hinaus möchte sind Sensoren für den Innenraum die Temp, Feuchte und Helligkeit messen und an die Zentrale senden.
Gleichzeitig soll dieser direkt mit HM-CC-RT-DN gepaired werden, damit dieser auf die Isttemperatur am UniSen regelt und nicht auf seine eigene.
Genau wegen diesem Direktpairing möchte ich möglichst nah bei der Vorlage von papa bleiben, weil er sich sicher was dabei gedacht hat :)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 26 Februar 2018, 20:30:52
Zitat von: andirs am 26 Februar 2018, 19:58:21
Danke dir.

Den HM-WDS10-TH-O wollte ich nicht 1zu1 nachbauen, sondern habe den als Vorlage für meinen Sensor genutzt.
Worauf ich hinaus möchte sind Sensoren für den Innenraum die Temp, Feuchte und Helligkeit messen und an die Zentrale senden.
Gleichzeitig soll dieser direkt mit HM-CC-RT-DN gepaired werden, damit dieser auf die Isttemperatur am UniSen regelt und nicht auf seine eigene.
Genau wegen diesem Direktpairing möchte ich möglichst nah bei der Vorlage von papa bleiben, weil er sich sicher was dabei gedacht hat :)

Also wenn Du direkt mit den HM-CC-RT-DN peeren willst, kommst Du am 32.768kHz Quarz und der RTC nicht vorbei. Die Geräte bereichen nach der aktuellen Messagenummer und der ID den nächsten Sendeslot. Dann wacht der Regler kurz auf und wartet auf die Nachricht mit der Temperatur. Da der Deep-Sleep beim AVR sehr ungenau ist, passt der Zeitpunkt nicht und die Kommunikation läuft ins leere.
Die RTC-Klasse nutzt den Timer2 mit den externen Quarz. Das ganze ist unabhängig vom Sleep-Mode.

Wie sieht denn der Mini aus ? Ist da ein grosser Qurz drauf ? Dann könnte man wahrscheinlich gegen ein 32.768kHz tauschen.

Mit sysclock sollte es so aussehen (nicht getestet)

//- -----------------------------------------------------------------------------------------------------------------------
// 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 EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Register.h>
#include <MultiChannelDevice.h>

#include "Dht.h"
#include "LM393LLS.h"

// Arduino Pro mini 8 Mhz
// Arduino pin for the config button
#define CONFIG_BUTTON_PIN 8

// #define TIME_MEASURE_AND_SEND_IN_S 15

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

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x11,0x12,0x13},          // Device ID
    "USLR111111",              // Device Serial
    {0xF1,0x01},              // Device Model
    0x10,                      // Firmware Version
    as::DeviceType::THSensor, // Device Type
    {0x01,0x01}                // Info Bytes
};

/**
* Configure the used hardware
*/
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<4> LedType;
typedef BatterySensorUni<A1,6> BatterySensorType;
typedef AskSin<LedType,BatterySensorType,RadioType> BaseHal;
class Hal : public BaseHal {
public:
  void init (const HMID& id) {
    BaseHal::init(id);
    // measure battery every 1h
    battery.init(seconds2ticks(60UL*60),sysclock);
    battery.low(20); // Low voltage set to 2.0V
    battery.critical(18); // Critical voltage set to 1.8V
  }

  bool runready () {
    return BaseHal::runready();
  }
} hal;

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

DEFREGISTER(WeatherRegsList0,DREG_BURSTRX)
typedef RegList0<WeatherRegsList0> WeatherList0;


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

  WeatherEventMsg msg;

  Dht<7,DHT22>      dht22;
  Lm393lls<A0>      lm393lls;
  uint16_t          millis;

public:
  WeatherChannel () : Channel(), Alarm(5), 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,dht22.temperature(),dht22.humidity(),lm393lls.brightness(),device().battery().low());
      device().sendPeerEvent(msg,*this);
     
      // reactivate for next measure
      HMID id;
      device().getDeviceID(id);
      uint32_t nextsend = delay(id,msgcnt); // TIME_MEASURE_AND_SEND_IN_S*240000;
      tick = millis2ticks(nextsend);
      sysclock.add(*this);
    }
  }

  // here we do the measurement
  void measure () {
    dht22.measure();
    lm393lls.measure();
    DPRINT("T: ");DDEC(dht22.temperature());DPRINT(" H: ");DDEC(dht22.humidity());DPRINT(" B: ");DDECLN(lm393lls.brightness());
  }

  // 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,WeatherList0>* dev,uint8_t number,uint16_t addr) {
    Channel::setup(dev,number,addr);
    tick = seconds2ticks(5);
    sysclock.add(*this);
    dht22.init();
    lm393lls.init();
  }

  uint8_t status () const {
    return 0;
  }

  uint8_t flags () const {
    return 0;
  }

};

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

ConfigButton<WeatherType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  sdev.initDone();
}

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: Klaus0815 am 26 Februar 2018, 22:13:28
Die Geräte bereichen nach der aktuellen Messagenummer und der ID den nächsten Sendeslot. Dann wacht der Regler kurz auf und wartet auf die Nachricht mit der Temperatur.
Hallo Papa, interessant, wie auch viele andere Details hier - wo erfährt man den sowas? Gibts da eine Newsgroup oder was in der Richtung?

Viele Grüße
Klaus
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 26 Februar 2018, 23:00:25
Zitat von: papa am 26 Februar 2018, 20:30:52
Also wenn Du direkt mit den HM-CC-RT-DN peeren willst, kommst Du am 32.768kHz Quarz und der RTC nicht vorbei. Die Geräte bereichen nach der aktuellen Messagenummer und der ID den nächsten Sendeslot. Dann wacht der Regler kurz auf und wartet auf die Nachricht mit der Temperatur. Da der Deep-Sleep beim AVR sehr ungenau ist, passt der Zeitpunkt nicht und die Kommunikation läuft ins leere.

Ich hatte bei meinen Sensoren die erste Version ohne 32KHz Quarz gebaut. Es stimmt, der Watchdog liegt oft 10-15% neben den Nominalwerten, ist damit für den RT-DN zu ungenau. Diese ersten Sensoren laufen gänzlich ohne Quarz, d.h. mit internem 8 MHz RC-Oszillator. Auch der ist ungenau.

Ich habe allerdings in meiner Firmware und im dazu passenden FHEM-Modul einen Parameter dazugebaut, mit dem ich den RC-Oszillator genau einstellen kann. Von diesem Takt abgeleitet habe ich dann eine Autokalibrierung für den Watchdog in die Firmware eingebaut, so daß die (nicht kalibrierbare) Ungenauigkeit des Watchdog softwaremäßig ausgeglichen wird.
Mit diesen zwei Anpassungen erreiche ich eine sehr gute Genauigkeit - die dann auf jeden Fall ausreichend für die Synchronität mit einem RT-DN ist.

Der Grund für mich, einen 32KHz Quarz dazuzubauen war, daß der Watchdog relativ viel Strom braucht. Mit der RTC kommt man in den stromsparendsten Modus - das war mir das Wichtigste. Obendrein gibt's noch etwas höhere Genauigkeit, die bei mir aber gar nicht nötig wäre.

Martin
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 27 Februar 2018, 00:31:25
Zitat von: andirs am 26 Februar 2018, 19:58:21
Danke dir.
Den HM-WDS10-TH-O wollte ich nicht 1zu1 nachbauen, sondern habe den als Vorlage für meinen Sensor genutzt.
Worauf ich hinaus möchte sind Sensoren für den Innenraum die Temp, Feuchte und Helligkeit messen und an die Zentrale senden.
Gleichzeitig soll dieser direkt mit HM-CC-RT-DN gepaired werden, damit dieser auf die Isttemperatur am UniSen regelt und nicht auf seine eigene.
Genau wegen diesem Direktpairing möchte ich möglichst nah bei der Vorlage von papa bleiben, weil er sich sicher was dabei gedacht hat :)
ok, jetzt habe ich verstanden was Du vorhast. Dann nützt Dir der Vorschlag mit der sysclock fürs Peeren nichts, höchstens zum Testen der allgemeinen Funktionalität.
Du brauchst einen Uhrenquarz, z.B. so was
https://www.conrad.de/de/quarzkristall-euroquartz-quarz-tc38-zylinder-32768-khz-125-pf-o-x-h-31-mm-x-8-mm-156098.html (https://www.conrad.de/de/quarzkristall-euroquartz-quarz-tc38-zylinder-32768-khz-125-pf-o-x-h-31-mm-x-8-mm-156098.html)
oder ebay "uhrenquarz 32 khz"
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 27 Februar 2018, 00:38:37
Zitat von: Linef am 26 Februar 2018, 23:00:25
Der Grund für mich, einen 32KHz Quarz dazuzubauen war, daß der Watchdog relativ viel Strom braucht. Mit der RTC kommt man in den stromsparendsten Modus - das war mir das Wichtigste. Obendrein gibt's noch etwas höhere Genauigkeit, die bei mir aber gar nicht nötig wäre.
Ich möchte nur anmerken das der Unterschied zwischen power down Strom bei enabled/disabled Watchdog nur 4 uA beim mega328P beträgt. Bei einem typischen Sensor trägt Aufwachen/Messen/Funk-Kommunikation sicherlich viel mehr zum Verbrauch bei als die 4 uA.
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 27 Februar 2018, 07:42:15
Hallo zusammen, danke für die Antworten.

Papa deine Änderungen im ino File funktionieren, ich musste lediglich im loop()

hal.activity.savePower<Sleep>(hal); -- ändern zu --> hal.activity.savePower<Sleep<>>(hal);

damit es kompiliert. Danke :)

Quarze habe ich mir jetzt mal 10Stk. für ~1$ bei Aliexpress bestellt :)
Auf meinen Minis ist kein großer Quarz. Ich hab mal nen Foto angehangen.

Ist das hier der beste Link für die Umrüstung? Sonst finde ich nichts besonderes:
https://www.davidpilling.com/wiki/index.php/Arduino32768  (https://www.davidpilling.com/wiki/index.php/Arduino32768)

:)
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 27 Februar 2018, 07:53:38
Zitat von: andirs am 27 Februar 2018, 07:42:15
Hallo zusammen, danke für die Antworten.

Jetzt muss ich doch mal ganz blöd nachfragen...
Du verwendest in deinem Sketch das Model {0xF1,0x01}, was keinem gültigen/bekannten HomeMatic-Model entspricht, sondern dem Custom Device HB-UW-Sen-THPL, welches an der CCU2 auch nur funktioniert, wenn man in /firmware/rftypes das entsprechende XML Metafile ablegt.

Und dennoch kann man deinen Custom-Sensor mit einem originalen HM-CC-RT-DN peeren?
Ist im HM-CC-RT-DN nicht eine Art "Liste gültiger Partner" hinterlegt?
Vielleicht bin ich auf dem Holzweg... Klär(t) mich bitte auf.  :)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Februar 2018, 08:11:01
Zitat von: andirs am 27 Februar 2018, 07:42:15
Quarze habe ich mir jetzt mal 10Stk. für ~1$ bei Aliexpress bestellt :)
Auf meinen Minis ist kein großer Quarz. Ich hab mal nen Foto angehangen.

Ist das hier der beste Link für die Umrüstung? Sonst finde ich nichts besonderes:
https://www.davidpilling.com/wiki/index.php/Arduino32768  (https://www.davidpilling.com/wiki/index.php/Arduino32768)

Da wird die Umrüstung schwierig. Das Board verwendet einen Resonator. Da sind Quarz und Lastkondensatoren in einem Bauteil. Wenn Du nun einen Qurz bestücken willst, müssen da noch die beiden Lastkondensatoren gegen Masse bestückt werden. Ich weiss nicht, ob es Resonatoren mit 32,768kHz in der kleinen Bauform gibt. Als Alternative könntest Du auch diese Platine (https://forum.fhem.de/index.php/topic,73954.0.html) hier nehmen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Februar 2018, 08:13:02
Zitat von: jp112sdl am 27 Februar 2018, 07:53:38
Jetzt muss ich doch mal ganz blöd nachfragen...
Du verwendest in deinem Sketch das Model {0xF1,0x01}, was keinem gültigen/bekannten HomeMatic-Model entspricht, sondern dem Custom Device HB-UW-Sen-THPL, welches an der CCU2 auch nur funktioniert, wenn man in /firmware/rftypes das entsprechende XML Metafile ablegt.

Und dennoch kann man deinen Custom-Sensor mit einem originalen HM-CC-RT-DN peeren?
Ist im HM-CC-RT-DN nicht eine Art "Liste gültiger Partner" hinterlegt?
Vielleicht bin ich auf dem Holzweg... Klär(t) mich bitte auf.  :)

Das geht super. Dem HM-CC-RT-DN ist egal, was da sendet. Es ist nur wichtig, dass an den richtigen Kanal die richtige Nachricht zur richtigen Zeit gesendet wird. Man das ist ja schon fast wie in ner Logistik-Vorlesung.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Februar 2018, 08:16:10
Zitat von: Tom Major am 27 Februar 2018, 00:38:37
Ich möchte nur anmerken das der Unterschied zwischen power down Strom bei enabled/disabled Watchdog nur 4 uA beim mega328P beträgt. Bei einem typischen Sensor trägt Aufwachen/Messen/Funk-Kommunikation sicherlich viel mehr zum Verbrauch bei als die 4 uA.

Naja, wenn ca. 2-3 Minuten geschlafen wird, um dann nur mal kurz zu Messen und zu Senden, ist das schon ein Unterschied, ob die CPU die gesamte Zeit durchschläft oder alle 8 Sekunden vom Watchdog geweckt wird. Jedes Wecken bedeutet auch ein komplettes Prüfen aller Weckquellen, da es nicht möglich ist festzustellen, wer für das Wecken verantwortlich war (Watchdog, Interrupt, Timer)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Februar 2018, 08:20:48
Zitat von: Klaus0815 am 26 Februar 2018, 22:13:28
Die Geräte bereichen nach der aktuellen Messagenummer und der ID den nächsten Sendeslot. Dann wacht der Regler kurz auf und wartet auf die Nachricht mit der Temperatur.
Hallo Papa, interessant, wie auch viele andere Details hier - wo erfährt man den sowas? Gibts da eine Newsgroup oder was in der Richtung?

Ich habe ganz viel aus den "alten" NewAskSin-Sachen (https://forum.fhem.de/index.php/topic,14140.0.html) und dem Selbstbau HM-WDS10-TH-O (https://forum.fhem.de/index.php/topic,20620.0.html) gelernt. Da gibt es viel zu Lesen. Ohne diese Forschungsarbeiten, würde es die AskSin++ Library nicht geben.
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 27 Februar 2018, 13:30:01
Zitat von: papa am 27 Februar 2018, 08:11:01
Da wird die Umrüstung schwierig. Das Board verwendet einen Resonator. Da sind Quarz und Lastkondensatoren in einem Bauteil. Wenn Du nun einen Qurz bestücken willst, müssen da noch die beiden Lastkondensatoren gegen Masse bestückt werden. Ich weiss nicht, ob es Resonatoren mit 32,768kHz in der kleinen Bauform gibt. Als Alternative könntest Du auch diese Platine (https://forum.fhem.de/index.php/topic,73954.0.html) hier nehmen.

Mal noch ne doofe frage dazu, wenn ich den 8Mhz Quarz mit einem 32.768Hz tausche, läuft dann der Atmel nicht viel langsamer? Zwischen Mhz und Khz liegen ja 3 Potenzen... Passt das trotz des langsamerern Takts?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Februar 2018, 13:39:02
Zitat von: andirs am 27 Februar 2018, 13:30:01
Mal noch ne doofe frage dazu, wenn ich den 8Mhz Quarz mit einem 32.768Hz tausche, läuft dann der Atmel nicht viel langsamer? Zwischen Mhz und Khz liegen ja 3 Potenzen... Passt das trotz des langsamerern Takts?

Vorher müssen die Fuses auf internen 8MHz Takt umgestellt werden.
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 27 Februar 2018, 14:29:23
Cool, hab die Fuses grad mal umgeschrieben und den Resonator rausgelötet.
Dabei hab ich den Spannungsregler direkt mit entfernt.

Soweit scheint noch alles zu funktionieren

Dann muss ich jetzt nur noch auf die Quarze und die Keramik Kondensatoren warten :)
Titel: Antw:AskSin++ Library
Beitrag von: Linef am 27 Februar 2018, 17:39:25
Zitat von: papa am 27 Februar 2018, 08:16:10
Naja, wenn ca. 2-3 Minuten geschlafen wird, um dann nur mal kurz zu Messen und zu Senden, ist das schon ein Unterschied, ob die CPU die gesamte Zeit durchschläft oder alle 8 Sekunden vom Watchdog geweckt wird. Jedes Wecken bedeutet auch ein komplettes Prüfen aller Weckquellen, da es nicht möglich ist festzustellen, wer für das Wecken verantwortlich war (Watchdog, Interrupt, Timer)

Insbesondere braucht der Betrieb des Watchdog den meisten Strom. Schlafende CPU mit RTC braucht laut Datenblatt nur 0,6uA. Mit Watchdog werden dagegen 4,5uA verbraucht. Ständig. Und das macht dann schon einen Unterschied. Wenn die CPU aufwacht, wird zwar Strom im mA-Bereich verbraucht, aber i.d.R. nur wenige mSec (außer es wird tatsächlich gesendet/empfangen).
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 28 Februar 2018, 00:31:22
Hallo papa und Linef,
bezüglich Ruhestrom, ich will das jetzt hier nicht weiter ausreizen da OT, ich war nur der Meinung das z.B. beim use case Temp.sensor, der z.B. alle 10 min seinen Temp.wert schickt, der Unterschied zwischen 0,5 uA und 4 uA Ruhestrom (und auch das kurze Aufwachen alle 8sec) nicht so wichtig ist für den Batterieverbrauch, da der Löwenanteil für das Senden draufgehen wird. Hätte ich Zahlen für die Sendedauer einer weather msg könnte man das auch mal kalkulieren. Bei einer Fernbedienung die fast nie sendet sondern nur daliegt wäre das natürlich was anders, da würde sich ein grosser Laufzeitunterschied mit einer Batterie ergeben.

Ich hätte 2 Fragen, zum einen stehe ich mit jp112sdl in Kontakt bezüglich seiner example sketche, und da ist uns folgendes aufgefallen. Er hat als Basis für seinen HM-WDS10-TH-O DS18B20 sketch einen Stand von papa vom November benutzt, da wurde u.a. folgender code verwendet:

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


Heute sieht diese Stelle so aus

DEFREGISTER(WeatherRegsList0,DREG_BURSTRX)
typedef RegList0<WeatherRegsList0> WeatherList0;

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


Was genau bewirkt diese Änderung, hat das was mit Burst mode für die HM-CC-RT-DN zu tun? Und brauche ich die nicht wenn ich keine HM-CC-RT-DN direkt peere?

Und zweitens, ich habe heute mal mit meinen Testaufbau den HM-WDS10-TH-O programmiert. Temp.werte und Feuchtigkeit kommen an, genial, aber kann mir vielleicht jemand sagen warum ich den Batteriestatus nicht in der ccu2 (RaspberryMatic) sehe? Beim Wassermelder gibt es beim Device ein Feld 'Batterie ok' aber bei diesen Temp.sensor nicht?
Ich weiß, ist keine FHEM sondern eine HM Frage, aber vielleicht weiß es ja trotzdem jemand hier.

Danke,
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Februar 2018, 10:03:56
Zitat von: Tom Major am 28 Februar 2018, 00:31:22
Was genau bewirkt diese Änderung, hat das was mit Burst mode für die HM-CC-RT-DN zu tun? Und brauche ich die nicht wenn ich keine HM-CC-RT-DN direkt peere?

Wahrscheinlich gar nichts - ich habe das bis dahin fehlende Register BurtRX mit eingebaut. Es wird aber noch nicht beachtet. Hm - aber eigentlich fehlen jetzt die Register für die MasterID ... müste eigentlich so sein

DEFREGISTER(WeatherRegsList0,MASTERID_REGS,DREG_BURSTRX)


Zitat von: Tom Major am 28 Februar 2018, 00:31:22
Und zweitens, ich habe heute mal mit meinen Testaufbau den HM-WDS10-TH-O programmiert. Temp.werte und Feuchtigkeit kommen an, genial, aber kann mir vielleicht jemand sagen warum ich den Batteriestatus nicht in der ccu2 (RaspberryMatic) sehe? Beim Wassermelder gibt es beim Device ein Feld 'Batterie ok' aber bei diesen Temp.sensor nicht?
Ich weiß, ist keine FHEM sondern eine HM Frage, aber vielleicht weiß es ja trotzdem jemand hier.

Gute Frage. Das könnte ein Fehler auf RaspberryMatic-Seite sein, da der Sensor ja nur das Battery-Low-Bit setzt. Die Auswertung erfolgt auf der Empfängerseite. Vielleicht liegt es aber auch an den fehlenden Registern für die Addresse der Master - das gehört eigentlich immer in die Liste 0.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 28 Februar 2018, 11:09:10
Zitat von: papa am 28 Februar 2018, 10:03:56
Gute Frage. Das könnte ein Fehler auf RaspberryMatic-Seite sein, da der Sensor ja nur das Battery-Low-Bit setzt.

Das ist kein Fehler, sondern ein Feature und auch nicht nur bei RaspberryMatic sondern auch bei der CCU2 so.
Bei einigen wenigen Geräten wird unter "Status und Bedienung" -> "Geräte" das Feld für den Batteriezustand mit angezeigt.
So u.a. beim HM-Sec-WDS und HM-WDS30-OT2-SM.
Bei anderen Geräten (kapazitiver Füllstandssensor, Fensterkontakte, Energiezähler, Kontaktinterface) wiederum nicht.
Was auch immer man sich dabei gedacht hat...
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 28 Februar 2018, 13:30:52
Zitat von: jp112sdl am 28 Februar 2018, 11:09:10
Das ist kein Fehler, sondern ein Feature und auch nicht nur bei RaspberryMatic sondern auch bei der CCU2 so.
Bei einigen wenigen Geräten wird unter "Status und Bedienung" -> "Geräte" das Feld für den Batteriezustand mit angezeigt.
So u.a. beim HM-Sec-WDS und HM-WDS30-OT2-SM.
Bei anderen Geräten (kapazitiver Füllstandssensor, Fensterkontakte, Energiezähler, Kontaktinterface) wiederum nicht.
Was auch immer man sich dabei gedacht hat...
Ok, verstanden, danke für den Hinweis.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 28 Februar 2018, 13:34:51
Zitat von: papa am 28 Februar 2018, 10:03:56
Wahrscheinlich gar nichts - ich habe das bis dahin fehlende Register BurtRX mit eingebaut. Es wird aber noch nicht beachtet. Hm - aber eigentlich fehlen jetzt die Register für die MasterID ... müste eigentlich so sein
DEFREGISTER(WeatherRegsList0,MASTERID_REGS,DREG_BURSTRX)

Ok, es sollte also die MASTERID_REGS mit in den HM-WDS10-TH-O sketch rein?
Eine kurze Suche zeigt übrigens das MASTERID_REGS aktuell nur in 6 von 15 HM-... example sketeches verwendet wird.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 März 2018, 08:52:07
Zitat von: Tom Major am 28 Februar 2018, 13:34:51
Ok, es sollte also die MASTERID_REGS mit in den HM-WDS10-TH-O sketch rein?
Eine kurze Suche zeigt übrigens das MASTERID_REGS aktuell nur in 6 von 15 HM-... example sketeches verwendet wird.

Es gibt noch Examples, die nutzen die alte List0 Implementierung.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 07 März 2018, 01:17:43
In den letzten Tagen haben jp112sdl und ich uns mit einem universellen HM Sensor auf Basis der AskSin++ beschäftigt.
Im verlinkten Arduino sketch werden als Demo dummy Werte generiert und an die CCU2 gesendet. Aufbauend auf dem sketch kann man die Messwerte beliebiger Sensoren selbst einbauen. Anpassen muss man nur den sketch selbst und für die Darstellung in der CCU2 die Datei hb_uni_sensor1.xml.
Vielleicht hilft es ja jemanden.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)

Vielen Dank an papa, jp112sdl, Dirk und andirs für die Anregungen und Hilfestellungen.
Titel: Antw:AskSin++ Library
Beitrag von: LuBeDa am 07 März 2018, 09:11:01
Zitat von: Tom Major am 07 März 2018, 01:17:43
In den letzten Tagen haben jp112sdl und ich uns mit einem universellen HM Sensor auf Basis der AskSin++ beschäftigt.

Das ist richtig Klasse!!!

Genau das was ich brauche.

Nur..... was muss ich machen damit FHEM auch die Kanäle Temperatur 1 -4 , Humity, Pressure richtig versteht? Ich habe mal bei Homebrew Wired etwas gefunden und werde noch nicht daraus schlau wie man sein eigenes Homematic-Modul für Homebrew Geräte programmiert. Die XML alleine wird wohl nicht ausreichen.

Ludger

Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 März 2018, 18:03:48
Tja - das ist leider das Problem. Man braucht immer eine Erweiterung. Ich köknnte mir aber auch ein generisches Sensordevice vorstellen, wo die Payload einer Sensornachricht (Typ 0x53) durch ein/mehrere Attribut(e) beschrieben und dann entsprechend in einzelne Readings aufgeteilt wird.


valueSze = 2:4:4
valueFactor = 10:1:1
valueName = Temperatur:Licht:Druck


Es werden 3 Werte übertragen - 2 Byte mit der Temperatur, 4 Byte Licht und 4 Byte Druck. Der Temperaturwert muss noch durch 10 geteilt werden.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 März 2018, 18:13:50
Zitat von: papa am 07 März 2018, 18:03:48
Tja - das ist leider das Problem. Man braucht immer eine Erweiterung.

Ich komme ja aus der reinen HomeMatic-Welt und finde das mit dem Addon, denn es ist ja nur eine einmalige Installation, nicht weiter schlimm.
Hat auch den Vorteil, dass in der WebUI auch ein passendes Gerätesymbol angezeigt werden.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 07 März 2018, 18:29:09
Zitat von: LuBeDa am 07 März 2018, 09:11:01
Das ist richtig Klasse!!!
Genau das was ich brauche.
Nur..... was muss ich machen damit FHEM auch die Kanäle Temperatur 1 -4 , Humity, Pressure richtig versteht? Ich habe mal bei Homebrew Wired etwas gefunden und werde noch nicht daraus schlau wie man sein eigenes Homematic-Modul für Homebrew Geräte programmiert. Die XML alleine wird wohl nicht ausreichen.
Ludger

Bei mir läuft zur Zeit FHEM und RaspberryMatic parallel und ohne connection, da ich bezüglich HomeMatic und seinen Devices noch im Testmodus bin.

Ich könnte Dir aber HMConfig_SenTHPL.pm aus dem Universalsensor so anpassen, dass es für das Demo mit Temperatur 1 -4 , Humity, Pressure laufen sollte, testen kann ich es aber nicht. Bin nicht 100% sicher ob das für FHEM ausreicht aber ich glaube schon. Wenn Du das machen willst dann sag Bescheid. Du brauchst natürlich eine lauffähige Sensor HW (z.B. Arduino Pro Mini und CC1101) für den Test.

Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 März 2018, 19:18:19
Zitat von: jp112sdl am 07 März 2018, 18:13:50
Ich komme ja aus der reinen HomeMatic-Welt und finde das mit dem Addon, denn es ist ja nur eine einmalige Installation, nicht weiter schlimm.
Hat auch den Vorteil, dass in der WebUI auch ein passendes Gerätesymbol angezeigt werden.

Addon ist ja auch ok - aber bei FHEM ist es Code, der gebaucht wird. Die XML Files gehen für Homematic nicht.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 März 2018, 19:20:31
Zitat von: papa am 07 März 2018, 19:18:19
Die XML Files gehen für Homematic nicht.

Reden wir von denselben XML Files?
Dieses XML File hier zB
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/CCURM_Install/HB-UNI-Sensor1_CCURM-addon-src/addon/firmware/rftypes/hb_uni_sensor1.xml (https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/CCURM_Install/HB-UNI-Sensor1_CCURM-addon-src/addon/firmware/rftypes/hb_uni_sensor1.xml)
funktioniert wunderbar mit Homematic.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 März 2018, 19:23:04
Ja für die CCU . aber es war ja die Frage nach FHEM Integration.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 März 2018, 19:24:44
Zitat von: papa am 07 März 2018, 19:23:04
Ja für die CCU . aber es war ja die Frage nach FHEM Integration.

Ok, dann hab ich es nur falsch rum verstanden.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 07 März 2018, 19:41:16
Deswegen auch das Angebot an LuBeDa, den FHEM Perl code HMConfig_SenTHPL.pm für das neue Unisensor Demo anzupassen falls er das dann in FHEM testen kann...
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 07 März 2018, 20:01:55
Hallo zusammen,
mit Interesse verfolge ich diese Entwicklung. Den einen oder anderen Sensor habe ich schon testweise nachgebaut, ohne wirklich die Funktionsweise des Sketches zu verstehen.

Welcher Aufwand ist es, einen HM-MOD-EM-8 nachzubilden?

Am Original stört mich, dass er nach dem Einschalten nicht sofort den aktuellen Zustand liefert. Ich verwende diesen, um Reedkontakte (Fenster) abzufragen, muss nach einem Reboot der CCU aber erst jedes Fenster auf und wieder zu machen, damit der Sensor den richtigen Zustand liefert. Ich hatte dies bereits vor längerer Zeit bei EQ3  angemerkt, aber dort gibt es ja kaum noch Änderungen an der original FW. Vom Programmieraufwand kann dies m.E. nicht so viel sein, um beim Init erstmal alle Ports der Reihe nach abzufragen...

Es wäre daher super von Euch, wenn jemand für diesen Sensor einen Sketch entwickeln könnte.

VG


Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 08 März 2018, 00:30:17
Wie hoch der Aufwand für eine direkte Nachbildung eines HM-MOD-EM-8 ist kann ich nicht sagen, dazu stecke ich zu wenig in den diversen HM Listen, Modi, channels usw. drin.
Das UniSensor Beispiel lässt sich aber leicht so anpassen dass IO Bits der Reedkontakte anstatt Sensorwerte übertragen werden, entweder als 1 Byte pro Eingang oder 1 Bit pro Eingang, das xml file lässt sich für beide Varianten anpassen. Das könnte man natürlich auch bei Einschalten des Sensors für alle IOs übertragen.

ZitatAm Original stört mich, dass er nach dem Einschalten nicht sofort den aktuellen Zustand liefert. Ich verwende diesen, um Reedkontakte (Fenster) abzufragen, muss nach einem Reboot der CCU aber erst jedes Fenster auf und wieder zu machen, damit der Sensor den richtigen Zustand liefert. Ich hatte dies bereits vor längerer Zeit bei EQ3  angemerkt, aber dort gibt es ja kaum noch Änderungen an der original FW. Vom Programmieraufwand kann dies m.E. nicht so viel sein, um beim Init erstmal alle Ports der Reihe nach abzufragen...

Dieser Punkt ist mir unklar. Das würde voraussetzen das der Sensor ein reboot der CCU mitbekommt und dann den Status senden kann. Ein Sensor ist ja normalerweise im power down oder power save Modus wo er keinen Empfang hat. Keine Ahnung ob es eine Lösung gibt, trotzdem das reboot der CCU mitzubekommen, ist eventuell schwierig.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 08 März 2018, 18:25:36
Stimmt, so hatte ich das noch gar nicht gesehen. Der Sensor kommuniziert nur mit der CCU, wenn sich sein Zustand ändert oder bei Lowbat. Von einem Reboot bekommt er also nichts mit, da die Kommunikation nur in eine Richtung geht. Es müsste eine Möglichkeit geben, dass die CCU den Zustand aktiv abfragen kann, also einen Befehl dafür an den Sensor schickt und dieser darauf die aktuellen Zustände überträgt.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 08 März 2018, 18:46:45
Das Problem dabei ist dass das Modul im power-down Modus ist. Verbaut ist ein STM8L151 und von ELV beworben werden 3 uA Standby. Das ist dann der  Low-power wait mode des STM8, eine Änderung an seinen Ports weckt ihn auf. Ohne diese Änderung wird er halt den "Abfrage-Befehl" der CCU nicht empfangen können da im sleep.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 09 März 2018, 00:02:05
Zitat von: Gruenebe am 08 März 2018, 18:25:36
Der Sensor kommuniziert nur mit der CCU, wenn sich sein Zustand ändert oder bei Lowbat. Von einem Reboot bekommt er also nichts mit, da die Kommunikation nur in eine Richtung geht. Es müsste eine Möglichkeit geben, dass die CCU den Zustand aktiv abfragen kann, also einen Befehl dafür an den Sensor schickt und dieser darauf die aktuellen Zustände überträgt.

was wäre, wenn Du zusätzlich den Zustand  z.B. alle 6 / 12 / 24h einfach neu überträgst? So oft startest Du ja im Normalfall die CCU / FHEM nicht neu?
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 09 März 2018, 00:19:42
oder ein "Advanced" AskSin++ HM-MOD-EM-8, und ich glaube in diese Richtung ging ja auch die ursprüngliche Frage, welches
a) beim power-on alle IO Statusinfos sendet und/oder
b) einen extra Taster hat, welcher bei Betätigung diese Statusinfos überträgt.
Dann könnte man nach CCU reboot ein power-reset am HM-MOD-EM-8 machen oder eben den Taster drücken - das spart dann den Gang zu jedem Fenster  :)

Wieso speichert die CCU eigentlich nicht den letzten Status aller Reedkontakte bei diesem Modul?
Titel: Antw:AskSin++ Library
Beitrag von: LuBeDa am 09 März 2018, 10:12:38
Zitat von: Tom Major am 07 März 2018, 19:41:16
Angebot an LuBeDa

Gerne!!! :) :) :),
macht aber erst Sinn wenn meine Bauteile aus China angekommen sind. Bis dahin werde ich mal einen Blick in die XML und Perl-Module werfen.

Richtig cool wäre ein FHEM Modul bei dem man die XML importiert und die Readings werden durch die Einstellungen in der XML aufgebaut.

Habe aber keine Ahnung wie utopisch diese Idee ist.

Ludger
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 09 März 2018, 10:53:54
Zitat von: Tom Major am 09 März 2018, 00:19:42
oder ein "Advanced" AskSin++ HM-MOD-EM-8, und ich glaube in diese Richtung ging ja auch die ursprüngliche Frage, welches
a) beim power-on alle IO Statusinfos sendet und/oder
b) einen extra Taster hat, welcher bei Betätigung diese Statusinfos überträgt.
Dann könnte man nach CCU reboot ein power-reset am HM-MOD-EM-8 machen oder eben den Taster drücken - das spart dann den Gang zu jedem Fenster  :)

Helfen würde ja auch schon, wenn bei jeder Änderung der Zustand aller 8 Ports (1 Byte) übertragen wird und nicht nur das geänderte Bit, was es ja zu sein scheint. 1 Fenster nach dem Reboot öffnen oder schliessen ist nicht so aufwändig, als 8.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 März 2018, 00:34:03
Zitat von: Gruenebe am 09 März 2018, 10:53:54
Helfen würde ja auch schon, wenn bei jeder Änderung der Zustand aller 8 Ports (1 Byte) übertragen wird und nicht nur das geänderte Bit, was es ja zu sein scheint. 1 Fenster nach dem Reboot öffnen oder schliessen ist nicht so aufwändig, als 8.
Genau, wäre eine 3. Möglichkeit, finde ich auch gut.

Warum die CCU nicht den letzten Status speichert habe ich das hier gefunden im HM Forum:
ZitatDas der Status der Sensoren nicht stimmt bzw. nicht abgefragt wird ist eine bekannte hier oft diskutierte Eigenschaft des Systems. Daran wird sich nichts ändern. Das HM Konzept bei Batteriebetrieb ist so. An der Stelle muss man andere Hardware einsetzen, wenn es für die konkrete Anwendung so wichtig ist.
Herbert_Testmann
Also ein weites Feld für eigene HW und Firmware Konzepte, die man mit der Lib hier realisieren kann  :D
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 10 März 2018, 08:23:23
Zitat von: Tom Major am 10 März 2018, 00:34:03
Zitat
Das der Status der Sensoren nicht stimmt bzw. nicht abgefragt wird ist eine bekannte hier oft diskutierte Eigenschaft des Systems.
Warum die CCU nicht den letzten Status speichert habe ich das hier gefunden im HM Forum:Also ein weites Feld für eigene HW und Firmware Konzepte, die man mit der Lib hier realisieren kann  :D

Das ist wohl der Kompromiss, den man eingehen muss, wenn man die größtmögliche Batterielebensdauer herausholen will und die Geräte nicht mal per Burst geweckt werden können.
Jedoch nicht nur bezüglich der Batterielebensdauer hätte ich da bedenken.
Wenn nach einem Reboot der CCU alle Batterie-Sensoren (betrifft ja z.B. auch die Tür-/Fensterkontakte, Drehgriffkontakte) nacheinander geweckt werden müssten, um den Status abzufragen, wäre man ganz schnell bei einer Auslastung des DutyCycle.
Der liegt bei mir nach einem Reboot so schon bei ~40...60% (Normalbetrieb ~5%). Wenn ich dann einen Batterieaktor innerhalb der ersten Stunde 5 oder 6x schalte, bin ich bei 100% angekommen.

Aber abgesehen davon - wann startet man die CCU neu?
Entweder bei einem Firmware-Update. Da macht man es bewusst und man kann sich drauf einstellen, ggf. "wichtige" Kontakte anschließend einmal zu schließen/öffnen.
Oder nach einem Stromausfall, was (hoffentlich) nicht mehr als 1x pro Jahr (wenn überhaupt) vor kommt.
Ich denke, das ist vertretbar.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 10 März 2018, 10:12:30
Zitat von: jp112sdl am 10 März 2018, 08:23:23
Das ist wohl der Kompromiss, den man eingehen muss, wenn man die größtmögliche Batterielebensdauer herausholen will und die Geräte nicht mal per Burst geweckt werden können.
Jedoch nicht nur bezüglich der Batterielebensdauer hätte ich da bedenken.
Batterielebensdauer spielt in meinem Fall keine Rolle, da die Readkontakte eh alle an eine zentrale Stelle gehen, wo ein Netzteil die Sensoren versorgt.
Zitat von: jp112sdl am 10 März 2018, 08:23:23
Wenn nach einem Reboot der CCU alle Batterie-Sensoren (betrifft ja z.B. auch die Tür-/Fensterkontakte, Drehgriffkontakte) nacheinander geweckt werden müssten, um den Status abzufragen, wäre man ganz schnell bei einer Auslastung des DutyCycle.
Der liegt bei mir nach einem Reboot so schon bei ~40...60% (Normalbetrieb ~5%). Wenn ich dann einen Batterieaktor innerhalb der ersten Stunde 5 oder 6x schalte, bin ich bei 100% angekommen.
Wo ist aber der Unterschied, ob ich nach einem Reboot nacheinander an jedes Fenster gehe und dort den Status ändern muß, damit der richtige Zustand erkannt wird. Da wird bei jedem einzelnen Fenster eine erneutes Senden erzwungen (für einen Sensor also 8x) gegenüber einer einzigen Abfrage bei der gleich alle 8 Zustände einmal übertragen werden.
Zitat von: jp112sdl am 10 März 2018, 08:23:23
Aber abgesehen davon - wann startet man die CCU neu?
Entweder bei einem Firmware-Update. Da macht man es bewusst und man kann sich drauf einstellen, ggf. "wichtige" Kontakte anschließend einmal zu schließen/öffnen.
Oder nach einem Stromausfall, was (hoffentlich) nicht mehr als 1x pro Jahr (wenn überhaupt) vor kommt.
Ich denke, das ist vertretbar.
Das ist nicht die Frage und wohl von jeder individuellen Situation abhängig. Wenn ich damit z.B die Fenster in einem Wochenendhaus überwachen will, geht das nicht, da ich nach jedem Stromausfall, auch wenn er geplant ist, hinfahren müsste, um den Sensor neu zu initialisieren.

Warum machen wir SmartHome?
In erster Linie um uns das Leben zu vereinfachen und sicherer zu machen.

Ich habe keine originalen Tür/Fensterkontakte, aber aus Deiner Bemerkung oben schliesse ich, dass die das gleiche Verhalten haben. Also auch ,,manuell aufgeweckt" werden müssen.
Bei meinen Fensterkontakten ist es noch so, dass diese bei Zustand offen und Regen die Rolläden runter fahren sollen - typisches SmartHome Szenario. Fällt aber vor einem Starkregen der Strom aus, habe ich u.U. die Bude voll Wasser. Das will man ja eigentlich vermeiden.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 10 März 2018, 10:17:19
Zitat von: Klaus0815 am 09 März 2018, 00:02:05
was wäre, wenn Du zusätzlich den Zustand  z.B. alle 6 / 12 / 24h einfach neu überträgst? So oft startest Du ja im Normalfall die CCU / FHEM nicht neu?
Ich kann den Sensor ja leider nicht aus einem Programm heraus zwingen, den aktuellen Zustand der Ports zu übertragen. Nur eine Portänderung überträgt den neuen Zustand an die CCU.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 10 März 2018, 10:31:11
Zitat von: Gruenebe am 10 März 2018, 10:12:30
Batterielebensdauer spielt in meinem Fall keine Rolle, da die Readkontakte eh alle an eine zentrale Stelle gehen, wo ein Netzteil die Sensoren versorgt.

Ok, da hätte man einen "Netzteil"-Modus einbauen können.
Dann müsste der HM-MOD auch noch so intelligent sein, dass er bei Nichterreichbarkeit seiner angelernten Zentrale, alle x Minuten seinen (kompletten) Status erneut überträgt.
Aber da wir von eQ-3 nichts neues mehr im klassischen HM-Sektor erwarten brauchen, muss wohl wirklich eine Custom-Lösung her :)

Zitat von: Gruenebe am 10 März 2018, 10:12:30
Warum machen wir SmartHome?
In erster Linie um uns das Leben zu vereinfachen und sicherer zu machen.

Ich habe keine originalen Tür/Fensterkontakte, aber aus Deiner Bemerkung oben schliesse ich, dass die das gleiche Verhalten haben. Also auch ,,manuell aufgeweckt" werden müssen.
Bei meinen Fensterkontakten ist es noch so, dass diese bei Zustand offen und Regen die Rolläden runter fahren sollen - typisches SmartHome Szenario. Fällt aber vor einem Starkregen der Strom aus, habe ich u.U. die Bude voll Wasser. Das will man ja eigentlich vermeiden.
Dein Szenario ist denkbar, aber sehr unwahrscheinlich.
Dann müsste der Strom vor dem Starkregen aber rechtzeitig wieder zurück sein, damit dein Rollladen ja auch fahren kann.
Um Stromausfälle (rechnerisch bis zu 1 Tag) zu puffern, nutze ich am RaspberryMatic eine Goobay Powerbank mit 20.000mAh.
Könnte man sicher auch in die CCU-Stromversorgung einschleifen.

Aber gut - vielleicht erfüllt HomeMatic wirklich nicht deine Ansprüche. Es gibt ja auch noch zahlreiche weitere Anbieter.
Ich habe mich auch schon desöfteren grün und blau geärgert über HM.

Ja, bei den originalen TFK (HM-Sec-SCO) ist es genau so.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 10 März 2018, 11:58:56
Zitat von: jp112sdl am 10 März 2018, 10:31:11
Aber da wir von eQ-3 nichts neues mehr im klassischen HM-Sektor erwarten brauchen, muss wohl wirklich eine Custom-Lösung her :)
Genau das war ja mein ursprünglicher Ansatz, bevor die Diskussion dann etwas OT wurde.

Leider muß ich, was die Programmierung angeht, im Bereich C(++) und OO-Programmierung passen.
Ich kann die Beispiele zwar in der Arduino IDE nachbauen und auch auf den Mini Pro bringen, aber verstehe nicht, was bei der BidCos Kommunikation abgeht.

Meine Stärken liegen eher im Bereich der Hardware.

Da meine SmartHome Anfänge schon etwas zurückliegen, hatte ich anfänglich auf eine CC2 Lösung von Conrad gesetzt mit den Erweiterungen von Andre Helbig (CC2Net).
Das Porgrammierniveau dort, ist etwas, wo ich noch mitkomme.

Problematisch war jedoch, dass die gesamte Hauskommunikation auf einem I2C bzw. CAN Bus basierte.
Kabeltechnisch weniger das Problem, da ich als ich mein Haus vor mehr als 10 Jahren gebaut habe, sehr viel CAT5 Kabel verlegt habe. Daher auch die Reedkontakte von den Fenstern.
Über lange Strecken war die Kommunikation darüber aber nicht sehr stabil, so dass ich dann vor etwa 2 Jahren auf Homematic umgestellt habe.

Meine Idee war nun, man könnte z.B. die zahlreichen I2C Erweiterungen von Andre https://www.cctools.eu/artikelindex.php/I2C-Bus mit dem Arduino verheiraten.
Vorteil von Andre`s Lösungen aus meiner Sicht sind die zahlreichen Hutschienenvarianten, wo man in das Gehäuse locker noch einen Arduino unterbringen könnte.
Man bräuchte nur die Spannung intern abgreifen und die I2C Ports des Arduino mit den Lötpunkten (Steckern) auf der Platine verbinden.

So könnte man z.B. mit der Max7311 Erweiterung ein 16 Kanal Eingangs- oder Ausgangsmodul bauen oder auch gemischt 8 Port Eingang und 8 Port Ausgang,
wie man es sonst nur von HM Wired kennt. Die Ansteuerung eines MAX7311 per I2C im Arduino ist nicht das Problem, das habe ich auch schon hinbekommen.
Ist letztendlich auch nichts anderes, als einen I2C Sensor anzubinden.

Auf CCU Seite bräuchte das Ganze dann aber wahrscheinlich ein komplett neues XML File, wo ich überhaupt keine Ahnung habe, ob und wie das möglich ist.
Wenn ich aber den Universalsensor anschaue, muß es ja gehen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 März 2018, 23:44:34
Hallo papa,
ich habe auf Anregung von jp112sdl mein UniSensor Beispiel so überarbeitet dass das Sendeintervall von RaspberryMatic oder CCU aus konfiguriert werden kann.
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino (https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino)

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

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

Danke,
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 März 2018, 20:14:26
Du kannst Dir auch ganz einfach eigene Register definieren - hier z.B. 16bit an Offset 0xe0.


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

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


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


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


Die erzeugte Klasse Reg1 beinhaltet die Umrechnung Register -> Offset und umgekehrt. Außerdem wird getSize() definiert und gibt die Anzahl der Byte zurück.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 12 März 2018, 01:47:11
ZitatDu kannst Dir auch ganz einfach eigene Register definieren - hier z.B. 16bit an Offset 0xe0.

Ok, habe das verstanden und probiere das morgen bei meinem Sketch aus, um die Hilfslösung mit refRunningTimeTopButton damit zu ersetzen.
Danke schon mal für den Hinweis und den Beispielcode.
Titel: Antw:AskSin++ Library
Beitrag von: hailfinger am 12 März 2018, 23:19:14
Ist eine Portierung auf EFM32G200F64 (SiLabs Energy Micro EFM32 Family) geplant?
Von den Hardwaredaten (ARM Cortex-M3, 64kB Flash, 16 kB RAM) sollte das theoretisch möglich sein.
Dieser Mikrocontroller ist in den aktuellen Hm-Sec-SCo Tür-/Fensterkontakt ARR verbaut (die Beschriftung auf dem Mikrocontroller lautet EFM32 G200F64).

Ich würde gerne langfristig den HM-Sec-SCo um einen Zusatzsensor erweitern, da die Plattform aus Bastlersicht sehr praktisch ist (AAA-Batterie, kompakte Bauform). Mit AskSin++-Unterstützung wäre das eine gangbare Lösung.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 März 2018, 09:59:29
Zitat von: hailfinger am 12 März 2018, 23:19:14
Ist eine Portierung auf EFM32G200F64 (SiLabs Energy Micro EFM32 Family) geplant?
Von den Hardwaredaten (ARM Cortex-M3, 64kB Flash, 16 kB RAM) sollte das theoretisch möglich sein.
Dieser Mikrocontroller ist in den aktuellen Hm-Sec-SCo Tür-/Fensterkontakt ARR verbaut (die Beschriftung auf dem Mikrocontroller lautet EFM32 G200F64).

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

Soweit ich das weiss, gibt es keine Arduino-Umgebung für den EFM32.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 15 März 2018, 01:18:06
Habe den Code für eigene Register Def. getestet und funktioniert einwandfrei, damit ist z.B. ein 16bit Register zum Konfigurieren des Sendeintervalls des Universalsensors möglich.
https://github.com/TomMajor/AskSinPP_Examples (https://github.com/TomMajor/AskSinPP_Examples)

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

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

mit BCAST als 4. Param bei Message::init()
- Ack wird nicht erwartet
- LazyConfig funktioniert nicht, d.h. eine anstehende Konf.Änderung von der Zentrale muss durch den Config Button am Sensor übernommen werden!
- optimal für Batterielebensdauer
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 18 März 2018, 16:50:15
Zitat von: Tom Major am 07 März 2018, 19:41:16
Deswegen auch das Angebot an LuBeDa, den FHEM Perl code HMConfig_SenTHPL.pm für das neue Unisensor Demo anzupassen falls er das dann in FHEM testen kann...
@Tom Major , ich habe gerade deinen HB_UNI-Sensor1 auf dem Steckbrett laufen, ich habe lediglich deine Device Model F301 in F101 geändert damit es mit  der HMConfig_SenTHPL.pm zusammen passt. An Readings bekomme ich jetzt schon mal

2018-03-18 15:51:25   batVoltage      0.00
2018-03-18 15:51:25   battery         ok
2018-03-18 15:51:25   humidity        4
2018-03-18 15:51:25   pressure        211.4
2018-03-18 15:51:25   state           T: 19.2 H: 4 P: 211.4
2018-03-18 15:51:25   temperature     19.2

Sensoren sind keine z.Z. angeschlossen, lasse das mit deinen  Dummys laufen. BCAST auf ich auf BIDI geändert, aber LazyConfig scheint doch nicht zu gehen.
Hatte versucht das Register lowBatLimitTHPL so zu ändern, die Änderungen wurde aber nicht beim Empfang von Sensordaten übertragen sondern erst durch drücken des Config Buttons.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 März 2018, 17:21:37
Zitat von: Wzut am 18 März 2018, 16:50:15
Hatte versucht das Register lowBatLimitTHPL so zu ändern, die Änderungen wurde aber nicht beim Empfang von Sensordaten übertragen sondern erst durch drücken des Config Buttons.

FHEM muss für das Device auch LazyConfig kennen, sonst geht das nicht.
Außerdem sollte in der Message das WKMEUP Flag gesetzt sein, damit wird signalisiert, dass das Gerät bereit ist, weitere Nachrichten zu empfangen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 März 2018, 17:29:50
Zitat von: Tom Major am 15 März 2018, 01:18:06
Habe den Code für eigene Register Def. getestet und funktioniert einwandfrei, damit ist z.B. ein 16bit Register zum Konfigurieren des Sendeintervalls des Universalsensors möglich.
https://github.com/TomMajor/AskSinPP_Examples (https://github.com/TomMajor/AskSinPP_Examples)

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

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

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

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

BIDI - fordert den Empfänger auf ein Ack zu schicken. Das wird auch zwingend für AES-Handling gebraucht.
BCAST - signalisiert eine Broadcast-Message. Das wird z.B. verwendet, wenn mehrere Peers vor einen Sensor existieren. Es wird dann an einen Peer gesndet und zusätzlich das BCAST-Flag gesetzt. So dass sich alle die Nachrricht ansehen. Ein Ack macht dann natürlich keinen Sinn - es ist ja nicht klar, wer das senden soll.
WKMEUP - wird für LazyConfig verwendet. Ist es in einer Message gesetzt, so weiss die Zentrale, dass das Geräte noch kurz auf weitere Nachrichten wartet. Die Lib setzt diese Flag für die StatusInfo-Message automatisch. Außerdem bleibt nach einer Kommunikation der Empfang grundsätzlich für 500ms angeschalten.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 18 März 2018, 17:41:11
Zitat von: Wzut am 18 März 2018, 16:50:15
@Tom Major , ich habe gerade deinen HB_UNI-Sensor1 auf dem Steckbrett laufen, ich habe lediglich deine Device Model F301 in F101 geändert damit es mit  der HMConfig_SenTHPL.pm zusammen passt. An Readings bekomme ich jetzt schon mal

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

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

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

Hast Du mal geschaut ob FHEM diesen Mechanismus einer "anstehenden Konfigurationsänderung" überhaupt unterstützt?
Titel: Antw:AskSin++ Library
Beitrag von: cactus-online am 18 März 2018, 17:42:44
Zitat von: jp112sdl am 07 März 2018, 18:13:50
Ich komme ja aus der reinen HomeMatic-Welt und finde das mit dem Addon, denn es ist ja nur eine einmalige Installation, nicht weiter schlimm.
Hat auch den Vorteil, dass in der WebUI auch ein passendes Gerätesymbol angezeigt werden.

Hast Du schon mal ein CCU Firmware-Update gemacht ? War die Beschreibungsdatei bzw. das Gerät dann noch da ? Ich  Frage, weil das beim UWS https://wiki.fhem.de/wiki/Universalsensor leider nicht der Fall war und nach jedem CCU Firmware-Update, dann das "add-on" wieder erneut eingespielt werden muss.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 18 März 2018, 17:44:54
Ja, das Addon ist anschließend noch da.
Ggf muss 2x neu gestartet werden nach einem Firmware Update


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 18 März 2018, 18:14:28
Das mit dem 2x neustarten kommt daher, dass bei der Installation des Addons (und das wird auch automatisch nach einem Firmware Update durchgeführt) die Gerätebeschreibungsdateien erst kopiert werden, wenn alle Dienste schon laufen
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 18 März 2018, 18:15:02
Zitat von: papa am 18 März 2018, 17:21:37
FHEM muss für das Device auch LazyConfig kennen, sonst geht das nicht.
Außerdem sollte in der Message das WKMEUP Flag gesetzt sein, damit wird signalisiert, dass das Gerät bereit ist, weitere Nachrichten zu empfangen.
hmm laut https://github.com/kc-GitHub/Wettersensor/tree/master/Contrib/FHEM -> add lazy config option , sollte also für F101 und F102 nichts Neues sein.
BIDI habe auf WKMEUP geändert, leider ohne Erfolg.

Zitat von: Tom Major am 18 März 2018, 17:41:11
Hast Du mal geschaut ob FHEM diesen Mechanismus einer "anstehenden Konfigurationsänderung" überhaupt unterstützt?
Da es bei anderen Geräten aus papas Baukasten geht sollte FHEM das nicht unbekannt sein.  Ist für mich aber nicht tragisch da ich z.Z. dafür keinen Einsatzfall habe,     
Titel: Antw:AskSin++ Library
Beitrag von: cactus-online am 18 März 2018, 18:31:06
Zitat von: papa am 20 Februar 2018, 17:40:42
Die Pins sind Template-Argumente. Siehe auch BatterySensor.h

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



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


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

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

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



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

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


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

lg.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 18 März 2018, 18:50:36
11,12,& 13 kannst du nicht ändern , siehe Datenblatt des ATMega328. Einzig CS auf Pin 10 kannst du bedenklos umlegen.
D.h. die interne LED auf Pin 13 ist für dich verloren/wertlos , da hatten die Arduino Designer kein glückliches Händchen :)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 März 2018, 19:49:14
Zitat von: Wzut am 18 März 2018, 18:15:02
hmm laut https://github.com/kc-GitHub/Wettersensor/tree/master/Contrib/FHEM -> add lazy config option , sollte also für F101 und F102 nichts Neues sein.
BIDI habe auf WKMEUP geändert, leider ohne Erfolg.
Da es bei anderen Geräten aus papas Baukasten geht sollte FHEM das nicht unbekannt sein.  Ist für mich aber nicht tragisch da ich z.Z. dafür keinen Einsatzfall habe,   

Mach mal beide -> BIDI|WKMEUP
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 18 März 2018, 20:05:45
Hat schon mal jemand das Phänomen beobachtet, dass ein Arduino/CC1101 auf Dauersendung war?

Ist mir nun schon ein zweites Mal passiert...  :-[
In der ganzen Bude ging nix (Funkgesteuertes) mehr.
Hab zum Glück nen SDR und konnte den Störer schnell ausfindig machen.
Ein nachgebauter WDS 10 TH O.

Batterien kurz raus - wieder rein. Nun geht wieder alles.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 März 2018, 20:14:19
Zitat von: jp112sdl am 18 März 2018, 20:05:45
Hat schon mal jemand das Phänomen beobachtet, dass ein Arduino/CC1101 auf Dauersendung war?

Ist mir nun schon ein zweites Mal passiert...  :-[
In der ganzen Bude ging nix (Funkgesteuertes) mehr.
Hab zum Glück nen SDR und konnte den Störer schnell ausfindig machen.
Ein nachgebauter WDS 10 TH O.

Batterien kurz raus - wieder rein. Nun geht wieder alles.

Hm - ich hatte mal ne Fernbedienung, die auf Dauersenden war. Aber ich denke da ist das Long-Press-Problem bei nicht vorhandenen Peer Schuld gewesen. Das kann aber bei WDS nicht sein.
Hast Du irgendwelche Logs ? Was wurde denn gesendet ?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 18 März 2018, 20:58:41
Zitat von: papa am 18 März 2018, 20:14:19
Hast Du irgendwelche Logs ? Was wurde denn gesendet ?

Hab ich leider nicht, da das Ding autark im Keller hängt.

Die CCU sagte mir "Kommunikationsstörung" zu so ziemlich allen meinen Geräten.
Hatte ich vor ein paar Wochen erst... Daraufhin hab ich mir für 13 EUR so nen DVB-T-Stick geholt, den man auch als SDR missbrauchen kann.
Mit CubicSDR habe ich dann einen Dauersender gesehen und bin (ohne Antenne!) der Signalquelle entgegengegangen.
Zu hören war währenddessen ein "Dauerquietschen", wie man es von FSK kennt. Also es war nicht nur ein Träger aufgetastet, sondern es muss auch permanent ein Datenstrom gesendet worden sein.

Ein ähnliches Verhalten hab ich mal in der HomeMatic-Community von den Fensterkontakten gelesen.

Daher hatte ich nun weniger den Sketch/Arduino in Verdacht - viel mehr den CC1101.

Sehr seltsam - ich beobachte das mal weiter.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 19 März 2018, 00:26:39
Zitat@Tom Major , ich habe gerade deinen HB_UNI-Sensor1 auf dem Steckbrett laufen, ich habe lediglich deine Device Model F301 in F101 geändert damit es mit  der HMConfig_SenTHPL.pm zusammen passt. An Readings bekomme ich jetzt schon mal

ok, wenn FHEM lazyconfig unterstüzt ist das geklärt.
Hast Du gecheckt ob in deinem HMConfig_SenTHPL.pm bei F101 das steht
rxt => 'l:w:c:f'

Ausserdem:
ZitatLazyConfig
Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung. Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.A. auf ein Config.

Kann es das sein (CUL/CUNO)?
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 19 März 2018, 00:31:15
Zitat11,12,& 13 kannst du nicht ändern , siehe Datenblatt des ATMega328. Einzig CS auf Pin 10 kannst du bedenklos umlegen.
D.h. die interne LED auf Pin 13 ist für dich verloren/wertlos , da hatten die Arduino Designer kein glückliches Händchen :)

Eine Möglichkeit für Fortgeschrittene wäre noch, in papa's Radio.h statt HW-SPI eine SW-SPI mit anderen Pins einzubauen, aber ich bezweifele mal das die LED an Pin 13 den Aufwand wert ist  ;)
Titel: Antw:AskSin++ Library
Beitrag von: cactus-online am 19 März 2018, 08:56:33
Zitat von: Tom Major am 19 März 2018, 00:31:15
Eine Möglichkeit für Fortgeschrittene wäre noch, in papa's Radio.h statt HW-SPI eine SW-SPI mit anderen Pins einzubauen, aber ich bezweifele mal das die LED an Pin 13 den Aufwand wert ist  ;)

Ganz sicher nicht. Da ist es besser, die LED auszulöten (wegen des unnötigen Stromverbrauches). Aber grundsätzlich bräuchte man dann ja eigentlich die Pins in der Typedef dann gar nicht. Egal, es ist halt wie es ist. Danke für die Infos, dann habe ich wenigstens verstanden, warum das so ist.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 19 März 2018, 13:46:21
Zitat von: cactus-online am 19 März 2018, 08:56:33
Ganz sicher nicht. Da ist es besser, die LED auszulöten (wegen des unnötigen Stromverbrauches).

Kenne Dein HW setup nicht, aber bei meinem Pro Mini hat die LED an Pin 13 keinen Einfluss da sie ja im sleep aus ist. Erreiche ca. 4uA im sleep mit LED. Bild der HW ist ein paar Seiten vorher zu sehen. Nur den LDO und die Power LED habe ich ausgelötet.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 19 März 2018, 13:53:40
Zitat von: jp112sdl am 18 März 2018, 20:58:41
Zu hören war währenddessen ein "Dauerquietschen", wie man es von FSK kennt. Also es war nicht nur ein Träger aufgetastet, sondern es muss auch permanent ein Datenstrom gesendet worden sein.
Ein ähnliches Verhalten hab ich mal in der HomeMatic-Community von den Fensterkontakten gelesen.
Daher hatte ich nun weniger den Sketch/Arduino in Verdacht - viel mehr den CC1101.
Sehr seltsam - ich beobachte das mal weiter.

Hmm, das klingt nicht gut.
Falls es noch einmal auftritt bei dem Selbstbau WDS 10 TH O, könntest Du hingehen und mit dem Multimeter messen ob chip select des CC1101 auf low oder high liegt? Ausserdem messen ob man an SCK diesen Dauer-Datenstrom sieht (Multimeter müsste ca. VBat/2 anzeigen, besser wäre natürlich ein Oszi, aber für ersten Test reicht auch Multimeter denke ich).
Um einzugrenzen ob es an der sketch SW oder intern am CC1101 liegt.
Man könnte ja dann über einen watchdog nachdenken, hat aber nur Sinn wenn der Dauer Senden Befehl von ausserhalb des CC1101 kommen würde.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 19 März 2018, 17:35:09
Zitat von: papa am 18 März 2018, 19:49:14
Mach mal beide -> BIDI|WKMEUP
Bingo, so scheint es zu klappen. regSet lowBatLimitTHPL 1.1 hat dann CMDs_pending zur Folge
Bei der nächsten Übertragung der Sensorwerte konnte ich in der seriellen Konsole sehen : Config Changed  List 0 , lowBatLimitTHPL : 11
und CMDs done. set getConfig , wieder CMDs_pending , nach der nächsten Übertragung und CMDs done liefert auch get regList den neuen Wert.

Um nun den Sketch von Tom Major als echten Ersatz für den Unisensor benutzen zu können müsste nur noch geklärt werden wie man den Wert für die Höhe zum Sensor überträgt, ( das ist wohl z.Z. nicht vorgesehen ) bzw. wie setzt man von FHEM aus das neue Register für den Sendeintervall.   

Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 19 März 2018, 19:21:34
Zitat von: Wzut am 19 März 2018, 17:35:09
Bingo, so scheint es zu klappen. regSet lowBatLimitTHPL 1.1 hat dann CMDs_pending zur Folge
Bei der nächsten Übertragung der Sensorwerte konnte ich in der seriellen Konsole sehen : Config Changed  List 0 , lowBatLimitTHPL : 11
und CMDs done. set getConfig , wieder CMDs_pending , nach der nächsten Übertragung und CMDs done liefert auch get regList den neuen Wert.

Um nun den Sketch von Tom Major als echten Ersatz für den Unisensor benutzen zu können müsste nur noch geklärt werden wie man den Wert für die Höhe zum Sensor überträgt, ( das ist wohl z.Z. nicht vorgesehen ) bzw. wie setzt man von FHEM aus das neue Register für den Sendeintervall.

Freut mich dass es jetzt auch mit FHEM geht.
Höhe einstellen ist vorgesehen, tatsächlich bin ich gerade dabei den BME280 zu integrieren, wenn der läuft mach ich auch die Höhe, wird in den nächsten Tagen passieren..
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 19 März 2018, 19:51:52
Zitat von: Tom Major am 19 März 2018, 19:21:34
Freut mich dass es jetzt auch mit FHEM geht.
naja so richtig wollen die beiden noch nicht mit einander ... Ich habe mir jetzt mal die übertragenden Werte genau angeschaut :
1. temperature scheint zu passen
2. payload 0 & 1 sind bei dir 16 Bit Luftdruck , payload 0 wird beim Typ F101 allerdings als  8 Bit humidity ausgewertet
3. payload 1 & 2 sind dann in der Auswertung  die 16 Bit Luftdruck
danach kommt nichts mehr ( habe die Message Länge auch schon erhöht )
die  HMConfig_SenTHPL.pm zerlegt die Msg so :
my ($dTempBat, $humidity, $pressure, $luminosity, $batVoltage) = map{hex($_)} unpack ('A4A2A4A8A4', $msgData);
D.h. $dTempBat, $humidity, $pressure passen mit meinem Versuch zusammen , allerdings fehlen die letzten beiden.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 19 März 2018, 22:44:04
ja, das FHEM Modul war noch eine Baustelle. Habe das originale so modifiziert dass es zu meiner payload aus dem Universalsensor passen müsste und erstmalig bei mir eingecheckt, schau es Dir mal an, im Ordner FHEM:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)
Titel: Antw:AskSin++ Library
Beitrag von: andirs am 20 März 2018, 12:24:26
Zitat von: Tom Major am 19 März 2018, 13:46:21
Kenne Dein HW setup nicht, aber bei meinem Pro Mini hat die LED an Pin 13 keinen Einfluss da sie ja im sleep aus ist. Erreiche ca. 4uA im sleep mit LED. Bild der HW ist ein paar Seiten vorher zu sehen. Nur den LDO und die Power LED habe ich ausgelötet.

Gelten die 4uA für den Ardunio alleine oder ist da der Verbrauch des CC1101 schon mit eingerechnet?
Schickt die Lib den CC1011 normalerweise schlafen? Ich frage daher weil ich auch etwa 4uA im sleep alleine für den Arduino erreiche.
Wenn der CC1101 angeschlossen ist habe ich in etwa 1,5 mA. Ich hab schon überlegt alle Sensoren und das Funkmodul während des sleeps von der Versorgungsspannung zu trennen...
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 20 März 2018, 12:35:55
Zitat von: andirs am 20 März 2018, 12:24:26
Gelten die 4uA für den Ardunio alleine oder ist da der Verbrauch des CC1101 schon mit eingerechnet?
Schickt die Lib den CC1011 normalerweise schlafen? Ich frage daher weil ich auch etwa 4uA im sleep alleine für den Arduino erreiche.
Wenn der CC1101 angeschlossen ist habe ich in etwa 1,5 mA. Ich hab schon überlegt alle Sensoren und das Funkmodul während des sleeps von der Versorgungsspannung zu trennen...
Die 4 uA gelten für den Arduino (LDO und power LED raus). Das ist der power down Modus mit ext. Quarz (8 MHz in dem Fall), die 4 uA werden für den watchdog OSC benötigt der das Teil ja wieder aufwecken muss.
Mit int. OSC statt 8 MHz und 32kHz als RTC kann man den watchdog disablen da dann die RTC wecken kann. Dann kommt man auf ca. 1 uA.
CC1101 wird von papas lib in den sleep geschickt, der braucht dann überhaupt keinen Strom, < 1uA, müsste im Datenblatt nachschauen.

Sensoren müssen normalerweise nicht extra abgeschaltet werden, kommt natürlich auf den Sensor an.
Bei meinem Universalsensor mit momentan DS18x20 und BME280  (Helligkeit kommt noch) ist das nicht nötig.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 März 2018, 13:09:00
Das kommt ganz auf den verwendeten Sleep-Mode an. Im sparsamsten Modus wird das CC1101 abgeschaltet, wenn es nicht gebraucht wird. Dafür kann man dann auch nicht mehr so einfach durch den Funk aufgeweckt werden.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 20 März 2018, 15:17:47
Zitat von: Tom Major am 19 März 2018, 22:44:04
Habe das originale so modifiziert dass es zu meiner payload aus dem Universalsensor passen müsste und erstmalig bei mir eingecheckt, schau es Dir mal an, im Ordner FHEM:
Ahhh eine Insel , jetzt habe es es geschnallt warum ich die anderen Werte nicht bekommen habe A4A2A4A8A4 vs. A4A4A2A2A4 :)
Ok, ich habe jetzt verstanden wie ich mir einen Sensor mit beliebiger Kennung baue , payload 0-x mit meinen Werten füttere und das Ganze auf FHEM Seite wieder in Readings zerpflücken kann.
Unklar ist mir jetzt noch : wie bekomme ich elegant einen Sollwert von FHEM Richtung Sensor und wie finde ich ihn im Sensor zur Verarbeitung wieder ?
Den Part mit regSet und dem Register lowBatLimitTHPL konnte ich auf FHEM Seite zumindest nachvollziehen, der Wertebereich ist zwar z.Z auf 1-5 beschränkt, ist aber für die ersten Versuche egal. Der Unisensor  macht das mit dem alitude wohl genau so. OK, zusammen mit der nun funktionierenden LayzConfig eine mögliche Variante um Werte zum Sensor zu bekommen. Es muss aber doch auch noch eleganter gehen wie z.B. bei einem Rolloaktor, wo man einfach mit Set <Device> pct X den Wert übermitteln kann (Mir ist klar das der Sensor dann nicht im Tiefschlaf sein darf um das Telegramm auch verarbeiten zu können)   
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 März 2018, 15:28:50
Zitat von: Wzut am 20 März 2018, 15:17:47
Ahhh eine Insel , jetzt habe es es geschnallt warum ich die anderen Werte nicht bekommen habe A4A2A4A8A4 vs. A4A4A2A2A4 :)
Ok, ich habe jetzt verstanden wie ich mir einen Sensor mit beliebiger Kennung baue , payload 0-x mit meinen Werten füttere und das Ganze auf FHEM Seite wieder in Readings zerpflücken kann.
Unklar ist mir jetzt noch : wie bekomme ich elegant einen Sollwert von FHEM Richtung Sensor und wie finde ich ihn im Sensor zur Verarbeitung wieder ?
Den Part mit regSet und dem Register lowBatLimitTHPL konnte ich auf FHEM Seite zumindest nachvollziehen, der Wertebereich ist zwar z.Z auf 1-5 beschränkt, ist aber für die ersten Versuche egal. Der Unisensor  macht das mit dem alitude wohl genau so. OK, zusammen mit der nun funktionierenden LayzConfig eine mögliche Variante um Werte zum Sensor zu bekommen. Es muss aber doch auch noch eleganter gehen wie z.B. bei einem Rolloaktor, wo man einfach mit Set <Device> pct X den Wert übermitteln kann (Mir ist klar das der Sensor dann nicht im Tiefschlaf sein darf um das Telegramm auch verarbeiten zu können)

Auf der AskSin++ Seite musst Du nur einfach
  bool Channel::process (const ActionSetMsg& msg) {}
für die Channel Klasse implementieren. Der BlindChannel macht einfach ein
  bool process (const ActionSetMsg& msg) {
    setDestLevel( msg.value() );
    return true;
  }

Wie man das ganze jetzt von FHEM aus triggert, ist mir noch nicht wirklich klar.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 20 März 2018, 15:42:06
Zitat von: andirs am 20 März 2018, 12:24:26
Wenn der CC1101 angeschlossen ist habe ich in etwa 1,5 mA. Ich hab schon überlegt alle Sensoren und das Funkmodul während des sleeps von der Versorgungsspannung zu trennen...

Wenn Du das in der sketch loop() drin hast

// if nothing to do - go sleep
hal.activity.savePower<Sleep<>>(hal);

sollte der CC1101 < 1uA ziehen..
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 20 März 2018, 15:45:11
Zitat
Ahhh eine Insel , jetzt habe es es geschnallt warum ich die anderen Werte nicht bekommen habe A4A2A4A8A4 vs. A4A4A2A2A4 :)
Ok, ich habe jetzt verstanden wie ich mir einen Sensor mit beliebiger Kennung baue , payload 0-x mit meinen Werten füttere und das Ganze auf FHEM Seite wieder in Readings zerpflücken kann.

Hast Du zufällig mal geschaut ob mein modifiziertes FHEM Modul alle Sensorwerte zu FHEM durchroutet?
Konfigurierbare Höhe baue ich heute abend ein.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 20 März 2018, 16:01:07
Zitat von: Tom Major am 20 März 2018, 15:45:11
Hast Du zufällig mal geschaut ob mein modifiziertes FHEM Modul alle Sensorwerte zu FHEM durchroutet?
ja mir fehlten bisher die letzten beiden Werte (batVoltage und Helligkeit), nach der Anpassung im FHEM Modul habe ich
zum einen jetzt batVoltage mit Werten (war vorher immer 0.00) und ein neues Reading  brightness mit meinem Testwert.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 21 März 2018, 01:47:32
ok, habe den BME280 im Universalsensor integriert und die Höhe für die Luftdruckberechnung (NN) konfigurierbar gemacht.
Sensor läuft und Höhe lässt sich über WebUI einstellen.

Habe auch das FHEM Modul an das von mir verwendete Register angepasst:

$HMConfig::culHmRegDefine{'altitude'}     = {a=>34.0,s=>2.0,l=>0,min=>0   ,max=>10000 ,c=>'',f=>'',u=>'m'  ,d=>0,t=>'Altitude for calculate air pressure at see level in meter.'};

@Wzut, kannst mal testen ob die Höhe damit auch von FHEM änderbar ist.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 März 2018, 08:56:33
Zitat von: Tom Major am 21 März 2018, 01:47:32
ok, habe den BME280 im Universalsensor integriert und die Höhe für die Luftdruckberechnung (NN) konfigurierbar gemacht.
Sensor läuft und Höhe lässt sich über WebUI einstellen.

Könntest Du das bitte als Sensor-Klasse für die Lib zur Verfügung stellen ? Den BMP180 gibt es ja schon. Gegebenenfalls müsste man die API für die Berechnung mit der eigenen Höhe noch anpassen.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 21 März 2018, 10:04:51
Zitat von: Tom Major am 21 März 2018, 01:47:32
@Wzut, kannst mal testen ob die Höhe damit auch von FHEM änderbar ist.
Ja kann ich heute Abend machen, allerdings ist das IMHO für FHEM nicht so wichtig. Der bestehende Unisensor geht den Weg über das globale Attribut altitude um NN als Reading zur Verfügung zu stellen. D.h. die Berechnung findet auf FHEM Seite statt und nicht im Sensor.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 21 März 2018, 11:50:40
Zitat von: papa am 21 März 2018, 08:56:33
Könntest Du das bitte als Sensor-Klasse für die Lib zur Verfügung stellen ? Den BMP180 gibt es ja schon. Gegebenenfalls müsste man die API für die Berechnung mit der eigenen Höhe noch anpassen.
Ja gerne, wir müssten aber die Details der Einbindung abstimmen, am Besten per PM. Ich habe in meinem Universalsensor die 2 bisher verwendeten Sensoren über eigene Header files gemacht, da ich dafür volle Kontrolle außerhalb der Lib wollte.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 21 März 2018, 11:55:11
Zitat von: Wzut am 21 März 2018, 10:04:51
Ja kann ich heute Abend machen, allerdings ist das IMHO für FHEM nicht so wichtig. Der bestehende Unisensor geht den Weg über das globale Attribut altitude um NN als Reading zur Verfügung zu stellen. D.h. die Berechnung findet auf FHEM Seite statt und nicht im Sensor.
Ja, ich habe es im FHEM Modul gesehen dass die NN Berechnung dort gemacht wird. Da die ausgewählte BME280 Lib aber NN Berechnung unterstützt habe ich es mal im Sensor mit vorgehalten, für nativen HM/RaspberryMatic Einsatz ist es schöner, bei Bedarf gleich den NN Luftdruck im Wetterkanal zu haben, dann braucht mon dort keinen script. Kann ja jeder im sketch selbst entscheiden welcher Luftdruck gesendet werden soll.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 22 März 2018, 16:25:33
Irre, der Thread ist jetzt schon 52 Seiten lang seit meinem ersten Reply.

Frage

HM-LC-SWX-SM & AES: ich hoffe / vermute wie ich gelesen habe, lediglich die Zeilen

#define USE_AES
#define HM_DEF_KEY 0xab,0xcd,0xef,0x00,0x01,0x02(usw...)
#define HM_DEF_KEY_INDEX 0


einzufügen und anzupassen, indem ich den Key vom VCCU / CUL in Hex form für HM_DEF_KEY eingebe und dann paire korrekt? Aktuell (ohne die Definiton) finde ich die zugehörigen Register nicht.

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 März 2018, 19:36:42
Wenn Du den HM Standardkey nimmst, kann HM_DEF_KEY_INDEX bei 0 bleiben. Wenn Du Deinen Key aus der VCCU einsetzt, musst Du auch den richtigen Index mit setzen.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 23 März 2018, 19:10:08
Ein kleiner Wunsch von mir, auch wirklich nur ein Wunsch, keine Aufforderung:
Ich würde mich riesig freuen wenn sich jemand erbarmen würde, das Ganze mal grob kurz zusammen zu fassen.
Es muss auch nicht Papa sein, der hat sicher genug um die Ohren, gibt wohl auch einige andere hier die sehr gut durchblicken

Ich würde gerne in das Thema Selbstbau von Homematic-Sensoren / Aktoren einsteigen.
Ziel des Ganzen wäre, die noch paar verbliebenen MySensors-Teile endgültig zu verbannen, da ständig Ärger damit

Flashen usw weiter traue ich mir grundsätzlich zu, löten usw alles kein Problem,
nur die Beispiele in Github verstehe ich zu wenig, die Bezeichnungen sagen mir nichts, sind wohl an Original-Homematic angelehnt.

Wäre interessiert an folgenden Teilen:
- Sensor mit DHT22 / DS18B20 o.ä. und Trigger für Taster oder Bewegungsmelder
- Sensor für mehrere Taster / Bewegungsmelder
- Sensor / Aktor zum ansteuern von 1-8 Relais, zusätzlich 1-8 direkte Tastereingänge, die die Ausgänge sofort schalten und auch direkt peerbar sind, also sofort schalten/ senden

Ob die Eingänge nachher open, tilted, on usw melden wäre mir egal bzw ich denke es wäre ein einfaches das dann zu ändern?
AES brauche ich erst mal nicht

Also, falls sich jemand erbarmen mag?
Viele Grüße

Klaus


Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 23 März 2018, 19:54:24
Hallo Klaus,
mir ging es vor ein paar Wochen relativ ähnlich als ich zum ersten Mal die AskSin++ Library entdeckt habe und die Fülle von Infos (und die spärliche Doku - keinesfalls als Vorwurf gemeint, in der Lib steckt auch ohne Doku wahnsinnig viel Arbeit und Know-How wie ich bei der Beschäftigung damit nach und nach erkannt habe und was frei verfügbar gemacht wurde - grosser Respekt vor dieser Leistung  :) ).

Ich habe mich dann einfach mit 2 konkreten Projekten befasst, die ich bei mir als erstes brauche und versucht diese zu verstehen, nachzubauen und den Code entsprechend anzupassen. Das sind bei mir ein Universalsensor und ein Wassermelder.
Ich versuche bei diesen Projekten im Code zu dokumentieren was nicht klar ist und wozu es auf den ersten Blick kaum Infos zu geben scheint, besonders beim Universalsensor habe ich einiges gelernt.
Kannst ja mal reinschauen, vielleicht hilft es etwas weiter. Beide Projekte sind als Prototypen aufgebaut und funktionieren einwandfrei an RaspberryMatic. Projekte sind noch nicht abgeschlossen, es werde noch weitere Infos, Schaltpläne usw. kommen:
https://github.com/TomMajor/AskSinPP_Examples (https://github.com/TomMajor/AskSinPP_Examples)

Ich würde an Deiner Stelle z.B. mit Wassermelder HM-SEC-WDS, Temperatur-/Luftfeuchtesensor HM-WDS10-TH-O oder 1-Kanal Handsender HM-RC-P1 anfangen, dass sind aus meiner Sicht alles relativ einfache Devices für den Einstieg.

Hier gibt es eine gute Doku von jp112sdl zum Nachbau des Handsenders:
https://github.com/jp112sdl/Beispiel_AskSinPP
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 23 März 2018, 20:02:24
Zitat von: papa am 22 März 2018, 19:36:42
Wenn Du den HM Standardkey nimmst, kann HM_DEF_KEY_INDEX bei 0 bleiben. Wenn Du Deinen Key aus der VCCU einsetzt, musst Du auch den richtigen Index mit setzen.


Danke, habe ich gemacht. Das Pairing klappt. Allerdings fehlt mir das Register "expectAES". get regList auf einem der Aktoren liefert

list:         register | range              | peer     | description
   1: powerUpAction    |     literal        |          | on: simulate short press of peer self01 (self02 if dual buttons) after power up options:off,on
   1: sign             |     literal        |          | signature (AES) options:off,on
   1: statusInfoMinDly |   0 to 15.5s       |          | status message min delay special:unused
   1: statusInfoRandom |   0 to 7s          |          | status message random delay
   1: transmitTryMax   |   1 to 10          |          | max message re-transmit
   3: lgActionType     |     literal        |          |  options:off,toggleToCntInv,jmpToTarget,toggleToCnt
   3: lgCtDlyOff       |     literal        |          | Jmp on condition from delayOff options:geHi,between,ltLo,ltHi,outside,geLo
   3: lgCtDlyOn        |     literal        |          | Jmp on condition from delayOn options:outside,geLo,geHi,ltLo,ltHi,between
   3: lgCtOff          |     literal        |          | Jmp on condition from off options:outside,geLo,between,ltLo,ltHi,geHi
   3: lgCtOn           |     literal        |          | Jmp on condition from on options:geHi,between,ltHi,ltLo,outside,geLo
   3: lgCtValHi        |   0 to 255         |          | Condition value high for CT table
   3: lgCtValLo        |   0 to 255         |          | Condition value low for CT table
   3: lgMultiExec      |     literal        |          | execution per repeat message options:on,off
   3: lgOffDly         |   0 to 111600s     |          | off delay
   3: lgOffTime        |   0 to 111600s     |          | off time special:unused
   3: lgOffTimeMode    |     literal        |          | off time meant absolut or at least options:minimal,absolut
   3: lgOnDly          |   0 to 111600s     |          | on delay
   3: lgOnTime         |   0 to 111600s     |          | on time special:unused
   3: lgOnTimeMode     |     literal        |          | on time meant absolut or at least options:minimal,absolut
   3: lgSwJtDlyOff     |     literal        |          | Jump from delayOff options:off,dlyOff,no,on,dlyOn
   3: lgSwJtDlyOn      |     literal        |          | Jump from delayOn options:off,dlyOff,no,on,dlyOn
   3: lgSwJtOff        |     literal        |          | Jump from off options:dlyOff,off,dlyOn,on,no
   3: lgSwJtOn         |     literal        |          | Jump from on options:no,on,dlyOn,off,dlyOff
   3: shActionType     |     literal        |          |  options:off,toggleToCntInv,jmpToTarget,toggleToCnt
   3: shCtDlyOff       |     literal        |          | Jmp on condition from delayOff options:geHi,between,ltLo,ltHi,outside,geLo
   3: shCtDlyOn        |     literal        |          | Jmp on condition from delayOn options:outside,geLo,geHi,ltLo,ltHi,between
   3: shCtOff          |     literal        |          | Jmp on condition from off options:outside,geLo,between,ltLo,ltHi,geHi
   3: shCtOn           |     literal        |          | Jmp on condition from on options:geHi,between,ltHi,ltLo,outside,geLo
   3: shCtValHi        |   0 to 255         |          | Condition value high for CT table
   3: shCtValLo        |   0 to 255         |          | Condition value low for CT table
   3: shMultiExec      |     literal        |          | reg unused, placeholder only options:off,on
   3: shOffDly         |   0 to 111600s     |          | off delay
   3: shOffTime        |   0 to 111600s     |          | off time special:unused
   3: shOffTimeMode    |     literal        |          | off time meant absolut or at least options:minimal,absolut
   3: shOnDly          |   0 to 111600s     |          | on delay
   3: shOnTime         |   0 to 111600s     |          | on time special:unused
   3: shOnTimeMode     |     literal        |          | on time meant absolut or at least options:minimal,absolut
   3: shSwJtDlyOff     |     literal        |          | Jump from delayOff options:off,dlyOff,no,on,dlyOn
   3: shSwJtDlyOn      |     literal        |          | Jump from delayOn options:off,dlyOff,no,on,dlyOn
   3: shSwJtOff        |     literal        |          | Jump from off options:dlyOff,off,dlyOn,on,no
   3: shSwJtOn         |     literal        |          | Jump from on options:no,on,dlyOn,off,dlyOff



expectAES scheint zu fehlen. Muss ich das Register in HM-LC-SWX-SM.ino noch definieren?

Nachtrag: der Eventlog von FHEM zeigt

2018-03-23 20:28:05 CUL_HM HM_668155 CMDs_pending
2018-03-23 20:28:05 CUL_HM HM_668155_Sw_01 set_on
2018-03-23 20:28:05 CUL_HM HM_668155 aesKeyNbr: 02
2018-03-23 20:28:06 CUL_HM HM_668155 aesCommToDev: ok
2018-03-23 20:28:06 CUL_HM HM_668155 CMDs_done
2018-03-23 20:28:06 CUL_HM HM_668155_Sw_01 deviceMsg: on (to VCCU)
2018-03-23 20:28:06 CUL_HM HM_668155_Sw_01 level: 100
2018-03-23 20:28:06 CUL_HM HM_668155_Sw_01 pct: 100
2018-03-23 20:28:06 CUL_HM HM_668155_Sw_01 on
2018-03-23 20:28:06 CUL_HM HM_668155_Sw_01 timedOn: off
2018-03-23 20:28:28 PRESENCE Marc absent
2018-03-23 20:28:28 PRESENCE Marc presence: absent
2018-03-23 20:28:41 CUL_HM HM_668155 CMDs_pending
2018-03-23 20:28:41 CUL_HM HM_668155_Sw_02 set_on
2018-03-23 20:28:41 CUL_HM HM_668155 CMDs_done
2018-03-23 20:28:42 CUL_HM HM_668155_Sw_02 deviceMsg: on (to VCCU)
2018-03-23 20:28:42 CUL_HM HM_668155_Sw_02 level: 100
2018-03-23 20:28:42 CUL_HM HM_668155_Sw_02 pct: 100
2018-03-23 20:28:42 CUL_HM HM_668155_Sw_02 on
2018-03-23 20:28:42 CUL_HM HM_668155_Sw_02 timedOn: off
2018-03-23 20:28:42 CUL_HM HM_668155 CMDs_pending
2018-03-23 20:28:42 CUL_HM HM_668155_Sw_02 set_off
2018-03-23 20:28:43 CUL_HM HM_668155 CMDs_done
2018-03-23 20:28:43 CUL_HM HM_668155_Sw_02 deviceMsg: off (to VCCU)
2018-03-23 20:28:43 CUL_HM HM_668155_Sw_02 level: 0
2018-03-23 20:28:43 CUL_HM HM_668155_Sw_02 pct: 0
2018-03-23 20:28:43 CUL_HM HM_668155_Sw_02 off
2018-03-23 20:28:43 CUL_HM HM_668155_Sw_02 timedOn: off
2018-03-23 20:28:43 PRESENCE Ramona absent
2018-03-23 20:28:43 PRESENCE Ramona presence: absent
2018-03-23 20:28:45 CUL_HM HM_668155 CMDs_pending
2018-03-23 20:28:45 CUL_HM HM_668155_Sw_01 set_off
2018-03-23 20:28:45 CUL_HM HM_668155 aesKeyNbr: 02
2018-03-23 20:28:45 CUL_HM HM_668155 aesCommToDev: ok
2018-03-23 20:28:45 CUL_HM HM_668155 CMDs_done
2018-03-23 20:28:45 CUL_HM HM_668155_Sw_01 deviceMsg: off (to VCCU)
2018-03-23 20:28:45 CUL_HM HM_668155_Sw_01 level: 0
2018-03-23 20:28:45 CUL_HM HM_668155_Sw_01 pct: 0
2018-03-23 20:28:45 CUL_HM HM_668155_Sw_01 off
2018-03-23 20:28:45 CUL_HM HM_668155_Sw_01 timedOn: off



Danke & Gruss Marc



Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: papa am 23 März 2018, 21:34:31
expectAES ist doch nur auf der Senderseite z.B. Fernbedienung. Damit wird dem Sender mitgeteilt, dass der Empfänger z.B. Switch eine AES-Signature nachfragen wird.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 24 März 2018, 06:44:16
Danke, das wusste ich nicht. Damit funktioniert es jetzt. Danke nochmals. Marc
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 30 März 2018, 18:45:11
Hallo,

Ich habe mir HM-WDS10-TH-O geschnappt und für meinen BMP180 umgeschrieben. Pairing hat geklappt, das fhem log sagt aber noch


2018.03.30 18:35:47 4: CUL_Parse: CUL_1 A 0C 39 A070 345678 280790 00D5CF50 -34
2018.03.30 18:35:47 1: Error dewpoint: humidity invalid: 207


Anscheinend erwartet er humidity, ich habe aber nur pressure. Einige Stunden probieren haben nichts geholfen, irgendwas mache ich falsch.



//- -----------------------------------------------------------------------------------------------------------------------
// 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 EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Register.h>
#include <MultiChannelDevice.h>
#include <OneWire.h>
//#include <sensors/Ds18b20.h>
//#include <sensors/Tsl2561.h>
//#include <sensors/Bh1750.h>
#include <sensors/Bmp180.h>
//#include <sensors/Sht10.h>
//#include <sensors/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

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

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x34,0x56,0x78},       // Device ID
    "papa111111",           // Device Serial
    {0x00,0x3d},            // Device Model
    0x10,                   // Firmware Version
    as::DeviceType::THSensor, // Device Type
    {0x01,0x00}             // Info Bytes
};

/**
* 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,int16_t temp,uint8_t pressure, 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] = pressure;
  }
};

DEFREGISTER(WeatherRegsList0,MASTERID_REGS,DREG_BURSTRX)
typedef RegList0<WeatherRegsList0> WeatherList0;


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

  uint16_t        millis;
//  Dht<6,DHT11>      dht11;
//  Sht10<A4,A5>    sht10;
  Bmp180          bmp180;
//  Tsl2561<>       tsl2561;
//  Bh1750<>          bh1750;
//  Ds18b20         ds18b20;
  OneWire         ow;

public:
  WeatherChannel () : Channel(), Alarm(5), millis(0), ow(6) {}
  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();
      WeatherEventMsg& msg = (WeatherEventMsg&)device().message();
//      msg.init(msgcnt,dht11.temperature(),dht11.humidity(),device().battery().low());
      msg.init(msgcnt,bmp180.temperature(),bmp180.pressure(),device().battery().low());
//      msg.init(msgcnt,0,0,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 / 10; // seconds to wait
      millis = nextsend % 1000; // millis to wait
      rtc.add(*this);
    }
  }

  // here we do the measurement
  void measure () {
    DPRINTLN("Measure...  ");
//    dht11.measure();
//    DPRINT("T: ");DDEC(dht11.temperature());DPRINT("  H: ");DDECLN(dht11.humidity());
//    sht10.measure();
//    DPRINT("T: ");DDEC(sht10.temperature());DPRINT("  H: ");DDECLN(sht10.humidity());
    bmp180.measure();
    DPRINT("T: ");DDEC(bmp180.temperature());DPRINT("  P: ");DDECLN(bmp180.pressure());
//    tsl2561.measure();
//    DPRINT("H: ");DDECLN(tsl2561.brightness());
//    bh1750.measure();
//    DPRINT("H: ");DDECLN(bh1750.brightness());
//    ds18b20.measure();
//    DPRINT("T: ");DDECLN(ds18b20.temperature());
  }

  // 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,WeatherList0>* dev,uint8_t number,uint16_t addr) {
    Channel::setup(dev,number,addr);
    tick = 5;
    rtc.add(*this);
//    dht11.init();
//    sht10.init();
    bmp180.init();
//    tsl2561.init();
//    bh1750.init();
//    Ds18b20::init(ow, &ds18b20, 1);
  }

  uint8_t status () const {
    return 0;
  }

  uint8_t flags () const {
    return 0;
  }

};


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

ConfigButton<WeatherType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<SleepRTC>(hal);
  }
}


Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 30 März 2018, 18:57:58
Zitat von: MBHG am 30 März 2018, 18:45:11

Anscheinend erwartet er humidity, ich habe aber nur pressure. Einige Stunden probieren haben nichts geholfen, irgendwas mache ich falsch.

Du sendest die humidity gar nicht mit wenn ich das richtig sehe. humidity muss in die payload rein, siehe z.B.
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino (https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino)

pload[2] = humidity;

und ggf. das FHEM Modul anpassen das dort humidity auch am richtigen Platz auftaucht.
Titel: Antw:AskSin++ Library
Beitrag von: LuBeDa am 01 April 2018, 14:01:05
Hallo zusammen,
mittlerweile ist der Eselskarren aus China mit meinen Modulen angekommen. Daher beschäfftige ich mich wieder mehr mit der AskSinPP Library.

Die hardwareseite verstehe ich jetzt einigermassen, was mir noch Probleme bereitet ist die FHEM-Seite.
Speziell die Herausforderung pro Homebrew-Sensor ein eigenes Modul zu entwickeln.

Könnte man nicht CUL_HM so erweitern das dort das Handshake und AES Geschäft abgewickelt wird, nur die Sensordaten von einem anderen Paket bearbeitet werden? Ich stelle mir das so vor. das ein Modul CUL_HB_SENSOR nur das Paket mit den Sensordaten erhält und anhand der HMID des Sensors und der "Bitbeschreibung" 7.1-7.5 => Humidity in % die Readings des Gerätes aktualisiert.


define MeinHumSensor CUL_HB_SENSOR hmId 7.1-7.5 Humidity


Aktoren wären damit schwierig aber für Sensoren scheint mit das ein gangbarer Weg.

Wie seht ihr das?

Wie kann man aus CUL_HM das Sensordatenpaket abgreifen?

Ludger

Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 01 April 2018, 18:55:08
Zitat von: Tom Major am 30 März 2018, 18:57:58
Du sendest die humidity gar nicht mit wenn ich das richtig sehe. humidity muss in die payload rein, siehe z.B.
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino (https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino)

pload[2] = humidity;

und ggf. das FHEM Modul anpassen das dort humidity auch am richtigen Platz auftaucht.


Danke. Habe die airPressure in den Payload eingebaut. Pairt auch mit der VCCU. Funktioniert fast. Anstatt einer Airpressure von 987 kommt 56417 an.  Erst kam einzu geringer Wert, dann hatte ich festgestellt, dass die Differenz genau 0x300 (in hex) war, d.h. es fehlte wohl genau ein byte. Also die Message Length verlängert. Jetzt kommt ein irrwitziger Wert. Muss mal noch überlegen, was es sein könnte.


class WeatherEventMsg : public Message {
public:
  void init(uint8_t msgcnt,int16_t temp,uint8_t airPressure, 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,BIDI,t1,t2);

    pload[0] = ((airPressure) >> 8) & 0x7f;
    pload[1] = (airPressure) & 0xff;
  }
};


Gruss
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 01 April 2018, 19:02:15
Was ich spontan sehe, Du darfst den airPressure nicht mit 7F sondern musst mit FF verunden. Die 7F sind bei der Temperatur richtig da dort dass low Batt Bit sitzt, aber nicht beim airPressure.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 01 April 2018, 19:05:23
Ausserdem: airPressure kommt bei Dir mir uint8_t in die Funktion rein, aber du verwendest es dort als 16bit Wert für 2 Byte payload. So wird das nichts.  ;)
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 01 April 2018, 19:22:51
ok, jetzt weiss ich wo die falsche Maske 7F beim airPressure herkam, von mir  ???
Habe es gerade im Repo gefixt.
Der Bug hat keine Auswirkungen da aufgrund des Wertebereiches des Luftdrucks hier auf dem Planeten dort nie ein Wert stehen sollte der Bit15 tatsächlich auf 1 setzt.

Der falsche Wert kommt dann sicherlich durch den uint8_t wie oben geschrieben.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 01 April 2018, 21:00:02
Hi,

danke. Klappt jetzt. Falsch war neben dem int8 das fehlen eines Wertes für Humdity. Klappt alles, danke!

Marc



class WeatherEventMsg : public Message {
public:
  void init(uint8_t msgcnt,int16_t temp,uint16_t airPressure, 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,BIDI,t1,t2);

    pload[0] = 0;   //zero for humidity
    pload[1] = ((airPressure) >> 8) & 0xff;
    pload[2] = (airPressure) & 0xff;
  }
};
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 April 2018, 15:37:55
Zitat von: LuBeDa am 01 April 2018, 14:01:05
Hallo zusammen,
mittlerweile ist der Eselskarren aus China mit meinen Modulen angekommen. Daher beschäfftige ich mich wieder mehr mit der AskSinPP Library.

Die hardwareseite verstehe ich jetzt einigermassen, was mir noch Probleme bereitet ist die FHEM-Seite.
Speziell die Herausforderung pro Homebrew-Sensor ein eigenes Modul zu entwickeln.

Könnte man nicht CUL_HM so erweitern das dort das Handshake und AES Geschäft abgewickelt wird, nur die Sensordaten von einem anderen Paket bearbeitet werden? Ich stelle mir das so vor. das ein Modul CUL_HB_SENSOR nur das Paket mit den Sensordaten erhält und anhand der HMID des Sensors und der "Bitbeschreibung" 7.1-7.5 => Humidity in % die Readings des Gerätes aktualisiert.


define MeinHumSensor CUL_HB_SENSOR hmId 7.1-7.5 Humidity


Aktoren wären damit schwierig aber für Sensoren scheint mit das ein gangbarer Weg.

Wie seht ihr das?

Wie kann man aus CUL_HM das Sensordatenpaket abgreifen?

Ludger

Ich hatte hier - oder in dem Hardwarebeitrag schon mal nen generischen Sensor vorgeschlagen. Dieser würde eine Sensormessage (Typ = 0x53) senden. Der Empfangscode auf der FHEM-Seite, würde die Nachricht auf Grund eines Attributes auswerten und in entsprechende Readings zerlegen.

Mal kurz suchen ...... hier (https://forum.fhem.de/index.php/topic,57486.msg777739.html#msg777739)
Titel: Antw:AskSin++ Library
Beitrag von: LuBeDa am 03 April 2018, 21:37:06
Hallo zusammen,
ich habe noch Probleme mit dem Debugging. Ich nutze einen Pro Mini 8MHz und einen FTDI Adapter den ich einfach nur in die Bohrlöcher des Arduinos stecke (War glaube ich ein Trick von Jerome).

Das Programmieren klappt auch damit aber ich bekomme keine Debugginginfos über die serielle Konsole.

#define NDEBUG ist nicht gesetzt und das sollte auch stimmen:

void setup() {
DINIT(57600, "Hallo");
...
}


Pairing etc funktionieren.

Habe noch Probleme mit meinem BME280 Sensor und ohne Debbuging ist die Fehlersuche schwierig.

Was könnte ich sonst noch falsch gemacht haben?

Ludger

Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 03 April 2018, 22:10:08
Zitat von: LuBeDa am 03 April 2018, 21:37:06
Das Programmieren klappt auch damit aber ich bekomme keine Debugginginfos über die serielle Konsole.

Du hast auch 57600 Baud eingestellt?
Kommt gar nicht oder Zeichenmüll?
Wenn Zeichenmüll kommt - stell mal auf 115200. Kommt dann was sinnvolles?
Titel: Antw:AskSin++ Library
Beitrag von: LuBeDa am 07 April 2018, 08:36:56
Frage zu "Register.h"

Hallo zusammen,
ursprünglich habe ich Probleme mit dem seriellen Debbuging. Um dem Problem auf die Spur zukommen habe ich eine
neue Hardware Arduino Pro Mini und einen neuen CC1101 genommen und wollte nun das Differenzthermometer https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples/HM-WDS30-OT2 von Jerome nachbauen.

Das ganze natürlich in einer sauberen Softwareumgebung.

Also habe ich die "HM-WDS30-OT2.ino" heruntergeladen und die ASK-Library V2 von pa-pa. Beim kompilieren bleiben zwei Fehler:

fatal error: Register.h:
fatal error: sensors/Ds18b20.h

Die Ds18b20.h kann ich aus dem Master von pa-pa nehmen, das ist glaube ich unkritisch aber kann ich auch die Register.h daher nehmen?

Irgendwo in dem Thread stand etwas in der Art "Man mehme die XML-Gerätebeschreibung von EQ3 und erzeuge sich die passende Register.h"

Da schwirren viele Fragezeichen in meinem Kopfs herum!?!?!

Ludger
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 April 2018, 08:44:05
Um mit einem konsistenten Stand zu arbeiten, nimm alles aus dem master-Branch.
Sonst müsstest du alle in allen referenzierten  Libs diffen, um nur das nötigste für dein Projekte nachzuziehen.


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: LuBeDa am 07 April 2018, 17:21:02
So, jetzt läuft es bei mir soweit.

Mein Problem mit dem seriellen Debugging lag an PlattformIO, scheinbar kommt er mit COM12 unter Windows nicht klar.  Der
WDS30-OT2 sketch von @jp112sdl mit dem Master-Branch der Library läuft perfekt.

Jetzt wird erstmal gegrillt und dann sehen wir weiter. ;D

Danke für die Library und den Support hier im Forum.

Ludger
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 08 April 2018, 01:49:43
Hallo papa,
ich baue gerade einen Wassermelder mit MAX1724 auf und frage mich eben ob Deine BatterySensor class eine Spannungsmessung z.B. einer Zelle von 1,5V oder 1,2V gegen Bandgap berücksichtigen kann?
Du hast zwar die BatterySensorUni, bei der man mit Spannungsteiler eine andere Spannung als den Default case (Bandgap gegen Vcc) messen kann, aber irgendwie vermisse ich dort die Umschaltung der Ref.Spannung auf Bandgap.
Wenn ich z.B. meinen 1,2V Akku mit Spannungsteiler 1:2 teile dann möchte ich die gegen die Bandgap messen und nicht gegen die Vcc vom MAX1724. Habe ich da was übersehen oder geht das zur Zeit wirklich nicht? Mache gern einen pull-request dafür..
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 08 April 2018, 12:50:55
Hallo papa,

Hmm, ich entdecke gerade im Beispiel HM-SEC-RHS (das einzige was BatterySensorUni verwendet) die Verwendung einer eigene Klasse BatSensor abgeleitet von BatterySensorUni. Das würde für meine Frage oben helfen, ich könnte in der abgeleiteten Klasse selbst die Ref.Spannung auf Bandgap umschalten und dann messen. Damit hätte sich meine Frage oben erledigt.

Daraus ergibt sich meine nächste Frage im Zusammenhang mit der Batteriemessung, ich verwende die eigene Klasse ADCThreeStateChannel für einen "ADCPosition" Sensor, ADCThreeStateChannel ist von ThreeStateGenericChannel abgeleitet.

class ADCThreeStateChannel : public ThreeStateGenericChannel<ADCPosition,HALTYPE,List0Type,List1Type,List4Type,PEERCOUNT> {


Ich möchte gern in ThreeStateGenericChannel die Batteriemessung direkt nach dem Senden machen, um ein realistischeres Bild des Ladezustands der Batterie zu bekommen - und keine "selbstständige" zyklische Batteriemessung mehr haben. So was in der Art:

ThreeState.h
class ThreeStateGenericChannel : public Channel<HALTYPE,List1Type,EmptyList,List4Type,PEERCOUNT,List0Type>, public Alarm {

  class EventSender : public Alarm {
  public:
    ThreeStateGenericChannel& channel;
    uint8_t count, state;

    EventSender (ThreeStateGenericChannel& c) : Alarm(0), channel(c), count(0), state(255) {}
    virtual ~EventSender () {}
    virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
      SensorEventMsg& msg = (SensorEventMsg&)channel.device().message();
      msg.init(channel.device().nextcount(),channel.number(),count++,state,channel.device().battery().low());
      channel.device().sendPeerEvent(msg,channel);
***   channel.device().battery().voltage(); ***
    }
  };


Meine Ergänzung mit *** gekennzeichnet. Siehst Du einen Weg diese Funktionalität zu bekommen ohne den Library source code (ThreeState.h) zu patchen?
Eigene patches in der Lib sind bei updates immer schlecht bzw. man vergisst leicht das man mal früher gepatcht hatte..

Danke,

Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 April 2018, 17:16:52
Es gibt mehrere Batteriesensor-Klassen. Einfach mal in Battery.h nachsehen. Dort steht auch die Beschreibung, wie sie funktionieren. Wenn das alles nicht passt, können wir auch noch weitere hinzufügen.

Schau Dir mal das RC-4 Beispiel an, da wird Hal::sendPeer() überladen, um nach 50 Nchrichten den aktuellen Batteriestand zu ermittel. Wenn Du nach jeder Nachricht messen willst, kannst Du das da auch einfach einfügen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 09 April 2018, 01:45:30
ZitatEs gibt mehrere Batteriesensor-Klassen. Einfach mal in Battery.h nachsehen. Dort steht auch die Beschreibung, wie sie funktionieren. Wenn das alles nicht passt, können wir auch noch weitere hinzufügen.
Schau Dir mal das RC-4 Beispiel an, da wird Hal::sendPeer() überladen, um nach 50 Nchrichten den aktuellen Batteriestand zu ermittel. Wenn Du nach jeder Nachricht messen willst, kannst Du das da auch einfach einfügen.

Hal::sendPeer() ist genial, quasi die Möglichkeit eines callbacks direkt nach dem Senden, genau das was ich gesucht hatte.
Vielen Dank für die Info und die Voraussicht beim SW-Design 8).

Wegen der Batteriesensor Klasse überlege ich noch mal wie es für die Applikation am Besten wäre und melde mich noch mal bei Bedarf.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 09 April 2018, 19:12:21
Zitat von: Wzut am 18 März 2018, 18:50:36
11,12,& 13 kannst du nicht ändern , siehe Datenblatt des ATMega328. Einzig CS auf Pin 10 kannst du bedenklos umlegen.
D.h. die interne LED auf Pin 13 ist für dich verloren/wertlos , da hatten die Arduino Designer kein glückliches Händchen :)
Hallo pa-pa,
läuft die Lib auch auf einem 328pb? Dieser hat den Vorteil, dass er eine 2. HW Serial hat und man damit auch Sensoren koppeln könnte, die per Uart kommunizieren. Ich denke da an einen FS20WUE von ELV, um eine Brücke zu alten Wettersensoren schlagen zu können oder auch einen Fingerprintsensor.
Mit SW Serial kann man nicht arbeiten, da die sich mit EnableInterrupt nicht verträgt.

Beim 328pb liegt aber auf den Pins 10-13 gerade diese zusätzliche serielle Schnittstelle. Zusätzlich hat der 328pb aber auch auf den Pins 14,15, 20&21 nochmal Miso1, Mosi1, SCK1 und SS1. Könnten diese für die Lib genutzt werden?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 April 2018, 09:02:52
Zitat von: Gruenebe am 09 April 2018, 19:12:21
Hallo pa-pa,
läuft die Lib auch auf einem 328pb? Dieser hat den Vorteil, dass er eine 2. HW Serial hat und man damit auch Sensoren koppeln könnte, die per Uart kommunizieren. Ich denke da an einen FS20WUE von ELV, um eine Brücke zu alten Wettersensoren schlagen zu können oder auch einen Fingerprintsensor.
Mit SW Serial kann man nicht arbeiten, da die sich mit EnableInterrupt nicht verträgt.

Beim 328pb liegt aber auf den Pins 10-13 gerade diese zusätzliche serielle Schnittstelle. Zusätzlich hat der 328pb aber auch auf den Pins 14,15, 20&21 nochmal Miso1, Mosi1, SCK1 und SS1. Könnten diese für die Lib genutzt werden?

Das wird sicherlich irgendwie gehen, wenn es entsprechende Packages für die Arduino Umgebung gibt. Wenn es nur um die serielle Schnittstelle geht, kannst Du auch einfach NDEBUG definieren. Es gibt dann keine Ausgaben mehr und die serielle Schnittstelle kann für andere Sachen verwendet werden.
Als schnelle alternative geht auch ein STM32F1 - wie z.B. das Maple Mini Board (http://wiki.stm32duino.com/index.php?title=Maple_Mini). Das hat 4 serielle Schnittstellen und mehr Speicher. Beispiele für dem STM32 gibt es bereits.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 10 April 2018, 10:18:28
Was meinst Du mit Packages?

Ich teste gerade mit einem A-Star 328PB Micro 3,3V 8Mhz, für den es auch eine Arduino IDE Boardbeschreibung gibt.

https://a.pololu-files.com/picture/0J8487.1200.jpg?f96c03fe3147f6a518b4a3cc08596866

Meine FS20WUE Abfrage inkl. EnableInterrupt alleine läuft damit.

Nun wollte ich ein Asksin++ Beispiel testen und den CC1101 mit    typedef AvrSPI<20, 21, 14, 15> SPIType;       statt an 10,11,12,13 hängen.

In der Konsole erscheint dann aber
AskSin++ V2.1.4 ...
Adress Space: 32 - 78
CC initl
Error at 00 expected: 2E read:FF
usw

Müssen die Ports für den CC1101 noch an anderer Stelle geändert werden?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 10 April 2018, 10:28:04
Zitat von: Gruenebe am 10 April 2018, 10:18:28
Was meinst Du mit Packages?

Ich teste gerade mit einem A-Star 328PB Micro 3,3V 8Mhz, für den es auch eine Arduino IDE Boardbeschreibung gibt.

https://a.pololu-files.com/picture/0J8487.1200.jpg?f96c03fe3147f6a518b4a3cc08596866

Meine FS20WUE Abfrage inkl. EnableInterrupt alleine läuft damit.

Nun wollte ich ein Asksin++ Beispiel testen und den CC1101 mit    typedef AvrSPI<20, 21, 14, 15> SPIType;       statt an 10,11,12,13 hängen.

In der Konsole erscheint dann aber
AskSin++ V2.1.4 ...
Adress Space: 32 - 78
CC initl
Error at 00 expected: 2E read:FF
usw

Müssen die Ports für den CC1101 noch an anderer Stelle geändert werden?

Hast du den GD0 auch umgelegt? Der wird ja in den Sketchen an Pin 2 übergeben:
typedef AskSin<StatusLed<4>,NoBattery,Radio<RadioSPI,2> > Hal;
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 April 2018, 10:58:32
Zitat von: Gruenebe am 10 April 2018, 10:18:28
Müssen die Ports für den CC1101 noch an anderer Stelle geändert werden?

Die Ports nicht - aber hat die CPU auch das gleich Register ? Die Daten werden ja per Hardware übertragen und dazu in das SPSR Register geschrieben.
Du kannst aber auch einfach mal auf die Arduino-SPI-Library umschalten. Dazu SPI.h includen und dann das Radio wie folgt definieren (siehe auch RC-4 Example):

typedef LibSPI<10> SPIType;
typedef Radio<SPIType,2> RadioType;


Es wird hier nur der Chip-Select-Pin (10) und der Interrupt-Pin (2) benötigt.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 April 2018, 11:16:19
ZitatMüssen die Ports für den CC1101 noch an anderer Stelle geändert werden?

Für SPI1 Verwendung müssen m.E. mindestens in Radio.h die SPI register angepasst werden, auf SPSR1, SPCR1 usw.

Oder eine Portierung wie z.B.
https://github.com/watterott/ATmega328PB-Testing (https://github.com/watterott/ATmega328PB-Testing) verwenden und dann auf diese SPI lib im sketch umschalten.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 11 April 2018, 00:32:04
Übrigens geiles Teil, der Pololu A-Star 328PB.
Das Design und der Aufbau sehen ziemlich sauber aus, es gibt eine richtige und ausführliche Doku https://www.pololu.com/docs/0J74/all (https://www.pololu.com/docs/0J74/all)
4 Varianten bezüglich Spannungen und Frequenz,
Pololu hat bereits einige Sachen für Arduino portiert (aber nicht die SPI1),
und mir gefällt der extra ISP Header.
Habe mir gleich mal welche bestellt.

Und Microchip bzw. Atmel haben echte Verbesserungen im Chip reingebaut (außer den Flash und RAM zu vergrössern, das wäre noch nicer gewesen):
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 12 April 2018, 16:15:38
Es funktioniert.

Dazu habe ich die Radio.h an den entsprechenden Stellen wie folgt angepasst:

class AvrSPI {

public:
  uint8_t send (uint8_t data) {
#if defined ATmega328PB
SPDR1 = data;                  // send byte
while (!(SPSR1 & _BV(SPIF1)));  // wait until transfer finished
return SPDR1;
#else
SPDR = data;                  // send byte
while (!(SPSR & _BV(SPIF)));  // wait until transfer finished
return SPDR;
#endif
  }

  void waitMiso () {

und
    // SPI enable, master, speed = CLK/4
{
#if defined ATmega328PB
SPCR1 = _BV(SPE1) | _BV(MSTR1);
#else
SPCR = _BV(SPE) | _BV(MSTR);
#endif
}
    PINTYPE::setHigh(CS);
    // Set SCLK = 1 and SI = 0, to avoid potential problems with pin control mode


Damit kann durch Einfügen von

#define ATmega328PB

am Anfang des Scetches zwischen einem normalen 328P und einem 328PB  umgeschaltet werden.
Beim 328PB kann dann die zweite SPI statt mit typedef AvrSPI<10, 11, 12, 13> SPIType; mit typedef AvrSPI<20, 21, 14, 15> SPIType;
genutzt werden.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 April 2018, 19:20:49
Cool. Mal schaun, ob man das noch irgendwie über die Templateargumente umschaltbar machen kann.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 28 April 2018, 18:49:34
Zitat von: papa am 27 Februar 2018, 08:11:01
Wenn Du nun einen Qurz bestücken willst, müssen da noch die beiden Lastkondensatoren gegen Masse bestückt werden.
Ich habe zu diesem Thema die letzte Stunde einiges gelesen, aber so richtig schlau bin ich leider noch nicht.
Kommt der 32kHz Uhrenquarz an XTAL1 & XTAL2 und wie groß müssen die beiden Kondesnsatoren sein ?
Ich habe im Netz so einige Varianten gefunden, u.A. war der Quarz ohne Kondensatoren an zwei anderen Pins, da an XTAL1/2 ein anderer Quarz war.
Die verwendeten Kondensatoren in diversen Schaltungen gingen von 7pF bis 33pF  ... :(
Müssen die Fuse Bits angepasst werden wenn z.Z der interne 8Mhz Takt verwendet wird ?       
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 28 April 2018, 20:02:57
Zitat von: Wzut am 28 April 2018, 18:49:34
Ich habe zu diesem Thema die letzte Stunde einiges gelesen, aber so richtig schlau bin ich leider noch nicht.
Kommt der 32kHz Uhrenquarz an XTAL1 & XTAL2 und wie groß müssen die beiden Kondesnsatoren sein ?
Ich habe im Netz so einige Varianten gefunden, u.A. war der Quarz ohne Kondensatoren an zwei anderen Pins, da an XTAL1/2 ein anderer Quarz war.
Die verwendeten Kondensatoren in diversen Schaltungen gingen von 7pF bis 33pF  ... :(

Das hängt u.a. von der load capacitance des verwendeten 32 kHz Quarzes ab. Laut Atmel application note berechnen sich die nötigen C so:
Ce = 2Cl - Cs -Ci
e extern, l load, s stray, i intern

Sehr häufig findet man 32kHz Quarze mit 12,5 pF Cload, z.B. verwende ich diese
http://de.farnell.com/abracon/ab26t-32-768khz/crystal-32-768khz-12-5pf-cylinder/dp/2467704 (http://de.farnell.com/abracon/ab26t-32-768khz/crystal-32-768khz-12-5pf-cylinder/dp/2467704)
Damit würde man auf ca. 13pF Cextern kommen (25-6-6 = 13), Cstray hängt vom Layout ab und ist geschätzt.

Bei einem Quarz mit 6 pF Cload braucht man keine Cextern (12-6-6 = 0).
http://de.farnell.com/citizen-finetech-miyota/cfs206-32-768kdzb-ub/quarz-uhr-32-768khz-zylinder-6pf/dp/1457085 (http://de.farnell.com/citizen-finetech-miyota/cfs206-32-768kdzb-ub/quarz-uhr-32-768khz-zylinder-6pf/dp/1457085)

Sicher wird der AVR eine Fehlanpassung der C in gewissen Grenzen tolerieren und der OSC trotzdem schwingen..
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 29 April 2018, 00:48:14
sehe gerade dass noch 2 andere Fragen im Text waren,

ZitatIch habe im Netz so einige Varianten gefunden, u.A. war der Quarz ohne Kondensatoren an zwei anderen Pins, da an XTAL1/2 ein anderer Quarz war.
Müssen die Fuse Bits angepasst werden wenn z.Z der interne 8Mhz Takt verwendet wird ?   

Es gibt AVRs wo man noch einen Uhrenquarz als Timerquelle an die TOSC pins anschließen kann, und zwar unabhängig vom Hauptquarz. Das geht z.B. beim ATmega128.
Der ATmega328 hat zwar auch die TOSC pins, aber die liegen halt genau auf XTAL, so dass bei dem 2 Quarze parallel nicht gehen.

Wenn die Fuses z.B. auf 8MHz externer Quarz konfiguriert sind (bei einem gekauften Arduino Pro Mini für 3,3V z.B.) muss man diese natürlich ändern wenn man auf internen 8MHz RC OSC umsteigen will.

Hoffe das hilft,
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 29 April 2018, 08:22:29
@Tom Major , danke für die ausführliche Erklärung ! Ich denke jetzt habe ich es gerafft, vor allem das bei den Quarzen auch ein pF Wert vorhanden ist.
Ich hatte mir den 32kHz Quarz bei Pollin rausgesucht , auch dieser hat wie bei deinen von Farnell 12,5 pF https://www.pollin.de/p/quarz-32-768-khz-230138
Hintergrund : Ich habe mir gestern den HM-WDS10-TH-O Sketch vorgenommen und diesen mangels Quarz auf dein UNISENSOR Beispiel umgeschrieben.
Das Timing ist damit nicht supergenau, aber für meinen Anwendungsfall ( Öltank Füllstand Messung mit US-100 ca. einmal pro Stunde ) völlig ausreichend. 

Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 29 April 2018, 08:37:58
Zitat von: Wzut am 29 April 2018, 08:22:29
Ich habe mir gestern den HM-WDS10-TH-O Sketch vorgenommen und diesen mangels Quarz auf dein UNISENSOR Beispiel umgeschrieben.

Ich habe genau aus diesem Grund beim HM-WDS10-TH-O auch nur mit Suchen/Ersetzen aus "rtc" ein "sysclock" gemacht. :)

Tom und ich hatten vor kurzem das Thema "Gangungenauigkeit mittels ext. 8MHz Quarz" mal etwas genauer betrachtet.
Er hat einen kleinen Sketch geschrieben, um die Abweichung zu berechnen. Bei mir sind es ~12% Abweichung, so dass ich den sysclock-Timer einfach mit 0.88 multipliziere.
Ist zwar immer noch nicht auf die Hundertstel präzise, aber macht doch schon einen sehr deutlichen Unterschied.
Titel: Antw:AskSin++ Library
Beitrag von: Wzut am 29 April 2018, 08:50:20
ja die 12% kommen vermutlich auch bei mir mit 8Mhz extern hin, ich habe bei 3500 Sekunden Wartezeit ein Sendeintervall von 1:04 Stunden.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 April 2018, 09:14:27
Welchen PowerSave-Mode benutzt Du ? Idle oder Sleep ?
Bei Sleep kommt die Ungenauigkeit durch den Watchdog. Da wären 12% echt super.

@jp112sdl: Wenn rtc durch sysclock ersetzt wird, muss aber auch die Zeitangabe angepasst werden. Die rtc zählt grundsätzlich in Sekunden. Die sysclock steht per default auf 100 Ticks pro Sekunde.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 29 April 2018, 09:51:22
Zitat von: papa am 29 April 2018, 09:14:27
Welchen PowerSave-Mode benutzt Du ? Idle oder Sleep ?
Bei Sleep kommt die Ungenauigkeit durch den Watchdog. Da wären 12% echt super.
Den Sleep.
Aber lt. 328P-Datenblatt liegt die Toleranz beim int. 8MHz auch bei ~10%, wenn ich mich nicht irre.

Zitat von: papa am 29 April 2018, 09:14:27

@jp112sdl: Wenn rtc durch sysclock ersetzt wird, muss aber auch die Zeitangabe angepasst werden. Die rtc zählt grundsätzlich in Sekunden. Die sysclock steht per default auf 100 Ticks pro Sekunde.
Ja stimmt, das hatte ich damals auch gemacht.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 29 April 2018, 11:11:44
Zitat von: jp112sdl am 29 April 2018, 08:37:58
Tom und ich hatten vor kurzem das Thema "Gangungenauigkeit mittels ext. 8MHz Quarz" mal etwas genauer betrachtet.

zur Verdeutlichung: Gemeint ist Gangungenauigkeit wegen der Ungenauigkeit des int. RC Watchdog OSC 128kHz (der im sleep mode bei Einsatz eines ext. 8MHz Quarz zum Einsatz kommt - für die langen Zeitspannen im sleep ist dieser zuständig, nicht der 8MHz Quarz, sonst würde man nie auf den sleep Strom kommen).

Der sketch zum Ausmessen ist hier:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Other/WDT_Frequenz (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Other/WDT_Frequenz)
Wenn dort z.B. Faktor 0.916 rauskommt muss man statt
seconds2ticks(3600)
seconds2ticks(3298)
aufrufen um auf 1h zu kommen.
Für das Ausmessen muss ein ext. Quarz als Referenz angeschlossen sein, der int. 8MHz RC OSC geht nicht als Referenz da er selber ungenau ist.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 30 April 2018, 20:54:40
Hi Tom,

Zitat von: Tom Major am 07 März 2018, 01:17:43
Im verlinkten Arduino sketch werden als Demo dummy Werte generiert und an die CCU2 gesendet. Aufbauend auf dem sketch kann man die Messwerte beliebiger Sensoren selbst einbauen. Anpassen muss man nur den sketch selbst und für die Darstellung in der CCU2 die Datei hb_uni_sensor1.xml.
Vielleicht hilft es ja jemanden.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)

kurze Rückfrage wg. dem wiring: in Bild sind zwei Sensoren, ein Temperatursensor und ein Lichtsensor auf der Platine abgebracht. In der Schaltung sind diese jeweils optional an A4 / A5. Im Sketch sieht es so aus als ob man beide gleichzeitig betreiben kann, würde auch zum Bild passen. Wo schliesse ich denn den anderen Sensor an, wenn ich den ersten an A4 / A5 anschliesse?

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 30 April 2018, 21:20:21
Zitat von: MBHG am 30 April 2018, 20:54:40
Wo schliesse ich denn den anderen Sensor an, wenn ich den ersten an A4 / A5 anschliesse?

Auch dort... Parallel... I²C ist ein Bus.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 30 April 2018, 23:00:17
Genau, die IC am I2C werden über ihre device address angesprochen. Solange die IC/Sensoren alle eine andere Adresse haben gehen alle zusammen an einem Bus.
Titel: Antw:AskSin++ Library
Beitrag von: Franki am 19 Mai 2018, 06:28:10
Hallo Papa,

Exzellente Arbeit!!
Kopplung des WDS100 klappte auf Anhieb. Leider sind die Werte fixiert. Temperatur, Feuchte Licht sehe ich nicht als Problem, sollte analog zu anderen Beispielen implemtierbar sein.
Als wesentlich schwieriger sehe ich die Implementierung des Regenmengenmessers oder auch des Windmessers (2 Counter?, Stromverbrauch?)
Hier habe ich leider zuwenig Kentnisse diese zu implementieren.
Alternativ: externe Zähler?
Hast Du vor diese zu implementieren oder irgendwer im Forum eine Lösung?

LG
Frank
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 20 Mai 2018, 11:36:10
Hallo Tom,

hatte Deinen Post damals übersehen, eigentlich genau das was ich suche

Zitat von: Tom Major am 07 März 2018, 01:17:43
Im verlinkten Arduino sketch werden als Demo dummy Werte generiert und an die CCU2 gesendet. Aufbauend auf dem sketch kann man die Messwerte beliebiger Sensoren selbst einbauen. Anpassen muss man nur den sketch selbst und für die Darstellung in der CCU2 die Datei hb_uni_sensor1.xml.

https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1)


2 Fragen:
- Funktioniert es mittlerweile mit FHEM, hat es jemand getestet? Kann man auch in FHEM die Devices konfigurieren?
- wie schwierig / einfach wäre es, zusätzlich einen Taster einzubauen?

Ich habe noch einige MySensors-Teile am laufen, mehr schlecht als recht, will diese ersetzen.
Aber an fast allen habe ich entweder einen Bewegungsmelder oder einen Taster zum Licht schalten o.ä. dran.


Viele Grüße
Klaus
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Mai 2018, 22:39:42
Es gibt in examples/custom/HB-GEN-SENS (https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/HB-GEN-SENS) einen generischen Sensor, der Temperatur & Luftfeuchtigkeit sendet. Damit er in FHEM funktioniert, muss das Module HMConfig_AskSinPPCustom.pm (https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM) installiert werden - einfach in das FHEM Verzeichnis kopieren.
Nach dem Pairing muss noch dem FHEM-Device mitgeteilt werden, wie die Nachrichten zu interpretieren sind. Dazu muss das Custom-Attribute valueformat angelegt werden:
attr DEVICE userattr valuesformat
attr DEVICE valuesformat SPEC1 SPEC2

Dabei ist für jeden gesendeten Wert eine Spezifikation durch Freizeichen getrennt anzugeben. Die SPEC besteht aus 3 Teilen, wobei nur der erste zwingend notwendig ist:
Anzahl Bytes - 1, 2 oder 4 - gefolgt von einem 's' wenn vorzeichenbehaftet
Name des Reading - wenn angegeben wird der Wert in dieses Reading gespeichert - default valueX
Faktor - empfangener Wert wird durch den Faktor geteilt - default 1

Für das Beispiel ist folgende Spezifikation zu verwenden:
2s:temperature:10 1:humidity
Also die Temperatur wird mit 2 Byte übertragen. Der Wert ist um den Faktor 10 erweitert. Das erzeugte Reading wird temperature heißen. Der zweite Wert ist ein Byte lang und nur positiv. Er wird im Reading humidity gespeichert. Je nachdem, was gesendet wird, muss der Formatstring im Device angelegt werden.
Ich hoffe mal, das kann man irgendwie verstehen. Es gibt auch noch ein paar Vorbereitungen, um einfach neue Devices mit unterschiedlichen Channels "einfach" in FHEM anzumelden. Das versuche ich demnächst nochmal zu erklären.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Mai 2018, 15:43:10
Ich habe mal nen neuen V3 Branch gemacht. Dieser sollte jetzt für aktuelle Projekte verwendet werden. Im Master wird wahrscheinlich neue Hardwareunterstützung dazu kommen. Dabei könnte sich auch was an den APIs ändern.
Außerdem habe ich mal ein paar Links zu Hardwareprojekten in die erste Seite eingefügt.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 21 Mai 2018, 15:55:24
Hat denn mittlerweile schon mal jemand ein 2 Kabel Counter zum laufen gebracht?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 Mai 2018, 11:30:30
Zitat von: ext23 am 21 Mai 2018, 15:55:24
Hat denn mittlerweile schon mal jemand ein 2 Kabel Counter zum laufen gebracht?

Probiere doch mal den generischen Sensor (https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110). Da kannst Du Deine 2 Zählerwerte einfach mit einer Nachricht an FHEM senden. Der Umbau auf 2 Zähler sollte auch nicht so dramatisch sein.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 22 Mai 2018, 15:40:09
Zitat von: papa am 22 Mai 2018, 11:30:30
Der Umbau auf 2 Zähler sollte auch nicht so dramatisch sein.

Das habe ich bei der "Kopie" des HM-ES-TX-WM auch gedacht ^^
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 22 Mai 2018, 15:59:47
Zitat von: Franki am 19 Mai 2018, 06:28:10
Hallo Papa,

Exzellente Arbeit!!
Kopplung des WDS100 klappte auf Anhieb. Leider sind die Werte fixiert. Temperatur, Feuchte Licht sehe ich nicht als Problem, sollte analog zu anderen Beispielen implemtierbar sein.
Als wesentlich schwieriger sehe ich die Implementierung des Regenmengenmessers oder auch des Windmessers (2 Counter?, Stromverbrauch?)
Hier habe ich leider zuwenig Kentnisse diese zu implementieren.
Alternativ: externe Zähler?
Hast Du vor diese zu implementieren oder irgendwer im Forum eine Lösung?

LG
Frank

Ich versuche mich auch gerade daran, einen Wind- und Regenmesser zu integrieren.
Zwar nicht bei dem WDS100, aber bei einem eigenen Sketch.
Stromtechnisch bin ich da entspannt, da die Schaltung von einem Netzteil versorgt wird.

Ich würde nicht auf einen externen Zähler zurückgreifen wollen, sondern den 328P die beiden Dinger mitzählen lassen.
Meine Idee wäre, 2 Interrupthandler anzulegen, die jeweils einen (Regen-/Wind-)Counter hochzählen.

Bei Regenmesser ist es m.M. eh nicht zeitkritisch.
Wenn z.B. ein Impuls kommt, während gerade gesendet wird, dann wird er halt bei der nächsten Aussendung mit übertragen.

Beim Windmesser sehe ich da eher das Problem, da man die Anzahl der Impulse in einem festgelegten Zeitraum zählen muss, die Geschwindigkeit zu berechnen.
Ich werde mal ein paar Versuche machen, sobald ich das Anemometer gedruckt habe.
Mir schwebt vor, eine AlarmClock anzulegen, die dann alle 5 Sekunden die Windgeschwindigkeit ermittelt.
Ist aber alles noch ein Gedankenspiel... mal schauen, wie es sich dann in der Praxis verhält.

Vielleicht hat ja papa noch einen Einwurf bzw. Denkanstoß. :)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 Mai 2018, 16:15:20
Zitat von: jp112sdl am 22 Mai 2018, 15:59:47
Vielleicht hat ja papa noch einen Einwurf bzw. Denkanstoß. :)

Hab ich - der Windmesser sollte direkt mit einem Hardware-Counter verbunden werden, da  ich hier doch sehr viele Impulse erwarten würde. Gegebenenfalls müsste noch per Hardware entprellt werden. Leider ist der 16bit-Counter schon weg. Bleibt also nur ein 8bit-Counter. Da müsste man mal überlegen/ausmessen, wie oft man den Wert lesen und zurücksetzen muss, damit man bei Orkan (bis 200km/h) noch keinen Überlauf kriegt. Alternativ müsse man noch nen ISR für den Überlauf vorsehen. Das Auslesen könnte über die sysclock mit einem Alarm mit async(true) erfolgen. Dabei dürfte aber nur der Wert umkopiert werden, da man direkt im ISR ausgeführt wird. Beim zyklischen Senden kann man dann ganz in Ruhe die erfassten Werte verarbeiten.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 22 Mai 2018, 17:02:43
Zitat von: papa am 22 Mai 2018, 16:15:20
Hab ich - der Windmesser sollte direkt mit einem Hardware-Counter verbunden werden, da  ich hier doch sehr viele Impulse erwarten würde.
Den DS2423 gibts ja nirgends mehr oder nur zu utopischen Preisen.
Ich habe was vom ATTiny als Ersatz gelesen (https://wiki.fhem.de/wiki/1-Wire_Emulation_per_ATTiny#ATtiny25), aber das scheint auch nicht ganz trivial zu sein.
Gibts noch andere Alternativen?

Zitat von: papa am 22 Mai 2018, 16:15:20
Leider ist der 16bit-Counter schon weg. Bleibt also nur ein 8bit-Counter. Da müsste man mal überlegen/ausmessen, wie oft man den Wert lesen und zurücksetzen muss, damit man bei Orkan (bis 200km/h) noch keinen Überlauf kriegt. Alternativ müsse man noch nen ISR für den Überlauf vorsehen.
Versteh ich noch nicht ganz.
Kann ich nicht
volatile uint32_t cnt = 0;
deklarieren und cnt dann inkrementieren?

Wenn ich mich nicht verrechnet habe, komme ich bei 200km/h auf ~84 Imp./Sekunde.
Zu viel für den ISR?


Zitat von: papa am 22 Mai 2018, 16:15:20
Das Auslesen könnte über die sysclock mit einem Alarm mit async(true) erfolgen. Dabei dürfte aber nur der Wert umkopiert werden, da man direkt im ISR ausgeführt wird. Beim zyklischen Senden kann man dann ganz in Ruhe die erfassten Werte verarbeiten.
Das leuchtet ein. :)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 Mai 2018, 17:19:40
Zitat von: jp112sdl am 22 Mai 2018, 17:02:43
Versteh ich noch nicht ganz.

Die Hardware Timer (https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR) sind nur Counter, die mit dem Takt verbunden sind. Der Takt kann auch von einem externen Pin kommen. Dann werden die Impulse vom Pin gezählt. Für Timer0 ist das T0 = PB0. Und für Timer2 ist das T1 = PB1.
Aber 84 Impulse pro Sekunde sollten auch noch mit einem ISR machbar sein.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 22 Mai 2018, 23:55:26
Zitat von: Klaus0815 am 20 Mai 2018, 11:36:10
Hallo Tom,

hatte Deinen Post damals übersehen, eigentlich genau das was ich suche

2 Fragen:
- Funktioniert es mittlerweile mit FHEM, hat es jemand getestet? Kann man auch in FHEM die Devices konfigurieren?
- wie schwierig / einfach wäre es, zusätzlich einen Taster einzubauen?

Ich habe noch einige MySensors-Teile am laufen, mehr schlecht als recht, will diese ersetzen.
Aber an fast allen habe ich entweder einen Bewegungsmelder oder einen Taster zum Licht schalten o.ä. dran.

Viele Grüße
Klaus

Den FHEM Perl code habe ich nach besten Wissen und Gewissen an das Nachrichtenlayout von meinem HB-UNI-Sensor1 Beispiel angepasst, kann es aber nicht testen da ich momentan Homematic devices mit RaspberryMatic getrennt von FHEM aufsetze. Ich könnte aber bezüglich des FHEM script unterstützen falls es mit einem Messwert in FHEM noch klemmen sollte..

Für den Taster würde ich mittels EnableInterrupt Lib diesen so programmieren dass er den AVR aufwecken kann und dann den Zustand des Taster in einem weiteren Byte/Bit der message übertragen, d.h. die message ein Byte länger machen. Nur eine Idee, Möglichkeiten gibt es viele.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 23 Mai 2018, 00:00:19
Zitat von: jp112sdl am 22 Mai 2018, 17:02:43
Den DS2423 gibts ja nirgends mehr oder nur zu utopischen Preisen.
Ich habe was vom ATTiny als Ersatz gelesen (https://wiki.fhem.de/wiki/1-Wire_Emulation_per_ATTiny#ATtiny25), aber das scheint auch nicht ganz trivial zu sein.
Gibts noch andere Alternativen?

Die DS2423 ATtiny Emulation geht übrigens super. Habe die an diversen S0 Stromzählern über OWserver angebunden, läuft seit mehreren Jahren problemlos.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 23 Mai 2018, 00:20:12
Zitat von: papa am 22 Mai 2018, 17:19:40
Die Hardware Timer (https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR) sind nur Counter, die mit dem Takt verbunden sind. Der Takt kann auch von einem externen Pin kommen. Dann werden die Impulse vom Pin gezählt. Für Timer0 ist das T0 = PB0. Und für Timer2 ist das T1 = PB1.
Aber 84 Impulse pro Sekunde sollten auch noch mit einem ISR machbar sein.

Sind die Zähler Eingangspins nicht eher T0=PD4, T1=PD5 beim mega328P?
Ist mir jetzt fast unangenehm den Meister zu berichtigen. duck und weg..
Titel: Antw:AskSin++ Library
Beitrag von: papa am 23 Mai 2018, 07:07:58
Stimmt PD4 & PD5
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 23 Mai 2018, 07:33:13
Das ist übrigens ein entscheidender Vorteil gegenüber dem ESP, der kann das nämlich nicht, einen Counter über einen externen Takt zu bedienen. Da muss man immer über den Int weg gehen, der aber bei hohen Frequenzen schnell in die Knie geht, wo der AVR erst anfängt warm zu laufen...

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 23 Mai 2018, 10:15:30
Zitat von: papa am 22 Mai 2018, 16:15:20
Hab ich - der Windmesser sollte direkt mit einem Hardware-Counter verbunden werden, da  ich hier doch sehr viele Impulse erwarten würde. Gegebenenfalls müsste noch per Hardware entprellt werden. Leider ist der 16bit-Counter schon weg. Bleibt also nur ein 8bit-Counter. Da müsste man mal überlegen/ausmessen, wie oft man den Wert lesen und zurücksetzen muss, damit man bei Orkan (bis 200km/h) noch keinen Überlauf kriegt.

Wenn man für diverse Zwecke doch noch 16bit counter braucht kann man übrigens den ATmega328PB nehmen.
Der hat neben weiteren Erweiterungen (z.B. eine zweite SPI) zwei zusätzliche 16bit timer/counter T3 und T4 die über die Pins PE3 und PE1 zählen können.

Eine geeignete HW dafür wäre z.B. der Pololu A-Star 328PB Micro
https://www.pololu.com/category/239/a-star-328pb-micro (https://www.pololu.com/category/239/a-star-328pb-micro)
Titel: Antw:AskSin++ Library
Beitrag von: Franki am 24 Mai 2018, 14:19:59
Hi,

danke Euch allen für Eure Antworten.
Werde es mit einem (oder zwei für Wind und Regenmenge) hardwarecountern versuchen. Der PCF8583 kann als Eventconter bis 1000000 verwendet werden (sollte reichen  ;D).
Das Auslesen geht einfach über das I2C Interface, verhält sich also wie ein Sensor.
Vom Gesamtstromverbrauch sollte die Lösung mit einem externen Counter sogar besser sein da der 328 im sleep modus bleiben kann (ich habe jetzt nicht im Datenblatt nachgeschaut ob das wirklich der fall ist).
Der Preis (zumindest for die SO Variante) ist auch OK (siehe Reichelt).

LG
Frank

Frank
Titel: Antw:AskSin++ Library
Beitrag von: Franki am 27 Mai 2018, 13:49:10
Hi,

Ich habe eine Frage zum MOD–EM–8bit, gibt es eine Möglickeit anstelle 8 Tasten abzufragen einen Wert der in einem Datenfeld abgespeichert ist zu übertragen?
Applikation: Taste drücken, dann wird RFID Tag ausgelesen und je nach ID ein unterschiedlicher Wert an die CCU übertragen (ca. 10 Werte sollten ausreichen). Die weitere Verarbeitung findet in der CCU statt.

LG

Franki
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 29 Mai 2018, 00:15:41
Zitat von: Franki am 27 Mai 2018, 13:49:10
Hi,

Ich habe eine Frage zum MOD–EM–8bit, gibt es eine Möglickeit anstelle 8 Tasten abzufragen einen Wert der in einem Datenfeld abgespeichert ist zu übertragen?
Applikation: Taste drücken, dann wird RFID Tag ausgelesen und je nach ID ein unterschiedlicher Wert an die CCU übertragen (ca. 10 Werte sollten ausreichen). Die weitere Verarbeitung findet in der CCU statt.
LG
Franki

Auf welchen AskSin++ example sketch für MOD–EM–8bit bezieht sich die Frage?
Titel: Antw:AskSin++ Library
Beitrag von: Franki am 29 Mai 2018, 11:32:19
Hallo Tom,

ich beziehe mich auf _wip_HM-MOD-EM8 und _wip_HM-MOD-EM8bit, ich fürchte aber dass sich beide sich auf die ältere Version des ELV Senders beziehen (ohne Datenübertragung) da beide keinen 3. Kanal implementiert haben.
Generell würde es mir sehr weiterhelfen die Struktur der Programme zu verstehen, zB. was wird initialisiert, wie und wo in der Software erfolgt die Erkennung eines Tastendrucks, wo in der Software erfolgt die Übertragung......

LG

Franki
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 Mai 2018, 11:41:42
Zitat von: Franki am 29 Mai 2018, 11:32:19
ich beziehe mich auf _wip_HM-MOD-EM8 und _wip_HM-MOD-EM8bit,

???? Wo / was ist das ????
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 29 Mai 2018, 11:43:11
Zitat von: Franki am 29 Mai 2018, 11:32:19
ich beziehe mich auf _wip_HM-MOD-EM8 und _wip_HM-MOD-EM8bit, ich fürchte aber dass sich beide sich auf die ältere Version des ELV Senders beziehen (ohne Datenübertragung) da beide keinen 3. Kanal implementiert haben.
Generell würde es mir sehr weiterhelfen die Struktur der Programme zu verstehen, zB. was wird initialisiert, wie und wo in der Software erfolgt die Erkennung eines Tastendrucks, wo in der Software erfolgt die Übertragung......

LG

Franki

Was meinst du mit 3. Kanal?
Der ...-EM8bit hat den 3.Kanal implementiert auf dem die 8 Zustände übertagen werden.
Beim EM8 werden die Zustände der einzelnen Kontakte als einzelne Kanäle aus der sysinfo (count_from_sysinfo="23.0:1.0") genommen.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 29 Mai 2018, 11:43:40
Zitat von: papa am 29 Mai 2018, 11:41:42
???? Wo / was ist das ????
https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/_wip_HM-MOD-EM-8Bit/_wip_HM-MOD-EM-8Bit.ino
https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/_wip_HM-MOD-EM-8/_wip_HM-MOD-EM-8.ino
Titel: Antw:AskSin++ Library
Beitrag von: Franki am 29 Mai 2018, 16:37:56
Hi,

ZitatWas meinst du mit 3. Kanal?
Der ...-EM8bit hat den 3.Kanal implementiert auf dem die 8 Zustände übertagen werden.
Beim EM8 werden die Zustände der einzelnen Kontakte als einzelne Kanäle aus der sysinfo (count_from_sysinfo="23.0:1.0") genommen.

Beim EM8 gibt es Übertragungsmodi bei denen ein Änderung an einem Taster (DUI30) die 8 bit Übertragung trigger, dh. alle 8 bit liegen an den entsprechenden Eingängen an und die Übertragung wird erst gestartet wenn DU30 zB. von high auf low geht.
Ich vermisse die Anschußmöglichkeit für einen 3. Taster.

LG

Franki
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 29 Mai 2018, 16:49:48
Ach so. Ja, ist noch im Status "wip" = work in progress
Vielleicht macht ein anderer den Sketch fertig und dann einen PullRequest. 8) :)
Ich komme momentan nicht dazu, daran weiterzuarbeiten.
Hatte den Sketch auch nur schnell zusammengeschustert, weil ich testen wollte, ob man beim EM8bit der CCU noch mehrere 8bit-Kanäle einem Device unterschustern kann.
Geht an sich sogar, aber die Ampel-Anzeige in der WebUI zeigt nur den ersten 8bit-Kanal an.
Titel: Antw:AskSin++ Library
Beitrag von: Funsailor am 30 Mai 2018, 14:14:27
Hallo Papa,
ich habe mal das Beispiel
V3\examples\stm32\HM-LC-SWX-SM\HM-LC-SWX-SM.ino
compiliert.
Dabei bekomme ich immer die Fehlermeldung das
ZitatHM-LC-SWX-SM.ino:22:23: error: 'at24cX' was not declared in this scope

Das liegt daran, das die Klasse at24cX in der storage.h definiert ist, diese Datei aber erst ein paar Zeilen weiter unten eingebunden wird.


#define STORAGEDRIVER at24cX<0x50,128,32>

#include <SPI.h>    // when we include SPI.h - we can use LibSPI class
#include <Wire.h>
#include <EEPROM.h> // the EEPROM library contains Flash Access Methods
#include <AskSinPP.h>

#include <MultiChannelDevice.h>
#include <Switch.h>


ändern in



#include <SPI.h>    // when we include SPI.h - we can use LibSPI class
#include <Wire.h>
#include <EEPROM.h> // the EEPROM library contains Flash Access Methods
#include <AskSinPP.h>

#include <MultiChannelDevice.h>
#include <Switch.h>

#define STORAGEDRIVER at24cX<0x50,128,32>



und das Beispiel wird fehlerlos kompiliert.

Mal sehen, wann ich dazu komme, das auf einem STM32F103 Board zu testen.
Bei der 48er Variante des F103 liegt SCL an PB6 und SDA an PB7.
Aber wo finde ich die PIN Definitio für das EEProm?
LG
Funsailor
Titel: Antw:AskSin++ Library
Beitrag von: papa am 30 Mai 2018, 14:38:40
Zitat von: Funsailor am 30 Mai 2018, 14:14:27
Hallo Papa,
ich habe mal das Beispiel
V3\examples\stm32\HM-LC-SWX-SM\HM-LC-SWX-SM.ino
compiliert.
Dabei bekomme ich immer die Fehlermeldung das
Das liegt daran, das die Klasse at24cX in der storage.h definiert ist, diese Datei aber erst ein paar Zeilen weiter unten eingebunden wird.

Schau mal in die Wire.h bzw. WireBase.h was da für ein Define drin ist und check das mal gegen die ifdef Liste im Storage.h. Vielleicht ist das eine andere Version.

STORAGEDRIVER muss unbedingt vor den Includes definiert werden, da es bei der Template-Instanziierung vorhanden sein muss. Sonst wird automatisch auf die Flash-Default-Implementierung zurück geschalten.
Wegen den Pins könnte ich ja jetzt "Search Goo..." sagen - aber hier der direkte Link (http://ww1.microchip.com/downloads/en/devicedoc/doc0336.pdf).
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 30 Mai 2018, 17:41:29
Zitat von: Franki am 29 Mai 2018, 11:32:19
Hallo Tom,

ich beziehe mich auf _wip_HM-MOD-EM8 und _wip_HM-MOD-EM8bit, ich fürchte aber dass sich beide sich auf die ältere Version des ELV Senders beziehen (ohne Datenübertragung) da beide keinen 3. Kanal implementiert haben.
Generell würde es mir sehr weiterhelfen die Struktur der Programme zu verstehen, zB. was wird initialisiert, wie und wo in der Software erfolgt die Erkennung eines Tastendrucks, wo in der Software erfolgt die Übertragung......

LG

Franki

Hm, jp112sdl schreibt ja das der sketch noch work in progress ist.

Weiss nicht genau was du vorhast, ob dir z.B. für das RFID Übertragen auf Tastendruck ein 'custom' HM device (mit eigener xml) reichen würde?
Falls ja würde ich z.B. den HM-RC-P1 sketch nehmen, versuchen (ggf. mit papas Hilfe) das zusätzliche RFID Byte an die message anzuhängen oder über einen zweitem Kanal zu senden und das xml für die CCU entsprechend anzupassen.

Wenn du allerdings genau das original HM-MOD-EM8bit device in der CCU brauchst würde ich mit jp112sdl sketch weitermachen..
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 01 Juni 2018, 14:30:43
Gibt es eigentlich mittlerweile schon eine Dokumentation. Ich hab mich jetzt mal an den generischen Sensor versucht um dort mein Wasseruhr Dual Zähler einzubauen aber ich sehe bei dem Code wirklich null durch. Dieser ganze public und class misst... Ich raff es nicht, das ist mir alles zu unübersichtlich. Ich hab die Objektorientierung schon im Studium nicht verstanden, ist irgendwie nicht besser geworden ;-)

Ich möchte doch nur das dieser Code ca. alle halbe Sekunde ausgeführt wird für zwei Sensoren und dann nach 3 Minuten beide Zählerstände übermittelt werden.

pinMode(senspin,INPUT);
pinMode(irpin,OUTPUT);

// read on value
digitalWrite(irpin,HIGH);
_delay_ms(10);
uint16_t valon = analogRead(senspin);
// read off value
digitalWrite(irpin,LOW);
_delay_ms(10);
uint16_t valoff = analogRead(senspin);


/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Juni 2018, 15:23:25
Zitat von: ext23 am 01 Juni 2018, 14:30:43
Gibt es eigentlich mittlerweile schon eine Dokumentation. Ich hab mich jetzt mal an den generischen Sensor versucht um dort mein Wasseruhr Dual Zähler einzubauen aber ich sehe bei dem Code wirklich null durch. Dieser ganze public und class misst... Ich raff es nicht, das ist mir alles zu unübersichtlich. Ich hab die Objektorientierung schon im Studium nicht verstanden, ist irgendwie nicht besser geworden ;-)
Also ohne C++ Kenntnisse wird es auch mit Doku schwer.
Zitat von: ext23 am 01 Juni 2018, 14:30:43
Ich möchte doch nur das dieser Code ca. alle halbe Sekunde ausgeführt wird für zwei Sensoren und dann nach 3 Minuten beide Zählerstände übermittelt werden.
Hier mal schnell der Code für das Senden von 2 Countern. Diese werden im Code nur hochgezählt. Da musst Du noch Deinen Code einbauen. Je nachdem wie Du es haben willst, müssen die Counter auch noch nach dem Senden genullt werden. Also ich finde das total übersichtlich und leicht verständlich  ;)
//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2018-04-22 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 EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Register.h>
#include <Device.h>
#include <MultiChannelDevice.h>

// use builtin led
#define LED_PIN 4
// Arduino pin for the config button
// use button on maple mini board
#define CONFIG_BUTTON_PIN 8


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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0xfa,0x32,0x71},       // Device ID
    "papafa3271",           // Device Serial
    {0xf2,0x05},            // Device Model
    0x01,                   // Firmware Version
  as::DeviceType::Sensor, // Device Type
    {0x00,0x00}             // Info Bytes
};

/**
* Configure the used hardware
*/
typedef AvrSPI<10,11,12,13> RadioSPI;
typedef AskSin<StatusLed<4>,BatterySensor,Radio<RadioSPI,2> > Hal;

DEFREGISTER(SensReg0,MASTERID_REGS)
class SensList0 : public RegList0<SensReg0> {
public:
  SensList0 (uint16_t addr) : RegList0<SensReg0>(addr) {}
};

DEFREGISTER(ValuesReg1,CREG_AES_ACTIVE)
class ValuesList1 : public RegList1<ValuesReg1> {
public:
  ValuesList1 (uint16_t addr) : RegList1<ValuesReg1>(addr) {}
};

class ValuesChannel : public Channel<Hal,ValuesList1,EmptyList,EmptyList,0,SensList0>, Alarm {

uint32_t count1, count2;

public:
  typedef Channel<Hal,ValuesList1,EmptyList,EmptyList,0,SensList0> BaseChannel;

  ValuesChannel () : BaseChannel(), Alarm(0), count1(0), count2(0) {}
  virtual ~ValuesChannel () {}

  virtual void trigger (AlarmClock& clock) {
    ValuesMsg& msg = device().message().values();
    msg.init(device().nextcount(),number());
    msg.add(count1);
    msg.add(count2);
    device().send(msg, device().getMasterID());

    set(seconds2ticks(3*60));
    clock.add(*this);
  }

  void setup(Device<Hal,SensList0>* dev,uint8_t number,uint16_t addr) {
    BaseChannel::setup(dev, number, addr);
    set(seconds2ticks(5));
    sysclock.add(*this);
  }

  uint8_t status () const { return 0; }
  uint8_t flags () const { return 0; }

  void raiseCounter1() { ++count1; }
  void raiseCounter2() { ++count2; }
  uint32_t getCounter1 () const { return count1; }
  uint32_t getCounter2 () const { return count2; }
  void setCounter1 (uint32_t value) { count1=value; }
  void setCounter2 (uint32_t value) { count2=value; }

};

class SensType : public MultiChannelDevice<Hal,ValuesChannel,1,SensList0> {
public:
  typedef MultiChannelDevice<Hal,ValuesChannel,1,SensList0> DevType;
  SensType (const DeviceInfo& i,uint16_t addr) : DevType(i,addr) {}
  virtual ~SensType () {}
};

Hal hal;
SensType sdev(devinfo,0x20);
ConfigButton<SensType> cfgBtn(sdev);

class CyclicMeasure : public Alarm {
public:
  CyclicMeasure () : Alarm(millis2ticks(500)) {}
  virtual ~CyclicMeasure () {}

  virtual void trigger (AlarmClock& clock) {
    set(millis2ticks(500));
    clock.add(*this);
    // add your own measure code here
    sdev.channel(1).raiseCounter1();
    if( (sdev.channel(1).getCounter1() % 1) == 0 ) {
      sdev.channel(1).raiseCounter2();
    }
  }
} measure;

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  sdev.initDone();
  sysclock.add(measure);
}

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: ext23 am 01 Juni 2018, 15:29:53
Schau ich mir mal an.

Naja diese ganzen Funktionen oder Methoden oder wie man das nennt, das wäre schon gut wenn das erklärt ist. Das hilft ungemein. HAL, ValuesList1, BaseChannel .... ich werd wahnsinnig ;-) Was ist ANSI C nicht einfach ^^

Aber ich glaube ein großes Problem ist hier auch die arduino IDE, die macht es ja ziemlich unmöglich mit Bibliotheken zuarbeiten da man nicht in den Code springen kann... aber gut das ist ein IDE Problem, kein Code Problem ;-)

Übrigens warum wird die Status LED unten fixed auf PIN 4 konfiguriert und oben gibt es aber ein define was vermutlich ignoriert wird?!?

UPDATE: Tatsache, jetzt funktioniert es... Jetzt schau ich mir mal das Modul auf FHEM Seite an. Wegen dem löschen der Counter, tja mhh Glaubensfrage... Ich lass die lieber hochzählen. Verliert man Nachrichten bzw. beim Stromausfall ist das etwas leichter zu erkennen glaube ich.

Gibt es eigentlich noch eine fertige Funktion die Status LED einmal blinken zu lassen?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Juni 2018, 16:39:24
Zitat von: ext23 am 01 Juni 2018, 15:29:53
Übrigens warum wird die Status LED unten fixed auf PIN 4 konfiguriert und oben gibt es aber ein define was vermutlich ignoriert wird?!?
Hm - kleiner Fehler
Zitat von: ext23 am 01 Juni 2018, 15:29:53
UPDATE: Tatsache, jetzt funktioniert es... Jetzt schau ich mir mal das Modul auf FHEM Seite an. Wegen dem löschen der Counter, tja mhh Glaubensfrage... Ich lass die lieber hochzählen. Verliert man Nachrichten bzw. beim Stromausfall ist das etwas leichter zu erkennen glaube ich.
Das freut mich
attr DEVICE userattr valuesformat
attr DEVICE valuesformat 4:Counter1 4:Counter2

Zitat von: ext23 am 01 Juni 2018, 15:29:53
Gibt es eigentlich noch eine fertige Funktion die Status LED einmal blinken zu lassen?
sdev.led().ledOn(millis2ticks(100));oderhal.led.ledOn(millis2ticks(100));
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 01 Juni 2018, 17:07:55
Jetzt scheint es mit der Kommunikation nicht 100% zu klappen, ich bekomme immer diese ack Meldung:

AskSin++ V2.1.5 (Jun  1 2018 16:32:57)
Address Space: 32 - 36
CC init1
CC Version: 14
- ready
<- 13 01 A2 53 230011 23FF23 01 02 00 00 00 00 00 00 00 00  - 442
-> 0A 01 80 02 23FF23 230011 00  - 567
waitAck: 01
<- 13 02 A2 53 230011 23FF23 01 02 00 00 00 00 00 00 00 00  - 16013
-> 0B 1E 84 70 23AA23 000000 01 22  - 16117
-> 0A 02 80 02 23FF23 230011 00  - 16142
waitAck: 01



--> Pair Mode enabled and config button pressed


debounce
pressed
released
<- 1A 03 80 00 230011 23FF23 01 F2 05 46 48 45 4D 30 30 30 30 31 31 41 01 00 00  - 21628

-> 10 2B A0 01 23FF23 230011 00 05 00 00 00 00 00  - 21755
<- 0A 2B 80 02 230011 23FF23 00  - 21878
-> 13 2C A0 01 23FF23 230011 00 08 02 01 0A 23 0B FF 0C 23  - 22167
<- 0A 2C 80 02 230011 23FF23 00  - 22288
-> 0B 2D A0 01 23FF23 230011 00 06  - 22568
<- 0A 2D 82 02 230011 23FF23 00  - 22689
-> 10 2E A0 01 23FF23 230011 00 04 00 00 00 00 00  - 25726
<- 12 2E 80 10 230011 23FF23 02 0A 23 0B FF 0C 23 00 00  - 25856
Counter A: 1
Counter A: 2
Counter A: 3
Counter A: 4
<- 13 04 A2 53 230011 23FF23 01 02 00 00 00 04 00 00 00 00  - 49965
-> 0A 04 80 02 23FF23 230011 00  - 50089
waitAck: 01


Das Gerät wurde unter FHEM aber angelegt. Und ich habe folgendes gesetzt:
userattr
valuesformat

valuesformat
4:Kaltwasser 4:Warmwasser
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Juni 2018, 20:57:16
Sieht doch alles gut aus. Die Werte müssten doch auch ankommen.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 01 Juni 2018, 21:29:44
Öhh achso, ich dachte der wartet auf ein Ack. Aber ankommen tut nichts, auch im event Monitor sehe ich nichts, mhh. Muss ich wohl mal den Debug Mode anschalten.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Juni 2018, 21:39:55
Die 01 heißt OK. Sonst kommt da 00 und es wird das Paket nochmal gesendet.

Ich nehme mal an, das hier ist Deine Zentrale 23FF23. Die sagt schön immer ACK. Müsste also irgendwo zu sehen sein.
Hast Du das FHEM-Modul HMConfig_AskSinPPCustom.pm aktualisiert ?
Schau mal das müsste auch was im Log ankommen.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 01 Juni 2018, 23:40:49
Ich hab das Modul genommen aus dem link wo du auf das custom example verwiesen hast.

Auch das file log bleibt leer, das letzte was da steht war das pairing. Der state steht noch bei "RESPONSE TIMEOUT:RegisterRead".
getconfig hilft auch nicht. Mhh mal FHEM neu starten?!?

2018-06-01_16:51:45 HM_230011 D-firmware: 0.1
2018-06-01_16:51:45 HM_230011 D-serialNr: FHEM000011
2018-06-01_16:51:51 HM_230011 R-pairCentral: 0x23FF23
2018-06-01_16:53:33 HM_230011 ResndFail
2018-06-01_16:53:33 HM_230011 RESPONSE TIMEOUT:RegisterRead
2018-06-01_16:57:41 HM_230011 D-firmware: 0.1
2018-06-01_16:57:41 HM_230011 D-serialNr: FHEM000011
2018-06-01_17:03:11 HM_230011 D-firmware: 0.1
2018-06-01_17:03:11 HM_230011 D-serialNr: FHEM000011
2018-06-01_17:03:11 HM_230011 R-pairCentral: set_0x23FF23
2018-06-01_17:03:15 HM_230011 R-pairCentral: 0x23FF23
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 02 Juni 2018, 09:16:26
Moin,

also bei lastMsg No:01 - t:53 s:230011 d:23FF23 01020000000000000000 sehe ich was im Modul, das passt also. Aber wieso werden die Readings die ich über valuesformat angelegt habe nicht angezeigt?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 Juni 2018, 10:57:15
Zitat von: ext23 am 01 Juni 2018, 23:40:49
Ich hab das Modul genommen aus dem link wo du auf das custom example verwiesen hast.

Also das hier https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM/HMConfig_AskSinPPCustom.pm ?
Und dannach ein Reload bzw Neustart ?

Zitat von: ext23 am 01 Juni 2018, 23:40:49
Auch das file log bleibt leer, das letzte was da steht war das pairing. Der state steht noch bei "RESPONSE TIMEOUT:RegisterRead".
getconfig hilft auch nicht. Mhh mal FHEM neu starten?!?

2018-06-01_16:51:45 HM_230011 D-firmware: 0.1
2018-06-01_16:51:45 HM_230011 D-serialNr: FHEM000011
2018-06-01_16:51:51 HM_230011 R-pairCentral: 0x23FF23
2018-06-01_16:53:33 HM_230011 ResndFail
2018-06-01_16:53:33 HM_230011 RESPONSE TIMEOUT:RegisterRead
2018-06-01_16:57:41 HM_230011 D-firmware: 0.1
2018-06-01_16:57:41 HM_230011 D-serialNr: FHEM000011
2018-06-01_17:03:11 HM_230011 D-firmware: 0.1
2018-06-01_17:03:11 HM_230011 D-serialNr: FHEM000011
2018-06-01_17:03:11 HM_230011 R-pairCentral: set_0x23FF23
2018-06-01_17:03:15 HM_230011 R-pairCentral: 0x23FF23

Kannst Du mal nen List vom Device schicken
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 02 Juni 2018, 12:03:38
Genau das habe ich genommen, aber danach kein Neustart gemacht, nur autocreate habe ich aktiviert. Den FHEM Neustart habe ich erst heute gemacht. Ohne Wirkung. Ich hab bestimmt irgendwo was falsch gemacht. Der Model Type war auch auf unknown, den habe ich manuell angepasst. Und ich habe es jetzt mal gelöscht und neu angelegt, Kein unterschied, die Readings fehlen. Musste man da erst noch was umstellen mit den Readings, irgend was war mir doch in Erinnerung, oder betraf das nur Readings mit . vorne ?!?


Internals:
   CFGFN     
   DEF        230011
   HMLAN1_MSGCNT 8
   HMLAN1_RAWMSG E230011,0000,8BACE556,FF,FFC9,01A25323001123FF2301020000000000000000
   HMLAN1_RSSI -55
   HMLAN1_TIME 2018-06-02 13:11:54
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     8
   NAME       HM_230011
   NOTIFYDEV  global
   NR         3575
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_230011_Values
   lastMsg    No:01 - t:53 s:230011 d:23FF23 01020000000000000000
   protLastRcv 2018-06-02 13:11:54
   protSnd    5 last_at:2018-06-02 13:11:54
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:8 min:-55 max:-45 avg:-51.37 lst:-55
   READINGS:
     2018-06-02 13:11:30   D-firmware      0.1
     2018-06-02 13:11:30   D-serialNr      FHEM000011
     2018-06-02 13:11:30   PairedTo        0x23FF23
     2018-06-02 13:11:30   R-pairCentral   0x23FF23
     2018-06-02 13:11:54   state           CMDs_done
   helper:
     HM_CMDNR   1
     PONtest    1
     cSnd       0123FF2323001100040000000000,0123FF2323001101040000000001
     cfgChkResult No regs found for:

HM_230011 type:custom -
list:peer register         :value
   0:      pairCentral      :0x23FF23
                       
                       

     mId        F205
     regLst     ,0,1
     rxType     4
     supp_Pair_Rep 0
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +230011,00,00,00
       nextSend   1527937890.96719
       prefIO     
       rxt        0
       vccu       
       p:
         230011
         00
         00
         00
     mRssi:
       mNo        01
       io:
         HMLAN1:
           -49
           -49
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         HMLAN1
       flg        A
       ts         1527937914.86753
       ack:
         HASH(0x8d06ba0)
         01800223FF2323001100
     rssi:
       at_HMLAN1:
         avg        -51.375
         cnt        8
         lst        -55
         max        -45
         min        -55
     shadowReg:
     tmpl:
   nb:
     cnt        1
Attributes:
   IODev      HMLAN1
   autoReadReg 4_reqStatus
   expert     1_allReg
   firmware   0.1
   model      HB-GEN-SENS
   room       X_Autocreate
   serialNr   FHEM000011
   subType    custom
   userattr   valuesformat
   valuesformat 4:Kaltwasser 4:Warmwasser
   webCmd     getConfig:clear msgEvents
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 02 Juni 2018, 13:17:32
Warte mal, ich Idiot, jetzt sehe ich gerade der hat ja noch ein Unterkanal angelegt und da stehen die Values drin, und da muss ich vermutlich auch das userattr einbauen, da steht jetzt nur Value1 und Value2 .... Misst, den Unterkanal legt autocreate blöderweise auch nicht da an wo er soll sondern ins Unsorted...
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 Juni 2018, 13:23:11
Zitat von: ext23 am 02 Juni 2018, 13:17:32
Warte mal, ich Idiot, jetzt sehe ich gerade der hat ja noch ein Unterkanal angelegt und da stehen die Values drin, und da muss ich vermutlich auch das userattr einbauen, da steht jetzt nur Value1 und Value2 .... Misst, den Unterkanal legt autocreate blöderweise auch nicht da an wo er soll sondern ins Unsorted...
Ja, die Attribute müssen in den Kanal1. Die Werte kommen auch dort an.
Titel: Antw:AskSin++ Library
Beitrag von: Funsailor am 05 Juni 2018, 13:12:56
Hallo Papa,
habe erst heute deine Antwort gelesen.
Zitat von: papa am 30 Mai 2018, 14:38:40
Schau mal in die Wire.h bzw. WireBase.h was da für ein Define drin ist und check das mal gegen die ifdef Liste im Storage.h. Vielleicht ist das eine andere Version.
STORAGEDRIVER muss unbedingt vor den Includes definiert werden, da es bei der Template-Instanziierung vorhanden sein muss. Sonst wird automatisch auf die Flash-Default-Implementierung zurück geschalten.
Um welche Defines geht es dir da?
Die Klasse at24cX wird durch diese Zeile verwaltet:
#if defined(TwoWire_h) || defined(_WIRE_H_) || defined(_TWOWIRE_H_) || defined(_WIREBASE_H_)

In den Dateien  Wire.h bzw. WireBase.h werden die Defines _WIREBASE_H_ und _TWOWIRE_H_ gesetzt.
Ich habe das jetzt mal so gelöst:


#define _WIRE_H_
//#define STORAGEDRIVER at24c32
#define STORAGEDRIVER at24cX<0x50,128,32>

#include <SPI.h>    // when we include SPI.h - we can use LibSPI class
#include <Wire.h>
#include <EEPROM.h> // the EEPROM library contains Flash Access Methods
#include <AskSinPP.h>


und hoffe das ich mit dem
#define _WIRE_H_
nicht irgend einen anderen Fehler erzeuge. Aber der Sketch läuft nun durch.
Einen Versionseintrag konnte ich nicht finden...

Zitat von: papa am 30 Mai 2018, 14:38:40
Wegen den Pins könnte ich ja jetzt "Search Goo..." sagen - aber hier der direkte Link (http://ww1.microchip.com/downloads/en/devicedoc/doc0336.pdf).
Über die Pinbelegung am EEProm weiß ich Bescheid, die haben wir in unseren Steuerungen schon vor mehr als 20 Jahren eingesetzt, allerdings mit 2KByte ....
Mit der Frage:
"Aber wo finde ich die PIN Definition für das EEProm?"
bezog ich mich auf die Pin Definition am Controller (STM32F103)....
Da war meine Frage nicht eindeutig.

Das habe ich in der "I2C_f1.c" gefunden:

static i2c_dev i2c1 = I2C_DEV_OLD(1, &gpiob, 7, 6);
static i2c_dev i2c2 = I2C_DEV_OLD(2, &gpiob, 11, 10);

und eine Zeile darunter kann man das I2C1 Device auf Pin  PB9 und PB8 remappen.

static int i2c1_wants_remap(const i2c_dev *dev)


Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 Juni 2018, 13:29:47
Komisch, dass das "normale" _TWOWIRE_H_ nicht reicht.
Es wird der I2C1 genutzt. Dieser liegt auf PB6 & PB7 - steht auf dem Maple Mini (https://os.mbed.com/media/uploads/hudakz/maplemini_pinout.png) schön drauf
Titel: Antw:AskSin++ Library
Beitrag von: Funsailor am 05 Juni 2018, 22:21:12
Hallo Papa,
wo wird _TWOWIRE_H_  normalerweise gesetzt?
Ich habe einfach eine der 4 Defines genommen.
Oder habe ich die falschen STM Libs genommen?
Ich habe hier einen China Clone und die Libs von Roger Clark installiert....
https://github.com/rogerclarkmelbourne/Arduino_STM32
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 Juni 2018, 22:26:48
In der Wire Lib in Wire.h bzw. WireBase.h. Die Arduinoumgebung von Clark nutze ich auch.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 19 Juni 2018, 21:24:55
Hey kurze Frage,
ich möchte einen Rolladenaktor um einen zusätzlichen Schaltkanal erweitern.
Was muss ich dazu im Sketch machen?
Klar dass ich auch wahrscheinlich ne neue Definition des Gerätes auf der CCU anlegen muss.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 19 Juni 2018, 21:50:29
Zitat von: Xent am 19 Juni 2018, 21:24:55
Hey kurze Frage,
ich möchte einen Rolladenaktor um einen zusätzlichen Schaltkanal erweitern.
Was muss ich dazu im Sketch machen?
Klar dass ich auch wahrscheinlich ne neue Definition des Gerätes auf der CCU anlegen muss.

Schau dir mal den HB-SW2-SENS Sketch an. (https://github.com/pa-pa/AskSinPP/blob/master/examples/custom/HB-SW2-SENS/HB-SW2-SENS.ino)
Dort sieht man schön, wie man 2 unterschiedliche Kanaltypen zu einem "MixDevice" vereinen kann.
Das klappt wunderbar. Ich hab mir damit vor kurzem erst einen kombinierten "Druckmesser mit Schließerkontakt" gebaut.
https://github.com/jp112sdl/HB-UNI-Sen-PRESS/blob/master/HB-UNI-Sen-PRESS-SC/HB-UNI-Sen-PRESS-SC.ino
Auf einem Kanal wird der Messwert des Drucksensors übertragen, auf einem anderen Kanal ein offen/zu-Kontakt bei über-/unterschreiten einer konfigurierbaren Hysterese.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Juni 2018, 09:18:16
Oder die Klingel (https://github.com/pa-pa/AskSinPP/blob/master/examples/stm32/HB-DoorBell/HB-DoorBell.ino) - ist etwas umfangreicher und für STM32 - aber da sieht man das auch gut. Es gibt dazu auch jeweils das passende FHEM Gerät.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 09:18:03
Soo ich hab da mal was gebastelt ...
Es compilert auch, allerdings stürzt der Arduino immer sofort ab.
Hab auch schon versucht was für die CCU2 zu basteln.

Der Sketch ist noch nicht komplett fertig. Wollte erstmal schauen ob er läuft und sich pairen lässt.
Am Ende soll eine Fernbedienung für meine Markiese mit dem Arduini gesteuert werden.
Diese hat die Buttons Au, Ab, Stopp und Licht an/aus.
Daher brauche ich am besten noch den zusätzlichen Schaltkanal.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 Juni 2018, 10:39:38
Hab mal schnel drüber gesehen. Ich denke, es liegt hier dran:
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal,BlindList0>,2,BlindList0> DeviceType;
  MixDevice (const DeviceInfo& info,uint16_t addr) : DeviceType(info,addr), cycle(*this) {
    DeviceType::registerChannel(c1,1);
    DeviceType::registerChannel(c3,3);
  }

Dein Device hat 2 Kanaäle, aber dur registrierst Kanal 1 und 3 -> das müsste dann auch 1 & 2 sein.
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal,BlindList0>,2,BlindList0> DeviceType;
  MixDevice (const DeviceInfo& info,uint16_t addr) : DeviceType(info,addr), cycle(*this) {
    DeviceType::registerChannel(c1,1);
    DeviceType::registerChannel(c3,2);
  }

Heute Abend kann ich das ganze mal auf ner Hardware testen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 11:28:33
Jau das wars ... Danke

Mal schauen obs nun Paired und ob die CCU mein Device akzeptiert.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 13:46:48
Also Pairing klappt und nachdem ich die internen Peerings angepasst habe funktioniert auch das Schalten.

Allerdings ist es so, dass im Sketch der Rolloaktor den 1. Kanal und der Schalter den zweiten Kanal hat.
In der WebGUI der CCU ist es allerdings genau umgekehrt.
Sprich wenn ich in der GUI das erste Rollo Auf/Ab schalte, dann schaltet der Schalter an und aus.
Beim 2. Rollo reagiert dann das Rollo.

Außerdem werden beide Channels als Rollo angezeigt.
Ist es möglich das, ein Kanal als Rollo und einer als Schalter dargestellt wird?
Falls nicht, werd ich damit leben können, da ja das Schalten und der Status funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 Juni 2018, 18:37:52
Bin jetzt zwar nicht der CCU Experte, aber setzte mal bei beiden Channels den Count direkt auf 1. Das count_from_sysinfo ergibt 2. Also anstattt
<channel index="1" type="BLIND" count_from_sysinfo="23.0:1.0">
direkt
<channel index="1" type="BLIND" count="1">
und ebenso
<channel index="2" type="SWITCH" count="1">.
Außerdem würde ich dem neuen Gerät noch eine andere ID geben. Also
<type name="radio-controlled blind actuator 1-channel (flush-mount)" id="HM-LC-Bl1PBU-FM" updatable="true" priority="2">
ersetzen durch z.B.
<type name="radio-controlled blind actuator 1-channel (flush-mount)" id="HB-LC-Bl-Sw" updatable="true" priority="2">.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 19:50:22
Das mit der ID hatte ich schon angepasst.
Allerdings wird es immer noch als HM-LC-BlX gefunden.
In einer anderen XML steht folgendes drin:
        <type name="generic blind actuator" id="HM-LC-BlX" priority="1">
            <parameter index="9.0" size="1.0" cond_op="LE" const_value="0x23" />
            <parameter index="22.0" size="1.0" const_value="0x30" />
        </type>


Was bedeutet eigentlich der Parameter index 9?
Das mit dem cond_op könnte ich mir denken:
LE = lower equal
E = equal
GE = greater equal
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 24 Juni 2018, 19:53:41
An dieser Stelle wird die Firmware Version des Device übermittelt.
Unterschiedliche Firmware Stände der selben Device ID nutzen bspw unterschiedliche Parameter, die erst mit neueren Firmwareständen hinzukam.
Daher gibt es für ein und den selben Gerätetyp auch manchmal mehrere XML Files. (Auch mit _le (less or equal) in Dateinamen)


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 19:58:36
Ok, dann könnte da noch mein Fehler sein.
Die Firmware Version war 0x21 und natürlich der Typ 0x30 und da die Priorität von diesem Eintrag höher als die der anderen ist, wurde das immer als dieses Gerät erkannt.

Werde das mal ändern und morgen testen.
Kann jetzt leider die CCU nicht mehr neustarten, da dann möglicherweise die Rollos der Kids wieder hochfahren xD
Oder gibts ne andere Möglichkeit die Typen neu laden zu lassen ohne nen kompletten Reboot?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 24 Juni 2018, 20:02:05
Ja
/etc/init.d/S61rfd restart


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 24 Juni 2018, 20:15:36
Wenn du eh eine neue eigene Device ID für dein Gerät vergeben hast, kannst du die ganze Zeile mit dem Index 9 auch rausschmeißen. Dann ist es egal, welche Firmware Version du aus deinem Sketch übermittelst.


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 20:24:34
Hmm irgendwie will das ganze nicht so richtig ...

Hier sind die Definitionen im Sketch:
// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x59,0x32,0xaf},              // Device ID
    "papa5932af",                  // Device Serial
    {0xf0,0x0f},                   // Device Model
    0x40,                          // Firmware Version
    as::DeviceType::BlindActuator, // Device Type
    {0x01,0x00}                    // Info Bytes
};


Und hier die in der XML:
    <supported_types>
        <type name="radio-controlled blind actuator 1-channel (flush-mount)" id="HM-LC-Bl-SW" updatable="true" priority="1">
            <parameter index="10.0" size="2.0" const_value="0xF00F" />
        </type>
    </supported_types>
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 24 Juni 2018, 20:27:35
Setze mal die Info Bytes beide auf 0x01.

Kann leider nicht viel mehr beim Debuggen helfen, bin bis Ende nächster Woche nur mobil unterwegs.
Aber wenn es dann immer noch ungelöste Probleme gibt, schau ich noch mal mit drauf.


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 20:34:40
Hab ich gemacht, brachte aber auch nichts ...
Hab zum testen mal das Modell auf 0x0005 gesetzt und siehe da, es wird als HM-LC-Bl1-FM erkannt.
Warum klappt das bloß nicht mit meiner Id ...
Muss man sonst noch irgendwo das neue Gerät bekannt machen?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 24 Juni 2018, 20:36:20
Nein.
Was klappt denn gerade nicht?
Anlernen an sich?
Die Darstellung des zweiten Kanals?


Gesendet von iPhone mit Tapatalk
Titel: AskSin++ Library
Beitrag von: jp112sdl am 24 Juni 2018, 20:40:03
Ach so - na klar.
Oh man ich bin voll im Urlaubsmodus [emoji23]

Ja in der /www/webui/webui.js und in der /www/config/devdescr/DEVDB.tcl oder so ähnlich.

Schau mal bitte im Addon Installationsskript von einem meiner Projekte.
https://github.com/jp112sdl/HB-UNI-Sen-CAP-MOIST/blob/master/Addon/HB-UNI-Sen-CAP-MOIST-addon-src/addon/install


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 20:56:17
So, hab ich nun auch angepasst, aber ich denke mal das war hauptsächlich für die GUI, dass die die entsprechenden Grafiken anzeigt.
Oder braucht das ganze nun doch nen kompletten neustart?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 24 Juni 2018, 20:59:27
Du musst dann die ReGa neustarten
/etc/init.d/S70ReGaHss restart
Wenn ich mich richtig erinnere


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 21:04:39
Ne braucht man nicht.
Hab zum testen mal deine XML Definition in mein File geschrieben und im Sketch die Firmware usw angepasst und schon wird nach nem neustart des rfd richtig erkannt.
Irgendwas muss da bei mir noch nicht korrekt sein.
Gab es den as::DeviceType::THSensor schon vorher oder ist das ne neue ID?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 24 Juni 2018, 21:06:33
Aber dein XML Inhalt ist syntaktisch ok?
Hast du den mal durch einen (online) Parser geschickt, um zu schauen, ob nicht irgendwo ein Tag vergessen wurde zu schließen?


Gesendet von iPhone mit Tapatalk
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 24 Juni 2018, 21:15:21
Genau das habe ich gerade getan ...
Natürlich hatte ich irgendwo nen Paramset vom Switch nicht komplett kopiert ...

So nun wirds korrekt angezeigt.
Erste Kanal Rollo und zweite Kanal der Schalter.

Den Fehler mit den vertauschten Kanälen hab ich auch gefunden. War nen Fehler beim registrieren der Kanäle.

Soo, dann muss nur noch die 2. Fernbedienung für die Markise kommen ...

@papa: Die Katzenklappe läuft immer noch einwandfrei. Scheinbar haben sich unsere Mühen bei der Initialisierung des Funkmoduls gelohnt.

EDIT: Mir ist gerade aufgefallen, dass man beim Kanal 2 noch keine Parameter einstellen kann.
Brauche das jetzt nicht zwingend aber wenns nur nen kleiner Fehler ist, sollte sich das ja schnell beheben lassen.
Titel: ThreeState.h Unsauberkeit
Beitrag von: Franki am 25 Juni 2018, 08:36:46
Hallo papa,

ich habe eine kleine "Unsauberkeit" in ThreeState.h gefunden.
Verwendet man diese Bibliothek für Taster oder Sensoren mit open collector Ausgang, die beide gegen GND schalten, zieht die Schaltung kurzzeitig (ca 20µs) einen Strom von ca. 30mA.
Der Grund liegt darin dass der Sensorpin zuerst in der Routine ReadPin als Eingang mit einem Pullup geschaltet wird, dann der Wert des Pins gelesen wird was ja korrekt ist.
Leider bewirkt dann das Umschalten des Pins als Ausgang dass der Pin kurzzeitig (bis zum nächsten Kommando) auf High geht wodurch sich eine niederohmige Verbindung zwischen dem Pin und GND ergibt wenn der externe Sensor (Schalter) auf GND schaltet.
Abhilfe ist einfach: Vor dem Umschalten des Pins auf Ausgang noch ein "pinMode(pinnr,INPUT);" einfügen, in diesem Fall wird der Pin beim Umschalten auf GND gelegt, Problem gelöst, habe ich getestet.

LG

Frank
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 Juni 2018, 08:44:32
Hallo Franki,

Danke für den Hinweis. Kannst Du das ganze gleich mal als PullRequest im GitHub fertig machen ?
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 25 Juni 2018, 09:20:57
Kann man beim generischen Sensor (https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110) auch Register setzen um zum Beispiel die Zeit für den Sendeinterval einzustellen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 Juni 2018, 10:37:41
Zitat von: gloob am 25 Juni 2018, 09:20:57
Kann man beim generischen Sensor (https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110) auch Register setzen um zum Beispiel die Zeit für den Sendeinterval einzustellen?

Gibt es derzeit noch nicht. Kann ich aber mal einbauen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 Juni 2018, 15:57:36
Zitat von: gloob am 25 Juni 2018, 09:20:57
Kann man beim generischen Sensor (https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110) auch Register setzen um zum Beispiel die Zeit für den Sendeinterval einzustellen?
Es gibt jetzt ein Register eventDlyTime im Value-Channel. Dieses enthält die Zeit zwischen 2 Nachrichten. Es wird mit 180s initialisiert. Damit FHEM das Register kennt, muss die HMConfig_AskSinPPCustom.pm aktualisiert und neu geladen werden.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 29 Juni 2018, 17:41:34
Zitat von: papa am 29 Juni 2018, 15:57:36
Es gibt jetzt ein Register eventDlyTime im Value-Channel. Dieses enthält die Zeit zwischen 2 Nachrichten. Es wird mit 180s initialisiert. Damit FHEM das Register kennt, muss die HMConfig_AskSinPPCustom.pm aktualisiert und neu geladen werden.

Sehr gut. Damit kann ich meinen Temperatursensor und den Ultraschallsensor jetzt fertig machen. Wobei es beim Ultraschallsensor wichtiger ist, da möchte man zum Einstellen ein kurzes und später ein großes Intervall haben will.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 04 Juli 2018, 22:29:19
Customsensor mit Temperatur, Luftfeuchtigkeit und Batteriespannung funktioniert. Der Zeitintervall lässt sich auch einstellen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 Juli 2018, 23:02:33
Zitat von: gloob am 04 Juli 2018, 22:29:19
Customsensor mit Temperatur, Luftfeuchtigkeit und Batteriespannung funktioniert. Der Zeitintervall lässt sich auch einstellen.
Super - danke für die Rückmeldung
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 05 Juli 2018, 15:05:54
Zitat von: papa am 04 Juli 2018, 23:02:33
Super - danke für die Rückmeldung

Kann es sein, dass das Updateinterval erst nach einem "Reset/Neustart" des Sensors übernommen wird?
Und wofür braucht es das "max" auf 15 Sekunden?

uint8_t delay = max(15,this->getList1().eventDelaytime());

Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 Juli 2018, 15:15:48
Zitat von: gloob am 05 Juli 2018, 15:05:54
Kann es sein, dass das Updateinterval erst nach einem "Reset/Neustart" des Sensors übernommen wird?
Nein, aber der gerade aktive Delay wird noch abgewartet - also wenn es 2 Minuten waren und Du auf 30 Sekunden änderst, musst Du maximal nochmal die 2 Minuten warten, dann wird beim nächsten Zyklus auf die 30 Sekunden gewechselt.
Zitat von: gloob am 05 Juli 2018, 15:05:54
Und wofür braucht es das "max" auf 15 Sekunden?
uint8_t delay = max(15,this->getList1().eventDelaytime());
Damit der Sensor nicht den gesamten Funkverkehr blockiert. Wahrscheinlich müsste man noch länger warten - 1% Regel (https://wiki.fhem.de/wiki/1%25_Regel)
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 05 Juli 2018, 15:16:41
Das klingt beides Plausibel. Vielen Dank.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 05 Juli 2018, 16:26:39
Zitat von: papa am 05 Juli 2018, 15:15:48Damit der Sensor nicht den gesamten Funkverkehr blockiert. Wahrscheinlich müsste man noch länger warten - 1% Regel (https://wiki.fhem.de/wiki/1%25_Regel)

Ich hab das auch mal durchgerechnet.
Ein Telegramm mit maximaler Länge (17 Byte Payload) (ohne Burst, ohne AES) dauert 30ms.
1% einer Stunde hat 36 Sekunden bzw. (36 * 1000ms) / (30ms / Telegramm) = 1200 Telegramme je Stunde oder halt auch alle 3 Sekunden ein Telegramm.
Alles bezogen auf 1x ausgesendete Messages (bei BIDI: Erfolg beim 1. Versuch).
Arbeitet man allerdings mit (bis zu 10) Wiederholungen bei Fehlschlägen, dann hat man u.U. schon 30 Sekunden voll.

Bei Burst kommen noch mal 360ms oben drauf und bei AES auch noch mal ~250ms.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 06 Juli 2018, 10:47:06
Ist die Größe einer Message z.B. beim Universalsensor eigentlich begrenzt?

// add battery voltage
msg.add(device().battery().current());

// add temperature value
msg.add(sht10.temperature());

// add humidity value
msg.add(sht10.humidity());

...


Ich würde im Moment gerne folgende Werte schicken:

Temperature: int16_t
Humidity: uint8_t
Brightness: uint32_t
BatteryVoltage: uint8_t
Distance: uint32_t


Allerdings können da gerne noch schnell ein paar dazu kommen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 06 Juli 2018, 11:29:29
Zitat von: gloob am 06 Juli 2018, 10:47:06
Ist die Größe einer Message z.B. beim Universalsensor eigentlich begrenzt?

Ich habe bei mir im HB-UNI-Sensor1.ino in Message::init(..) diesen Kommentar drin, den ich irgendwo gelesen hatte, weiß leider nicht mehr genau woher und wie glaubwürdig die Info ist:
// max. msg length 0x19 ?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 06 Juli 2018, 11:40:35
Die maximale Länge eines Telegramm beträgt 26 Byte, wovon bis zu 17 Byte Nutzdaten sein können.

Der Aufbau ist grob dargestellt:
LENGTH(1) - MSGCOUNTER(1) - CONTROL(1) - FRAMETYPE(1) - SENDER(3) - RECEIVER(3) - PAYLOAD(1-17)
Wobei das erste Byte "LENGTH" nicht mit in die Telegrammlänge eingerechnet wird.


Sehr interessante Detailinformationen gibt es beim CCC: https://media.ccc.de/v/30C3_-_5444_-_en_-_saal_g_-_201312301600_-_attacking_homematic_-_sathya_-_malli
Sowie zur Staffelung des Sendeverhaltens hier: https://www.youtube.com/watch?v=uAyzimU60jw
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 06 Juli 2018, 14:54:02
Sehr interessante Videos.
Beim 2. Video ist bei ca. 10 min die max. payload von 17 Bytes erwähnt.

Die Message Length im ersten Parameter bei papas Message::init() Funktion müsste sich m.E. so berechnen:
11 + payload
hier ist der overhead 11 Bytes im Gegensatz zu den 9/10 Bytes aus
ZitatLENGTH(1) - MSGCOUNTER(1) - CONTROL(1) - FRAMETYPE(1) - SENDER(3) - RECEIVER(3)
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Juli 2018, 10:32:04
Soo, hab jetzt endlich die Fernbedienung da.
Soweit funktioniert auch alles allerdings ist mir aufgefallen, dass wenn der Aktor meint, dass das Rollo zu 100% auf bzw komplett unten ist, dann löst er nicht mehr aus.
Bei den originalen Aktoren ist es so, dass sie sich trotzdem noch für ne Sekunde oderso einschalten, damit man mögliche Fehler in der Position des Rollos beheben kann.

Wie schaut es eigentlich mit Kalibrierungsfahrten aus?
Kann man das auch schon einstellen bzw. fährt er bei kompletten zu Ständen also komplett Auf/Zu, etwas länger um mögliche Fehler bei der Position zu korrigieren?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Juli 2018, 18:23:56
Zitat von: Xent am 07 Juli 2018, 10:32:04
Soo, hab jetzt endlich die Fernbedienung da.
Soweit funktioniert auch alles allerdings ist mir aufgefallen, dass wenn der Aktor meint, dass das Rollo zu 100% auf bzw komplett unten ist, dann löst er nicht mehr aus.
Bei den originalen Aktoren ist es so, dass sie sich trotzdem noch für ne Sekunde oderso einschalten, damit man mögliche Fehler in der Position des Rollos beheben kann.
Das sollte eigentlich genau so funktionieren. Habe das aber bisher bur mit den internen Tastern probiert. Kann sein, dass es bei der Fernbedienung noch Probleme gibt.
Zitat von: Xent am 07 Juli 2018, 10:32:04
Wie schaut es eigentlich mit Kalibrierungsfahrten aus?
Kann man das auch schon einstellen bzw. fährt er bei kompletten zu Ständen also komplett Auf/Zu, etwas länger um mögliche Fehler bei der Position zu korrigieren?
Die Fahrzeit wird über die Register refRunningTimeButtonTop bzw. refRunningTimeTopButton eingestellt.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Juli 2018, 21:19:31
Das ist mir klar, dass die Zeiten damit eingestellt werden.
In der CCU kann man aber einstellen dass nach x Fahrten wo nur eine bestimmte Position angefahren wurde, eine Kalibrierungsfahrt gemacht wird und alle kompletten fahrten also 0% oder 100% auch als Kalibrieringsfahrt gelten.
Also müssten diese ja etwas länger als normal ausfallen, damit kleine Fehler behoben werden.


Ich werd mal nen internen Taster testen und schauen ob dann was gesendet wird.
Per Funk bekomme ich zwar ne Rückmeldung geschickt, aber es wird nichts ausgelöst.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Juli 2018, 21:46:36
Zitat von: Xent am 07 Juli 2018, 21:19:31
Das ist mir klar, dass die Zeiten damit eingestellt werden.
In der CCU kann man aber einstellen dass nach x Fahrten wo nur eine bestimmte Position angefahren wurde, eine Kalibrierungsfahrt gemacht wird und alle kompletten fahrten also 0% oder 100% auch als Kalibrieringsfahrt gelten.
Also müssten diese ja etwas länger als normal ausfallen, damit kleine Fehler behoben werden.
Ach das meinst Du - das ist nicht implementiert. Müsste man mal schauen, wo das gut einzubauen geht.
Zitat von: Xent am 07 Juli 2018, 21:19:31
Ich werd mal nen internen Taster testen und schauen ob dann was gesendet wird.
Per Funk bekomme ich zwar ne Rückmeldung geschickt, aber es wird nichts ausgelöst.
Schau mal in Blind.h BlindStateMachine::calcDriveTime wird sichergestellt, dass mindestens 2 Sekunden gefahren wird. Also wenn der State Change von On -> nach DelayOn und weiter nach RampOn kommt, wird immer mindestens 2 Sekunden gefahren. Schau die mal die Register an, ob er auch in ON-State beim Tastendruck nach DelayOn geht.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Juli 2018, 22:38:50
Soo, habe nun denke ich nen Fix dafür gefunden.
Wenn ich in der Zentrale auf oder ab drücke, dann wird das level entweder auf 0 oder 200 gesetzt.
Wenn es aber laut Aktor schon 0 ist, wird nichts in der Funktion setDestLevel ausgelöst.

Habe nun eingebaut, dass er bei kompletten Fahrten trotzdem auslöst.
Dann fährt er die 2 Sekunden die du angesprochen hast.

void setDestLevel (uint8_t value) {
    destlevel = value;
    if( destlevel > level || level == 200 ) {
      setState(AS_CM_JT_ONDELAY, 0);
    }
    else if ( destlevel < level || level == 0) {
      setState(AS_CM_JT_OFFDELAY, 0);
    }
  }



https://www.elv.de/faq/homematic-rollladenschalter-kalibrierfahrt.html
https://www.elv.de/topic/frage-zu-homematic-rollladen-jalousie-aktor-hm-lc-bl1-fm-funk-rollladenaktor-1fach-unterputzmontage.html
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 08 Juli 2018, 11:17:50
Hab gerade bemerkt, dass ich nen Fehler drin hatte ...

void setDestLevel (uint8_t value) {
    destlevel = value;
    if( destlevel > level || destlevel == 200 ) {
      setState(AS_CM_JT_ONDELAY, 0);
    }
    else if ( destlevel < level || destlevel == 0) {
      setState(AS_CM_JT_OFFDELAY, 0);
    }
  }



Irgendwie klappt da konfigurieren auch noch nicht so recht.
Könnte am XML liegen, da scheinbar noch nicht mal was von der CCU gesendet wird.
Es wird die ganze Zeit nur der Ladebalken für "Daten werden übertragen" angezeigt und der Schalter lässt sich inder GUI nicht konfigurieren.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Juli 2018, 20:15:29
Zitat von: Xent am 08 Juli 2018, 11:17:50
Hab gerade bemerkt, dass ich nen Fehler drin hatte ...

void setDestLevel (uint8_t value) {
    destlevel = value;
    if( destlevel > level || destlevel == 200 ) {
      setState(AS_CM_JT_ONDELAY, 0);
    }
    else if ( destlevel < level || destlevel == 0) {
      setState(AS_CM_JT_OFFDELAY, 0);
    }
  }

Baue ich demnächst mal ein
Zitat von: Xent am 08 Juli 2018, 11:17:50
Irgendwie klappt da konfigurieren auch noch nicht so recht.
Könnte am XML liegen, da scheinbar noch nicht mal was von der CCU gesendet wird.
Es wird die ganze Zeit nur der Ladebalken für "Daten werden übertragen" angezeigt und der Schalter lässt sich inder GUI nicht konfigurieren.
Hm - sollte aber gehen. Hast Du mal den "einfachen" probiert ? Mit der CCU kann ich halt nicht testen. Aber hier (https://homematic-forum.de/forum/viewtopic.php?f=76&t=43917) wurde das ganz auch schon mal erfolgreich benutzt. Im Zweifel mit reseten und neu anlernen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 08 Juli 2018, 20:53:50
Bin gerade dabei den simulierten Buttondruck per Alarm wieder zu deaktivieren.
Beim Switch funktioniert es so wie es aktuell eingebaut ist.
Wenn ich aber das Rollo fahren lasse kommt bei der Ausgabe nur:

-> 0C 0C A0 11 473071 5932AF 02 01 00  - 28121
Swit


Und der Arduino ist quasi abgestürzt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Juli 2018, 21:22:02
Ich verstehe zwar nicht, was Du da vor hast, aber das Problem konnt mit hoher Wahrscheinlichkeit von async(true)
  btnAlarm () : Alarm(0) { async(true); }
  virtual void trigger (AlarmClock& clock) {

Das bedeutet, dass der Alarmcode tigger() direkt im Timer-Interrupt aufgerufen wird. Da kann es dann schnell mal zu einem Stack-Overflow kommen. Ohne async(true) wird der Alarm nur in die ReadyListe umgehängt und dann im normalen loop() synchron zum Hauptprogramm ausgeführt. Da kann man dann auch aufwendige Sachen im Alarm machen.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 08 Juli 2018, 21:34:40
Ich steuer die Markiese über die originale Fernbedienung und der Arduino drück quasi nur die Tasten auf der Fernbedienung.
Daher muss die Taste für ne gewisse Zeit gedrückt sein.

Das mit dem async hatte ich von meiner Katzenklappe übernommen.
Hab das async auf false gesetzt und auch ganz entfernt, es passiert immer noch.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Juli 2018, 21:49:07
Mach mal nen sysclock.cancel(_btnAlarm); vor dem _btnAlarm.set(millis2ticks(200));
          sysclock.add(_btnAlarm);
. Damit wird ein eventuell noch aktiver Alarm deativiert.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 08 Juli 2018, 22:27:13
Super funktioniert nun.
Muss jetzt noch das Timing richtig einstellen.
Titel: Antw:AskSin++ Library
Beitrag von: Benni am 13 Juli 2018, 07:07:13
Zitat von: papa am 20 Mai 2018, 22:39:42
Es gibt in examples/custom/HB-GEN-SENS (https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/HB-GEN-SENS) einen generischen Sensor, der Temperatur & Luftfeuchtigkeit sendet. Damit er in FHEM funktioniert, muss das Module HMConfig_AskSinPPCustom.pm (https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM) installiert werden - einfach in das FHEM Verzeichnis kopieren.

Hallo papa,

ich habe bei mir gestern einen Ultraschallsensor (https://forum.fhem.de/index.php/topic,89293.msg817685.html#new) mit der Library als generischen Sensor eingebunden. Das funktioniert auch alles soweit hervorragend, allerdings erhalte ich bei jedem Event des Sensors die Meldung


HB-GEN-SENS01 has 2 values (0102012920)


Ich habe mir jetzt mal den Code in der HMConfig_AskSinPPCustom.pm angeschaut und anscheinend ist dafür die Log-Anweisung in Zeile 201


Log 1, $model.$chnnum." has $numval values ($p)";


verantwortlich. Wenn ich es richtig verstanden habe handelt es sich dabei doch nicht um eine Fehlermeldung sondern lediglich um eine Debug-Ausgabe, die für den Produktiveinsatz weg könnte.

Da die Ausgabe nicht Device-spezifisch mit Log3 sondern mit Log (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Logging) erfolgt kann ich das leider auch nicht einfach per "attr <Device> verbose 0" unterdrücken, sondern müsste dazu das global-Device komplett stumm schalten.

Vielleicht kannst du das bei Gelegenheit anpassen?

Ich habe bei mir die Zeile jetzt erst mal auskommentiert, damit ich Ruhe habe.

Gruß Benni.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Juli 2018, 10:41:19
Das ist richtig - ist nur eine Debug-Ausgabe. In dem Modul sind noch mehr drin.
Wie müsste es denn richtig sein? Perl und Modul-API sind nicht so meine Stärke.
Titel: Antw:AskSin++ Library
Beitrag von: Benni am 13 Juli 2018, 11:00:59
Idealerweise sollten solche Ausgaben, wenn möglich direkt an das jeweilige, betreffende Device gebunden sein (Log3 (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Logging) hatte ich ja oben schon mal verlinkt) so dass ich das einzelne Device bei Bedarf in seiner Geschwätzigkeit (verbose-Stufe) per attribut verbose (am Device) hoch- bzw. runter drehen kann.

verbose 1 und 2 sind normalerweise für Fehlermeldungen (je nach schwere: 1 schwerer als 2)
verbose 3 ist für Standard (Info-) Meldungen, die das Modul im Normalbetrieb ausgeben soll
verbose 4 und 5 wird i.d.R. für unterschiedlich tiefe (5 tiefer als 4) Debugging-Meldungen verwendet.

Die oben genannte Meldung wäre also eher eine für Kategorie 4

Gruß Benni.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Juli 2018, 14:28:10
Und was ist jetzt $name - das Device oder der Channel ?
Titel: Antw:AskSin++ Library
Beitrag von: Benni am 13 Juli 2018, 14:56:40
Zitat von: gloob am 13 Juli 2018, 14:48:17
Da darfst du entscheiden, was du rein schreibst. Ich würde jetzt den Namen des Device nehmen.

Ja das sollte unbedingt der Name des Device sein, denn nur so erreicht man das, was ich oben schon geschrieben habe.
Wenn es kein Device-Name ist, hätte sich im Vergleich zum bisher verwendeten Log nichts verbessert, dann würde hier auch nur die verbose-Einstellung des  global-Device angezogen werden.


Sorry, nochmal die Frage gelesen und kann auch nur sagen, die Entscheidung obliegt dir, ob du hier den Namen des Chanels einträgst oder des Device, je nachdem, wer die Meldung quasi auslöst.
Im zweifelsfall würde ich aber dennoch zum Device tendieren.

Gruß Benni.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 15 Juli 2018, 13:53:58
So, hier nochmal eine verbesserte Version von meinem Markiesenaktor.
Leider klappt das konfigurieren der Kanäle über die GUI immer noch nicht.
Der Schaltkanal wird als nicht konfigurierbar angezeigt und der Rollo-Kanal lässt sich nicht konfigurieren, sprich wenn man auf Speichern klickt, dann kommt der Ladebalken aber sonst passiert nichts mehr.
Am Aktor selber kommen auch keine Daten an.


Habe die Zeiten jetzt immer direkt im Sketch definiert, da es über die GUI nicht ging.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 Juli 2018, 22:35:53
Ich glaub ich hab das Problem behoben weswegen sich der Aktor nicht konfigurieren ließ.
Ich hatte einen Fehler beim hinzufügen des neues Gerätes in die CCU2 gemacht. Eine Datei enthielt einen Fehler.

Jetzt noch was anderes zu den Alarmen.

Hier habe ich einen Alarm gesetzt der dafür sorgt, dass die UP-Taste für 400ms gedrückt bleibt:
btnOff - 22595
UP - 22597
<- 0E 04 A2 10 5932AF 473071 06 01 00 50 58  - 22630
-> 0A 04 80 02 473071 5932AF 00  - 22755
waitAck: 01
btnOff - Alarm - 22994


Jetzt sollte danach zum Stoppen der fahrt das gleiche mit dem Stopp-Button passieren:
btnOff - 23312
STOP - 23312
btnOff - Alarm - 23322
<- 0E 05 A2 10 5932AF 473071 06 01 0A 00 58  - 23463
-> 0A 05 80 02 473071 5932AF 00  - 23588
waitAck: 01

Wie man sieht wurde der Alarm schon 10 ms nach dem er gesetzt wurde ausgelöst wurde.

Hier der Code der die Buttons drückt usw.

virtual void switchState(uint8_t oldstate,uint8_t newstate) {
    BaseChannel::switchState(oldstate, newstate);
    btnOff();
   
    if( newstate == AS_CM_JT_RAMPON ) {
      moving = true;
      motorUp();
      DPRINT("UP - "); DDECLN(millis());
    }
    else if( newstate == AS_CM_JT_RAMPOFF ) {
      moving = true;
      motorDown();
      DPRINT("DOWN - "); DDECLN(millis());
    }
    else {
      if(!moving)
        return;
       
      moving = false;
      motorStop();
      DPRINT("STOP - "); DDECLN(millis());
    }
  }
 
  void motorUp () {
    pinMode(motorUp_PIN, OUTPUT);
    digitalWrite(motorUp_PIN,LOW);

    sysclock.cancel(_btnAlarm);
    _btnAlarm.set(millis2ticks(400));
    sysclock.add(_btnAlarm);
  }

  void motorDown () {
    pinMode(motorDown_PIN, OUTPUT);
    digitalWrite(motorDown_PIN,LOW);

    sysclock.cancel(_btnAlarm);
    _btnAlarm.set(millis2ticks(400));
    sysclock.add(_btnAlarm);
  }

  void motorStop () {
    pinMode(motorStop_PIN, OUTPUT);
    digitalWrite(motorStop_PIN,LOW);
   
    sysclock.cancel(_btnAlarm);
    _btnAlarm.set(millis2ticks(400));
    sysclock.add(_btnAlarm);
  }

  void btnOff(){
    DPRINT("btnOff - "); DDECLN(millis());
    pinMode(motorStop_PIN, INPUT);
    digitalWrite(motorStop_PIN, HIGH);
    pinMode(motorUp_PIN, INPUT);
    digitalWrite(motorUp_PIN, HIGH);
    pinMode(motorDown_PIN, INPUT);
    digitalWrite(motorDown_PIN, HIGH);
    pinMode(light_PIN, INPUT);
    digitalWrite(light_PIN, HIGH);
  }
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Juli 2018, 22:49:04
Warum rufst Du bntOff() am Anfang von switchState() auf? Könnte hier das Problem sein?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 16 Juli 2018, 22:50:24
Das ist ne andere Funktion nur um sicherzustellen, dass kein anderer Button gedrückt ist, da die Fernbedienung immer nur einen registrieren kann.

der btnAlarm hat ja ne eigene Klasse:
class btnAlarm : public Alarm {
public:
  btnAlarm () : Alarm(0) { async(false); }
  virtual void trigger (AlarmClock& clock) {
    DPRINT("btnOff - Alarm - "); DDECLN(millis());
    pinMode(motorStop_PIN, INPUT);
    digitalWrite(motorStop_PIN, HIGH);
    pinMode(motorUp_PIN, INPUT);
    digitalWrite(motorUp_PIN, HIGH);
    pinMode(motorDown_PIN, INPUT);
    digitalWrite(motorDown_PIN, HIGH);
    pinMode(light_PIN, INPUT);
    digitalWrite(light_PIN, HIGH);
  }
};
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Juli 2018, 18:44:56
Das ist komisch - kannst Du mal den ganzen Code zeigen ?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 17 Juli 2018, 20:28:36
Hier bitte.
Was auch nicht funktioniert ist das konfigurieren des Tasters für den Lichtschalter.
Vermutlich ist das auch noch nen Fehler im Sketch bei der Registrierung des Buttons.
Das war zumindest bei dem Rolladenbuttons das Problem.

Eigentlich sind alle 3 Funktionen identisch aufgebaut.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Juli 2018, 20:42:10
Mit dem XML kann ich Dir nicht helfen. Und wo ist der Source-Code ?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 17 Juli 2018, 22:43:03
Ach mist, hab die falsche Datei erwischt ...
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Juli 2018, 18:30:13
Hm - könnte es sein, dass da der Aalrm von Sswitch-Channel noch in der Queue? Kannst Du da den Alarm einfach mal rausmachcen und dann mal schauen, ob der im BlindChannel dann ordentlich funktioniert.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 18 Juli 2018, 22:07:23
Hab jetzt noch eingebaut, dass der Alarm abgebrochen wird bevor ein neuer durch den Switch ausgelöst wird, aber das bringt auch nichts.

Hier mal das komplette Log.
Das erste OFF kommt vom Switchkanal.

AskSin++ V3.1.0 (Jul 18 2018 22:01:19)
Address Space: 32 - 729
CC init1
CC Version: 14
- ready

OFF

Activate Cycle Msg
<- 1A 01 80 00 5932AF 473071 21 F0 05 70 61 70 61 35 39 33 32 61 66 30 02 01 01  - 2015
btnOff - Alarm - 2017
<- 0E 02 A2 10 5932AF 473071 06 01 00 00 00  - 2103
-> 0A 01 80 02 473071 5932AF 00  - 2138
waitAck: 00
<- 0E 02 A2 10 5932AF 473071 06 01 00 00 00  - 2744
-> 0A 02 80 02 473071 5932AF 00  - 2871
waitAck: 01
<- 0E 03 A2 10 5932AF 473071 06 02 00 00 5F  - 2904
-> 0A 03 80 02 473071 5932AF 00  - 3028
waitAck: 01

-> 0B 88 A4 40 3B198C 5932AF 04 46  - 22196
<- 0E 88 80 02 5932AF 3B198C 01 01 00 40 64  - 22315
btnOff - 22712
DOWN - 22714
<- 0E 04 A2 10 5932AF 473071 06 01 00 60 64  - 22747
-> 0A 04 80 02 473071 5932AF 00  - 22874
waitAck: 01
btnOff - Alarm - 23103

btnOff - 23369
STOP - 23371
btnOff - Alarm - 23386
<- 0E 05 A2 10 5932AF 473071 06 01 00 00 5E  - 23422
-> 0A 05 80 02 473071 5932AF 00  - 23549
waitAck: 01
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 18 Juli 2018, 22:21:31
Komischerweise scheint es auch mal zu funktionieren und dann wieder nicht.

Beim ersten mal funktioniert der Alarm beim zweiten mal löst er fast sofort aus.
Beim zweiten Drücken scheint auch nen kleines Kommunikationsproblem mit der Zentrale dagewesen zu sein.

-> 0B 8D A4 40 3B198C 5932AF 04 4B  - 28063
<- 0E 8D 80 02 5932AF 3B198C 01 01 00 40 6E  - 28188

btnOff - 28583
DOWN - 28585
<- 0E 0A A2 10 5932AF 473071 06 01 00 60 6E  - 28620
-> 0A 0A 80 02 473071 5932AF 00  - 28745
waitAck: 01
btnOff - Alarm - 28977
<- 0E 0B A2 10 5932AF 473071 06 01 00 60 51  - 29276
-> 0A 0B 80 02 473071 5932AF 00  - 29401
waitAck: 01
btnOff - 29411
STOP - 29413
btnOff - Alarm - 29804
<- 0E 0C A2 10 5932AF 473071 06 01 00 00 57  - 29927
-> 0A 0C 80 02 473071 5932AF 00  - 30052
waitAck: 01


-> 0B 8E A4 40 3B198C 5932AF 04 4C  - 30558
<- 0E 8E 80 02 5932AF 3B198C 01 01 00 40 6F  - 30685
btnOff - 31072
DOWN - 31074
<- 0E 0D A2 10 5932AF 473071 06 01 00 60 5C  - 31109
waitAck: 00
<- 0E 0D A2 10 5932AF 473071 06 01 00 60 5C  - 31748
waitAck: 00
<- 0E 0D A2 10 5932AF 473071 06 01 00 60 5C  - 32387
-> 0A 0D 80 02 473071 5932AF 00  - 32512
waitAck: 01
btnOff - Alarm - 32514
btnOff - 33007
STOP - 33009
btnOff - Alarm - 33024
<- 0E 0E A2 10 5932AF 473071 06 01 00 00 54  - 33062
-> 0A 0E 80 02 473071 5932AF 00  - 33187
waitAck: 01


EDIT:
Habe jetzt noch nen paar Versuche unternommen und meistens wird der Alarm nun korrekt ausgeführt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Juli 2018, 22:30:51
Kannst Du bitte mal die folgende Zeile raus nehmen:
    hal.activity.savePower<Idle<> >(hal);
Mal sehen, ob das was mit dem Sleep/Idle zu tun hat.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 19 Juli 2018, 21:01:37
Scheint nun besser zu laufen.
Konnte ich zumindest nicht mehr reproduzieren.

Siehste vielleicht noch nen Grund warum ich den Switchkanal nicht konfigurieren kann?
Hab ich da was falsch gemacht?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 Juli 2018, 22:33:22
Zitat von: Xent am 19 Juli 2018, 21:01:37
Scheint nun besser zu laufen.
Konnte ich zumindest nicht mehr reproduzieren.
Mist - das sollte im Idle eigentlich nicht passieren. Muss ich mal bei Gelegenheit nochmal drauf sehen.
Zitat von: Xent am 19 Juli 2018, 21:01:37
Siehste vielleicht noch nen Grund warum ich den Switchkanal nicht konfigurieren kann?
Hab ich da was falsch gemacht?
Kann ich machen - aber kann etwas dauern.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 21 Juli 2018, 22:19:47
Könnte es sein, dass ich/wir einen Denkfehler bei den Millis Ausgaben und dem aktiven PowerSave hatten?
Laufen die in diesem Modus weiter oder sind die pausiert?
Das würde erklären weswegen der Alarm scheinbar direkt nach dem aktivieren ausgelöst wurde.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 22 Juli 2018, 11:38:13
Moin!

Ich habe zurzeit ein kleines Problem mit ThreeState-Sketchen, wie z.B. dem RHS.
Wenn ich 3.3V anlege, verbraucht die Schaltung im Sleep-Zustand ~11µA.
Sinkt die Spannung < 3.3V (es fängt direkt ab 3.2V an), steigt der Stromverbrauch immens an und liegt dann bei 2,3mA!

Hat das was mit dem Pin-Polling zu tun? Kann das jemand nachvollziehen? Bin etwas ratlos. ???
BOD am 328P habe ich deaktiviert.

Btw.: Flashe ich bspw. einen WDS-TH-O, liegt der Verbauch auch bei sinkender Spannung bei konstant ~4µA.

VG,
JP
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 22 Juli 2018, 12:40:51
Zitat von: jp112sdl am 22 Juli 2018, 11:38:13
Moin!

Ich habe zurzeit ein kleines Problem mit ThreeState-Sketchen, wie z.B. dem RHS.
Wenn ich 3.3V anlege, verbraucht die Schaltung im Sleep-Zustand ~11µA.
Sinkt die Spannung < 3.3V (es fängt direkt ab 3.2V an), steigt der Stromverbrauch immens an und liegt dann bei 2,3mA!

Hat das was mit dem Pin-Polling zu tun? Kann das jemand nachvollziehen? Bin etwas ratlos. ???
BOD am 328P habe ich deaktiviert.

Btw.: Flashe ich bspw. einen WDS-TH-O, liegt der Verbauch auch bei sinkender Spannung bei konstant ~4µA.

VG,
JP

Du meinst du flashst *dieselbe* HW mit WDS-TH-O und hast bei 3,2V nicht das Problem?
Battery critical Schwelle richtig gesetzt?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 22 Juli 2018, 12:46:06
Zitat von: Tom Major am 22 Juli 2018, 12:40:51
Du meinst du flashst *dieselbe* HW mit WDS-TH-O und hast bei 3,2V nicht das Problem?

Sorry - ja genau, hab mich wohl nicht eindeutig ausgedrückt.

Zitat von: Tom Major am 22 Juli 2018, 12:40:51
Battery critical Schwelle richtig gesetzt?

Critical ist bei 1,9V, Low bei 2,2V.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 22 Juli 2018, 12:51:15
ok, dann wird ein HW Problem unwahrscheinlicher, aber noch nicht ganz ausgeschlossen.  ;)
Funktioniert der RHS bei 3,2V trotzdem noch korrekt?
Wie sieht die Eingangsschaltung für die pin Abfrage aus?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 22 Juli 2018, 13:04:44
Zitat von: Tom Major am 22 Juli 2018, 12:51:15
ok, dann wird ein HW Problem unwahrscheinlicher, aber noch nicht ganz ausgeschlossen.  ;)
Habe es mit 3 verschiedenen Pro-Mini Boards getestet und im Sleep auch mal den Vcc vom CC1101 getrennt, um diesen als Stromfresser auszuschließen.
LDO ist natürlich von den Pro-Mini-Boards auch entfernt.  ;)

Zitat von: Tom Major am 22 Juli 2018, 12:51:15
Funktioniert der RHS bei 3,2V trotzdem noch korrekt?
Ja, er funktioniert einwandfrei, auch noch bei 2,0 V. Nur die Batterien halten nicht sehr lange...  8)
Das war mir aufgefallen, weshalb ich der Sache mal auf den Grund gehen wollte.
Bei 2V sinkt die Stromaufnahme dann auf 1,4mA. Sie fällt also proportional zur VCC.

Zitat von: Tom Major am 22 Juli 2018, 12:51:15
Wie sieht die Eingangsschaltung für die pin Abfrage aus?
Hardwareseitig ist nur ein Reed-Kontakt dran an A3. Aber auch die Verwendung von "echten" Digitalpins z.B. "6" ändert nix.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 22 Juli 2018, 13:20:04
Nach diesen Infos klingt das nach einem relativ seltsamen Problem  >:(
Kannst du mal ein gutes Foto vom Schaltungsaufbau posten oder verlinken?
Ist der Status des Reeds egal für die Stromaufnahme bei 3,2V?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 22 Juli 2018, 13:35:21
Der Aufbau ist eigentlich total unspektakulär.
2x AAA an VCC und GND, das CC1101 ist mit Lackdraht auf der Rückseite des Pro Mini angeheftet.

Den Status des Reeds habe ich gar nicht verändert; der Kontakt war bei meinen Messungen bisher immer "offen".

Ich vermute den "Fehler" (sofern es sich um einen handelt) nicht mal unbedingt in der AskSinPP Lib, sondern eher in der Low-Power Lib.

Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 22 Juli 2018, 17:46:42
Stimmt, relativ unspektakulärer Aufbau  ;)

Kann es sein dass der AVR bei 3,2V nicht mehr in den sleep geht? Die Stromaufnahme legt das nahe. Sehe allerdings aus der Ferne keinen Grund warum er das ab 3,2V nicht mehr tun sollte...

Man könnte in der LowPower bei wake-up und sleep eine LED an/ausmachen um das zu verifizieren, das wäre allerdings nur eine Annäherung an das Problem und noch keine Lösung.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 22 Juli 2018, 17:52:50
Eine weitere Annäherung:
Alle pin Pegel des Pro Mini vergleichen bei 3,3V und 3,2V. Irgendwelche Unterschiede?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 22 Juli 2018, 21:21:42
Zitat von: Tom Major am 22 Juli 2018, 17:52:50
Eine weitere Annäherung:
Alle pin Pegel des Pro Mini vergleichen bei 3,3V und 3,2V. Irgendwelche Unterschiede?

Ich hab mal den Oszi angeschlossen und sehe, egal bei welcher Spannung, dass die Pegel der zu überwachenden Pins L sind und in kurzen Intervallen beim Prüfen kurz einen H-Peak haben.
Die ungenutzten Pins dümpeln bei 0,6V irgendwo umher.

Aber - Trommelwirbel - ich habe die Schaltung neu aufgebaut und einen Pro Mini aus einer anderen Charge (Bestellung) genommen.
Nu gehts! Ich hab noch drei mal alles verglichen. Die Fuses sind identisch, der Sketch ist derselbes.
Ich hab keine Ahnung, was da faul ist!

Kann es am Bootloader liegen? Ich hab nun schon den Bootloader neu gebrannt (der von der Arduino IDE mitkommt), was jedoch keine Besserung brachte.

Im Moment bin ich zufrieden, da der Batteriefresser nun gefixt ist.
Die anderen 3 Boards mit erhöhtem Stromverbrauch markiere ich mit "Netzteil only". ::)

Danke für die Hilfe bei der Fehlersuche!
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 23 Juli 2018, 20:01:06
Glaub nicht das der bootloader der Verursacher sein kann.
Das Problem ist ziemlich seltsam, m.E. könnte es sich lohnen das weiter zu untersuchen da der sleep Strom bei unseren HM devices ziemlich wichtig ist.
Ich habe mal ein SleepTest Sketch gemacht:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SleepTest (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SleepTest)

Der Sketch schickt den CC1101 in den powerdown, und toggelt dann aller 8s zwischen Normal und Sleep, die LED auf dem Board wird auch entsprechend getoggelt.

cc1101_powerdown();
sollte aktiviert werden wenn ein CC1101 angeschlossen ist.

Man müsste dann in einem mA Messbereich den Wechsel zwischen 0 und einigen mA gut sehen können. Das muss auch bei 3,2V funktionieren.
Wenn deine "Netzteil only" Boards keine Unterschiede zur anderen Charge ergeben kann es m.E. nicht an den Boards liegen. Im sleep wird BOD per SW abgeschaltet.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 25 Juli 2018, 20:45:07
So... jetzt hatte ich mal kurz Zeit zum Tüfteln.
Vielen Dank für deinen Test-Sketch.

Also es ist unerheblich, ob 3.3V oder 3.0V - die Stromaufnahme schwankt zwischen 10mA (EIN) und 6mA (SLEEP)....

Lade ich den Sketch auf einen "guten" 328P mit CC1101 komme ich auf 4,8mA (EIN) und 1,7mA (SLEEP)

Keine Ahnung, ob der Stromfresser ein russisches Modell mit Heizdraht ist... irgendwo muss die Energie ja bleiben. ??? :o
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 25 Juli 2018, 23:12:56
Beim "guten" 328P, meinst du da 1,7 Microampere? Sonst muss ich das selber noch mal testen  ;)
LDO ist bei beiden, gut und schlecht, entfernt?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 26 Juli 2018, 06:51:02
Zitat von: Tom Major am 25 Juli 2018, 23:12:56
Beim "guten" 328P, meinst du da 1,7 Microampere? Sonst muss ich das selber noch mal testen  ;)
Nein nein, Milliampere!
Bei meinem Messgerät schließe ich auch aus, dass es falsch misst, denn das Amperemeter am Labornetzteil zeigt auch grob 0,011 / 0,004 A an.
Ist beim powerDown evtl. noch mehr mit anzugeben?

Zitat von: Tom Major am 25 Juli 2018, 23:12:56
LDO ist bei beiden, gut und schlecht, entfernt?
Entfernt beim "schlechten" und bei 2 "guten" hatte ich einen mit LDO und einen ohne LDO. Jedoch fielen die paar zusätzlichen µA bei den mA nicht ins Gewicht.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 29 Juli 2018, 13:06:19
Zitat von: jp112sdl am 26 Juli 2018, 06:51:02
Nein nein, Milliampere!
Bei meinem Messgerät schließe ich auch aus, dass es falsch misst, denn das Amperemeter am Labornetzteil zeigt auch grob 0,011 / 0,004 A an.
Ist beim powerDown evtl. noch mehr mit anzugeben?
Entfernt beim "schlechten" und bei 2 "guten" hatte ich einen mit LDO und einen ohne LDO. Jedoch fielen die paar zusätzlichen µA bei den mA nicht ins Gewicht.

Dann läuft da was schief.. Fuses? (Clock/Xtal), zusätzlich angeschlossene HW? oder es stimmt was mit dem AVR selbst nicht..

Habe den SleepTest Sketch getestet und besser dokumentiert:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SleepTest (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SleepTest)

Macht genau das was er soll.
Mit diesem Sketch (und auf HW bestehend aus Pro Mini und CC1101) muss die Stromaufnahme in etwa zwischen 3mA und 3..4uA toggeln.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 30 Juli 2018, 19:20:28
Hallo,

Ich wollte gerade einen Arduino Pro Mini flashen und bekomme folgenden Fehler im Log:

AskSin++ V3.1.1 (Jul 30 2018 19:18:47)
Address Space: 32 - 73
CAFE993D
Init Storage: CAFE6189
CC init1
Error at 00 expected: 2E read: 00
Error at 02 expected: 06 read: 00
Error at 03 expected: 0D read: 00
Error at 04 expected: E9 read: 00
Error at 05 expected: CA read: 00
Error at 07 expected: 0C read: 00
Error at 0B expected: 06 read: 00
Error at 0D expected: 21 read: 00
Error at 0E expected: 65 read: 00
Error at 0F expected: 6A read: 00
Error at 10 expected: C8 read: 00
Error at 11 expected: 93 read: 00
Error at 12 expected: 03 read: 00
Error at 15 expected: 34 read: 00
Error at 17 expected: 03 read: 00
Error at 18 expected: 18 read: 00
Error at 19 expected: 16 read: 00
Error at 1B expected: 43 read: 00
Error at 21 expected: 56 read: 00
Error at 23 expected: E9 read: 00
Error at 24 expected: 2A read: 00
Error at 25 expected: 1F read: 00
Error at 26 expected: 11 read: 00
Error at 29 expected: 59 read: 00
Error at 2C expected: 81 read: 00
Error at 2D expected: 35 read: 00
Error at 2E expected: 09 read: 00
Error at 3E expected: 03 read: 00
CC Version: 00
Error at 3E expected: C0 rea


Jemand eine Idee, was das sein könnte? Sieht stark danach aus als könnte er den CC1101 nicht ansprechen.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 30 Juli 2018, 19:27:53
Zitat von: gloob am 30 Juli 2018, 19:20:28
Sieht stark danach aus als könnte er den CC1101 nicht ansprechen.
Korrekt!
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 30 Juli 2018, 19:45:20
Zitat von: jp112sdl am 30 Juli 2018, 19:27:53
Korrekt!

Schade. Es scheint als seinen die Gerber Dateien von Alex Reinert defekt:
https://github.com/alexreinert/PCB/tree/master/HB-UNI-SEN-BATT

In der Mitte sieht man schön die Lötpads des CC1101 und dort 3 Leitungen direkt mit der Massefläche verbunden sind

30€ an Platinen für die Tonne.  :(

Edit: Mal schauen ob ich die Bahnen mit dem Cutter-Messer trennen kann.

Edit 2: Ich hab die fehlerhaften Bahne auf der Unterseite getrennt und schon kann der CC1101 und der BME280 korrekt angesprochen werden
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 30 Juli 2018, 22:12:58
Zitat von: gloob am 30 Juli 2018, 19:45:20
Schade. Es scheint als seinen die Gerber Dateien von Alex Reinert defekt:
https://github.com/alexreinert/PCB/tree/master/HB-UNI-SEN-BATT

Es war tatsächlich irgendwas faul mit der Vorlage.
Er hat mir gerade geschrieben, dass er sie gefixt und im Github aktualisiert hat.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 30 Juli 2018, 22:17:28
Zitat von: jp112sdl am 30 Juli 2018, 22:12:58
Es war tatsächlich irgendwas faul mit der Vorlage.
Er hat mir gerade geschrieben, dass er sie gefixt und im Github aktualisiert hat.

Vielen Dank für die Rückmeldung von dir. Hab die Daten jetzt mal bei JLCPCB hochgeladen und dort sieht es jetzt gut aus. Ich werd mal schauen wie ich meine fehlerhaften Platinen trotzdem verwenden kann. Prinzipiell fehlt mir ja nur das Flashen des Bootloaders.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 31 Juli 2018, 20:52:07
Ich habe mich jetzt auch mal an das sehr spannende Thema hier gemacht, zum Test wollte ich mal den 8fach-Temperatursensor mit DS18B20 bauen:

https://github.com/jp112sdl/HB-UNI-Sen-TEMP-DS18B20 (https://github.com/jp112sdl/HB-UNI-Sen-TEMP-DS18B20)

flashen, anlernen usw hat alles funktioniert, nur, wie komme ich jetzt an die Temperaturwerte?
Momentan ist 1 Sensor angeschlossen, unten das was ich ich in FHEM was bekomme:

In FHEM habe ich die HMConfig_AskSinPPCustom.pm reinkopiert

Was brauche ich noch um an die Sensorwerte zu kommen?



CUNO_MSGCNT
19
CUNO_RAWMSG
A16148453F301015885AB00450000460000470000480000::-52.5:CUNO
CUNO_RSSI
-52.5
CUNO_TIME
2018-07-31 20:24:03
DEF
F30101
HMLAN1_MSGCNT
18
HMLAN1_RAWMSG
EF30101,0000,48474A22,FF,FFA8,148453F301015885AB00450000460000470000480000
HMLAN1_RSSI
-88
HMLAN1_TIME
2018-07-31 20:24:03
IODev
HMLAN1
LASTInputDev
CUNO
MSGCNT
37
NAME
HM_F30101
NOTIFYDEV
global
NR
447
NTFY_ORDER
50-HM_F30101
STATE
???
TYPE
CUL_HM
lastMsg
No:14 - t:53 s:F30101 d:5885AB 00450000460000470000480000
protLastRcv
2018-07-31 20:24:03
protRcv
19 last_at:2018-07-31 20:24:03
rssi_at_CUNO
cnt:19 min:-52.5 max:-42 avg:-47.21 lst:-52.5
rssi_at_HMLAN1
cnt:18 min:-93 max:-82 avg:-87.16 lst:-88
Readings
CommandAccepted
yes
2018-07-31 19:49:28
D-firmware
1.0
2018-07-31 20:03:09
D-serialNr
UNITEMP001
2018-07-31 20:03:09
R-pairCentral
set_0x5885AB
2018-07-31 19:49:27
HM_F30101
CUL_HM
Attributes
IODev
HMLAN1
deleteattr
IOgrp
myVCCU:HMLAN1
deleteattr
autoReadReg
4_reqStatus
deleteattr
expert
2_raw
deleteattr
firmware
1.0
deleteattr
model
unknown
deleteattr
room
CUL_HM
deleteattr
serialNr
UNITEMP001
deleteattr
subType
deleteattr
Titel: Antw:AskSin++ Library
Beitrag von: papa am 31 Juli 2018, 21:15:17
Für diesen Gerät existiert nur eine Einbindung in die CCU. Wie viele Temperaturen brauchst Du denn ? 4 Könnte man auch gut mit meinem generischen Sensor (https://github.com/pa-pa/AskSinPP/blob/master/examples/custom/HB-GEN-SENS/HB-GEN-SENS.ino) machen. Der ist durch das AskSinPP_Addon in FHEM unterstützt. Dort müsste nur der SHT10 durch das DS18B20 Array ausgetauscht werden und entsprechend die Nachricht mit Daten gefüttert werden.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 31 Juli 2018, 21:52:58
Danke für Deine schnelle Antwort, 4 Kanäle würden locker reichen, notfalls nehme ich halt mehr Sender.

ZitatDort müsste nur der SHT10 durch das DS18B20 Array ausgetauscht werden und entsprechend die Nachricht mit Daten gefüttert werden.

Da hört es halt bei meinen Kenntnissen auf bzw. wäre was für lange Winterabende und Wochen, bis das läuft

Konkret bräuchte ich einfach schnell einen Sensor mit 1-2 DS18B20 für die Klimaanlage, zukünftig interessant wäre Taster + DHT22 oder ähnlich, könnte man dann für Bewegungsmelder oder als Steuertaster nutzen



Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 August 2018, 12:22:47
Habe im GitHub das generische Example um DS18b20 Unterstützung erweitert. Es muss das USE_DS18B20 Define gesetzt und der ONEWIRE_PIN definiert werden. Es sind 4 Sensoren im Beispiel vorgesehen. Folgende Attribute müssen gesetzt werden:
attr VALUECHANNEL userattr valuesformat
attr VALUECHANNEL valuesformat 2s:Temp1:10 2s:Temp2:10 2s:Temp3:10 2s:Temp4:10

Alles nicht weiter getest - gerade keine passende Hardware da - sollte aber funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 03 August 2018, 21:21:00
Vielen Dank, wollte es gleich mal testen

Leider kommt jetzt beim kompilieren:

HB-GEN-SENS:121: error: 'byteTimeCvtSeconds' is not a member of 'as::AskSinBase'

     set(AskSinBase::byteTimeCvtSeconds(delay));

         ^



EDIT: sorry, habs jetzt, muss die Master nehmen, nicht die Stable

Temperaturen werden angezeigt, vielen Dank :-)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 August 2018, 22:09:15
Du musst die Library aktualisieren.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 07 August 2018, 14:53:40
Wird BOD eigentlich per Software in der Lib deaktiviert oder geht es nur über das Setzen der Fuses?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 August 2018, 15:13:10
Im Sleep ist BOD_OFF gesetzt. Der Flash-Code vom OTA-Bootoader hat den BOD auch aus. Tja - sollte also aus sein.
Nur beim ATMega32 ist er an, da es dort sonst zu Problemen beim Start kommt und der Inhalt des Flash kaputt geht.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 08 August 2018, 12:15:37
Hallo papa,

nachdem nun meine PCBs aus China angekommen sind, habe ich mich ans SMD Löten gemacht und mehrere HM_LC_SW4_SM aufgebaut.

Im HM_LC_SWX_SM Sketch habe ich allen Devices eine andere "Device Serial" gegeben.

Anlernen eines Geräts an der CCU2 GUI funktioniert tadellos. Aber ein Anlernen eines weiteren dieser Geräte ist nicht möglich.

Erst dachte ich, dass noch irgendwo ein Lötfehler steckt, aber nach dem Löschen des ersten Gerätes und erneutem Anlernen des zweiten,
wird dieses auch erkannt. Nur ein Anlernen des jeweils anderen Gerätes als zusätzliches schlägt fehl.Ist es nicht damit getan, im Sketch
unterschiedliche "Device Serial's" zu definieren oder muß an anderer Stelle noch was geändert werden?

Da ich nicht immer 4 Schaltkanäle brauche, habe ich erstmal nur 2 Relais bestückt. Dazu wollte ich es dann auch als HM_LC_SW2_SM ausprägen.
Dazu habe ich im Sketch als "Device Model" HM_LC_SW2_SM eingetragen. Nach dem Anlernen in der GUI erscheint das Gerät zwar in der
Geräteliste, aber als unbekanntes Device. Woran kann das liegen?

VG
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 08 August 2018, 12:43:30
Zur ersten Frage:
Bei mehreren Geräten des gleichen Typs muss Device ID und Device Serial unterschiedlich sein.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 08 August 2018, 15:12:03
ok. Das hat geholfen.
Danke.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 08 August 2018, 19:15:37
Wie würdet Ihr denn den internen AD-Wandler abfragen? Über den Universalsensor? Oder gibts was anderes passendes?
Habe mich mal durch die Kürzel durchgeklickt, aber so auf Anhieb nichts gefunden.

Viele Grüße

Klaus



Titel: Antw:AskSin++ Library
Beitrag von: gloob am 08 August 2018, 19:21:10
Zitat von: Klaus0815 am 08 August 2018, 19:15:37
Wie würdet Ihr denn den internen AD-Wandler abfragen? Über den Universalsensor? Oder gibts was anderes passendes?
Habe mich mal durch die Kürzel durchgeklickt, aber so auf Anhieb nichts gefunden.

Viele Grüße

Klaus

Was willst du denn messen, die Spannung der Batterie?
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 08 August 2018, 19:25:13
Nein, eine externe Spannungsquelle, bzw ja eigentlich schon:
Ich will die Autobatterie meines 2.-Autos überwachen.
Läuft seit ca. 2 Jahren über MySensors, Spannungsteiler, als Versorgung ein Step-Down-Wandler

Nur, dieses MySensors-Zeug nervt mich dermaßen, mal wieder keine Verbindung, irgendwann 3 Gateways installiert, will das alles loshaben und was das einfach nur funktioniert

Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 09 August 2018, 19:11:43
Sorry, muss noch mal fragen:

Verstehe ich es richtig, das man für die vielen verschiedenen Beispiele auf pa-pas Seite eine entsprechende HMConfig_AskSinPPCustom.pm braucht -
Bislang aber nur
-HM-LC-Sw2-FM-CustomFW
-HB-SW2-SEN
-HB-DoorBell
-HB-GEN-SENS

eingebunden sind?

Für die anderen Beispiele bräuchte ich eine CCU, um die Aktoren zu nutzen?

Titel: Antw:AskSin++ Library
Beitrag von: gloob am 09 August 2018, 19:44:28
Du kannst alle Beispiele auf Pa-Pas Github Seite in FHEM einbinden.

Nur der Custom-Sensor (HB-GEN-SENS) benötigt die HMConfig_AskSinPPCustom.pm

Alle anderen verhalten sich wie richtige Homematic Geräte.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 14 August 2018, 07:48:23
Hat jemand eine Idee, wie man folgende Log-Meldungen noch weg bekommt?

2018.08.14 07:43:38 1: HB-GEN-SENS01 has 4 values (010400F52F000000651E)
2018.08.14 07:43:45 1: HB-GEN-SENS01 has 4 values (010400FA2E000000541F)
2018.08.14 07:43:53 1: HB-GEN-SENS01 has 4 values (010400FA2F0000006420)
2018.08.14 07:45:03 1: HB-GEN-SENS01 has 3 values (010300F52F20)
2018.08.14 07:45:57 1: HB-GEN-SENS01 has 2 values (0102065819)
2018.08.14 07:45:58 1: HB-GEN-SENS01 has 4 values (010400F92E000000711A)
2018.08.14 07:46:18 1: HB-GEN-SENS01 has 3 values (010300F52F1E)
.
.
.


Die scheinen von unterschiedlichen Geräten zu kommen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 August 2018, 08:39:14
Die kommen aus der HMConfig_AskSinPPCustom.pm. Da gab es schon mal eine Diskussion zu, das man das Loggen auf Device umstellen muss, damit dann die Einstellungen am Device wirken. Das sind halt noch meine Debug-Ausgaben. Habe auch schon nen Issue (https://github.com/pa-pa/AskSinPP/issues/57) angelegt - nur keine Zeit, mich drum zu kümmern. PullRequests are welcome  ;)
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 14 August 2018, 08:42:06
Zitat von: gloob am 14 August 2018, 07:48:23
Hat jemand eine Idee, wie man folgende Log-Meldungen noch weg bekommt?
Die scheinen von unterschiedlichen Geräten zu kommen.

Entweder das FHEM Attr verbose runtersetzen oder Zeile 215 im HMConfig_AskSinPPCustom.pm auskommentieren, als schnelle Lösung..
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 14 August 2018, 08:48:12
Zitat von: Tom Major am 14 August 2018, 08:42:06
Entweder das FHEM Attr verbose runtersetzen oder Zeile 215 im HMConfig_AskSinPPCustom.pm auskommentieren, als schnelle Lösung..

Genau die Zeile habe ich irgendwie nicht gefunden. Vielen Dank.
Titel: Antw:AskSin++ Library
Beitrag von: Benni am 14 August 2018, 09:59:27
Zitat von: Tom Major am 14 August 2018, 08:42:06
Entweder das FHEM Attr verbose runtersetzen oder Zeile 215 im HMConfig_AskSinPPCustom.pm auskommentieren, als schnelle Lösung..

verbose Funktioniert hier  aber nur, wenn der globale verbose am global-Device auf 0 gesetzt wird. Dann kommt aber quasi gar nix mehr im Log an (von keinem Device). Von daher nicht empfehlenswert.

(s.a. https://forum.fhem.de/index.php/topic,57486.msg818260.html#msg818260)

Einzig sinnvolle Möglichkeit bleibt daher aktuell nur das Deaktivieren der entsprechenden Log-Ausgabe in der genannten Zeile (in diesem Fall wohl 215).


gb#


Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 14 August 2018, 11:48:20
Zitat von: Benni am 14 August 2018, 09:59:27
verbose Funktioniert hier  aber nur, wenn der globale verbose am global-Device auf 0 gesetzt wird. Dann kommt aber quasi gar nix mehr im Log an (von keinem Device). Von daher nicht empfehlenswert.

(s.a. https://forum.fhem.de/index.php/topic,57486.msg818260.html#msg818260)
Einzig sinnvolle Möglichkeit bleibt daher aktuell nur das Deaktivieren der entsprechenden Log-Ausgabe in der genannten Zeile (in diesem Fall wohl 215).

gb#

Ja genau, in papas HMConfig_AskSinPPCustom.pm ist die "alte" Log Funktion mit verbose level 1 (für Fehler usw.) drin.
Besser wäre m.E. statt
Log 1, $model.$chnnum." has $numval values ($p)";
z.B. sowas
Log3($DEVICE, 4, $model.$chnnum." has $numval values ($p)");
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 14 August 2018, 12:09:49
Zitat von: Tom Major am 14 August 2018, 11:48:20
Ja genau, in papas HMConfig_AskSinPPCustom.pm ist die "alte" Log Funktion mit verbose level 1 (für Fehler usw.) drin.
Besser wäre m.E. statt
Log 1, $model.$chnnum." has $numval values ($p)";
z.B. sowas
Log3($DEVICE, 4, $model.$chnnum." has $numval values ($p)");

Scheinbar ist der Device Name aber nicht vergeben:

2018.08.14 12:08:12 1: Error loading file: ./FHEM/HMConfig_AskSinPPCustom.pm:
Global symbol "$DEVICE" requires explicit package name (did you forget to declare "my $DEVICE"?) at ./FHEM/HMConfig_AskSinPPCustom.pm line 215, <$fh> line 532.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 14 August 2018, 12:56:03
Den DEVICE Namen musst Du Dir noch aus den Datenstrukturen rausfriemeln. Schau mal in Zeile 94. Das müsste (wahrscheinlich) der Name sein.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 14 August 2018, 13:11:37
Zitat von: papa am 14 August 2018, 12:56:03
Den DEVICE Namen musst Du Dir noch aus den Datenstrukturen rausfriemeln. Schau mal in Zeile 94. Das müsste (wahrscheinlich) der Name sein.

So wird die Datei immerhin geladen und eingebunden:

Log3(CUL_HM_id2Hash($src)->{NAME}, 4, $model.$chnnum." has $numval values ($p)");

Ich muss nur mal weiter schauen wie man an den richtigen Namen kommt. Aktuell sieht der Log eintrag dann so aus:

2018.08.14 13:09:41 4: HB-GEN-SENS01 has 3 values (010301082A1E)

Verbose muss auch im Haupt-Device (HM_444020) eingestellt werden und nicht im Channel-Device (HM_444020_Values).




Problem für mich gelöst:

        #    2018.04.15 21:56:46 1: HB-GEN-SENS01 has 4 values (090400E82803EB0000)
        #    Log(1, "Values Message for Channel: $chnnum");
        if( $HMConfig::culHmRegChan{$model.$chnnum} == $HMConfig::culHmRegType{values} ) {
            my $chnHash = $modules{CUL_HM}{defptr}{$src.$chnnum};
            my $vfmt = AttrVal($chnHash->{NAME},"valuesformat","");
            Log3($chnHash->{NAME}, 4, $chnHash->{NAME}." has $numval values ($p)");


Jetzt wird das Verbose Level vom Channel Device genommen und der Log-Eintrag macht auch Sinn:

2018.08.14 13:23:43 4: HM_444021_Values has 3 values (0103010C2919)
2018.08.14 13:23:47 4: HM_444022_Values has 3 values (010301092A1B)
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 14 August 2018, 19:49:35
Wäre es nicht mal an der Zeit, hier eine Untergruppe für Asksin++ oder generell Selbstbau-Sensoren/Aktoren einzurichten?
Mittlerweile gibt es zig Themen auf 66 Seiten verteilt, die CCU-Fraktion hat sich selbständig gemacht mit eigenen XML-Dateien im Homemnatic-Forum

Ich finde es sehr spannend, das Thema 230V-Aktoren usw Homematic zu überlassen, Spezialsensoren  hier zu diskutieren und entwickeln, aber alles ist dann kombinierbar

So wie ich es momentan verstehe funktionieren BidCos und AskSin sehr gut zusammen, größere Fehler gab es bislang keine.
Es ist nur etwas schwer, für einen Einsteiger den richtigen Punkt zu finden, vor allem was FHEM angeht, für die CCU finden sich bereits zig gut dokumentierte Nachbauvorschläge im Netz.
Es ist sicher nicht nur ein Thema wo sich eine Hand voll Freaks ihre Sensoren gebaut haben und dann interessiert es niemand mehr

Wie denkt ihr darüber?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 August 2018, 08:46:40
Mehr Dokumentation ist immer gut. Ich versuche den ersten Beitrag immer mal wieder zu akrualisieren und verlinke dort auch Projekte.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 15 August 2018, 21:06:57
Ich frag noch mal ganz frech,habe leider zu wenig Programmier-Erfahrung, vor allem das interrupt-Zeug um aus dem Sleep zu wecken

WIe bekomme ich den Universal-Sensor in folgenden Konfigurationen hin:

- DHT22 + Taster- finde es schön wenn meine Bewegungsmelder usw wenn ssie schon da sind gleich Temperatur mit aussenden

- alternativ, falls einfacher oder schon vorhanden : DS18B20 + Taster

-  Spannung am ADC messen und schicken

Hat so was schon mal jemand gebastelt?

Viele Grüße

Klaus
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 August 2018, 22:05:02
Mir ist jetzt nicht klar, was Du eigentlich willst.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 17 August 2018, 18:41:43
ZitatMir ist jetzt nicht klar, was Du eigentlich willst.

Hallo papa,  sorry wenn es etwas verwirrend war
Was ich bräuchte wäre quasi der Universalsensor zur Temperaturmessung, egal ob DS18B20, DHT22, BME280,...
Und dann zusätzlich ein Taster-Eingang,  dort kann ich dann z.B. einen Bewegunsmelder, einen Türkontakt, ein Taster der irgend eine Aktion auslöst anschließen

Szenario wäre z.B.:
- Habe im Bad (momerntan MySensors) einen Feuchtigkeitsmesser zur Ventilatorsteuerung, zusätzlich ist dort ein Taster um den Ventilator für 5 min anzuschalten

oder

- Auf der Terasse liegt ein Sensor - Temp+Luftfeuchte + Bewegungsmelder

Ich verstehe leider nicht wie ich das hinbekomme, der Sensor ist im deep-sleep, alle 5 min eine Temperatur-Messung, aber für den Taster / Bewegungsmelder muss ich ihn ja per Interrupt aufwecken?

Viele Grüße

Klaus




Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 26 August 2018, 14:57:49
Ich habe heute mal den UniSensor mit BMP280 und TSL2561 nachgebaut. Klappt alles auf Anhieb, inkl Plots. Super, vielen Dank.

Wie kann ich denn / muss ich die Meereshöhe einstellen?

Danke & Gruss
Titel: Antw:AskSin++ Library
Beitrag von: kpwg am 26 August 2018, 18:05:40
Schau mal bei get regList und get regTable, was Du alles siehst. Ist da die Höhe (altitude) dabei?

Ich konnte bei meinem THPL Sensor mit BME280 und MAX44009 über getConfig // Config drücken // set regSet altitude 590 // Config drücken // getConfig // Config drücken die Höhe einstellen. Bitte berichtigt mich, wenn ich da zu viel drücke und mache- so hat es jedenfalls funktioniert  ::)

Ich habe mittlerweile bereits im Sketch die Default-Höhe auf meine Seehöhe gesetzt und spare mir nun die Anpassung.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 02 September 2018, 22:26:24
Wie wird denn beim generischen Sensor die Batteriemessung mit eingebunden?

verstehe leider zu wenig von C++

Einfach das hier mit rein kopieren?
  hal.battery.init(seconds2ticks(60UL*60), sysclock);
  hal.battery.low(22);
  hal.battery.critical(19);
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 September 2018, 08:08:23
Das kommt ganz drauf an, wie die Spannungsversorgung aussieht. Wenn Du die Batteriesn direkt angeschlossen hast, wird die BatterySensor Klasse im HAL-Template genutzt. Wenn Du nen Stepup benutzt, musst Du noch den Spannungsteiler mit auf der Platine haben und nutzt die BatterySensorUni Klasse.
Die Batterieklasse muss dann noch initialisiert werden. Das hast Du aber schon gefunden. Als einfaches Beispiel für die direkte messung könnte der HM-SEC-MDIR.ino dienen.
Titel: Antw:AskSin++ Library
Beitrag von: tndx am 09 September 2018, 21:14:16
Hallo zusammen,

ich kämpfe hier gerade auch mit der Spannungsmessung. Ich habe Dirks Außensensorplatine mit StepUp und will die eigentliche Batteriespannung messen, die entsprechenden Widerstände sind bestückt. Laut Schaltplan werden zur Messung die Ports A1 und D7 verwendet. Naiv wie ich bin, habe ich einfach "#define INTERNAL_VOLTAGE_MEASUREMENT" auskommentiert und habe erwartet, dass damit schon das richtige BatteryDevice zum Tragen kommt, wie im Forum bereits mehr fach an unterschiedlichen Stellen entdeckt:
#ifdef INTERNAL_VOLTAGE_MEASUREMENT
typedef BatterySensor           BatteryType;
#else
typedef BatterySensorUni<5, 6>  BatteryType;
#endif

Doch damit werden bei mir die Werte zw. 5 und 12 gemessen, was nicht stimmen kann. Ich kann auch mit den beiden Ports 5 und 6 überhaupt nichts anfangen, keine mir bekannte Platine hier aus dem Forum nutzt diese Ports zur Messung. Da stellt sich mir die Frage, was für Port-Bezeichnungen werden hier erwartet? Atmega-Pinnummern, Arduino Pro Mini Pinnummern oder noch irgendwas Anderes? Bzw. was muss ich da konkret bei den Ports A1 und D7 angeben? Sind noch mehr Änderungen mit dem anderen BatteryDevice notwendig?

Sorry, bin nicht so der C++ Programmrierer  :(

Danke schonmal!

P.S.: Kompiliert wurde mit AskSinPP V3 vom 7.8.2018
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 September 2018, 21:44:33
Die Batteryklasse erwartet Arduino-Pin-Nummern. Diese unterscheiden sich zwischen verschiedenen Boards. Für den Pro Mini ist A1 == 15 und D7 == 7. Es muss also

typedef BatterySensorUni<15,7>  BatteryType;

heissen und der Pro Mini in der IDE eingestellt.sein.
Titel: Antw:AskSin++ Library
Beitrag von: tndx am 09 September 2018, 22:02:57
Vielen Dank papa, läuft!
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 17 September 2018, 10:42:46
Hallo papa,
funktioniert im V3 Branch der HM-SEC-RHS noch richtig?

Das Gerät lässt sich an der CCU anlernen, regiert aber nur auf Änderungen am Sabotage Pin.

Die Pins 14 und 15 werden in threestate.h unter readPin() erkannt. Es werden aber keine Statusänderungen an die CCU übertragen.

Laut ser. Mon sieht die Kommunikation bei Änderungen am Sabotagepin wie folgt aus:

<- 0E 08 A2 10 095634 45FB6E 06 01 C8 00 56  - 7606
waitAck: 00
<- 0E 08 A2 10 095634 45FB6E 06 01 C8 00 56  - 8242
-> 11 08 A0 02 45FB6E 095634 04 93 68 00 00 68 1A 02  - 8375
waitAck: 01


Bei einer Änderung an Pin 14 bzw. 15 wird nur der folg. 2er Block übertragen

<- 0C 05 A2 41 095634 45FB6E 01 04 00  - 5760
-> 11 05 A0 02 45FB6E 095634 04 65 29 00 00 29 0A 02  - 5893
waitAck: 01

Danke für einen Hinweis.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 September 2018, 11:58:38
Der Sketch sollte unverändert mit 2 Kontakten am Griff und einem Sabotage-Kontakt funktionieren.
Hast Du zufällig SENS3_PIN definiert ? Du musst hier dann einen zusätzlichen Kontakt anschliessen, der wie ein extra Fenster-Kontakt arbeitet. Also wenn dieser Kontakt offen ist - ist auch das Fenster immer im offen Zustand - egal wie der Griff steht. Es gibt dann keinen Sabotagekontakt.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 17 September 2018, 12:14:43
nein, Sens3 habe ich nicht definiert. Habe es so, wie im Beispiel als Standard gelassen.

Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 September 2018, 12:18:09
Wie ist die eventDelayTime konfiguriert ? Du musst den Pin mindestens so lange geändert lassen, wie die eventDelayTime eingestellt ist. Sonst wird immer nur der letzte Status übertragen. Also wenn Du den Pin nur ganz kurz schliesst, aber ein Delay von einer Sekunde eingestellt ist, kriegst Du immer nur den einen Status.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 17 September 2018, 12:59:31
die eventDelayTime habe ich nicht verändert.

Ich habe aber den Kontakt zu Pin 14 bzw. 15 dauerhaft geschlossen und es wird aber trotzdem nichts übertragen.

Wenn er sonst nur den letzten Zustand übertragen würde, müsste doch zumindest in der CCU Oberfläche die
"letzte Änderung" den aktuellen Zeitpunkt des kurzen Schliessens ausgeben?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 September 2018, 13:10:37
Irgendwelche anderen Änderungen am Code ?
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 17 September 2018, 13:30:22
nein, habe heute extra nochmal den v3 Branch neu runtergezogen, das Example daraus genommen und neu kompiliert.
Einzig die beiden LEDs im Code liegen bei mir beide auf dem gleichen Pin, da ich an meinem Testboard nur eine LED an Pin4 hängen habe.
Das dürfte aber wohl keinen Einfluss auf die Ausführung des Codes haben.

Was mich aber etwas wundert, ist Dein Satz von vorhin:
"Also wenn dieser Kontakt offen ist - ist auch das Fenster immer im offen Zustand - egal wie der Griff steht. Es gibt dann keinen Sabotagekontakt."

Das ist zwar bei mir nicht der Fall, da kein Sens3 genutzt wird, aber wenn Du schreibst Kontakt offen = Fenster offen, würde doch bedeuten, dass Sens3 immer geschlossen sein muß,
wenn der Griff auf den Positionen Sens1 oder Sens2 steht.

Das führt mich nochmal zur generellen Frage der Beschaltung der Kontakte.

Ich gehe davon aus, dass die geschlossen auf GND gezogen werden und jeder nur einzeln schaltet. Also nicht Sens1 und Sens2 gleichzeitig geschlossen sein müssen, um einen bestimmten
Zustand zu signalisieren.

=>
Sens1 auf GND, Sens2 und Sab offen = "Fenster offen"
Sens2 auf GND, Sens1 und Sab offen = "Fenster Kippstellung"
Sab auf GND, Sens1 und Sens2 offen = "Sabotage"
alle offen = "Fenster verrriegelt"
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 September 2018, 13:34:28
Guckst Du hier (https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Sensor_spezifische_Einstellungen)
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 17 September 2018, 13:51:45
ok, das deckt sich dann ja mit meiner Zuordnung, nur dass A2 noch der Sabotagepin ist.

An der Beschaltung kann es also nicht liegen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 September 2018, 15:24:45
Wie sieht denn die Hardware aus ?
Welche Entwicklungsumgebung benutzt Du ?
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 17 September 2018, 15:35:04
Ich benutze einen Arduino Pro Mini V2   der mit 8Mhz und 3,3V läuft.

Als IDE arbeite ich mit der Arduino IDE V1.85

Wie im ersten Post ja schon geschrieben, werden die Pineingaben an A0, A1 und A2 auch erkannt.
Habe mir dazu mal zum Debuggen in Threestate.h in den beiden readPin-Funktionen den Value ausgeben lassen
und sehe dort, dass die Pinänderung ankommt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 September 2018, 16:30:20
Kannst Du bitte nochmal mehrere Messages aufzeichnen. Also A0 drücken - Message - loslassen - Message - A1 drücken - Message - loslassen - Message.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 17 September 2018, 16:49:20
A0 gedrückt
<- 0C 11 A2 41 095634 45FB6E 01 08 00  - 52487
-> 11 11 A0 02 45FB6E 095634 04 CA 38 00 00 38 0E 02  - 52620
waitAck: 01

A0 losgelassen
<- 0C 12 A2 41 095634 45FB6E 01 09 C8  - 53147
-> 11 12 A0 02 45FB6E 095634 04 A3 0B 00 00 0B 02 02  - 53281
waitAck: 01

A1 gedrückt
<- 0C 13 A2 41 095634 45FB6E 01 0A 64  - 53809
-> 11 13 A0 02 45FB6E 095634 04 13 1A 00 00 1A 06 02  - 53942
waitAck: 01

A1 losgelassen
<- 0C 14 A2 41 095634 45FB6E 01 0B C8  - 54470
-> 11 14 A0 02 45FB6E 095634 04 1B 6C 00 00 6C 1B 02  - 54603
waitAck: 01

A2 gedrückt
<- 0E 15 A2 10 095634 45FB6E 06 01 C8 0E 51  - 55133
-> 11 15 A0 02 45FB6E 095634 04 88 42 00 00 42 10 02  - 55267
waitAck: 01

A2 losgelassen
<- 0E 16 A2 10 095634 45FB6E 06 01 C8 00 51  - 55797
-> 11 16 A0 02 45FB6E 095634 04 5E 0B 00 00 0B 02 02  - 55931
waitAck: 01

ignore 0C F6 84 70 3C6DD3 000000 00 EC 3B  - 56179

A0 gedrückt
<- 0C 17 A2 41 095634 45FB6E 01 0C 00  - 56458
-> 11 17 A0 02 45FB6E 095634 04 E1 6F 00 00 6F 1B 02  - 56592
waitAck: 01

A0 losgelassen
<- 0C 18 A2 41 095634 45FB6E 01 0D C8  - 57120
-> 11 18 A0 02 45FB6E 095634 04 F9 48 00 00 48 12 02  - 57254
waitAck: 01

ignore 0C 0D A0 11 45FB6E 40CC07 02 01 C8  - 57542
ignore 0E 0D 80 02 40CC07 45FB6E 01 01 C8 00 33  - 57669

A1 gedrückt
<- 0C 19 A2 41 095634 45FB6E 01 0E 64  - 57783
-> 11 19 A0 02 45FB6E 095634 04 9B 34 00 00 34 0D 02  - 57917
waitAck: 01

A1 losgelassen
<- 0C 1A A2 41 095634 45FB6E 01 0F C8  - 58447
-> 11 1A A0 02 45FB6E 095634 04 D4 79 00 00 79 1E 02  - 58582
waitAck: 01

A2 gedrückt
<- 0E 1B A2 10 095634 45FB6E 06 01 C8 0E 52  - 59110
-> 11 1B A0 02 45FB6E 095634 04 32 41 00 00 41 10 02  - 59244
waitAck: 01

ignore 14 16 84 5E 44B144 000000 8B 4B 70 00 00 00 00 00 09 25 FE  - 59528
ignore 0C 9E 86 5A 3C9586 000000 28 EF 2F  - 59641

A2 losgelassen
<- 0E 1C A2 10 095634 45FB6E 06 01 C8 00 57  - 59771
-> 0C 1D 84 70 3C93DB 000000 00 EE 33  - 59854
-> 11 1C A0 02 45FB6E 095634 04 B0 5E 00 00 5E 17 02  - 59908
waitAck: 01

A0 gedrückt
<- 0C 1D A2 41 095634 45FB6E 01 10 00  - 60431
-> 0C E1 86 5A 3C93C1 000000 88 FB 2F  - 60504
-> 11 1D A0 02 45FB6E 095634 04 21 2D 00 00 2D 0B 02  - 60567
waitAck: 01

A0 losgelassen
<- 0C 1E A2 41 095634 45FB6E 01 11 C8  - 61092
-> 11 1E A0 02 45FB6E 095634 04 17 07 00 00 07 01 02  - 61227
waitAck: 01

A1 gedrückt
<- 0C 1F A2 41 095634 45FB6E 01 12 64  - 61753
-> 11 1F A0 02 45FB6E 095634 04 72 0E 00 00 0E 03 02  - 61887
waitAck: 01

A1 losgelassen
<- 0C 20 A2 41 095634 45FB6E 01 13 C8  - 62415
-> 11 20 A0 02 45FB6E 095634 04 88 6F 00 00 6F 1B 02  - 62550
waitAck: 01

A2 gedrückt
<- 0E 21 A2 10 095634 45FB6E 06 01 C8 0E 52  - 63078
-> 11 21 A0 02 45FB6E 095634 04 D6 76 00 00 76 1D 02  - 63211
waitAck: 01

ignore 0C 19 A0 11 45FB6E 3E0B49 02 01 C8  - 63428
ignore 0E 19 80 02 3E0B49 45FB6E 01 01 C8 00 49  - 63555

A2 losgelassen
<- 0E 22 A2 10 095634 45FB6E 06 01 C8 00 54  - 63739
-> 11 22 A0 02 45FB6E 095634 04 55 4C 00 00 4C 13 02  - 63874
waitAck: 01

Bei A2 wird als Sabotagemessage in der CCU erkannt. A0 & A1 keine Änderung.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 September 2018, 20:05:43
Also die Nachrichten sehen alles bestens aus:

A0 gedrückt
<- 0C 11 A2 41 095634 45FB6E 01 08 00  - 52487
-> 11 11 A0 02 45FB6E 095634 04 CA 38 00 00 38 0E 02  - 52620
waitAck: 01
Im Event wird 00 gesendet -> das Fenster ist geschlossen

A0 losgelassen
<- 0C 12 A2 41 095634 45FB6E 01 09 C8  - 53147
-> 11 12 A0 02 45FB6E 095634 04 A3 0B 00 00 0B 02 02  - 53281
waitAck: 01
Im Event wird 200 gesendet -> das Fenster ist offen

A1 gedrückt
<- 0C 13 A2 41 095634 45FB6E 01 0A 64  - 53809
-> 11 13 A0 02 45FB6E 095634 04 13 1A 00 00 1A 06 02  - 53942
waitAck: 01
Im Event wird 100 gesendet -> das Fenster ist angekippt

A1 losgelassen
<- 0C 14 A2 41 095634 45FB6E 01 0B C8  - 54470
-> 11 14 A0 02 45FB6E 095634 04 1B 6C 00 00 6C 1B 02  - 54603
waitAck: 01
Im Event wird 200 gesendet -> das Fenster ist wieder offen

Von der CCU kommt auch immer schon die Bestätigung - UPS NÖ - ich sehe gerade, es kommt eine AES-Challange - Du hast ohne AES übersetzt. Dann musst Du bei der CCU die sichere Verbindung deaktivieren oder mit AES übersetzen. Bitte im Readme nach sehen, wie das geht.
Titel: Antw:AskSin++ Library
Beitrag von: Gruenebe am 18 September 2018, 10:57:21
Ok. Danke.

Habe jetzt das AES im Sketch definiert und nun funktioniert es.


Noch eine generelle Frage.

Die Pinabfrage in Threestate.h erfolgt doch über die readPin Funktionen per Polling.

Warum werden die Pins nicht per Interrupt ausgelöst? EnableInterrupt ist im Sketch ja included.

Wird dann das Timing der CC1101 Kommunikation, welche nehme ich an interruptbasiert arbeitet, gestört, wenn noch weitere ISRs loslaufen?

Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 September 2018, 12:04:07
Das Polling wird genutzt, um die Batterie zu schonen. Für Interrupts müssten die Pins dauerhaft auf INPUT_PULLUP gesetzt werden. Das benötigt zu viel Energy. Im Fensterkontakt-Thread gab es eine tiefere Analyse dazu.
Titel: Antw:AskSin++ Library
Beitrag von: neumann am 29 September 2018, 14:23:34
Hey Leute!
Ich bräuchte einen simplen Sensor, der 32 Bit Worte senden und empfangen kann.
Könnt ihr mir da helfen?

Lg
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 September 2018, 20:26:26
Zitat von: neumann am 29 September 2018, 14:23:34
Hey Leute!
Ich bräuchte einen simplen Sensor, der 32 Bit Worte senden und empfangen kann.
Könnt ihr mir da helfen?
Na klar - https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110
Titel: Antw:AskSin++ Library
Beitrag von: neumann am 30 September 2018, 15:05:33
Zitat von: papa am 29 September 2018, 20:26:26
Na klar - https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110

Vielen Dank!
Das Senden vom Sensor an FHEM klappt, nur weiß ich noch nicht, wie das in die andere Richtung funktioniert, also einen 32 Bit Wert an den Sensor zu schicken.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 30 September 2018, 21:02:46
Was willst Du denn genau machen ? Das könnte etwas komplizierter werden.
Titel: Antw:AskSin++ Library
Beitrag von: neumann am 30 September 2018, 21:16:29
Ich will ein Gateway für meine Gegensprechanlage betreiben, das 32 Bit Worte vom Bus lesen und schreiben kann. Das will ich via FHEM mit einem CUL ansteuern.
Das Lesen klappt so bereits.
Titel: Antw:AskSin++ Library
Beitrag von: neumann am 01 Oktober 2018, 00:43:01
Vielleicht gibt es ja einen Hacky Weg mit schreiben in ein Register oder verwenden eines Device Typs der das kann o.ä.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Oktober 2018, 18:32:42
hm - mir fällt da spontan nichts ein. Bei einem Byte könnte an recht einfach die Set-Message nehmen. Aber 32bit geht so nicht. Da müsste man ein ganz neues Gerät machen inklusive FHEM-Anbindung.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 02 Oktober 2018, 01:20:05
@papa
Könnte er nicht einfach im culHmRegDefine des FHEM Scripts die message length einer 'custom' message auf 4 Bytes setzen
s=>4.0
und dann im Arduino Sketch bei DEFREGISTER die 4 Bytes definieren und zum 32bit Wert zusammensetzen?
Hacky, aber danach wurde gefragt  ;)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 Oktober 2018, 22:17:25
Ja - man könnte ein Regsiter definieren, aber das wird dann immer in den Flash geschrieben. Das macht der Chip dann nicht ewig mit.
Besser wäre, eine Action zu definieren. Mal aus

$HMConfig::culHmSubTypeSets{"Values"} = { };

folgendes machen

$HMConfig::culHmSubTypeSets{"Values"} = { pct =>"[-value-] ... [-ontime-] [-ramptime-]" };

Dann müsste es möglich sein, wie beim Dimmer, ein Byte und 2 2-Byte-Werte zu übertragen. Leider wird FHEM allerdings die 2-Byte-Werte noch mit CUL_HM_encodeTime16() umrechnen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 03 Oktober 2018, 00:38:39
Zitat von: papa am 02 Oktober 2018, 22:17:25
Ja - man könnte ein Regsiter definieren, aber das wird dann immer in den Flash geschrieben. Das macht der Chip dann nicht ewig mit.

Guter Punkt, wobei Du wahrscheinlich EEPROM und nicht Flash meinst? Die Register sollten in den EE geschrieben werden (nehme ich zumindest an).
EE hat mindestens 100k Schreibzyklen gegenüber 10k beim Flash.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Oktober 2018, 20:40:03
Ja natürlich EEPROM
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 04 Oktober 2018, 18:21:39
Zitat von: Klaus0815 am 17 August 2018, 18:41:43
Hallo papa,  sorry wenn es etwas verwirrend war
Was ich bräuchte wäre quasi der Universalsensor zur Temperaturmessung, egal ob DS18B20, DHT22, BME280,...
Und dann zusätzlich ein Taster-Eingang,  dort kann ich dann z.B. einen Bewegunsmelder, einen Türkontakt, ein Taster der irgend eine Aktion auslöst anschließen


Ich hole das alte Thema noch mal hoch, habe jetzt wieder etwas mehr Zeit zum Basteln.


Hat zufällig jemand was wie oben beschrieben am laufen?
Notlösung wäre sonst einfach 2 x die Mini-Platine in einem Gehäuse, aber wohl etwas übertrieben...

Grüße

Klaus
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 09 Oktober 2018, 19:19:52
Hallo,

inzwischen habe ich einige von den Modulen am Laufen. Da ich es Leid war, immer die Kabel zu löten, habe ich mal ein Layout entworfen. Im Prinzip ist es ein 5v Pro Mini (durch Drahtbrücken könnte man auch 3.3v einsetzen), mit einem CC1101, Levelschifter und Ausgängen. Die Widerstände möchte ich unter dem Pro Mini verlöten um Platz zu sparen.

Daran anschließen kann man entweder Relais, Temperatursensoren etc....

Hat jemand Verbesserungsvorschläge?

Gruss Marc
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 09 Oktober 2018, 20:09:43
Warum nicht gleich ein 3,3V Pro Mini? Spart 6x Widerstand und bei den HM Modulen ist es in der Regel performance-mäßig egal ob 8 oder 16 MHz..
Titel: Antw:AskSin++ Library
Beitrag von: kpwg am 09 Oktober 2018, 20:30:50
Oder das papa-Board, hervorgegangen aus dem Fensterdrehgriffkontakt in der Bastelecke: https://github.com/pa-pa/HMSensor (https://github.com/pa-pa/HMSensor)
Sehr kleine Abmessungen, alles Wichtige an Bord, preiswert aufzubauen, 8 Pins für alles Mögliche.
Man muss halt den Kram zusammentragen und Platinen ordern sowie sehr kleine SMDs löten.
Ich hatte mir auch erst überlegt, zum frickeln und testen einen pro mini mit cc1101 aufzubauen, sehe da nur keine Vorteile.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Oktober 2018, 21:04:58
Oder eine Platine von hier https://github.com/alexreinert/PCB
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 09 Oktober 2018, 21:44:29
Zitat von: Tom Major am 09 Oktober 2018, 20:09:43
Warum nicht gleich ein 3,3V Pro Mini? Spart 6x Widerstand und bei den HM Modulen ist es in der Regel performance-mäßig egal ob 8 oder 16 MHz..

Ist ein berechtigter Punkt, mit einem 3.3v modul habe ich den Unisensor aufgebaut. Der Gedanke bei 5v zu bleiben kam dadurch, dass ich in aller Regel für meine Anwendungen 5v zur Verfügung habe. Außerdem kann ich durch drei einfache Drahtbrücken auch einen 3.3v Pro Mini verwenden.
Gruss
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 10 Oktober 2018, 06:24:31
Zitat von: papa am 09 Oktober 2018, 21:04:58
Oder eine Platine von hier https://github.com/alexreinert/PCB

Danke, diese habe ich auf einer Lochraster Platine nachgebaut und wirklich sehr gut. Sie ist mir aber zu gross und zu speziell um sie zB in meine Gegensprechanlage oder Steckdosenleiste einzubauen.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 10 Oktober 2018, 07:20:39
Zitat von: kpwg am 09 Oktober 2018, 20:30:50
Oder das papa-Board, hervorgegangen aus dem Fensterdrehgriffkontakt in der Bastelecke: https://github.com/pa-pa/HMSensor (https://github.com/pa-pa/HMSensor)
Sehr kleine Abmessungen, alles Wichtige an Bord, preiswert aufzubauen, 8 Pins für alles Mögliche.
Man muss halt den Kram zusammentragen und Platinen ordern sowie sehr kleine SMDs löten.
Ich hatte mir auch erst überlegt, zum frickeln und testen einen pro mini mit cc1101 aufzubauen, sehe da nur keine Vorteile.

Das klingt doch super. Muss ich mir mal ansehen. Danke
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 11 Oktober 2018, 14:21:12
Hallo,

eine Frage, ich habe derzeit ein Schlüsselbrett an dem ich 3 1-Wire iButtons hängen kann. Das Abfragen der Buttons funktioniert aber nur mittelprächtig weil FHEM doch teilweise stark blockiert etc.
Mir kam jetzt die Idee das mit einem HB-GEN-SENS zu realisieren. Sprich der pollt den 1-Wire Bus und übermittelt an FHEM die vorhandenen gefundenen iButton Seriennummern. Bekommt man das hin? Kann ich an FHEM eine "Liste" dynamischer Länge übermittelt? Gut in meinem Fall sind es nur maximal 3 Seriennummern...

Allerdings ist das vielleicht keine gute Idee über Funk zu regeln, vielleicht doch lieber Kabelbasiert?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 11 Oktober 2018, 15:44:41
Zitat von: ext23 am 11 Oktober 2018, 14:21:12
Mir kam jetzt die Idee das mit einem HB-GEN-SENS zu realisieren. Sprich der pollt den 1-Wire Bus und übermittelt an FHEM die vorhandenen gefundenen iButton Seriennummern. Bekommt man das hin? Kann ich an FHEM eine "Liste" dynamischer Länge übermittelt? Gut in meinem Fall sind es nur maximal 3 Seriennummern...

Nach meinen Infos beträgt die max. Payload 17 Bytes. Mit 3 Seriennummern a 6 Byte also etwas knapp, aber man könnte ja die Nummern multiplexed auf mehrere Telegramme aufteilen.
Auf jeden Fall brauchst du dafür einen custom Perl script um das dann im gewünschten Format in FHEM reinzubekommen, möglich sollte es aber sein.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Oktober 2018, 16:03:42
Zitat von: ext23 am 11 Oktober 2018, 14:21:12
eine Frage, ich habe derzeit ein Schlüsselbrett an dem ich 3 1-Wire iButtons hängen kann. Das Abfragen der Buttons funktioniert aber nur mittelprächtig weil FHEM doch teilweise stark blockiert etc.
Mir kam jetzt die Idee das mit einem HB-GEN-SENS zu realisieren. Sprich der pollt den 1-Wire Bus und übermittelt an FHEM die vorhandenen gefundenen iButton Seriennummern. Bekommt man das hin? Kann ich an FHEM eine "Liste" dynamischer Länge übermittelt? Gut in meinem Fall sind es nur maximal 3 Seriennummern...

Allerdings ist das vielleicht keine gute Idee über Funk zu regeln, vielleicht doch lieber Kabelbasiert?
Für mein Klingelprojekt https://forum.fhem.de/index.php/topic,87512.msg799444.html#msg799444 habe ich schon eine rudimentäre iButton-Unterstützung . Die grobe Idee ist, dass man einen iButton-Kanal hat, welcher eine ID zugewiesen bekommt. Wenn der Button mit der entsprechenden ID gelesen wird, wird ein Remote-Event (wie bei einer Fernbedienung) erzeugt. Es können dann Geräte mit dem entsprechenden Kanal gepeert werden, womit dann eine Aktion ausgelöst werden kann. Das ganze ist derzeit nur im entsprechenden Projekt https://github.com/pa-pa/AskSinPP/tree/master/examples/stm32/HB-DoorBell implementiert.
Die ID für jeden Kanal kann per Register gesetzt werden oder indem man den Kanal auf ON schaltet. Dann wird der Kanal für 60 Sekunden in den Konfig-Modus versetzt und merkt sich die nächste gelesene ID.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 11 Oktober 2018, 16:53:21
Naja das würde ja auch gehen, aber dann findet die Seriennummer Verwaltung in dem Gerät statt. Dann muss man die eben als Register oder so bekannt machen und dem Kanal zuordnen. Oder eben per "Anlernen" speichern, irgendwie so ja.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Oktober 2018, 17:12:32
Das funktioniert soweit alles schon. Man müsste es nur noch in ein extra Geräte auslagern.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Oktober 2018, 22:46:12
Ich habe ein neues Geräte im GitHub eingecheckt. HB-IBUT-8 - ein 8 Kanal iButton Gerät. Damit es erfolgreich in FHEM angelernt werden kann, muss die HMConfig_AskSinPPCustom.pm aktualisiert werden.
Nach dem Anlernen sind 8 Kanäle Id_01 - Id_08 verfügbar.  Jedem Kanal kann ein iButton zugeordnet werden. Dazu ist der entsprechende Kanal mit
set DEVICE_Id_Kanalnummer on
in den Anlernmodus zu versetzen. Dieser ist für 1 Minute aktiv. Der aktive Anlernmodus wird durch abwechselndes Blinken der beiden Leds angezeigt. Wird jetzt ein iButton an den Leser gehalten, wird die entsprechende Id im Kanal gespeichert. Das Speichern wird mit der grünen Led bestätigt. Von nun an wird ein Remote-Event ausgelöst, wenn der entsprechende iButton gelesen wird.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 11 Oktober 2018, 23:09:51
Was passiert wenn 3 iButtons am Bus hängen? Und beim "entfernen", gibt es da auch ein event?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Oktober 2018, 07:17:08
Wei meinst Du das - 3 Buttons am Bus hängen ? Meinst Du 3 Reader ? Kannst Du das mal irgendwie genauer beschreiben.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 12 Oktober 2018, 08:06:07
Na One-Wire ist doch ein Bus, ich habe an meinem Schlüsselbrett 3 Magnetkontaktflächen an denen die Schlüssel hängen, je nachdem wer zu Hause ist. Also das HM Modul ist der Busmaster und dann kannst du ja x beliebige 1W Geräte haben.

Ist wie gesagt bei mir ein etwas anderer UseCase.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 12 Oktober 2018, 08:20:16
Zitat von: papa am 12 Oktober 2018, 07:17:08
Wei meinst Du das - 3 Buttons am Bus hängen ? Meinst Du 3 Reader ? Kannst Du das mal irgendwie genauer beschreiben.

Ich glaube ext23 hat 3 Reader mit je einem Button. Du nutzt einen Reader und hast dort 3 Buttons dran.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Oktober 2018, 09:30:01
Also eher wie ein Fensterkontakt ..... also als ThreeState-Kanal mit den States
0 - ABSENT
100 - PRESENT
200 - EDUCATE

Das Verhalten könnte man natürlich alternativ implementieren.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 12 Oktober 2018, 10:33:26
Nee nicht ganz ;-)

Dein Ansatz mit Multikanal ist schon gut. Es können ja auch mehr als 3 Schlüssel existieren.

Ich muss FHEM technisch wissen, welcher Schlüssel bzw. IButton bzw. Seriennummer "häng". Sprich sobald ein IButton mit einer gültigen Seriennummer angehangen wurde. Man könnte also sagen ich haben 5 Seriennummern angelernt an je einem Kanal. Jeder Kanal entspricht dann einer bestimmten Person das kann man ja mappen. So und ich muss unter FHEM den Status sehen welcher dieser Buttons gerade hängt. Ziehe ich ein Button ab weil jemand die Wohnung verlässt dann muss ich da ebenfalls ein Trigger bekommen um direkt drauf zu reagieren.

Ich bin mir halt nur nicht sicher ob das sicherheitstechnisch eine gute Lösung ist, weil damit auch die Alarmanlage aktiviert wird etc. Oder ob man Kabelgebunden bleibt und es über MQTT und LAN macht etc.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Oktober 2018, 11:19:25
Das meine ich doch - es sind dann X ThreeStateKanäle - pro iButton/Schlüssel einer. Dann gibt es bei jeder Statusänderung eine Nachricht. Wie bei einem Fenstersensor, kann jeder Kanal direkt mit Aktoren gepeert werden.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 12 Oktober 2018, 11:58:38
Ja ok, also Dual State reicht ;-) Aber gut um es auf "HM" abzubilden richtig ja.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 12 Oktober 2018, 20:27:45
Habe zufällig diese interessante Seite gefunden:
https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples (https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples)

Ja, vieles von papa kopiert, aber finde es interessant, Sensoren zu bauen, die man so nicht kaufen kann

Nur, bevor ich mich verrenne, was läuft denn davon mit FHEM?
So wie ich es verstanden habe ist die Homematic Comunity sehr fleissig im Nachbauen, die Beispiele gehen dann auch mit der CCU, aber für FHEM braucht es wohl jeweils spezielle Files?
Mag da mal jemand etwas aufklären? 
Von Papa gibt es den generischen Sensor, was ist der HB-Uni-Sen?

Bin zugegeben kein Programmierer, würde es evtl. Sinn machen, einen eigenen Thread hier zu eröffnen mit (auch in FHEM) funktionierenden Beispielen?

Viele Grüße
Klaus

Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Oktober 2018, 20:53:18
Zitat von: ext23 am 12 Oktober 2018, 11:58:38
Ja ok, also Dual State reicht ;-) Aber gut um es auf "HM" abzubilden richtig ja.
Der HM-IBUT-8 kann jetzt auch den ThreeStateMode. Dazu muss im Device das Regsiter buttonMode auf state gestet werden. Default ist remote.
set DEVICE buttonMode state
Der Rest bleibt so wie zuvor.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Oktober 2018, 20:54:57
Zitat von: Klaus0815 am 12 Oktober 2018, 20:27:45
Nur, bevor ich mich verrenne, was läuft denn davon mit FHEM?
Nur die Original-Nachbauten. Für die HB-Geräte wird eine angepasste HM-Config benötigt.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 12 Oktober 2018, 21:03:20
ZitatNur die Original-Nachbauten. Für die HB-Geräte wird eine angepasste HM-Config benötigt.

Habe gesehen, TomMajor hat da was veröffentlicht, aber ist das dann auch der Richtige?
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1/FHEM (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1/FHEM)

Oder nur zufällig der gleiche Name?
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 12 Oktober 2018, 22:07:09
Zitat von: papa am 12 Oktober 2018, 20:53:18
Der HM-IBUT-8 kann jetzt auch den ThreeStateMode. Dazu muss im Device das Regsiter buttonMode auf state gestet werden. Default ist remote.
set DEVICE buttonMode state
Der Rest bleibt so wie zuvor.

Super, probiere ich jetzt aus, hab ein PanStamp genommen und check das mal.

Ich mag ja diese Arduino IDE nicht so, aber wie kann man denn die Lib in dem Ordner speichern wo die INO liegt? Da die AskSin lib doch sehr dynamisch ist, ist es besser die dort zu lagen wo auch das Projekt ist, wenn man das später nochmal kompilieren möchte. Mache ich ein include mit vollem Pfad findet der einiges aus der lib nicht.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 12 Oktober 2018, 23:04:38
Also das funktioniert in der Tat gut!

Aber zwei Probleme habe ich noch, ich bekomme den buttonMode nicht geändert, der steht noch auf undef und dann darf der natürlich nicht dauerhaft senden wenn der iButton dran hängt, das macht er jetzt aber, liegt aber vielleicht am falschen mode. Ich spiele mal noch nen bissel rum.

Wirklich gut, aber ich glaube ich muss dann echt mal einen eigenen HM Key einstellen, sonst wird mir das alles ein bissel heiß, das möchte schon wenigstens signiert sein dann.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 12 Oktober 2018, 23:06:54
Genau es lag am mode! Er zeigt zwar immer noch undef an, egal wie oft ich ein getconfig mache aber jetzt funktioniert es.

Gut, dass ich mich mit panstamps eingedeckt habe damals. Die alten gibt es ja nicht mehr, aber die sind für die HM Sachen echt gut.

Ich hab noch einen kleinen Verbesserungsvorschlag. Es passiert manchmal, das alle in absent gehen wenn man ein neuen steckt. Ist eben ein Bus, und die Dinger sind alle parasitär versorgt. Kann man das noch irgendwie abfangen? Vielleicht doppelt abfragen ob der wirklich weg ist wenn wenn einer verschwindet?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 12 Oktober 2018, 23:33:02
Zitat von: Klaus0815 am 12 Oktober 2018, 21:03:20
Habe gesehen, TomMajor hat da was veröffentlicht, aber ist das dann auch der Richtige?
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1/FHEM (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1/FHEM)
Oder nur zufällig der gleiche Name?
Das Richtige für was genau?
Die verlinkte Datei ist die FHEM Configuration für meine Variante HB-UNI-Sensor1 von papas generischem Sensor (mit etwas Erklärung und Optionen für diverse Sensoren).
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 13 Oktober 2018, 11:01:01
ZitatDas Richtige für was genau?

Hallo Tom,

ich meinte diese Beispiele hier:

https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples (https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples)

Dort v.a. die verschiedenen HB-UNI-Sen....
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 13 Oktober 2018, 11:13:19
Zitat von: Klaus0815 am 13 Oktober 2018, 11:01:01
Hallo Tom,

ich meinte diese Beispiele hier:

https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples (https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples)

Dort v.a. die verschiedenen HB-UNI-Sen....

Soviel ich weiß ist jp112sdl ist eher auf CCU/RaspberryMatic Seite und nicht auf FHEM unterwegs.
Für jeden 'custom' Sensor mit spezifischem Messdaten und Payload braucht man ein angepasstes Perl script um das korrekt in FHEM reinzubekommen.

Das hier
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1/FHEM (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1/FHEM)
passt halt genau für die Payload in meiner HB-UNI-Sensor1 Variante.
Mit Perl Kenntnissen kann man das an Eigenentwicklungen mit anderer Payload anpassen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Oktober 2018, 11:32:24
Zitat von: ext23 am 12 Oktober 2018, 23:06:54
Genau es lag am mode! Er zeigt zwar immer noch undef an, egal wie oft ich ein getconfig mache aber jetzt funktioniert es.

Gut, dass ich mich mit panstamps eingedeckt habe damals. Die alten gibt es ja nicht mehr, aber die sind für die HM Sachen echt gut.

Ich hab noch einen kleinen Verbesserungsvorschlag. Es passiert manchmal, das alle in absent gehen wenn man ein neuen steckt. Ist eben ein Bus, und die Dinger sind alle parasitär versorgt. Kann man das noch irgendwie abfangen? Vielleicht doppelt abfragen ob der wirklich weg ist wenn wenn einer verschwindet?
Ja - das mit den Resgistern im Device geht irgendwie noch nicht richtig in FHEM. Muss ich mal mit Martin checken, was ich da flasch mache.
Ich habe das State Update nochmal angepasst. Es müsste jetzt besser funktionieren, wenn mal kurz ein Button weg ist.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 13 Oktober 2018, 11:35:06
Super, teste ich gleich! Ansonsten Seriennummern löschen über die Register geht auch sehr gut, manuell anlegen wenn man die Seriennummer kennt checke ich auch nochmal.

Also ich bin wirklich schwer begeistert!

>Ich habe das State Update nochmal angepasst. Es müsste jetzt besser funktionieren, wenn mal kurz ein Button weg ist.
Ist das schon auf github?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Oktober 2018, 15:38:48
Ja - im iButton.h
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 13 Oktober 2018, 18:29:34
Sieht besser aus!

Ich bau das jetzt mal in mein Schlüsselkasten ein und dann schau ich mal. Muss mir nur mal eben ne kleine Platine ätzen.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: neumann am 13 Oktober 2018, 22:06:06
Zitat von: papa am 02 Oktober 2018, 22:17:25
Ja - man könnte ein Regsiter definieren, aber das wird dann immer in den Flash geschrieben. Das macht der Chip dann nicht ewig mit.
Besser wäre, eine Action zu definieren. Mal aus

$HMConfig::culHmSubTypeSets{"Values"} = { };

folgendes machen

$HMConfig::culHmSubTypeSets{"Values"} = { pct =>"[-value-] ... [-ontime-] [-ramptime-]" };

Dann müsste es möglich sein, wie beim Dimmer, ein Byte und 2 2-Byte-Werte zu übertragen. Leider wird FHEM allerdings die 2-Byte-Werte noch mit CUL_HM_encodeTime16() umrechnen.


Hey!
Ich habe es nun geschafft, einen 32 Bit Wert zu senden und zu empfangen, mit dem unten angeführten Sketch.
Der Befehl, um an das Gateway zu senden ist ein Action Command: ++A011F0F0F0FA327180021234567803
Wie schaffe ich nun, das aus FHEM heraus zu senden mit Fehlererkennung (Ack) (zum testen ging es über set raw bei der VCCU, allerdings ohne Erkennung des zurückkommenden Acks)?
Am besten so einfach wie möglich.

Danke!


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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0xfa,0x32,0x71},       // Device ID
    "papafa3271",           // Device Serial
    {0xf2,0x05},            // Device Model
    0x01,                   // Firmware Version
  as::DeviceType::Sensor, // Device Type
    {0x00,0x00}             // Info Bytes
};

/**
* Configure the used hardware
*/
typedef AvrSPI<10,11,12,13> RadioSPI;
typedef AskSin<StatusLed<14>,BatterySensor,Radio<RadioSPI,3> > Hal;

DEFREGISTER(SensReg0,MASTERID_REGS,DREG_BURSTRX)
class SensList0 : public RegList0<SensReg0> {
public:
  SensList0 (uint16_t addr) : RegList0<SensReg0>(addr) {}
  void defaults () {
     burstRx(true);
   }
};

DEFREGISTER(ValuesReg1,CREG_AES_ACTIVE)
class ValuesList1 : public RegList1<ValuesReg1> {
public:
  ValuesList1 (uint16_t addr) : RegList1<ValuesReg1>(addr) {}
  void defaults () {
     aesActive(false);
   }
};

class BaseChannel : public Channel<Hal,ValuesList1,EmptyList,EmptyList,0,SensList0> {
public:
  virtual bool process (const ActionSetMsg& msg) { return false; }
  virtual bool process (const ActionCommandMsg& msg) { return false; }
  virtual bool process (const RemoteEventMsg& msg) { return false; }
  virtual bool process (const SensorEventMsg& msg) { return false; }
  uint8_t status () const { return 0; }
  uint8_t flags () const { return 0; }
};

class ValuesChannel : public BaseChannel, Alarm {
public:
  ValuesChannel () : BaseChannel(), Alarm(0)
  {}
  virtual ~ValuesChannel () {}

  virtual void trigger (AlarmClock& clock) {

  }

  void setup(Device<Hal,SensList0>* dev,uint8_t number,uint16_t addr) {
    BaseChannel::setup(dev, number, addr);
    set(seconds2ticks(3));
    sysclock.add(*this);
  }
};

class ActionChannel : public BaseChannel {
public:
  ActionChannel () : BaseChannel() {}
  virtual ~ActionChannel () {}

  void setup(Device<Hal,SensList0>* dev,uint8_t number,uint16_t addr) {
    BaseChannel::setup(dev, number, addr);
  }

  virtual bool process (const ActionCommandMsg& msg) override {
    DPRINTLN(F("got 32 bit word!"));
    return true;
  }
};

typedef ChannelDevice<Hal,BaseChannel,2,SensList0> CustomChannelDevice;

class SensType : public CustomChannelDevice {
private:
  ValuesChannel values;
  ActionChannel actions;
public:
  SensType (const DeviceInfo& i,uint16_t addr) : CustomChannelDevice(i, addr) {
    this->registerChannel(values, 1);
    this->registerChannel(actions, 2);
  }
  virtual ~SensType () {}
};

Hal hal;
SensType sdev(devinfo,0x20);
ConfigButton<SensType> cfgBtn(sdev);

void setup () {
  pinMode(5, INPUT);           // set pin to input
  digitalWrite(5, HIGH);

  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<Sleep<>>(hal);
  }
 
  if(!digitalRead(5)) {
    readFromBus();
  }
}

void readFromBus() {
    ValuesMsg& msg = sdev.message().values();
    msg.init(sdev.nextcount(),1);
    uint32_t value = 0xA1A2A3A4;
    msg.add(value);
    sdev.send(msg, sdev.getMasterID());

    delay(1000);
}
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 15 Oktober 2018, 19:16:12
ZitatDas hier
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1/FHEM
passt halt genau für die Payload in meiner HB-UNI-Sensor1 Variante.
Mit Perl Kenntnissen kann man das an Eigenentwicklungen mit anderer Payload anpassen.

Hallo Tom,

an den Perl Kentnissen scheitert es leider...

Habe jetzt aber trotzdem die meiszen meiner nervigen MySensors-Teile mit Deinem Script ersetzt, läuft bislang sehr gut

Was jetzt noch fehlen würde: EIn "Umwelt"-Sensor, also Temperatur, Luftfeuchte usw, wie in Deinem Beispiel, und zusätzlich ein EIngang für Taster, Bewegungsmelder, der dann sofort auslöst
In der RIchtung hat bislang niemand was gebastelt?

Viele Grüße

Klaus
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 16 Oktober 2018, 12:29:31
Zitat von: Klaus0815 am 15 Oktober 2018, 19:16:12
Hallo Tom,
an den Perl Kentnissen scheitert es leider...
Habe jetzt aber trotzdem die meiszen meiner nervigen MySensors-Teile mit Deinem Script ersetzt, läuft bislang sehr gut
Was jetzt noch fehlen würde: EIn "Umwelt"-Sensor, also Temperatur, Luftfeuchte usw, wie in Deinem Beispiel, und zusätzlich ein EIngang für Taster, Bewegungsmelder, der dann sofort auslöst
In der RIchtung hat bislang niemand was gebastelt?
Viele Grüße
Klaus

jp112sdl hat einen Sensor mit Taster in seinen Beispielen, aber wahrsch. ohne FHEM Unterstützung, bin nicht sicher.
Zufällig habe ich gerade den Bedarf, Daten eines extra Schalters/Inputs am Unisensor zu benötigen, der dann auch bei Änderung sofort senden soll, ich versuche das die nächsten Tage im HB-UNI-Sensor1 als Option nachzuziehen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Oktober 2018, 12:57:26
Zitat von: ext23 am 13 Oktober 2018, 18:29:34
Sieht besser aus!

Ich bau das jetzt mal in mein Schlüsselkasten ein und dann schau ich mal. Muss mir nur mal eben ne kleine Platine ätzen.
Und gibt es schon Bilder ?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Oktober 2018, 12:59:54
Zitat von: neumann am 13 Oktober 2018, 22:06:06
Hey!
Ich habe es nun geschafft, einen 32 Bit Wert zu senden und zu empfangen, mit dem unten angeführten Sketch.
Der Befehl, um an das Gateway zu senden ist ein Action Command: ++A011F0F0F0FA327180021234567803
Wie schaffe ich nun, das aus FHEM heraus zu senden mit Fehlererkennung (Ack) (zum testen ging es über set raw bei der VCCU, allerdings ohne Erkennung des zurückkommenden Acks)?
Am besten so einfach wie möglich.
Wie schon geschrieben, fällt mir da nur der Umweg über "set pct ..." ein.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 16 Oktober 2018, 13:20:23
Zitat von: papa am 16 Oktober 2018, 12:57:26
Und gibt es schon Bilder ?

Von der Platine oder der defekten Ätzmaschine :-( Ich hab Lochraster genommen, bis der neue Luftschlauch kommt dauert es mir zu lange ;-)
Es läuft aber tadellos! Danke nochmal.

/Daniel


Titel: Antw:AskSin++ Library
Beitrag von: sentinel1 am 19 Oktober 2018, 19:02:32
Zitat von: papa am 11 Oktober 2018, 22:46:12
Ich habe ein neues Geräte im GitHub eingecheckt. HB-IBUT-8 - ein 8 Kanal iButton Gerät. Damit es erfolgreich in FHEM angelernt werden kann, muss die HMConfig_AskSinPPCustom.pm aktualisiert werden.
Nach dem Anlernen sind 8 Kanäle Id_01 - Id_08 verfügbar.  Jedem Kanal kann ein iButton zugeordnet werden. Dazu ist der entsprechende Kanal mit
set DEVICE_Id_Kanalnummer on
in den Anlernmodus zu versetzen. Dieser ist für 1 Minute aktiv. Der aktive Anlernmodus wird durch abwechselndes Blinken der beiden Leds angezeigt. Wird jetzt ein iButton an den Leser gehalten, wird die entsprechende Id im Kanal gespeichert. Das Speichern wird mit der grünen Led bestätigt. Von nun an wird ein Remote-Event ausgelöst, wenn der entsprechende iButton gelesen wird.


Hallo,

ich habe mir einen HB-IBUT-8 gebaut auf Basis von Papas HM Universalsensor von hier https://forum.fhem.de/index.php/topic,73954.0.html (https://forum.fhem.de/index.php/topic,73954.0.html).Ich bekomme aber keinen IButton angelernt und weiß eigentlich nicht wo ich ansetzen soll.

Muss ich am Sketch etwas ändern?Ich habe da nichts geändert,der I-Reader ist an Gnd und B1 angeschlossen.
Ansonsten scheint alles zu funktionieren auch das anlernen und anlegen in FHEM hat problemlos funktioniert.

Ich versorge die Platine von einen Breadboard mit 3,3V.Ist das vielleicht zu wenig für den I-Button Reader?

Vielleicht hat jemand eine Idee und kann mir helfen.

Gruß,
Claudiu
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 19 Oktober 2018, 20:09:05
3,3V reicht vollkommen aus. Hast du ein PullUp von 4,7k auf dem Datenport? Die IButtons arbeiten nur Parasitär.

Was meinst du eigentlich mit "I-Button Reader", diese Kontaktfläche oder wie?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: sentinel1 am 19 Oktober 2018, 20:43:48
Zitat von: ext23 am 19 Oktober 2018, 20:09:05
3,3V reicht vollkommen aus. Hast du ein PullUp von 4,7k auf dem Datenport? Die IButtons arbeiten nur Parasitär.

Was meinst du eigentlich mit "I-Button Reader", diese Kontaktfläche oder wie?

/Daniel

4,7K Pullup habe ich nicht,werde ich gleich probieren.

ja,mit iButon Reader meine ich die Kontaktfläche wo mann den iButton dranhält.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 19 Oktober 2018, 20:55:53
Zitat von: sentinel1 am 19 Oktober 2018, 20:43:48
4,7K Pullup habe ich nicht,werde ich gleich probieren.

Der muss sein.
Titel: Antw:AskSin++ Library
Beitrag von: sentinel1 am 19 Oktober 2018, 20:58:24
Zitat von: ext23 am 19 Oktober 2018, 20:55:53
Der muss sein.

ja,das wars,jetzt geht es.Danke!
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 22 Oktober 2018, 20:38:04
Hallo Tom,

Zitatjp112sdl hat einen Sensor mit Taster in seinen Beispielen, aber wahrsch. ohne FHEM Unterstützung, bin nicht sicher.

welchen meinst Du da genau? sind so viele auf der Seite :-)
Denke auch dass das in FHEM nicht funktioniert, schade das da die Homematic-Jungs so viel weiter sind

Zitat
Zufällig habe ich gerade den Bedarf, Daten eines extra Schalters/Inputs am Unisensor zu benötigen, der dann auch bei Änderung sofort senden soll, ich versuche das die nächsten Tage im HB-UNI-Sensor1 als Option nachzuziehen.

Bin gespannt, würde mich sehr freuen wenn das klappt

Viele Grüße

Klaus
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 23 Oktober 2018, 00:49:27
Zitat von: Klaus0815 am 22 Oktober 2018, 20:38:04
Bin gespannt, würde mich sehr freuen wenn das klappt
Viele Grüße
Klaus
Hallo Klaus,
ja der digitale Eingang mit Sendeinterrupt läuft mittlerweile in meinem Unisensor, mache gerade noch etwas Feintuning an den HomeMatic AddOn Scripten dafür, zum Glück habe ich da mit jp112sdl einen sehr kompetenten Ansprechpartner  :)
Bei FHEM ist die Integration leicht da nur 1 Byte in der payload message dazugekommen ist..
Stelle ich die nächsten Tage online.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 24 Oktober 2018, 19:32:10
Zitat von: Klaus0815 am 22 Oktober 2018, 20:38:04
Bin gespannt, würde mich sehr freuen wenn das klappt
Viele Grüße
Klaus

Ein digitaler Eingang ist jetzt als zusätzlicher "Sensor" im HB-UNI-Sensor1 aktivierbar.
Aktuell wird der interne pull-up an diesem pin aktiviert, es reicht also ein Schalter gegen Masse. Bei jeder Statusänderung am Eingang wird ein Telegramm übertragen (unabhängig vom eingestellten Sendeintervall).

Die Scripte für HM CCU und FHEM sind auch angepasst, bei HM getestet, bei FHEM nicht (da HM bei mir zur Zeit nur auf RaspberryMatic läuft).
Falls etwas bei FHEM nicht passt melde dich einfach.
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 25 Oktober 2018, 19:46:37
Hallo Tom,

habs gleich mal getestet, funktioniert :-)

Im FHEM Script ist noch ein kleiner Fehler:
Die jetzt neue Zeile "Digital Input" wird nicht aktualisiert
(Bei state, wo alle Werte angezeigt werden, sieht man aber die Änderung)

Viele Grüße

Klaus


Titel: Antw:AskSin++ Library
Beitrag von: der-pw am 25 Oktober 2018, 21:22:15
Hallo,

ich muss mal ganz blöd fragen. Mit meinen rudimentären Arduinokenntnissen wollte ich dem HM-LC-SW1-BA-PCB-Beispiel einen fade-in (und später auch fade-out) Effekt beibringen.
Ich habe vor, einen kleinen LED-Strip damit zu schalten, jedoch soll der etwas schicker an und aus gehen.

Im Modul Switch.h habe ich folgende Änderung vorgenommen.
  virtual void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate,__attribute__((unused)) uint32_t delay) {
    if( newstate == AS_CM_JT_ON ) {
      i = 0;
      while (i < 255) {
        analogWrite(pin, i);
        i++;
        delayMicroseconds(10000);
      }
      digitalWrite(pin,lowact ? LOW : HIGH);
     
    }
    else if ( newstate == AS_CM_JT_OFF ) {
      digitalWrite(pin,lowact ? HIGH : LOW);
    }
    BaseChannel::changed(true);
  }


Wenn newstate == AS_CM_JT_ON dreht er also die Whileschleife dimmt hoch und macht danach den üblichen Aufruf "digitalWrite(pin,lowact ? LOW : HIGH);"
Das funktioniert auch, aber leider nur nach jedem Neustart genau einmal. beim zweiten Mal anschalten, schaltet die Lampe wieder "hart" an. Seltsamerweise muss die Schleife aber trotzdem irgendwie durchlaufen, denn das Feedback, dass die Lampe nun an ist kommt in FHEM mit genau der Verzögerung an die dem Delta ebenmeiner Schleife entspricht.
Ich hoffe ich habe das halbwegs verständlich wiedergegeben. In der Hoffnung auf eine Lösung. ;-)

i wird am Anfag auch als "unsigned int i = 0;" deklariert.

Schöne Grüße,
Patrick

btw: ja, ich weiß dass es unter Examples auch den Dimmer gibt. Das einfache An- und Ausschalten sollte einfach nur schicker gemacht werden, und da erschien mir "HM-LC-SW1-BA-PCB" perfekt zu. Zudem will ich ja noch was lernen dabei. ;-)
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 26 Oktober 2018, 19:32:14
Zitat von: Klaus0815 am 25 Oktober 2018, 19:46:37
Hallo Tom,

habs gleich mal getestet, funktioniert :-)

Im FHEM Script ist noch ein kleiner Fehler:
Die jetzt neue Zeile "Digital Input" wird nicht aktualisiert
(Bei state, wo alle Werte angezeigt werden, sieht man aber die Änderung)

Viele Grüße

Klaus

Hallo Klaus,
der neue "Digital Input" wird genau so in die event queue gepusht wie auch die anderen Daten
push (@events, [$shash, 1, 'digital input:' . $digInput0]);
deswegen wüsste ich auf die Schnelle nicht woran das liegt.
Am besten du meldest dich mal per PM, ich möchte hier diesen Thread nicht damit belasten da dieses Problem doch etwas off-topic ist.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 30 Oktober 2018, 23:39:52
Zitat von: Tom Major am 26 Oktober 2018, 19:32:14
Hallo Klaus,
der neue "Digital Input" wird genau so in die event queue gepusht wie auch die anderen Daten
push (@events, [$shash, 1, 'digital input:' . $digInput0]);
deswegen wüsste ich auf die Schnelle nicht woran das liegt.
Am besten du meldest dich mal per PM, ich möchte hier diesen Thread nicht damit belasten da dieses Problem doch etwas off-topic ist.

Nachtrag, vielleicht hilft es noch jemanden:
Die Aktualisierung des neuen Readings "Digital Input" funktioniert jetzt bei Klaus0815 auch in FHEM.
Der Fehler war das im Perl script an dieser Stelle
push (@events, [$shash, 1, 'digital input:' . $digInput0]);
kein Leerzeichen im Reading Namen 'digital input:' sein darf, der state (wo alle Werte drin sind) wird korrekt aktualisiert, nur halt das Reading selbst nicht. Ohne Leerzeichen alles Bestens.
Titel: Antw:AskSin++ Library
Beitrag von: kpwg am 02 November 2018, 07:43:19
Zitat von: Tom Major am 30 Oktober 2018, 23:39:52
Nachtrag, vielleicht hilft es noch jemanden:
Die Aktualisierung des neuen Readings "Digital Input" funktioniert jetzt bei Klaus0815 auch in FHEM.

Hier in meiner Testumgebung klappt es auch wie gewünscht. Das Reading wird bei jedem Tastendruck aktualisiert. Eine sehr gut geignete Funktion, um einen Tür- oder Fensterkontakt zu gestalten.

Viele Grüße,

Ricardo
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 02 November 2018, 18:21:15
Zitat von: kpwg am 02 November 2018, 07:43:19
Hier in meiner Testumgebung klappt es auch wie gewünscht. Das Reading wird bei jedem Tastendruck aktualisiert. Eine sehr gut geignete Funktion, um einen Tür- oder Fensterkontakt zu gestalten.

Viele Grüße,

Ricardo

Hey Ricardo, danke für das feedback.
Ich habe vor einen Unisensor im Keller zu plazieren und mit dem neuen Eingang monitore ich den Heizung an/aus Status.
Titel: Antw:AskSin++ Library
Beitrag von: Prof. Dr. Peter Henning am 03 November 2018, 10:57:58
Gibt es irgendwo noch Platinen für diesen Unisensor zu kaufen? ich würde nämlich mehrere benötigen.

LG

pah
Titel: Antw:AskSin++ Library
Beitrag von: kadettilac89 am 03 November 2018, 12:15:06
Zitat von: Prof. Dr. Peter Henning am 03 November 2018, 10:57:58
Gibt es irgendwo noch Platinen für diesen Unisensor zu kaufen? ich würde nämlich mehrere benötigen.

Meinst du die Universalplatine von pa-pa? ... diese hier ...https://github.com/pa-pa/HMSensor ?

Wenn ja, ich habe die als Temperatursensor mit Software basierend auf Temp-Seonsor von TomMajor am laufen.

Von den Platinen mit StepUp hätte ich noch welche übrig ...
Titel: Antw:AskSin++ Library
Beitrag von: kpwg am 03 November 2018, 12:29:09
... und ich habe noch einige der zum StepUp Sensor passenden 1xAAA Batterieträger-Platinen übrig.

EDIT: Platinen sind weg.  :)
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 03 November 2018, 12:39:13
Zitat von: Prof. Dr. Peter Henning am 03 November 2018, 10:57:58
Gibt es irgendwo noch Platinen für diesen Unisensor zu kaufen? ich würde nämlich mehrere benötigen.

LG

pah

Ich könnte dir noch 5 Stück davon anbieten: https://forum.fhem.de/index.php/topic,92773.0.html
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 03 November 2018, 12:51:30
gerade ganz frisch eingestellt, mein aktuelles Redesign von Dirks Sensor.
https://forum.fhem.de/index.php/topic,20620.msg853373.html#msg853373 (https://forum.fhem.de/index.php/topic,20620.msg853373.html#msg853373)
Titel: Antw:AskSin++ Library
Beitrag von: kpwg am 03 November 2018, 13:41:57
Zitat von: Tom Major am 03 November 2018, 12:51:30
gerade ganz frisch eingestellt, mein aktuelles Redesign von Dirks Sensor.
... was Dir sehr gut gelungen ist! Das Bessere ist immer der Feind des Guten. Aktuell teste ich einige Sensoren "alter Bauart" ohne Lastmessung mit relativ leeren Batterien, um das Verhalten bei mangelhafter Energieversorgung zu erkunden. Erste Erkenntnis: unter 2.1V wird es kritisch, die Gefahr des "babbling idiot" nimmt stark zu. Ich hatte zwar diesen Fall so noch nicht, aber einen UNISENSOR1 mit BME280-/MAX44009-Breakout auf papa-Board an 2xAA am bedrahteten Batteriehalter, welcher nach jedem Sendevorgang rebootet und somit in einer Schleife hing. Die LED hat da nur noch leicht geglimmt.

Ich kann da nur empfehlen, innerhalb weniger Tage die Batterien zu tauschen, wenn der Sensor ohne die echte Batteriespannungsmessung unter Last auf "low" geht.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 03 November 2018, 20:24:15
Zitat von: kpwg am 03 November 2018, 13:41:57
... was Dir sehr gut gelungen ist! Das Bessere ist immer der Feind des Guten. Aktuell teste ich einige Sensoren "alter Bauart" ohne Lastmessung mit relativ leeren Batterien, um das Verhalten bei mangelhafter Energieversorgung zu erkunden. Erste Erkenntnis: unter 2.1V wird es kritisch, die Gefahr des "babbling idiot" nimmt stark zu. Ich hatte zwar diesen Fall so noch nicht, aber einen UNISENSOR1 mit BME280-/MAX44009-Breakout auf papa-Board an 2xAA am bedrahteten Batteriehalter, welcher nach jedem Sendevorgang rebootet und somit in einer Schleife hing. Die LED hat da nur noch leicht geglimmt.

Ich kann da nur empfehlen, innerhalb weniger Tage die Batterien zu tauschen, wenn der Sensor ohne die echte Batteriespannungsmessung unter Last auf "low" geht.

Danke für die Blumen.
Beim Aufbau sieht man dann immer was noch nicht optimal ist, z.B. das Loch passt nicht genau zum verwendeten Batteriehalter.
Ich fange mal am besten eine Liste an was in der nächsten Revision zu verbessern wäre.
Die Schaltung für Batt.messung unter Last habe ich noch nicht aufgelötet und getestet, das habe ich nächste Woche vor.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 November 2018, 10:16:29
Wer sich für die derzeit möglichen Nachbauten/Eigenbauten interessiert, möge mal nen Blick in das AskSin++ Collection (https://github.com/jp112sdl/AskSinPPCollection) Github werfen. Dort hat Jerome jede Menge Infos zusammengetragen.
Titel: Antw:AskSin++ Library
Beitrag von: Jochen222 am 22 November 2018, 08:34:43
Da ich noch eine Sprachausgabe für die Homematic suchte habe ich mir mal den Wiffi Voice nachgebaut (nur ESP8266 Modul mit dem DF-Player-Mini). Die HexFiles und MP3´s gibt es hier:
https://www.stall.biz/project/wiffi-voice-hausautomation-mit-ansage

Den DFPlayer gibts für ca. 2€, dieser hat sogar schon einen Audio Verstärker eingebaut:
https://www.aliexpress.com/item/DFPlayer-Mini-MP3-Player-Module-MP3-Voice-Module-for-Arduino-DIY-Supporting-TF-Card-and-USB/32691455792.html



Schöner wäre jedoch ein Nachbau auf Asksinpp Basis, quasi ein  DIY - "HM-OU-CFM-TW".

Gibt es dazu schon Ansätze bzw. einen passendes Asksinpp-Device?



Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 November 2018, 12:06:59
Nein gibt es nicht - aber wenn ich das jetzt so auf die Schnelle richtig verstenden habe, funktioniert der HM-OU-CFM-TW wie ein Dimmer. Es kann das Level (aka Song Nummer) gesetzt werden. Dieser wird dann abgespielt. Wahrschenlich stellt sich der Channel wieder automatisch auf 0 zurück, wenn der Song abgespielt worden ist.
Die LED ist ein einfaccher Switch-Channel, der eine LED ansteuert.
So grob müssten die meisten Bausteine vorhanden sein.
Titel: Antw:AskSin++ Library
Beitrag von: Saharel am 23 November 2018, 08:50:16
Hi,

ich habe einen THSensor gebaut und brauche nen Tip für eine Anpassung...

Ich habe das payload angepasst da ich versehentlich einen BMP280 anstatt einen BME280 in China bestellt habe, it works.


class WeatherEventMsg : public Message {
  public:
    void init(uint8_t msgcnt, int16_t temp, uint16_t airPressure, uint8_t power, bool batlow) {
      uint8_t t1 = (temp >> 8) & 0x7f;
      uint8_t t2 = temp & 0xff;
      if ( batlow == true ) {
        t1 |= 0x80; // set bat low bit
      }
      Message::init(0xf, msgcnt, 0x70, (msgcnt % 20 == 1) ? BIDI : BCAST, t1, t2);
      pload[0] = 0;   //zero for humidity
      pload[1] = ((airPressure) >> 8) & 0xff;
      pload[2] = (airPressure) & 0xff;
      pload[3] = power;
    }
};


Was nicht funktioniert ist die Spannung zu übertragen.. bzw wird kein Reading erzeugt.... ist das die falsche Stelle? Kann der THSensor voltage überhaupt als Reading in FHEM abbilden?
Fragen über Fragen ;)

Wenn ich übrigens den die variabel "power" an "pload[0]" übergebe bekomme ich die Daten im reading humidity, also die Übertragung an sich geht.

Ansonsten bleibt mir noch zu sagen ....... Ich liebe diese Library meine Frau nicht so 8) :P
Titel: Antw:AskSin++ Library
Beitrag von: papa am 23 November 2018, 09:21:30
Das geht leider nicht so einfach. Wenn Du die Daten in der Message änderst, musst Du auch das FHEM-Addon anpassen, da dieses die Nachricht verarbeitet.
Es gibt allerdings das generische Sensordevice (https://forum.fhem.de/index.php/topic,57486.msg804110.html#msg804110). Da kannst Du dann den Inhalt der Nachricht durch ein Attribute definieren.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 23 November 2018, 12:29:42
@Saharel
Das Einfachste für dich wäre, die payload so zu lassen wie sie ist und nur die Feuchtigkeit im sketch auf 0 zu setzen (bzw. ggf. wird sie sowie so auf 0 initialisiert).
Dann musst du nichts am FHEM script anpassen..
Titel: Antw:AskSin++ Library
Beitrag von: molnitza am 24 November 2018, 19:25:46
Ich habe eben versucht ein Example Sketch von Askskin++ für meinen Panstamp AVR (1) zu kompilieren und war alles andere als erfolgreich. Das Ganze ist in Flickschuhsterei in diversen Libraries ausgeartet. Ich habe vorerst entnervt das Handtuch geworfen. Hat sich hier jemand ggf. schon einmal der Sache angenommen und kann mir hilfreiche Hinweise geben?
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 25 November 2018, 01:36:48
PanStamp AVR 1 und 2 sind ja im Prinzip gleich. Ich nutze die auch. Neuste Arduino IDE und AskSin Lib? Und was hast du ausgewählt in der IDE, den Panstamp AVR darfst du da nicht nehmen! Nehme ein Arduino Pro/Pro Mini  mit 3,3V und 8 MHz oder sowas, etwas was passt.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: molnitza am 25 November 2018, 13:55:01
Hallo Daniel,

danke für die Informationen. Ich hatte tatsächlich panstamp als Board ausgewählt und nicht den Arduino Mini. Das kompilieren läuft jetzt schon einmal fehlerfrei durch. Lässt sich der panStick v1.3 dann noch für den Upload nutzen oder sollte ich doch lieber meinen USB-Prog wie der aus der Versenkung holen? Momentan bekomme ich zumindest nichts über den panStick auf den panStamp hochgeladen.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 25 November 2018, 18:20:19
Nee Flashen musst du schon klassisch per USB. Oder du hast ein Wireless Bootloader drauf, aber ich mach das per USB und gut ist.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: meddie am 03 Dezember 2018, 11:50:34
Hallo zusammen,

bitte nicht prügeln wenn die Frage hier schon mal irgendwo gefallen ist, ich habe den Anfang des Threads mal durchgelesen, aber nicht fündig geworden. Die AskSin++  ermöglich ja den Bau einiger Sensoren die Homematic kompatibel sind aber auch einige die es so nicht gibt, man muss hier in der CCU2/3 den Cuxd Addon installieren und z.B. den JP HB Addon. Aber wie steht es wenn man gar keine CCU einsetzt. Ich habe nur den Lanconfig Adapter von HM im Einsatz und in FHEM eingebunden. Untertützt FHEM all die Geräte von Haus aus oder wie muss ich den hier vorgehen?

Vielen Dank im Voraus und schöne Grüße
Eddie
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 03 Dezember 2018, 12:02:20
Für Geräte die es nicht offiziell gibt brauchst du ein entsprechend angepasstes Perl Script (quasi das CCU Addon für FHEM)
z.B. so was
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1/FHEM (https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1/FHEM)
Titel: Antw:AskSin++ Library
Beitrag von: meddie am 03 Dezember 2018, 22:44:09
Ok, verstehe! Das heißt wenn hier sowas nicht dabei ist,
https://github.com/jp112sdl/HB-UNI-Sen-CAP-MOIST

Dann muss ich mir wohl eine CCU (Raspi und das Funkmodul hätte ich hier liegen) herrichten?

Danke und schöne Grüße
Eddie
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 04 Dezember 2018, 19:15:23
Zitat von: meddie am 03 Dezember 2018, 22:44:09
Ok, verstehe! Das heißt wenn hier sowas nicht dabei ist,
https://github.com/jp112sdl/HB-UNI-Sen-CAP-MOIST
Dann muss ich mir wohl eine CCU (Raspi und das Funkmodul hätte ich hier liegen) herrichten?
Danke und schöne Grüße
Eddie

Hmm, eine RaspberryMatic betreiben nur um Werte von Homebrew Geräten nach FHEM zu bekommen? Klingt umständlich und ich kann nicht sagen ob das Problem damit gelöst wird, sprich Messages von Homebrew Geräten korrekt ankommen.
Einfacher m.E. ein Perl Script nach Beispiel an den HB-UNI-Sen-CAP-MOIST anzupassen..
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 Dezember 2018, 20:09:27
Wir müssen mal überlegen, wie wir hier die Unterstützung auf beiden Systemen organisieren können. Ohne doppelte oder veraltete Sachen. Vielelicht über ein zentrales Git-Repository, wo nur die Addons drin sind.
Titel: Antw:AskSin++ Library
Beitrag von: meddie am 04 Dezember 2018, 22:10:02
Zitat von: Tom Major am 04 Dezember 2018, 19:15:23
Einfacher m.E. ein Perl Script nach Beispiel an den HB-UNI-Sen-CAP-MOIST anzupassen..

Für mich nicht, mit programmieren habe ich es nicht so leider leider leider  :'( :'( :'(
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 04 Dezember 2018, 22:45:04
mag vielleicht mal einer der Experten hier erklären, wie man solche Skrpte für FHEM erstellt bzw modifiziert?

Es gibt sehr viele schöne Sensoren, die auf AskSin++ aufbauen, nur leider hakt es dann bei der Integration in FHEM

Jetzt extra ne CCU zu kaufen, nur weil ein paar Bytes an der richtigen Stelle fehlen kann ja nicht der Weg sein
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 Dezember 2018, 13:53:32
Das ist leider nicht ganz so einfach zu erklären :-(
Ich habe da viel rumprobiert und versucht zuerst mal die Sachen aus der HMConfig.pm zu verstehen.

Im Prinzip muss (siehe auch die Geräte in HMConfig_AskSinPPCustom.pm)

Da ich bekennender Perl-Hasser bin, weiß ich auch nicht, ob das nicht noch alles viel besser/einfacher geht.
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 09 Dezember 2018, 01:41:26
Zitat von: Wzut am 19 März 2018, 17:35:09
Bingo, so scheint es zu klappen. regSet lowBatLimitTHPL 1.1 hat dann CMDs_pending zur Folge
Bei der nächsten Übertragung der Sensorwerte konnte ich in der seriellen Konsole sehen : Config Changed  List 0 , lowBatLimitTHPL : 11
und CMDs done. set getConfig , wieder CMDs_pending , nach der nächsten Übertragung und CMDs done liefert auch get regList den neuen Wert.

Um nun den Sketch von Tom Major als echten Ersatz für den Unisensor benutzen zu können müsste nur noch geklärt werden wie man den Wert für die Höhe zum Sensor überträgt, ( das ist wohl z.Z. nicht vorgesehen ) bzw. wie setzt man von FHEM aus das neue Register für den Sendeintervall.

Hänge mich mal hier mit der gleichen Frage an: hat es jemand geschafft das Sendeintervall für den HB-UNI-Sensor1 aus Fhem einstellen zu können? Alles andere funktioniert 1a - top !
In der Register Liste sehe ich leider nur:


list:         register | range              | peer     | description
   0: altitude         |   0 to 10000m      |          | Altitude for calculate air pressure at see level in meter.
   0: burstRx          |     literal        |          | device reacts on Burst options:off,on
   0: ledMode          |     literal        |          | LED mode options:off,on
   0: lowBatLimit      |   1 to 5V          |          | Low batterie limit, step 0.1 V.
   0: pairCentral      |   0 to 16777215    |          | pairing to central
   0: transmDevTryMax  |   1 to 10          |          | max message re-transmit
   1: sign             |     literal        |          | signature (AES) options:on,off


Andreas
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 09 Dezember 2018, 01:56:34
Hmm, bei @kpwg funktioniert das so für die Höhe einstellen:
Zitat"Ich konnte bei meinem THPL Sensor mit BME280 und MAX44009 über getConfig // Config drücken // set regSet altitude 590 // Config drücken // getConfig // Config drücken die Höhe einstellen. Bitte berichtigt mich, wenn ich da zu viel drücke und mache- so hat es jedenfalls funktioniert ::)"

Das geht nicht bei dir fürs Sendeintervall? Aktuelles Firmware-Sketch und Perl script verwendet?
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 09 Dezember 2018, 02:13:33
Zitat von: Tom Major am 09 Dezember 2018, 01:56:34
Hmm, bei @kpwg funktioniert das so für die Höhe einstellen:
Das geht nicht bei dir fürs Sendeintervall? Aktuelles Firmware-Sketch und Perl script verwendet?

nein leider nicht. Er verwendet ja


set regSet altitude 590


und das passt auch da in der Register-List das Register 'altitude' vorhanden ist. Aber leider gibt es kein Register für ein Sendeintervall sonst hätte ich das genau so probiert. Die Info hatte ich nämlich auch schon auf Github unter


https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1


am Ende der Readme.md gefunden und war guten Mutes das analog zu konfiguerien.

Sehe gerade auch im Fhem Modul:


# Register model mapping
$HMConfig::culHmRegModel{'HB-UNI-Sensor1'} = {
    'burstRx'         => 1,
    'lowBatLimit'     => 1,
    'ledMode'         => 1,
    'transmDevTryMax' => 1,
    'altitude'        => 1


Bin jetzt net so der Coding-Guru ... denke mal da müsste doch die Info hinterlegt sein?

Meine Sensor FW+ HMConfig_UniSensor1.pm sind aktuell.

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 09 Dezember 2018, 13:17:55
Habe mir gerade das Perl script noch mal zu Gemüt geführt, da fehlt tatsächlich das Define des updateIntervall Registers, hat noch keiner gemerkt, bei mir auf RaspberryMatic ging das Einstellen immer einwandfrei  ;)

Glaube den Fehler gefixt zu haben, habe gerade commited. Bitte neustes Perl script testen ob es damit geht - ich glaube FHEM braucht einen Restart oder reicht ein reload für das geänderte .pm file?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 09 Dezember 2018, 17:11:29
Zitat von: papa am 09 November 2018, 10:16:29
Wer sich für die derzeit möglichen Nachbauten/Eigenbauten interessiert, möge mal nen Blick in das AskSin++ Collection (https://github.com/jp112sdl/AskSinPPCollection) Github werfen. Dort hat Jerome jede Menge Infos zusammengetragen.

Christoph (hier leider nicht vertreten) hat sich die Mühe gemacht und die Übersicht user-friendly gestaltet.
Der Link ist nun etwas anders: https://jp112sdl.github.io/AskSinPPCollection
Titel: Antw:AskSin++ Library
Beitrag von: Klaus0815 am 09 Dezember 2018, 17:50:44
Ich kopiere es mal hier rein, weiss nicht ob alle von hier den anderen Thread lesen

Es gibt Probleme mit diversen CC1101-Modulen, die wohl auf der falschen Frequenz senden (leichter Offset)

https://forum.fhem.de/index.php/topic,91740.0.html (https://forum.fhem.de/index.php/topic,91740.0.html)

Bestünde evtl. bei der AskSIn++-Library die Möglichkeit, die Sendefrequenz zu verändern? Müsste evtl. ein zusätzliches Register gesetzt werden oder irgendwas wird falsch initialisiert?


Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 10 Dezember 2018, 01:33:16
Zitat von: Tom Major am 09 Dezember 2018, 13:17:55
Habe mir gerade das Perl script noch mal zu Gemüt geführt, da fehlt tatsächlich das Define des updateIntervall Registers, hat noch keiner gemerkt, bei mir auf RaspberryMatic ging das Einstellen immer einwandfrei  ;)

Glaube den Fehler gefixt zu haben, habe gerade commited. Bitte neustes Perl script testen ob es damit geht - ich glaube FHEM braucht einen Restart oder reicht ein reload für das geänderte .pm file?

habe jetzt mal den neusten Stand (.pm + FW) vom Git gezogen und konnte jetzt das Sendeintervall in Fhem einstellen und soweit funktioniert auch alles sehr gut - nochmals: Top Leistung :-)
Was mir bei meinen Tests aufgefallen ist:

1) kann den LED Mode via


set <devicename> regSet ledMode <on|off>


leider nicht ändern. Bekomme folgende Meldung in Fhem:


cannot calculate value. Please issue set HM_A5A501 getConfig first - invalid: not supported by FW version


2) das Lesen der Register-Werte via getConfig geht bei mir nur sehr sporadisch. Keine Ahnung woran das liegt. Das Setzen funktioniert aber einwandfrei.


Habe auch mal genauere Verbrauchsmessungen (via Fluke 8808a + Digi Oszi) gemacht, um die Batterielebensdauer abzuschätzen. Verwendet habe ich die Platine aus


https://forum.fhem.de/index.php/topic,73954.msg656384.html#msg656384


Folgende Werte sind dabei herausgekommen:


Standbystrom       ~20uA
Strom beim Senden  ~7mA für ca. 70ms


Das sollten theoretisch ca. ~421 Tage Lebensdauer bei einer CR2032 (230mAh) mit 20 Übertragungen pro Std ergeben. Keine Ahnung wie das Spannungsverhältnis einer CR2032 gegen Ende der entnommenen Kapazität aussieht und somit der Sensor überhaupt noch senden kann - würde vermuten, dass das weniger Tage in der Realität sind. Falls jemand auch Werte gemessen hat, wäre nett mal quer zu checken ob die im ähnlichen Bereich liegen.

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 Dezember 2018, 01:51:16
Hallo Andreas,

freut mich das der Fix mit dem Sendeintervall gleich funktioniert hat.

LED abschalten ist momentan im UniSensor1 (noch) nicht implementiert, hatte ich vor und steht auf auf der Liste, hat es aber noch nicht in die oberen Prios geschafft  ;)

Lesen der Werte nur sporadisch, da kann ich nicht viel sagen, du drückst schon den Taster wenn du Werte lesen willst? (BIDI, BCAST Problematik, im Sketch kommentiert)

20uA Sleep ist zu viel, das geht besser, siehe
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SleepTest (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SleepTest)
Eventuell BOD aktiv?

Und 7mA beim Senden kommen mir etwas wenig vor, im Datenblatt stehen 16-35 mA je nach output power.

Grüße Tom
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 10 Dezember 2018, 02:34:01
Hallo Tom,

wg. LED: ah ok. Dann warte ich mal - das eilt für mich net.
wg. Lesen der Werte nur sporadisch: ja drücke brav den Config Taster - hab' schon ne Delle in der Fingerkuppe ;-)
Werde noch mehrere Unisensoren aufbauen; mal schauen ob das da auch auftritt.

habe gerade auch nochmal mit meinem STK600 die Fuses gecheckt:


BODLEVEL = DISABLED
RSTDISBL = [ ]
DWEN =     [ ]
SPIEN =    [X]
WDTON =    [ ]
EESAVE =   [ ]
BOOTSZ =   2048W_3800
BOOTRST =  [ ]
CKDIV8 =   [ ]
CKOUT =    [ ]
SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_65MS

EXTENDED = 0xFF (valid)
HIGH = 0xD9 (valid)
LOW = 0xE2 (valid)


Also keine BOD aktiv.

Habe meine Messung mit 3V Versorgung + BME280 + MAX44009 Breakout gemacht. Der Standby kam mir ehrlich gesagt auch zu hoch vor (komme in anderen ATMega Projekten teilweise in den nA Bereich beim Sleep). Habe zur Zeit noch den int. RC gefused - da auf dem Board ja ein Uhrenquartz ist: funktioniert dein Sketch auch damit (wg. Timing etc.)? Normalerweise spart das auch noch ...

Wg. Sendestrom: ok - kann nochmal mit Fast Rate sampeln (hatte das mit Medium gemacht) und nochmal den Max-Wert Speicher verwenden. Das scheint in der Tat nach Datenblatt zu wenig.
Das Fluke misst an sich sehr gut (hat einen Messverstärker). Werde mal weiter schauen ...

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Dezember 2018, 09:14:02
Zitat von: Tom Major am 10 Dezember 2018, 01:51:16
LED abschalten ist momentan im UniSensor1 (noch) nicht implementiert, hatte ich vor und steht auf auf der Liste, hat es aber noch nicht in die oberen Prios geschafft  ;)
Das könnten wir auch direkt in die Lib einbauen. Das Register ist auf jeden Fall schon definiert. Soll bei Off die Led gar nichts mehr machen oder nur die Signalisierung beim Senden/Empfangen abgeschalten werden ?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Dezember 2018, 09:15:06
Zitat von: fhemfreund am 10 Dezember 2018, 02:34:01
wg. Lesen der Werte nur sporadisch: ja drücke brav den Config Taster - hab' schon ne Delle in der Fingerkuppe ;-)
Werde noch mehrere Unisensoren aufbauen; mal schauen ob das da auch auftritt.
Könntest Du bitte mal die seriellen Ausgaben loggen, wenn es auftritt. Vielleicht können wir da was sehen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Dezember 2018, 09:15:54
Zitat von: Klaus0815 am 09 Dezember 2018, 17:50:44
Bestünde evtl. bei der AskSIn++-Library die Möglichkeit, die Sendefrequenz zu verändern? Müsste evtl. ein zusätzliches Register gesetzt werden oder irgendwas wird falsch initialisiert?
Man kann wahrscheinlich alles machen. Aber dazu müssten wir erst mal ganz genau wissen, wo das Problem wirklich liegt und wie es zu fixen ist.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 10 Dezember 2018, 09:32:38
Zitat von: papa am 10 Dezember 2018, 09:14:02
Das könnten wir auch direkt in die Lib einbauen. Das Register ist auf jeden Fall schon definiert. Soll bei Off die Led gar nichts mehr machen oder nur die Signalisierung beim Senden/Empfangen abgeschalten werden ?

Original HM Devices deaktivieren die LED nur beim Senden.
Beim Anlernen/Reset/Init blinkt sie trotzdem.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Dezember 2018, 09:45:06
Zitat von: jp112sdl am 10 Dezember 2018, 09:32:38
Original HM Devices deaktivieren die LED nur beim Senden.
Beim Anlernen/Reset/Init blinkt sie trotzdem.
Beim Senden wird das ledMode Register jetzt beachtet. Für alle Geräte, welche dieses Register nicht haben, ist der Default auf "On" gesetzt.
Titel: Antw:AskSin++ Library
Beitrag von: scuba am 10 Dezember 2018, 11:08:21
Hallo zusammen,

Ich würde gerne die Tasten meines HM-LC-Dim1TPBU-FM für zusätzliche Schaltvorgänge verwenden. Die Möglichkeit den Aktorstatus mit "notifys" zu verarbeiten ist mir zwar bekannt allerdings für meinen Anwendungsfall nicht brauchbar.

Anders als beim HM-LC-Dim1PWM-CV handelt es sich hier ja um einen Phasenabschnittdimmer (Nullduchgangssynchronisation) mit zusätzlicher Temperaturüberwachung über einen NTC (103AT-2) und Überstromerkennung. Soweit ich das gesehen habe ist das soweit (noch?) nicht in AskSin++ implementiert. Gibt's eventuell schon Bestrebungen oder Ansätze für eine Umsetzung ?

lg
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Dezember 2018, 11:41:49
Ich nicht
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 Dezember 2018, 12:40:30
Zitat von: papa am 10 Dezember 2018, 09:45:06
Beim Senden wird das ledMode Register jetzt beachtet. Für alle Geräte, welche dieses Register nicht haben, ist der Default auf "On" gesetzt.
Sehr gut.
Auf Sketch Seite muss ich nur dafür sorgen das DREG_LEDMODE in der List0 erscheint, das wars, korrekt?
(Und schauen das die die xml und Perl scripte das Register berücksichtigen).
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Dezember 2018, 13:13:24
Genau - einfach das DREG_LEDMODE mit in die List0-Definition aufnehmen und in der defaults() Methode auf On (also 1) stellen.
Titel: Antw:AskSin++ Library
Beitrag von: DeepCore am 10 Dezember 2018, 13:30:02
Hallo zusammen!

Zitat...mit in die List0-Definition aufnehmen ...

Wo kann ich diese Definitionen finden? Ich vermute mal, dass die aus den Homematic XML-Dateien generiert wurden/werden, oder?
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 Dezember 2018, 17:32:09
Zitat von: DeepCore am 10 Dezember 2018, 13:30:02
Hallo zusammen!
Wo kann ich diese Definitionen finden? Ich vermute mal, dass die aus den Homematic XML-Dateien generiert wurden/werden, oder?

Die device registers stehen in Register.h
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 10 Dezember 2018, 18:36:16
Zitat von: fhemfreund am 10 Dezember 2018, 02:34:01
...
Habe meine Messung mit 3V Versorgung + BME280 + MAX44009 Breakout gemacht. Der Standby kam mir ehrlich gesagt auch zu hoch vor (komme in anderen ATMega Projekten teilweise in den nA Bereich beim Sleep). Habe zur Zeit noch den int. RC gefused - da auf dem Board ja ein Uhrenquartz ist: funktioniert dein Sketch auch damit (wg. Timing etc.)? Normalerweise spart das auch noch ...

...

@Tom,
bringe das nochmal hier hoch, da es ev. untergegangen ist: funktioniert dein Sketch auch mit 32Khz Takt? Würde das mal im Rahmen meiner Stromverbrauchsmessungen dann probieren ...

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 Dezember 2018, 23:53:31
Zitat von: fhemfreund am 10 Dezember 2018, 18:36:16
@Tom,
bringe das nochmal hier hoch, da es ev. untergegangen ist: funktioniert dein Sketch auch mit 32Khz Takt? Würde das mal im Rahmen meiner Stromverbrauchsmessungen dann probieren ...

Ja das geht, du kannst dich z.B. an papas Example HM-WDS10-TH-O orientieren.
Basically die codestellen die mit sysclock arbeiten auf rtc ändern..

32k Quarz spart dir ungefähr 3,5 von den 4uA mit aktiviertem watchdog, siehe 'Power-Down Supply Current vs. VCC' im Datenblatt.
Solange du aber 20uA hast ist diese Änderung nicht so entscheidend.
Kann gut sein dass es an den breakout boards liegt, die haben oft auch einen LDO drauf. Ich werde meine bei Gelegenheit auch mal messen was die verbrauchen.
Und auch mal den Sendestrom, das hatte ich schon länger vor.

Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 Dezember 2018, 23:58:26
@papa
Ich wollte in einem neuem Projekt die AltSoftSerial
https://github.com/PaulStoffregen/AltSoftSerial (https://github.com/PaulStoffregen/AltSoftSerial)
zusammen mit AskSinPP verwenden, habe aber gesehen das diese und auch deine Lib den 16bit Timer1 verwenden, und ich glaube du nimmst auch den Timer2 her, habe zumindest code Stellen dafür gesehen.
Kann ich aber zumindest den Timer0 für meine Zwecke zusammen mit der AskSinPP verwenden?
Danke,
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 11 Dezember 2018, 01:51:21
Zitat von: Tom Major am 10 Dezember 2018, 23:53:31
Ja das geht, du kannst dich z.B. an papas Example HM-WDS10-TH-O orientieren.
Basically die codestellen die mit sysclock arbeiten auf rtc ändern..

32k Quarz spart dir ungefähr 3,5 von den 4uA mit aktiviertem watchdog, siehe 'Power-Down Supply Current vs. VCC' im Datenblatt.
Solange du aber 20uA hast ist diese Änderung nicht so entscheidend.
Kann gut sein dass es an den breakout boards liegt, die haben oft auch einen LDO drauf. Ich werde meine bei Gelegenheit auch mal messen was die verbrauchen.
Und auch mal den Sendestrom, das hatte ich schon länger vor.

Habe jetzt nochmal mit hoher Abtastung (100 Werte/s) gemessen und siehe da - es kommt etwas sinnvolleres heraus: ~ 28mA beim Senden.
Der gemessene Standbystrom ist wahrscheinlich korrekt, da auf meinen Breakout-Boards jeweil LDOs vom Typ 662K verbaut sind. Diese haben einen Ruhestrom von ~ 7 ... 15uA.
Ein MCP1700 verbraucht nur ca. 1.6 ... 4uA und ist pinkompatibel. Ev. tausche ich und messe nochmal.

Mit den neuen Werten komme ich auf ~310Tage. Eine Reduktion um 2uA im Standby (ev. via Uhrenquartz) kommt auf ~330Tage.

>Basically die codestellen die mit sysclock arbeiten auf rtc ändern.
heisst das einfach von z.B.


battery.init(seconds2ticks(12UL * 60 * 60), sysclock);


auf


battery.init(seconds2ticks(12UL * 60 * 60), rtc);


?

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Dezember 2018, 08:59:13
Zitat von: Tom Major am 10 Dezember 2018, 23:58:26
@papa
Ich wollte in einem neuem Projekt die AltSoftSerial
https://github.com/PaulStoffregen/AltSoftSerial (https://github.com/PaulStoffregen/AltSoftSerial)
zusammen mit AskSinPP verwenden, habe aber gesehen das diese und auch deine Lib den 16bit Timer1 verwenden, und ich glaube du nimmst auch den Timer2 her, habe zumindest code Stellen dafür gesehen.
Kann ich aber zumindest den Timer0 für meine Zwecke zusammen mit der AskSinPP verwenden?
Danke,
Die Sysclock wird standardmäßig an den Timer1 angebunden. Die RTC nutzt den Timer2 - aber nur, wenn sie auch im Sketch benutzt wird. Ist also im Prinzip verwendbar. Der Timer0 wird glaube ich von der Arduinobasis für die millis() verwendet. AskSinPP braucht millis() nicht - kann also auch für andere Sachen genutzt werden. Die millis() stimmen eh nicht mehr, wenn der Sleep benutzt wird.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Dezember 2018, 09:00:39
Zitat von: fhemfreund am 11 Dezember 2018, 01:51:21
>Basically die codestellen die mit sysclock arbeiten auf rtc ändern.
heisst das einfach von z.B.

battery.init(seconds2ticks(12UL * 60 * 60), sysclock);

auf

battery.init(seconds2ticks(12UL * 60 * 60), rtc);

Nicht ganz. Die RTC tickt immer im Sekundentakt und braucht somit die Umrechnung in ticks nicht - also nur

battery.init(12UL * 60 * 60, rtc);

Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 11 Dezember 2018, 12:23:34
Zitat von: papa am 11 Dezember 2018, 08:59:13
Die Sysclock wird standardmäßig an den Timer1 angebunden. Die RTC nutzt den Timer2 - aber nur, wenn sie auch im Sketch benutzt wird. Ist also im Prinzip verwendbar. Der Timer0 wird glaube ich von der Arduinobasis für die millis() verwendet. AskSinPP braucht millis() nicht - kann also auch für andere Sachen genutzt werden. Die millis() stimmen eh nicht mehr, wenn der Sleep benutzt wird.

Danke für die Info. millis() hatte ich gar nicht auf dem Schirm, aber stimmt, habe nachgeschaut, Arduino verwendet Timer0 dafür.
Da ich die RTC normalerweise nicht verwende werde ich Timer2 für die SoftSerial nehmen.
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 11 Dezember 2018, 17:04:45
Zitat von: papa am 11 Dezember 2018, 09:00:39
Nicht ganz. Die RTC tickt immer im Sekundentakt und braucht somit die Umrechnung in ticks nicht - also nur

battery.init(12UL * 60 * 60, rtc);


Ok - danke für die Info. Habe dann mal alle Codestellen zusammengefasst, die von:


battery.init(seconds2ticks(12UL * 60 * 60), sysclock);
bool runready() { return sysclock.runready() || BaseHal::runready(); }
sysclock.cancel(*this);
trigger(sysclock);
sysclock.add(*this);


nach


battery.init(12UL * 60 * 60), rtc);
bool runready() { return rtc.runready() || BaseHal::runready(); }
rtc.cancel(*this);
trigger(rtc);
rtc.add(*this);


geändert werden müssen. Wenn das so korrekt ist würde ich es mal versuchen ... (und dann wieder messen)

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Dezember 2018, 19:14:07
Zitat von: fhemfreund am 11 Dezember 2018, 17:04:45
Ok - danke für die Info. Habe dann mal alle Codestellen zusammengefasst, die von:


battery.init(seconds2ticks(12UL * 60 * 60), sysclock);
bool runready() { return sysclock.runready() || BaseHal::runready(); }
sysclock.cancel(*this);
trigger(sysclock);
sysclock.add(*this);


nach


battery.init(12UL * 60 * 60), rtc);
bool runready() { return rtc.runready() || BaseHal::runready(); }
rtc.cancel(*this);
trigger(rtc);
rtc.add(*this);


geändert werden müssen. Wenn das so korrekt ist würde ich es mal versuchen ... (und dann wieder messen)

Andreas
So einfach ist es nicht. Die sxscöock wird intern immer noch gebraucht. Bitte mal den ganzen Sketch anhängen bzw. in schon vorher erwähnten Beispiel ansehen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 11 Dezember 2018, 19:29:00
Zitat von: fhemfreund am 11 Dezember 2018, 17:04:45
Ok - danke für die Info. Habe dann mal alle Codestellen zusammengefasst, die von:


battery.init(seconds2ticks(12UL * 60 * 60), sysclock);
bool runready() { return sysclock.runready() || BaseHal::runready(); }
sysclock.cancel(*this);
trigger(sysclock);
sysclock.add(*this);


nach


battery.init(12UL * 60 * 60), rtc);
bool runready() { return rtc.runready() || BaseHal::runready(); }
rtc.cancel(*this);
trigger(rtc);
rtc.add(*this);


geändert werden müssen. Wenn das so korrekt ist würde ich es mal versuchen ... (und dann wieder messen)

Andreas

Es fehlt zumindest auch
rtc.init();
und
hal.activity.savePower<SleepRTC>(hal);
in deiner Auflistung.
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 11 Dezember 2018, 20:22:05
Zitat von: papa am 11 Dezember 2018, 19:14:07
So einfach ist es nicht. Die sxscöock wird intern immer noch gebraucht. Bitte mal den ganzen Sketch anhängen bzw. in schon vorher erwähnten Beispiel ansehen.

ok. Dann muss ich leider passen - habe mir mal dein HM-WDS10-TH-O Beispiel angeschaut und konnte auch ein paar Ähnlichkeiten zu Tom's Code feststellen - es übersteigt aber doch meine Fähigkeiten das korrekt anzupassen.

@Tom - können wir deinen Code hier von papa mal checken lassen?

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 11 Dezember 2018, 22:50:50
Zitat von: fhemfreund am 11 Dezember 2018, 20:22:05
ok. Dann muss ich leider passen - habe mir mal dein HM-WDS10-TH-O Beispiel angeschaut und konnte auch ein paar Ähnlichkeiten zu Tom's Code feststellen - es übersteigt aber doch meine Fähigkeiten das korrekt anzupassen.

@Tom - können wir deinen Code hier von papa mal checken lassen?
Andreas

Klar, ist ja kein Geheimnis und basiert natürlich sowieso auf papas Beispielen.
Ich könnte dir wahrsch. eine Testversion mit RTC machen, aber nicht vor dem WE.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 11 Dezember 2018, 22:57:00
Zitat von: fhemfreund am 11 Dezember 2018, 01:51:21
Habe jetzt nochmal mit hoher Abtastung (100 Werte/s) gemessen und siehe da - es kommt etwas sinnvolleres heraus: ~ 28mA beim Senden.
Der gemessene Standbystrom ist wahrscheinlich korrekt, da auf meinen Breakout-Boards jeweil LDOs vom Typ 662K verbaut sind. Diese haben einen Ruhestrom von ~ 7 ... 15uA.
Ein MCP1700 verbraucht nur ca. 1.6 ... 4uA und ist pinkompatibel. Ev. tausche ich und messe nochmal.
Mit den neuen Werten komme ich auf ~310Tage. Eine Reduktion um 2uA im Standby (ev. via Uhrenquartz) kommt auf ~330Tage.

Habe mich heute etwas mit dem Ruhestrom der Sensor-/Breakout-Boards für BME280 und MAX44009 beschäftigt.

Tatsächlich verbrauchen die LDOs auf diesen Boards einige uA.
Habe mal versucht das ganze zu dokumentieren:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Ruhestrom#ruhestrom-mit-sensor-boards (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Ruhestrom#ruhestrom-mit-sensor-boards)

z.B. BME280 Board 5uA, ohne LDO 0,1uA, da kann man definitiv Batterielaufzeit für das Gerät rausholen  :)

Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 12 Dezember 2018, 01:23:22
Zitat von: Tom Major am 11 Dezember 2018, 22:50:50
Klar, ist ja kein Geheimnis und basiert natürlich sowieso auf papas Beispielen.
Ich könnte dir wahrsch. eine Testversion mit RTC machen, aber nicht vor dem WE.

Das wäre klasse. Dann warte ich auf deine Version und werde danach messen.

Den Ansatz die LDOs zu entfernen (statt einen MCP1700 zu nehmen) habe ich auch ins Auge gefasst. So wie es aussieht muss das (in meiner Konfiguration) nur für den MAX44009 gemacht werden.
Für den BME280 gibt es ein Breakout ohne LDO.

Mit dem Uhrenquartz+Breakouts ohne LDOs+abschaltbarer LED (=LedMode off) ist einiges an Optimierungspotential vorhanden. Mal angenommen der Ruhestrom kann auf 10uA gesenkt werden, dann sind das rechnerisch schon ~458 Tage.

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 12 Dezember 2018, 20:05:48
Zitat von: fhemfreund am 12 Dezember 2018, 01:23:22
Den Ansatz die LDOs zu entfernen (statt einen MCP1700 zu nehmen) habe ich auch ins Auge gefasst. So wie es aussieht muss das (in meiner Konfiguration) nur für den MAX44009 gemacht werden.
Für den BME280 gibt es ein Breakout ohne LDO.
Andreas

Hast du mal einen link auf ein BME280 Board ohne LDO? Möglichst mit der VIN-GND-SCL-SDA Reihenfolge der Pins.

Habe heute den LDO beim MAX44009 entfernt, Resultat:
Standby 0,7 uA statt 6 uA  8)

LED Abschaltmöglichkeit ist jetzt beim UniSensor1 drin und zumindest mit RaspberryMatic getestet.
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 12 Dezember 2018, 21:19:32
Zitat von: Tom Major am 12 Dezember 2018, 20:05:48
Hast du mal einen link auf ein BME280 Board ohne LDO? Möglichst mit der VIN-GND-SCL-SDA Reihenfolge der Pins.

Habe heute den LDO beim MAX44009 entfernt, Resultat:
Standby 0,7 uA statt 6 uA  8)

LED Abschaltmöglichkeit ist jetzt beim UniSensor1 drin und zumindest mit RaspberryMatic getestet.

Na das sieht doch gut aus - wir bekommen das super optimiert. Bin schon auf die RTC Version gespannt :-)
Theoretisch könnte man mit der RTC Version dann auch den LED Mode aus Fhem testen - oder?

Mein BME Board ist von hier:


https://www.ebay.de/itm/BME280-BMP280-digitaler-Barometer-Temperatur-Luftdrucksensor-od-Feuchte-Arduino/172471251481?hash=item2828167219:m:mG8pHpdu0AXQvlqdtEMVEeg:rk:3:pf:0


Andreas
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 14 Dezember 2018, 00:01:52
Zitat von: fhemfreund am 12 Dezember 2018, 21:19:32
Na das sieht doch gut aus - wir bekommen das super optimiert. Bin schon auf die RTC Version gespannt :-)
Theoretisch könnte man mit der RTC Version dann auch den LED Mode aus Fhem testen - oder?

Mein BME Board ist von hier:


https://www.ebay.de/itm/BME280-BMP280-digitaler-Barometer-Temperatur-Luftdrucksensor-od-Feuchte-Arduino/172471251481?hash=item2828167219:m:mG8pHpdu0AXQvlqdtEMVEeg:rk:3:pf:0


Andreas

Das BME Board ist etwas breiter wegen der 2 extra pins, aber gut, dafür ohne LDO. Würde wahrscheinlich wegen Preis und Abmessungen bei den Ali 4-pin Boards bleiben und den LDO entfernen.

LED Mode ist unabhängig von sysclock oder rtc und sollte jetzt schon von fhem aus testbar sein (mit meinem Perl script update von gerade eben).
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 16 Dezember 2018, 14:51:44
Zitat von: Tom Major am 14 Dezember 2018, 00:01:52
LED Mode ist unabhängig von sysclock oder rtc und sollte jetzt schon von fhem aus testbar sein (mit meinem Perl script update von gerade eben).

sehr gut - das teste ich dann mit der RTC FW Version zusammen (sobald diese verfügbar ist)

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 16 Dezember 2018, 20:11:29
Zitat von: fhemfreund am 16 Dezember 2018, 14:51:44
sehr gut - das teste ich dann mit der RTC FW Version zusammen (sobald diese verfügbar ist)
Andreas

das machen wir am besten per PN.
Titel: Antw:AskSin++ Library
Beitrag von: thunder1902 am 17 Dezember 2018, 15:34:09
Ich steig' beim AsksinPP von Papa nicht durch.
Gibt es irgend eine Art von "Hilfe" oder einer Doku?

Mein Ziel: Ich möchte einen möglichst Batterie-Sparsamen Sensor/Schalter bauen, der 2 Relais oder FETS schalten kann - UND jede Stunde mittels einem DS18B20 die Temperatur mist. Optional noch über den I2C Bus die Helligkeit (SHT10) und Luftdruck (BMP180). Also ein "Kombi-Schalt-Sensor".

Wie kann ich als "Laie" jetzt vorgehen?

Danke schonmal für eure Hilfe!!
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 17 Dezember 2018, 17:56:51
Zitat von: thunder1902 am 17 Dezember 2018, 15:34:09
Ich steig' beim AsksinPP von Papa nicht durch.
Gibt es irgend eine Art von "Hilfe" oder einer Doku?

Mein Ziel: Ich möchte einen möglichst Batterie-Sparsamen Sensor/Schalter bauen, der 2 Relais oder FETS schalten kann - UND jede Stunde mittels einem DS18B20 die Temperatur mist. Optional noch über den I2C Bus die Helligkeit (SHT10) und Luftdruck (BMP180). Also ein "Kombi-Schalt-Sensor".

Wie kann ich als "Laie" jetzt vorgehen?

Danke schonmal für eure Hilfe!!

Also das Thema (extrem) Batterie-sparenden Sensor bin ich gerade dabei mit Tom weiter zu verfolgen. Dauert aber noch etwas. Dieser hat einen Digital Eingang, Helligkeitsmessung (via Max 44009), Temp, Luftfeuchte und Druck (via BME280).

Der Sensor kann (einstellbar via Register) aus Fhem eingestellt werden (z.B. Sendezyklus, LED Mode an/aus usw.). Dazu gibt es ein Fhem Modul + FW von Tom. Und zwar hier:


https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1


Eine mögliche Platine dazu gibt es von Papa:


https://github.com/pa-pa/HMSensor/tree/master/HMSensor-CR2032


Prinzipiell gibt es auch Relais, die man vom Sensor (technisch gesehen) schalten könnte, allerdings müsste das in der FW+Fhem unterstützt werden. Beispiele, was alles schon möglich ist findet man z.B. hier:


https://jp112sdl.github.io/AskSinPPCollection/Grundlagen/



Andreas
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 20 Dezember 2018, 20:43:52
@papa

Komme nochmal auf mein Problem mit dem Lesen der Register in Fhem zurück:

Zitat von: papa am 10 Dezember 2018, 09:15:06
Könntest Du bitte mal die seriellen Ausgaben loggen, wenn es auftritt. Vielleicht können wir da was sehen.

Habe jetzt mal einen Trace über die serielle Konsole gemacht mit folgender Prozedur in Fhem:

1. set HM_A5A500 getConfig
2. Am Sensor den Config Button drücken
3. Check in Fhem auf 'CMDs processing' (muss 2x den Config Button drücken, weil ich zwischendrin die Meldung CMDs pending bekomme und sonst nichts weiter passieren würde)
4. Das Device hat am Ende 'RESPONSE TIMEOUT:RegisterRead'. Es funktioniert aber einwandfrei und auch das Setzen von Registerwerten funktioniert korrekt (z.B. updateIntervall)

Hier der Trace:


debounce
pressed
released
<- 1A 02 84 00 A5A500 000000 12 F1 03 55 4E 49 53 45 4E 53 30 30 31 70 01 01 01  - 532

-> 10 2A A0 01 F11034 A5A500 00 04 00 00 00 00 00  - 1609
<- 1A 2A A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 1748
waitAck: 00
<- 1A 2A A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 2400
waitAck: 00
<- 1A 2A A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 3049
waitAck: 00
<- 1A 2A A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 3700
waitAck: 00
<- 1A 2A A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 4349
-> 10 2B A0 01 F11034 A5A500 00 04 00 00 00 00 00  - 4648
waitAck: 00
<- 1A 2A A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 5005
-> 10 2B A0 01 F11034 A5A500 00 04 00 00 00 00 AA  - 5122
-> 0A 2A 80 02 F11034 A5A500 00  - 5246
waitAck: 01
<- 0E 2A 80 10 A5A500 F11034 02 23 00 00 00  - 5279
ignore 0F 02 86 10 639BE7 000000 0A BD 08 8E 00 40  - 13744
ignore 14 E0 80 5E 29F26F F11034 00 00 00 00 00 00 00 00 00 00 00  - 18268
ignore 10 45 86 53 4D1532 000000 00 4D 26 E6 00 03 69  - 18952
debounce
pressed
released
<- 1A 03 84 00 A5A500 000000 12 F1 03 55 4E 49 53 45 4E 53 30 30 31 70 01 01 01  - 20574

-> 10 2B A0 01 F11034 A5A500 00 04 00 00 00 00 00  - 21600
<- 1A 2B A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 21731
waitAck: 00
<- 1A 2B A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 22382
-> 0F 69 86 10 639BE8 000000 0A 98 C5 0D 0E 40  - 22458
waitAck: 00
<- 1A 2B A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 23037
waitAck: 00
<- 1A 2B A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 23689
waitAck: 00
<- 1A 2B A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 24340
-> 10 2C A0 01 F11034 A5A500 00 04 00 00 00 00 00  - 24739
waitAck: 00
<- 1A 2B A0 10 A5A500 F11034 02 0A 00 0B 00 0C 00 14 06 12 16 20 00 21 B4 22 00  - 24995
-> 10 2C A0 01 F11034 A5A500 00 04 00 00 00 00 00  - 25436
waitAck: 00
<- 0C 2B 80 10 A5A500 F11034 02 00 00  - 25638
ignore 14 E3 80 5E 29F26F F11034 00 00 00 00 00 00 00 00 00 00 00  - 32053


Andreas
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Dezember 2018, 21:42:18
waitAck: 00
Es wird auf eine Bestätigung der Zentrale gewartet, die aber leider nicht empfangen wird. Könntest Du das auch mal von einem zweiten unbeteiligten Gräte loggen. Dann sehen wir auch die Nachrrichten der Zentrale. Irgendwie ist das komisch.
Titel: Antw:AskSin++ Library
Beitrag von: PeMue am 03 Januar 2019, 21:36:29
Hallo,

Zitat von: papa am 20 Mai 2018, 22:39:42
Es gibt in examples/custom/HB-GEN-SENS (https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/HB-GEN-SENS) einen generischen Sensor, der Temperatur & Luftfeuchtigkeit sendet. Damit er in FHEM funktioniert, muss das Module HMConfig_AskSinPPCustom.pm (https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM) installiert werden - einfach in das FHEM Verzeichnis kopieren.
Nach dem Pairing muss noch dem FHEM-Device mitgeteilt werden, wie die Nachrichten zu interpretieren sind. Dazu muss das Custom-Attribute valueformat angelegt werden:
attr DEVICE userattr valuesformat
attr DEVICE valuesformat SPEC1 SPEC2

Dabei ist für jeden gesendeten Wert eine Spezifikation durch Freizeichen getrennt anzugeben. Die SPEC besteht aus 3 Teilen, wobei nur der erste zwingend notwendig ist:
Anzahl Bytes - 1, 2 oder 4 - gefolgt von einem 's' wenn vorzeichenbehaftet
Name des Reading - wenn angegeben wird der Wert in dieses Reading gespeichert - default valueX
Faktor - empfangener Wert wird durch den Faktor geteilt - default 1

Für das Beispiel ist folgende Spezifikation zu verwenden:
2s:temperature:10 1:humidity
Also die Temperatur wird mit 2 Byte übertragen. Der Wert ist um den Faktor 10 erweitert. Das erzeugte Reading wird temperature heißen. Der zweite Wert ist ein Byte lang und nur positiv. Er wird im Reading humidity gespeichert. Je nachdem, was gesendet wird, muss der Formatstring im Device angelegt werden.
Ich hoffe mal, das kann man irgendwie verstehen. Es gibt auch noch ein paar Vorbereitungen, um einfach neue Devices mit unterschiedlichen Channels "einfach" in FHEM anzumelden. Das versuche ich demnächst nochmal zu erklären.

ich habe gloob's Sketch (https://forum.fhem.de/index.php/topic,89857.msg823318.html#msg823318) für den Ultraschallsensor genommen, compiliert und auf einen Universalsensor aufgespielt. Die Werte kommen sauber, aber ich habe im Log folgende zyklische Meldungen:
2019.01.03 21:30:11 1: HB-GEN-SENS01 has 2 values (010202480D)
2019.01.03 21:33:28 1: HB-GEN-SENS01 has 2 values (010202490D)

Wie bekomme ich die weg, bzw. was ist bei mir noch falsch?

Danke + Gruß

Peter

Edit:
Und beim setzen des R-eventDlyTime Registers kommt folgende Meldung  :o:
R-eventDlyTime failed: supported register are eventDlyTime pairCentral sign

Irgend etwas scheint da nicht zu passen, hier ein List:
Internals:
   DEF        B513ED
   IODev      PMCUL01
   LASTInputDev PMCUL01
   MSGCNT     4870
   NAME       UG_Tank
   NOTIFYDEV  global
   NR         363
   NTFY_ORDER 50-UG_Tank
   PMCUL01_MSGCNT 4870
   PMCUL01_RAWMSG A0E2EA253B513EDF10000010204380D::-80:PMCUL01
   PMCUL01_RSSI -80
   PMCUL01_TIME 2019-01-03 21:43:11
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 UG_Tank_Values
   lastMsg    No:2E - t:53 s:B513ED d:F10000 010204380D
   protCmdDel 2
   protLastRcv 2019-01-03 21:43:11
   protResndFail 1 last_at:2019-01-03 21:39:46
   protSnd    4854 last_at:2019-01-03 21:43:11
   protState  CMDs_done
   rssi_at_PMCUL01 cnt:4870 min:-80 max:-64.5 avg:-70.12 lst:-80
   READINGS:
     2018-12-30 18:07:29   CommandAccepted yes
     2019-01-03 21:39:41   D-firmware      0.3
     2019-01-03 21:39:41   D-serialNr      US00000001
     2018-12-30 18:08:40   PairedTo        0xF10000
     2018-12-30 18:08:40   R-pairCentral   0xF10000
     2019-01-03 21:43:11   state           CMDs_done
     RegL_00.:
       VAL       
   helper:
     HM_CMDNR   46
     cSnd       ,01F10000B513ED00040000000000
     mId        F205
     regLst     ,0
     rxType     4
     supp_Pair_Rep 0
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +B513ED,00,00,00
       nextSend   1546548191.31786
       prefIO     
       rxt        0
       vccu       
       p:
         B513ED
         00
         00
         00
     mRssi:
       mNo        2E
       io:
         PMCUL01:
           -78
           -78
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         PMCUL01
       flg        A
       ts         1546548191.22091
       ack:
         HASH(0x1899fb0)
         2E8002F10000B513ED00
     rssi:
       at_PMCUL01:
         avg        -70.1276180698152
         cnt        4870
         lst        -80
         max        -64.5
         min        -80
     tmpl:
Attributes:
   IODev      PMCUL01
   autoReadReg 4_reqStatus
   expert     251_anything
   firmware   0.3
   model      HB-GEN-SENS
   room       3_Keller
   serialNr   US00000001
   subType    custom
   webCmd     getConfig:clear msgEvents


Internals:
   DEF        B513ED01
   NAME       UG_Tank_Values
   NOTIFYDEV  global
   NR         364
   NTFY_ORDER 50-UG_Tank_Values
   STATE      216 1.3
   TYPE       CUL_HM
   chanNo     01
   device     UG_Tank
   READINGS:
     2018-12-27 15:58:38   R-eventDlyTime  180 s
     2018-12-27 15:58:38   R-sign          off
     2019-01-03 21:43:08   batVoltage      1.3
     2019-01-03 21:43:08   complete        216.0 cm   1.3 V
     2019-01-03 21:43:08   distance        216
     2019-01-03 21:43:08   state           216 1.3
     2018-12-27 15:54:33   value1          3
     2018-12-27 15:54:33   value2          60
   helper:
     getCfgListNo
     regLst     ,1
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     role:
       chn        1
     tmpl:
Attributes:
   model      HB-GEN-SENS
   peerIDs   
   userReadings complete { sprintf("%3.1f cm   %3.1f V", ReadingsVal("$name", "distance", 0), ReadingsVal("$name", "batVoltage", 0)); }
   userattr   valuesformat
   valuesformat 2:distance:5 1:batVoltage:10
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Januar 2019, 23:29:22
Das Regsiter heisst einfach eventDlyTime - also ohne das "R-". Du kannst auch das hier zum Register setzen (https://forum.fhem.de/index.php/topic,94412.0.html) benutzen.
Wegen den Logeinträgen - bitte sicherstellen, dass die neueste Version der HMConfig_AskSinPPCustom.pm (https://github.com/pa-pa/AskSinPP/blob/master/examples/custom/contrib/FHEM/HMConfig_AskSinPPCustom.pm) genutzt wird. Da habe ich das Logging umgestellt.
Titel: Antw:AskSin++ Library
Beitrag von: PeMue am 04 Januar 2019, 21:00:52
Zitat von: papa am 03 Januar 2019, 23:29:22
Das Regsiter heisst einfach eventDlyTime - also ohne das "R-".
Wegen den Logeinträgen - bitte sicherstellen, dass die neueste Version der HMConfig_AskSinPPCustom.pm (https://github.com/pa-pa/AskSinPP/blob/master/examples/custom/contrib/FHEM/HMConfig_AskSinPPCustom.pm) genutzt wird. Da habe ich das Logging umgestellt.
Und schon funktioniert's, macht man es richtig.

Vielen Dank.

Gruß Peter
Titel: Antw:AskSin++ Library
Beitrag von: PeMue am 05 Januar 2019, 12:16:35
Hallo,

Zitat von: gloob am 01 August 2018, 10:03:37
Einstellen des Sendeintervalls
Das Sendeintervall steht per Default auf 180 Sekunden. Kann aber über das Setzen eines Registers geändert werden

set HM_xxxxxx_Values regSet eventDlyTime ZEIT_IN_SEKUNDEN


Nach dem Setzen des Intervalls muss der Konfig-Button am Sensor gedrückt werden um den Wert zu übernehmen.
so ganz klappt das bei mir noch nicht.
Ich habe verschiedene Szenarien durch (wie oben; setzen, getConfig auf Kanalebene, Taster drücken; setzen, getConfig auf Sensorebene, Taster drücken; ...), aber der Wert für das Sendeintervall wird nicht übernommen.
Wo bzw. wie kann ich suchen?

Internals:
   DEF        B513ED01
   NAME       UG_Tank_Values
   NOTIFYDEV  global
   NR         364
   NTFY_ORDER 50-UG_Tank_Values
   STATE      58.4 1.3
   TYPE       CUL_HM
   chanNo     01
   device     UG_Tank
   READINGS:
     2019-01-05 12:01:57   R-eventDlyTime  set_3600 s
     2018-12-27 15:58:38   R-sign          off
     2019-01-05 12:12:45   batVoltage      1.3
     2019-01-05 12:12:45   complete        58.4 cm   1.3 V
     2019-01-05 12:12:45   distance        58.4
     2019-01-05 12:12:45   state           58.4 1.3
     2018-12-27 15:54:33   value1          3
     2018-12-27 15:54:33   value2          60
   helper:
     getCfgListNo
     regLst     ,1
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     role:
       chn        1
     shadowReg:
       RegL_01.     08:00 21:BC 00:00
     tmpl:
Attributes:
   model      HB-GEN-SENS
   peerIDs   
   userReadings complete { sprintf("%3.1f cm   %3.1f V", ReadingsVal("$name", "distance", 0), ReadingsVal("$name", "batVoltage", 0)); }
   userattr   valuesformat
   valuesformat 2:distance:10 1:batVoltage:10


Danke + Gruß

Peter
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 Januar 2019, 16:27:20
Kannst Du mal die AUsgaben auf der seriellen Console loggen. Dann in FHEM das "set ......" ausführen und danach den KonfigTaster drücken.
Titel: Antw:AskSin++ Library
Beitrag von: PeMue am 06 Januar 2019, 15:02:06
Zitat von: papa am 05 Januar 2019, 16:27:20
Kannst Du mal die AUsgaben auf der seriellen Console loggen. Dann in FHEM das "set ......" ausführen und danach den KonfigTaster drücken.
Nachdem ich auch nicht OTA flashen kann (fail:notInBootLoader) habe ich den Verdacht, dass ich mit einer zu alten AskSin Library compiliert habe. Reicht die v3 (v3.0.2) nicht? Oder muss ich den aktuellen development branch (3.1.2) verwenden?
Vorher muss ich natürlich noch Debug anschalten und irgendwie ein Kabel zumindest den Tx Pin am Prozessor anlöten, im Layout ist natürlich nichts vorgesehen  :(.

Danke + Gruß

Peter
Titel: Antw:AskSin++ Library
Beitrag von: xkalle01 am 08 Januar 2019, 16:07:47
Hallo,
ich verfolge diesen Thread schon einige Zeit und habe drei HB-WDS10-TH-O
und drei MotionDetector HM-SEC-MDIR auf Basis der Universalsensor-Hardware im Berieb.

Dietmar63 hatte mir damals die Registerdefinitionen generiert, welche jetzt ja in der Motion.h integriert ist.
Zitat 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.

Jetzt meine Frage:
Kann ich mit dem jetzigen Stand der AskSinPP-Lib V3 den Regensensor von HomeMatic (HM-Sen-RD-O, rf_rd.xml ) implementieren?
Kann mir jemand die Registerdefinitionen generieren?
Oder gibt es das Perl Script von Dietmar63 (analize.pl) irgendwo zum download?

Wenn Interesse besteht, kann ich die Hardware für die Heizung und die Regensensor-Ansteuerung hier posten.

Als nächstes Projekt würde ich dann gern die Fernbedienung HM-RC-19 (rf_rc_19.xml) nachbauen.
Hier die gleichen Fragen nach AskSinPP-Lib Unterstützung und Registerdefinitionen.
Ich will hier eine handesübliche IR-Fermbedienung benutzen und über einen IR-Sensor die Anbindung an die Universalsensor-Hardware implementieren.

VG xkalle01
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Januar 2019, 20:38:53
Zitat
Kann ich mit dem jetzigen Stand der AskSinPP-Lib V3 den Regensensor von HomeMatic (HM-Sen-RD-O, rf_rd.xml ) implementieren?
Das geht auf jeden Fall. Die Register werden jetzt durch Macros definiert. Das geht alles viel einfacher. Wenn noch Register fehlen, können die auch einfach nachgepflegt werden.
ZitatAls nächstes Projekt würde ich dann gern die Fernbedienung HM-RC-19 (rf_rc_19.xml) nachbauen.
Hier die gleichen Fragen nach AskSinPP-Lib Unterstützung und Registerdefinitionen.
Schau mal in die Examples. Da gibt es bereits ne HM-RC-4 und HM-RC-8.
Titel: Antw:AskSin++ Library
Beitrag von: xkalle01 am 10 Januar 2019, 13:57:58
Hallo papa,
leider komme ich nicht so ganz klar mit der XML-Datei (z.B. rf_rd.xml). Deshalb die Frage nach dem Perl Script.
Kann mir jemand helfen die benötigten register zu identifizieren?

Irgendwie hat der Regensensor zwei Kanäle, wenn ich das richtig verstanden habe, einen für den Sensor und einen um die Heizung ein/aus zu schalten.

Reicht es, wenn ich aus den Beispielen die Definition eines Sensor-Cannel und einen Switch-Cannel in einen neuen Sketch zusammen bringe?

Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Januar 2019, 18:39:57
Ich schau mir das die Tage mal an.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Januar 2019, 18:42:00
Ich wollte mal noch auf die AskSin++ Webseite (https://asksinpp.de/) hinweisen. Einige Leute (vor allem aus dem Homematic Forum), haben dort angefangen möglichst viele Informationen zu sammen und über sichtlich bereitzustellen.
Titel: Antw:AskSin++ Library
Beitrag von: xkalle01 am 11 Januar 2019, 10:53:49
Danke im Voraus.

Ich habe jetzt versucht, die rf_rd.xml besser zu verstehen.
Demnach fehlen einige Register in der register.h für list1 und ein Register in der list4.
(Ich habe allerdings nur die register.h im V3 geprüft. Schaue heute Abend noch einmal im master branch)

Auf der AskSin++ Webseite hat sich noch niemand mit dem Regensensor beschäftig.
Scheint wohl nicht so interessant für einen Nachbau zu sein, obwohl der Preis für das Teil sehr hoch.

Gruß xkalle01


Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 11 Januar 2019, 11:02:02
Zitat von: xkalle01 am 11 Januar 2019, 10:53:49
Scheint wohl nicht so interessant für einen Nachbau zu sein, obwohl der Preis für das Teil sehr hoch.

Moin... :)
Als Nachbau als eigenständiges Gerät fand ich es nicht so gut.
Denn wenn ich schon eine AskSinPP Platine im Außenbereich aufstelle, um Regen zu detektieren, kann man auch gleich noch andere Daten erfassen... Helligkeit, Temperatur, Feuchte... usw.
Da ist man schnell bei einer kompletten Wetterstation.
Inwiefern das jedoch für dich interessant sein könnte und wie man diese in FHEM integrieren könnte, erschließt sich mir jedoch nicht, da ich aus der Homematic Welt komme.
Jedenfalls ist dort auch einen Regendetektor mit Heizung integriert.
https://github.com/jp112sdl/HB-UNI-Sen-WEA
Titel: Antw:AskSin++ Library
Beitrag von: xkalle01 am 11 Januar 2019, 11:35:34
Hallo jp112sdl,
Hut ab, Dein UNI-Sen-WEA ist eine umpfangreiche Wetterstationslösung.

Ich habe aber ehr vor, das Originalverhalter der HomeMatic-Geräte zu implementieren.
Damit können sie in allen Umgebungen, die HomeMatic unterstützen, ohne Anpassung integriert werden.

Den Regensensor benötige ich um ein Regenschutz-Rollo am Hauseingang zu steuern. Andere Wetterdaten sind für mich nicht so relevant.
Danke jedoch für den Link, damit kann ich mein Wissen vertiefen.

@papa: Die class RegList4 ist wohl doch schon passend.

VG. xkalle01
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 11 Januar 2019, 12:19:37
Zitat von: xkalle01 am 11 Januar 2019, 10:53:49
Danke im Voraus.

Ich habe jetzt versucht, die rf_rd.xml besser zu verstehen.
Demnach fehlen einige Register in der register.h für list1 und ein Register in der list4.
(Ich habe allerdings nur die register.h im V3 geprüft. Schaue heute Abend noch einmal im master branch)

Auf der AskSin++ Webseite hat sich noch niemand mit dem Regensensor beschäftig.
Scheint wohl nicht so interessant für einen Nachbau zu sein, obwohl der Preis für das Teil sehr hoch.

Gruß xkalle01

Ich fände den Nachbau des HM-Sen-RD-O auch interessant, u.a. wegen dem hohen Preis.

Habe mir gerade mal die xml angeschaut, es fehlen zur Zeit wohl z.B. die Regs dez. 143 und 145.
Die könnte man ja relativ leicht nachdefinieren bzw. eine eigene Implementation für Rd/Wr von custom registern machen.

Was ich mich grundsätzlich frage, die speziellen Register können ja über das WebUI konf. werden und sind ja ein Zeichen dafür das in der Original Firmware ein Algorithmus werkelt der diese Settings entsprechend berücksichtigt. Willst du das auch im Nachbau haben?, dann wird das ein interessantes Projekt  :)
Falls aber nur eine einfache Nass/Trocken Erkennung beabsichtigt ist wären die speziellen Regs egal, man sollte sie nur als Rd/Wr verfügbar haben.
Titel: Antw:AskSin++ Library
Beitrag von: xkalle01 am 11 Januar 2019, 12:40:17
ZitatWas ich mich grundsätzlich frage, die speziellen Register können ja über das WebUI konf. werden und sind ja ein Zeichen dafür das in der Original Firmware ein Algorithmus werkelt der diese Settings entsprechend berücksichtigt. Willst du das auch im Nachbau haben?, dann wird das ein interessantes Projekt  :)

Ja, das macht natürlich Sinn. Intern müssen ja eh die Werte für 'nass'  und 'tocken ' definiert und behandelt werden.
Dann kann man die Schwellwerte auch gleich aus den Registern nehmen.
Die Zeitangaben sollten wohl auch kein Problem sein.
Titel: Antw:AskSin++ Library
Beitrag von: PeMue am 11 Januar 2019, 16:28:46
Hallo zusammen,

ich habe mal probiert, meinen Ultraschall Sensor Sketch für Atmega 644 (Mighty Core) zu kompilieren, aber da macht wohl die low power library nicht mit:
D:\1_programme\arduino187\portable\sketchbook\libraries\Low-Power_v1.6/LowPower.h:144:6: error: #error "Please ensure chosen MCU is either 168, 328P, 32U4, 2560 or 256RFR2."

#error "Please ensure chosen MCU is either 168, 328P, 32U4, 2560 or 256RFR2."

Habt ihr schon mal irgendwelche batteriebetriebenen Sensoren für den Atmega 644 kompiliert?

Danke + Gruß

Peter
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 11 Januar 2019, 16:47:50
Zitat von: PeMue am 11 Januar 2019, 16:28:46
Hallo zusammen,

ich habe mal probiert, meinen Ultraschall Sensor Sketch für Atmega 644 (Mighty Core) zu kompilieren, aber da macht wohl die low power library nicht mit:
D:\1_programme\arduino187\portable\sketchbook\libraries\Low-Power_v1.6/LowPower.h:144:6: error: #error "Please ensure chosen MCU is either 168, 328P, 32U4, 2560 or 256RFR2."

#error "Please ensure chosen MCU is either 168, 328P, 32U4, 2560 or 256RFR2."

Habt ihr schon mal irgendwelche batteriebetriebenen Sensoren für den Atmega 644 kompiliert?

Danke + Gruß

Peter

Hast du wirklich einen 644 oder einen 644P?
Der 644P wird in der LowPower lib supported:
#elif defined __AVR_ATmega644P__ || defined (__AVR_ATmega1284P__)

Für den 644 kann man das sicher leicht patchen (nachdem man gecheckt hat das beide bezüglich Sleep mode register usw. kompatible sind)  ;)
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 11 Januar 2019, 17:09:17
Soll ich euch mal den Sketch für den Entfernungsmesser kompilieren oder ein HEX file schicken?
Titel: Antw:AskSin++ Library
Beitrag von: Starsurfer am 11 Januar 2019, 17:33:34
Zitat von: jp112sdl am 11 Januar 2019, 11:02:02
Moin... :)
Als Nachbau als eigenständiges Gerät fand ich es nicht so gut.
Denn wenn ich schon eine AskSinPP Platine im Außenbereich aufstelle, um Regen zu detektieren, kann man auch gleich noch andere Daten erfassen... Helligkeit, Temperatur, Feuchte... usw.
Da ist man schnell bei einer kompletten Wetterstation.
Inwiefern das jedoch für dich interessant sein könnte und wie man diese in FHEM integrieren könnte, erschließt sich mir jedoch nicht, da ich aus der Homematic Welt komme.
Jedenfalls ist dort auch einen Regendetektor mit Heizung integriert.
https://github.com/jp112sdl/HB-UNI-Sen-WEA

Kann man das Teil auch mit einem HmUARTLGW betreiben?
Ist noch zufällig eine Platine über?  :o
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Januar 2019, 21:22:01
Zitat von: jp112sdl am 11 Januar 2019, 11:02:02
Inwiefern das jedoch für dich interessant sein könnte und wie man diese in FHEM integrieren könnte, erschließt sich mir jedoch nicht, da ich aus der Homematic Welt komme.
Jedenfalls ist dort auch einen Regendetektor mit Heizung integriert.
https://github.com/jp112sdl/HB-UNI-Sen-WEA
Das könnte man mit in das HMConfig_AskSinPPCustom.pm aufnehmen.
Titel: Antw:AskSin++ Library
Beitrag von: PeMue am 12 Januar 2019, 18:55:42
Zitat von: Tom Major am 11 Januar 2019, 16:47:50
Hast du wirklich einen 644 oder einen 644P?
Der 644P wird in der LowPower lib supported:
#elif defined __AVR_ATmega644P__ || defined (__AVR_ATmega1284P__)

Für den 644 kann man das sicher leicht patchen (nachdem man gecheckt hat das beide bezüglich Sleep mode register usw. kompatible sind)  ;)
Ich habe das mit der Mighty Core Atmega 644 -> Atmega 644P/PA compiliert. Da scheint dann was nicht zu passen. Muss ich mir mal im Detail anschauen.

Zitat von: gloob am 11 Januar 2019, 17:09:17
Soll ich euch mal den Sketch für den Entfernungsmesser kompilieren oder ein HEX file schicken?
Danke, nicht notwendig. Ich will ja auch noch was lernen und die Software ist nicht ganz so stark bei mir  ;)

Gruß Peter

Edit: Problem gelöst. Die Low-Power Library, die der Bibliotheksmanager holt, ist zu alt. Ich habe per ZIP die aktuelle eingebunden und jetzt funktioniert es. Außerdem ist im library.json noch die alte Versionsnummer drin   ::).

Der Sketch verwendet 18618 Bytes (28%) des Programmspeicherplatzes. Das Maximum sind 64512 Bytes.
Globale Variablen verwenden 706 Bytes (17%) des dynamischen Speichers, 3390 Bytes für lokale Variablen verbleiben. Das Maximum sind 4096 Bytes.
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 18 Januar 2019, 00:23:35
@papa

habe mal die letzte Zeit mit Tom (Major) einen RTC Sketch (sowohl seine angepasste Version also auch deine https://github.com/pa-pa/AskSinPP/tree/master/examples/HM-WDS10-TH-O) getestet, um den Sensor im Sleep möglichst stromsparend zu bekommen. Leider messe ich ca. 70uA im Sleep mit beiden Sketches (getestet auf 2 verschiedenen Hardware Versionen: 1x Breadboard, 1x https://github.com/pa-pa/HMSensor/tree/master/HMSensor-CR2032/files). Sketches mit int. SysClk brauchen auf beiden Hardware Versionen ca. 4uA wie erwartet.

Gibt es vielleicht noch etwas zu beachten? Hast du bei deinen RTC Versionen niedrigere Ströme gemessen?

Folgende Fuses sind gesetzt:


BODLEVEL  = DISABLED
RSTDISBL  = [ ]
DWEN      = [ ]
SPIEN     = [X]
WDTON     = [ ]
EESAVE    = [X]
BOOTSZ    = 1024W_3C00
BOOTRST   = [X]
CKDIV8    = [ ]
CKOUT     = [ ]
SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_65MS

EXTENDED = 0xFF (valid)
HIGH     = 0xD2 (valid)
LOW      = 0xE2 (valid)


Andreas
Titel: Antw:AskSin++ Library
Beitrag von: papa am 18 Januar 2019, 08:38:27
Hm - 70µA ist etwas viel - ABER die Verwendung der RTC erhöht grundsätzlich den Verbrauch, da nicht mehr der "Power Down" sondern "Power Save" Mode der CPU genutzt wird. Dieser braucht - schon durch den aktiven Timer2 - immer mehr Strom. Was man durch die RTC gewinnt, ist die höhere Genauigkeit des Timers, da er durch den 32kHz Quarz getaktet wird. Der sonst verwendete Watchdog Timer ist absolut unterirdisch in der Genauigkeit.

Also die Entscheidung für die RTC ist nicht der Verbrauch, sondern die Einhaltung von Timings (z.B. Kommunikationsslot mit einem Thermostat).

Sieh auch https://www.mikrocontroller.net/articles/Sleep_Mode (https://www.mikrocontroller.net/articles/Sleep_Mode)
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 18 Januar 2019, 12:01:48
Zitat von: papa am 18 Januar 2019, 08:38:27
Hm - 70µA ist etwas viel - ABER die Verwendung der RTC erhöht grundsätzlich den Verbrauch, da nicht mehr der "Power Down" sondern "Power Save" Mode der CPU genutzt wird. Dieser braucht - schon durch den aktiven Timer2 - immer mehr Strom.

Im Datenblatt wird bei 32kHz Quarz Running auch der Power-Save mode referenziert, allerdings mit ca. 1uA bei 3V:
ZitatFigure 33-13. ATmega328: Power-Save Supply Current vs. V CC (Watchdog Timer Disabled and 32kHz Crystal
Oscillator Running

- deswegen hätte ich vermutet, man kann die 4uA sleep Strom mit Watchdog durch Einsatz der 32kHz RTC auf 1uA bringen.  8)
Habe es aber selbst noch nie getestet.
70uA kommen mir def. zu hoch vor (auch mit Timer2 running), IMHO stimmt irgendwas  noch nicht ganz mit dem RTC code.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 22 Januar 2019, 19:56:52
Zitat von: papa am 18 Januar 2019, 08:38:27
Hm - 70µA ist etwas viel - ABER die Verwendung der RTC erhöht grundsätzlich den Verbrauch, da nicht mehr der "Power Down" sondern "Power Save" Mode der CPU genutzt wird. Dieser braucht - schon durch den aktiven Timer2 - immer mehr Strom.

@papa

ok, habe noch ein paar Test gemacht da mir die 70uA wie gesagt zu hoch vorkommen.
Und fhemfreund hat auch keine Ruhe gegeben  :) :)

Der Timer2 im async mode war etwas tricky, aber jetzt habe ich das Resultat.
Der AVR braucht ca. 0,75uA im power-save mode mit Uhrenquarz am laufenden Timer2. Dies stimmt auch mit dem Diagramm "Power-save Supply Current" im Datenblatt überein.

Hier habe ich die Erkenntnisse etwas beschrieben und 2 Testsketche zum Prüfen des Ruhestroms abgelegt.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Ruhestrom#%C3%BCberpr%C3%BCfung-des-avr-ruhestroms-power-save-mode (https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Ruhestrom#%C3%BCberpr%C3%BCfung-des-avr-ruhestroms-power-save-mode)

Danach habe ich mir die Sleep Klassen in der AskSinPP, Datei Activity.h angeschaut. Ich glaube der Fehler ist das du im RTC/Timer2/32kHz Fall
LowPower.powerExtStandby(..)
anstatt
LowPower.powerSave(..)

aufrufst. Das lässt den internen 8MHz RC OSzillator an und dies ist IMHO die Ursache für die 70uA.
Mit powerSave sollte sich das hoffentlich auf die 0,75uA reduzieren lassen.

Ich könnte auch einen PR machen, nur ich verstehe nicht vollständig warum
LowPower.powerExtStandby(..)
an 2. Stellen auftaucht, ich vermute nur die 2. Stelle in der SleepRTC Klasse wäre die Richtige, deswegen warte ich erst mal auf deinen Kommentar   :)

Danke,
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 Januar 2019, 20:19:21
Ja in SleepRTC passt.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 25 Januar 2019, 18:58:16
ok, PR für den Fix des RTC sleep modes wurde gemacht und von papa gemerged.
Jetzt ist im RTC mode ca. 1uA Ruhestrom erreichbar (ohne Sensoren).
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 Januar 2019, 19:36:59
Sehr cool.

Hat eigentlich jemand die RTC mit einem ATMega644P zum Laufen gekriegt ? Hatte das letztens mal versucht, aber da kommen die Interrupts nichts :-(
Eigentlich sollte meiner Meinung nach der gleiche Code wie für den ATMega328P funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 25 Januar 2019, 20:08:06
Zitat von: papa am 25 Januar 2019, 19:36:59
Sehr cool.

Hat eigentlich jemand die RTC mit einem ATMega644P zum Laufen gekriegt ? Hatte das letztens mal versucht, aber da kommen die Interrupts nichts :-(
Eigentlich sollte meiner Meinung nach der gleiche Code wie für den ATMega328P funktionieren.

Die relevanten Register sehen auf den ersten Blick gleich aus.
Hast du den 32k Quarz an TOSC1/2 angeschlossen? Das ist ein Unterschied zum mega328, dort gibt es nur XTAL, beim 644 verschiedene OSC pins.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 Januar 2019, 21:14:02
Ich habe die Platine von Alex https://github.com/alexreinert/PCB#hb-uni-644-rev-2 (https://github.com/alexreinert/PCB#hb-uni-644-rev-2)
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 25 Januar 2019, 23:03:34
Hattest du den 32kHz Quarz an PC6/7 angeschlossen? Und Lastkapazitäten auch dran?
Titel: Antw:AskSin++ Library
Beitrag von: kaihs am 25 Januar 2019, 23:08:31
Ich möchte eine Überwachung der Stellventile meiner Fußbodenheizung bauen.
Dazu sollen minimal vier (besser sechs) Gabellichtschranken zyklisch (ca. alle 3 Minuten) abgefragt und deren Zustand (on/off) gemeldet werden.
Das Ganze soll batteriebetrieben sein.

Welcher Beispielsketch wäre dafür die Beste Vorlage?

HM-RC-8 (https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-RC-8/HM-RC-8.ino) und den Zustand der Lichtschranken als Tastendrücke übermitteln?
Wie könnte das zyklische Aufwachen implementiert werden?

Am Besten von den Standard Homematic Komponenten würde wahrscheinlich das 8-Bit HM-MOD-EM-8Bit (https://www.elv.de/elv-homematic-funk-sendemodul-8-bit-bausatz.html) passen, erweitert um das zyklische Aufwachen mit Ansteuerung und Abfrage der Lichtschranken.
Dafür gibt es aber noch keine Asksin++ Beispielimplementierung, oder?


Titel: Antw:AskSin++ Library
Beitrag von: papa am 26 Januar 2019, 11:17:28
Zitat von: Tom Major am 25 Januar 2019, 23:03:34
Hattest du den 32kHz Quarz an PC6/7 angeschlossen? Und Lastkapazitäten auch dran?
Das ist es wahrscheinlich. Der Quarz auf der Platine geht an XTAL und nicht OSC. Mist :-(
Titel: Antw:AskSin++ Library
Beitrag von: papa am 26 Januar 2019, 11:18:47
Zitat von: kaihs am 25 Januar 2019, 23:08:31
Am Besten von den Standard Homematic Komponenten würde wahrscheinlich das 8-Bit HM-MOD-EM-8Bit (https://www.elv.de/elv-homematic-funk-sendemodul-8-bit-bausatz.html) passen, erweitert um das zyklische Aufwachen mit Ansteuerung und Abfrage der Lichtschranken.
Dafür gibt es aber noch keine Asksin++ Beispielimplementierung, oder?
Schon mal hier (https://asksinpp.de/Sketche/) nach was passenden gesucht ?
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 26 Januar 2019, 12:30:21
Zitat von: papa am 26 Januar 2019, 11:17:28
Das ist es wahrscheinlich. Der Quarz auf der Platine geht an XTAL und nicht OSC. Mist :-(

Das passt zum Fehlerbild, ohne Timer2 Quarz kommt der overflow interrupt nicht, alles andere läuft wie bisher  ;)
Titel: Antw:AskSin++ Library
Beitrag von: kaihs am 26 Januar 2019, 14:45:07
Zitat von: papa am 26 Januar 2019, 11:18:47
Schon mal hier (https://asksinpp.de/Sketche/) nach was passenden gesucht ?

Danke, der HB-UNI-SenAct-4-4 (https://github.com/jp112sdl/HB-UNI-SenAct-4-4) passt glaube ich ganz gut.
Allerdings steht dort, dass das JP-HB-Devices-addon (https://github.com/jp112sdl/JP-HB-Devices-addon/releases/latest) benötigt wird, was sich ja auf die Verwendung mit der HMCCU bezieht.
Wie sieht es mit der Einbindung in fhem aus, ist die bereits möglich?.
Titel: Antw:AskSin++ Library
Beitrag von: berniie am 27 Januar 2019, 12:14:15
Für die HB irgendwas  Sketche brauchst du die Datei  HMConfig_AskSinPPCustom.pm im FHEM Verzeichniss.
Der HB-UNI-SenAct-4-4  hat die Model ID F332 und die findest sich leider nicht im Perl Modul.
Sprich, der ist noch nicht implementiert.
Titel: Antw:AskSin++ Library
Beitrag von: berniie am 04 Februar 2019, 19:52:22
Hier meine Lösung um die HMConfig_AskSinPPCustom.pm um den HB-UNI-SenAct-4-4 -RC ohne Batterie zu erweitern.
Ist mein erster Versuch mit selbst gebauten Sensoren und bestimmt nicht perfekt, scheint aber zu funktionieren.

$HMConfig::culHmModel{"F332"} = {name=>"HB-UNI-SenAct-4-4-RC",st=>'custom',cyc=>'',rxt=>'',lst=>'1',chn=>"Sw:1:4,Btn:5:8"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-RC00"}{fwUpdate} = "<filename>";
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-RC01"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-RC02"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-RC03"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-RC04"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-RC05"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-RC06"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-RC07"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-RC08"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-RC01"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-RC02"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-RC03"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-RC04"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-RC05"} = $HMConfig::culHmRegType{remote};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-RC06"} = $HMConfig::culHmRegType{remote};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-RC07"} = $HMConfig::culHmRegType{remote};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-RC08"} = $HMConfig::culHmRegType{remote};

Titel: Antw:AskSin++ Library
Beitrag von: Trexis5 am 07 Februar 2019, 18:27:15
Hallo Leute,
woher bekomme ich denn die
SwitchChannel.h Datei?
Ich kann diese auch nirgens bei Github finden.
Kann mir einer helfen.
Danke.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 Februar 2019, 18:35:10
Zitat von: Trexis5 am 07 Februar 2019, 18:27:15
woher bekomme ich denn die
SwitchChannel.h Datei?
Ich kann diese auch nirgens bei Github finden.
Kann mir einer helfen.

Wo wird die denn benötigt?
Ich vermute mal, du meinst die Switch.h - und die liegt bei allen anderen Dateien der AskSinPP Lib
Titel: Antw:AskSin++ Library
Beitrag von: Trexis5 am 07 Februar 2019, 18:38:13
Hi,
nein bei Seite 35.
Die Umsetztung auf ESP nicht auf Atmel Prozessor.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 07 Februar 2019, 18:48:43
Die Klasse "SwitchChannel" ist in Switch.h enthalten.
Ich vermute die Datei hieß früher so und wurde inzwischen in Switch.h umbenannt.
Titel: Antw:AskSin++ Library
Beitrag von: Trexis5 am 07 Februar 2019, 19:26:02
Ah super, teste ich.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 Februar 2019, 21:16:14
Zitat von: berniie am 04 Februar 2019, 19:52:22
Hier meine Lösung um die HMConfig_AskSinPPCustom.pm um den HB-UNI-SenAct-4-4 -RC ohne Batterie zu erweitern.
Ist mein erster Versuch mit selbst gebauten Sensoren und bestimmt nicht perfekt, scheint aber zu funktionieren.

$HMConfig::culHmModel{"F332"} = {name=>"HB-UNI-SenAct-4-4-RC",st=>'custom',cyc=>'',rxt=>'',lst=>'1',chn=>"Sw:1:4,Btn:5:8"};
....
Habe ich aufgenommen - und gleich noch die Peerlisten korrigiert.
Titel: Antw:AskSin++ Library
Beitrag von: berniie am 13 Februar 2019, 23:07:59
Klasse! Vielen Dank dafür.
Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 18 Februar 2019, 20:34:41
Hallo,

hat schonmal wer versucht, seine Schaltung mit einem 18650 Akku (3.7V) zu betreiben?
Mich würde interessieren, wie man die Batterieüberwachung am Besten realisiert.

Micky
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 18 Februar 2019, 21:07:07
Ich hab zwei, aber in Reihe und ein DCDC zwischen um auf 5V zu kommen. Bei 2,5V pro Zelle würde ich langsam Alarm schlagen, viel tiefer sollte man nicht gehen wenn man die Zellen nicht schädigen möchte. Bei Polymer Zellen dann 3,3V.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 19 Februar 2019, 10:05:50
2.5V scheint zu niedrig => https://www.mikrocontroller.net/topic/418276

Mein Arduino läuft mit 3.3V und ich habe gelesen, dass man bei der 18650 nicht unter 3.xV gehen sollte.
Mit 3.3V Spannungsregler(bzw: mutig => ohne Spannungsregler) könnte ich "Batterie low" bei 3.2V melden.

Wenn ich das allerdings schon bei 3.5V machen wollte, müsste ich einen Spannungsteiler nutzen und dann aber wieder Rückschlüsse auf die tatsächliche Batteriespannung ziehen.
Und da tue ich mich schwer..

Micky




Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 19 Februar 2019, 11:19:39
Also die Rundzellen sind Li-Ion, die gehen schon bis 2,5V, aber nicht tiefer, das ist wirklich die Entladeschlussspannung, aber hängt vom Hersteller ab, also Datenblatt.
Die 3,3V sind von den Li-Po Akkus, auch hier Untergrenze. Ich nehme die 3,3V auch beim Modellflug, und da fließen 60A und mehr, 3,2V sind schon der Tod. Aber im Modellbau ist es schwieriger durch die hohen Ströme. Bei unserem Kram hier fließt so wenig, das man nicht Gefahr läuft unter die 3,3V zu sacken wenn man zeitnahe reagiert.

Nimmst halt etwas mehr, also 3,4V und 2,6V.

Du tust dich mit einem Spannungsteiler schwer? Schau mal bei Google nach unbelasteten Spannungsteiler. Ist im Prinzip einfach, nur beachte den Gesamtwiderstand weil sonst zu viel Strom fließt. Also arbeite mit 50k oder besser 100k.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 Februar 2019, 12:13:57
Ich habe ein paar Geräte mit 18650 Akku laufen. Da hängt der Akku direkt an 3.3V und ich nehme einfach die interne Spannungsmessung. Battery-Low ist bei 3V (glaube ich) eingestellt.
Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 19 Februar 2019, 19:42:41
@papa: Danke, das mit den 3.0V scheint mir jetzt auch sinnvoll.

Zitat von: ext23 am 19 Februar 2019, 11:19:39
Nimmst halt etwas mehr, also 3,4V und 2,6V.

Die 3.4 Volt muss man ja erstmal messen!
Mein Verständnis:

Bei Referenz = 3.3V und Spannung >= 3.3V ergibt:
Interene Messung = 3.3V
BatterySensorUni = 3.3V
BatterySensorExt = 3.3V

Der max. Wert an einem Analogping entspricht einer angelegten Spannung, die gleich oder größer der Referenzspannung ist.
Ich kann da also keine Werte messen, die höher als die Referenz sind.

Mein ursprünglicher Hintergrund bezog sich auf die hier dargestellten Daten:
https://www.powerstream.com/lithium-ion-charge-voltage.htm

Allerdings habe ich dabei den Strom (100 mA) nicht näher betrachtet.
Deshalb habe ich mir die Frage gestellt, wie ich es so hinbekomme, dass eine Spannung von 4.1V (max bei 18650) z.B. als 3.2V gemessen wird und welchen Batt-Low Wert ich dann im Sketch einstellen muss, damit bei 3.6V (tatsächlicher Spannung) eine Warnung kommt. Vermutlich wird das bei einem Spannungsteiler aber sowieso linear sein.



Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 19 Februar 2019, 20:37:38
Zitat von: micky0867 am 19 Februar 2019, 19:42:41
Der max. Wert an einem Analogping entspricht einer angelegten Spannung, die gleich oder größer der Referenzspannung ist.
Ich kann da also keine Werte messen, die höher als die Referenz sind.

Die Aussage ist Quatsch, weil die Lösung heißt unbelasteter Spannungsteiler, sonst würde ja vieles nicht funktionieren ;-)

https://www.mikrocontroller.net/articles/Spannungsteiler

Also das sollte kein Problem sein. Mach ich ja bei mir nicht anders, ich habe ja zwei Zellen in Reihe. Da messe ich auch die Gesamtspannung. Natürlich musst du das unter FHEM dann wieder anpassen wenn du nicht den Sketch ändern möchtest. Also wenn der Sketch dann 3V misst ist es ja in Wirklichkeit mehr, ab er das kann man ja mit demselben Teilungsfaktor wieder hochrechnen.

Titel: Antw:AskSin++ Library
Beitrag von: gloob am 19 Februar 2019, 20:57:41
Hallo,

Hat jemand eine Idee, warum ich den Sensor nicht pairen kann mit FHEM?


20:55:53.800 -> AskSin++ V3.1.7 (Feb 19 2019 20:52:57)
20:55:53.800 -> Address Space: 32 - 90
20:55:53.800 -> CC init1
20:55:53.800 -> CC Version: 14
20:55:53.836 ->  - ready
20:55:54.177 -> Bat: 33
20:55:54.177 -> *List1 changed
20:55:54.177 -> *ledOntime 0
20:55:54.177 -> *transmitTryMax 0
20:55:54.177 -> *waterUpperThreshold 0
20:55:54.177 -> *waterLowerThreshold 0
20:55:54.177 -> *caseDesign 0
20:55:54.177 -> *caseHigh 0
20:55:54.177 -> *caseWidth 100
20:55:54.214 -> *caseLength 100
20:55:54.214 -> *measureLength 0
20:55:54.214 -> *fillLevel 0
20:55:54.214 -> *useCustomCalibration 0
20:56:08.354 ->  debounce
20:56:08.422 ->  pressed
20:56:08.494 ->  released
20:56:08.532 ->
20:56:11.669 -> ignore 14 10 00 8E B5453F 96E6C1 0C 62 B1 E7 78 77 E6 A1 22 CB C9  - 3590
20:56:16.437 -> ignore 14 C7 84 5E 24B05C 000000 80 12 4B 00 00 81 00 0C 09 08 FE  - 8366
20:56:16.608 -> ignore 27 10 00 8E 3C22EC BF992C 00 00 33 E8 76 3D 45 49 CF C9 79 EA CD 77 2A FF 63 64 15 26 4D E9 AC EB B2 BB 50 F7 DD B0  - 8527
20:56:19.711 -> ignore 14 76 84 5E 3272FA 000000 80 85 BA 00 00 AE 00 0C 09 06 FE  - 11616
20:56:19.811 -> ignore 27 10 00 8E 24448E B5453F 00 03 15 0F 21 E9 A2 DE 18 13 B2 5E 42 44 01 08 72 3D A7 42 D4 01 6C 54 71 7D 23 70 40 7C  - 11737
20:56:19.911 -> ignore 14 10 00 8E B5453F 24448E 0C 62 B1 E8 1A 4C 2D B6 89 BF C1  - 11841
20:56:21.474 -> ignore 13 12 00 83 2200EE F00001 00 00 06 05 60 E2 79 63 97 17  - 13373
20:56:24.115 -> ignore 0F 39 86 10 42D73C 000000 0A 60 B7 0C 00 00  - 16027


//- -----------------------------------------------------------------------------------------------------------------------
// 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 EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>
#include <Register.h>

#include <MultiChannelDevice.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

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

//seconds between sending messages
#define MSG_INTERVAL 400

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0x00, 0x9f, 0x01},     // Device ID
  "JPWAOD0001",           // Device Serial
  {0x00, 0x9f},           // Device Model
  0x10,                   // Firmware Version
  as::DeviceType::THSensor, // Device Type
  {0x01, 0x00}            // Info Bytes
};

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

    bool runready () {
      return sysclock.runready() || BaseHal::runready();
    }
} hal;

DEFREGISTER(WaOdReg0, MASTERID_REGS, DREG_CYCLICINFOMSGDIS, DREG_LOCALRESETDISABLE, DREG_TRANSMITTRYMAX)
class WaOdList0 : public RegList0<WaOdReg0> {
  public:
    WaOdList0 (uint16_t addr) : RegList0<WaOdReg0>(addr) {}
    void defaults () {
      clear();
      // cyclicInfoMsgDis(0);
      // transmitDevTryMax(6);
      // localResetDisable(false);
    }
};

DEFREGISTER(WaOdReg1, CREG_WATER_UPPER_THRESHOLD_CH, CREG_WATER_LOWER_THRESHOLD_CH, CREG_CASE_DESIGN, CREG_CASE_HIGH, CREG_FILL_LEVEL, CREG_CASE_WIDTH, CREG_CASE_LENGTH, CREG_MEASURE_LENGTH, CREG_USE_CUSTOM_CALIBRATION, CREG_LEDONTIME, CREG_TRANSMITTRYMAX)
class WaOdList1 : public RegList1<WaOdReg1> {
  public:
    WaOdList1 (uint16_t addr) : RegList1<WaOdReg1>(addr) {}
    void defaults () {
      clear();
      caseLength(100);
      caseWidth(100);
    }
};

class FillingEventMsg : public Message {
  public:
    void init(uint8_t msgcnt, uint8_t fill) {
      Message::init(0xc, msgcnt, 0x41, BIDI, 0x01, msgcnt);
      pload[0] = fill;
    }
};

class FillingChannel : public Channel<Hal, WaOdList1, EmptyList, List4, PEERS_PER_CHANNEL, WaOdList0>, public Alarm {

    FillingEventMsg msg;
    int16_t         fill;
    uint16_t        millis;
    uint8_t last_flags = 0xff;

  public:
    FillingChannel () : Channel(), Alarm(5), fill(0), millis(0) {}
    virtual ~FillingChannel () {}

    // here we do the measurement
    void measure () {
      fill = 170;
    }

    virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
      uint8_t msgcnt = device().nextcount();
      // reactivate for next measure
      tick = delay();
      clock.add(*this);

      if (last_flags != flags()) {
        this->changed(true);
        last_flags = flags();
      }

      measure();

      msg.init(msgcnt, fill);
      device().sendPeerEvent(msg, *this);
    }

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


    uint8_t status () const {
      return fill;
    }

    void configChanged() {
      DPRINTLN(F("*List1 changed"));
      DPRINT(F("*ledOntime ")); DDECLN(this->getList1().ledOntime());
      DPRINT(F("*transmitTryMax ")); DDECLN(this->getList1().transmitTryMax());
      DPRINT(F("*waterUpperThreshold ")); DDECLN(this->getList1().waterUpperThreshold());
      DPRINT(F("*waterLowerThreshold ")); DDECLN(this->getList1().waterLowerThreshold());
      DPRINT(F("*caseDesign ")); DDECLN(this->getList1().caseDesign());
      DPRINT(F("*caseHigh ")); DDECLN(this->getList1().caseHigh());
      DPRINT(F("*caseWidth ")); DDECLN(this->getList1().caseWidth());
      DPRINT(F("*caseLength ")); DDECLN(this->getList1().caseLength());
      DPRINT(F("*measureLength ")); DDECLN(this->getList1().measureLength());
      DPRINT(F("*fillLevel ")); DDECLN(this->getList1().fillLevel());
      DPRINT(F("*useCustomCalibration ")); DDECLN(this->getList1().useCustomCalibration());
    }

    uint8_t flags () const {
      uint8_t flags = this->device().battery().low() ? 0x80 : 0x00;
      return flags;
    }
};

typedef MultiChannelDevice<Hal, FillingChannel, 1, WaOdList0> WaOdType;
WaOdType sdev(devinfo, 0x20);

ConfigButton<WaOdType> cfgBtn(sdev);

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if ( worked == false && poll == false ) {
    hal.activity.savePower<Sleep<>>(hal);
  }
}


Der Code ist unverändert von hier: https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples/HM-Sen-WA-OD
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Februar 2019, 09:29:27
Das sieht schon komisch aus. Nach dem Drücken des Tasters (also nach release) müsste eigentlich eine DeviceInfo-Message zu sehen sein. Diese startet den Pairing-Vorgang. In den Ausgaben ist aber kein Senden zu erkennen. Scheinbar wird nur empfangen. Muss mir den Sketch mal auf ein Testsystem spielen. So habe ich auch keine Erklärung.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Februar 2019, 20:34:25
Das Problem ist folgende Zeile:
// transmitDevTryMax(6);

Damit wird TransmitTryMax auf 0 initialisiert und es wird nie eine Nachrricht gesendet. Einfach den Kommentar vor dieser Zeile entfernen und das Geräte RESETen. Dannach sollte es wie erwartet funktionieren.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 21 Februar 2019, 07:58:14
Vielen Dank ich werde es mal damit probieren.
Hast du eine Idee, warum die meisten Sensoren trotzdem funktionieren, obwohl die Zeile überhaupt nicht vorhanden ist?
Ich würde gerne den Hintergrund/Sinn erkennen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Februar 2019, 08:08:29
Wenn das Register nicht vorhanden ist, dann ist der Wert automatisch 6 (Register.h Zeile 360). Aber wenn das Register angelegt ist, muss es auch ordentlich initialisiert werden.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 21 Februar 2019, 08:18:29
Zitat von: papa am 21 Februar 2019, 08:08:29
Wenn das Register nicht vorhanden ist, dann ist der Wert automatisch 6 (Register.h Zeile 360). Aber wenn das Register angelegt ist, muss es auch ordentlich initialisiert werden.

Okay das macht dann natürlich auch Sinn. Vielen Dank. Hätte nicht gedacht, dass das den kompletten Anlernvorgang lahm legt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Februar 2019, 08:25:29
Zitat von: gloob am 21 Februar 2019, 08:18:29
Okay das macht dann natürlich auch Sinn. Vielen Dank. Hätte nicht gedacht, dass das den kompletten Anlernvorgang lahm legt.
Wenn er halt keine Nachrichten mehr sendet - geht natürlich gar nichts mehr.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 21 Februar 2019, 08:27:02
Ich werde es heute Nachmittag  testen und dann Jerome informieren, dass seine Sample auf der Github Seite nicht laufen.  ;)
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 21 Februar 2019, 18:05:33
Zitat von: papa am 20 Februar 2019, 20:34:25
Das Problem ist folgende Zeile:
// transmitDevTryMax(6);

Damit wird TransmitTryMax auf 0 initialisiert und es wird nie eine Nachrricht gesendet. Einfach den Kommentar vor dieser Zeile entfernen und das Geräte RESETen. Dannach sollte es wie erwartet funktionieren.

Vielen Dank. Jetzt geht der Sensor und wird in FHEM als HM-SEN-WA-OD erkannt  ;D
Titel: Antw:AskSin++ Library
Beitrag von: The-Holgi am 23 Februar 2019, 16:14:47
Hallo,
habe folgenden Wandsender nachgebaut:
https://github.com/ronnythomas/Wandsender
Soweit funktioniert auch alles, allerdings wird Taste 3 im webinterface nach betätigung nicht als btn3 angezeigt, sondern nur cmd's done. Taste 1 und 2 funktionieren.
Internals:
   CFGFN     
   DEF        02BF02
   FUUID      5c7143c4-f33f-6571-935d-98347cdbebf51713
   HMLAN1_MSGCNT 269
   HMLAN1_RAWMSG E02BF02,0000,2F562563,FF,FFC9,C6A24002BF0229A0F10318
   HMLAN1_RSSI -55
   HMLAN1_TIME 2019-02-23 16:02:09
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     269
   NAME       HM_02BF02
   NOTIFYDEV  global
   NR         522
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_02BF02_Btn_01
   channel_02 HM_02BF02_Btn_02
   lastMsg    No:C6 - t:40 s:02BF02 d:29A0F1 0318
   protLastRcv 2019-02-23 16:02:09
   protRcv    269 last_at:2019-02-23 16:02:09
   protResnd  1 last_at:2019-02-23 15:45:03
   protSnd    184 last_at:2019-02-23 16:02:09
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:269 min:-81 max:-55 avg:-64.56 lst:-55
   READINGS:
     2019-02-23 15:18:45   CommandAccepted yes
     2019-02-23 16:00:22   D-firmware      1.4
     2019-02-23 16:00:22   D-serialNr      HOLB2FM001
     2019-02-23 16:00:23   PairedTo        0x29A0F1
     2019-02-23 15:19:15   R-pairCentral   0x29A0F1
     2019-02-23 16:00:22   RegL_00.         00:00 02:01 0A:29 0B:A0 0C:F1
     2019-02-23 16:02:09   battery         ok
     2019-02-23 16:02:09   state           CMDs_done
     2019-02-23 15:18:34   trigDst_broadcast noConfig
     2019-02-23 16:02:09   trigger         Short_24
     2019-02-23 16:02:09   trigger_cnt     24
   helper:
     BNO        24
     BNOCNT     1
     HM_CMDNR   198
     PONtest    1
     cSnd       0129A0F102BF0202040000000001,0129A0F102BF020203
     mId        00BF
     regLst     ,0
     rxType     20
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +02BF02,00,01,00
       nextSend   1550934129.99849
       prefIO     
       rxt        2
       vccu       
       p:
         02BF02
         00
         01
         00
     mRssi:
       mNo        C6
       io:
         HMLAN1:
           -49
           -49
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       dev        1
     rpt:
       IO         HMLAN1
       flg        A
       ts         1550934129.91028
       ack:
         HASH(0x56377ae794c0)
         C6800229A0F102BF0200
     rssi:
       at_HMLAN1:
         avg        -64.5650557620817
         cnt        269
         lst        -55
         max        -55
         min        -81
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-PB-2-FM
   room       CUL_HM
   serialNr   HOLB2FM001
   subType    pushButton
   webCmd     getConfig:clear msgEvents

Denke es liegt daran, das er als HM-PB-2-FM erkannt wird. Ist vielleicht nicht in der HMConfig_AskSinPPCustom.pm angelegt ?
Im eventmonitor kommt zumindest was von Btn3 an.
Was kann ich tun ?

Gruß Holger
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 Februar 2019, 13:47:56
Da Ronny leider seine Sachen nicht frei zur Verfügung stellt, kann und will ich nicht für ihn Support machen. Bitte wende Dich direkt an Ronny.
Titel: Antw:AskSin++ Library
Beitrag von: The-Holgi am 24 Februar 2019, 14:23:26
Ok,
dafür habe ich natürlich Verständnis.

Gruß Holger
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 10 März 2019, 13:59:05
Zitat von: Tom Major am 25 Januar 2019, 18:58:16
ok, PR für den Fix des RTC sleep modes wurde gemacht und von papa gemerged.
Jetzt ist im RTC mode ca. 1uA Ruhestrom erreichbar (ohne Sensoren).

@papa,

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

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

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 10 März 2019, 14:11:04
Zitat von: fhemfreund am 10 März 2019, 13:59:05
Frage daher: gibt es die Möglichkeit eine Art Totzeit zu realisieren, in der *keine* Transmits stattfinden, egal ob ein Interrupt (durch den PIR) getriggert wird?

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

Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 12 März 2019, 01:10:38
Zitat von: jp112sdl am 10 März 2019, 14:11:04
Ja, schau dir mal die Motion.h an.
Beim HM Bewegungsmelder kann man auch sowas über List1-Parameter definieren.

Das Ganze soll für den Unisensor sein und der Dig.Input dort möglichst universell. Bin nicht sicher wie ich das mit Motion verheiratet bekomme.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 12 März 2019, 01:23:30
Zitat von: fhemfreund am 10 März 2019, 13:59:05
@papa,

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

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

Andreas

@papa
ich versuche mal die Frage so zu formulieren:

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

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

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

p.s. Das Update-Intervall soll dafür auch noch on-the-fly umprogrammiert werden, um nach Ende der Totzeit immer den aktuellen Status zu übertragen, nur das "Retrigger" innerhalb der Totzeit soll nicht senden.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 März 2019, 07:18:08
Ihr macht einfach einen Alarm, der eine interne Variable hat, ob neue Events gesendet werden sollen. Dieser wird mit dem Timeout in die RTC gehangen und bei neuen Events abgefragt. So macht es in etwas auch der Motion-Channel.

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

Wenn dann der Motionsensor ein Event liefert einfach

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

Alles nur hier schnell eingetippert. Wird wahrscheinlich nicht sofort durch den Compiler gehen. Aber die Idee sollte erkennbar sein.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 März 2019, 08:43:01
Alternativ könnte der Alarm aber auch einfach den Interrupt abschalten und im trigger() wieder anschalten. Damit würde dann keine Energie für die Interruptverarbeitung, die ja eh ignoriert wird, verschwendet.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 12 März 2019, 23:41:31
Hallo papa,
vielen Dank für die Idee mit der class SendePause, ich verstehe das Konzept, aber selber drauf gekommen wäre ich nicht.

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

In deinem Bsp. wacht der uC also völlig unabhängig vom Haupt-SendeIntervall des Sensors auf (ich weiß, eigentlich weckt die RTC sowieso jede Sekunde), setzt still und leise pause zurück (oder enabled den pin INT) und geht wieder in den sleep, korrekt?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 13 März 2019, 07:24:08
Zitat von: Tom Major am 12 März 2019, 23:41:31
Hallo papa,
vielen Dank für die Idee mit der class SendePause, ich verstehe das Konzept, aber selber drauf gekommen wäre ich nicht.

Das heißt die RTC kann quasi viele verschiedene virtual void trigger() bedienen, nicht nur einen. Weil SendePause von Alarm abgeleitet wird nehme ich an.
Genau. Die RTC verwaltet eine Liste mit auszulösenden Alarmen und ruft die trigger() entsprechend auf. Für "kleien" Sachen, kann auch noch async(true) im Alarm gesetzt werden. Dann erfolgt sie Ausführung direkt im Timer-Interupt. Sonst wird es im Main-Loop durch rtc.runready() synchron zur Anwendung ausgeführt. Die sysclock arbeitet genau gleich. Dadurch kann man recht einfach die CPU für die maximal mögliche Zeit schlafen legen, da ja der nächste zu berbeitende Alarm bekannt ist.
Zitat von: Tom Major am 12 März 2019, 23:41:31
In deinem Bsp. wacht der uC also völlig unabhängig vom Haupt-SendeIntervall des Sensors auf (ich weiß, eigentlich weckt die RTC sowieso jede Sekunde), setzt still und leise pause zurück (oder enabled den pin INT) und geht wieder in den sleep, korrekt?
Genau.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 13 März 2019, 16:46:14
Alles klar, sehr schönes Konzept, danke für die Erläuterungen  :)
Werde ich die nächsten Tage mal für einen ersten Test bei fhemfreund implementieren.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 24 März 2019, 11:38:18
Kann es sein, dass die Werte für die Frequenzanpassung jetzt nicht mehr durch einen LongPress Reset überschrieben werden? Irgendwo hatte ich da letztens was zu gelesen.

Ich nutze den Master Stand von heute.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 März 2019, 12:21:00
Zitat von: gloob am 24 März 2019, 11:38:18
Kann es sein, dass die Werte für die Frequenzanpassung jetzt nicht mehr durch einen LongPress Reset überschrieben werden? Irgendwo hatte ich da letztens was zu gelesen.

Ich nutze den Master Stand von heute.
Meiner Meinung nach sollte das auch bisher nicht passieren. Aber ich hatte noch keine Zeit, das nochmal zu debuggen. Der RESET löscht eigentlich nur die ersten 4 Byte im EEPROM. Damit stimmt beim nächsten Neustart die Checksumme nicht mehr und der Speicher wird neu eingerichtet. Dabei werden die ersten 4 Byte mit der Checksumme beschrieben und dann ab Byte 32 die Gerätedaten/ChannelListen. Der Bereich dazwischen sollte eigentlich nicht geändert werden. Und ganau da wird die Frequenz abgelegt.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 24 März 2019, 12:23:46
Okay dann funktioniert es mit der Frequenz wie gewünscht und ich kann den beschriebenen Fehler aus dem Nachbar Thread nicht nachvollziehen. Vielen Dank für die Erklärung.
Titel: Antw:AskSin++ Library
Beitrag von: CatWeazle am 27 März 2019, 20:20:24
Hi Leutz,

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

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

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



Titel: Antw:AskSin++ Library
Beitrag von: PeMue am 27 März 2019, 20:26:46
Zitat von: CatWeazle am 27 März 2019, 20:20:24
Was ich aber nicht gelesen, oder überlesen habe, wie kommt es zu dem Bat-Status Reading?
Braucht es noch einen Spannungsteiler an einem analogen Eingang oder erfasst die AskSin++ Library die Werte intern am AVR?
Tom hat das hier https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#messung-der-batteriespannung super dargestellt, die Schaltung die Messung ermöglichen und die Software natürlich auch. Sprich die ersten zwei sind Deine angesprochenen Varianten, die dritte halte ich jedoch für die Beste.

Gruß Peter
Titel: Antw:AskSin++ Library
Beitrag von: CatWeazle am 27 März 2019, 21:07:40
Hallo Peter,
danke für den Link.
Ja die dritte Lösung ist schon raffiniert, eine Last über einen FET zu schalten und dann messen, echt clever!

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

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

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

Fürs Erste, besten Dank.

Titel: Antw:AskSin++ Library
Beitrag von: vbs am 03 April 2019, 12:58:45
Ich versuche gerade etwas warm zu werden mit AskSin++ und hab mir einen von Tom's Sensoren gebaut: https://github.com/TomMajor/SmartHome/tree/master/PCB/Sensor_PLHT

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

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

Ein List vom Device:

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


Vermtl. anderes Problem aber mag auch zusammen hängen: Ich bekomme regelmäßig (ich glaube auch beim Drücken) diese Warning im Log:
2019.04.02 18:48:21.315 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.02 18:48:21.315 1: stacktrace:
2019.04.02 18:48:21.315 1:     main::__ANON__                      called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.02 18:48:21.317 1:     main::CUL_HM_getRegFromStore        called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.02 18:48:21.317 1:     main::CUL_HM_updtRegDisp            called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.02 18:48:21.317 1:     main::CUL_HM_parseCommon            called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.02 18:48:21.317 1:     main::CUL_HM_Parse                  called by fhem.pl (3893)
2019.04.02 18:48:21.317 1:     main::Dispatch                      called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.02 18:48:21.317 1:     main::HMUARTLGW_Parse               called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.02 18:48:21.317 1:     main::HMUARTLGW_Read                called by fhem.pl (3697)
2019.04.02 18:48:21.317 1:     main::CallFn                        called by fhem.pl (744)


("FHEM/HMConfig_UniSensor1.pm" hab ich installiert)
Titel: Antw:AskSin++ Library
Beitrag von: fhemfreund am 03 April 2019, 15:37:57
Zitat von: vbs am 03 April 2019, 12:58:45
...
Wenn ich zB "getConfig" mache, dann bekomme ich "Pending Message", die jedoch nie verarbeitet werden. Ich hätte gedacht, dass (ohne Burst) diese Messages bei der nächsten Kontaktaufnahem, also beim nächsten Senden, abgearbeitet werden. Ist aber nicht der Fall bei mir.
Erst wenn ich den Taster am Gerät drücke, dann wird offenbar genau eine Pending-Nachricht verarbeitet. Ich muss also mehrfalls drücken, um die Queue zu leeren. Kenne ich eigentlich bei HM-Sensoren anders. Ist das ein normales Verhalten oder geht da etwas schief?
...

Ist bei mir auch so. Sprich mit einem GetConfig + mehrmaligen Drücken des Tasters (sobald er auf Pending steht) wird dann die Config eingelesen.

Andreas
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 03 April 2019, 16:44:14
Das Verhalten bei der Übernahme von Config Änderungen habe ich hier mal versucht zu dokumentieren:
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L183
Die Kommentare zu BIDI und BCAST.

Zitat
// als Standard wird BCAST gesendet um Energie zu sparen, siehe Beschreibung unten.
// Bei jeder 20. Nachricht senden wir stattdessen BIDI|WKMEUP, um eventuell anstehende Konfigurationsänderungen auch
// ohne Betätigung des Anlerntaster übernehmen zu können (mit Verzögerung, worst-case 20x Sendeintervall).

Man kann das auf immer BIDI ändern wenn man will, dann wird es beim nächsten wakeup ohne Taster automatisch übernommen, zum Preis von leicht erhöhtem Funkverkehr wegen ACK.
Titel: Antw:AskSin++ Library
Beitrag von: vbs am 03 April 2019, 23:03:11
Ok danke, dann ist das ja ok soweit. Ich hab das probiert mit "BIDI" und es wird dann automatisch geholt. Danke!
Titel: Antw:AskSin++ Library
Beitrag von: SirBen am 12 April 2019, 11:44:34
Moin,
ich habe ein HM-LC-BL1-FM nachgebaut und an dem Example von der Asksin++ Library natürlich die Device ID und Device Serial geändert, außerdem noch für die Relais alle High und Low invertiert (habe active LOW Relais Module).
An sich funktioniert alles, nur ist manchmal der Wert "pct" auf "0" obwohl er anders sein sollte.
Mir ist aufgefallen, dass im Log direkt vor dem falschen pct-Wert der Aktor anscheinend einen Neustart durchführt und somit standardmäßig "0" angenommen wird.
Von dem Neustart merkt man nichts. Er tritt bisher immer nur dann auf, wenn der Rolladen geöffnet werden soll. Er fährt auch ohne Probleme komplett auf.
Hier mal der Auszug aus dem Log vom Device:
2019-04-10_07:08:39 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-10_07:08:39 HM_220301 level: 100
2019-04-10_07:08:39 HM_220301 motor: stop:on
2019-04-10_07:08:39 HM_220301 pct: 100
2019-04-10_07:08:39 HM_220301 on
2019-04-10_07:08:39 HM_220301 timedOn: off
2019-04-10_20:19:31 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-10_20:19:31 HM_220301 level: 0
2019-04-10_20:19:31 HM_220301 motor: stop:off
2019-04-10_20:19:31 HM_220301 pct: 0
2019-04-10_20:19:31 HM_220301 off
2019-04-10_20:19:31 HM_220301 timedOn: off
2019-04-11_07:41:47 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-11_07:41:47 HM_220301 level: 0
2019-04-11_07:41:47 HM_220301 motor: stop:off
2019-04-11_07:41:47 HM_220301 pct: 0
2019-04-11_07:41:47 HM_220301 powerOn: 2019-04-11 07:41:47
2019-04-11_07:41:47 HM_220301 off
2019-04-11_07:41:47 HM_220301 timedOn: off
2019-04-11_09:12:24 HM_220301 level: set_100
2019-04-11_09:12:24 HM_220301 set_100
2019-04-11_09:12:24 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-11_09:12:24 HM_220301 level: 0
2019-04-11_09:12:24 HM_220301 motor: stop:off
2019-04-11_09:12:24 HM_220301 pct: 0
2019-04-11_09:12:24 HM_220301 off
2019-04-11_09:12:24 HM_220301 timedOn: running
2019-04-11_09:12:58 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-11_09:12:58 HM_220301 level: 100
2019-04-11_09:12:58 HM_220301 motor: stop:on
2019-04-11_09:12:58 HM_220301 pct: 100
2019-04-11_09:12:58 HM_220301 on
2019-04-11_09:12:58 HM_220301 timedOn: off
2019-04-11_12:13:46 HM_220301 level: set_5
2019-04-11_12:13:46 HM_220301 set_5
2019-04-11_12:13:47 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-11_12:13:47 HM_220301 level: 100
2019-04-11_12:13:47 HM_220301 motor: stop:on
2019-04-11_12:13:47 HM_220301 pct: 100
2019-04-11_12:13:47 HM_220301 on
2019-04-11_12:13:47 HM_220301 timedOn: running
2019-04-11_12:14:14 HM_220301 deviceMsg: 5 (to nanoCUL)
2019-04-11_12:14:14 HM_220301 level: 5
2019-04-11_12:14:14 HM_220301 motor: stop:5
2019-04-11_12:14:14 HM_220301 pct: 5
2019-04-11_12:14:14 HM_220301 5
2019-04-11_12:14:14 HM_220301 timedOn: off
2019-04-11_13:49:19 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-11_13:49:19 HM_220301 level: 100
2019-04-11_13:49:19 HM_220301 motor: stop:on
2019-04-11_13:49:19 HM_220301 pct: 100
2019-04-11_13:49:19 HM_220301 on
2019-04-11_13:49:19 HM_220301 timedOn: off
2019-04-11_20:19:53 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-11_20:19:53 HM_220301 level: 0
2019-04-11_20:19:53 HM_220301 motor: stop:off
2019-04-11_20:19:53 HM_220301 pct: 0
2019-04-11_20:19:53 HM_220301 off
2019-04-11_20:19:53 HM_220301 timedOn: off
2019-04-12_07:40:04 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_07:40:04 HM_220301 level: 0
2019-04-12_07:40:04 HM_220301 motor: stop:off
2019-04-12_07:40:04 HM_220301 pct: 0
2019-04-12_07:40:04 HM_220301 powerOn: 2019-04-12 07:40:04
2019-04-12_07:40:04 HM_220301 off
2019-04-12_07:40:04 HM_220301 timedOn: off
2019-04-12_11:19:53 HM_220301 set_on
2019-04-12_11:19:53 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:19:53 HM_220301 level: 0
2019-04-12_11:19:53 HM_220301 motor: stop:off
2019-04-12_11:19:53 HM_220301 pct: 0
2019-04-12_11:19:53 HM_220301 off
2019-04-12_11:19:53 HM_220301 timedOn: running
2019-04-12_11:20:28 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:20:28 HM_220301 level: 0
2019-04-12_11:20:28 HM_220301 motor: stop:off
2019-04-12_11:20:28 HM_220301 pct: 0
2019-04-12_11:20:28 HM_220301 off
2019-04-12_11:20:28 HM_220301 timedOn: off
2019-04-12_11:20:58 HM_220301 level: set_100
2019-04-12_11:20:58 HM_220301 set_100
2019-04-12_11:20:59 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:20:59 HM_220301 level: 0
2019-04-12_11:20:59 HM_220301 motor: stop:off
2019-04-12_11:20:59 HM_220301 pct: 0
2019-04-12_11:20:59 HM_220301 off
2019-04-12_11:20:59 HM_220301 timedOn: running
2019-04-12_11:21:35 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:21:35 HM_220301 level: 0
2019-04-12_11:21:35 HM_220301 motor: stop:off
2019-04-12_11:21:35 HM_220301 pct: 0
2019-04-12_11:21:35 HM_220301 off
2019-04-12_11:21:35 HM_220301 timedOn: off
2019-04-12_11:22:01 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:22:01 HM_220301 level: 0
2019-04-12_11:22:01 HM_220301 motor: stop:off
2019-04-12_11:22:01 HM_220301 pct: 0
2019-04-12_11:22:01 HM_220301 off
2019-04-12_11:22:01 HM_220301 timedOn: off
2019-04-12_11:22:52 HM_220301 set_on
2019-04-12_11:22:52 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:22:52 HM_220301 level: 0
2019-04-12_11:22:52 HM_220301 motor: stop:off
2019-04-12_11:22:52 HM_220301 pct: 0
2019-04-12_11:22:52 HM_220301 off
2019-04-12_11:22:52 HM_220301 timedOn: running
2019-04-12_11:23:27 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:23:27 HM_220301 level: 0
2019-04-12_11:23:27 HM_220301 motor: stop:off
2019-04-12_11:23:27 HM_220301 pct: 0
2019-04-12_11:23:27 HM_220301 powerOn: 2019-04-12 11:23:27
2019-04-12_11:23:27 HM_220301 off
2019-04-12_11:23:27 HM_220301 timedOn: off
2019-04-12_11:23:59 HM_220301 set_on
2019-04-12_11:24:00 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-12_11:24:00 HM_220301 level: 0
2019-04-12_11:24:00 HM_220301 motor: stop:off
2019-04-12_11:24:00 HM_220301 pct: 0
2019-04-12_11:24:00 HM_220301 off
2019-04-12_11:24:00 HM_220301 timedOn: running
2019-04-12_11:24:33 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-12_11:24:33 HM_220301 level: 100
2019-04-12_11:24:33 HM_220301 motor: stop:on
2019-04-12_11:24:33 HM_220301 pct: 100
2019-04-12_11:24:33 HM_220301 on
2019-04-12_11:24:33 HM_220301 timedOn: off


und hier aus dem FHEM Log:
2019.04.11 09:12:24 3: CUL_HM set HM_220301 pct 100
2019.04.11 12:13:46 3: CUL_HM set HM_220301 pct 5
2019.04.12 11:19:53 3: CUL_HM set HM_220301 on
2019.04.12 11:20:58 3: CUL_HM set HM_220301 pct 100
2019.04.12 11:22:01 3: CUL_HM set HM_220301 statusRequest
2019.04.12 11:22:23 3: CUL_HM set HM_220301 getConfig
2019.04.12 11:22:52 3: CUL_HM set HM_220301 on
2019.04.12 11:23:59 3: CUL_HM set HM_220301 on


Hier das list vom Device:
Internals:
   DEF        220301
   FUUID      5c850f3f-f33f-2b06-52b6-3fe19a17ee2a0571
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     62
   NAME       HM_220301
   NOTIFYDEV  global
   NR         65
   NTFY_ORDER 50-HM_220301
   STATE      on
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:02 - t:10 s:220301 d:310388 0601C80048
   nanoCUL_MSGCNT 62
   nanoCUL_RAWMSG A0E02A2102203013103880601C80048::-76:nanoCUL
   nanoCUL_RSSI -76
   nanoCUL_TIME 2019-04-12 11:24:33
   peerList   self01,self02,
   protLastRcv 2019-04-12 11:24:33
   protRcv    61 last_at:2019-04-12 11:24:33
   protResnd  1 last_at:2019-04-09 12:27:23
   protSnd    61 last_at:2019-04-12 11:24:33
   protState  CMDs_done
   rssi_at_nanoCUL cnt:62 min:-81.5 max:-72 avg:-75.95 lst:-76
   rssi_nanoCUL cnt:27 min:-106 max:-72 avg:-77.22 lst:-72
   READINGS:
     2019-04-12 11:24:00   CommandAccepted yes
     2019-04-09 09:24:27   D-firmware      2.4
     2019-04-09 09:24:27   D-serialNr      RolloKind3
     2019-04-12 11:22:24   PairedTo        0x310388
     2019-04-08 12:22:03   R-confBtnTime   5 min
     2019-04-08 12:23:27   R-driveDown     26.5 s
     2019-01-16 11:08:32   R-driveTurn     0.5 s
     2019-04-08 12:23:27   R-driveUp       29 s
     2019-04-09 09:25:11   R-intKeyVisib   invisib
     2019-04-08 12:22:03   R-localResDis   off
     2019-04-09 09:25:11   R-pairCentral   0x310388
     2019-01-16 11:08:32   R-refRunCounter 0
     2019-01-16 11:08:34   R-self01-lgActionType jmpToTarget
     2019-01-16 11:08:34   R-self01-lgBlJtDlyOff refOff
     2019-01-16 11:08:34   R-self01-lgBlJtDlyOn dlyOff
     2019-01-16 11:08:34   R-self01-lgBlJtOff dlyOff
     2019-01-16 11:08:34   R-self01-lgBlJtOn dlyOff
     2019-01-16 11:08:34   R-self01-lgBlJtRampOff rampOff
     2019-01-16 11:08:34   R-self01-lgBlJtRampOn on
     2019-01-16 11:08:34   R-self01-lgBlJtRefOff rampOff
     2019-01-16 11:08:34   R-self01-lgBlJtRefOn on
     2019-01-16 11:08:34   R-self01-lgCtDlyOff geLo
     2019-01-16 11:08:34   R-self01-lgCtDlyOn geLo
     2019-01-16 11:08:34   R-self01-lgCtOff geLo
     2019-01-16 11:08:34   R-self01-lgCtOn geLo
     2019-01-16 11:08:34   R-self01-lgCtRampOff geLo
     2019-01-16 11:08:34   R-self01-lgCtRampOn geLo
     2019-01-16 11:08:34   R-self01-lgCtRefOff geLo
     2019-01-16 11:08:34   R-self01-lgCtRefOn geLo
     2019-01-16 11:08:34   R-self01-lgCtValHi 100
     2019-01-16 11:08:34   R-self01-lgCtValLo 50
     2019-01-16 11:08:34   R-self01-lgDriveMode direct
     2019-01-16 11:08:34   R-self01-lgMaxTimeF 0.5 s
     2019-01-16 11:08:34   R-self01-lgMultiExec on
     2019-01-16 11:08:34   R-self01-lgOffDly 0 s
     2019-01-16 11:08:34   R-self01-lgOffLevel 0 %
     2019-01-16 11:08:34   R-self01-lgOffTime unused
     2019-01-16 11:08:34   R-self01-lgOffTimeMode absolut
     2019-01-16 11:08:34   R-self01-lgOnDly 0 s
     2019-01-16 11:08:34   R-self01-lgOnLevel 100 %
     2019-01-16 11:08:34   R-self01-lgOnTime unused
     2019-01-16 11:08:34   R-self01-lgOnTimeMode absolut
     2019-01-16 11:08:34   R-self01-shActionType jmpToTarget
     2019-01-16 11:08:34   R-self01-shBlJtDlyOff refOff
     2019-01-16 11:08:34   R-self01-shBlJtDlyOn dlyOff
     2019-01-16 11:08:34   R-self01-shBlJtOff dlyOff
     2019-01-16 11:08:34   R-self01-shBlJtOn dlyOff
     2019-04-08 12:22:05   R-self01-shBlJtRampOff rampOff
     2019-04-08 11:59:45   R-self01-shBlJtRampOn on
     2019-01-16 11:08:34   R-self01-shBlJtRefOff rampOff
     2019-01-16 11:08:34   R-self01-shBlJtRefOn on
     2019-01-16 11:08:34   R-self01-shCtDlyOff geLo
     2019-01-16 11:08:34   R-self01-shCtDlyOn geLo
     2019-01-16 11:08:34   R-self01-shCtOff geLo
     2019-01-16 11:08:34   R-self01-shCtOn geLo
     2019-01-16 11:08:34   R-self01-shCtRampOff geLo
     2019-01-16 11:08:34   R-self01-shCtRampOn geLo
     2019-01-16 11:08:34   R-self01-shCtRefOff geLo
     2019-01-16 11:08:34   R-self01-shCtRefOn geLo
     2019-01-16 11:08:34   R-self01-shCtValHi 100
     2019-01-16 11:08:34   R-self01-shCtValLo 50
     2019-01-16 11:08:34   R-self01-shDriveMode direct
     2019-01-16 11:08:34   R-self01-shMaxTimeF unused
     2019-01-16 11:08:34   R-self01-shMultiExec off
     2019-01-16 11:08:34   R-self01-shOffDly 0 s
     2019-01-16 11:08:34   R-self01-shOffLevel 0 %
     2019-01-16 11:08:34   R-self01-shOffTime unused
     2019-01-16 11:08:34   R-self01-shOffTimeMode absolut
     2019-01-16 11:08:34   R-self01-shOnDly 0 s
     2019-01-16 11:08:34   R-self01-shOnLevel 100 %
     2019-01-16 11:08:34   R-self01-shOnTime unused
     2019-01-16 11:08:34   R-self01-shOnTimeMode absolut
     2019-01-16 11:08:35   R-self02-lgActionType jmpToTarget
     2019-01-16 11:08:35   R-self02-lgBlJtDlyOff dlyOn
     2019-01-16 11:08:35   R-self02-lgBlJtDlyOn refOn
     2019-01-16 11:08:35   R-self02-lgBlJtOff dlyOn
     2019-01-16 11:08:35   R-self02-lgBlJtOn dlyOn
     2019-01-16 11:08:35   R-self02-lgBlJtRampOff off
     2019-01-16 11:08:35   R-self02-lgBlJtRampOn rampOn
     2019-01-16 11:08:35   R-self02-lgBlJtRefOff off
     2019-01-16 11:08:35   R-self02-lgBlJtRefOn rampOn
     2019-01-16 11:08:35   R-self02-lgCtDlyOff geLo
     2019-01-16 11:08:35   R-self02-lgCtDlyOn geLo
     2019-01-16 11:08:35   R-self02-lgCtOff geLo
     2019-01-16 11:08:35   R-self02-lgCtOn geLo
     2019-01-16 11:08:35   R-self02-lgCtRampOff geLo
     2019-01-16 11:08:35   R-self02-lgCtRampOn geLo
     2019-01-16 11:08:35   R-self02-lgCtRefOff geLo
     2019-01-16 11:08:35   R-self02-lgCtRefOn geLo
     2019-01-16 11:08:35   R-self02-lgCtValHi 100
     2019-01-16 11:08:35   R-self02-lgCtValLo 50
     2019-01-16 11:08:35   R-self02-lgDriveMode direct
     2019-01-16 11:08:35   R-self02-lgMaxTimeF 0.5 s
     2019-01-16 11:08:35   R-self02-lgMultiExec on
     2019-01-16 11:08:35   R-self02-lgOffDly 0 s
     2019-01-16 11:08:35   R-self02-lgOffLevel 0 %
     2019-01-16 11:08:35   R-self02-lgOffTime unused
     2019-01-16 11:08:35   R-self02-lgOffTimeMode absolut
     2019-01-16 11:08:35   R-self02-lgOnDly 0 s
     2019-01-16 11:08:35   R-self02-lgOnLevel 100 %
     2019-01-16 11:08:35   R-self02-lgOnTime unused
     2019-01-16 11:08:35   R-self02-lgOnTimeMode absolut
     2019-01-16 11:08:35   R-self02-shActionType jmpToTarget
     2019-01-16 11:08:35   R-self02-shBlJtDlyOff dlyOn
     2019-01-16 11:08:35   R-self02-shBlJtDlyOn refOn
     2019-01-16 11:08:35   R-self02-shBlJtOff dlyOn
     2019-01-16 11:08:35   R-self02-shBlJtOn dlyOn
     2019-04-08 11:59:46   R-self02-shBlJtRampOff off
     2019-04-08 12:22:06   R-self02-shBlJtRampOn rampOn
     2019-01-16 11:08:35   R-self02-shBlJtRefOff off
     2019-01-16 11:08:35   R-self02-shBlJtRefOn rampOn
     2019-01-16 11:08:35   R-self02-shCtDlyOff geLo
     2019-01-16 11:08:35   R-self02-shCtDlyOn geLo
     2019-01-16 11:08:35   R-self02-shCtOff geLo
     2019-01-16 11:08:35   R-self02-shCtOn geLo
     2019-01-16 11:08:35   R-self02-shCtRampOff geLo
     2019-01-16 11:08:35   R-self02-shCtRampOn geLo
     2019-01-16 11:08:35   R-self02-shCtRefOff geLo
     2019-01-16 11:08:35   R-self02-shCtRefOn geLo
     2019-01-16 11:08:35   R-self02-shCtValHi 100
     2019-01-16 11:08:35   R-self02-shCtValLo 50
     2019-01-16 11:08:35   R-self02-shDriveMode direct
     2019-01-16 11:08:35   R-self02-shMaxTimeF unused
     2019-01-16 11:08:35   R-self02-shMultiExec off
     2019-01-16 11:08:35   R-self02-shOffDly 0 s
     2019-01-16 11:08:35   R-self02-shOffLevel 0 %
     2019-01-16 11:08:35   R-self02-shOffTime unused
     2019-01-16 11:08:35   R-self02-shOffTimeMode absolut
     2019-01-16 11:08:35   R-self02-shOnDly 0 s
     2019-01-16 11:08:35   R-self02-shOnLevel 100 %
     2019-01-16 11:08:35   R-self02-shOnTime unused
     2019-01-16 11:08:35   R-self02-shOnTimeMode absolut
     2019-01-16 11:08:32   R-sign          off
     2019-01-16 11:08:32   R-statusInfoMinDly 2 s
     2019-01-16 11:08:32   R-statusInfoRandom 1 s
     2019-01-16 11:08:32   R-transmitTryMax 6
     2019-04-12 11:22:23   RegL_00.         00:00 02:01 0A:31 0B:03 0C:88 15:05 18:00
     2019-04-12 11:22:24   RegL_01.         00:00 08:00 0B:01 0C:09 0D:01 0E:22 0F:05 10:00 30:06 57:24
     2019-04-12 11:22:25   RegL_03.self01   00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0F:00 11:C8 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8F:00 91:C8 9C:00 9D:05 9E:93 9F:00
     2019-04-12 11:22:27   RegL_03.self02   00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0F:00 11:C8 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8F:00 91:C8 9C:00 9D:05 9E:68 9F:00
     2019-04-12 11:24:33   deviceMsg       on (to nanoCUL)
     2019-04-12 11:24:33   level           100
     2019-04-12 11:24:33   motor           stop:on
     2019-04-12 11:24:33   pct             100
     2019-04-12 11:22:24   peerList        self01,self02,
     2019-04-12 11:23:27   powerOn         2019-04-12 11:23:27
     2019-04-12 11:24:33   recentStateType info
     2019-04-12 11:24:33   state           on
     2019-04-12 11:24:33   timedOn         off
   helper:
     HM_CMDNR   2
     PONtest    0
     cSnd       113103882203010201C80000,113103882203010201C80000
     dlvlCmd    ++A0113103882203010201C80000
     mId        0005
     peerFriend peerSens,peerVirt
     peerIDsRaw ,22030101,22030102,00000000
     peerOpt    3:blindActuator
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     dir:
       cur        stop
       rct        up
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +220301,00,00,00
       nextSend   1555061073.72008
       prefIO     
       rxt        0
       vccu       
       p:
         220301
         00
         00
         00
     mRssi:
       mNo        02
       io:
         nanoCUL:
           -74
           -74
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         nanoCUL
       flg        A
       ts         1555061073.62327
       ack:
         HASH(0x1d05008)
         02800231038822030100
     rssi:
       at_nanoCUL:
         avg        -75.9516129032258
         cnt        62
         lst        -76
         max        -72
         min        -81.5
       nanoCUL:
         avg        -77.2222222222222
         cnt        27
         lst        -72
         max        -72
         min        -106
     shadowReg:
     tmpl:
Attributes:
   IODev      nanoCUL
   autoReadReg 4_reqStatus
   expert     251_anything
   firmware   2.4
   genericDeviceType blind
   model      HM-LC-BL1-FM
   peerIDs    00000000,22030101,22030102,
   room       Tobi,CUL_HM,Homebridge
   serialNr   RolloKind3
   subType    blindActuator
   webCmd     statusRequest:toggleDir:on:off:up:down:stop


Ich habe am Aktor 2 Taster angeschlossen für die manuelle Bedienung. Diese sind auch active-Low, also beim Betätigen 0V, sonst 3.3V.

Hat jemand eine Ahnung woran das liegen kann? Bin ziemlich ratlos.
Ich bin doch bestimmt nicht der Einzige, der den Code von pa-pa benutz?!

Vielen Dank schon mal.
Gruß Ben
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 April 2019, 14:52:02
Hm - aus den FHEM-Logs sieht man nicht wirklich was. Kannst Du mal an der seriellen Konsole am Geräte mitloggen ?
Titel: Antw:AskSin++ Library
Beitrag von: SirBen am 12 April 2019, 15:41:07
Das Gerät ist im Rolladenkasten eingebaut. Komme da nicht so leicht ran.
Eventuell könnte ich einfach noch einen Rolladen umrüsten und prüfen, ob dort das gleiche Problem auftritt.
könnte aber ein paar Tage dauern...
Titel: Antw:AskSin++ Library
Beitrag von: SirBen am 15 April 2019, 13:02:58
Moin,
mir ist heute noch was aufgefallen. Heute morgen ist der Rolladen mit dem Taster angesteuert geöffnet worden (kurz vor dem ersten Log Eintrag). Das Feedback vom Aktor an FHEM war wieder "0".
Danach habe ich den "on" Befehl von FHEM an den Aktor gesendet und nach 36 Sekunden kommt wieder die Position "0" vom Aktor.
Nach einem erneuten Versuch den Rolladen auf 100% zu setzen mittels FHEM kommt 34 Sekunden später die Antwort, dass er endlich auf 100% steht (also open).
Die Fahrzeit ist fürs Öffnen mit 29 Sekunden hinterlegt.

Hier mal die LOG Auszüge:
2019-04-15_07:32:14 HM_220301 level: 0
2019-04-15_07:32:14 HM_220301 motor: stop:off
2019-04-15_07:32:14 HM_220301 pct: 0
2019-04-15_07:32:14 HM_220301 powerOn: 2019-04-15 07:32:14
2019-04-15_07:32:14 HM_220301 off
2019-04-15_07:32:14 HM_220301 timedOn: off
2019-04-15_10:18:39 HM_220301 set_on
2019-04-15_10:18:39 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-15_10:18:39 HM_220301 level: 0
2019-04-15_10:18:39 HM_220301 motor: stop:off
2019-04-15_10:18:39 HM_220301 pct: 0
2019-04-15_10:18:39 HM_220301 off
2019-04-15_10:18:39 HM_220301 timedOn: running
2019-04-15_10:19:15 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-15_10:19:15 HM_220301 level: 0
2019-04-15_10:19:15 HM_220301 motor: stop:off
2019-04-15_10:19:15 HM_220301 pct: 0
2019-04-15_10:19:15 HM_220301 off
2019-04-15_10:19:15 HM_220301 timedOn: off
2019-04-15_12:52:49 HM_220301 level: set_100
2019-04-15_12:52:49 HM_220301 set_100
2019-04-15_12:52:49 HM_220301 deviceMsg: off (to nanoCUL)
2019-04-15_12:52:49 HM_220301 level: 0
2019-04-15_12:52:49 HM_220301 motor: stop:off
2019-04-15_12:52:49 HM_220301 pct: 0
2019-04-15_12:52:49 HM_220301 off
2019-04-15_12:52:49 HM_220301 timedOn: running
2019-04-15_12:53:23 HM_220301 deviceMsg: on (to nanoCUL)
2019-04-15_12:53:23 HM_220301 level: 100
2019-04-15_12:53:23 HM_220301 motor: stop:on
2019-04-15_12:53:23 HM_220301 pct: 100
2019-04-15_12:53:23 HM_220301 on
2019-04-15_12:53:23 HM_220301 timedOn: off


Ich finde das seltsam...
Kann mir jemand die Log Einträge erklären? Was z.B. bedeutet "motor: stop:off" und "tidemOn: off"?

Danke und Gruß
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 April 2019, 20:32:08
Hm - bei mir (original HM-LC-Bl1PBU-FM) entspricht 0 -> Offen und 100 -> Geschlossen. Ich denke, so funktioniert auch die Implementierung der AskSinPP.

Komisch ist, dass er bei "set on" scheinbar nach 0 fährt - auch wenn er schon da ist. Hast Du irgendwas im Code geändert ? Der serielle Log wäre hier wirklich hilfreich.
Titel: Antw:AskSin++ Library
Beitrag von: SirBen am 25 April 2019, 14:34:44
ZitatMoin,
ich habe ein HM-LC-BL1-FM nachgebaut und an dem Example von der Asksin++ Library natürlich die Device ID und Device Serial geändert, außerdem noch für die Relais alle High und Low invertiert (habe active LOW Relais Module).
An sich funktioniert alles, nur ist manchmal der Wert "pct" auf "0" obwohl er anders sein sollte.
Mir ist aufgefallen, dass im Log direkt vor dem falschen pct-Wert der Aktor anscheinend einen Neustart durchführt und somit standardmäßig "0" angenommen wird.
Von dem Neustart merkt man nichts. Er tritt bisher immer nur dann auf, wenn der Rolladen geöffnet werden soll. Er fährt auch ohne Probleme komplett auf.

Moin,
ich habe es heute geschafft, ein bisschen mehr Fehlersuche zu betreiben.
Mit angeschlossenem FTDI USB to Serial Adapter funktioniert die Steuerung ohne Fehler.  :o
Ich habe mindestens 20 mal verschiedene Stellungen angefahren.
Kaum war der Adapter getrennt, schon nach dem zweiten Fahrvorgang ein reboot.
Für mich klingt das nach einem Problem der Spannungsversorgung.
Versorgt wird das Gerät von einem HiLink 5V 3W Modul.
Die 3.3V nehme ich direkt am pro mini ab und benötige diese für das CC1101 Modul und die Optokoppler Schaltung für die Taster und das Relais Modul.
Meine Vermutung liegt in der 3.3V Versorgung. Eventuell wird diese zu lange zu stark belastet, dass für den pro mini nicht mehr genügend Leistung übrig ist und ein Neustart erfolgt.
Könnte das eine Erklärung sein? Oder bin ich dort total auf dem Holzweg?
Ich bin über jeden Denkanstoß dankbar.
Gruß Ben

Edit: Ich habe noch weiter recherchiert. Es könnte wirklich was dran sein an der Spannungsversorgung:
http://tips-und-mehr.de/cul-selbstbau-spannungstechnisch-auf-der-sicheren-seite/ (http://tips-und-mehr.de/cul-selbstbau-spannungstechnisch-auf-der-sicheren-seite/)
Man beachte den Kommentar von Dirk Anderseck.
Somit werde ich (sobald es meine Zeit zulässt) einen Kondensator zusätzlich einbauen. Ich werde berichten...
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 April 2019, 17:05:46
Das kann schon sein, aber ohne Schaltplan kann man da nichts sagen.
Titel: Antw:AskSin++ Library
Beitrag von: SirBen am 30 April 2019, 13:56:41
Moin,
eine kurze Rückmeldung: es lag am fehlenden Kondensator.
Ich habe die 3,3V Spannungsversorgung für das CC1101 Modul mit einem 100uF Kondensator erweitert (vielleicht reichen auch 10uF) und jetzt funktioniert die Schaltung fehlerfrei.
@papa
Wenn du möchtest, kannst du das gerne auf GitHub oder deiner sehr gut gelungenen asksin Seite aufmerken.
Vielleicht hilft das ja dem einen oder anderen.
Vielen Dank für die Bemühungen!
Gruß
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 07 Mai 2019, 09:22:24
Hallo,

ich habe eine ganze Reihe von HM_SW4 Selbstbau Aktoren in Betrieb, alle mit AES. Alle sind vollstandig gepairt, HM info liefert keine offenen Punkte. An einem der Aktoren habe ich ein seltsames Problem:

Wenn ich den Aktor schalte, dann funktioniert alles prächtig. Er schaltet das Relais, die Bestätigung kommt. Nach ca 2 min schaltet der Aktor aber selbstständig auf off.

Ich habe den Aktor mehrfach neu beschrieben und gepairt. Immer das gleiche Verhalten. Die lists von den Aktoren sind bis auf IDs identisch.

HM_66815A ....  funktioniert nicht
HM_668159 ... funktioniert

Log
2019.05.07 07:12:06 3: CUL_HM set Sprinkler5 on
2019.05.07 07:12:07 3: CUL_HM set Sprinkler4 on
2019.05.07 07:12:08 4: CUL_HM_Resend: HM_66815A nr 2
2019.05.07 07:12:08 5: CUL_HM HM_66815A signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:08 5: CUL_HM HM_66815A signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:08 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:2
2019.05.07 07:12:08 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:1
2019.05.07 07:12:08 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:12:08 3: CUL_HM set Sprinkler3 on
2019.05.07 07:12:08 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:08 5: CUL_HM HM_66815A signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:08 5: CUL_HM HM_66815A signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:08 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:1
2019.05.07 07:12:09 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:09 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:09 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:09 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:0
2019.05.07 07:12:09 5: CUL_HM HM_668159 protEvent:CMDs_done_Errors:1
2019.05.07 07:12:09 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:12:09 3: CUL_HM set Sprinkler2 on
2019.05.07 07:12:09 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:10 3: CUL_HM set Sprinkler1 on
2019.05.07 07:12:12 4: CUL_HM_Resend: HM_66815A nr 2
2019.05.07 07:12:12 5: CUL_HM HM_66815A signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:12 5: CUL_HM HM_66815A signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:12 5: CUL_HM HM_66815A protEvent:CMDs_processing... pending:0
2019.05.07 07:12:12 3: CUL_HM set Pump on
2019.05.07 07:12:12 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:12:13 4: CUL_HM_Resend: HM_668159 nr 2
2019.05.07 07:12:13 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:13 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:13 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:2
2019.05.07 07:12:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:1
2019.05.07 07:12:14 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:14 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:1
2019.05.07 07:12:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:14 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:12:14 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:12:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:12:15 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A sent ACK:2
2019.05.07 07:14:00 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A sent ACK:2
2019.05.07 07:14:00 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A sent ACK:2
2019.05.07 07:14:00 5: CUL_HM HM_66815A protEvent:CMDs_done
2019.05.07 07:14:00 5: CUL_HM HM_66815A sent ACK:2
2019.05.07 07:15:02 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:02 3: CUL_HM set Sprinkler3 on
2019.05.07 07:15:02 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:02 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:02 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:15:02 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:02 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:15:12 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:12 3: CUL_HM set Sprinkler3 off
2019.05.07 07:15:12 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:13 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:13 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:13 3: CUL_HM set Sprinkler2 off
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:13 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:13 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:15:13 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:14 3: CUL_HM set Sprinkler1 off
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:14 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:14 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd to authenticate
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:14 5: CUL_HM HM_668159 protEvent:CMDs_done
2019.05.07 07:15:15 5: CUL_HM HM_668159 protEvent:CMDs_pending pending:1
2019.05.07 07:15:15 3: CUL_HM set Pump off
2019.05.07 07:15:15 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:15 5: CUL_HM HM_668159 signing request for Asxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx challenge: ccccccccccccc kNo: 1
2019.05.07 07:15:15 5: CUL_HM HM_668159 signing response: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy should send ddddddddddd  to authenticate
2019.05.07 07:15:15 5: CUL_HM HM_668159 protEvent:CMDs_processing... pending:0
2019.05.07 07:15:15 5: CUL_HM HM_668159 protEvent:CMDs_done


Hat jemand eine Idee?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Mai 2019, 09:31:56
Mach mal nen RESET - und dann neu anlernen.
Titel: Antw:AskSin++ Library
Beitrag von: MBHG am 07 Mai 2019, 11:27:07
Danke, hatte ich schon mehrfach gemacht. Ich habe es nach drei Tagen gerade gefunden: das passiert nur, wenn viele Aktoren an sind, dh viele Relais geschaltet sind. Anscheinend ist der USB Charger zu schwach und der HM_66815A macht einen Reset und sendet für alle Aktoren Status off. Der HM_668159 kommt wohl mit geringfügig weniger Spannung aus.

Danke für den Hinweis.

Marc


Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Mai 2019, 12:15:13
Sowas sollte man gut in den seriellen Ausgaben sehen. Das wäre meine nächste Frage gewesen :-)
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 Mai 2019, 00:19:18
fhemfreund hat bei meiner HB-UNI-Sensor1 Variante das Problem das sich die LED nicht ausschalten lässt.
Bei mir über RaspberryMatic geht das.
Ich habe diese Debugausgabe in configChanged() für list0 drin:

virtual void configChanged()
    {
        TSDevice::configChanged();
        DPRINTLN("Config Changed: List0");

        uint8_t ledMode = this->getList0().ledMode();
        DPRINT("ledMode: ");
        DDECLN(ledMode);
...
...


Dort sieht man das bei Änderungen des LED modes korrekt 0 oder 1 ausgegeben wird:

-> 0A 0A 81 02 F11034 A5A500 00  - 5982
-> 10 13 A0 01 F11034 A5A500 00 05 00 00 00 00 00  - 6017
<- 0A 13 80 02 A5A500 F11034 00  - 6131
-> 0D 1C A0 01 F11034 A5A500 00 08 05 40  - 6166
<- 0A 1C 80 02 A5A500 F11034 00  - 6281
-> 0B 25 A0 01 F11034 A5A500 00 06  - 6311
Config Changed: List0
ledMode: 1
lowBatLimit: 21
transmitDevTryMax: 6
updCycle: 120
altitude: 0
<- 0A 25 82 02 A5A500 F11034 00  - 6430
debounce
pressed
released
<- 1A 0B 80 00 A5A500 F11034 12 F1 03 55 4E 49 53 45 4E 53 30 30 31 70 01 01 01  - 8478

-> 0A 0B 80 02 F11034 A5A500 00  - 8589
ignore 14 E4 80 5E 29F26F F11034 00 00 00 00 00 00 04 53 00 00 00  - 9728
ignore 14 E5 80 5E 29F26F F11034 00 00 00 00 00 00 04 51 00 00 00  - 28346
debounce
pressed
released
<- 1A 0C 80 00 A5A500 F11034 12 F1 03 55 4E 49 53 45 4E 53 30 30 31 70 01 01 01  - 28526

ignore 0F F0 86 10 639BDE 000000 0A B8 FE 0E 18 40  - 28590
-> 0A 0C 81 02 F11034 A5A500 00  - 28637
-> 10 15 A0 01 F11034 A5A500 00 05 00 00 00 00 00  - 28672
<- 0A 15 80 02 A5A500 F11034 00  - 28786
-> 0D 1E A0 01 F11034 A5A500 00 08 05 00  - 28821
<- 0A 1E 80 02 A5A500 F11034 00  - 28936
-> 0B 27 A0 01 F11034 A5A500 00 06  - 28968
Config Changed: List0
ledMode: 0
lowBatLimit: 21
transmitDevTryMax: 6
updCycle: 120
altitude: 0
<- 0A 27 82 02 A5A500 F11034 00  - 29087
ignore 14 E7 80 5E 29F26F F11034 00 00 00 00 00 00 04 4F 00 00 00  - 35471


trotzdem blinkt die LED beim Senden bei ihm.

Ich muss in configChanged() nichts weiter tun, oder? da ich DREG_LEDMODE bei DEFREGISTER angegeben habe sollte die Senderoutine dort nachschauen und die LED ggf. aus lassen, korrekt?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Mai 2019, 08:32:56
Hm, eigentlich beachtet Device::send den LedMode aus List0. Aber vielleicht gibt es auch noch andere Stellen, wo die Led angesteuert wird und  das nicht geprüft wird. Am besten/einfachsten dürfte es sein, wenn die Led selbst abgeschaltet werden kann - so wie der Invert-Modus. Dann bräuchte der Rest des Systems das/die Settings, die dafür verantwortlich sind, nicht kennen. Kannst ja mal nen Issue im Github auf machen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 11 Mai 2019, 00:44:27
ok, wollte nur erst mal sicher gehen dass ich bei der LED nichts übersehen habe. Das Merkwürdige ist halt das meine Tests diesbezüglich funktioniert hatten, aber bei fhemfreund nicht.
@fhemfreund: Kannst du mal bitte den DigitalInput im sketch deaktivieren und schauen ob es mit der LED dann ev. geht?
Die Idee mit neuem Setter für LED on/off finde ich gut, kann das gern mit der issue machen.
Titel: Antw:AskSin++ Library
Beitrag von: neumann am 27 Mai 2019, 21:02:15
Hey!
Ich möchte gerne die Fernbedienung für mein KeyMatic nachbauen (HM-SEC-KEY).
Dazu verwende ich den Beispiel-Sketch HM-RC-4. Das klappt auch soweit gut, leider bekomme ich jedoch AES nicht zum laufen (assignHmKey liefert ein Nack).
Das peering an KeyMatic klappt ebenfalls nicht.
Wäre sehr lieb, wenn ihr mir helfen könntet!

Lg
Oskar
Titel: Antw:AskSin++ Library
Beitrag von: papa am 27 Mai 2019, 21:15:30
Hast Du auch den AES-Support aktiviert ?

https://github.com/pa-pa/AskSinPP#enable-aes-support
Titel: Antw:AskSin++ Library
Beitrag von: neumann am 27 Mai 2019, 23:27:31
Klappt nun :) Ich weiß zwar nicht, was ich geändert habe. Ich glaube, es lag am Empfang zur VCCU.
Danke!

Lg
Titel: Antw:AskSin++ Library
Beitrag von: neumann am 07 Juni 2019, 12:10:25
Hallo zusammen,

ich möchte ein Multi-Channel Gerät mit einem Button Kanal und einem Datenkanal (ein Byte) erstellen.
Welches Template nehme ich dafür am besten?

Lg
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Juni 2019, 12:53:01
Hm, das ist gar nicht so einfach, da es kein vergleichbares original Gerät gibt. Am ehesten passt da noch mein HB-DoorBell Example (stm32), was mal eine Türklingel inklusive Klimadaten-Messung und IButton-Support werden soll. Da kannst Du Dir ansehen, wie man die Channels zusammenbaut. Du brauchst einen Remote-Channel für den Button und einen Value-Channel für die Daten. Für Dein neues Gerät musst Du auch ein neues Device-Model definieren.

Damit FHEM damit umgehen kann, muss auch ein entsprechendes Config-File erzeugt werden. Die HB-DoorBell findest Du im HMConfig_AskSinPPCustom.pm. Doku gibt es dazu nicht wirklich. Da musst Du probieren, bis es geht. Da Du ja nur die Channels richtig zurecht rücken musst, solle es aber machbar sein.
Titel: Antw:AskSin++ Library
Beitrag von: Prof. Dr. Peter Henning am 07 Juni 2019, 13:02:50
ZitatDoku gibt es dazu nicht wirklich.
Amen, Bruder, Amen.

in Anbetracht der Tatsache, dass eQ3 HM so langsam gegen die Wand fährt, wäre es höchste Zeit, diesen Mangel zu beheben. Ich trage gerne meinen Teil dazu bei.

LG

pah
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 07 Juni 2019, 13:42:45
Naja die wollen eben das sicherere HmIP forcen, wobei "sicher" nur für heute spricht. Da kann man sich mal folgende Slides anschauen, den Vortrag habe ich gerade bei einem Security Summit verfolgt:

https://www.avantec.ch/wp-content/uploads/2019/05/michael-osborne-it-security-inside-19.pdf

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: Prof. Dr. Peter Henning am 07 Juni 2019, 14:27:13
Auf unserer letzten "Langen Nacht der Mathematik" habe ich mal wieder den Mitternachtsvortrag gehalten - unter dem Titel "Quantencomputer und die Zukunft von Google".

LG

pah
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 07 Juni 2019, 14:32:18
Hast du da noch Folien von? Würde mich bzw. meine Kollegen ja glatt weg mal interessieren.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: surfi am 09 Juni 2019, 22:34:43
Eine Art Doku fänd ich auch sehr charmant. Ich möchte mir die HB-UNI-SEN-WEA von jp nachbauen,
bin aber bislang sehr kläglich an den Einträgen in der Asksincustompp gescheitert.

Hat vielleicht schon jemand diese Wetterstation in fhem integriert bekommen?

Titel: Antw:AskSin++ Library
Beitrag von: gloob am 10 Juni 2019, 20:54:10
Zitat von: papa am 29 Juni 2018, 15:57:36
Es gibt jetzt ein Register eventDlyTime im Value-Channel. Dieses enthält die Zeit zwischen 2 Nachrichten. Es wird mit 180s initialisiert. Damit FHEM das Register kennt, muss die HMConfig_AskSinPPCustom.pm aktualisiert und neu geladen werden.

Wie groß ist eigentlich der maximale Wert vom Register? Kann ich einen uint16_t setzen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Juni 2019, 21:51:43
  eventDlyTime    =>{a=> 33  ,s=>1  ,l=>1,min=>0      ,max=>7620   ,c=>'fltCvT60',p=>'n',f=>''      ,u=>'s'   ,d=>1,t=>"filters short events, causes reporting delay"},
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 10 Juni 2019, 21:54:21
Zitat von: papa am 10 Juni 2019, 21:51:43
  eventDlyTime    =>{a=> 33  ,s=>1  ,l=>1,min=>0      ,max=>7620   ,c=>'fltCvT60',p=>'n',f=>''      ,u=>'s'   ,d=>1,t=>"filters short events, causes reporting delay"},


Danke. Woher kommt denn das max=7620?
Der Timer kann ja auch längere Zeiten.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Juni 2019, 23:08:14
https://github.com/mhop/fhem-mirror/blob/515788acadd92a1304e55044a76879f5c167d620/fhem/FHEM/HMConfig.pm#L679
Titel: Antw:AskSin++ Library
Beitrag von: neumann am 11 Juni 2019, 14:14:52
Muss man den eigenen custom AES Schlüssel eigentlich immer pre-deployen oder kann man ihn auch nachträglich über assignHmKey mitteilen?
Wenn ich das versuche, kommt ein Nack. Pre-deployment klappt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 11 Juni 2019, 14:47:12
assignHmKey geht nur, wenn Du vorher den Default-Key eingetragen hast. Lies mal hier
https://homematic-forum.de/forum/viewtopic.php?f=76&t=44178
Titel: Antw:AskSin++ Library
Beitrag von: rih am 12 Juni 2019, 21:20:11
Hallo papa,

ich habe den HB-UNI-Sen-PRESS nachgebaut und möchte damit zwei Druckschalter abfragen. Das habe ich im Sketch entsprechend konfiguriert und funktioniert auch soweit laut seriellem Monitor der Arduino-IDE.

Allerdings habe ich keine CCU, sondern möchte die Drücke direkt in FHEM einlesen. Dazu hast Du ja die HMConfig_AskSinPPCustom.pm für FHEM geschrieben, in der Du u.a. auch den HB-UNI-Sen-PRESS verarbeitest. Leider verarbeitest Du in dem Programm aber nur einen Kanal bzw. Druckschalter, sofern ich den Code richtig verstanden habe.

Kannst Du mir bitte sagen, wie ich den Druckschalter-Abschnitt in der HMConfig_AskSinPPCustom.pm erweitern muss, damit zwei Kanäle mit den entsprechenden Werten in FHEM angezeigt werden?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Juni 2019, 21:32:05
FHEM kann leider mit der dynamischen Kanalanzahl nicht umgehen. Du musst ein neues Gerät mit 2 Kanälen definieren. Ohne Garantie
$HMConfig::culHmModel{"????"} = {name=>"HB-UNI-Sen-PRESS2",st=>'custom',cyc=>'',rxt=>'c:l',lst=>'1',chn=>"Pressure:1:2"};
$HMConfig::culHmChanSets{"HB-UNI-Sen-PRESS200"}{fwUpdate} = "<filename>";
$HMConfig::culHmChanSets{"HB-UNI-Sen-PRESS201"} = {};
$HMConfig::culHmChanSets{"HB-UNI-Sen-PRESS202"} = {};
$HMConfig::culHmRegChan {"HB-UNI-Sen-PRESS2"}   = { pairCentral=>1, sendIntervalPress=>1 };
$HMConfig::culHmRegChan {"HB-UNI-Sen-PRESS201"} = { sensorTypePress=>1 };
$HMConfig::culHmRegChan {"HB-UNI-Sen-PRESS202"} = { sensorTypePress=>1 };

Titel: Antw:AskSin++ Library
Beitrag von: rih am 12 Juni 2019, 22:24:46
Sorry, dass ich parallel im Homematic-Forum diesselbe Frage gestellt habe.
Habe nun Deine Version versucht, geht leider auch nicht (kein Wert im 2. Kanal). Ich denke, es liegt wie schon im Homematic-Forum geschrieben, an der späteren Auswertung der Daten in dem else-Zweig:

elsif( $model eq "HB-UNI-Sen-PRESS" ) {
      my $chnHash = $modules{CUL_HM}{defptr}{$src."01"};
      Log3 $chnHash->{NAME}, 4, $model.": ".$values;
      # extract 2 byte value
      my @unpacked = map{hex($_)} unpack("A2A4",$values);
      push @evtEt,[$chnHash,1,"pressure:".$unpacked[1]/100];
      push @evtEt,[$chnHash,1,"state:".$unpacked[1]/100];
    }


Bitte gib mir genauere Infos, was ich anpassen muss.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Juni 2019, 22:27:44
Wir bleiben hier.
Nochmal die Antwort.

Ach - die Werte für die beiden Kanäle kommen ja auch noch in einer Nachricht. Hm - geht sicherlich auch irgendwie. Nicht weiter getested

elsif( $model eq "HB-UNI-Sen-PRESS" ) {
      my $chnHash = $modules{CUL_HM}{defptr}{$src."01"};
      Log3 $chnHash->{NAME}, 4, $model.": ".$values;
      # extract 2 byte value
      my @unpacked = map{hex($_)} unpack("A2A4A4",$values);
      push @evtEt,[$chnHash,1,"pressure:".$unpacked[1]/100];
      push @evtEt,[$chnHash,1,"state:".$unpacked[1]/100];
     
      $chnHash = $modules{CUL_HM}{defptr}{$src."02"};
      push @evtEt,[$chnHash,1,"pressure:".$unpacked[2]/100];
      push @evtEt,[$chnHash,1,"state:".$unpacked[2]/100];
    }

Habe ich eigentlich erwähnt, dass Perl ein sch..... Sprache ist. Das versteht doch kein Mensch mehr nach 5 Minuten.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 12 Juni 2019, 22:35:32
Arg - ich glaube es gibt doch einzelne Nachrichten. Hm - probier mal


elsif( $model eq "HB-UNI-Sen-PRESS" ) {
      # extract 2 byte value
      my @unpacked = map{hex($_)} unpack("A2A4",$values);
      my $chnHash = $modules{CUL_HM}{defptr}{$src."0".$unpacked[0]};
      Log3 $chnHash->{NAME}, 4, $model.": ".$values;
      push @evtEt,[$chnHash,1,"pressure:".$unpacked[1]/100];
      push @evtEt,[$chnHash,1,"state:".$unpacked[1]/100];
    }
Titel: Antw:AskSin++ Library
Beitrag von: rih am 12 Juni 2019, 23:06:04
Ich danke Dir! Deine letzte Version funktioniert einwandfrei :)
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 16 Juni 2019, 14:03:54
Hi,

ich habe so langsam den Überblick etwas verloren über die ganzen Devices. Ich wollte mein Badradio gegen ein DAB+ Radio tauschen und hab da eins gekauft was sich Viola nennt. Ist ganz gut. Ich habe im Türblech ein Mikrotaster der das alte Radio immer aktiviert hat. Die neuen haben natürlich keine echten Schalter mehr nur noch Taster und da muss ich ein wenig basteln. OK ein kleiner AtTiny um den Power Button zu bedienen und über das Licht des Display abzufragen ob der Zustand an und aus ist ist schnell gebaut aber mir kam die Idee vielleicht ein HM Modul zu nehmen um das ganze etwas flexibler zu gestalten. Die DAB+ Radios brauchen eh leider bis zu 8 Sekunden um Musik zu spielen. Da kommt eine extra Verzögerung wegen HM nicht weiter zum Tragen.

Jetzt frage ich mich, gibt es ein Modul was IO Ausgänge hat die man nur mit einem kurzen Impuls schalten kann und wenigstens noch 1 Eingang den ich als Rückkanal nehmen kann um zu schauen ob das Radio jetzt an oder aus ist? Was könnte ich denn da am besten nehmen ohne zwei HM Module zu benutzen?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 16 Juni 2019, 14:06:40
Zitat von: ext23 am 16 Juni 2019, 14:03:54
Hi,

ich habe so langsam den Überblick etwas verloren über die ganzen Devices. Ich wollte mein Badradio gegen ein DAB+ Radio tauschen und hab da eins gekauft was sich Viola nennt. Ist ganz gut. Ich habe im Türblech ein Mikrotaster der das alte Radio immer aktiviert hat. Die neuen haben natürlich keine echten Schalter mehr nur noch Taster und da muss ich ein wenig basteln. OK ein kleiner AtTiny um den Power Button zu bedienen und über das Licht des Display abzufragen ob der Zustand an und aus ist ist schnell gebaut aber mir kam die Idee vielleicht ein HM Modul zu nehmen um das ganze etwas flexibler zu gestalten. Die DAB+ Radios brauchen eh leider bis zu 8 Sekunden um Musik zu spielen. Da kommt eine extra Verzögerung wegen HM nicht weiter zum Tragen.

Jetzt frage ich mich, gibt es ein Modul was IO Ausgänge hat die man nur mit einem kurzen Impuls schalten kann und wenigstens noch 1 Eingang den ich als Rückkanal nehmen kann um zu schauen ob das Radio jetzt an oder aus ist? Was könnte ich denn da am besten nehmen ohne zwei HM Module zu benutzen?

/Daniel

Arduino Pro mini + Funkmodul + Adapter Platine = fertig
Gesamtkosten < 10€

Oder soll es was fertiges zum kaufen sein?
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 16 Juni 2019, 18:13:09
Na an der HW soll es nicht scheitern, da nehme ich immer panstamps, da habe ich noch so viele. Mehr am Device, also am logischen Device ohne da jetzt was neues zu bauen wo ich erst noch irgend welche CCU/FHEM Module für HM zu bauen. Ich dachte ich könnte da irgend was nehmen und vergewaltigen was mein Zweck erfüllen würde.

Aber vielleicht denke ich da auch gerade zu kompliziert. Ich brauche ja eigentlich nur ein Device was ein ON/OFF Kanal hat und 5 andere Tasterausgänge. Die Logik von dem ON/OFF Kanal kann ich ja dann in dem Programm einbauen das ein Analog Eingang zum Beispiel genommen wird um anhand des Lichtes zu sehen ob das Radio an oder aus ist. Bei den anderen ist das ja nicht wichtig wie Lautstärke und so... mhh stimmt, da würde ja vielleicht das 8 Port IO Ding reichen von HM, müsst ich nur ein bissel anpassen dann mhhh ich muss nochmal drüber schlafen.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: LuBeDa am 22 Juni 2019, 21:52:16
Hallo Programmierer,

ich probiere gerade den Sketch von jerome HB-LC-RGBW-WM anzupassen. Ich möchte dazu den Kanalparameter Speed vom Kanal 3 (dem "Effekt") in meinem Sketch verwenden um z.B. ein schnelles oder langsames Blinken zu erzeugen.
Ich habe aber noch nicht rausgefunden wie ich im Sketch auf diesen Parameter zugreifen kann.

Habe versucht aus der channel.h schlau zu werden, habe aber dort nichts gefunden.

Kann mir jemand einen Tipp geben? Bzw. gibt es einen Sketch der Kanalparameter benutzt?

Ludger

Titel: Antw:AskSin++ Library
Beitrag von: wolwin am 14 Juli 2019, 21:31:29
Hallo papa,

ich bräuchte einmal Deine Unterstützung: habe von dem Projekt 'Umbau GARDENA Bewässerungsventil (1251-20) 9V auf HomeMatic'

https://homematic-forum.de/forum/viewtopic.php?f=76&t=49719&p=498500#p498500

vom Autor Gelegenheitsbastler eine bestückte Platine bekommen, die ich in FHEM eingebunden und gepairt habe. FHEM erkennt den Schalter korrekt als HM-LC-Sw1-Ba-PCB - nun bleibt nur noch: wie kann ich die beiden Channels / Schaltausgänge einzeln von FHEM aus ansprechen - die beiden Channels sind im INO-File von Dir so angegeben worden. Momentan funktioniert nur der erste Kanal - quasi als Default ... es wird nur der erste Channel geschaltet.

Danke schon einmal
Gruss
Wolfram
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 Juli 2019, 20:31:49
Auf der CCU benutzen sie die Eigenschaft, dass der Aktor die Anzahl der vorhandenen Kanäle übermittelt. FHEM kennt dieses Konzept nicht. Dadurch hat der HM-LC-Sw1-Ba-PCB grundsätzlich in FHEM nur einen Kanal. Du könntest mal versuchen den Aktor als HM-LC-Sw4-Ba-PCB (Device Model auf 0x00,0xAB setzen) anzumelden. Dann fehlen allerdings der 3. und 4. Kanal. Keine Ahnung, ob das nicht wieder andere Probleme macht.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 15 Juli 2019, 20:46:49
Ich habe mal das AskSin++ Addon angepasst dort gibt es jetzt auch ein paar mehr Homebrew-Geräte.

https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM
Titel: Antw:AskSin++ Library
Beitrag von: wolwin am 16 Juli 2019, 21:32:55
Zitat von: papa am 15 Juli 2019, 20:31:49
Auf der CCU benutzen sie die Eigenschaft, dass der Aktor die Anzahl der vorhandenen Kanäle übermittelt. FHEM kennt dieses Konzept nicht. Dadurch hat der HM-LC-Sw1-Ba-PCB grundsätzlich in FHEM nur einen Kanal. Du könntest mal versuchen den Aktor als HM-LC-Sw4-Ba-PCB (Device Model auf 0x00,0xAB setzen) anzumelden. Dann fehlen allerdings der 3. und 4. Kanal. Keine Ahnung, ob das nicht wieder andere Probleme macht.

Danke erst einmal für diese Info zu den fehlenden Kanälen in FHEM - werde bei Gelegenheit mal das Device Model ändern ...
Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 28 Juli 2019, 17:51:34
Hallo,

ich bräuchte mal eure Hilfe.
Ich habe den HM-LC-SW4-SM nachgebaut und HM_SENSOR_RELAY gesetzt, um lokale Buttons zu nutzen.
Das Schalten über FHEM funktioniert soweit, aber wenn ich den Button1 am Aktor drücke, passiert nichts.
Im seriellen Log sehe ich aber:

debounce
pressed
released
-> 0B 13 02 40 ABC001 ABC001 01 0A  - 34021


Sieht für mich so aus, als würde der Aktor ABC001 sich selbst eine Nachricht senden ???

Wie sollte das denn eigentlich aussehen?
Schaltet der Aktor den Kanal und sendet den Zustand an die Zentrale?
Oder wird nur der gewünschte Zustand an die Zentrale geschickt und diese gibt dann das Kommando zum Schalten? ..macht eigentlich keinen Sinn....

Danke und Gruß
Micky




Titel: Antw:AskSin++ Library
Beitrag von: micky0867 am 28 Juli 2019, 18:45:43
Fehler gefunden, sitzt vor der Tastatur.
Der Aktor war nicht richtig gepaired!

Micky
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 18 August 2019, 13:25:20
Guten Morgen,

ich habe eine Verständnisfrage.

Ich habe den HM-WDS40-TH-I-DHT22 nachgebaut.

Wenn ich den Sketch hochladen möchte, bekomme ich eine Fehlermeldung.
Arduino: 1.8.9 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328P (3.3V, 8 MHz)"

Sketch wird kompiliert...
HM-WDS40-TH-I-DHT22:125:79: error: 'as::Channel<Hal, as::List1, as::EmptyList, as::List4, 6, as::List0>::DeviceType {aka class as::Device<Hal, as::List0>}' has no member named 'broadcastEvent'

       if (msgcnt % 20 == 1) device().sendPeerEvent(msg, *this); else device().broadcastEvent(msg, *this);

                                                                               ^

Bibliothek EnableInterrupt-master in Version 1.0.0 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\EnableInterrupt-master  wird verwendet
Bibliothek AskSinPP-master in Version 4.1.0 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\AskSinPP-master  wird verwendet
Bibliothek Low-Power-master in Version 1.6 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\Low-Power-master  wird verwendet
Bibliothek DHT-sensor-library-master in Version 1.3.7 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\DHT-sensor-library-master  wird verwendet
Bibliothek Adafruit_Sensor-master in Version 1.0.3 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\Adafruit_Sensor-master  wird verwendet
exit status 1
'as::Channel<Hal, as::List1, as::EmptyList, as::List4, 6, as::List0>::DeviceType {aka class as::Device<Hal, as::List0>}' has no member named 'broadcastEvent'


Dieses ist der Eintrag im Sketch:
msg.init(msgcnt, temp+OFFSETtemp, humidity+OFFSEThumi, device().battery().low());
      if (msgcnt % 20 == 1) device().sendPeerEvent(msg, *this); else device().broadcastEvent(msg, *this);
    }

Wo wird normalerweise der broadcastEvent erzeugt bzw angelegt?

Danke
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 18 August 2019, 13:28:02
Ist im aktuellen master drin.
https://github.com/pa-pa/AskSinPP/blob/6796f35eea71e8ed0baf826375d3a554b4a25992/Device.h#L539
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 18 August 2019, 14:04:32
Zitat von: jp112sdl am 18 August 2019, 13:28:02
Ist im aktuellen master drin.
https://github.com/pa-pa/AskSinPP/blob/6796f35eea71e8ed0baf826375d3a554b4a25992/Device.h#L539

Hallo,

danke das war es.

Was bewirkt diese Funktion?
Ist es richtig, dass bei jeder Temp / Luftfeuchtigkeitsübertragung auch der Batteriestatus übertragen wird?
Wäre es nicht sparsamer, wenn der Batteriestatus nur alle paar Stunden übertragen wird?

Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 18 August 2019, 15:07:02
Zitat von: Beetle2003 am 18 August 2019, 14:04:32
Was bewirkt diese Funktion?
Dass an die Broadcastadresse 000000 gesendet wird, was dem Standardverhalten eines HM Sensors entspricht.

Zitat von: Beetle2003 am 18 August 2019, 14:04:32
Ist es richtig, dass bei jeder Temp / Luftfeuchtigkeitsübertragung auch der Batteriestatus übertragen wird?
Ja

Zitat von: Beetle2003 am 18 August 2019, 14:04:32
Wäre es nicht sparsamer, wenn der Batteriestatus nur alle paar Stunden übertragen wird?
Nein. LowBat ist nur ein Bit im Temperatur-Byte, das gedreht wird.

Was sollte man sparen können?

Btw: Meine ersten gebauten Sensoren mit SHT10, freiluftverdrahtet am Pro Mini, laufen seit 2017 bereits immer noch mit den ersten Batterien.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 18 August 2019, 22:19:49
Zitat von: jp112sdl am 18 August 2019, 15:07:02
Dass an die Broadcastadresse 000000 gesendet wird, was dem Standardverhalten eines HM Sensors entspricht.
Ja
Nein. LowBat ist nur ein Bit im Temperatur-Byte, das gedreht wird.

Was sollte man sparen können?

Btw: Meine ersten gebauten Sensoren mit SHT10, freiluftverdrahtet am Pro Mini, laufen seit 2017 bereits immer noch mit den ersten Batterien.

Hallo,

danke für die Erklärung.

Ich dachte, dass wenn nicht jedes Mal der Batteriestatus mit übertragen wird, die Batterien länger halten. Das g´hast Du mit deiner Aussage wiederlegt :-).
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 03 September 2019, 16:32:59
Hallo,

kann mir bitte jemand helfen die Batterie Messung in den HB-GEN-SENS Sketch im Anhang zu bauen, ich bekomme es irgendwie nicht hin. Ich möchte die Spannung von einem Spannungsteiler (7,4V auf 3,3V) an einem Pin X mit dem Teilungsverhältnis Y messen und übertragen. Ich müsste also den BatterySensorExt benutzen richtig? Aber ich bekomme das irgendwie nicht so ganz zum Laufen was da jetzt an welche Stelle muss.

/Daniel

Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 September 2019, 21:04:31
Im Master oder im V4 ? Welche Werte hat der Spannungsteiler ? Wie ist er angeschlossen ? So wie hier https://github.com/pa-pa/HMSensor/blob/master/HMSensor-StepUp/files/HMSensor-StepUp.pdf ?
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 03 September 2019, 21:32:15
Ich habe glaube noch die alte V2 oder was das ist. Würde dann aber die neuste nehmen, also V4 wenn es OK ist (Und nicht 2000 neue Kompiler Fehler kommen ;-) )

Spannungsteiler ist ganz normal, GND gegen VCC der Akkus und Mittelabgriff geht an den Eingang X (Mit egal welcher, kann ich ja einstellen dann). 100 / 80 wollte ich nehmen so dass 7,4V reichlich 3,3V entspricht. Ich brauche also kein "enable". Bei 180kOhm fließt da kaum was. Aber ich kann es auch gerne so machen wie in deinem Beispiel, das ist mir im Prinzip egal. Wenn das häufig so genutzt wird mache ich das auch so. Also elektrisch bin ich da offen für alles, ich bin nur irgendwie zu blöde das Softwareseitig einzubauen weil ich diesen ganzen Kram mit dem Klassen etc. nicht verstehe und mein Gefrickel hat bis jetzt leider nicht zum Erfolg geführt, nichtmal mit dem internen VCC zum test.

Danke.

Update:
Bibliothek AskSinPP in Version 4.0.3 (lässt sich kompilieren, also nehme ich die.)

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 September 2019, 22:10:50
Also V4. Probier mal (nicht weiter getestet)


#define SENSPIN X
#define ACTIVATIONPIN 0 // disable
#define AVRVCC 3300 // AVR VCC is 3.3V
typedef BatterySensorUni<SENSPIN,ACTIVATIONPIN,AVRVCC> ExtBat;
typedef AskSin<StatusLed<9>,ExtBat,Radio<RadioSPI,2> > Hal;


und dann an das Ende von setup()


hal.battery.init(seconds2ticks(60UL*60),sysclock,22);  // 180/80*10


Sollte auch mit V2 gehen.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 04 September 2019, 13:05:23
Danke,

muss ich irgendwo noch für sorgen, dass der Wert auch übermittelt wird? Ich hab das attr jetzt auf:
   
valuesformat 4:Kaltwasser:2 4:Warmwasser:2 1:batVoltage:10

ob die 10 nun passt oder nicht, aber zumindest sollte ich damit doch ein Wert bekommen oder?

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 September 2019, 13:23:16
Den Wert musst Du natürlich auch mitschicken.


  virtual void trigger (AlarmClock& clock) {
    ValuesMsg& msg = device().message().values();
    msg.init(device().nextcount(),number());
    msg.add(count1);
    msg.add(count2);
    msg.add(device().battery().current());
    device().send(msg, device().getMasterID());

    set(seconds2ticks(3*60));
    clock.add(*this);
  }
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 04 September 2019, 18:40:16
Ja super, das habe ich natürlich vergessen. Danke, jetzt passt es.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: Gernott am 09 September 2019, 20:24:49
Ich habe einen HM-SEC-MDIR aus den Beispielen nachgebaut. Zur Erweiterung des Erfassungsbereiches würde ich gern einen zweiten PIR-Sensor dazubauen. Was wäre denn der einfachste Weg für eine Parallelschaltung?

Grüße
G.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 September 2019, 21:40:11
Du könntest einen 2. Pin versuchen. Dazu musst Du (wahrscheinlich) nur eine Zeile im init() ändern und eine hinzufügen.
Aus
motionISR(sdev,1,PIR_PIN);
wird
motionChannelISR(sdev.channel(1),PIR_PIN);
motionChannelISR(sdev.channel(1),PIR_PIN2);


Das sollte so wahrscheinlich schon funktionieren. Must Du mal probieren.
Hardwarelösung wäre ein Oder-Gatter vor den Pin, um mehrere PIRs zu verwenden.
Titel: Antw:AskSin++ Library
Beitrag von: Gernott am 11 September 2019, 21:52:58
Zitat von: papa am 09 September 2019, 21:40:11
Du könntest einen 2. Pin versuchen. Dazu musst Du (wahrscheinlich) nur eine Zeile im init() ändern und eine hinzufügen.
Aus
motionISR(sdev,1,PIR_PIN);
wird
motionChannelISR(sdev.channel(1),PIR_PIN);
motionChannelISR(sdev.channel(1),PIR_PIN2);


Das sollte so wahrscheinlich schon funktionieren. Must Du mal probieren.
Das Teil hängt schon so im Keller und funktioniert prächtig. Vielen Dank!
Titel: Antw:AskSin++ Library
Beitrag von: wolwin am 18 September 2019, 12:33:33
Zitat von: papa am 15 Juli 2019, 20:31:49
Auf der CCU benutzen sie die Eigenschaft, dass der Aktor die Anzahl der vorhandenen Kanäle übermittelt. FHEM kennt dieses Konzept nicht. Dadurch hat der HM-LC-Sw1-Ba-PCB grundsätzlich in FHEM nur einen Kanal. Du könntest mal versuchen den Aktor als HM-LC-Sw4-Ba-PCB (Device Model auf 0x00,0xAB setzen) anzumelden. Dann fehlen allerdings der 3. und 4. Kanal. Keine Ahnung, ob das nicht wieder andere Probleme macht.

Projekt 'Umbau GARDENA Bewässerungsventil (1251-20) 9V auf HomeMatic'

... ist schon etwas her ... aber es funktioniert so: die Änderung erfolgt über das setzen des Attributes "modelForce" auf den Wert "HM-LC-SW4-BA-PCB" in der FHEM Oberfläche - danach können die beiden Kanäle geschaltet werden (Kanal 3 und 4 einfach ignorieren).
Titel: Antw:AskSin++ Library
Beitrag von: rih am 20 September 2019, 10:01:16
ZitatBist Du Dir denn sicher, dass FHEM auch wirklich korrekt mit einem originalen Repeater funktioniert? Das sollte man vielleicht erst mal rauskriegen. Das ist hier aber das falsche Ort.

Hallo papa,
ich nehme Bezug zu Deiner Antwort bzw. Frage im Homematic-Forum. Die Einrichtung des leider nicht mehr käuflichen Homematic-Repeaters in FHEM wird in einem eigenen kleinen Wiki beschrieben: https://wiki.fhem.de/wiki/HM-Sys-sRP-Pl_Funk-Zwischenstecker_Repeater (https://wiki.fhem.de/wiki/HM-Sys-sRP-Pl_Funk-Zwischenstecker_Repeater)
Von daher gehe ich davon aus, dass der originale Repeater in Verbindung mit FHEM funktioniert hat.

Es wäre schön, wenn Du Dich der Sache annehmen könntest. Ein funktionierender Nachbau-Repeater ist bestimmt auch noch für andere interessant.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 September 2019, 10:49:50
Tut mir Leid - ich habe nicht mal Zeit für meine privaten Projekte. Kann mich wirklich nicht darum kümmern.
Ich gebe gerne Tips und schau vielleicht auch mal kurz in den AskSin++ Code. Aber für mehr reicht es nicht.

Du sagst ja selber - "funktioniert hat". FHEM ändert sich ständig. Wenn da nicht auch ein aktiver Nutzer ist, das so ein Teil am laufen hat, kriegt hier niemand mit, wenn etwas nicht mehr funktioniert. Da Jeromes Code mit der CCU geht, sehe ich das Problem erst mal bei FHEM.
Titel: Antw:AskSin++ Library
Beitrag von: rih am 20 September 2019, 11:13:06
Ok, schade. Dann werde ich wohl einen anderen Weg gehen (2. IO-Device). Ist wahrscheinlich auch die bessere Lösung.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 September 2019, 11:23:02
Ein 2. IO und ne VCCU sind in FHEM auf jeden Fall die bessere Lösung.
Titel: Antw:AskSin++ Library
Beitrag von: CQuadrat am 20 September 2019, 11:50:14
Zitat von: papa am 20 September 2019, 11:23:02
Ein 2. IO und ne VCCU sind in FHEM auf jeden Fall die bessere Lösung.
Diese Variante ist leider nur möglich, wenn am Ort der vCCU-Installation auch Netzzugang besteht.
Gerade im Garten ist der Einsatz eines HM-Repeaters mit 868 MHz oft die einzige Möglichkeit (Stromversorgung vorausgesetzt) die HM-Reichweite bis in den hintersten Winkel zu gewährleisten.
Klar man könnte mit WLAN mit Außenantenne, Richtfunk, PowerLAN etc. arbeiten, dann wären aber wieder zusätzliche Geräte beteiligt.
Titel: Antw:AskSin++ Library
Beitrag von: rih am 20 September 2019, 19:04:48
@cquadrat: genauso ist es. Beschreibt genau meine Situation bzw. Problem, welches ich mit dem Nachbau-Repeater lösen wollte.

Neuer Plan:
Ich habe im Garten einen Raspberry mit Motioneye/Kamera per Wlan angebunden. Ist zwar eine relativ schlechte Verbindung, aber vermutlich besser als die Homematic-Verbindung (rssi <90). Dem RPi werde ich nun ein HM-MOD-RPI-PCB als 2. IO-Device  aufstecken und remote mit Socat meiner VCCU bekannt machen. Hoffe, das wird klappen.

Parallel suche ich nach einem gebrauchten Repeater, vielleicht hat jemand einen übrig.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 September 2019, 15:39:59
Also der Repeater-Sketch funktioniert grundsätzlich auch mit FHEM. Allerdings scheint es einen Fehler in FHEM zu geben, der die Readings nicht korrekt mit den Adressen aus dem Repeater füllt. Ich habe da kurz draufgesehen und verstehe den Code nicht. Da kann wahrscheinlich nur Martin helfen.
Titel: Antw:AskSin++ Library
Beitrag von: rih am 21 September 2019, 22:43:37
Das habe ich auch festgestellt, dass die Adressen nicht korrekt in die Readings geschrieben werden. Welches FHEM-Modul ist denn dafür zuständig?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 September 2019, 11:13:52
10_CUL_HM
Titel: Antw:AskSin++ Library
Beitrag von: sn2k am 01 Oktober 2019, 12:58:39
Wie ist es möglich im Arduino Sketch "HM-SEC-SCO" die Statusänderungen open bez. close direkt per Code zu senden?
Danke
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Oktober 2019, 14:18:40
Siehe hier https://github.com/pa-pa/AskSinPP/blob/8e235f54c6a31c9485be6e60632d58274ff199ba/ThreeState.h#L29
Titel: Antw:AskSin++ Library
Beitrag von: sn2k am 01 Oktober 2019, 20:38:12
Hallo papa

Kannst du mir einwenig mehr helfen, wie kann ich ohne in die Libary die Werte senden?

void Send_Open() {
      uint8_t count, state;
      state = 100;
      SensorEventMsg& msg = (sdev.SensorEventMsg&)sdev.channel.device().message();
      //sdev.msg.init(dev.channel.device().nextcount(),sdev.channel.number(),count++,state,sdev.channel.device().battery().low());
      sdev.channel.device().sendPeerEvent(msg,sdev.channel);
}
Geht leider nicht so einfach ;(

Vielen Dank
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 01 Oktober 2019, 22:04:49
Innerhalb der Device Klasse musst du zunächst festlegen, auf welchem Kanal du deine Message senden möchtest.
Ungetestet.

class SCOType : public ThreeStateDevice<Hal,ChannelType,1,SCOList0, CYCLETIME> {
private:
  uint8_t count, state;
public:
  typedef ThreeStateDevice<Hal,ChannelType,1,SCOList0, CYCLETIME> TSDevice;
  SCOType(const DeviceInfo& info,uint16_t addr) : TSDevice(info,addr), count(0), state(255) {}
  virtual ~SCOType () {}

  void Send_Open_ch1() {
    ChannelType& c1 = this->channel(1);
    SensorEventMsg& msg = (SensorEventMsg&)c1.device().message();
    msg.init(c1.device().nextcount(),c1.number(),count++,state,c1.device().battery().low());
    c1.device().sendPeerEvent(msg,c1);
  }
...
Titel: Antw:AskSin++ Library
Beitrag von: sn2k am 01 Oktober 2019, 23:13:36
Jetzt hab's ich es verstanden, vielen Dank jp112sdl

Funktioniert:



class SCOType : public ThreeStateDevice<Hal,ChannelType,1,SCOList0, CYCLETIME> {
private:
  uint8_t count, state;
public:
  typedef ThreeStateDevice<Hal,ChannelType,1,SCOList0, CYCLETIME> TSDevice;
  SCOType(const DeviceInfo& info,uint16_t addr) : TSDevice(info,addr), count(0), state(255) {}
  virtual ~SCOType () {}

void Send_State_ch1(bool bstate) {
    if(bstate == 1){state=200;}else{state=0;}
    ChannelType& c1 = this->channel(1);
    SensorEventMsg& msg = (SensorEventMsg&)c1.device().message();
    msg.init(c1.device().nextcount(),c1.number(),count++,state,c1.device().battery().low());
    c1.device().sendPeerEvent(msg,c1);
  }
...


Mit Send_State_ch1(0 oder 1) kann man nun direkt Open oder Closed senden, perfekt.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 Oktober 2019, 20:57:37
Ich versuch mich gerade an OTA.

Leider haperts irgendwie beim Bootloader.
Ich habe den Bootloader mit der makeota.html und mit cygwin und dem makeota.sh erstellt.

Bei der html Datei kommt ne 98,4 kb große Datei raus bei der .sh ist die Datei 11 kb groß.

Das schreiben des Bootloaders funktioniert mit beiden Dateien.
Allerdings scheint der Bootloader niht zu laufen.
Wenn ich den Arduino Pro Mini dann an einen FTDI Adapter aber ich bekomme überhaupt keine Ausgabe.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 Oktober 2019, 09:59:51
Welche Hardware hast Du ? Welche Einstellungen hast Du im makeota.html verwendet ?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 04 Oktober 2019, 10:19:28
Hab nen Pro Mini 3.3V.
In der Makeota.html hab ich den Typ für den RGB Stripe Sketch von Jerome eingetragen.
Seriennummer und ID wurden zufällig erstellt.
Als Datei habe ich die hex des Bootloaders für ATmega328P genommen
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 Oktober 2019, 20:39:39
Du brauchts für den reinen Bootloader gar keine Datei angeben. Optional kann das Anwendungs-Hex - also die LED Stripe Firmware - angegeben werden. Dann ist das Gerät sofort lauffähig.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 04 Oktober 2019, 20:58:42
Hatte ich auch irgendwo gelesen.
Allerdings steht in der Anleitung bei dir im Repo
ZitatThe specific boot loader can created by using the makeota.html page. Load the "Bootloader-OTA-atmega328.hex" into the web browser and fill all fields. After pressing the "Create" button the bootloader can be downloaded to the loacl disk. The complete page runs inside your web browser. There is no internet access needed.

Das makeota.sh Script hat den Bootloader mit den Modifizierten Parametern ausgespuckt.
Hab das auch nochmal per diff mit dem originalen Bootloader verglichen.

Werde jetzt nochmal die komplette Firmware reinladen und flashen.
Da sollte ja auf jedenfall ne Ausgabe kommen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 Oktober 2019, 21:02:00
Hm - muss ich wohl mal anpassen :-( Doku ist echt lästig.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 04 Oktober 2019, 22:21:04
Also irgendwie will das nicht ...

Hier mal beide Firmwares. Vielleicht könntest du die mit dem Bootloader ja mal bei dir testen ob es da tut.
Muss eigentlich nen Funkmodul dran hängen damit der Bootloader weitermacht und die eigentliche Firmware startet?

Bei der Firmware ohne den Bootloader bekomme ich ne Ausgabe vom Sketch beim Start.
Beide Firmwares wurden mit den gleichen Befehlen übertragen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 Oktober 2019, 11:17:45
Ich denke ohne Funkmodul geht da nichts.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 05 Oktober 2019, 11:21:06
Auch mit Modul kommt keine Ausgabe.

Könntest du vielleicht mal die Firmware bei dir flashen und schauen ob bei dir was kommt?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 05 Oktober 2019, 12:14:24
Check mal die Fuses. Boot Size muss 2k sein. (High 0xD0)
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 05 Oktober 2019, 13:07:48
Die Fuses waren Ok.
Ich habs jetzt auch irgendwie hinbekommen.

Ich hatte das ganze einmal mit und einmal ohne Funkmodul probiert.
Am Anfang muss ich wohl irgendwas falsch gemacht haben, daher bin ich davon ausgegangen, dass man den Atmega nicht flashen kann, wenn das Funkmodul angeschlossen ist.
Dann hab ichs halt auf nem blanken Pro Mini probiert aber hier scheint ohne Funkmodul überhaupt keine Ausgabe zu kommen.
Habs dann in verschiedenen Konstellationen immer wieder probiert aber scheinbar immer wenn ich es beim Arduino mit Funkmodul probiert habe immer nen teil vom Programmer angeschlossen gelassen.
Das hat so wie es aussieht das booten verhindert.

Also kurz zusammen gefasst:
1. bei der makeota.html direkt die Firmware des Sketches angeben
2. Flashen mit Funkmodul funktioniert
3. Programmer komplett trennen
4. mehrere Sekunden auf die erste Ausgabe warten

Der Sketch wird nun auch direkt gestartet.

Ich werd trotzdem gleich mal das OTA Flashen testen, einmal über die CCU und einmal über das Tool.
Muss man dort die Firmwareversion oderso anpassen damit man es neu flashen kann über die CCU?
Also damit die CCU erkennt, dass es eine neue Firmware ist.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 05 Oktober 2019, 13:22:03
Ich hatte dein File mal testweise geflasht.
Da kam auch nix... bis ich dann gesehen hab, dass die Boot Size Fuse nicht korrekt war.
Anschließend ging es auf Anhieb.

Was die CCU betrifft, siehe hier ganz unten:
https://github.com/pa-pa/AskSinPP/tree/master/bootloader/avr
In der info Datei muss die FirmwareVersion größer sein, als die, mit der das Gerät angelernt wurde.
Und sie sollte oder muss der Version entsprechen, die du im Sketch kompiliert hast, sonst wird dir das Update immer wieder angeboten... (z.B. Sketch = 1.0; info = 1.1)
Andererseits musst du bei der Versionierung der Firmware auch schauen, ob die Geräte-XML in der CCU nicht fix versionsgebunden ist!
z.B. rf_bl_le_v2_3.xml

<device version="1" supports_aes="true">
<supported_types>
<type name="radio-controlled blind actuator 1-channel (surface-mount)" id="HM-LC-Bl1-SM" priority="2">
<parameter index="9.0" size="1.0" cond_op="LE" const_value="0x23"/>
<parameter index="10.0" size="2.0" const_value="0x0006"/>
</type>
...

Die geht nur für Firmware Version <= 2.3

Je nach Firmwareversion kann es (bzw. wird es) unterschiedliche Geräte-Parameter geben.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 05 Oktober 2019, 13:46:42
Habs jetzt mal an die CCU angelernt und dann mit dem Tool in den Bootloader geschickt.

Irgendwie scheint die Datei defekt zu sein.
Habs mit Cygwin unter Windows und der prepareforota.sh umgewandelt.
Ich wandel die Firmware jetzt nochmal mit prepota.sh unter Linux um. Dauert aber etwas ...

HomeMatic OTA flasher version 0.103-git

Reading firmware from HB-UNI-RGB-LED-CTRL.ino_201910051323.eq3...
Firmware with 224 blocks successfully read.
HM-MOD-UART firmware version: 1.4.1, used credits: 4%

HM-MOD-UART opened

Entering 10k-mode
Adding HMID
Sending device with hmid 353dbb to bootloader
Waiting for device with serial USV3261990
Device with serial USV3261990 (HMID: 353dbb) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0056/0224 /
Missing ACK!
Flashing 224 blocks: 0135/0224 /
Missing ACK!
Flashing 224 blocks: 0218/0224 /
Missing ACK!
Flashing 224 blocks: 0224/0224 -
Entering 10k-mode
Waiting for device to reboot
Device rebooted


AskSin OTA Bootloader V0.7.0

TX bootloader sequence
Wait for CB msg
Got CB msg
Switch to 100k mode
Receive firmware
Got CB msg
.......................................................pageSize and blockPos differ
...............................................................................blockLen differ pageSize
blockLen differ pageSize
blockLen differ pageSize
....................................................................................Retransmit, reflash!<\n>
.......Timeout
CRC OK
Start App
AskSin++ V4.0.2 (Oct  4 2019 21:29:13)<\n>
Address Space: 32 - 844
CC init1
CC Version: 14


EDIT: gleiches Problem mit der unter Linux erstellen eq3 Version
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 05 Oktober 2019, 13:52:00
Kann auch passieren, wenn anderen Geräte dazwischenfunken.
Nach einer gewissen Anzahl retransmits ist schluss.
Hat mich alles nicht so überzeugt. Hab dann auch aufgehört, mich weiter mit OTA zu befassen
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 05 Oktober 2019, 13:59:14
Obwohl, wenn ich mir es genau anschaue, dann sagt er ja am Ende CRC Ok.
Sollte also funktioniert haben ...

Ich muss nacher mal was am Sketch ändern, damit ich sehe dass die neue Version angekommen ist.

Ich hoffe mal das Funktioniert alles ...
Wenn ich meine Gartenleuchten wieder zusammengebaut habe, kommt man da nicht mehr so einfach dran, daher das OTA und Reset durch An/Aus Sequenz.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 06 Oktober 2019, 17:36:45
Flashen OTA funktioniert ohne Probleme.

Allerdings habe ich gerade nen komisches Problem.
Es funktionierte alles, nur wollte ich was bauen, damit ich die Reset-Blink-Anzeige nicht auf der Status LED habe, sondern auf der RGB LED.
Damit ich nicht alles umbauen muss im Code war der Plan auf den Pin 3 einen Interrupt zu legen und diesen mit Pin 4 der eigentlichen Status LED zu verbinden.
Im Interrupt wollte ich dann prüfen ob der Sketch gerade gestartet wurde und noch innerhalb der Resetzeit ist.
Falls ja, soll bei jedem triggern die RGB LED an/aus geschaltet werden.

Habe das ganze dann wieder OTA geflasht.
Aber nun scheint nichts mehr vom Gerät empfangen zu werden. Ich sehe wie was gesendet wird, aber es kommt kein ACK.
Habe darauf hin wieder die alte Firmware OTA geflasht. Dies hat auch funktioniert, also ist der CC1101 immernoch richtig verbunden.
Gebracht hat es aber nichts ...

Habs jetzt auch nochmal normal geflasht, hat aber auch nichts gebracht.


Gabs schonmal sonen Problem wo zwar die Initialisierung des Funkmoduls funktioniert usw. aber nichts empfangen wird?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 06 Oktober 2019, 17:41:22
Zitat von: Xent am 06 Oktober 2019, 17:36:45
Gabs schonmal sonen Problem wo zwar die Initialisierung des Funkmoduls funktioniert usw. aber nichts empfangen wird?
Ja. https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html#ermittlung-der-cc1101-frequenz
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 06 Oktober 2019, 18:03:20
Werd den Sketch mal drüber laufen lassen ...
Beim ersten mal hat das Anlernen sofort funktioniert und auch die Bedienung funktionierte ohne Probleme.

Könnte es sein, dass es mit dem ResetOnBoot zutun haben könnte.
Erst danach trat das Problem auf.

Als eingestellte Frequenz wird mit folgende ausgegeben:
Config Freq: 0x21FFFF

Vielleicht hat sich da ja was Adressenmäßig verschoben.
Hab leider gerade keine Ausgabe von nem anderen Arduino da zum Vergleichen.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 06 Oktober 2019, 19:10:14
Zitat von: Xent am 06 Oktober 2019, 18:03:20
Könnte es sein, dass es mit dem ResetOnBoot zutun haben könnte.
Erst danach trat das Problem auf.

Als eingestellte Frequenz wird mit folgende ausgegeben:
Config Freq: 0x21FFFF

Vielleicht hat sich da ja was Adressenmäßig verschoben.
Eigentlich nicht.
Die bei den Freq-Bytes werden in Config Byte 0 und 1 abgelegt.
Der Bootstate für den Reset in Byte 2
https://github.com/pa-pa/AskSinPP/blob/7efdd76da8ec6bfe734b5d42416b0d407a87a7cf/AskSinPP.h#L14

Wenn die ResetOnBoot-Routine das Gerät zurücksetzt, wird die selbe Methode aufgerufen, wie beim Lange-Config-Taster-Gedrückthalten.
https://github.com/pa-pa/AskSinPP/blob/8e235f54c6a31c9485be6e60632d58274ff199ba/ResetOnBoot.h#L61
Die Freq bleibt dabei eigentlich erhalten.

Getestet habe ich es jedoch nicht.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 06 Oktober 2019, 19:15:41
Habs mal fix durchgespielt.
Freq blieb auch nach ResetOnBoot erhalten.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 06 Oktober 2019, 19:33:56
Zitat von: Xent am 06 Oktober 2019, 17:36:45
Habs jetzt auch nochmal normal geflasht, hat aber auch nichts gebracht.

Gabs schonmal sonen Problem wo zwar die Initialisierung des Funkmoduls funktioniert usw. aber nichts empfangen wird?
Da ja der alte Code geht, hast Du bestimmt irgendwas bei den Interrupts verdreht und nun kriegt das Funkmodul nicht mehr mit, dass eine Nachricht reingekommen ist.
Ich habe mal eben schnell die ResetOnBoot-Klasse etwas geändert und eine virtuelle led() Methode eingeführt. Diese ist jetzt für die Signalisierung zuständig. Du kannst jetzt einfach eine neue Klasse ableiten und deine eigene On/Off Methode implementieren.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 06 Oktober 2019, 20:25:37
Also irgendwas muss da schiefgegangen sein bei der Freuqenz ...

Fand es ja schon komisch, dass es gerade 21FFFF war.
Nachdem ich den FrequenzSketch hab laufen lassen kam folgende Freuenz raus:
Config Freq: 0x21654A

Jetzt hab ich wieder den Sketch drauf der nicht lief und diesmal funktioniert alles.

Danke papa.
Werd ich mir morgen mal anschauen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 07 Oktober 2019, 09:47:33
Zitat von: Xent am 06 Oktober 2019, 20:25:37
Also irgendwas muss da schiefgegangen sein bei der Freuqenz ...

Fand es ja schon komisch, dass es gerade 21FFFF war.
Nachdem ich den FrequenzSketch hab laufen lassen kam folgende Freuenz raus:
Config Freq: 0x21654A

FF ist der Inhalt einer gelöschten bzw. noch nie benutzten EEPROM Zelle. Die 21 wird nicht mit gespeichert wenn ich mich richtig erinnere.
Sieht für mich so aus das mit 21FFFF der FrequenzSketch noch nie gelaufen ist oder die Frequenz irgendwie danach wieder aus dem EEPROM gelöscht wurde.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Oktober 2019, 10:52:33
Den Sketch hatte ich bisher noch nicht laufen lassen auf dem Arduino.

Also ich vermute ja, dass das irgendwie gelöscht wurde.
Hatte ja auch die vorherige Version des Firmware geflasht und es funktionierte immer noch nicht.
Zuerst lief ja alles.

Vielleicht sollte man noch ne Prüfung einbauen, ob der Wert plausibel ist und bei FFFF oder 0000 dann den Standard nimmt.
Wenn man noch etwas Platz im EEPROM hat könnte man ja auch noch ne Checksumme  drauf legen.

Vielleicht hing das ja auch mit dem OTA Flashen zusammen.

Ich werd bei meinen Lampen jedenfalls den Pin 8 nach GND brücken und im Sketch einen anderen Config-Pin definieren.
So kann ich zumindest immer OTA flashen wenn ich das Teil einschalte.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 Oktober 2019, 10:57:51
Zitat von: Xent am 07 Oktober 2019, 10:52:33
Vielleicht sollte man noch ne Prüfung einbauen, ob der Wert plausibel ist und bei FFFF oder 0000 dann den Standard nimmt.
Wenn man noch etwas Platz im EEPROM hat könnte man ja auch noch ne Checksumme  drauf legen.
Wird doch alles gemacht.
https://github.com/pa-pa/AskSinPP/blob/master/Storage.h
https://github.com/pa-pa/AskSinPP/blob/30b03a0bdc2f84dd5a1ca4ced4090c51011810df/AskSinPP.h#L175

Man müsste halt rausfinden, warum die StorageConfig valid war, bzw. wenn der Rest gestimmt hat, warum nur die FreqConfig-Bytes FF waren.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 07 Oktober 2019, 11:21:43
Zitat von: jp112sdl am 07 Oktober 2019, 10:57:51
Wird doch alles gemacht.
https://github.com/pa-pa/AskSinPP/blob/master/Storage.h
https://github.com/pa-pa/AskSinPP/blob/30b03a0bdc2f84dd5a1ca4ced4090c51011810df/AskSinPP.h#L175

Man müsste halt rausfinden, warum die StorageConfig valid war, bzw. wenn der Rest gestimmt hat, warum nur die FreqConfig-Bytes FF waren.

Moin Jerome, bin gerade nicht in den Details der StorageConfig drin, aber ist das nicht die allgemeine HM Config die bei longpress gelöscht wird?
Dann wäre doch da die Frequenz mit Absicht nicht innerhalb der chksum (da sie erhalten bleiben muss) und deine verlinkte Prüfung auf sc.valid() würde für die Frequenz nichts bringen?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Oktober 2019, 11:22:26
Ich werd nacher mal die alte Firmware flashen und schauen, ob dort auch schon die Frequenz ausgegeben wurde.
Falls nicht, dann wurden diese Bytes des EEPROMs ja noch nie beschrieben oder?

Wenn nun in beiden FF drin steht, dann wird ja beim berechnen der Checksumme zwei mal XOR mit FF gemacht und dadurch das erste XOR wieder rückgängig gemacht.
Dadurch passt dann die Checksumme wieder weil das Ergebnis raus kommt was auch ohne die beiden Bytes rausgekommen währe.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 Oktober 2019, 11:33:34
Zitat von: Tom Major am 07 Oktober 2019, 11:21:43
Moin Jerome, bin gerade nicht in den Details der StorageConfig drin, aber ist das nicht die allgemeine HM Config die bei longpress gelöscht wird?
Dann wäre doch da die Frequenz mit Absicht nicht innerhalb der chksum (da sie erhalten bleiben muss) und deine verlinkte Prüfung auf sc.valid() würde für die Frequenz nichts bringen?
Zitat von: Xent am 07 Oktober 2019, 11:22:26
Ich werd nacher mal die alte Firmware flashen und schauen, ob dort auch schon die Frequenz ausgegeben wurde.
Falls nicht, dann wurden diese Bytes des EEPROMs ja noch nie beschrieben oder?

Wenn nun in beiden FF drin steht, dann wird ja beim berechnen der Checksumme zwei mal XOR mit FF gemacht und dadurch das erste XOR wieder rückgängig gemacht.
Dadurch passt dann die Checksumme wieder weil das Ergebnis raus kommt was auch ohne die beiden Bytes rausgekommen währe.

Dann mal anders herangegangen:
Wenn ich einen Sketch flashe und den 328P das erste Mal in Betrieb nehme -> welcher EEPROM Bereich wird dann mit Init Storage beschrieben?
Oder anders: Wann werden denn die Config-Bytes 0x04-0x20, in dem auch die Freq liegt, mit 0 beschrieben?

Bei einem nagelneuen 328P sollten ja alle EEPROM Bytes 0xFF sein?
Die Freq wird nur geladen, wenn
if( f1 != 0 ) {...

Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 07 Oktober 2019, 11:42:00
Zitat von: jp112sdl am 07 Oktober 2019, 11:33:34

Bei einem nagelneuen 328P sollten ja alle EEPROM Bytes 0xFF sein?
Die Freq wird nur geladen, wenn
if( f1 != 0 ) {...

korrekt.
imho müsste mindestens noch f1,f2 != 0xff zur Prüfung dazu genommen werden - falls die Frequenz außerhalb der chksum liegt, das weiß ich nicht.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Oktober 2019, 12:13:00
Ich denke, dass auch wenn es in der Checksumme drin ist, grprüft werden sollte ob das erste Byte  != FF ist.
Wenn man als Frequenz 0x21FF00 nehmen würde, dann währe das schon weit oberhalb der 868 Mhz.


EDIT: noch was anderes.
Wie überschreibe ich jetzt die Methode der ResetOnBoot Klasse?
Irgendwie bekomme ich es nicht hin, dass er von der Klasse erbt ...

So versuch ichs gerade ...
template <class DEVTYPE>
class ResetOnBootCustom : public ResetOnBoot<DEVTYPE> {
  DEVTYPE& dev;

public:
 
  virtual void led(bool on) {
      on == true ? dev.led().ledOn() : dev.led().ledOff();
  }
}
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Oktober 2019, 13:20:48
Da hilft ein C++Buch/Kurs ;-)

template<class DEVTYPE>
class ResetOnBootCustom : public ResetOnBoot<DEVTYPE> {
public:
  ResetOnBootCustom (DEVTYPE& dev) : ResetOnBoot<DEVTYPE>(dev) {}
  virtual ~ResetOnBootCustom () {}
  virtual void led(bool on) {
       // do your own stuff here
   }
};
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Oktober 2019, 13:21:59
Zitat von: Xent am 07 Oktober 2019, 12:13:00
Ich denke, dass auch wenn es in der Checksumme drin ist, grprüft werden sollte ob das erste Byte  != FF ist.
Wenn man als Frequenz 0x21FF00 nehmen würde, dann währe das schon weit oberhalb der 868 Mhz.
Ja - 0 ist da sicherlich falsch. Da muss 0xff hin.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 Oktober 2019, 13:27:00
Zitat von: papa am 07 Oktober 2019, 13:21:59
Ja - 0 ist da sicherlich falsch. Da muss 0xff hin.
Mich wundert nur, dass es da noch keinen "Aufschrei" gab.
Denn eigentlich müssten doch seit Einführung der FreqConfig Bytes alle erst-programmierten 328P derzeit FFFF als Freq setzen, sofern der FreqTest nicht ausgeführt wurde?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Oktober 2019, 13:28:16
Danke, jetzt gehts.

Bin eigentlich mehr in C#, PHP und Javascript unterwegs.

Bisher habe ich die Klassen in C++ auch direkt vererbt ohne Template.
Daher haben mir meine bisherigen Erfahrungen und umgebaute Sketche nichts gebracht.

EDIT:
Bin ja froh, dass es scheinbar doch nen Bug ist und ich nicht einfach nur zu blöd war xD
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Oktober 2019, 13:44:18
Zitat von: jp112sdl am 07 Oktober 2019, 13:27:00
Mich wundert nur, dass es da noch keinen "Aufschrei" gab.
Denn eigentlich müssten doch seit Einführung der FreqConfig Bytes alle erst-programmierten 328P derzeit FFFF als Freq setzen, sofern der FreqTest nicht ausgeführt wurde?
Stimmt - aber vielleicht einfach Pech mit der 1 Byte Checksumme gehabt. Wenn der Chip schon mal in Benutzung war, kann da ja zufällig mal was Gültiges stehen. Auf jedem Fall sollte der Code bei einem neuen Chip funktionieren - da die Checksumme auf keinen Fall 0xFF ist.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Oktober 2019, 15:31:04
Werd ich nachher testen.
Hab gestern noch nen neuen Arduino gelötet aber noch nicht programmiert.

Wird die Frequenz denn nun zurückgesetzt wenn man einen Reset macht?
Ich hatte dann irgendwann einen gemacht mit dem ResetOnBoot aber die Frequenz war immer noch falsch.
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 07 Oktober 2019, 15:42:57
Zitat von: Xent am 07 Oktober 2019, 15:31:04
Werd ich nachher testen.
Hab gestern noch nen neuen Arduino gelötet aber noch nicht programmiert.

Wird die Frequenz denn nun zurückgesetzt wenn man einen Reset macht?
Ich hatte dann irgendwann einen gemacht mit dem ResetOnBoot aber die Frequenz war immer noch falsch.

Nein die Frequenz bleibt bestehen, auch noch einem Reset.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 Oktober 2019, 15:58:42
Schrieb ich ja gestern auch bereits
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 07 Oktober 2019, 16:29:24
da das Thema heute und hier Aufmerksamkeit hat, ich hätte mal folgende Frage an @papa um das für mein AskSinPP Wissen abzuspeichern:

- die 2 Frequenzbytes sind nicht nicht im allgemeinen AskSinPP Config space der bei longpress gelöscht wird, richtig?
- die 2 Frequenzbytes nehmen folglich nicht an der chksum des Config spaces teil?

oder adere Variante:

die 2 Frequenzbytes sind im AskSinPP Config space enthalten, nehmen an der chksum teil aber bei longpress werden diese ausnahmsweise nicht gelöscht?

Danke,
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 Oktober 2019, 19:57:17
Ich versuch mal wiederzugeben, wie ich es bisher verstanden habe.
Mit der Bitte um Korrektur von pa-pa.

Zutreffend ist am ehesten wohl
Zitat von: Tom Major am 07 Oktober 2019, 16:29:24
oder adere Variante:
die 2 Frequenzbytes sind im AskSinPP Config space enthalten, nehmen an der chksum teil aber bei longpress werden diese ausnahmsweise nicht gelöscht?

Die ersten 4 Byte (0...3) im EEPROM enthalten die 'magic'.
Die Freq liegt in Byte 4 und 5 (also die STORAGE_CFG_START + 0 und +1), und wird für die chksum mit herangezogen.
Beim Speichern der Frequenz wird die Neuberechnung der chksum durch sc.validate() vorgenommen: https://github.com/pa-pa/AskSinPP/blob/30b03a0bdc2f84dd5a1ca4ced4090c51011810df/examples/FreqTest/FreqTest.ino#L128

Ein longpress löscht nur die 'magic', also die ersten 4 Bytes, was dazu führt, dass beim nächsten Start ein "Init Storage" ausgeführt wird.
Der Space, der beim Booten seriell ausgegeben wird (32 - ...) wird gelöscht. Alles < 32 (0x20), die getConfigArea(), bleibt erhalten.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 07 Oktober 2019, 21:00:08
Danke für die Klarstellung Jerome, habe es verstanden glaub ich.
D.h. ein jungfräulicher EEPROM mit FF erzeugt beim ersten Start mittels "Init Storage" eine gültige chksum für den ganzen Bereich, darin enthalten ist auch die eigentlich noch ungültige Frequenz (21)FFFF.
Jetzt verstehe ich warum du nach dem Aufschrei gefragt hast  ;)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Oktober 2019, 21:36:58
Ein Bild sagt mehr als 1000 Worte.

Bei Adresse 0x00 befinden sich 2 Byte Magic & 2 Byte CRC16 Checksumme der Device-Struktur. Damit ist gemeint, die Register der unterschiedlichen Listen, die Anzahl der Channels & der Peers. Damit soll sichergestellt werden, dass wenn sich im Code etwas ändert, was Einfluß auf die Position der Daten im EEProm hat, die Daten neu initialisiert werden. Es wird dann der "Device Data" Bereich neu initialisiert und die Checksumme aktualisiert. Das passiert natürlich auch nach dem erstmaligen Flashen. Ein RESET löscht die Magic und damit wird alles neu aufgebaut.
Der Start der "Device Data" wird im Konstructor angegeben - default 0x20. Der Bereich zwischen dem Magic und den "Device Data" war anfangs ungenutzt. Als das Frequenz-Thema auf kam, wurde der Bereich in das "Config Area" gewandelt. Daten die hier liegen, werden bei der Initialisierung niemals angefasst. Das letzte Byte im "Config Area" ist eine einfache XOR-Checksumme, mit welcher herausgefunden wird, ob die Daten gültig sind. Diese muss expliziert nach dem Ändern der Daten neu geschrieben werden.

Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Oktober 2019, 21:58:38
Also ich hab gerade einen jungfräulichen Pro Mini programmiert und siehe da 0x21FFFF

AskSin OTA Bootloader V0.7.0

Start App
AskSin++ V4.1.1 (Oct  7 2019 21:51:00)<\n>
Address Space: 32 - 258
CC init1
CC Version: 14
- ready
Config Freq: 0x21FFFF
iVcc: 3332
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 Oktober 2019, 22:07:53
Habe mal mit

  for (int i = 0 ; i < EEPROM.length() ; i++) {
    EEPROM.write(i, 0xFF);
  }

mein EEPROM mit FF beschrieben.

Anschließend den HM-LC-Sw1-BA-PCB geflasht und es kommt

AskSin++ V4.1.1 (Oct  7 2019 22:05:41)
Address Space: 32 - 258
FFFFFFFF
Init Storage: CAFEA52E
CC init1
CC Version: 04
- ready
iVcc: 3372


Mit Standard Optibootloader.

Da kommt nix mit Config Freq: 0x21FFFF

Ob der OTA Bootloader da nicht doch irgendwo reinspielt!?



EDIT:
Beim 2. Start kommt jetzt bei mir auch  Config Freq: 0x21FFFF
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 07 Oktober 2019, 22:14:41
Auf welcher Frequenz arbeitet der CC1101 eigentlich standardmäßig?
Lohnt es sich den FrequenzSketch auch bei richtigen CC1101 anzuwenden?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 Oktober 2019, 22:20:41
Das CC1101 hat keine "Standardfrequenz".
Es arbeitet (sollte zumindest) auf der Frequenz, mit dem du es initialisierst.
Homematic arbeitet auf 868.3 MHz. Die default Freq Parameter sind diese hier:

      // 868.299866 MHz - if other values are found in EEPROM, these are overwritten later
      CC1101_FREQ2,     0x21,   //  0x1E
      CC1101_FREQ1,     0x65,   //  0xC4
      CC1101_FREQ0,     0x6A,   //  0xEC


Wenn du nun z.B. mithilfe eines SDR siehst, dass trotz eingestellter 868.3MHz die Funksignale bspw. auf 868.2 MHz gesendet werden, kannst du diese 100kHz Offset durch die angepassten FREQ Definitionen ausgleichen.

Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 07 Oktober 2019, 22:36:42
Zitat von: papa am 07 Oktober 2019, 13:21:59
Ja - 0 ist da sicherlich falsch. Da muss 0xff hin.
Nur auf 0xff oder lieber 0x00 && 0xff prüfen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 07 Oktober 2019, 22:43:29
Zitat von: jp112sdl am 07 Oktober 2019, 22:07:53
Beim 2. Start kommt jetzt bei mir auch  Config Freq: 0x21FFFF
Weil beim ersten Start der ResetOnBoot-Code die Checksumme schreibt. Damit sind dann auch die beiden Frequenzbyte aktiviert.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 08 Oktober 2019, 00:05:14
Zitat von: papa am 07 Oktober 2019, 21:36:58
Ein Bild sagt mehr als 1000 Worte.


Danke für die Erläuterungen. So langsam fügt sich das Bild zusammen.  :)

Vorschlag
a) die 21 mit schreiben durch den Test sketch und nur wenn die da ist die Freq. nehmen oder
b) range check beim Freq. lesen einführen, HM Freq +- 500kHz oder was auch immer
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 08 Oktober 2019, 06:45:11
500kHz sind schon mega viel.
Aber letztlich gehts ja nur um die Plausibilität.
Mein Vorschlag:
if (f1 >= 0x60 && f1 <= 0x6F)
oder kompakter?
if ((f1 >> 4) == 0b0110)

Ich mach mal einen PR zur Diskussion (oder zum Mergen^^)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Oktober 2019, 07:58:57
Naja kompakter ist das nicht. Ich habe mal den Compiler drauf geschickt:

Variante 1:
Program:   26576 bytes (81.1% Full)
Data:       1088 bytes (53.1% Full)


Variante2:
Program:   26588 bytes (81.1% Full)
Data:       1088 bytes (53.1% Full)


Also Variante 1 benötigt 12 Byte weniger Code und man kann es sogar noch besser verstehen :-)
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 08 Oktober 2019, 08:04:47
Das ja mal interessant... Ok, bau ich um auf Var.1
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 08 Oktober 2019, 12:13:53
Zitat von: jp112sdl am 08 Oktober 2019, 06:45:11
500kHz sind schon mega viel.
Aber letztlich gehts ja nur um die Plausibilität.
Mein Vorschlag:
if (f1 >= 0x60 && f1 <= 0x6F)
oder kompakter?
if ((f1 >> 4) == 0b0110)

Ich mach mal einen PR zur Diskussion (oder zum Mergen^^)

Die +-500kHz waren auch gestern nach Mitternacht nur schnell hingeschrieben  ;)
+-300 sind sicher besser und praktikabel.

Dein range 60..6F ist aber nicht mittig zur Centerfrequenz.
Besser wäre z.B. 62..69, das ergibt ca. 350kHz in beide Richtungen.

Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 08 Oktober 2019, 12:20:49
Zitat von: jp112sdl am 08 Oktober 2019, 06:45:11
Aber letztlich gehts ja nur um die Plausibilität.

Hmm
Zitat von: Tom Major am 08 Oktober 2019, 12:13:53
Besser wäre z.B. 62..69, das ergibt ca. 350kHz in beide Richtungen.
Am besten nen neuen PR machen.




Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 08 Oktober 2019, 12:34:58
Das stimmt, für den Plausibilität check reicht dein range allemal.
Wenn man es einmal anfasst hatte ich es halt nur so gemacht dass es auch noch Sinn macht wenn man mal 1 Jahr später draufschaut.  ;)
Denn für -500kHz +1MHz Asymmetrie gibt es ja keine Erklärung/Grund.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Oktober 2019, 14:53:43
Warum nicht ? Es wird hier der Fehler des Quarzes korrigiert. Der kann auch sehr weit daneben liegen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 08 Oktober 2019, 17:12:00
Zitat von: papa am 08 Oktober 2019, 14:53:43
Warum nicht ? Es wird hier der Fehler des Quarzes korrigiert. Der kann auch sehr weit daneben liegen.

Schon klar.
Ich meinte nur das es keinen Grund für die Asymmetrie gegenüber der center Frequenz gibt.
Titel: Antw:AskSin++ Library
Beitrag von: stan23 am 09 Oktober 2019, 09:22:41
Zitat von: Tom Major am 08 Oktober 2019, 12:13:53
Besser wäre z.B. 62..69, das ergibt ca. 350kHz in beide Richtungen.
Ich vermute mal dass es dann doch wieder mehr Programm Memory braucht.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 09 Oktober 2019, 17:16:28
Habe mal einen PR gemacht für einen Vorschlag:
"Bessere symmetrische Grenzen für den CONFIG_FREQ1 check um die default HM Frequenz herum"
868,3MHz -550kHz/+567kHz
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 09 Oktober 2019, 17:17:19
Zitat von: stan23 am 09 Oktober 2019, 09:22:41
Ich vermute mal dass es dann doch wieder mehr Programm Memory braucht.
nein, das ist mit dem aktuellen code Stand egal.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 Oktober 2019, 20:00:28
Zitat von: Tom Major am 09 Oktober 2019, 17:16:28
Habe mal einen PR gemacht für einen Vorschlag:
"Bessere symmetrische Grenzen für den CONFIG_FREQ1 check um die default HM Frequenz herum"
868,3MHz -550kHz/+567kHz
Warum wollen wir das unnötig weit einschränken ? Eigentlich reicht doch auch ein Test ungleich 0x00 && ungleich 0xFF.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 09 Oktober 2019, 23:18:04
Zitat von: papa am 09 Oktober 2019, 20:00:28
Warum wollen wir das unnötig weit einschränken ? Eigentlich reicht doch auch ein Test ungleich 0x00 && ungleich 0xFF.

Hallo papa,
streng genommen hättest du die Frage gestern stellen sollen als Jerome den PR für die Einschränkung auf 0x6x gemacht hat und du akzeptiert hast.
Ich wollte heute nur die Asymmetrie des ranges von Jeromes PR korrigieren (für die es imho keinen Grund gibt) und auch gleich bei der Gelegenheit den Range des Frequenz checks dokumentieren.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 Oktober 2019, 07:21:47
Ich habe ja auch gefragt und bisher keine Zeit gehabt, alles bis zum Ende durchzudenken :-)
Wir wissen nicht, wie weit die Funkmodule im Einzelfall abweichen. Wenn der Testsketch eine funktionierende Frequenz raus kriegt und speichert, sollte diese auch genutzt werden. Es muss nur sichergestellt werden, dass der uninitialisierte Zustand erkannt wird. Das hatte ich falsch mit 0x00 gemacht. Der EEProm ist aber per default auf 0xff.
Vielleicht müsste man auch beim ersten Schreiben den gesamten Bereich "formatieren" - also auf einen definierten Zustand bringen. So wie es jetzt ist, könnte durch eine vorherige Anwendung schon Daten im EEProm stehen und das Schreiben der RebootFlags würde dann auch die Frequenz aktivieren und die Firmeware würde mit einem völlig unsinnigen Wert starten.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 10 Oktober 2019, 12:26:01
Zitat von: papa am 10 Oktober 2019, 07:21:47
Ich habe ja auch gefragt und bisher keine Zeit gehabt, alles bis zum Ende durchzudenken :-)
Wir wissen nicht, wie weit die Funkmodule im Einzelfall abweichen. Wenn der Testsketch eine funktionierende Frequenz raus kriegt und speichert, sollte diese auch genutzt werden. Es muss nur sichergestellt werden, dass der uninitialisierte Zustand erkannt wird. Das hatte ich falsch mit 0x00 gemacht. Der EEProm ist aber per default auf 0xff.
Vielleicht müsste man auch beim ersten Schreiben den gesamten Bereich "formatieren" - also auf einen definierten Zustand bringen. So wie es jetzt ist, könnte durch eine vorherige Anwendung schon Daten im EEProm stehen und das Schreiben der RebootFlags würde dann auch die Frequenz aktivieren und die Firmeware würde mit einem völlig unsinnigen Wert starten.

ja, mein Gedanke war auch das durch vorherige Belegung ein Wert ungleich FF drinsteht der aber trotzdem keine gültige Frequenz ist. Deswegen habe ich einen sauberen symmetrischen check um die default HM Frequenz vorgeschlagen. Ich hatte bisher nie mehr als 100 kHz Abweichung, imho sollten +-500 alles abdecken.

Oder man macht für Config area auch eine crc16 genau so wie für device data area, wäre man dann safe?
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 November 2019, 16:01:27
Ich hab mich in letzter zeit etwas mit dem Thema OTA auseinander gesetzt und mir ist aufgefallen, dass sich der Bootloader selbst updaten könnte.

Ich hatte bei einem Aktor das Problem, dass beim OTA Flashen immer der CC1101 ausgestiegen ist und nichts mehr empfangen hat.
Ich hab darauf hin den Bootloader etwas angepasst und auch das Flash-Tool um eine Option zur Angabe der maximalen Versuche ergänzt.
Darauf hin konnte ich den Aktor immer wieder ohne Probleme flashen.

https://github.com/alexreinert/Asksin_OTA_Bootloader/pull/2
https://github.com/jp112sdl/hmcfgusb/pull/1

Jetzt habe ich schon eine RGB Gartenleuchte zusammengebaut, dort ist aber noch die alte Version des Bootloaders drauf.
Aus Bequemlichkeit und Interesse würde ich gerne dort auch den Bootloader aktualisieren ohne sie wieder auseinander zu nehmen.

Hat schonmal jemand soeine Firmware gebaut, wo auch der Bootloader aktualisiert wurde?

Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 November 2019, 19:33:32
Habe mich jetzt mal weiter eingearbeitet.

Also damit man den Bootloader OTA aktualisieren kann, muss man ihn an die die Stelle 0x0000 Flashen und ein Magicword an Adresse 0x6FFC schreiben.
Dann liest der Bootloader den Flash von 0x0000 und überschreibt den aktuellen Bootloader ab 0x7000 mit 30 Pages a 128 Bytes

Aber eigentlich dürfte er doch nur 29 pages schreiben, da in der obersten Page also 0x7F00 der Code fürs Bootloaderupdate drin steht.

Danach muss man wieder die gewünschte Firmware OTA Flashen.

Habe mich auch mal an dem Makefile versucht.
https://github.com/Xento/Asksin_OTA_Bootloader/commit/09650a063225b644cffaa3853f6b005c7ee10b26

https://pastebin.com/7EH7msJE

Damit sollte der Flash wie benötigt aussehen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 November 2019, 20:17:50
Wusste gar nicht, dass man den Bootloader selbst auch per OTA updaten kann.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 03 November 2019, 20:41:51
Klar sollte das gehen.

Der Einsprung ist hier
https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/faf129629ee1bb8ee9bd6c3dc27fd60d5100d818/bootloader.c#L373

Und geflasht wird hier.
Wobei ich der Meinung bin, dass nur 29 Pages geschrieben werden dürfen, da er sonst de letzte Page wo der Flashcode drin sitzt, also 0x7F00, überschreibt.
https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/faf129629ee1bb8ee9bd6c3dc27fd60d5100d818/bootloader.c#L651
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 03 November 2019, 20:55:41
Man darf dann bestimmt nicht die Lock Bit Fuse BLB1: SPM_DISABLE gesetzt haben
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 03 November 2019, 22:57:03
Zitat von: jp112sdl am 03 November 2019, 20:55:41
Man darf dann bestimmt nicht die Lock Bit Fuse BLB1: SPM_DISABLE gesetzt haben

Genau, das kam mir als erstes auch in den Sinn, ich setzte diese Fuse immer beim bootloader.

Außerdem muss der 'alte' bootloader dieses Feature bereits unterstützen.
Ein sauber programmierter bootloader ohne ein solches Feature schaut sich die Adressen/Pages an und flasht nur die die zur Application gehören.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 04 November 2019, 08:50:52
Der Bootloader schreibt ja nur die Pages die per OTA übertragen werden.
Nur beim Selbstupdate ist es anders, da dort die Routine sehr klein sein muss.

Wenn man per OTA den Bootloader aktuallisiern will, muss ja folgendes passieren:

1. neuen Bootloader per OTA flashen an die Adresse 0x0000 (wie eine normale Firmware)
2. an Adresse 0x6FFC muss ein Magciword geschrieben werden
3. bei Booten prüft der Bootloader, ob das Magicword an Adresse 0x6FFC steht.
4. wenn Magicword gefunden wurde, liest der Bootloader ab Adresse 0x0000 und schreibt 30 Pages ab Adresse 0x7000. Dadurch aktualisiert sich der Bootloader selbst

Bei 30 Pages wird aber auch die Page 0x7F00 überschrieben oder hab ich mich da verrechnet?

Zitat/**
* The updateBootloaderFromRWW function is placed in the topmost page and cannot be changed via OTA Update
* This must not be touched for OTA update otherwise you may brick the bootloader and need and ISP update
*/
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 08 November 2019, 21:17:05
Hmm ich bekomme es irgendwie nicht so recht hin eine Firmware zu bauen, die man per OTA flashen könnte.
Entweder passt beim Konvertieren ins eq3 Format was nicht oder aber das flash-ota meckert rum.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 09 November 2019, 07:43:51
Was machst Du denn genau ? Meine Glaskugel ist gerade kaputt.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 09 November 2019, 08:40:50
Sorry, war gestern etwas kurz angebunden ...

Habe mich am Makefile versucht um damit eine Firmware für das OTA Update des Bootloaders zu bauen.
Soweit wird auch alles gebaut und das Magicword landet auch an der richtigen Stelle im Flash.

Hier mal die letzten Zeilen der Firmware.
Wie man sieht kommt das Magicword an die Adresse 6FFC.
Was mich aber vewundert ist, die Zeile davor.
Da wird ja nur von 30 bis 34 hochgezählt ...
:100E90008CEB91E00E94EA0681E00E94EE050E9440
:100EA000CC030E94F203FB01DC0102C005900D920D
:100EB00041505040D8F70895FB01DC0102C0019079
:0E0EC0000D9241505040D8F70895F894FFCF9E
:100ECE003031323334353637383941424344454672
:026FFC0011473B
:00000001FF


Wenn ich die angehängte Hex-Datei umwandel und dann mit flash-ota versuche zu übertragen, bekomme ich folgenden Fehler:
HomeMatic OTA flasher version 0.103-git

Reading firmware from Bootloader-AskSin-OTA-Atmega328p_OTA_201911090831.eq3...
can't get length information!


Ich hab irgendwie die Vermutung, das es daran liegt, dass der Flash nicht zusammenhängend ist.
Also, dass erst vorne alles hingeschrieben wird und dann noch was am Ende.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 09 November 2019, 09:04:35
Jetzt hab ich mal die erste Page mit dem Magicword gefüllt und den Bootloader ab 0x1000 anfangen lassen und schon akzeptiert auch das flash-ota die Datei ...
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 09 November 2019, 18:24:10
Hab's jetzt hinbekommen, dass man den Bootloader OTA aktualisieren kann.
Mehr schreib ich morgen dazu.

Aktuell hab ich noch das Problem mit der Makefile, dass dort die eine Zeile des Flashs die Adresse 0x0ECE hat. 
Irgendwie passt das nicht da in der Zeile ja schon was ab 0x0EC0 geschrieben wurde.
Musste jetzt diese Zeile raus editieren.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 09 November 2019, 22:20:00
Hattest du es mal mit der https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/Contrib/hex2eq3.php versucht?
Da kannst du beim Konvertieren des HEX-Files als Parameter direkt markAsBootloaderUpdate mitgeben.
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 10 November 2019, 07:02:38
Oh ne, dass hab ich noch garnicht gesehen.
Werd ich mir mal anschauen.
Titel: Antw:AskSin++ Library
Beitrag von: PeMue am 16 November 2019, 17:46:44
Hallo zusammen,

wäre das Thema Bootloader per OTA flashen nicht etwas für den Fensterkontakt? Wenn die Spannungsgrenzen nicht richtig eingestellt sind, dann könnte man ohne große Probleme nachflashen und die Sache wäre gut. Leider weiß ich nicht, was man da tun muss ...

Danke für einen Hinweis.

Gruß Peter
Titel: Antw:AskSin++ Library
Beitrag von: Xent am 19 November 2019, 08:22:24
Den Bootloader per OTA Flashen ist nochmal ein anderes Thema.

Ich hab versucht den Bootloader zu optimieren, da sich bei mir scheinbar immer wieder der CC1101 verabschieded und nichts mehr empfängt.
Nach ner Neuinitialisierung empfängt er dann wieder was.
Auch habe ich das flash-ota angepasst, so dass man einstellen kann, das mehr als 5 Versuche gemacht werden.
Titel: Antw:AskSin++ Library
Beitrag von: mdk2412 am 24 November 2019, 12:26:43
Zitat 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;



Ich versuche gerade, aus Layout-Gründen den Pin 2 GDO0 umzulegen (da außer dem Taster-Pin ja nur der Pin 2 auf der Seite ist, wollte ich alles auf die andere Seite vom Arduino bringen). Von 2 auf 3 geht, auf 9 geht schon nicht, und die bevorzugte Variante auf einen der analogen Pins A0-A3 geht gar nicht.

Was müsste man also noch alles umstellen, um den Pin 2 nach 9 oder A0-3 zu legen?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 24 November 2019, 12:30:22
Pin 2 und 3 sind die einzigen beiden Hardware-Interrupts beim 328P.
Titel: Antw:AskSin++ Library
Beitrag von: mdk2412 am 24 November 2019, 12:43:20
Zitat von: jp112sdl am 24 November 2019, 12:30:22
Pin 2 und 3 sind die einzigen beiden Hardware-Interrupts beim 328P.

Ich hatte sowas befürchtet... Danke für die Info, dann brauche ich ja nicht weiter zu suchen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 24 November 2019, 16:09:30
Das Radio (Zeile 751) benutzt die Standard-Arduino-Funktionen attachInterrupt/detachInterrupt. Damit gehen nur die Hardware-Interrupts. Man könnte mal versuchen, das so umzubauen. Dann sollte jeder andere Pin auch gehen.
void enable () {
  if( digitalPinToInterrupt(GDO0) == NOT_AN_INTERRUPT )
    enableInterrupt(GDO0,isr,FALLING);
  else
    attachInterrupt(digitalPinToInterrupt(GDO0),isr,FALLING);
}
void disable () {
  if( digitalPinToInterrupt(GDO0) == NOT_AN_INTERRUPT )
    disableInterrupt(GDO0);
  else
    detachInterrupt(digitalPinToInterrupt(GDO0));
}
Titel: Antw:AskSin++ Library
Beitrag von: mdk2412 am 30 November 2019, 12:23:26
Zitat von: papa am 24 November 2019, 16:09:30
Das Radio (Zeile 751) benutzt die Standard-Arduino-Funktionen attachInterrupt/detachInterrupt. Damit gehen nur die Hardware-Interrupts. Man könnte mal versuchen, das so umzubauen. Dann sollte jeder andere Pin auch gehen.

Vielen Dank für die Lösung (s.o). Das funktioniert so. Sind irgendwelche Nebenwirkungen davon zu erwarten, dass jetzt kein Hardware-Interrupt-Pin benutzt wird?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 30 November 2019, 16:42:26
Nö - denke nicht. Kannst Du bitte mal nen PullRequest fertig machen?
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 01 Dezember 2019, 15:08:27
Zitat von: mdk2412 am 30 November 2019, 12:23:26
Sind irgendwelche Nebenwirkungen davon zu erwarten, dass jetzt kein Hardware-Interrupt-Pin benutzt wird?
Zitat von: papa am 30 November 2019, 16:42:26
Nö - denke nicht. Kannst Du bitte mal nen PullRequest fertig machen?

Nur für mein Verständnis:
- Verwendung eines beliebigen Pins: Wenn ein Interrupt auftritt und der Sketch gerade irgendwo wartet (delay(...)), würde dieser beim Pinpolling verloren gehen, falls die Haltezeit des Pegels kürzer war, als das delay.
- Verwendung eines Hardware-Interrupt-Pins: der AVR merkt intern jederzeit das Auftreten einer Flankenänderung und löst in jedem Fall die hinterlegte ISR aus
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 01 Dezember 2019, 15:57:24
Zitat von: jp112sdl am 01 Dezember 2019, 15:08:27
Nur für mein Verständnis:
- Verwendung eines beliebigen Pins: Wenn ein Interrupt auftritt und der Sketch gerade irgendwo wartet (delay(...)), würde dieser beim Pinpolling verloren gehen, falls die Haltezeit des Pegels kürzer war, als das delay.
- Verwendung eines Hardware-Interrupt-Pins: der AVR merkt intern jederzeit das Auftreten einer Flankenänderung und löst in jedem Fall die hinterlegte ISR aus

Wo hast du diese Info her?
Nach meinem Verständnis kann ein delay() einen Pin Change Interrupt (PCINT) nicht verloren gehen lassen.

Unterschiede EXINT - PCINT nach meinem Verständnis:
- historisch gewachsen, EXINT war schon bei den frühen Devices da, PCINT kam später
- EXINT hat mehr Config Möglichkeiten (level)
- EXINT hat eigene ISR Vektoren, PCINT hat shared Vektoren, dort muss geschaut werden welcher Pin es war (aber nicht per Pin-polling sondern gespeichertes Interrupt bit)
- EXINT kann alle Sleep modes aufwecken (nur level), PCINT nur Idle Edit: PCINT auch
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 01 Dezember 2019, 16:24:50
Zitat von: Tom Major am 01 Dezember 2019, 15:57:24
Wo hast du diese Info her?
Das war mein eigenes Gedankenkonstrukt mit Informationen von hier:
https://www.arduino.cc/reference/de/language/functions/external-interrupts/attachinterrupt/
Zitat
Interrupts sind nützlich, um bestimmte Tasks in Microkontrollerprogrammen automatisch ablaufen zu lassen und können helfen, Timingprobleme zu lösen.
...
Wenn du z.B. sicherstellen willst, dass das Programm alle Stromimpulse eines Drehgebers messen kann, wäre es sehr schwer ein Programm zu schreiben, das noch andere Aufgaben zusätzlich erfüllt, weil das Programm sonst immer den Sensor pollen (d.h. permanent abfragen) müsste.
Ich hatte mal bei einem Pulszählerprojekt Probleme, dass Pulse verloren gingen, wenn ich nicht die INT Pins benutzt habe.
Ist aber auch schon wieder ein paar Jahre her.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 01 Dezember 2019, 18:37:16
Das mit dem delay() bezieht sich darauf dass es nicht innerhalb einer ISR funktioniert.
Eine PCINT Erkennung wird in PCIFR geflagt und sollte nicht verloren gehen.
Wenn der uC allerdings in einer anderen ISR beschäftigt ist und in der Zeit kommt der PCINT 2x, dann wirst du eine Zählung verlieren. Ist aber bei EXINT auch nicht anders.

Was mir gerade einfällt, mit dem neuen WOR im cc1101, kann es da den Fall geben dass der uC über /INT0 geweckt werden soll?
Falls ja, dies wird nicht bei PCINT funktionieren falls wir im power-down/power-save Mode sind.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 01 Dezember 2019, 19:23:36
Zitat von: Tom Major am 01 Dezember 2019, 18:37:16
Falls ja, dies wird nicht bei PCINT funktionieren falls wir im power-down/power-save Mode sind.
Und wie ist das bei den RC-Sketchen?
Die Taster wecken den AVR dort ja an jedem beliebigen Pin!?
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 01 Dezember 2019, 19:52:59
Gute Frage. war heute zu flüchtig beim Drüberschauen.
Tabelle 14.2. Sleep Modes, da steht bei den Wake-up Sources
3) For INT1 and INT0, only level interrupt.
PCINT kann aufwecken, nur EXINT nicht als change sonder nur level.
Also alles gut fürs wake-up.  :)
Titel: Antw:AskSin++ Library
Beitrag von: Psi am 20 Januar 2020, 20:46:09
Hi,
wie kann ich einen Dimmer-Kanal in der setup() Methode nach dem Booten des AVR auf einen bestimmten Wert stellen, optimalerweise mit Ramp?

PS: Ich hab schon das eine oder andere Probiert aber iwie tuts nicht wie erwartet.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Januar 2020, 21:11:34
Das sollte mit
sdev.channel(1).set(value, ramp, delay);
gehen.
Titel: Antw:AskSin++ Library
Beitrag von: Psi am 20 Januar 2020, 21:58:07
Zitat von: papa am 20 Januar 2020, 21:11:34
Das sollte mit
sdev.channel(1).set(value, ramp, delay);
gehen.

Vielen dank für die schnelle Antwort. genau so hab ich das gemacht aber iwie is das nicht rund.
value: Steps (also 0..200)
ramp: Millisekunden? Das ist doch die Zeit des Dimmvorgangs?
delay: 0


setup() {
   ...
  sdev.initDone();
  sdev.channel(1).set(200, 500, 0);
}



AskSin++ V4.1.2 (Jan 20 2020 21:55:14)
Address Space: 32 - 843
CC init1
CC Version: 04
- ready
Config Freq: 0x2165AA
SetLevel: 00 0000 FFFF
SetLevel: 00 0000 FFFF
SetLevel: 00 0000 FFFF
ID: 11125A  Serial: konstant22
SetLevel: C8 01F4 0000
Ramp/Level: 0/200
Ramp/Level: 50/0


Titel: Antw:AskSin++ Library
Beitrag von: papa am 20 Januar 2020, 22:52:34
Mach mal delay auf 0xffff
Titel: Antw:AskSin++ Library
Beitrag von: Psi am 20 Januar 2020, 23:56:22
Zitat von: papa am 20 Januar 2020, 22:52:34
Mach mal delay auf 0xffff

Vielen Dank, mit

sdev.channel(1).set(200, 0b01100001, 0xffff);

tut es nun. Ganz verstehe ich es aber nicht.

Die Funktion erklärt sich mir nicht ganz: https://github.com/pa-pa/AskSinPP/blob/master/AskSinPP.h#L112
Die linken 3 Bits geben die Ramp zurück und sie wird verdoppelt wenn eins der rechten 5 Bits gesetzt ist?

Warum setz ich delay auf 0xFFFF? Naiv würde ich annehmen, dass ich dann eben so lange warte.
Titel: Antw:AskSin++ Library
Beitrag von: jp112sdl am 21 Januar 2020, 06:31:44
Zitat von: Psi am 20 Januar 2020, 23:56:22
Die linken 3 Bits geben die Ramp zurück und sie wird verdoppelt wenn eins der rechten 5 Bits gesetzt ist?


Wenn du 0xFFFF übergibst, wird direkt 0xFFFFFFFF zurückgegeben: AskSinPP.h#L114 (https://github.com/pa-pa/AskSinPP/blob/master/AskSinPP.h#L114)

Zitat von: Psi am 20 Januar 2020, 23:56:22
Die Funktion erklärt sich mir nicht ganz
Die linken 3 Bits geben die Ramp zurück und sie wird verdoppelt wenn eins der rechten 5 Bits gesetzt ist?

Die Zeitberechnung, wie sie in den XML Files verwendet wird, war für mich als "nicht-Informatik-oder-Mathe-Student" auch nicht sofort klar zu verstehen:

<parameter id="RAMP_TIME" operations="write" control="NONE">
  ...
  <conversion type="integer_tinyfloat" mantissa_start="5" mantissa_size="11" exponent_start="0" exponent_size="5"/>
</parameter>

und musste mich erstmal belesen, was es mit Mantisse und Exponent (https://de.wikipedia.org/wiki/Gleitkommazahl#Mantisse) auf sich hat  ::)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Januar 2020, 08:25:46
Die Zeitumrechnung habe ich auch nur von der NewAskSin geerbt :-)
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 21 Januar 2020, 10:00:44
hatte auch schon die "alte" AskSin ähnlich drin:
https://github.com/trilu2000/AskSin/blob/master/utility/Helpers.cpp#L41 (https://github.com/trilu2000/AskSin/blob/master/utility/Helpers.cpp#L41)
Titel: Antw:AskSin++ Library
Beitrag von: Psi am 21 Januar 2020, 19:23:17
Das mit dem delay ist weiterhin unklar.

Nutze ich delay=0 oder delay=0x00ff, dann bekomme ich


SetLevel: C8 0041 0000 (bzw 00FF)
Ramp/Level: 40/200
// Ablauf der Rampe ...
Ramp/Level: 50/0
// Ablauf der Rampe ...


Bei delay=0xffff funktioniert es wie erwartet. Wo ist denn der Code der dafür zuständig ist?


Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Januar 2020, 19:35:05
https://github.com/pa-pa/AskSinPP/blob/f26f1b0db15c15c46d12b90ead9ed7b41fbc1f1c/Dimmer.h#L571
https://github.com/pa-pa/AskSinPP/blob/f26f1b0db15c15c46d12b90ead9ed7b41fbc1f1c/Dimmer.h#L318
Titel: Antw:AskSin++ Library
Beitrag von: Psi am 21 Januar 2020, 19:58:16
Ahh vielen Dank! Kapiert!

Nur

Ramp/Level: 40/200
setState
setState UpdateSate
setState DELAY_NO
setState
setState UpdateSate
setState DELAY_NO
setState
setState UpdateSate
setState RAMP
Ramp/Level: 50/0
setState
setState UpdateSate


ist noch komisch wenn delay != 0 && delay != 0xffff. Das zweite "Ramp/Level: 50/0" sollte ausbleiben.
Hier fallen wir wohl in if ( state == AS_CM_JT_RAMPON || state == AS_CM_JT_RAMPOFF ) { rein?
Sieht für mich erst mal nach nem Bug aus aber da (zumindest ich) kein delay brauche ist weitere Investigation nicht nötig.

Vielen Dank für die Erklärungen !!!
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Januar 2020, 20:56:35
Nein das ist kein Bug - bei 0x00ff kommt nach der Umrechnung 0 raus. Wenn die 30 Sekunden delay haben willst, musst Du ((30 * 10) << 5) übergeben. Alternativ kannst Du auch  (((15 * 10) << 5) | 0x01) nehmen.

Edit: Mist ist doch ein Bug in der Umrechnung - da gibt es nen Überlauf.

Edit2: Ist gefixt
Titel: Antw:AskSin++ Library
Beitrag von: Psi am 21 Januar 2020, 21:06:42
In der Tat :)

Dennoch: sdev.channel(1).set(200, 0b01000001, 0b01000001);


Ramp/Level: 40/200
...
Ramp/Level: 50/0


Aber wegen mir müssen wir hier nicht weiter graben, meine Anforderung ist erfüllt.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 21 Februar 2020, 13:20:20
Hallo,

Ich habe mehrere HMSCI-3 aufgebaut.
Bei jedem benötige ich eine unterschiedliche Tasteranzahl.
Diese ist von 1. Bis 3.
In dem Sketch gibt es folgenden Eintrag

// Anzahl Kanäle (3 - 7)
#define CHANNEL_COUNT 3
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {14, 15, 16, 17, 3, 6, 9 };

Wie mache ich die Abfrage, dass ich je nach Wetz in CHANNEL-COUNT eine unterschiedliche Pin Config hinterlegen kann und wo Stelle ich die angezeigten Channels ein.

Wenn ich die Konfig manuell anpasse, funktioniert das, möchte es automatisch doch es werden immer 3 Channels angezeigt. Die nicht konfigurierten reagieren nicht. Wäre schön wenn diese auch nicht sichtbar wären.

Danke Euch.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 21 Februar 2020, 22:54:12
FHEM legt immer alle Channel für das Device an. Das ist in der HMConfig hart verdrahtet.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 22 Februar 2020, 08:49:24
Zitat von: papa am 21 Februar 2020, 22:54:12
FHEM legt immer alle Channel für das Device an. Das ist in der HMConfig hart verdrahtet.

Danke

Wie setzte ich die Anordnung der Eingänge im Sketch um
Für 1 Taster

#define CHANNEL_COUNT 1
// Pin für Kanal        1   2   3
uint8_t sens_pins[] = {15, 14, 16 };

Für 2 Taster

#define CHANNEL_COUNT 2
// Pin für Kanal        1   2   3
uint8_t sens_pins[] = {14, 16, 15 };

Für 3 Taster

#define CHANNEL_COUNT 3
// Pin für Kanal        1   2   3
uint8_t sens_pins[] = {15, 14, 16 };

Wie baue ich die 3 Einstellungen in eine Abfrage ein, damit ich die Konfiguration nicht jedes Mal die Pins anpassen muss.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 22 Februar 2020, 16:28:52
Ich glaube, ich verstehe nicht, was Du meinst.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 23 Februar 2020, 00:23:12
Zitat von: papa am 22 Februar 2020, 16:28:52
Ich glaube, ich verstehe nicht, was Du meinst.

Hallo,

wie baue ich eine If then elsif Abfrage in einen Scatch ein?

#define CHANNEL_COUNT 1

if (CHANNEL_COUNT == 1) {
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {15, 14, 16, 17, 3, 6, 9 };
}
else if (CHANNEL_COUNT == 2) {
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {14, 16, 15, 17, 3, 6, 9 };
}
else {
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {14, 15, 16, 17, 3, 6, 9 };
}

Fehlermeldung:
Arduino: 1.8.9 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328P (3.3V, 8 MHz)"


HM-SCI-3-FM:29:1: error: expected unqualified-id before 'if'

if (CHANNEL_COUNT == 1) {

^~

HM-SCI-3-FM:33:1: error: expected unqualified-id before 'else'

else if (CHANNEL_COUNT == 2) {

^~~~

HM-SCI-3-FM:37:1: error: expected unqualified-id before 'else'

else {

^~~~

exit status 1
expected unqualified-id before 'if'


Danke
Titel: Antw:AskSin++ Library
Beitrag von: papa am 23 Februar 2020, 16:52:03
Du kannst hier kein if nehmen, da sonst die Pindefinition nur innerhalb der Klammern gültig ist. Du willst ja auch nicht zur Laufzeit - sondern zur Übersetzungszeit testen. Da brauchst Du das Präprozessor-Kommando #if.
#define CHANNEL_COUNT 1

#if CHANNEL_COUNT == 1
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {15, 14, 16, 17, 3, 6, 9 };
#elif CHANNEL_COUNT == 2
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {14, 16, 15, 17, 3, 6, 9 };
#else
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {14, 15, 16, 17, 3, 6, 9 };
#endif

Siehe auch https://de.wikibooks.org/wiki/C-Programmierung:_Pr%C3%A4prozessor##if (https://de.wikibooks.org/wiki/C-Programmierung:_Pr%C3%A4prozessor##if)
Titel: Antw:AskSin++ Library
Beitrag von: RaspiLED am 23 Februar 2020, 17:21:28

WikiBooks, cool kannte ich noch nicht ;-)

Also hier:
https://de.m.wikibooks.org/wiki/C-Programmierung:_Pr%C3%A4prozessor

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 23 Februar 2020, 18:12:57
Zitat von: papa am 23 Februar 2020, 16:52:03
Du kannst hier kein if nehmen, da sonst die Pindefinition nur innerhalb der Klammern gültig ist. Du willst ja auch nicht zur Laufzeit - sondern zur Übersetzungszeit testen. Da brauchst Du das Präprozessor-Kommando #if.
#define CHANNEL_COUNT 1

#if CHANNEL_COUNT == 1
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {15, 14, 16, 17, 3, 6, 9 };
#elif CHANNEL_COUNT == 2
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {14, 16, 15, 17, 3, 6, 9 };
#else
// Pin für Kanal        1   2   3   4  5  6  7
uint8_t sens_pins[] = {14, 15, 16, 17, 3, 6, 9 };
#endif

Siehe auch https://de.wikibooks.org/wiki/C-Programmierung:_Pr%C3%A4prozessor##if (https://de.wikibooks.org/wiki/C-Programmierung:_Pr%C3%A4prozessor##if)

Hallo papa,

vielen Dank für Deine Hilfe und den Link.

Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 24 Februar 2020, 16:16:06
Zitat von: Beetle2003 am 23 Februar 2020, 18:12:57
Hallo papa,

vielen Dank für Deine Hilfe und den Link.

Funktioniert so.
Titel: Antw:AskSin++ Library
Beitrag von: molnitza am 01 März 2020, 18:30:11
Hallo liebe Leute,

ich bin zur Zeit etwas am Verzweifeln. Ich habe mir ein HM-WDS40-TH-I-BME280 gebaut. Dabei bin ich wie folgt vorgegangen:

1. Die lowfuses auf E2 geändert .
avrdude -p m328p -c avripsmkii -U lfuse:w:0xE2:m

2. Externen Quarz durch eines mit 32kHz ersetzt.
https://www.reichelt.de/uhrenquarz-metallgehaeuse-2x2x6mm-6pf-32-768-ms1v-6-p85043.html?&trstct=pos_0&nbc=1

3. Arduino mit FreqTest.ino geflasht und drei Zyklen laufen lassen.
https://github.com/pa-pa/AskSinPP/blob/master/examples/FreqTest/FreqTest.ino

4. HM-WDS40-TH-I-BME280/HM-WDS40-TH-I-BME280.ino geflasht, wobei ich USE_RTC einkommentiert und Device Serial gändert habe.
https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/HM-WDS40-TH-I-BME280/HM-WDS40-TH-I-BME280.ino

5. Sensor in Betrieb genommen und mit der Zentrale gepairt.

Bis hierhin funktioniert alles problemlos. Der Sensor wird gefunden und sendet fleißig Daten.
Mein nächster Schritt war den Sensor mit einem HM-CC-RT-DN zu pairen. Nur scheint hier irgendetwas nicht zu stimmen. Pairen lassen sich die Geräte. Nur blinkt im Anschluss das Funksymbol auf dem Display des HM-CC-RT-DN und die Temperaturen werden nicht übernommen, was nach meiner Meinung wieder auf falsche Timings hindeutet.

Hat jemand eine Idee?
Hier noch die serielle Ausgabe mit Zeitstempel: https://pastebin.com/4em9Ywbb (https://pastebin.com/4em9Ywbb)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 März 2020, 20:56:52
Der verwendete Sketch berechnet die Sendslots nicht. Er sendet stumpf mit dem eingestellten Interval.
Du must den folgenden Sketch als Basis nehmen https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-WDS10-TH-O/HM-WDS10-TH-O.ino. Hier wird der Sendslot richtig berechnet. Zur Feinjustierung kann EXTRAMILLIS angepasst werden. Die Sht10-Klasse kann einfach durch die Bme280 ausgetauscht werden.
Titel: Antw:AskSin++ Library
Beitrag von: molnitza am 02 März 2020, 05:41:03
Hallo papa,

danke für deine schnelle Antwort. Ich habe den Sketch fix umgebaut. leider stellt sich keinerlei Änderung ein. Es wird nach wie vor stumpf nach Zeit gesendet. Hast du noch eine Idee?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 März 2020, 08:05:29
Na dann zeig doch mal Deinen Sketch und die Ausgaben der Console - meine Glaskugel ist gerade defekt.
Titel: Antw:AskSin++ Library
Beitrag von: molnitza am 02 März 2020, 16:12:30
Hallo papa,
ich war heute Morgen schon unterwegs, daher habe ich nichts anhängen können. Aber nun möchte ich deine Glaskugel mit Informationen füllen.

Hier zunächst der abgewandelte Sketch: https://pastebin.com/03TBvf0W
Dieser nutzt den von dir Genannten als Basis: https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-WDS10-TH-O/HM-WDS10-TH-O.ino
Als Ausgabe erhalte ich folgendes: https://pastebin.com/94F09kpZ

Das Blinken des Funksymbols des HM-CC-RT-DN ist wieder zu beobachten.
Sehr viel anders als beim ersten Versuch scheint sich der Sketch leider nicht zu verhalten. Ich hoffe du kannst mit den Informationen was anfangen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 März 2020, 20:21:27
Hast Du das Peering nochmal neu gemacht ?
So ganz scheint aber das Timing auch noch nicht zu passen.
15:58:13.763 -> <- 0C 03 84 70 345679 000000 00 D1 27  - 20365
15:58:13.763 -> 120.500
16:00:10.533 -> Measure... 
16:00:10.533 -> T: 208  H: 37
16:00:14.784 -> <- 0C 04 84 70 345679 000000 00 D0 25  - 20418

Er hat 120,5 Sekunden bis zum nächsten Sendeslot berechnet. Sendet aber erst nach 121 Sekunden. Setzte mal die EXTRAMILLIS um 500ms nach unten.
Titel: Antw:AskSin++ Library
Beitrag von: molnitza am 05 März 2020, 19:03:23
Hallo papa,

ich habe ein wenig mit EXTRAMILLIS herumgespielt und bin nun bei 530 angelangt.
Eine Besserung hat sich leider nicht eingestellt - sprich das bzw. die Thermostate bekommen die Temperatur nicht übertragen. Angelernt sind diese allerdings. Mir aufgefallen, dass sich die Abweichungen teils enorm variieren (siehe Anhang). Ist das normal?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 März 2020, 20:39:37
Hast Du jedes mal, nachdem Du was am Sketch geändert hast, nochmal das Peering gemacht? Sonst ist es reiner Zufall, wenn sich die beiden verstehen.
Die Werte haben schon recht viel Abweichung. Was ist denn da für ein Quarz dran ? Zeig mal den Aufbau.
Titel: Antw:AskSin++ Library
Beitrag von: molnitza am 05 März 2020, 20:57:49
Das Pairing habe ich nach jedem Flashen wiederholt. Nun habe ich die Heizkörperthermostate ebenfalls komplett zurückgesetzt und neu gepaired. Seitdem scheint die Übertragung mehr oder minder gut zu funktionieren. Ich nutze dieses Quarz ohne weiteren Kondensator: https://www.reichelt.de/uhrenquarz-metallgehaeuse-2x2x6mm-6pf-32-768-ms1v-6-p85043.html

Am Wochenende baue ich einen weiteren Sensor auf. Die Hardware hierfür kommt aus einer anderen Charge, bis auf das Quarz. Bei dem Sensor werde ich ebenfalls eine Auswertung machen. Ggf. stellt sich hier eine Änderung ein.




Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 März 2020, 22:18:56
Du hast die Kondensatoren am Quarz weg gelassen. Das könnte die Abweichungen erklären.
Titel: Antw:AskSin++ Library
Beitrag von: Gernott am 06 März 2020, 00:29:45
Zitat von: papa am 05 März 2020, 22:18:56
Du hast die Kondensatoren am Quarz weg gelassen. Das könnte die Abweichungen erklären.
Ich hatte mal im letzten Jahr eine längere Testreihe zur Synchronisation mit dem Heizungsregler gemacht.
Durch Änderung der Extramillis in kleinen Schritten habe ich dann eine funktionierende Kommunikation hinbekommen. Ich hatte auf meiner Platine auch einen Mini-Uhrenquarz ohne zusätzliche Kondensatoren angelötet. Es ist natürlich möglich, daß dadurch verschiedene Zeiten notwendig werden.

Laut einer Info von Tom geht es auch ohne Cs, wenn man den richtigen Quarz hat:
https://forum.fhem.de/index.php/topic,20620.msg991792.html#msg991792
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 06 März 2020, 00:57:02
ja, Abschnitt
13.5. Low Frequency Crystal Oscillator
im Datenblatt, die Formel dort.
Die Streukapazität muss man ohne das nötige Equipment schätzen.
Trotz Schätzung, je mehr man mit CL vom Quarz runtergeht desto eher erreicht man den Punkt wo man keine optionalen ext. C mehr braucht.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 07 März 2020, 18:25:10
Hallo,

Ich habe nach den anfänglichen Schwierigkeiten den HM-SEN-LI-O neu aufgebaut. Als Sketch habe ich den mit der Übertragung alle 120sec von Jerome genutzt, da der in der Asksin Bibliothek hinterlegte alle 8 Sekunden eine Übertragung durchgeführt hat. Die Bibliothek ist die Version 4.1.2.

Nun Stelle ich fest, dass zwischendurch der Fall passiert, dass der Wert von zu.B 10000 auf 2 wechselt, obwohl keine so extreme Änderung zu erkennen ist. Einer der nachfolgenden Läufe liefert wieder ein Wert.

Wie kann ich den Sketch abändern, dass bei einer Veränderung von mehr als z.B. 50% zum vorigen Wert oder testen auf 0 der Wert nicht übernommen wird? Nachts müsste o zulässig sein.


Anbei ein Log Auszug

2020-03-12_08:04:45 Lichtsensor1 brightness: 13602
2020-03-12_08:07:07 Lichtsensor1 brightness: 20256
2020-03-12_08:09:29 Lichtsensor1 brightness: 22088
2020-03-12_08:11:51 Lichtsensor1 brightness: 22302
2020-03-12_08:14:13 Lichtsensor1 brightness: 21303
2020-03-12_08:16:35 Lichtsensor1 brightness: 20137
2020-03-12_08:18:57 Lichtsensor1 brightness: 21469
2020-03-12_08:21:19 Lichtsensor1 brightness: 18261
2020-03-12_08:23:40 Lichtsensor1 brightness: 18512
2020-03-12_08:26:02 Lichtsensor1 brightness: 16752
2020-03-12_08:28:25 Lichtsensor1 brightness: 19238
2020-03-12_08:30:46 Lichtsensor1 brightness: 21701
2020-03-12_08:33:09 Lichtsensor1 brightness: 20837
2020-03-12_08:35:30 Lichtsensor1 brightness: 23621
2020-03-12_08:37:52 Lichtsensor1 brightness: 16683
2020-03-12_08:40:14 Lichtsensor1 brightness: 12978
2020-03-12_08:42:36 Lichtsensor1 brightness: 17375
2020-03-12_08:47:20 Lichtsensor1 brightness: 17671
2020-03-12_08:49:42 Lichtsensor1 brightness: 22270
2020-03-12_08:52:04 Lichtsensor1 brightness: 18982
2020-03-12_08:54:25 Lichtsensor1 brightness: 23013
2020-03-12_08:56:50 Lichtsensor1 brightness: 18863
2020-03-12_08:59:09 Lichtsensor1 brightness: 19677
2020-03-12_09:01:31 Lichtsensor1 brightness: 17696
2020-03-12_09:03:53 Lichtsensor1 brightness: 21893
2020-03-12_09:06:15 Lichtsensor1 brightness: 22514
2020-03-12_09:08:37 Lichtsensor1 brightness: 19564
2020-03-12_09:10:59 Lichtsensor1 brightness: 23407
2020-03-12_09:13:21 Lichtsensor1 brightness: 13213
2020-03-12_09:15:42 Lichtsensor1 brightness: 18694
2020-03-12_09:18:04 Lichtsensor1 brightness: 18988
2020-03-12_09:20:26 Lichtsensor1 brightness: 12980
2020-03-12_09:22:48 Lichtsensor1 brightness: 22562
2020-03-12_09:25:10 Lichtsensor1 brightness: 21158
2020-03-12_09:27:32 Lichtsensor1 brightness: 11784
2020-03-12_09:29:54 Lichtsensor1 brightness: 9226
2020-03-12_09:32:15 Lichtsensor1 brightness: 15545
2020-03-12_09:34:37 Lichtsensor1 brightness: 17297
2020-03-12_09:37:00 Lichtsensor1 brightness: 12326
2020-03-12_09:39:21 Lichtsensor1 brightness: 12675
2020-03-12_09:41:43 Lichtsensor1 brightness: 15477
2020-03-12_09:44:05 Lichtsensor1 brightness: 11887
2020-03-12_09:46:27 Lichtsensor1 brightness: 16584
2020-03-12_09:48:49 Lichtsensor1 brightness: 3674
2020-03-12_09:51:11 Lichtsensor1 brightness: 3214
2020-03-12_09:53:33 Lichtsensor1 brightness: 11411
2020-03-12_09:55:54 Lichtsensor1 brightness: 22533
2020-03-12_09:58:16 Lichtsensor1 brightness: 19512
2020-03-12_10:00:38 Lichtsensor1 brightness: 0
2020-03-12_10:05:23 Lichtsensor1 brightness: 24079
2020-03-12_10:07:44 Lichtsensor1 brightness: 0
2020-03-12_10:45:42 Lichtsensor1 brightness: 16123
2020-03-12_10:48:03 Lichtsensor1 brightness: 0
2020-03-12_10:55:06 Lichtsensor1 brightness: 4987
2020-03-12_10:57:28 Lichtsensor1 brightness: 0
2020-03-12_11:25:55 Lichtsensor1 brightness: 21807
2020-03-12_11:28:17 Lichtsensor1 brightness: 0
2020-03-12_11:30:39 Lichtsensor1 brightness: 24209
2020-03-12_11:33:01 Lichtsensor1 brightness: 0
2020-03-12_11:35:24 Lichtsensor1 brightness: 27122
2020-03-12_11:37:46 Lichtsensor1 brightness: 0
2020-03-12_12:20:21 Lichtsensor1 brightness: 7697
2020-03-12_12:22:44 Lichtsensor1 brightness: 6488
2020-03-12_12:25:06 Lichtsensor1 brightness: 23896
2020-03-12_12:27:28 Lichtsensor1 brightness: 25916
2020-03-12_12:29:50 Lichtsensor1 brightness: 0
2020-03-12_12:36:57 Lichtsensor1 brightness: 2339
2020-03-12_12:39:20 Lichtsensor1 brightness: 0
2020-03-12_12:41:42 Lichtsensor1 brightness: 21625
2020-03-12_12:44:04 Lichtsensor1 brightness: 14215
2020-03-12_12:46:26 Lichtsensor1 brightness: 1
2020-03-12_12:48:48 Lichtsensor1 brightness: 0


Danke
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 14 März 2020, 13:28:45
Hallo,

Heute ist der Fall, dass seit 9:52 nur noch 0 Werte übertragen werden.

Kann sich das jemand erklären?
Titel: Antw:AskSin++ Library
Beitrag von: kpwg am 14 März 2020, 16:33:39
Welchen Sensor haste denn verbaut? Mit dem MAX44009 gibt es sehr gute Erfahrungen, der TSL2561 dagegen ist für dieses Problem bekannt.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 14 März 2020, 23:32:40
Zitat von: kpwg am 14 März 2020, 16:33:39
Welchen Sensor haste denn verbaut? Mit dem MAX44009 gibt es sehr gute Erfahrungen, der TSL2561 dagegen ist für dieses Problem bekannt.

Vielen Dank für dem Hinweis.
Ich habe einen TSL2561 verbaut. Dieses war mir nicht bekannt.

Werde einen Max44009 bestellen.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 25 März 2020, 19:23:41
Hallo,

habe schon mehrere Board mit dem HB-SCI-3-FM Sketch geflashed.
Seit gestern erhalte ich die gezeigte Fehlermeldung. Habe son verschiedene Versionen von AdruinoIDE probiert.
Immer der gleiche Fehler.

Was kann es sein?


Arduino: 1.8.9 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328P (3.3V, 8 MHz)"

C:\Users\Ralf\Documents\Save\Arduino_eigen\HB-SCI-3-FM\HB-SCI-3-FM.ino:179:1:   required from here

C:\Users\Ralf\Documents\Arduino\libraries\AskSinPP-master/ContactState.h:194:26: error: 'class OnePinChannel<Hal, RHSList0, RHSList1, as::RegList4<as::DefaultRegisterList4>, 6>' has no member named 'changed'

         dev.channel(idx).changed(true); // force StatusInfoMessage to central

Bibliothek EnableInterrupt-master in Version 1.0.0 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\EnableInterrupt-master  wird verwendet
Bibliothek AskSinPP-master in Version 4.1.2 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\AskSinPP-master  wird verwendet
Bibliothek Low-Power in Version 1.6 im Ordner: C:\Users\Ralf\Documents\Arduino\libraries\Low-Power  wird verwendet
exit status 1
template argument 1 is invalid



Danke Euch
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 März 2020, 20:04:40
Das ThreeState-Sachen haben sich geändert. Am besten Du nimmst den V4-Branch. Sonst müsste man sich mal den Sketch genauer ansehen und entsprechend anpassen.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 25 März 2020, 22:15:27
Zitat von: papa am 25 März 2020, 20:04:40
Das ThreeState-Sachen haben sich geändert. Am besten Du nimmst den V4-Branch. Sonst müsste man sich mal den Sketch genauer ansehen und entsprechend anpassen.

Hallo,

danke für die schnelle Rückmeldung.

Was ist mit V4 Branch gemeint. Ich habe den aktuelle Asksin-Master.zip in der Version 4.1.2 geladen.

Danke
Titel: Antw:AskSin++ Library
Beitrag von: papa am 25 März 2020, 23:17:33
https://github.com/pa-pa/AskSinPP/tree/V4
Titel: Antw:AskSin++ Library
Beitrag von: Psi am 25 März 2020, 23:33:23
Also ich hab ja mit https://github.com/pa-pa/AskSinPP/archive/master.zip recht gute Erfahrungen gemacht :)

v4 Branch ist  234 commits behind master, ist das nicht schon etwas weit zurück?
https://github.com/pa-pa/AskSinPP/compare/018c087...8c75792
Der Move von ThreeState zu ContatState ist hier noch nich drin.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 26 März 2020, 10:46:29
Zitat von: Psi am 25 März 2020, 23:33:23
Also ich hab ja mit https://github.com/pa-pa/AskSinPP/archive/master.zip recht gute Erfahrungen gemacht :)

v4 Branch ist  234 commits behind master, ist das nicht schon etwas weit zurück?
https://github.com/pa-pa/AskSinPP/compare/018c087...8c75792
Der Move von ThreeState zu ContatState ist hier noch nich drin.

Danke, mit der alten Version hat es funktioniert.

Was muss getan werden, damit beim nächsten AskSin-Master update die alte Logik funktioniert?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 26 März 2020, 13:48:27
Keine Ahnung - der Sketch muss halt irgendwo angepasst werden. Eigentlich sollten die Änderungen im Master rückwärtskompatibel sein. Scheint wohl aber nicht ganz geklappt zu haben. Bei meinen Examples ging es ohne Probleme.
Titel: Antw:AskSin++ Library
Beitrag von: Bird am 08 Juli 2020, 11:33:37
Hallo zusammen,

ich habe mir den HM-UNI-SEN-WEA nachgebaut und mit der aktuellen Software (1.4) versehen. In FHEM habe ich beiden PM-Files von papa installiert. Die Wetterstation wurde im FHEM sofort angelernt und liefert artig regelmässig seine Daten der angeschlossenen I2C Sensoren. Meinen grossen Dank an alle Beteiligten dieser tollen Homematic Projekte.
Als ich den Regensensor (generic) angeschlossen habe ist mir aber ein Fehler aufgefallen, bei einsetzenden Regen oder einer Windböe werden kurzzeitig falsche Werte für Temperatur, Feuchte und Luftdruck in FHEM angezeigt. Wenn ich die Software vom HM-UNI-SEN-WEA richtig verstanden habe, werden hier 3 verschiedene Messagetypen versenden, die zyklischen Wetterdaten (Typ 0x70), Eventdaten bei einsetzenden Regen, Heizung und Windböen (Typ 0x53) und weitere Eventdaten (Typ 0x41), der Payload dieser drei Messagetypen ist unterschiedlich. In dem PM-File HMConfig_AskSinCustom.pm wird nach meinem Verständnis nicht zwischen diesen Messagetypen unterschieden und nur das Datenformat der Typ 0x70 Messages ohne Typprüfung ausgewertet. Ich habe deswegen die HMConfig_AskSinCustom.pm so ergänzt, das der Messagetype mit berücksichtigt wird und das Datenformat des Typs 0x53 ergänzt. Meine Frage ist jetzt, habe ich das vom Verständnis richtig gelöst oder habe ich die Funktionsweise der HMConfig_AskSinCustom.pm falsch verstanden und muß doch woanders ansetzen?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Juli 2020, 12:56:17
Da hast Du bestimmt Recht. Bitte als Pull-Request zur Verfügung stellen. Danke
Titel: Antw:AskSin++ Library
Beitrag von: papa am 08 Juli 2020, 20:27:42
@Bird: Danke. Ich habe noch ein paar kleine Änderungen gemacht. Kannst Du das bitte nochmal bei Dir testen ?
Titel: Antw:AskSin++ Library
Beitrag von: Bird am 09 Juli 2020, 21:30:16
@papa: Danke für Deine schnelle Hilfe. Ich musste allerdings noch etwas anpassen. Ich stelle Dir einen neuen pull request ein sobald ich mit den Tests fertig bin.
Titel: Antw:AskSin++ Library
Beitrag von: capt_bluebaer am 23 Juli 2020, 21:31:05
Hallo,
hab mal ne Frage zu dem Beispiel HM-LC-SWX-SM. Ich habe einige Exemplare davon zusammengebaut und benutze sie als Ersatz für IT-Aktoren, die ja einigermassen unzuverlässig sind und auch kein Feedback senden.
Ich setzte die Aktoren für zeitgesteurte Schaltvorgänge ein und möchte unabhängig von der Zentrale sein. Leider erreiche ich bei "on-till-timer" nur Zeitspannen bis 26201 s, das entspricht 7h 16m 41s. Werte darüber hinaus werden mit NACK (Response 01010000 statt 0101C840) quittiert. Der Befehl "on-until" verhält sich dabei genauso, liegt die Ausschaltzeit später als die 26201s ist auch damit Schluß. Die Original HM-Aktoren kennen diese Grenze nicht. Sie liegt weitaus höher, ich habe das Limit aber nicht weiter verfolgt.
Da ich Schaltzeiten von bis zu 12 Stunden brauche und unabhängig von der Zentrale sein will, würde ich gerne wissen, ob - und wenn ja - wo in den Sketches was zu machen wäre.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 23 Juli 2020, 21:56:55
Das ist komisch - schau mal hier
https://github.com/pa-pa/AskSinPP/blob/f43a56c3c216493ce9ca09dda00b8ca06e42baf1/Switch.h#L313
oder hier
https://github.com/pa-pa/AskSinPP/blob/f43a56c3c216493ce9ca09dda00b8ca06e42baf1/AskSinPP.h#L141
ob da was komisches raus kommt.
Titel: Antw:AskSin++ Library
Beitrag von: capt_bluebaer am 24 Juli 2020, 13:01:55
Auf meinem Test-Aktor funktierte es auf Anhieb!
Grund: Ich bentutze einen fertig kompilierten Sketch den ich über OTA auf meine Produktiv-Aktoren verteilt habe. Dieser hatte allerdings noch einen Versionsstand 4.1.2.
Papa, du hast ja selber bereits den entscheidenen Patch hier (https://github.com/pa-pa/AskSinPP/commit/9a1c906ba97382d603081b926dba08c42aa89617#diff-c634abda79199062d4f4ec1f9c23324e) eingebaut.
Mit der Deklaration der Variablen tByte als 4 Byte Integer kommt es nach Werten > 0x80 nicht mehr zu einem Überlauf.
Vielen, vielen Dank für die schnelle Hilfe, ohnen Deinen Hinweis hätte ich mir 'nen Ast gesucht.
Titel: Antw:AskSin++ Library
Beitrag von: wolwin am 03 August 2020, 21:18:23
Ich möchte das HM-LC-Sw1-Ba-PCB Script gerne so umbauen, dass es quasi eine 'Tasterfunktion' statt einer 'Schalterfunktion' abbildet - Anmerkung: ich weiß, dass man mit virtuellen Tastern und Experten Einstellungen aus Schaltern auch Schalter mit Tastfunktion machen kann - das ganze wollte ich auf Asksin Ebene nachstellen, ohne irgendwelche Expertenparameter einstellen zu müssen...

Dazu habe ich einen eigenen SwitchChannel eingeführt, in dem die Switch-Methode ersetzt wurde, die nun einem Trigger-Alarm startet. Der Trigger schaltet dann für eine vordefinierte Dauer den Port auf HIGH ... dannach wird er z.Z. wieder auf LOW gesetzt - funktioniert auch. Jedoch steht dann der Schalter auf AN ... besser wäre es, wenn er wieder auf AUS zurückgesetzt würde.

Eigentlich müsste man, statt den Port auf LOW zu setzen, eine Asksin Funktion aufrufen, mit der ein Tastendruck (o.ä.??) für AUS simuliert wird (damit auch die CCU ein Update bekommt). Ich habe schon einige Möglichkeiten durchprobiert (z.B. Toogle Methode), aber nichts führt zum Ziel. Hat jemand eine Idee ... gibt es in Asksin Möglichkeiten zur message-injection  o.ä. ... ???

Hier mal der (gekürzte) Beispielcode:


...
// this class controls the pin high/low sequence
class SwAlarm : public Alarm {
private:
  uint8_t  pin;
  uint16_t time;
  uint8_t  state;
public:
  SwAlarm () : Alarm(0), pin(0), time(0), state(0) {
    async(true);
  }
  virtual ~SwAlarm () {}

  virtual void trigger (AlarmClock& clock) {
    switch(state) {
    case 1:
      DPRINTLN("SwitchChannel - trigger 1 - START (500)");
      set(millis2ticks(500));
      break;
    case 2:
      DPRINT("SwitchChannel - trigger 2 - HIGH - "); DDEC(pin); DPRINT(" (");  DDEC(time); DPRINTLN(")");
      set(millis2ticks(time));
      digitalWrite(pin, HIGH);
      break;
    case 3:
      // DPRINT("SwitchChannel - trigger 3 - LOW - "); DDEC(pin); DPRINT(" (");  DDEC(time); DPRINTLN(")");
      // set(millis2ticks(time));
      DPRINT("SwitchChannel - trigger 3 - LOW - "); DDEC(pin); DPRINTLN(" (100)");
      set(millis2ticks(100));
      digitalWrite(pin, LOW);
      break;
    case 4:
      DPRINTLN("SwitchChannel - trigger 4 - END");
      state=0;
      break;
    }
    if( state != 0 ) {
      ++state;
      clock.add(*this);
    }
  }

  bool press (uint8_t p, uint16_t t, AlarmClock& clock) {
    // check that we are not running
    if( state == 0 ) {
      pin = p;
      time = t;
      state = 1;
      trigger(clock);
      return true;
    }
    return false;
  }
};

class SwChannel : public SwitchChannel<Hal, PEERS_PER_CHANNEL, SwList0> {
protected:
  uint8_t  swpin;
  uint16_t swtime;
  SwAlarm  swalarm;
public:
  typedef SwitchChannel<Hal, PEERS_PER_CHANNEL, SwList0> BaseChannel;
  virtual ~SwChannel () {}

  void init (uint8_t pin, uint16_t pintime) {
    BaseChannel::init(pin, false);
    swpin = pin;
    swtime = pintime;
    pinMode(swpin, OUTPUT);
    this->changed(true);
    DPRINT("INIT Pin "); DDEC(swpin); DPRINT(" - OUTPUT - SWTIME "); DDECLN(swtime);
  }

  // replace standard switch method - trigger alarm to start sequence
  virtual void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate,__attribute__((unused)) uint32_t delay) {
    bool pressed = false;
   
    DPRINTLN("### SwitchChannel - switchState");

    if( newstate == AS_CM_JT_ON ) {
      // digitalWrite(swpin, HIGH);
      if( swpin > 0) {
        DPRINT("SwitchChannel - AS_CM_JT_ON - Pin "); DDEC(swpin); DPRINT(" (");  DDEC(swtime); DPRINTLN(")");
        pressed = swalarm.press(swpin, swtime, sysclock);
      }
    }
    else if ( newstate == AS_CM_JT_OFF ) {
      // digitalWrite(swpin, LOW);
      if( swpin > 0) {
        DPRINT("SwitchChannel - AS_CM_JT_OFF - Pin "); DDEC(swpin); DPRINT(" (");  DDEC(swtime); DPRINTLN(")");
        pressed = swalarm.press(swpin, swtime, sysclock);
      }
    }
    if( pressed == true ) {
      DPRINTLN("### SwitchChannel - pressed");
      this->changed(true);
    }
  }
};

// setup the device with channel type and number of channels
class SwitchType : public MultiChannelDevice<Hal,SwChannel,cDEVICE_NUM_CHANNELS,SwList0> {
public:
  typedef MultiChannelDevice<Hal,SwChannel,cDEVICE_NUM_CHANNELS,SwList0> DevType;
  SwitchType (const DeviceInfo& i,uint16_t addr) : DevType(i,addr) {}
  virtual ~SwitchType () {}

  bool init (Hal& hal) {
    bool rtn = DevType::init(hal);
    return(rtn);
  }

};

SwitchType sdev(devinfo, 0x20);
ConfigButton<SwitchType> cfgBtn(sdev);

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY_PIN_1, RELAY_PIN_1_TIME);
...
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 August 2020, 21:34:23
Versuch doch mal die set() Methode zu überschreiben und igrundsätzlich den delay Wert zu setzen.
https://github.com/pa-pa/AskSinPP/blob/f43a56c3c216493ce9ca09dda00b8ca06e42baf1/Switch.h#L262

Übrigens gibt es für den Taster schon die Klasse PushButton im actors Ordner.
Titel: Antw:AskSin++ Library
Beitrag von: wolwin am 04 August 2020, 10:55:51
Zitat von: papa am 03 August 2020, 21:34:23
Versuch doch mal die set() Methode zu überschreiben

Ok, leider sind die SwitchChannel Definitionen wohl nicht kompatibel, um bis zum SwitchStateMachine vorzudringen - was mache ich falsch ?


class SwStateMachine : public SwitchStateMachine {
public:
  // typedef SwStateMachine() : state(AS_CM_JT_NONE), change(false), alarm(*this) {}
  virtual ~SwStateMachine () {}

  // bool set (uint8_t value,__attribute__ ((unused)) uint16_t ramp,uint16_t delay) {
  //   status(value, delay);
  //   return true;
  // }
 
};

template <class HalType,int PeerCount,class List0Type,class IODriver=ArduinoPins>
class SwChannel : public ActorChannel<HalType,SwitchList1,SwitchList3,PeerCount,List0Type,SwStateMachine> {

public:
  // SwChannel () : BaseChannel(), lowact(false), pin(0) {}
   virtual ~SwChannel() {}

};



class SwChannel : public SwitchChannel<Hal, PEERS_PER_CHANNEL, SwList0> {
...
};

class SwitchType : public MultiChannelDevice<Hal,SwChannel,cDEVICE_NUM_CHANNELS,SwList0> {
public:
  typedef MultiChannelDevice<Hal,SwChannel,cDEVICE_NUM_CHANNELS,SwList0> DevType;
  SwitchType (const DeviceInfo& i,uint16_t addr) : DevType(i,addr) {}
  virtual ~SwitchType () {}
...
};

...


Zitat von: papa am 03 August 2020, 21:34:23
Übrigens gibt es für den Taster schon die Klasse PushButton im actors Ordner.
Aah - kannte ich noch nicht ...
Titel: Antw:AskSin++ Library
Beitrag von: papa am 04 August 2020, 17:19:02
Du denkst viel zu kompliziert - einfach nur im SwitchChannel überschreiben. Dieser ist doch direkt von der SwitchStateMachine abgeleitet.
template <class HalType,int PeerCount,class List0Type,class IODriver=ArduinoPins>
class SwCh : public SwitchChannel<HalType,PeerCount,List0Type,IODriver> {
public:
  bool set (uint8_t value,__attribute__ ((unused)) uint16_t ramp,uint16_t delay) {
    // change delay here
    if( delay == 0 ) delay = 50;
    return SwitchChannel<HalType,PeerCount,List0Type,IODriver>::set(value, ramp, delay);
  }
};

Titel: Antw:AskSin++ Library
Beitrag von: cs-online am 16 August 2020, 07:55:29
Hallo zusammen,

verzeiht,möglicherweise steht das schon auf einer der 98 Seiten, aber alle durchzusuchen wird zu lange dauern, ich scheitere schon beim Einbinden der AskSinPP-master.zip, da kommt in der Arduino IDE immer der Fehler "ZIP enthält keine Bibliothek". Version ist 1.8.7 und auch mit Version 1.8.12 das selbe Problem :-(

Habt Ihr eine Idee ?

Grüße Christian
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 16 August 2020, 08:09:32
Entpacken und händisch in den Library Ordner schieben?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 August 2020, 21:00:15
Hilft das hier weiter ?
https://asksinpp.de/Grundlagen/02_software.html#arduino-ide
Titel: Antw:AskSin++ Library
Beitrag von: cs-online am 19 August 2020, 07:42:41
Danke für den Tip, diese Seite hatte ich (glaube ich) noch nicht. Ich probier das heute abend nochmal. Muss ich irgendwas beachten, wenn ich das mit Win10 runterlade ?

Grüße Christian
Titel: Antw:AskSin++ Library
Beitrag von: cs-online am 20 August 2020, 20:31:28
Jawoll, mit der ZIP-Datei V4 hat eshingehauen, die LIB hinzuzufügen :-) Danke dir für den Tip !!!
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 11 November 2020, 22:21:20
Hallo,

ich möchte einen Relais-Schalter gemäß HM-LC-Sw1-PCB aufbauen und dann für diverse Schaltvorgänge einsetzen.
Als Software dazu habe ich HM-LC-SW1-PI-CT-R1 in den AsksinPP Examples gefunden.
Das habe ich auf meinem Experimentierboard gesteckt und geflashed, funktioniert auch soweit, pairing hat auch geklappt.

Jetzt habe ich in der Software eine Funktion

// if A0 and A1 connected
// we use LOW for ON and HIGH for OFF
bool checkLowActive () {
  pinMode(14, OUTPUT); // A0
  pinMode(15, INPUT_PULLUP); // A1
  digitalWrite(15, HIGH);
  digitalWrite(14, LOW);
  bool result = digitalRead(15) == LOW;
  digitalWrite(14, HIGH);
  return result;
}

gesehen.
Wo und wie werden die Pin A0 und A1 angeschlossen und was bewirken diese dann?

Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 16 November 2020, 22:00:57
gelöst:
Brücke A0 - A1 bwirkt on = 0V
keine Brücke on = 3,3V
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 17 November 2020, 01:32:39
Hallo zusammen,
da ich den Actor auf der Asksinpp-Standard-Hardware aufbauen will und mit Batterie betreiben möchte, ist der Ruhestrom ein wichtiges Merkmal.

Wie oben schon beschrieben habe ich den Sketch HM-LC-SW1-PI-CT-R1 geflashed.
Anscheinend geht das Modul mit dieser Software nicht in den Ruhezustand wie es bei meinen anderen Modulen, Temperatursensor, Lichtsensor, 4 Tasten Fernbedienung der Fall ist.

Bei den anderen Modulen messe ich einen Ruhestrom 4,7 uA, bei diesem Actor (auf der gleichen Experimentierhardware geflashed) jedoch 20,3 mA.
Etwas Ähnliches hatte ich auch bei dem 4-Tasten-Modul mit dem Sketch HM-RC-4. Nachdem ich dann den Sketch HM-PBI-4-FM geflashed habe, war der Ruhestrom 4,7 uA.

Weiß jemand, was man bei dem Actor tun kann um den Ruhestrom zu minimieren oder gibt es  vielleicht wie beim 4-Tasten-Modul einen besseren Sketch?

Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: tndx am 17 November 2020, 07:39:48
Moin,

das Originalgerät ist halt kein Batteriegerät, der Sketch bildet das Originalgerät nach, damit es sich nach außen hin ohne zusätzliche Einstellungen auch so verhält. Suche Dir ein Originalgerät, was ein Batteriegerät ist, z.B.:
https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples/HM-MOD-Re-8 (https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples/HM-MOD-Re-8)

Dann müsste es auch mit Stromsparen klappen:
#define USE_WOR

Ist 8 kanalig, aber who cares :)
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 17 November 2020, 09:10:18
Guten Morgen,
Danke für die Info.
Mit dem anderen Sketch funktioniert es.
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 18 November 2020, 22:12:10
Hallo,

kann der Sketch
HB-LC-Sw1PBU-FM
auch auf der AsksinPP-Hardware (Pro Mini mit CC1101) verwendet werden?
Was muss eventuell geändert werden?
Das wäre ideal, um sowohl lokal als auch remote zu schalten.

Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: tndx am 18 November 2020, 23:01:52
Hi,

ja, Du musst nur die Pinbelegung ggf. anpassen (Zeilen 31-37) und beim Kompilieren den entsprechenden ProMini auswählen.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 19 November 2020, 01:16:32
Zitat von: tndx am 18 November 2020, 23:01:52
Hi,

ja, Du musst nur die Pinbelegung ggf. anpassen (Zeilen 31-37) und beim Kompilieren den entsprechenden ProMini auswählen.

Ich habe die PinBelegung folgendermaßen geändert
#define RELAY_PIN          17 //PD4 
#define BTN_PIN_1          14 //PD6
#define BTN_PIN_2          15  //PD0
#define LED_PIN            4  //PB0
#define CONFIG_BUTTON_PIN  8 //PD7
#define CS_PIN             0  //PB4
#define GDO0_PIN           0 //PD2

Kompilieren und Hochladen geht fehlerfrei.

Funktioniert leider nicht.
Weder eine Ausgabe am seriellen Monitor der Arduino IDE, noch irgendeine Reaktion im FHEM beim cfg-Btn und autocreate und der AskSinAnalyzer empfängt auch nichts von diesem Modul.

Was mache ich falsch?
Gruß
Werner
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 19 November 2020, 02:17:10
Es war auch die Änderung für die Schnittstelle zum CC1101 notwendig:

alt:
typedef LibSPI<CS_PIN> SPIType;
typedef Radio<SPIType, GDO0_PIN> RadioType;
typedef AvrSPI<10,11,12,13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>,BattSensor<AsyncMeter<InternalVCC>>,Radio<RadioSPI,2> > Hal;
typedef StatusLed<LED_PIN> LedType;
typedef AskSin<LedType, NoBattery, RadioType> Hal;

neu:
typedef AvrSPI<10,11,12,13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>,BattSensor<AsyncMeter<InternalVCC>>,Radio<RadioSPI,2> > Hal;

Jetzt ist ein device eingerichtet, pairen hat auch funktioniert.
Die Funktionen muss ich erst weiter verstehen, der  Status ist ein großes Fragezeichen.

Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 29 November 2020, 01:08:51
Hallo alle zusammen,
ich habe den Sketch HM-LC-Sw2-FM auf der AskSinPP-Standardhardware ausprobiert.
Das funktioniert hervoragend. Die Relays können im FHEM-Web ein- und ausgeschaltet werden
und lokal kann per Tastendruck der Schaltzustand geändert werden.
Dazu benötigt man lokal einen bzw. zwei Taster.

Nun möchte ich lokal aber gern keine Taster sondern vorhandene Schalter verwenden,
d.h. der Schaltzustand der Relays soll sich jeweils bei der Betätigung des Schalters,
egal ob von Ein nach Aus oder von Aus nach Ein ändern (wie bei einer Wechselschaltung).
d.h. eine Änderung erfolgt bei Änderung des button_pin von low nach high und von high nach low.
Beim obigen Sketch wird bei dauerhaftem low immerzu longpressed gesendet, das sollte natürlich
bei Verwendung eines Schalters nicht sein.

Kennt jemand einen Sketch, mit dem man lokal Schalter verwenden kann oder weiß jemand,
wie man den obigen Sketch für diese Funktion verändern kann. Ein Kanal würde reichen.

Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: tndx am 29 November 2020, 11:26:30
Moin,

es gibt ja von eq-3 HM-SC-3-FM, die Schalterschnittstelle, dazu gibt es auch einen AskSin++-Sketch https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/HM-SCI-3-FM/HM-SCI-3-FM.ino (https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/HM-SCI-3-FM/HM-SCI-3-FM.ino). Vielleicht kannst Du Dir da die Behandlung der Eingänge abgucken
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 30 November 2020, 00:35:36
Zitat von: tndx am 29 November 2020, 11:26:30
Moin,

es gibt ja von eq-3 HM-SC-3-FM, die Schalterschnittstelle, dazu gibt es auch einen AskSin++-Sketch https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/HM-SCI-3-FM/HM-SCI-3-FM.ino (https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/HM-SCI-3-FM/HM-SCI-3-FM.ino). Vielleicht kannst Du Dir da die Behandlung der Eingänge abgucken

Vielen Dank für die Info.
Ich habe den Sketch erst mal so geflashed um eine Vorstellung davon zu haben.
Leider ist es mir nur gelungen, den Status von Sw1 auf open und closed zu ändern indem ich jeweils den Schalter von A0 (Pin14) gegen Masse geschlossen oder geöffnet habe.
SW2 und SW3 konnte ich leider nicht ändern. Ein Schalter wäre ja schon mal gut. Falls Du eine Lösung hast, wie man den Status der anderen SW ändert, wäre das toll.
Bei A1, A2 oder A3 ändert sich nichts, wird laut Arduino Monitor auch kein Telegramm an FHEM gesendet.

Wie ich dann den Teil für die Eingänge in das andere Modul übertragen kann, weiß ich noch nicht. Ich bin in dieser Programmstruktur Neuling und verstehe vieles nicht.
Falls jemand eine Idee hat würde das sehr helfen.
Gruß
Werner


Titel: Antw:AskSin++ Library
Beitrag von: papa am 30 November 2020, 08:46:06
Der Code sieht eigentlich soweit gut aus. Schau doch mal im Homematic-Florum, ob Du da was findest.
https://homematic-forum.de/forum/viewforum.php?f=76
Dort ist auch Jerome sehr aktiv und hilft eigentlich immer gerne.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 30 November 2020, 23:18:08
Hallo papa,
vielen Dank für die Info.
Leider bin ich als Neuling mit der Programmstruktur von AskSinPP nicht vertraut
und verstehe nur wenig, da ich nicht alle Programmmodule in ihrer Bedeutung
nachverfolgen kann. Ein bisschen Kommentar wäre da sicher hilfreich.

Ich will mich aber nicht beschweren und nörgeln, sondern erst einmal allen,
die an AsksinPP und FHEM mitgearbeitet haben und vor allem auch den Nichtfachleuten
umfangreiche Hilfe geben, danken, dass sie ihre Zeit hierfür einsetzen. Das ist sicher
sehr zeitaufwendig und nicht ganz einfach.

Zurück zu meiner Aufgabe.
Da ich nicht alles verstehe, habe ich es jetzt auf die einfache, wenn auch nicht professionelle Art gelöst.
Den Code habe ich unten beigefügt.
Den Taster habe ich durch eine Verbindung eines digitalen Ausgangs zum Tasterpin ersetzt, und steuere diesen abhängig von der Veränderung der Schalterstellung. So funktioniert der Ausgang von Pin 7 wie ein Taster zum ground.
Hier der Code, falls jemand anders das auch mal gebrauchen kann.


//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++  "HM-LC-Sw2-FM-WS-locSwitch-FHEM.ino"
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2020-11-30 McShire modification for use of a switch instead of a button for local change of the actor-relay
//            connect switch to pin 16 (A2) and Ground
//- -----------------------------------------------------------------------------------------------------------------------

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

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Switch.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

//set to 0x01 if the RELAY should be switched on LOW level
#define LOW_ACTIVE 0x00 
#define RELAY1_PIN 5    // modified from A3, on my Experim.board LED2, to see relay state
#define RELAY2_PIN 6    // modified from A2

#define BUTTON1_PIN 14
#define BUTTON2_PIN 15

#define SWITCH1_PIN 9  // inserted McShire
#define BTN_PRESS_PIN 7 // connect Pin 7 to Pin 14, / is eq to press btn

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

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0x12, 0x09, 0x01},     // Device ID
  "JPLCSw2001",           // Device Serial
  {0x00, 0x09},           // Device Model
  0x24,                   // Firmware Version
  as::DeviceType::Switch, // Device Type
  {0x01, 0x00}            // Info Bytes
};

/**
   Configure the used hardware
*/
typedef AvrSPI<10, 11, 12, 13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<RadioSPI, 2> > Hal;

// setup the device with channel type and number of channels
typedef MultiChannelDevice<Hal, SwitchChannel<Hal, PEERS_PER_CHANNEL, List0>, 2> SwitchType;

// inserted by McShire
boolean localon = false;   // state of the Switch, true = on, false = off

Hal hal;
SwitchType sdev(devinfo, 0x20);
ConfigButton<SwitchType> cfgBtn(sdev);
InternalButton<SwitchType> btn1(sdev, 1);
InternalButton<SwitchType> btn2(sdev, 2);

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if ( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    for ( uint8_t i = 1; i <= sdev.channels(); ++i ) {
      Peer ipeer(devid, i);
      sdev.channel(i).peer(ipeer);
    }
  }
}

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY1_PIN, LOW_ACTIVE);
  sdev.channel(2).init(RELAY2_PIN, LOW_ACTIVE);

  buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
  buttonISR(btn1, BUTTON1_PIN);
  buttonISR(btn2, BUTTON2_PIN);

  pinMode(9, INPUT_PULLUP); // inserted by McShire
  pinMode(14, INPUT_PULLUP);
  pinMode(7, OUTPUT);


  sdev.channels(2);
  initPeerings(first);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();

  // The following block was inserted by McShire
  // replace pressbutton by set digitaloutput connected to buttonPin LOW
 
  if (localon == true) {              // switch was already on
     if (digitalRead(9) == LOW) {     // switch is on
         digitalWrite(7,HIGH);       // release button if pressed
     }
     else {                           // switch is off, but was on
         digitalWrite(7,LOW);        // press button, toggle relay
         localon = false;             // Switch state = off
     }
  }
  else    {                           // switch was already off
     if (digitalRead(9) == HIGH) {    // switch is off
        digitalWrite(7,HIGH);        // release button if pressed
     }
     else {                           // switch is on, but was off
         digitalWrite(7,LOW);        // press button, toggle relay
         localon = true;              // Switch state = on
     }
  }
 
  bool poll = sdev.pollRadio();
  if ( worked == false && poll == false ) {
    hal.activity.savePower<Idle<> >(hal);
  }
}


Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 30 November 2020, 23:22:32
Nachtrag:
Im Kommentar steht noch Pin 16, das ist im Code geändert, es muss überall statt Pin 16 jetzt Pin 9 heißen.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 30 November 2020, 23:36:35
Nun kann ich meine vorhandenen Lichtschalter behalten, um das Licht lokal an- und auszuschalten und dahinter preisgünstig selbst gebaute Aktoren zur Steuerung durch FHEM setzen.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Dezember 2020, 08:32:03
Coole Lösung - hat mich direkt auf eine Idee gebracht.
Ich habe die InternalButton-Klasse um eine shortPress() Methode erweitert. Damit kann per Software ein kurzer Tastendruck ausgelöst werden. Das erspart Dir das Verbinden und Schalten des extra Pins. Im Prinzip sollte es reichen, wenn Du bei jedem Wechsel des Schalters ein shortPress() auslöst.

Kannst Du ja mal probieren, wenn Du magst.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 01 Dezember 2020, 11:52:53
Hallo papa
Werde ich gerne probieren.
Aber leider weiß ich nicht, wo ich dazu den Schalter verbinden muss und was ich dazu in FHEM bzw. im Sketch machen muss.
Wie gesagt, ich bin ziemlich unbedarft und freue mich schon, wenn ich in der objektorientierten Programmierung verstehe, was eine Klasse ist.
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Dezember 2020, 12:18:23
 
  if (localon == true) {               // switch was already on
     if (digitalRead(9) == HIGH) { // switch is off
         btn1.shortPress();           // short press for toggle
         localon = false;                // Switch state = off
     }
  }
  else  {                                   // switch was already off
     if (digitalRead(9) == LOW) { // switch is off
         btn1.shortPress();           // short press for toggle
         localon = true;                // Switch state = on
     }
  }


oder sogar noch kürzer

if( localon != digitalRead(9) ) {
  localon = !localon;
  btn1.shortPress();
}


Allerdings darf der Schalter bei beiden Lösungen nicht prellen.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 01 Dezember 2020, 13:06:07
Hallo papa,
Die Kurzform gefällt mir am besten, tolle Lösung.
Wird denn short press im nachfolgendem Programmdurchlauf erkannt?
Ich habe den button pin immer extra einen Programmdurchlauf LOW gehalten.
So langsam beginne ich zu verstehen, es ist auch eine Frage der Vokabeln.
Für das Entprellen hilft sicher vor dem btn1.shortPress() ein kurzes delay(100) o.ä.
Der Schaltzustand bleibt ja bis zum nächsten Umschalten erhalten.
Gruß
Werner
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 01 Dezember 2020, 15:27:14
Zitat von: papa am 01 Dezember 2020, 08:32:03
Coole Lösung - hat mich direkt auf eine Idee gebracht.
Ich habe die InternalButton-Klasse um eine shortPress() Methode erweitert. Damit kann per Software ein kurzer Tastendruck ausgelöst werden. Das erspart Dir das Verbinden und Schalten des extra Pins. Im Prinzip sollte es reichen, wenn Du bei jedem Wechsel des Schalters ein shortPress() auslöst.

Kannst Du ja mal probieren, wenn Du magst.

Wie bekomme ich die erweiterte InternalButton-Class?
In der bestehenden Class ist die Methode nicht enthalten.
Gruß
Werner
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Dezember 2020, 15:36:25
Du musst die AskSin++ Library aktualisieren.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 01 Dezember 2020, 22:50:32
Hallo papa,
ich denke, diese Version ist jetzt Dank Deiner Hilfe gebrauchsfähig.
Es können jetzt jeder der beiden Ausgänge (Aktoren) für sich remote (FHEM) on oder off gesetzt werden,
oder lokal mit Taster oder mit Schalter getoggled werden.
Genau das, was ich gesucht habe, kann in der bestehenden Installation als Ausschalter, Wechselschalter oder Kreuzschalter
hinter den vorhandenen Schaltern oder Tastern eingesetzt werden. Zur Stromversorgung gibt es kleine AC230V / DC3,3V
Converter.
Ich habe hier sehr viel dazu gelernt. Nachdem ich mir in Button.h die Klasse InternalButton und weiter unten die Methode
shortPress () angesehen habe, erübrigt sich die Frage mit dem Programmdurchlauf.

Hier der jetzige Code


//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++  "HM-LC-Sw2-FM-WS-locSwitch-FHEM-v1.ino"
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2020-11-30 McShire modification for use of a switch instead of a button for local change of the actor-relay
//            connect switch to pin 9
// 2020-12-01 papa replace simulation of btn1 on pin 7 and connection pin 7 to pin 14 by a new methode shortPress()
//            in class InternalButton
//- -----------------------------------------------------------------------------------------------------------------------

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

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Switch.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

//set to 0x01 if the RELAY should be switched on LOW level
#define LOW_ACTIVE 0x00
#define RELAY1_PIN 5    // modified from A3, on my Experim.board LED2, to see relay state
#define RELAY2_PIN 6    // modified from A2

#define BUTTON1_PIN 14
#define BUTTON2_PIN 15

#define SWITCH1_PIN 9  // inserted McShire
#define SWITCH2_PIN 7  // Pin 9 und Pin 7 connect to switch, other switch pole to ground

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

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0x12, 0x09, 0x01},     // Device ID
  "JPLCSw2001",           // Device Serial
  {0x00, 0x09},           // Device Model
  0x24,                   // Firmware Version
  as::DeviceType::Switch, // Device Type
  {0x01, 0x00}            // Info Bytes
};

/**
   Configure the used hardware
*/
typedef AvrSPI<10, 11, 12, 13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<RadioSPI, 2> > Hal;

// setup the device with channel type and number of channels
typedef MultiChannelDevice<Hal, SwitchChannel<Hal, PEERS_PER_CHANNEL, List0>, 2> SwitchType;

// inserted by McShire
boolean localon1 = false;   // state of the Switch1, true = on, false = off
boolean localon2 = false;   // state of the Switch2, true = on, false = off


Hal hal;
SwitchType sdev(devinfo, 0x20);
ConfigButton<SwitchType> cfgBtn(sdev);
InternalButton<SwitchType> btn1(sdev, 1);
InternalButton<SwitchType> btn2(sdev, 2);

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if ( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    for ( uint8_t i = 1; i <= sdev.channels(); ++i ) {
      Peer ipeer(devid, i);
      sdev.channel(i).peer(ipeer);
    }
  }
}

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY1_PIN, LOW_ACTIVE);
  sdev.channel(2).init(RELAY2_PIN, LOW_ACTIVE);

  buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
  buttonISR(btn1, BUTTON1_PIN);
  buttonISR(btn2, BUTTON2_PIN);

  pinMode(SWITCH1_PIN, INPUT_PULLUP); // inserted by McShire
  pinMode(SWITCH2_PIN, INPUT_PULLUP); // inserted by McShire

  sdev.channels(2);
  initPeerings(first);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();


// Version v1 Modification created by papa
if( localon1 != digitalRead(SWITCH1_PIN) ) {
  delay(50);                                   //wait because of possible switch bouncing
  localon1 = !localon1;
  btn1.shortPress();
}
if( localon2 != digitalRead(SWITCH2_PIN) ) {
  delay(50);                                   //wait because of possible switch bouncing
  localon2 = !localon2;
  btn2.shortPress();
}

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


Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 Dezember 2020, 13:31:19
Schön das es so gut funktioniert. War ja dann auch nicht wirklich kompliziert.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 04 Dezember 2020, 21:41:43
Hallo papa,
für mich war es schon erstmal kompliziert. Du musst das immer aus
der Brille eines Unkundigen betrachten. Aber so langsam komme ich dahinter.
Bis zum nächsten Projekt.
Ich wünsche ein schönes Wochenende
Werner
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 07 Dezember 2020, 00:55:32
Hallo zusammen,
gibt es für den Asksin-Analyzer auch einen Sketch mit dem 433MHz Protokolle angezeigt werden?
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 19 Dezember 2020, 09:09:56
Guten Morgen,

ich suche nach einem Sketch, bei dem die Ausgänge eine Blinkfrequenz haben und diese, sofern möglich noch von aussen beeinflusst werden kann.

Derzeit nutze ich hierfür ein HM-LC-SW2-SM welcher an den Ausgängen LEDs hat und über MSwitch lasse ich diese blinken. Das führt zu einem Overload an den HMLANs und CUL.

Somit eine schlechte Idee. Wer kann mir einen besseren Tipp geben?

Danke
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 26 Dezember 2020, 04:40:16
Hallo,
noch an einem Blinker interessiert? ich hätte da vielleicht etwas.
Den folgenden Sketch auf eine AskSinPP-Hardware https://asksinpp.de/Grundlagen/01_hardware.html#microcontroller flashen.
Mit autocreate und config-button in FHEM ein device anlegen.
Mit Button1 (Toggle) oder Switch1 (E/A-Schalter) oder in FHEM wird der Blinker ein- bzw. ausgeschaltet (RELAY1).
Die Blinkfrequenz kann mit Button2 (Toggle) oder Switch2 (E/A-Schalter) oder in FHEM eingestellt werden.
Die Einschaltdauer von RELAY2 (mit max begrenzt) stellt die Periodendauer für die Blinkfrequenz ein.
Die LEDs oder ein Relay oder Transistor werden an RELAY3 angeschlossen.
Die Anschlussbelegungen für Taster bzw. Schalter und den Blinkerausgang gehen aus dem Code hervor und können dort verändert werden.


//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++  "HM-LC-Sw2-FM-WS-Blink-v1.ino"
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2020-11-30 McShire modification for use of a switch instead of a button for local change of the actor-relay
//            connect switch to pin 9
// 2020-12-01 papa replace simulation of btn1 on pin 7 and connection pin 7 to pin 14 by a new methode shortPress()
//            in class InternalButton
//- -----------------------------------------------------------------------------------------------------------------------

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

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Switch.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

//set to 0x01 if the RELAY should be switched on LOW level
#define LOW_ACTIVE 0x00
#define RELAY1_PIN 5    // modified from A3 in original
#define RELAY2_PIN 6    // modified from A2

#define BUTTON1_PIN 14  //A0, connect to local button (Toggle Betrieb RELAY1)
#define BUTTON2_PIN 15  //A1, connect to local button (Toggle Betrieb RELAY2)

#define SWITCH1_PIN 9  // inserted McShire, connect to local SWITCH1
#define SWITCH2_PIN 7  // connect to local SWITCH2, switches against ground
#define RELAY3_PIN 17   // A3, blink signal output

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

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0x12, 0x09, 0x01},     // Device ID
  "JPLCSw2001",           // Device Serial
  {0x00, 0x09},           // Device Model
  0x24,                   // Firmware Version
  as::DeviceType::Switch, // Device Type
  {0x01, 0x00}            // Info Bytes
};

/**
   Configure the used hardware
*/
typedef AvrSPI<10, 11, 12, 13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<RadioSPI, 2> > Hal;

// setup the device with channel type and number of channels
typedef MultiChannelDevice<Hal, SwitchChannel<Hal, PEERS_PER_CHANNEL, List0>, 2> SwitchType;

// inserted by McShire
boolean localon1 = false;   // prior state of Switch1, true = on, false = off
boolean localon2 = false;   // prior state of Switch2, true = on, false = off
int peri_max = 10;         // predefined number of loops for blink/no blink time
int peri_count = 0;         // counter for actual number of loops
int peri_set = 0;           // Counter for setting peri_max using SWITCH2
int peri_set_max = 5000; // Limit for peri_max
boolean blink = LOW;
boolean rel_old = LOW;

Hal hal;
SwitchType sdev(devinfo, 0x20);
ConfigButton<SwitchType> cfgBtn(sdev);
InternalButton<SwitchType> btn1(sdev, 1);
InternalButton<SwitchType> btn2(sdev, 2);

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if ( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    for ( uint8_t i = 1; i <= sdev.channels(); ++i ) {
      Peer ipeer(devid, i);
      sdev.channel(i).peer(ipeer);
    }
  }
}

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY1_PIN, LOW_ACTIVE);
  sdev.channel(2).init(RELAY2_PIN, LOW_ACTIVE);

  buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
  buttonISR(btn1, BUTTON1_PIN);
  buttonISR(btn2, BUTTON2_PIN);

  pinMode(SWITCH1_PIN, INPUT_PULLUP); // inserted by McShire
  pinMode(SWITCH2_PIN, INPUT_PULLUP); // inserted by McShire
  pinMode(RELAY3_PIN, OUTPUT);

  digitalWrite(RELAY1_PIN,LOW);
  digitalWrite(RELAY2_PIN,LOW);
  digitalWrite(RELAY3_PIN,LOW);

  sdev.channels(2);
  initPeerings(first);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();


// Version v1 Modification created by papa
if( localon1 != digitalRead(SWITCH1_PIN) ) {   //state of switch1 has changed?
  delay(50);                                   //wait because of possible switch bouncing
  localon1 = !localon1;                        //save new state of switch1
  btn1.shortPress();                           //generate virtual press Button (Toggle Relay1
                                               //and send Msg to FHEM)
}
if( localon2 != digitalRead(SWITCH2_PIN) ) {   //state of switch2 has changed?
  delay(50);                                   //wait because of possible switch bouncing
  localon2 = !localon2;                        //save new state of switch2
  btn2.shortPress();                           //generate virtual press Button (Toggle Relay2
                                               //and send Msg to FHEM)
}

Serial.print(digitalRead(RELAY3_PIN));
Serial.print("   "); Serial.print(peri_count); Serial.print("   ");
Serial.println(peri_max);
if( digitalRead(RELAY1_PIN) == HIGH ) { //Blink is set on
  peri_count++;
  if( peri_count >= peri_max ) {
    blink = !blink;
    digitalWrite(RELAY3_PIN,blink);
    peri_count = 0;
  }
}
else {
  blink = LOW;
  digitalWrite(RELAY3_PIN,blink) ;
}

if( digitalRead(RELAY2_PIN) == HIGH) {  // set new duration of blink / no blink time
  if (rel_old == LOW) peri_set = 0;
  if (peri_set <= peri_set_max) {
    peri_set++;
  }
}
else {
  peri_max = peri_set;
}
rel_old = digitalRead(RELAY2_PIN);

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


Viel Spass und Erfolg und frohe Weihnachten.
Werner
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 26 Dezember 2020, 15:24:47
Hallo Werner,

vielen Dank für das Beispiel.
Ich werde dieses in den nächsten Tagen probieren und Dir eine Rückmeldung geben.

Danke erst einmal und einen schönen 2. Weihnachtstag.

Bleib gesund.

Gruss

Ralf
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 26 Dezember 2020, 20:33:30
Hallo Ralf,
die Blinkfrequenz lässt sich besser steuern, wenn Du unten die Zeile
  peri_max = peri_set;
ersetzt durch
  peri_max = peri_set/5;
ersetzt.
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 27 Dezember 2020, 19:22:48
Hallo Ralf,
Update auf bessere Anfangsbedingungen

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++  "HM-LC-Sw2-FM-WS-Blink-v1.ino"
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2020-11-30 McShire modification for use of a switch instead of a button for local change of the actor-relay
//            connect switch to pin 9
// 2020-12-01 papa replace simulation of btn1 on pin 7 and connection pin 7 to pin 14 by a new methode shortPress()
//            in class InternalButton
// 2020-12-27 McShire new funktion blink output at RELAY3 output, on/off controlled bei RELAY1 state,
//            blink frequency set by on-time RELAY2
//- -----------------------------------------------------------------------------------------------------------------------

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

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Switch.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

//set to 0x01 if the RELAY should be switched on LOW level
#define LOW_ACTIVE 0x00
#define RELAY1_PIN 16    //  A2
#define RELAY2_PIN 17    //  A3

#define BUTTON1_PIN 14  //A0, connect to local button (Toggle Betrieb RELAY1)
#define BUTTON2_PIN 15  //A1, connect to local button (Toggle Betrieb RELAY2)

#define SWITCH1_PIN 9  // inserted McShire, connect to local SWITCH1
#define SWITCH2_PIN 7  // connect to local SWITCH2, switches against ground
#define RELAY3_PIN 6   // blink signal output

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

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0x12, 0x09, 0x01},     // Device ID
  "JPLCSw2001",           // Device Serial
  {0x00, 0x09},           // Device Model
  0x24,                   // Firmware Version
  as::DeviceType::Switch, // Device Type
  {0x01, 0x00}            // Info Bytes
};

/**
   Configure the used hardware
*/
typedef AvrSPI<10, 11, 12, 13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<RadioSPI, 2> > Hal;

// setup the device with channel type and number of channels
typedef MultiChannelDevice<Hal, SwitchChannel<Hal, PEERS_PER_CHANNEL, List0>, 2> SwitchType;

// inserted by McShire
boolean localon1 = false;   // prior state of Switch1, true = on, false = off
boolean localon2 = false;   // prior state of Switch2, true = on, false = off
int peri_max = 50;         // predefined number of loops for blink/no blink time
int peri_count = 1;         // counter for actual number of loops
int peri_set = 50;           // Counter for setting peri_max using SWITCH2
int peri_set_max = 5000; // Limit for peri_max
boolean blink = LOW;
boolean rel_old = LOW;

Hal hal;
SwitchType sdev(devinfo, 0x20);
ConfigButton<SwitchType> cfgBtn(sdev);
InternalButton<SwitchType> btn1(sdev, 1);
InternalButton<SwitchType> btn2(sdev, 2);

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if ( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    for ( uint8_t i = 1; i <= sdev.channels(); ++i ) {
      Peer ipeer(devid, i);
      sdev.channel(i).peer(ipeer);
    }
  }
}

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY1_PIN, LOW_ACTIVE);
  sdev.channel(2).init(RELAY2_PIN, LOW_ACTIVE);

  buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
  buttonISR(btn1, BUTTON1_PIN);
  buttonISR(btn2, BUTTON2_PIN);

  pinMode(SWITCH1_PIN, INPUT_PULLUP); // inserted by McShire
  pinMode(SWITCH2_PIN, INPUT_PULLUP); // inserted by McShire
  pinMode(RELAY3_PIN, OUTPUT);
  sdev.channels(2);
  initPeerings(first);
  sdev.initDone();

  digitalWrite(RELAY3_PIN,LOW);
  btn1.shortPress();
  btn2.shortPress();
}

void loop() {
  bool worked = hal.runready();


// Version v1 Modification created by papa
if( localon1 != digitalRead(SWITCH1_PIN) ) {   //state of switch1 has changed?
  delay(50);                                   //wait because of possible switch bouncing
  localon1 = !localon1;                        //save new state of switch1
  btn1.shortPress();                           //generate virtual press Button (Toggle Relay1
                                               //and send Msg to FHEM)
}
if( localon2 != digitalRead(SWITCH2_PIN) ) {   //state of switch2 has changed?
  delay(50);                                   //wait because of possible switch bouncing
  localon2 = !localon2;                        //save new state of switch2
  btn2.shortPress();                           //generate virtual press Button (Toggle Relay2
                                               //and send Msg to FHEM)
}

Serial.print(digitalRead(RELAY3_PIN));
Serial.print("   "); Serial.print(peri_count); Serial.print("   ");
Serial.print(peri_max); Serial.print("   "); Serial.println(peri_set);
if( digitalRead(RELAY1_PIN) == HIGH ) { //Blink is set on
  peri_count++;
  if( peri_count >= peri_max ) {
    blink = !blink;
    digitalWrite(RELAY3_PIN,blink);
    peri_count = 0;
  }
}
else {
  blink = LOW;
  digitalWrite(RELAY3_PIN,blink) ;
}

if( digitalRead(RELAY2_PIN) == HIGH) {  // set new duration of blink / no blink time
  if (rel_old == LOW) peri_set = 0;
  if (peri_set <= peri_set_max) {
    peri_set++;
  }
}
else {
  peri_max = peri_set/5;
}
rel_old = digitalRead(RELAY2_PIN);

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

viele Grüße
Werner

Titel: Antw:AskSin++ Library
Beitrag von: McShire am 27 Dezember 2020, 20:07:48
die devices dazu in FHEM sind:

Internals:
   CUL868T_MSGCNT 675
   CUL868T_RAWMSG A0E1A86101209010000000602000000::-71:CUL868T
   CUL868T_RSSI -71
   CUL868T_TIME 2020-12-27 19:29:30
   DEF        120901
   FUUID      5fc424c1-f33f-f21b-d69b-86c14c2f70c649b8
   IODev      CUL868T
   LASTInputDev CUL868T
   MSGCNT     675
   NAME       HM_120901
   NOTIFYDEV  global
   NR         836
   NTFY_ORDER 50-HM_120901
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_120901_Sw_01
   channel_02 HM_120901_Sw_02
   lastMsg    No:1A - t:10 s:120901 d:000000 0602000000
   protCmdDel 5
   protLastRcv 2020-12-27 19:29:30
   protRcv    675 last_at:2020-12-27 19:29:30
   protResnd  16 last_at:2020-12-26 22:31:47
   protResndFail 4 last_at:2020-12-26 22:31:53
   protSnd    43 last_at:2020-12-27 18:19:54
   protState  CMDs_done
   rssi_CUL868T cnt:39 min:-79 max:-59 avg:-69.25 lst:-61
   rssi_at_CUL868T cnt:675 min:-85 max:-57.5 avg:-68.48 lst:-71
   rssi_broadcast cnt:257 min:-89 max:-51 avg:-70.96 lst:-78
   READINGS:
     2020-12-27 18:19:48   D-firmware      2.4
     2020-12-27 18:19:48   D-serialNr      JPLCSw2001
     2020-12-01 21:59:01   PairedTo        0x000000
     2020-12-01 21:59:01   RegL_00.        00:00 02:01 0A:00 0B:00 0C:00
     2020-12-01 21:59:01   cfgState        updating
     2020-12-27 18:19:54   commState       CMDs_done
     2020-12-01 21:58:46   powerOn         2020-12-01 21:58:46
     2020-12-27 18:19:54   state           CMDs_done
   helper:
     HM_CMDNR   26
     cSnd       112802471209010202000000,01280247120901010E
     mId        00CB
     peerFriend
     peerOpt    -:switch
     regLst     0
     rxType     1
     supp_Pair_Rep 0
     cmds:
       TmplKey    :no:1609089593.41341
       TmplTs     1609089593.41341
       cmdKey     0:1:0::HM_120901:00CB:00:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
         getVersion noArg
         pair       noArg
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplDel     
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       newChn     +120901,00,00,00
       nextSend   1609093770.73532
       prefIO     
       rxt        0
       vccu       
       p:
         120901
         00
         00
         00
     mRssi:
       mNo        1A
       io:
         CUL868T:
           -69
           -69
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       CUL868T:
         avg        -69.2564102564103
         cnt        39
         lst        -61
         max        -59
         min        -79
       at_CUL868T:
         avg        -68.4851851851851
         cnt        675
         lst        -71
         max        -57.5
         min        -85
       broadcast:
         avg        -70.9688715953308
         cnt        257
         lst        -78
         max        -51
         min        -89
     tmpl:
Attributes:
   IODev      CUL868T
   alias      HM-LC-Sw2-FM-WS-locSwitch-FHEM-v1 (HM_120901)
   autoReadReg 4_reqStatus
   comment    Sketchbook\HM-LC-Sw2-WS-locSwitch-FHEM-v1\HM-LC-Sw2-FM-WS-locSwitch-FHEM-v1.ino
Ein Funk-Schaltaktor (2-Relais), der hinter einem Lichtschalter
verwendet werden kann. Die Relais können remote mit FHEM ein- und ausgeschaltet werden und lokal durch Lichtschalter oder Taster. Die Lichtschalter müssen dabei den Pin 9 bzw.Pin7 nach Masse schalten und damit die Relais für das Licht ein und ausschalten.

   expert     rawReg
   firmware   2.4
   model      HM-LC-SW2-FM
   room       CUL_HM,Schalter,Test
   serialNr   JPLCSw2001
   subType    switch
   webCmd     getConfig:clear msgEvents


und die Kanäle

Internals:
   DEF        12090101
   FUUID      5fc424c1-f33f-f21b-096b-ac03015cdf8fa191
   NAME       HM_120901_Sw_01
   NOTIFYDEV  global
   NR         838
   NTFY_ORDER 50-HM_120901_Sw_01
   STATE      on
   TYPE       CUL_HM
   chanNo     01
   device     HM_120901
   peerList   self01,
   READINGS:
     2020-12-27 14:36:55   CommandAccepted yes
     2020-12-01 21:59:07   RegL_01.        00:00 08:00 30:06 56:00 57:24
     2020-12-01 21:59:17   RegL_03.self01  00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:01 8B:14 8C:63
     2020-12-01 21:59:01   cfgState        updating
     2020-12-27 19:28:44   deviceMsg       on (to broadcast)
     2020-12-27 19:28:44   level           100
     2020-12-27 19:28:44   pct             100
     2020-12-23 20:38:29   peerList        self01,
     2020-12-27 19:28:44   recentStateType info
     2020-12-27 19:28:44   state           on
     2020-12-27 19:28:44   timedOn         off
     2020-12-27 14:36:55   trigLast        fhem:02
   helper:
     peerFriend peerSens,peerVirt
     peerOpt    3:switch
     regLst     1,3p
     cmds:
       TmplKey    self01,:no:1609089593.41004
       TmplTs     1609089593.41004
       cmdKey     1:0:0::HM_120901:00CB:01:self01,
       cmdLst:
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         eventL     -peer- -cond-
         eventS     -peer- -cond-
         getConfig  noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
         inhibit    [(on|{off})]
         off        noArg
         on         noArg
         on-for-timer -ontime-
         on-till    -time-
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerIODev  [IO] -btn- [({set}|unset)] 'not for future use'
         peerSmart  -peerOpt-
         press      [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{self01})]
         pressS     [(-peer-|{self01})]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         sign       [(on|{off})]
         statusRequest noArg
         toggle     noArg
         tplDel     -tplDel-
       lst:
         condition  slider,0,1,255
         peer       self01
         peerOpt    HM_001A00,HM_075F02_Sw_01,HM_075F02_Sw_02,HM_075F02_Sw_03,HM_6B5B22,HM_6B5CAD,HM_6B5D88,HM_6B5DDC,HM_6B5DE9,HM_6B5E1A,HM_6B5E1D,HM_6B5E2A,HM_6B9B29,HM_6B9B30,HM_6B9B51,HM_6C1515,HM_789012_Btn_01,HM_789012_Btn_02,HM_789012_Btn_03,HM_789012_Btn_04,HM_789015_Btn_01,HM_789015_Btn_02,HM_789015_Btn_03,HM_789015_Btn_04,Virtual_HM_Dummy_Btn1,Virtual_HM_Dummy_Btn2,Virtual_HM_Dummy_Btn3,Virtual_HM_Dummy_Btn4,Virtual_HM_Dummy_Btn5,Virtual_HM_Dummy_Btn6,Virtual_HM_Dummy_Btn7,Virtual_HM_Dummy_Btn8
         tplDel     
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   comment    Ein Funk-Schaltaktor (Relais), der hinter einem Lichtschalter
verwendet werden kann. Das Relais kann remote mit FHEM ein- und ausgeschaltet werden und lokal durch den Lichtschalter. Der Lichtschalter muss dabei den Pin 9 nach Masse schalten und das Relais das Licht ein und ausschalten.
Ist ein Kanal von HM_120901 (Sketchbook\HM-LC-Sw2-FM-WS-locSwitch-FHEM-v1\HM-LC-Sw2-FM-WS-locSwitch-FHEM-v1.ino
   model      HM-LC-SW2-FM
   peerIDs    00000000,12090101,
   room       Schalter,Test
   webCmd     statusRequest:toggle:on:off


viel Spass und Erfolg.
Gruß
Werner

Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 28 Dezember 2020, 14:46:42
@papa
ich möchte für meine Version des Wassermelders (mit ADC Messung, Platine ist fertig und im Teststadium)
https://github.com/TomMajor/SmartHome/blob/master/HB-SEC-WDS-2/Arduino/HB-SEC-WDS-2.ino (https://github.com/TomMajor/SmartHome/blob/master/HB-SEC-WDS-2/Arduino/HB-SEC-WDS-2.ino)
eine per user define umschaltbare Version machen, die dann nicht mehr genau das Originalgerät für die Zentrale abbildet sondern 2 Byte extra Daten für die Batt.spannung in mV ähnlich dem HB-UNI-Sensor1 in der CCU darstellt.
Die xml Seite auf der CCU bekomme ich vermutlich hin, aber wie mache ich das am Elegantesten in der AskSinPP?

ich habe hier bei dir was entdeckt was mir vielleicht in der Richtung helfen würde (patchStatus)
https://github.com/pa-pa/AskSinPP/blob/master/ContactState.h#L136-L141 (https://github.com/pa-pa/AskSinPP/blob/master/ContactState.h#L136-L141)

Könnten wir in StateGenericChannel z.B. 2 zusätzliche Methoden machen

setExtraDataSize(uint8_t size)
updateExtraData(uint8_t size, uint8_t* data)


Dabei soll setExtraDataSize(uint8_t size) der Klasse *permanent* mitteilen dass bei jedem Senden immer size Bytes hinten anzufügen sind.
updateExtraData() macht dann bei Bedarf das Update vor dem Senden.
Wäre das ein brauchbares Konzept? Soll ich einen PR dafür machen?

Danke,
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Dezember 2020, 19:42:05
Das wären dann 2 zusätziche virtuelle Methoden, die zusätzlich Platz im RAM brauchen. Das würde ich wenn möglich verhindern wollen. Warum geht die patchStatus-Lösung nicht ?
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 28 Dezember 2020, 20:48:54
Zitat von: papa am 28 Dezember 2020, 19:42:05
Das wären dann 2 zusätziche virtuelle Methoden, die zusätzlich Platz im RAM brauchen. Das würde ich wenn möglich verhindern wollen. Warum geht die patchStatus-Lösung nicht ?

Das verstehe ich natürlich mit dem zusätzlichen Platz für diesen Spezialfall.
Aber dann könnten wir das doch mit einem #ifdef lösen so wie du jetzt bei CONTACT_STATE_WITH_BATTERY ? Das könnte ich ja alles erst mal lokal vorbereiten und testen ob es überhaupt das gewünschte Resultat liefert.

Und ich brauche eine universelle Methode für append custom data mit ggf. mehren Bytes, nicht fest auf battery().current().

Finde auch kein Bsp. zur Verwendung von patchStatus() aus einem Sketch heraus und verstehe es nicht wirklich. Mein Problem ist ja das der Wassermelder keinen direkten Zugriff auf die msg hat, aber patchStatus erwartet die msg als Parameter.

Wie müsste der Code in der Klasse StateGenericChannel aussehen, um 2 Byte anzuhängen, das ist mir ein Rätsel:

updateExtraData(uint8_t size, uint8_t* data) {
  for (uint8_t i = 0; i < size; i++) {
    // append data[i] to send msg, aber wie ??
  }
}
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Dezember 2020, 23:23:28
patchStatus wird immer vom Device aufgerufen, wenn der Gerätestatus gesendet wird

https://github.com/pa-pa/AskSinPP/blob/ca9518b5b70d7b95daeede0f2c5053a98db8e0f7/Device.h#L357
https://github.com/pa-pa/AskSinPP/blob/ca9518b5b70d7b95daeede0f2c5053a98db8e0f7/Device.h#L391

Du kannst diese Method in "Deinen" Channel überschreiben und dort anhängen, was immer Du willst. Die Message wird vom Device vorher initialisiert.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Dezember 2020, 23:43:26
Man könnte aber auch die Sensor-Klasse (erstes Templateargument im StateGenericChannel) um eine weitere Methode erweitern, diese kriegt dann die Message und kann extra Daten anhängen. Alle bestehenden Sensoren kriegen eine leere Implementierung - dann ist das auch schön rückwärts kompatibel.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 28 Dezember 2020, 23:44:09
Zitat von: papa am 28 Dezember 2020, 23:23:28
patchStatus wird immer vom Device aufgerufen, wenn der Gerätestatus gesendet wird

https://github.com/pa-pa/AskSinPP/blob/ca9518b5b70d7b95daeede0f2c5053a98db8e0f7/Device.h#L357
https://github.com/pa-pa/AskSinPP/blob/ca9518b5b70d7b95daeede0f2c5053a98db8e0f7/Device.h#L391

Du kannst diese Method in "Deinen" Channel überschreiben und dort anhängen, was immer Du willst. Die Message wird vom Device vorher initialisiert.

Oh Mann, wieder mal den Wald vor lauter Bäumen nicht gesehen, ich dachte ich muss patchStatus aufrufen, ans Überschreiben wieder mal nicht gedacht  ::)
Dann sollte es in etwa so gehen wenn dein #define aktiv ist ?

// --------------------------------------------------------
template <class HALTYPE, class List0Type, class List1Type, class List4Type, int PEERCOUNT>
class ADCThreeStateChannel : public ThreeStateGenericChannel<ADCPosition, HALTYPE, List0Type, List1Type, List4Type, PEERCOUNT> {
public:
    typedef ThreeStateGenericChannel<ADCPosition, HALTYPE, List0Type, List1Type, List4Type, PEERCOUNT> BaseChannel;

    ADCThreeStateChannel()
        : BaseChannel() {};
    ~ADCThreeStateChannel() {}

    void init(uint8_t adcpin1, uint8_t adcpin2)
    {
        BaseChannel::init();
        BaseChannel::possens.init(adcpin1, adcpin2);
    }
   
    // append custom data to status message
    uint16_t myValue = 0x1234;
    void patchStatus (Message& msg) {
        msg.append(myValue);
    }
};


ich habe gesehen, du hast bereits msg.append() mit jeder Menge sinnvollen Parameter Kominationen überladen.

Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Dezember 2020, 23:50:16
Wenn das reicht - es müsste aber hier

https://github.com/pa-pa/AskSinPP/blob/ca9518b5b70d7b95daeede0f2c5053a98db8e0f7/ContactState.h#L32

noch der #ifdef Block durch einen Aufruf

channel.patchStatus(msg);

ausgetauscht werden, damit das auch bei der normalen SensorMsg mit dran steht.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 29 Dezember 2020, 00:14:30
Danke, so langsam wird es klarer.

patchStatus() in Zeile 137 kommt also beim Gerätestatus senden zum Zug und Zeile 33 bei einer Sensor Nachricht senden.

Dann wäre es eigentlich besser du machst in #33 das
channel.patchStatus(msg);
standardmäßig rein, oder?
Dann wäre CONTACT_STATE_WITH_BATTERY ja schon eine Art universelles APPEND_CUSTOM_DATA define.

ich teste das die nächsten Tage. Danke.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 Dezember 2020, 00:53:07
Zitat von: Tom Major am 29 Dezember 2020, 00:14:30
Danke, so langsam wird es klarer.

patchStatus() in Zeile 137 kommt also beim Gerätestatus senden zum Zug und Zeile 33 bei einer Sensor Nachricht senden.

Dann wäre es eigentlich besser du machst in #33 das
channel.patchStatus(msg);
standardmäßig rein, oder?
Dann wäre CONTACT_STATE_WITH_BATTERY ja schon eine Art universelles APPEND_CUSTOM_DATA define.

ich teste das die nächsten Tage. Danke.
#33 - ja kann ich machen - wenn es erfolgreich bei Dir läuft.

Das Define brauche ich nur, damit ich im RHS-3 Sketch den Channel nicht nochmal ableiten muss.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 29 Dezember 2020, 01:43:26
Zitat von: papa am 01 Dezember 2020, 08:32:03
Coole Lösung - hat mich direkt auf eine Idee gebracht.
Ich habe die InternalButton-Klasse um eine shortPress() Methode erweitert. Damit kann per Software ein kurzer Tastendruck ausgelöst werden. Das erspart Dir das Verbinden und Schalten des extra Pins. Im Prinzip sollte es reichen, wenn Du bei jedem Wechsel des Schalters ein shortPress() auslöst.

Kannst Du ja mal probieren, wenn Du magst.

Hallo papa,
ich wollte meine Projekte von ArduinoIDE nach PlatformIO umziehen.
Mit der neuen Methode shortPress() gibt das ein Problem.
In Arduino funktioniert das Kompilieren einwandfrei.
in platformIO gibt es für die Methode immer folgende Fehlermeldungen:


C:/Users/werne/Documents/PlatformIO/Projects/201229-010003-pro8MHzatmega328/src/HM-LC-Sw2-FM-WS-Blink-v1.ino:116:8: error: 'class as::InternalButton<as::MultiChannelDevice<as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >, as::SwitchChannel<as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >, 8, as::List0>, 2> >' has no member named 'shortPress'
   btn1.shortPress();
        ^
C:/Users/werne/Documents/PlatformIO/Projects/201229-010003-pro8MHzatmega328/src/HM-LC-Sw2-FM-WS-Blink-v1.ino:117:8: error: 'class as::InternalButton<as::MultiChannelDevice<as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >, as::SwitchChannel<as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >, 8, as::List0>, 2> >' has no member named 'shortPress'
   btn2.shortPress();
        ^
C:/Users/werne/Documents/PlatformIO/Projects/201229-010003-pro8MHzatmega328/src/HM-LC-Sw2-FM-WS-Blink-v1.ino: In function 'void loop()':       
Archiving .pio\build\pro8MHzatmega328\libFrameworkArduinoVariant.a
C:/Users/werne/Documents/PlatformIO/Projects/201229-010003-pro8MHzatmega328/src/HM-LC-Sw2-FM-WS-Blink-v1.ino:128:8: error: 'class as::InternalButton<as::MultiChannelDevice<as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >, as::SwitchChannel<as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >, 8, as::List0>, 2> >' has no member named 'shortPress'
   btn1.shortPress();                           //generate virtual press Button (Toggle Relay1
        ^
C:/Users/werne/Documents/PlatformIO/Projects/201229-010003-pro8MHzatmega328/src/HM-LC-Sw2-FM-WS-Blink-v1.ino:134:8: error: 'class as::InternalButton<as::MultiChannelDevice<as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >, as::SwitchChannel<as::AskSin<as::StatusLed<4u>, as::NoBattery, as::Radio<as::AvrSPI<10u, 11u, 12u, 13u>, 2u> >, 8, as::List0>, 2> >' has no member named 'shortPress'
   btn2.shortPress();                           //generate virtual press Button (Toggle Relay2
        ^
*** [.pio\build\pro8MHzatmega328\src\HM-LC-Sw2-FM-WS-Blink-v1.ino.cpp.o] Error 1


Wie kann ich da Abhilfe schaffen?

Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 Dezember 2020, 09:03:46
Zitat von: McShire am 29 Dezember 2020, 01:43:26
Wie kann ich da Abhilfe schaffen?
Ist die Library die Letzte vom GitHub ?
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 29 Dezember 2020, 09:14:39
Hallo papa,
Ich habe die Library importiert, die ich in der ArduinoIDE verwendet habe.
Die hatte ich aktualisiert, nachdem du die neue Methode eingefügt hast.
Aber ich schau heute abend, ob sich vielleicht etwas von de alten Version eingeschlichen hat.
Gruß
Werner
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 29 Dezember 2020, 11:56:29
Zitat von: papa am 29 Dezember 2020, 00:53:07
#33 - ja kann ich machen - wenn es erfolgreich bei Dir läuft.

Das Define brauche ich nur, damit ich im RHS-3 Sketch den Channel nicht nochmal ableiten muss.

Alles klar ich melde mich wenn es soweit ist.

Kurze Zusatzfrage, ich verwende ja noch
ThreeStateGenericChannel / ThreeStateDevice
(am Anfang von AskSinPP war das wohl so)

ich sehe in ContactState.h Kommentare "alias for old code"
Kann ich ThreeStateGenericChannel durch StateGenericChannel und
ThreeStateDevice durch StateDevice ohne weitere Anpassungen ersetzen?

Danke,
Titel: Antw:AskSin++ Library
Beitrag von: papa am 29 Dezember 2020, 13:45:04
Ja - sollte das selbe sein.
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 29 Dezember 2020, 21:54:30
Zitat von: McShire am 27 Dezember 2020, 19:22:48
Hallo Ralf,
Update auf bessere Anfangsbedingungen

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++  "HM-LC-Sw2-FM-WS-Blink-v1.ino"
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2020-11-30 McShire modification for use of a switch instead of a button for local change of the actor-relay
//            connect switch to pin 9
// 2020-12-01 papa replace simulation of btn1 on pin 7 and connection pin 7 to pin 14 by a new methode shortPress()
//            in class InternalButton
// 2020-12-27 McShire new funktion blink output at RELAY3 output, on/off controlled bei RELAY1 state,
//            blink frequency set by on-time RELAY2
//- -----------------------------------------------------------------------------------------------------------------------


viele Grüße
Werner



Hallo Werner,

ich habe den Sketch probiert. Ich mache sicherlich etwas falsch. Das blinken bekomme ich nicht abgeschaltet.
Sie blinkt immer.

Hast Du einen Tipp für mich?

Gruss
Ralf
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 30 Dezember 2020, 16:46:52
Zitat von: papa am 29 Dezember 2020, 13:45:04
Ja - sollte das selbe sein.

Alles klar, Danke.

Wenn es beim Wassermelder keine Statusänderung bzgl. Wasser/Trocken gibt sendet er ja trotzdem in Abständen eine Statusnachricht.
Wo wird eigentlich das Interval dieser Statusnachricht festgelegt, wird das vom Batteriemessungs-Interval abgeleitet?
https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-SEC-WDS/HM-SEC-WDS.ino#L91 (https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-SEC-WDS/HM-SEC-WDS.ino#L91)
Oder gibt es da einen AskSinPP internen Default?

Ich sehe sonst nichts dazu im Sketch, nur noch cycleInfoMsg(false) in List0
https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-SEC-WDS/HM-SEC-WDS.ino#L59 (https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-SEC-WDS/HM-SEC-WDS.ino#L59)
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 01 Januar 2021, 11:38:43
Zitat von: Beetle2003 am 29 Dezember 2020, 21:54:30
Hallo Werner,

ich habe den Sketch probiert. Ich mache sicherlich etwas falsch. Das blinken bekomme ich nicht abgeschaltet.
Sie blinkt immer.

Hast Du einen Tipp für mich?

Gruss
Ralf

Hallo Ralf,
hast Du in FHEM das device HM_120901 und die zugehörigen Kanäle HM_120901_Sw_01 und HM_120901_Sw_02
angelegt?
Kannst Du dann den den Kanal HM_120901_Sw_01 in FHEM ausschalten (set HM_120901_SW_01 off), dann müsste auch der Ausgang RELAY1 LOW (0V)
sein und bei set HM_120901_SW_01 on müsste der Ausgang RELAY1 HIGH sein.
Mit Taster button1 sollte der Ausgang bei jedem Drücken wechseln.
Bitte mal probieren, des gleichen für HM_120901_SW_02, RELAY2 und button2.
schick mal das Ergebnis und ein list von HM_120901_SW_01.

Ein frohes neues Jahr
Werner
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Januar 2021, 12:15:14
Zitat von: Tom Major am 30 Dezember 2020, 16:46:52
Wenn es beim Wassermelder keine Statusänderung bzgl. Wasser/Trocken gibt sendet er ja trotzdem in Abständen eine Statusnachricht.
Wo wird eigentlich das Interval dieser Statusnachricht festgelegt, wird das vom Batteriemessungs-Interval abgeleitet?
https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-SEC-WDS/HM-SEC-WDS.ino#L91 (https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-SEC-WDS/HM-SEC-WDS.ino#L91)
Ist das letzt Template-Argument
https://github.com/pa-pa/AskSinPP/blob/ca9518b5b70d7b95daeede0f2c5053a98db8e0f7/ContactState.h#L202
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 01 Januar 2021, 18:04:16
Zitat von: papa am 01 Januar 2021, 12:15:14
Ist das letzt Template-Argument
https://github.com/pa-pa/AskSinPP/blob/ca9518b5b70d7b95daeede0f2c5053a98db8e0f7/ContactState.h#L202

Zunächst erst mal ein Gesundes Neues Jahr an alle AskSin++ Mitleser.

Danke, aber was mache ich falsch um CycleTime zu ändern?
Wenn du schreibst es ist das letzte Template-Argument habe ich es in meiner Naivität einfach hinten drangeschrieben, das mag er aber leider nicht:

...
typedef ADCThreeStateChannel<HalType, WDSList0, WDSList1, DefList4, PEERS_PER_CHANNEL> ChannelType;

#define CYCLETIME seconds2ticks(60ul*60*12) // two messages per day
class DevType : public StateDevice<HalType, ChannelType, 1, WDSList0, CYCLETIME> {
public:
    typedef StateDevice<HalType, ChannelType, 1, WDSList0> TSDevice;
    DevType(const DeviceInfo& info, uint16_t addr)
        : TSDevice(info, addr)
    {
    }
    virtual ~DevType() {}

    virtual void configChanged()
...



Compiling sketch...
"C:\\Users\\user7\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-g++" -c -g -Os -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=10813 -DARDUINO_AVR_PRO -DARDUINO_ARCH_AVR "-IC:\\Users\\user7\\AppData\\Local\\Arduino15\\packages\\arduino\\hardware\\avr\\1.8.3\\cores\\arduino" "-IC:\\Users\\user7\\AppData\\Local\\Arduino15\\packages\\arduino\\hardware\\avr\\1.8.3\\variants\\eightanaloginputs" "-Ie:\\_user7\\Documents\\Arduino\\libraries\\EnableInterrupt" "-Ie:\\_user7\\Documents\\Arduino\\libraries\\AskSinPP" "-Ie:\\_user7\\Documents\\Arduino\\libraries\\Low-Power" "b:\\Temp\\arduino_build_163631\\sketch\\HB-SEC-WDS-2.ino.cpp" -o "b:\\Temp\\arduino_build_163631\\sketch\\HB-SEC-WDS-2.ino.cpp.o"
e:\_user7\Documents\Arduino\_HomeMatic_Devices\HB-SEC-WDS-2\HB-SEC-WDS-2.ino: In constructor 'DevType::DevType(const as::DeviceInfo&, uint16_t)':
HB-SEC-WDS-2:276:11: error: type 'as::StateDevice<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, ADCThreeStateChannel<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, WDSList0, WDSList1, as::RegList4<as::DefaultRegisterList4>, 6>, 1, WDSList0>' is not a direct base of 'DevType'
         : TSDevice(info, addr)
           ^~~~~~~~
HB-SEC-WDS-2:276:30: error: no matching function for call to 'as::StateDevice<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, ADCThreeStateChannel<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, WDSList0, WDSList1, as::RegList4<as::DefaultRegisterList4>, 6>, 1, WDSList0, 4320000>::StateDevice()'
         : TSDevice(info, addr)
                              ^
In file included from e:\_user7\Documents\Arduino\_HomeMatic_Devices\HB-SEC-WDS-2\HB-SEC-WDS-2.ino:33:0:
e:\_user7\Documents\Arduino\libraries\AskSinPP/ContactState.h:224:3: note: candidate: as::StateDevice<HalType, ChannelType, ChannelCount, List0Type, CycleTime>::StateDevice(const as::DeviceInfo&, uint16_t) [with HalType = as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >; ChannelType = ADCThreeStateChannel<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, WDSList0, WDSList1, as::RegList4<as::DefaultRegisterList4>, 6>; int ChannelCount = 1; List0Type = WDSList0; long unsigned int CycleTime = 4320000; uint16_t = unsigned int]
   StateDevice(const DeviceInfo& info,uint16_t addr) : DevType(info,addr), cycle(*this) {}
   ^~~~~~~~~~~
e:\_user7\Documents\Arduino\libraries\AskSinPP/ContactState.h:224:3: note:   candidate expects 2 arguments, 0 provided
e:\_user7\Documents\Arduino\libraries\AskSinPP/ContactState.h:207:7: note: candidate: as::StateDevice<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, ADCThreeStateChannel<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, WDSList0, WDSList1, as::RegList4<as::DefaultRegisterList4>, 6>, 1, WDSList0, 4320000>::StateDevice(const as::StateDevice<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, ADCThreeStateChannel<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, WDSList0, WDSList1, as::RegList4<as::DefaultRegisterList4>, 6>, 1, WDSList0, 4320000>&)
class StateDevice : public MultiChannelDevice<HalType,ChannelType,ChannelCount,List0Type> {
       ^~~~~~~~~~~
e:\_user7\Documents\Arduino\libraries\AskSinPP/ContactState.h:207:7: note:   candidate expects 1 argument, 0 provided
e:\_user7\Documents\Arduino\_HomeMatic_Devices\HB-SEC-WDS-2\HB-SEC-WDS-2.ino: In member function 'virtual void DevType::configChanged()':
HB-SEC-WDS-2:283:33: error: cannot call member function 'void as::StateDevice<HalType, ChannelType, ChannelCount, List0Type, CycleTime>::configChanged() [with HalType = as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >; ChannelType = ADCThreeStateChannel<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, WDSList0, WDSList1, as::RegList4<as::DefaultRegisterList4>, 6>; int ChannelCount = 1; List0Type = WDSList0; long unsigned int CycleTime = 7200000]' without object
         TSDevice::configChanged();
                                 ^
Using library EnableInterrupt at version 1.0.0 in folder: e:\_user7\Documents\Arduino\libraries\EnableInterrupt
Using library AskSinPP at version 4.1.7 in folder: e:\_user7\Documents\Arduino\libraries\AskSinPP
Using library Low-Power at version 1.6 in folder: e:\_user7\Documents\Arduino\libraries\Low-Power
exit status 1
type 'as::StateDevice<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, ADCThreeStateChannel<as::AskSin<as::StatusLed<4>, as::tmBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, WDSList0, WDSList1, as::RegList4<as::DefaultRegisterList4>, 6>, 1, WDSList0>' is not a direct base of 'DevType'

Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Januar 2021, 20:31:36
Im Typedef fehlt das CYCLETIME - also

public:
    typedef StateDevice<HalType, ChannelType, 1, WDSList0,CYCLETIME> TSDevice;

Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 01 Januar 2021, 22:50:26
Zitat von: McShire am 01 Januar 2021, 11:38:43
Hallo Ralf,
hast Du in FHEM das device HM_120901 und die zugehörigen Kanäle HM_120901_Sw_01 und HM_120901_Sw_02
angelegt?

Ein frohes neues Jahr
Werner

Hallo Werner,

Dir auch ein frohes neues Jahr.

Ich hatte ein Missverständnis. Hatte die Beschaltung nicht richtig. Nun LED an D6 und mit SW1 kann ich die LED Ein / ausschalten. Mit SW2 über on-for-timer die Blinkfrequenz beeinflussen.

Nun stellten sich folgende Fragen:
1. kann die Blinkfrequenz durch einen Parameter direkt beeinflusst werden (je nach Status soll eine andere Frequenz ausgegeben werden)
2. Können weitere Kanäle mit LEDs angesteuert werden (ich möchte die LEDs als Statusanzeige für verschiedene Geräte nutzen)
3. Gibt es eine Resetfunktion ohne das Board stromlos zu machen


Gruss
Ralf
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 02 Januar 2021, 01:59:22
Zitat von: papa am 01 Januar 2021, 20:31:36
Im Typedef fehlt das CYCLETIME - also

public:
    typedef StateDevice<HalType, ChannelType, 1, WDSList0,CYCLETIME> TSDevice;


Das 2. template habe ich übersehen  ::)
Gerade getestet, funktioniert super, Danke!

---

patchStatus() habe ich auch schon angefangen zu testen. In die CCU/xml bekomme ich die extra Bytes rein, das sieht gut aus.
ich habe jetzt folgendes temporär in ContactState.h

#33

      DPRINTLN(F("### ContactState trigger"));
#ifdef CONTACT_STATE_WITH_BATTERY
      channel.patchStatus(msg);
      // msg.append(channel.device().battery().current());
      // msg.append(__gb_BatCount);
#endif


#138

#ifdef CONTACT_STATE_WITH_BATTERY
  void patchStatus (Message& msg) {
    uint16_t u16 = 0x0ABC;
    msg.append(u16);
    DPRINTLN(F("### ContactState patchStatus"));
  }
#endif


Sketch

class ADCThreeStateChannel : public StateGenericChannel<ADCPosition, HALTYPE, List0Type, List1Type, List4Type, PEERCOUNT> {
...
    // papa: patchStatus wird immer vom Device aufgerufen, wenn der Gerätestatus gesendet wird, siehe Device.h #357, #391
    // append custom data to status message
    void patchStatus (Message& msg) {
        uint16_t u16 = 0x1234;
        msg.append(u16);
        DPRINTLN(F("### sketch patchStatus"));
    }


Die Messages sehen jetzt so aus:

*Position Change*

00:44:43.913 -> ADC Wet:   0
00:44:43.913 -> Status:    WATER
00:44:43.913 -> ### ContactState trigger
00:44:43.913 -> ### ContactState patchStatus
00:44:43.947 -> <- 0E 01 A2 41 4929D3 435F5B 01 00 C8 0A BC  - 247
00:44:44.083 -> -> 0A 01 80 02 435F5B 4929D3 00  - 372
00:44:44.083 -> waitAck: 01


*cycleInfoMsg*

01:14:58.709 -> ADC Wet:   0
01:14:58.709 -> Status:    WATER
01:14:58.743 -> ### sketch patchStatus
01:14:58.777 -> <- 10 02 A2 10 4929D3 435F5B 06 01 C8 00 25 12 34  - 1474
01:14:58.880 -> -> 0A 02 80 02 435F5B 4929D3 00  - 1599
01:14:58.914 -> waitAck: 01


Was du geschrieben hast
ZitatpatchStatus wird immer vom Device aufgerufen, wenn der Gerätestatus gesendet wird, siehe Device.h #357, #391

stimmt exakt, der uint16_t 0x1234 wird bei der cycleInfoMsg appended, siehe 01:14:58.777

Einziges Problem noch, nur bei Position Change wird nicht 0x1234 appended, sondern 0x0ABC, siehe 00:44:43.947, was mein Testwert aus ContactState.h #138 ist.
Was muss getan werden, damit auch Position Change die Funktion patchStatus() aus dem Sketch hernimmt, nicht aus ContactState?

Danke,
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 Januar 2021, 15:27:48
Hm - das wird nicht so einfach, da im ersten Fall nur die patchStatus vom StateGenericChannel bekannt ist. Damit das so funktioniert, müsste patchStatus() virtual gemacht werden.

Wir könnten am HAL eine Methode vorsehen, die immer vor dem Senden einer Nachricht aufgerufen wird. Diese kann dann einfach im Device-Sketch überladen werden. Dann brauchst Du das patchStatus() wahrscheinlich gar nicht. Was hältst DU davon ?
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 02 Januar 2021, 17:23:04
Zitat von: papa am 02 Januar 2021, 15:27:48
Hm - das wird nicht so einfach, da im ersten Fall nur die patchStatus vom StateGenericChannel bekannt ist. Damit das so funktioniert, müsste patchStatus() virtual gemacht werden.

Wir könnten am HAL eine Methode vorsehen, die immer vor dem Senden einer Nachricht aufgerufen wird. Diese kann dann einfach im Device-Sketch überladen werden. Dann brauchst Du das patchStatus() wahrscheinlich gar nicht. Was hältst DU davon ?

Das klingt nach einem guten Plan und würde die Umstände mit patchStatus() überflüssig machen. Die Sache mit patchStatus(), es gibt ja ein nicht virtuelles patchStatus mit leerer Impl. in Channel - das kann ich anscheinend für die cycleInfoMsg überschreiben, aber nicht für die PositionChangeMsg. Ich vermute das liegt daran, dass das nicht virtuelle patchStatus in Channel kein late binding bekommt und deswegen nichts vom patchStatus() im Sketch wissen kann?
(Außerdem gibt es weiterhin 2 virtuelle patchStatus in VirtBaseChannel und VirtChannel.)

Also eine neue Methode, die immer vor dem Senden einer Nachricht aufgerufen wird und die im Sketch überladen wird klingt gut, kannst du das bei Gelegenheit machen?

Danke,
Titel: Antw:AskSin++ Library
Beitrag von: papa am 02 Januar 2021, 22:51:05
Na klar - geht doch ganz schnell.
Es wird jetzt immer von dem Senden einer Nachricht HAL::prepareSend() aufgerufen.
Im Sketch kann einfach ein eigener HAL definiert und die leere Standardimplementierung überladen werden.
Z.B. so
typedef AskSin<LedType,BatterySensor,RadioType> HalType;
class Hal : public HalType {
public:
  void prepareSend (Message& msg) {
    if( msg.isSensorEvent() || msg.isInfoActuatorStatusMsg() ) {
      // add you code here
    }
  }
};

Hal hal;
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 03 Januar 2021, 00:32:08
Zitat von: papa am 02 Januar 2021, 22:51:05
Na klar - geht doch ganz schnell.
Es wird jetzt immer von dem Senden einer Nachricht HAL::prepareSend() aufgerufen.
Im Sketch kann einfach ein eigener HAL definiert und die leere Standardimplementierung überladen werden.


Vielen Dank und Wow, so schnell habe ich nicht damit gerechnet  :)
ich werde testen und berichten.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 03 Januar 2021, 04:20:55
Zitat von: Beetle2003 am 01 Januar 2021, 22:50:26
Hallo Werner,

Dir auch ein frohes neues Jahr.

Ich hatte ein Missverständnis. Hatte die Beschaltung nicht richtig. Nun LED an D6 und mit SW1 kann ich die LED Ein / ausschalten. Mit SW2 über on-for-timer die Blinkfrequenz beeinflussen.

Nun stellten sich folgende Fragen:
1. kann die Blinkfrequenz durch einen Parameter direkt beeinflusst werden (je nach Status soll eine andere Frequenz ausgegeben werden)
2. Können weitere Kanäle mit LEDs angesteuert werden (ich möchte die LEDs als Statusanzeige für verschiedene Geräte nutzen)
3. Gibt es eine Resetfunktion ohne das Board stromlos zu machen


Gruss
Ralf

Hallo Ralf,
schön, dass es jetzt funktioniert.
zu1.
Ja, die Pulsweite des Blinkers wird durch die Einschaltdauer von RELAY2 gesetzt.
Mit der Anweisung set HM_120901_Sw_02 on-for-timer 500 gibt 500 die Pulsweite und damit die Blinkfrquenz vor.
Wenn Du jetzt die 500 durch den Wert eines Dummy-devices ersetzt oder die Einschaltdauer anders variierst,
z.B. set ... on, sleep ..., set off, kannst Du darüber die Blinkfrequenz setzen.
zu2.
Nur über FHEM ansteuern oder auch mit Taster lokal?
zu3. lokal über die Resttaste auf dem Pro Mini und über den Eingang RST gegen GND.

Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 03 Januar 2021, 12:58:26
Zitat von: papa am 02 Januar 2021, 22:51:05
Na klar - geht doch ganz schnell.
Es wird jetzt immer von dem Senden einer Nachricht HAL::prepareSend() aufgerufen.
Im Sketch kann einfach ein eigener HAL definiert und die leere Standardimplementierung überladen werden.

Läuft einwandfrei, papa, Vielen Dank für die Hilfe und rasche Umsetzung!

Im Log erst die Sensor Msg, danach die Gerätestatus Msg. 1234h angehängt per Überladung im Sketch.

..
Battery set low:  24
transmitDevTryMax: 6
ADC Wet:   0
Status:    WATER
<- 0E 01 A2 41 4929D3 435F5B 01 00 C8 12 34  - 243
-> 0A 01 80 02 435F5B 4929D3 00  - 368
waitAck: 01
<- 10 02 A2 10 4929D3 435F5B 06 01 C8 00 20 12 34  - 913
-> 0A 02 80 02 435F5B 4929D3 00  - 1038
waitAck: 01
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 03 Januar 2021, 15:23:29
Zitat von: McShire am 03 Januar 2021, 04:20:55
Hallo Ralf,
schön, dass es jetzt funktioniert.
zu1.
Ja, die Pulsweite des Blinkers wird durch die Einschaltdauer von RELAY2 gesetzt.
Mit der Anweisung set HM_120901_Sw_02 on-for-timer 500 gibt 500 die Pulsweite und damit die Blinkfrquenz vor.
Wenn Du jetzt die 500 durch den Wert eines Dummy-devices ersetzt oder die Einschaltdauer anders variierst,
z.B. set ... on, sleep ..., set off, kannst Du darüber die Blinkfrequenz setzen.
zu2.
Nur über FHEM ansteuern oder auch mit Taster lokal?
zu3. lokal über die Resttaste auf dem Pro Mini und über den Eingang RST gegen GND.

Viele Grüße
Werner

Hallo Werner,

danke.
zu 1. Das mit on-for-timer habe ich durchgeführt. Hat zur Folge, dass eine Veränderung der Blinkfreuenz sehr zeitaufwändig ist. Meine Hoffnung ging dorthin, dass ein Readingwert oder Attribut genutzt werden kann, in dem die Blinkfrequenz gespeichert ist und dieser Wert eingelesen wird. Somit enthält die Wartezeit für z.B. on-for-timer.
zu 2. Derzeit würde mir eine Steuerung über Fhem reichen. Sicherlich gibt es weitere Mitstreiter, welche die Ansteuerung über Taster für sinvoll halten. Die Blinkfreuenz sollte wie zu 1 beschrieben für jede LED anpassbar sein.
zu 3. Die genannten Dinge sind mir bekannt. Doch wenn ich das Board in eine Gehäuse einbaue, so ist es suboptimal wenn es hierfür geöffnet werden muss. Deshalb dachte ich an eine Steuerung für die Software.

Wie sagt ein sehr guter Kollege regelmässig: Auf Wunsch eines einzelnen angepasst! :-)

Gruss
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 03 Januar 2021, 16:55:28
Zitat von: Tom Major am 03 Januar 2021, 12:58:26
Läuft einwandfrei, papa, Vielen Dank für die Hilfe und rasche Umsetzung!

Im Log erst die Sensor Msg, danach die Gerätestatus Msg. 1234h angehängt per Überladung im Sketch.

und hier noch der erste Anwendungsfall:
https://homematic-forum.de/forum/viewtopic.php?f=76&t=64212 (https://homematic-forum.de/forum/viewtopic.php?f=76&t=64212)

Es ist auf jeden Fall eine gute Sache vom Sketch aus Bytes der Nachricht anfügen zu können. Das erhöht die Flexibilität für zukünftige Geräte.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 04 Januar 2021, 01:00:44
Zitat von: Beetle2003 am 03 Januar 2021, 15:23:29
Hallo Werner,

danke.
zu 1. Das mit on-for-timer habe ich durchgeführt. Hat zur Folge, dass eine Veränderung der Blinkfreuenz sehr zeitaufwändig ist. Meine Hoffnung ging dorthin, dass ein Readingwert oder Attribut genutzt werden kann, in dem die Blinkfrequenz gespeichert ist und dieser Wert eingelesen wird. Somit enthält die Wartezeit für z.B. on-for-timer.
zu 2. Derzeit würde mir eine Steuerung über Fhem reichen. Sicherlich gibt es weitere Mitstreiter, welche die Ansteuerung über Taster für sinvoll halten. Die Blinkfreuenz sollte wie zu 1 beschrieben für jede LED anpassbar sein.
zu 3. Die genannten Dinge sind mir bekannt. Doch wenn ich das Board in eine Gehäuse einbaue, so ist es suboptimal wenn es hierfür geöffnet werden muss. Deshalb dachte ich an eine Steuerung für die Software.

Wie sagt ein sehr guter Kollege regelmässig: Auf Wunsch eines einzelnen angepasst! :-)

Gruss

Hallo Ralf,
zu 1.
leider wird hier für die Blinkfrequenz überhaupt kein Wert übertragen. Dieser Sketch ist lediglich
ein Derivat von einem 2-poligen Schalter, der nur on und off überträgt. Die Blinkfunktion, (LED on/off und blinkfrequenz ) wird nur im Arduino erzeugt, abgeleitet aus den Schaltzuständen.
Im Arduino läuft als Hauptprogramm eine loop. Die Pulsweite ergibt sich aus der Anzahl der loop-Durchläufe während der Einschaltzeit von Kanal2. Das ganze ist quick and dirty eingefügt in die loop am Ende. Pulsweiten in Form einer Zahl geht mit diesem Modul leider nicht. Es lässt sich Zeit sparen, wenn man die Pulsweite nicht variabel gestaltet, sondern nur wenige Frequenzen festlegt. Dann kann man dafür ganz kurze Einschaltzeiten übertragen und daraus im Arduino die Pulsweite ableiten.
zu2.
Wenn man keinen Taster braucht, benötigt man dafür auch keinen DI am Arduino. Die Zahl ist ja begrenzt. Ich glaube , es gibt auch einen Sketch für einen 8-fach Aktor, den könnte man dann wie beim 2-fach Switch "aufbohren" und käme auf 4 Blinker, das sind dann 12 DOs , das ist für den Mini das Maximum.
zu 3.
Mit Steuerung über FHEM kann man beliebige Logik und Verknüpfungen einführen, das ist ein großer Vorteil, z.B. die Pulsweite in Abhägigkeiten von Stati festlegen. Wer dann noch einen Taster braucht, kann dann ja parallel einen Taster betreiben und dessen Signale in FHEM zur Steuerung des Blinkmoduls benutzen.

Ich melde mich wieder, wenn ich mit dem 8-fach Aktor etwas probiert habe. Kann ein bisschen dauern.
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 04 Januar 2021, 20:45:27
Zitat von: McShire am 04 Januar 2021, 01:00:44
Hallo Ralf,
zu 1.
leider wird hier für die Blinkfrequenz überhaupt kein Wert übertragen. Dieser Sketch ist lediglich
ein Derivat von einem 2-poligen Schalter, der nur on und off überträgt. Die Blinkfunktion, (LED on/off und blinkfrequenz ) wird nur im Arduino erzeugt, abgeleitet aus den Schaltzuständen.
Im Arduino läuft als Hauptprogramm eine loop. Die Pulsweite ergibt sich aus der Anzahl der loop-Durchläufe während der Einschaltzeit von Kanal2. Das ganze ist quick and dirty eingefügt in die loop am Ende. Pulsweiten in Form einer Zahl geht mit diesem Modul leider nicht. Es lässt sich Zeit sparen, wenn man die Pulsweite nicht variabel gestaltet, sondern nur wenige Frequenzen festlegt. Dann kann man dafür ganz kurze Einschaltzeiten übertragen und daraus im Arduino die Pulsweite ableiten.
zu2.
Wenn man keinen Taster braucht, benötigt man dafür auch keinen DI am Arduino. Die Zahl ist ja begrenzt. Ich glaube , es gibt auch einen Sketch für einen 8-fach Aktor, den könnte man dann wie beim 2-fach Switch "aufbohren" und käme auf 4 Blinker, das sind dann 12 DOs , das ist für den Mini das Maximum.
zu 3.
Mit Steuerung über FHEM kann man beliebige Logik und Verknüpfungen einführen, das ist ein großer Vorteil, z.B. die Pulsweite in Abhägigkeiten von Stati festlegen. Wer dann noch einen Taster braucht, kann dann ja parallel einen Taster betreiben und dessen Signale in FHEM zur Steuerung des Blinkmoduls benutzen.

Ich melde mich wieder, wenn ich mit dem 8-fach Aktor etwas probiert habe. Kann ein bisschen dauern.
Viele Grüße
Werner

Hallo Werner,

Danke für die Antwort.

Ich freue mich auf deinen Ergebnis.

Bleib gesund

Gruß
Ralf
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 13 Januar 2021, 02:05:24
Zitat von: Beetle2003 am 04 Januar 2021, 20:45:27
Hallo Werner,

Danke für die Antwort.

Ich freue mich auf deinen Ergebnis.

Bleib gesund

Gruß
Ralf


Hallo Ralf,
hat ein bisschen gedauert, ist jetzt fertig "quick and dirty"
3 Blinker, mehr geht nach diesem Verfahren wegen der begrenzten Ausgänge nicht.
jeder Blinker hat 3 Kanäle, Ein/Aus, Pulsweite, Blinker-Ausgang.
Falls man mehr Blinker braucht, muss man ein vollkommen neues device in FHEM schaffen,
das dann die Daten anders überträgt. Das jetzige Modell ist ja nur von einem Aktor abgeleited.
Falls Du es gebrauchen kannst, viel Spass damit.


//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2018-09-29 jp112sdl Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2021-01-05 modification by mcshire, to use this sketch in combination with device HM-MOD-Re-8
// to generate 3 outputs for blinkers with varable frequency.
// There are 3 DI for every blinker: on/off Signal, pulsewidth, blinkeroutput.
// on/off controlled in FHEM: on - blinker is activ
// pulsewidth: duration on-time is analog to pulswidth scaled by factor
// blinkeroutput: supplies LED or relay with square wave signal, when DI (on/off) is HIGH
//PIN-Belgung und FHEM-Kanäle siehe im auskommentierten define-Block
//- -----------------------------------------------------------------------------------------------------------------------

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

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Switch.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

int RELAY_EA_PIN[3] = {14, 16, 7};
int RELAY_PW_PIN[3] = {15, 17, 9};
int RELAY_BLINK_PIN[3] = {6, 3, 5};

// #define RELAY_EA_PIN[0] 14      //A0 //on-off Blinker 1 CH1
// #define RELAY_PW_PIN[0] 15      //A1 //Pulswi Blinker 1 CH2
// #define RELAY_EA_PIN[1] 16      //A2 //on-off Blinker 2 CH3
// #define RELAY_PW_PIN[1] 17      //A3 //Pulswi Blinker 2 CH4
// #define RELAY_EA_PIN[2] 7            //on-off Blinker 3 CH5
// #define RELAY_PW_PIN[2] 9            //Pulswi Blinker 3 CH6
// #define RELAY_BLINK_PIN[0] 6         //Output Blinker 1 CH7
// #define RELAY_BLINK_PIN[1] 3         //Output Blinker 2 CH8
// #define RELAY_BLINK_PIN[2] 5         //Output Blinker 3 kein Channel,keine Verbindung zu FHEM
// Pin 10:  connected to ChipSelect CC1101
// Pin 11, 12, 13: SPI (Miso, Mosi CLK) CC1101
// PIN 2: GD0 CC1101
// PIN 4: StateLED
// PIN 8: Config-button


// number of available peers per channel
#define PEERS_PER_CHANNEL 4
// max number of loops for pulswidth
int MAX_NO_LOOP = 5000;

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x00,0xBE,0x00},       // Device ID
    "JP00BE0000",           // Device Serial
    {0x00,0xbe},            // Device Model
    0x12,                   // Firmware Version
    as::DeviceType::Switch, // Device Type
    {0x01,0x00}             // Info Bytes
};

/**
* Configure the used hardware
*/
typedef AvrSPI<10,11,12,13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>,BatterySensor,Radio<RadioSPI,2> > Hal;

DEFREGISTER(Reg0,DREG_INTKEY,DREG_LEDMODE,MASTERID_REGS,DREG_LOWBATLIMIT)
class SwList0 : public RegList0<Reg0> {
public:
  SwList0(uint16_t addr) : RegList0<Reg0>(addr) {}
  void defaults () {
    clear();
    lowBatLimit(22);
  }
};

// setup the device with channel type and number of channels
class SwitchType : public MultiChannelDevice<Hal,SwitchChannel<Hal,PEERS_PER_CHANNEL,SwList0>,8,SwList0> {
public:
  typedef MultiChannelDevice<Hal,SwitchChannel<Hal,PEERS_PER_CHANNEL,SwList0>,8,SwList0> DevType;
  SwitchType (const DeviceInfo& i,uint16_t addr) : DevType(i,addr) {}
  virtual ~SwitchType () {}

  virtual void configChanged () {
    DevType::configChanged();
    uint8_t lowbat = getList0().lowBatLimit();
    DDECLN(lowbat);
    if( lowbat > 0 ) {
      battery().low(lowbat);
    }
  }
};

// Mod WS
int peri_max[3] = {50,50,50};         // number of loops for blink/no blink time
int peri_count[3] = {1,1,1};         // counter for actual number of loops
int peri_set[3] = {500,500,500};           // Counter for setting peri_max counting SWITCH2 on-time, init = 500
int peri_set_max[3] = {MAX_NO_LOOP,MAX_NO_LOOP,MAX_NO_LOOP}; // Limit for peri_max
bool rel_old[3] = {LOW,LOW,LOW}; //
bool blinki[3] = {LOW,LOW,LOW}; //
int peri_scale = 5; // loops pulsewidth = loops/peri_scale (peri_max = peri_set/peri_scale)

Hal hal;
SwitchType sdev(devinfo,0x20);
ConfigButton<SwitchType> cfgBtn(sdev);

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    for( uint8_t i=1; i<=sdev.channels(); ++i ) {
      Peer ipeer(devid,i);
      sdev.channel(i).peer(ipeer);
    }
  }
}


void setup () {

// Mod WS
  pinMode(RELAY_BLINK_PIN[2], OUTPUT);   
 
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY_EA_PIN[0]);
  sdev.channel(2).init(RELAY_PW_PIN[0]);
  sdev.channel(3).init(RELAY_EA_PIN[1]);
  sdev.channel(4).init(RELAY_PW_PIN[1]);
  sdev.channel(5).init(RELAY_EA_PIN[2]);
  sdev.channel(6).init(RELAY_PW_PIN[2]);
  sdev.channel(7).init(RELAY_BLINK_PIN[0]);
  sdev.channel(8).init(RELAY_BLINK_PIN[1]);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  initPeerings(first);
  // stay on for 15 seconds after start
  hal.activity.stayAwake(seconds2ticks(15));
  // measure battery every hour
  hal.battery.init(seconds2ticks(60UL*60),sysclock);
  sdev.initDone();

  digitalWrite(RELAY_BLINK_PIN[0],LOW);
  digitalWrite(RELAY_BLINK_PIN[1],LOW);
  digitalWrite(RELAY_BLINK_PIN[2],LOW);
}
int i = 2;
int count = 0;
int count_diff = 0;


void loop() {
  bool worked = hal.runready();

// Mod WS start

for (i=0;i<3;i++) {

count++;
if (count >= 10000) {count = 0;} //Schleifnkontrolle für Geschindigkeit
count_diff = count - peri_count[0]; //Kontrolle ob alle perioden erfasst werden

  if( digitalRead(RELAY_EA_PIN[i]) == HIGH ) { //Blinker is set on
    peri_count[i]++;
     Serial.print("peri_count: ");
     Serial.println(peri_count[i]);
 
    if( peri_count[i] >= peri_max[i] ) {
      blinki[i] = !blinki[i];
      digitalWrite(RELAY_BLINK_PIN[i],blinki[i]);
      peri_count[i] = 0;
    }
  }
  else {
    blinki[i] = LOW;
    digitalWrite(RELAY_BLINK_PIN[i],blinki[i]) ;
  }

  if( digitalRead(RELAY_PW_PIN[i]) == HIGH) {  // set new duration of blink / no blink time
    if (rel_old[i] == LOW) peri_set[i] = 0;
    if (peri_set[i] <= peri_set_max[i]) {
      peri_set[i]++;
    }
  }
  else {
    peri_max[i] = peri_set[i]/peri_scale;
  }
  rel_old[i] = digitalRead(RELAY_PW_PIN[i]);

}
// Mod WS end

 
  bool poll = sdev.pollRadio();
 
  if(RELAY_EA_PIN[0] == LOW && RELAY_PW_PIN[0] == LOW) {
    if( worked == false && poll == false ) {
      hal.activity.savePower<Sleep<> >(hal);
    }
  }
}


Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 18 Januar 2021, 07:06:15
Zitat von: McShire am 13 Januar 2021, 02:05:24

Hallo Ralf,
hat ein bisschen gedauert, ist jetzt fertig "quick and dirty"
3 Blinker, mehr geht nach diesem Verfahren wegen der begrenzten Ausgänge nicht.
jeder Blinker hat 3 Kanäle, Ein/Aus, Pulsweite, Blinker-Ausgang.
Falls man mehr Blinker braucht, muss man ein vollkommen neues device in FHEM schaffen,
das dann die Daten anders überträgt. Das jetzige Modell ist ja nur von einem Aktor abgeleited.
Falls Du es gebrauchen kannst, viel Spass damit.



Viele Grüße
Werner

Guten Morgen Werner,

Ich habe das schlechte Wetter gestern genutzt um mich mit deinem Vorschlag zu beschäftigen.
Vielen Dank für die Mühe. Mir fehlt oft die Idee, ein fertiges Produkt für meine Belange zu ändern.

Ich habe aufgrund deiner Grundidee den 8 Fach Schalter wie folgt geändert:
2x BlinkLed, 3x leuchtende LEDs welche geschaltet werden können und die Blinkfrequenz über einen Kanal für beide Ausgänge festgelegt werden.

Was mache ich damit:
Ich habe dieses Modul in das Gehäuse für meinen Kartenleser eingebaut.
Led1. Signal Alarmanlage ein/aus
Led2 blink. Signalisierung Aktivierung / Deaktivierung Alarmanlage ( Funktion wurde ausgeführt)
Led3 blink. Meldung Wassermelder Wasser erkannt
Led4 und 5. Duo Led.   Türen / Fenster min 1 offen oder alle geschlossen.

Danke für deine Hilfe
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 18 Januar 2021, 13:38:55
Hallo Ralf,
eine gute Idee, zum Ein-und Ausschalten einen Kartenleser zu verwenden und mit LEDs die Ausführung zu bestätigen.
Kann ich vielleicht gut verwenden.
Ein- Ausschalten für Alarm, Prüfung Türen und Fenster zu usw. mache ich mit einem 4-fach-Taster. (Homebrew HB_... batterieschonend in Ruhe 4,7uA).
Die Rückmeldung bekomme ich über SIP-Anrufe auf mein Mobiltelefon.
Insbesondere Warnmeldungen wie Wasserschaden, Fenster bei Abwesenheit auf, Alarm, Rauchmelder usw.
Bleib gesund und eine schöne Zeit
Werner
Titel: Antw:AskSin++ Library
Beitrag von: cw am 22 März 2021, 14:23:52
Hallo zusammen,

ich beschäftige mich gerade mit "HM-LC-SWX-SM" und auf den UNO und NANO habe ich es auch zum Laufen gebracht.
In FHEM anmelden, LEDs steuern und auch die Taster funktionieren.

Nun würde ich gerne den Mega 2560 nutzen, klar das man die PINs nicht 1:1 über nehmen kann. Momentan bin ich auf dem Stand das das CC1101 Modul funktioniert und auch alles in FHEM steuerbar ist (so wie beim UNO / NANO), nur die Taster bekomme ich nicht ans Laufen.

Hatte mir auch schon die Files zu AskSinPP von papa angesehen aber da versteh ich noch weniger, ein Sketch zu verändern ist das eine .. :-|
Leichenhaft ausgedrückt, die PINs haben ja bestimmte "Funktionen" und die hatte ich versucht in Richtung Mega zu mappen bin aber gescheitert.
Gibt es jmd der schon einen Mega verwendet hat und mir evtl einen Tipp geben kann?

Viele Grüße ...Carsten
Titel: Antw:AskSin++ Library
Beitrag von: gloob am 22 März 2021, 14:50:01
Zeig doch mal deinen aktuellen Sketch für den Mega.
Titel: Antw:AskSin++ Library
Beitrag von: cw am 22 März 2021, 14:53:41
Gerne,

sind nur minimale Änderung zum Beispiel ....
Der Abschnitt mit den Buttons ist aus purer Verzweiflung entstanden und müssten eigentlich die digitalen PINs sein.
Ich verstehe es nur einfach nicht da werden doch nur PINs übergeben, grübel.

Viele Grüße ...Carsten

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// ci-test=yes board=328p aes=no
//- -----------------------------------------------------------------------------------------------------------------------

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

// number of relays by defining the device
#define HM_LC_SW1_SM 0x00,0x02
#define HM_LC_SW2_SM 0x00,0x0a
#define HM_LC_SW4_SM 0x00,0x03

#define CFG_LOWACTIVE_BYTE 0x00
#define CFG_LOWACTIVE_ON   0x01
#define CFG_LOWACTIVE_OFF  0x00

#define DEVICE_CONFIG CFG_LOWACTIVE_OFF

#define HM_SENSOR_RELAY

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Switch.h>


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


// relay output pins compatible to the HM_Relay project
#define RELAY1_PIN 30
#define RELAY2_PIN 31
#define RELAY3_PIN 32
#define RELAY4_PIN 33
#define BUTTON1_PIN 4
#define BUTTON2_PIN 5
#define BUTTON3_PIN 6
#define BUTTON4_PIN 7


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


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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0x90, 0x90, 0x90},     // Device ID
  "cw-mega-00",           // Device Serial
  {HM_LC_SW4_SM},         // Device Model
  0x16,                   // Firmware Version
  as::DeviceType::Switch, // Device Type
  {0x01, 0x00}            // Info Bytes
};

/**
   Configure the used hardware
*/
typedef AvrSPI<53, 51, 50, 52> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<RadioSPI, 2> > Hal;

// setup the device with channel type and number of channels
typedef MultiChannelDevice<Hal, SwitchChannel<Hal, PEERS_PER_CHANNEL, List0>, 4> SwitchType;

Hal hal;
SwitchType sdev(devinfo, 0x20);
#ifdef HM_SENSOR_RELAY
ConfigButton<SwitchType> cfgBtn(sdev);
InternalButton<SwitchType> btn1(sdev, 1);
InternalButton<SwitchType> btn2(sdev, 2);
InternalButton<SwitchType> btn3(sdev, 3);
InternalButton<SwitchType> btn4(sdev, 4);
#else
ConfigToggleButton<SwitchType> cfgBtn(sdev);
#endif

// if A0 and A1 connected
// we use LOW for ON and HIGH for OFF
// bool checkLowActive () {
//   pinMode(14, OUTPUT); // A0
//   pinMode(15, INPUT_PULLUP); // A1
//   digitalWrite(15, HIGH);
//   digitalWrite(14, LOW);
//   bool result = digitalRead(15) == LOW;
//   digitalWrite(14, HIGH);
//   return result;
// }

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if ( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    for ( uint8_t i = 1; i <= sdev.channels(); ++i ) {
      Peer ipeer(devid, i);
      sdev.channel(i).peer(ipeer);
    }
  }
}

void initModelType () {
  uint8_t model[2];
  sdev.getDeviceModel(model);
  if ( model[1] == 0x02 ) {
    sdev.channels(1);
    DPRINTLN(F("HM-LC-SW1-SM"));
  }
  else if ( model[1] == 0x0a ) {
    sdev.channels(2);
    DPRINTLN(F("HM-LC-SW2-SM"));
  }
  else {
    DPRINTLN(F("HM-LC-SW4-SM"));
  }
}


void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
#ifdef HM_SENSOR_RELAY
  bool low = false;
#else
  bool low = (sdev.getConfigByte(CFG_LOWACTIVE_BYTE) == CFG_LOWACTIVE_ON) || checkLowActive();
#endif
  DPRINT("Invert "); low ? DPRINTLN("active") : DPRINTLN("disabled");
  sdev.channel(1).init(RELAY1_PIN, low);
  sdev.channel(2).init(RELAY2_PIN, low);
  sdev.channel(3).init(RELAY3_PIN, low);
  sdev.channel(4).init(RELAY4_PIN, low);

  buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
#ifdef HM_SENSOR_RELAY
  buttonISR(btn1, BUTTON1_PIN);
  buttonISR(btn2, BUTTON2_PIN);
  buttonISR(btn3, BUTTON3_PIN);
  buttonISR(btn4, BUTTON4_PIN);
#endif
  initModelType();
  initPeerings(first);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if ( worked == false && poll == false ) {
    hal.activity.savePower<Idle<> >(hal);
  }
}
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 22 März 2021, 16:40:31
Jerome hat den Mega 2560 mit AskSinPP hier verwendet, evtl. hilft das beim Pin Mapping:
https://github.com/jp112sdl/HB-UNI-RGB-LED-CTRL (https://github.com/jp112sdl/HB-UNI-RGB-LED-CTRL)
Titel: Antw:AskSin++ Library
Beitrag von: cw am 22 März 2021, 16:44:49
@Tom Major,

Danke, ja das hatte ich schon gefunden und mich daran orientiert.
Das Problem ist nicht die Einbindung / Ansteuerung via FHEM sondern das ich die Taster nicht zur Steuerung verwenden kann.
Egal welchen "PIN" ich angebe, es kommt keine Reaktion vom Mega, auf den UNO / NANO alles gut.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 24 März 2021, 18:40:52
Zitat von: cw am 22 März 2021, 16:44:49
@Tom Major,

Danke, ja das hatte ich schon gefunden und mich daran orientiert.
Das Problem ist nicht die Einbindung / Ansteuerung via FHEM sondern das ich die Taster nicht zur Steuerung verwenden kann.
Egal welchen "PIN" ich angebe, es kommt keine Reaktion vom Mega, auf den UNO / NANO alles gut.

Eventuell mal im orangen Forum in der Rubrik
Hardwareentwicklung und Selbstbau von Aktoren und Sensoren
fragen ob Jerome was dazu sagen kann. Er ist m.W. einer der wenigen die was mit dem Mega 2560 und AskSinPP gemacht haben.

Ich glaube mich zu erinnern das dort neulich auch ein thread war wo jemand eine Frage zum 2560 hatte, ich glaube zum FreqTest.
Titel: Antw:AskSin++ Library
Beitrag von: andre.k am 25 März 2021, 09:09:33
Hallo,

ich habe einige Eigenbaugeräte mit AskSinPP im Einsatz und würde gern mal dieses Feature ausprobieren https://github.com/pa-pa/AskSinPP#alternative-device-reset-method (https://github.com/pa-pa/AskSinPP#alternative-device-reset-method).

Mir ist aber nicht klar, wie ich den ATMEGA booten kann, ohne den Resettaster zu betätigen. So wie ich den Anwendungsfall verstehe, soll er ja gerade für schwer zugängliche Geräte gedacht sein, d.h wenn ich nicht so leicht an die Konfigtaste rankomme. Aber dann komme ich üblicherweise auch nicht leicht an des Resettaster. Gibt es ein Kommando, welches den ATMEGA per Software bootet?

VG
Andre
Titel: Antw:AskSin++ Library
Beitrag von: tndx am 25 März 2021, 13:18:37
Zitat von: andre.k am 25 März 2021, 09:09:33
Mir ist aber nicht klar, wie ich den ATMEGA booten kann, ohne den Resettaster zu betätigen. So wie ich den Anwendungsfall verstehe, soll er ja gerade für schwer zugängliche Geräte gedacht sein, d.h wenn ich nicht so leicht an die Konfigtaste rankomme. Aber dann komme ich üblicherweise auch nicht leicht an des Resettaster. Gibt es ein Kommando, welches den ATMEGA per Software bootet?

Aber an die Stromzufuhr kommst Du ja dran :) So verstehe ich jedenfalls den Anwendungsfall, ist kein Taster (oder freie Atmega-Ports) verfügbar, so kann man anstelle eines Tasterdrucks eben die Stromzufuhrunterbrechung als Trigger nehmen, das Device zu resetten. Damit es nicht zufällig bei dem nächsten Stromausfall passiert, gibt es ein Muster.
Titel: Antw:AskSin++ Library
Beitrag von: andre.k am 25 März 2021, 14:20:27
Zitat von: tndx am 25 März 2021, 13:18:37
Aber an die Stromzufuhr kommst Du ja dran :) So verstehe ich jedenfalls den Anwendungsfall, ist kein Taster (oder freie Atmega-Ports) verfügbar, so kann man anstelle eines Tasterdrucks eben die Stromzufuhrunterbrechung als Trigger nehmen, das Device zu resetten. Damit es nicht zufällig bei dem nächsten Stromausfall passiert, gibt es ein Muster.
Danke. An POR hatte ich gar nicht gedacht.
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 05 April 2021, 14:04:06
Moin,
ich habe mich nun auch mal an die "AskSin-Thematik" gewagt, wegen defekter und nicht mehr lieferbarer HM-MOD-EM-8.

Super Sache, danke an alle, die daran mitgearbeitet haben ! !  :)

Ich habe aber eine Frage zum HB-UNI-Sen-WEA:

nach getConfig, regSet etc muss man die ConfigTaste am Device drücken, um die pending Commands abzuarbeiten. Das ist natürlich mindestens sportlich bei auf dem Dach oder an einem Mast angebauten Devices. Kann man dieses Verhalten im Sketch (oder in der HMConfig_AskSinPPCustom.pm) dahingegehend modifizieren, dass die Commands sofort abgearbeitet werden und nur beim Pairing die ConfigTaste gedrückt werden muss ?

Alternativ muss man viel Geduld haben, nach x normalen Sendzyklen werden nach meiner Beobachtung auch die Befehle "plötzlich" abgearbeitet.

Schon mal vielen Dank für einen Tipp !

Moin
Bernd

Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 April 2021, 18:41:40
Zitat von: pwlr am 05 April 2021, 14:04:06
Moin,
ich habe mich nun auch mal an die "AskSin-Thematik" gewagt, wegen defekter und nicht mehr lieferbarer HM-MOD-EM-8.

Super Sache, danke an alle, die daran mitgearbeitet haben ! !  :)

Ich habe aber eine Frage zum HB-UNI-Sen-WEA:

nach getConfig, regSet etc muss man die ConfigTaste am Device drücken, um die pending Commands abzuarbeiten. Das ist natürlich mindestens sportlich bei auf dem Dach oder an einem Mast angebauten Devices. Kann man dieses Verhalten im Sketch (oder in der HMConfig_AskSinPPCustom.pm) dahingegehend modifizieren, dass die Commands sofort abgearbeitet werden und nur beim Pairing die ConfigTaste gedrückt werden muss ?

Alternativ muss man viel Geduld haben, nach x normalen Sendzyklen werden nach meiner Beobachtung auch die Befehle "plötzlich" abgearbeitet.

Schon mal vielen Dank für einen Tipp !
Ich glaube mich zu erinnern, dass der Sketch nur alle 10? Nachrichten nen ACK anfordert. Und nur dann werden die ausstehenden Konfig-Daten übermittelt.
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 05 April 2021, 21:42:01
Moin papa,

danke für die schnelle Antwort.

ZitatIch glaube mich zu erinnern, dass der Sketch nur alle 10? Nachrichten nen ACK anfordert. Und nur dann werden die ausstehenden Konfig-Daten übermittelt.

Ja, ist wohl so. Aber kann man das ändern ? Ich sehe irgendwie keinen Vorteil duch diese Regelung.

Moin
Bernd
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 April 2021, 22:02:41
Zitat von: pwlr am 05 April 2021, 21:42:01
Ja, ist wohl so. Aber kann man das ändern ? Ich sehe irgendwie keinen Vorteil duch diese Regelung.

Ja - hier - https://github.com/jp112sdl/HB-UNI-Sen-WEA/blob/be781c868938074e7013c54c748714ee3b3e2c73/HB-UNI-Sen-WEA.ino#L412
Es sind übrigens nur alle 20 Messages
Titel: Antw:AskSin++ Library
Beitrag von: cw am 25 April 2021, 12:55:15
Hallo,

und sorry für die späte Reaktion meinerseits.

Nun geht es wie gedacht und für die Nachwelt:

Arduino Mega 2560 (PRO, MINI, Embedded oder wie er sonst noch genannt wird).
Ich habe die PINs der RELAYx_PINs verschoben und nun lassen sich auch andere PINs für die Taster nutzen.


#define RELAY1_PIN 28
#define RELAY2_PIN 29
#define RELAY3_PIN 30
#define RELAY4_PIN 31
#define BUTTON1_PIN 18
#define BUTTON2_PIN 19
#define BUTTON3_PIN 20
#define BUTTON4_PIN 21


Danke für eure Hilfe!
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 31 Mai 2021, 12:24:35
Hallo,

ich versuche gerade mit dem Device HB-GEN-SENS meinen Drucksensor (via Spannungsmessung) für mein Regenfass auszulesen (MPX5010DP), das klappt auch aber ich verstehe gerade die folgenden Parameter nicht ganz:

#define ANALOG_ENABLE_PIN 0 (Der Port geht vor dem Messen hoch, richtig?)
#define ANALOG_ENABLE_STATE LOW
#define ANALOG_VCCREF 0
#define ANALOG_FACTOR 110

Kann mir hier kurz jemand ein paar Kommentare zu abgeben? Im Prinzip reichen mir für meinen Zweck die Werte des ADC aus.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: papa am 01 Juni 2021, 04:01:31
Da wird die Klasse für die externe Betriebsspannungmessung verwendet. Deshalb auch die vielen Parameter.
ANALOG_PIN - hier wird gemessen
ANALOG_ENABLE_PIN - zur Aktivierung der Messschaltung
ANALOG_ENABLE_STATE - der State bei dem die Messschaltung aktiviert ist
ANALOG_VCCREF - das ist die Referenzspannung - bei 0 wird intern die Referenz ermittelt
ANALOG_FACTOR - Faktor, um einen vorgeschalteten Spannungsteiler auszugleichen


Wenn Du nur die ADC brauchst, kannst Du den ganzen Quatsch auch weg lassen. Das könnte dann so aussehen
virtual void trigger (AlarmClock& clock) {
.....
#ifdef ANALOG_PIN
  uint16_t value = analogRead(ANALOG_PIN);
  msg.add(value);
#endif
.....

void setup ......
.....
#ifdef ANALOG_PIN
  pinMode(ANALOG_PIN,INPUT);
#endif
}
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 01 Juni 2021, 10:05:27
Super danke, jetzt läuft alles wie gewünscht.

/Daniel
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 14 Juli 2021, 15:23:14
Zitat
author=papa link=topic=57486.msg489099#msg489099 date=1473325885]
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.github.io/).


Hallo papa,

mit den Projekten in der AskSin++ Library habe ich ja schon, auch mit Deiner Hilfe, einiges gemacht.
Jetzt waren meine bisherigen Arduino Mini Pro aufgebraucht und ich habe neue beschafft.
Diese ließen sich nicht wie o.a. gemäß der AskSin++ website flashen.
Nachdem ich einiges gelesen hatte, war der erste Gedanke gemäß zahlreicher Artikel, die Module haben keinen Bootloader.
Also mit ArduinoISP mit einem Nano den Bootloader geflashed, geht auch erfolgreich.
Das Modul wieder an den FTDI-Adapter gesteckt, flashen funktioniert nicht.
Das Modul über den Programmer Arduino as ISP geflashed, als erfolgreich angezeigt, an den FTDI-Adapter als
Schnittstelle zum seriellen Monitor angeschlossen, keine Ausgabe, also funktioniert die Programmierung anscheinend nicht.
Mit Arduino as ISP ein Blinkprogram geflashed, LED angeschlossen, sieh da, es blinkt.
Also konnte es nur an der Verbindung zum FTDI Interface liegen.
Nach längerem Suchen habe ich die Ursache gefunden!
Bei den neuen Modulen ist die Reihenfolge der Anschlüsse zum FTDI-Interface umgedreht, man muss das Interface andersherum einstecken,
dann funktioniert alles.
Da ich darüber nirgendwo etwas gelesen habe, schreibe ich das hier, weil andere vielleicht die gleichen Probleme haben und dann nicht lange suchen müssen
oder gar die Module als defekt entsorgen.
Vielleicht kannst Du die AskSin Webseite beim Thema Sofware mit einem Hinweis versehen, dass man bitte die Beschriftung auf den Modulen vergleicht und zum flashen den Adapter
ggf. anders herum anschließt.
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 14 Juli 2021, 15:59:03
Zitat von: McShire am 14 Juli 2021, 15:23:14
Nach längerem Suchen habe ich die Ursache gefunden!
Bei den neuen Modulen ist die Reihenfolge der Anschlüsse zum FTDI-Interface umgedreht, man muss das Interface andersherum einstecken,
dann funktioniert alles.

Die Pins des seriellen Programmier-Anschlusses waren bei mir auf Pro Mini Seite immer beschriftet, ich schaue z.B. immer auf DTR before ich den FTDI platziere.
Ist das bei deinen Pro Mini nicht mehr so? Mach doch mal bitte ein gutes Foto von der neuen Version.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 14 Juli 2021, 22:38:19
Hallo Tom ,

Bisher habe ich immer darauf geachtet, dass die beiden Oberseiten zueinander standen, wie auf den Fotos in den verschiedenen Beiträgen dargestellt wird.
Da es funktionierte, hat mich die Beschriftung nicht interessiert, zumal beim FTDI-Adapter nur DTR erkennbar ist.

Fotos kann ich hier schlecht importieren.
Ich habe mal bei EBAY (nicht auf die Preise achten, gibt es in China günstiger) zwei Links herausgesucht, auf denen man die Unterschiede sehen kann.

Meine bisher verwendeten Module: https://www.ebay.de/itm/253093645576?hash=item3aed8e8d08:g:8OIAAOSwAWtb4LA2
Die neuen Module: https://www.ebay.de/itm/163974111931?hash=item262d9e62bb:g:XdIAAOSwOOFfHJvu

Die neuen funktionieren wie die alten, man muss nur den Adapter mit der Unterseite zur Oberseite vom Mini gewandt aufstecken.

Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 15 Juli 2021, 15:55:54
Hallo Werner,
Danke auf jeden Fall für die Info. Diese Variante hatte ich noch nicht gesehen.
Ich habe auch mal einen Hinweis im orangen Forum gepostet.
Im Bild links die alte Belegung, rechts die gedrehte. Bei der gedrehten steht auch nicht mehr DTR (wonach ich mich immer orientiert habe), sondern DTR ist dort mit "GRN" bezeichnet.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 15 Juli 2021, 23:39:21
Hallo Tom,
gerne lerne ich immer etwas dazu.
Klär mich doch bitte einmal auf, was das orangene Forum ist.
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: papa am 16 Juli 2021, 08:14:21
Das Homematic Forum (https://homematic-forum.de/forum/viewforum.php?f=76)
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 16 Juli 2021, 08:30:35
Danke
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 17 Juli 2021, 00:41:37
ich habe noch eine kleinen Info bei asksinpp.de zu diesem Thema im Abschnitt Software/Flashen eingestellt.
https://asksinpp.de/Grundlagen/02_software.html#arduino-mini-pro-mit-gedrehtem-ftdi-interface (https://asksinpp.de/Grundlagen/02_software.html#arduino-mini-pro-mit-gedrehtem-ftdi-interface)
Titel: Antw:AskSin++ Library
Beitrag von: papa am 17 Juli 2021, 17:30:27
Sehr gut - danke
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 19 August 2021, 00:07:10
Hallo zusammen,

jetzt brauche ich wieder Hilfe.
Ich habe einen HM-Schalter auf der AskSinPP Hardware aufgebaut und mit einer modifizierten Software (mit Papas Hilfe erstellt) geflashed.

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++  "HM-LC-Sw2-FM-WS-locSwitch-FHEM-v1.ino"
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2020-11-30 McShire modification for use of a switch instead of a button for local change of the actor-relay
//            connect switch to pin 9
// 2020-12-01 papa replace simulation of btn1 on pin 7 and connection pin 7 to pin 14 by a new methode shortPress()
//            in class InternalButton
//- -----------------------------------------------------------------------------------------------------------------------

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

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Switch.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

//set to 0x01 if the RELAY should be switched on LOW level
#define LOW_ACTIVE 0x00
#define RELAY1_PIN 5    // modified from A3, on my Experim.board LED2, to see relay state
#define RELAY2_PIN 6    // modified from A2

#define BUTTON1_PIN 14
#define BUTTON2_PIN 15

#define SWITCH1_PIN 9  // inserted McShire
#define SWITCH2_PIN 7  // Pin 9 und Pin 7 connect to switch, other switch pole to ground

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

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0x12, 0x09, 0x01},     // Device ID
  "JPLCSw2001",           // Device Serial
  {0x00, 0x09},           // Device Model
  0x24,                   // Firmware Version
  as::DeviceType::Switch, // Device Type
  {0x01, 0x00}            // Info Bytes
};

/**
   Configure the used hardware
*/
typedef AvrSPI<10, 11, 12, 13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<RadioSPI, 2> > Hal;

// setup the device with channel type and number of channels
typedef MultiChannelDevice<Hal, SwitchChannel<Hal, PEERS_PER_CHANNEL, List0>, 2> SwitchType;

// inserted by McShire
boolean localon1 = false;   // state of the Switch1, true = on, false = off
boolean localon2 = false;   // state of the Switch2, true = on, false = off


Hal hal;
SwitchType sdev(devinfo, 0x20);
ConfigButton<SwitchType> cfgBtn(sdev);
InternalButton<SwitchType> btn1(sdev, 1);
InternalButton<SwitchType> btn2(sdev, 2);

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if ( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    for ( uint8_t i = 1; i <= sdev.channels(); ++i ) {
      Peer ipeer(devid, i);
      sdev.channel(i).peer(ipeer);
    }
  }
}

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY1_PIN, LOW_ACTIVE);
  sdev.channel(2).init(RELAY2_PIN, LOW_ACTIVE);

  buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
  buttonISR(btn1, BUTTON1_PIN);
  buttonISR(btn2, BUTTON2_PIN);

  pinMode(SWITCH1_PIN, INPUT_PULLUP); // inserted by McShire
  pinMode(SWITCH2_PIN, INPUT_PULLUP); // inserted by McShire

  sdev.channels(2);
  initPeerings(first);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();


// Version v1 Modification created by papa
if( localon1 != digitalRead(SWITCH1_PIN) ) {
  delay(50);                                   //wait because of possible switch bouncing
  localon1 = !localon1;
  btn1.shortPress();
}
if( localon2 != digitalRead(SWITCH2_PIN) ) {
  delay(50);                                   //wait because of possible switch bouncing
  localon2 = !localon2;
  btn2.shortPress();
}

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


Leider funktionieren die lokalen Betätigungen button und switch nicht. Das Schalten über FHEM funktioniert einwandfrei.
Über den seriellen Monitor sehe ich folgenden Datenverkehr:

1. Ein- und Ausschalten im FHEM Web

23:19:49.371 -> -> 0E 97 A0 11 <IOdev> <HMdev> 02 01 C8 00 00  - 27334
23:19:49.510 -> <- 0E 97 80 02 <HMdev> <IOdev> 01 01 C8 00 39  - 27457
23:19:59.921 -> -> 0E 98 A0 11 <IOdev> <HMdev> 02 01 00 00 00  - 28008
23:20:00.062 -> <- 0E 98 80 02 <HMdev> <IOdev> 01 01 00 00 39  - 28135

d.h. IOdev und der HM-Schalter haben miteinander kommuniziert.
Das Relay schaltet einwandfrei

2. lokalen Switch ein- und ausschalten

23:28:45.389 -> -> 0B 0B 02 40 <HMdev> <HMdev> 01 06  - 31365
23:28:48.472 -> -> 0B 0C 02 40 <HMdev> <HMdev> 01 07  - 31936

d.h. keine Kommunikation mit dem IOdev, Relay schaltet nicht.

3. lokalen Taster betätigen

23:32:12.282 ->  debounce
23:32:12.329 ->  pressed
23:32:12.329 ->  released
23:32:12.329 -> -> 0B 0D 02 40 <HMdev> <HMdev> 01 08  - 33474
23:32:12.374 ->
23:32:12.420 ->  debounce
23:32:12.466 ->  released
23:32:12.466 -> -> 0B 0E 02 40 <HMdev> <HMdev> 01 09  - 33634
23:32:12.512 ->

auch hier keine Kommunikation mit dem IOdev, Relay schaltet nicht.

Das Problem scheint im peering zu liegen. Vermutlich durch verschiedenes Probieren ist
in den Registern des Mini Pro etwas Falsches in den Registern.

Bei einem anderen funktionierenden Schalter steht im List


Internals:
   ...
   chanNo     01
   device     WZ_UP
   peerList   self01
   CL:
     ...
     ...

     2021-01-17 17:29:44   RegL_01.        00:00 08:00 30:06 56:00 57:24
     2021-01-17 17:29:45   RegL_03.self01  00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:01 8B:14 8C:63
     2021-01-17 17:29:43   cfgState        updating
     ...
     ...
     2021-08-18 23:16:52   pct             0
     2021-08-17 09:21:36   peerList        self01
     2021-08-18 23:16:52   recentStateType ack
     2021-08-18 23:16:52   state           off
     2021-08-18 23:16:52   timedOn         off
     2021-08-18 23:16:51   trigLast        fhem:02
  ...
  ...
     cmds:
       TmplKey    self01:no:1629184896.98864
       TmplTs     1629184896.98864
       cmdKey     1:0:0::WZ_UP:00CB:01:self01
      ...
      ...
      ...
Attributes:
   comment    Ein Funk-Schaltaktor (Relais), der hinter einem Lichtschalter
verwendet werden kann. Das Relais kann remote mit FHEM ein- und ausgeschaltet werden und lokal durch den Lichtschalter. Der Lichtschalter muss dabei den Pin 9 nach Masse schalten und das Relais das Licht ein und ausschalten.
Ist ein Kanal von HM_120901 (Sketchbook\HM-LC-Sw2-FM-WS-locSwitch-FHEM-v1\HM-LC-Sw2-FM-WS-locSwitch-FHEM-v1.ino
Ist von HM_120901 umbenannt in WZ_UP und sitzt hinter dem Dimmer im Wohnzimmer.
   model      HM-LC-SW2-FM
   peerIDs    00000000,12090101
   room       HM_devices,Schalter,Test
   webCmd     statusRequest:toggle:on:off




Bei dem neuen Schalter steht hingegen statt self01 in den peer-Angaben immer das device WZ_UP, das ist aber der
oben gelistete Schalter


Internals:
   CFGFN     
   DEF        12090201
   FUUID      611d62e4-f33f-f21b-952d-7383af984dfbd61c
   NAME       HM_120902_Sw_01
   NOTIFYDEV  global
   NR         1333
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     HM_120902
   peerList   WZ_UP_Sw_01
   CL:
     Authenticated 1
...
...
READINGS:
     2021-08-18 23:19:59   CommandAccepted yes
     2021-08-18 23:18:18   RegL_01.         00:00 08:00 30:06 56:00 57:24
     2021-08-18 23:18:20   RegL_03.WZ_UP_Sw_01  00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:01 8B:14 8C:63
     2021-08-18 23:18:18   cfgState        updating
     2021-08-18 23:19:59   commState       CMDs_done
     2021-08-18 23:19:59   deviceMsg       off (to VCCU)
     2021-08-18 23:19:59   level           0
     2021-08-18 23:19:59   pct             0
     2021-08-18 23:18:19   peerList        WZ_UP_Sw_01
...
....



Nun die Frage:
Wie kann ich die peering Informationen auf den richtigen Stand bringen?
Ich habe das Wiki und dieses Forum durchsucht und viel probiert einschließlich alles löschen
und neu einrichten. Aber immer stand WZ_UP statt self01 in den peer Einträgen.
Hier den MiniPro austauschen geht nicht, da er bereits fest und eng zu den anderen Bauteilen
in die Platine für diesen Schalter eingelötet ist.

Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: papa am 19 August 2021, 07:38:04
Mach mal einen RESET - mindestens 6 Sekunden den Config-Taster drücken. Dannach wird alles im EEProm neu eingerichtet.
Alternative müsste auch ein set DEVICE reset aus FHEM funktionieren.

Code habe ich nur flüchtig überflogen.
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 19 August 2021, 08:02:58
Danke.
Reset war der richtige Hinweis.
Jetzt funktioniert alles.
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 19 August 2021, 10:56:44
Ich habe bei meiner Suche nach einer Lösung nirgendwo über den reset mit dem Konfi-button etwas gefunden oder gelesen.
Sollte man vielleicht eine Info dazu in der asksinpp.de einfügen?
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: Beetle2003 am 20 August 2021, 15:50:53
Zitat von: McShire am 19 August 2021, 10:56:44
Ich habe bei meiner Suche nach einer Lösung nirgendwo über den reset mit dem Konfi-button etwas gefunden oder gelesen.
Sollte man vielleicht eine Info dazu in der asksinpp.de einfügen?
Viele Grüße
Werner

Hallo Werner,

dieses gilt für alle Homematic Produkte. Konfig Taster drücken bis sich die Blinkfrequenz ändert und kurz loslassen und wieder drücken. Das setzt das Gerät in Werkszustand zurück.

Gruss

Ralf
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 25 August 2021, 21:12:57
Hallo Ralf,
danke für die Info. Das habe ich nicht gewusst.
Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: capt_bluebaer am 25 August 2021, 23:32:36
Hallo Leute,
ich habe 'mal 'ne Frage an die Experten.
Ich bin auf der Suche nach einer Lösung für einen 4-fach kombinierten Sensor/Aktor (HM_LC_SWX-SM / HM_SENSOR_RELAY) der sich verhält wie eine Radio-Button Funktion (so wie in Software GUI Programmierung). Soll heißen, dass z.B. Button 1 betätigt wird soll Relais 1 wie gewohnt aktivieren, gleichzeitig aber Relais 2 und 3 abfallen lassen.
Folgende Gedanken habe ich mir gemacht:
- Eine Verriegelung von Relais 2/3 ausgangsseitig durch Relais 1 scheidet aus - es gibt kein Feedback über deren Status.
- Eine RC-Kombination mit FET, die von Relais 1 für eine definierte Zeit die Eingänge 2 und 3 auf Low zieht wäre möglich.
- Eine Software-Lösung wäre mir am liebsten, entweder über Register-Einträge (ist mir allerdings nicht bekannt) oder irgendwelche Modifikationen im Source-Code.
- Ist der https://github.com/jp112sdl/HB-UNI-SenAct-4-4 (https://github.com/jp112sdl/HB-UNI-SenAct-4-4) von Jérôme die Lösung? Beim Peering von Button 1 mit Relais 2/3 muss aber sichergestellt sein, dass Button 1 nur bei "on" die Ausgänge 2/3 ausschaltet - also Toggle ist nicht die Lösung.
Bin gespannt auf Antworten.

Capt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 26 August 2021, 20:50:27
Das geht komplett mit den Peerings und richtigen Registersettings. Allerdings nur für die Buttons.
Siehe angehängten Sketch - initPeerings()
Titel: Antw:AskSin++ Library
Beitrag von: capt_bluebaer am 28 August 2021, 13:42:15
Funktioniert wie es soll. Mit den gleichen Registersettings der Buttons kann man die Logik auch nach gepeerten Fernbedienungen übertragen.
In Fhem genügen zwei notifys für meine Anwendung.
Danke papa, das hat mir ein Haufen Bastelarbeit mit dem Lötkolben erspart.  :)
Titel: Antw:AskSin++ Library
Beitrag von: McShire am 30 August 2021, 18:43:31
Hallo papa, hallo capt_bluebaer,

ich habe mal einen Sketch für einen 2-fach Sensor/Actor auf 4 Channels erweitert.
Mit papa's Hilfe wurde der Sketch so verändert, dass man ihn nicht nur mit buttons sondern auch mit einem Schalter lokal schalten kann.
Damit kann man das Modul hinter einem Lichtschalter verwenden um parallel zum Lichtschalter das Licht auch mit FHEM fernsteuern kann.

In diese Erweiterung habe ich softwaremäßig eine Verriegelung für Relay 2 und 3 eingebaut, das die Relays ausgeschaltet werden, wenn Relay 1 geschlossen wird.
Damit erfolgt das Ausschalten der Relays sowohl wenn R1 über die lokalen buttons als auch über FHEM eingeschaltet wird und wenn sie eingeschaltet
werden sollen, während R1 eigeschaltet ist, werden sie sofort wieder ausgeschaltet, so dass die Relais (je nach Verzögerung) gar nicht erst anziehen.

Fernsteuern kann man dann einfach, indem die Fernsteuerung über notify jeweils die Relays in FHEM schaltet
Hiermit ist man nicht mehr von den buttons und vom peering abhängig. Vielleicht kannst Du es gebrauchen.

Hier der Sketch:

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++  "HM-LC-Sw4-FM-on-1-off-2-3.ino"
// Modification from AsksinPP Scetch "HM-LC-Sw2-FM.ino" (papa)
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2020-11-30 McShire modification for use of a switch like a button for local change of the actor-relay
//            connect switch to pin 9 and GND
// 2021-08-30 McShire expand to 4 Channels
//            set Relay 2 / Relay 3 OFF when Relay 1 is ON
//- -----------------------------------------------------------------------------------------------------------------------

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

#define HM_LC_SW4_SM 0x00,0x03

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Switch.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

//set to 0x01 if the RELAY should be switched on LOW level
#define LOW_ACTIVE 0x00 
#define RELAY1_PIN 5    // modified from A3,
#define RELAY2_PIN 6    // modified from A2
#define RELAY3_PIN 7    // additional Channel
#define RELAY4_PIN 3    // additional Channel


#define BUTTON1_PIN 14
#define BUTTON2_PIN 15
#define BUTTON3_PIN 16
#define BUTTON4_PIN 17

#define SWITCH1_PIN 9  // inserted McShire
#define SWITCH2_PIN 18  // Pin 9 und Pin 18 connect to switch, other switch pole to ground, 18 statt 7


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

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0x12, 0x09, 0x41},     // Device ID
  "JPLCSw2041",           // Device Serial
  {HM_LC_SW4_SM},           // Device Model
  0x24,                   // Firmware Version
  as::DeviceType::Switch, // Device Type
  {0x01, 0x00}            // Info Bytes
};

/**
   Configure the used hardware
*/
typedef AvrSPI<10, 11, 12, 13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<RadioSPI, 2> > Hal;

// setup the device with channel type and number of channels
typedef MultiChannelDevice<Hal, SwitchChannel<Hal, PEERS_PER_CHANNEL, List0>, 4> SwitchType;

// inserted by McShire
// boolean localon = false;   // state of the Switch, true = on, false = off
boolean localon1 = false;   // state of the Switch1, true = on, false = off
boolean localon2 = false;   // state of the Switch2, true = on, false = off

Hal hal;
SwitchType sdev(devinfo, 0x20);
ConfigButton<SwitchType> cfgBtn(sdev);
InternalButton<SwitchType> btn1(sdev, 1);
InternalButton<SwitchType> btn2(sdev, 2);
InternalButton<SwitchType> btn3(sdev, 3);
InternalButton<SwitchType> btn4(sdev, 4);

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if ( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    for ( uint8_t i = 1; i <= sdev.channels(); ++i ) {
      Peer ipeer(devid, i);
      sdev.channel(i).peer(ipeer);
    }
  }
}

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
  bool first = sdev.init(hal);
  sdev.channel(1).init(RELAY1_PIN, LOW_ACTIVE);
  sdev.channel(2).init(RELAY2_PIN, LOW_ACTIVE);
  sdev.channel(3).init(RELAY3_PIN, LOW_ACTIVE);
  sdev.channel(4).init(RELAY4_PIN, LOW_ACTIVE);

  buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
  buttonISR(btn1, BUTTON1_PIN);
  buttonISR(btn2, BUTTON2_PIN);
  buttonISR(btn3, BUTTON3_PIN);
  buttonISR(btn4, BUTTON4_PIN);

pinMode(SWITCH1_PIN, INPUT_PULLUP); // inserted by McShire
pinMode(SWITCH2_PIN, INPUT_PULLUP); // inserted by McShire

  sdev.channels(4);
  initPeerings(first);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();

  // Version v1 Modification by McShire (virual button created by papa)
if( localon1 != digitalRead(SWITCH1_PIN) ) {
  delay(50);                                   //wait because of possible switch bouncing
  localon1 = !localon1;
  btn1.shortPress();
}
if( localon2 != digitalRead(SWITCH2_PIN) ) {
  delay(50);                                   //wait because of possible switch bouncing
  localon2 = !localon2;
  btn2.shortPress();
}

  // The following block was inserted by McShire,
  // if Relay 1 on then Relay 2 and Relay 3 off
  if (digitalRead(RELAY1_PIN) == HIGH) {        // Relay 1 state is on       
     if (digitalRead(RELAY2_PIN) == HIGH)      // Relay 2 state is on
         btn2.shortPress();                    // Relay 2 is set off (toggle)
     if (digitalRead(RELAY3_PIN) == HIGH)      // Relay 3 state is on
         btn3.shortPress();                    // Relay 3 is set off (toggle)
  }
 
  bool poll = sdev.pollRadio();
  if ( worked == false && poll == false ) {
    hal.activity.savePower<Idle<> >(hal);
  }
}



Viele Grüße
Werner
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 09 September 2021, 23:54:29
Moin in die Runde,

ich bin über den HB-LC-BL1-FM-2 (Jalousieaktor, 2 Kanäle) "gestolpert", den ich gut für meine Garagentorsteuerung benutzen kann. Um die jeweils aktuellen Aktor Positionen auch über eine Power-Off-Phase zu erhalten, habe ich mal ein FRAM mit eingebaut. Diese Justierfahrten nach PowerOn sind bei einem Garagentor mehr als nervig...
Ich gehe dabei davon aus, dass sowohl der Tormotor als auch der HB-LC-BL1-FM-2 über den selben Stromkreis versorgt werden und somit die letzte Postion im HB-LC-BL1-FM-2 auch der Realität entspricht. Ausnahmen sind Erstinstallation und ein Stromausfall während einer Torfahrt.

Aktivierung im Sketch mit :
#define use_I2C                yes                              //enable code for I2C communication
#define use_fram               yes                              //enable code for FRAM

Funktionsübersicht:
1. bei motorStop wird die aktuelle Position im FRAM gespeichert
2. bei PowerOn wir diese letzte Position aus dem FRAM gelesen und der Kanal per updateLevel richtig gesetzt.

Die zulässigen Schreibzyklen sind bei FRAM ja mehr als großzügig.

hier der Code, falls jemand Interesse hat :

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

//HB-LC-Bl1-FM-2 copied from https://pastebin.com/zPf89Jir
//with some modifications by bmw

/*Doc 2 channel blind actor


see FHEM-Forum  https://forum.fhem.de/index.php/topic,102920.msg965762.html#msg965762




*/

/*Doc definition needed in     HMConfig_AskSinPPCustom.pm
# 2 channel blind actor
$HMConfig::culHmModel{"F207"} = {name=>"HB-LC-BL1-FM-2",st=>'custom',cyc=>'',rxt=>'',lst=>'1,3:1p.2p',chn=>"Blind:1:2"};
$HMConfig::culHmChanSets{"HB-LC-BL1-FM-200"}{fwUpdate} = "<filename>";
$HMConfig::culHmChanSets{"HB-LC-BL1-FM-201"} = $HMConfig::culHmSubTypeSets{"blindActuator"};
$HMConfig::culHmChanSets{"HB-LC-BL1-FM-202"} = $HMConfig::culHmSubTypeSets{"blindActuator"};
$HMConfig::culHmRegModel{"HB-LC-BL1-FM-2"}   = {};
#$HMConfig::culHmRegModel{"HB-LC-BL1-FM-2"}   = {};
$HMConfig::culHmRegChan {"HB-LC-BL1-FM-201"} = $HMConfig::culHmRegType{blindActuator};
$HMConfig::culHmRegChan {"HB-LC-BL1-FM-202"} = $HMConfig::culHmRegType{blindActuator};
$customMsg{"HB-LC-BL1-FM-2"} = sub {
  my ($msg,$target) = @_;
  return $msg->processBlindStatus($target) if $msg->isStatus;
  return ();
};

# restart FHEM after changes !!
*/

/*Doc
status bei powerOn: stop:off, pct 0, level 0
see modifications bmw to include FRAM support

Tagets :
store actual channel position in FRAM - done
include some (4) additional position sensors


*/

//modified bmw
#define no 2 //only for compilers usage
#define yes 3 //only for compilers usage
#define inoperative 0 //only for compilers usage
#define separate 9 //only for compilers usage
#define checked 8 //only for compilers usage
#define German 2 //only for compilers usage
#define English 3 //only for compilers usage

#define use_I2C yes //enable code for I2C communication
#define use_fram yes //enable code for FRAM
//modified bmw end

#define HIDE_IGNORE_MSG //do not show packet dumps of received messages
#define FHEM_MODEL "HB-LC-BL1-FM-2" //modified bmw
#define serial_number "AskSinPP1A" //modified bmw

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

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Blind.h>

#if use_fram == yes //modified bmw
#define use_I2C yes //we need I2C
#endif
#if use_I2C == yes //modified bmw
#include <Wire.h> //include I2C 
//https://www.arduino.cc/en/Reference/Wire
#define I2C_STANDARD_MODE UL100000
#define I2C_FAST_MODE                        UL400000
#define I2C_FAST_MODE_PLUS_MODE             UL1000000
#define I2C_HIGH_SPEED_MODE                 UL3400000

//#define FRAM_I2C_MODES I2C_FAST_MODE_PLUS_MODE
#endif

#if use_fram == yes //modified bmw
#define fram_I2C_address 0x50 //I2C address - Doc only !

#define fram_storage_base 0x800 //storage base within FRAM
#define error_cond 220 //indicator for power lost while motion
#define fram_runtime_verbose 0
#define fram_init_verbose 0
#define fram_debug no
#include <MB85_FRAM.h> // https://github.com/Zanduino/MB85_FRAM

/* Doc Declare global variables and instantiate classes */
MB85_FRAM_Class FRAM; //Create an instance of the MB85_FRAM class

uint8_t fram_chips; //amount of memory chips ( 0 - 8)
uint8_t actual_position;
uint8_t couple_position;
#endif


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

#define ON_RELAY_PIN A0    //old 14
#define DIR_RELAY_PIN A1 //old 15

#define ON_RELAY2_PIN 16
#define DIR_RELAY2_PIN 17

#define UP_BUTTON_PIN 7
#define DOWN_BUTTON_PIN 6

#define UP_BUTTON2_PIN 5
#define DOWN_BUTTON2_PIN 3

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

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0x00, 0x05, 0xaf},            // Device ID
  serial_number,                  // Device Serial
  {0xF2, 0x07},                  // Device Model -> old {0x00, 0x05},
  0x24,                          // Firmware Version
  as::DeviceType::BlindActuator, // Device Type
  {0x01, 0x00}                    // Info Bytes
};

/**
   Configure the used hardware
*/
typedef AvrSPI<10, 11, 12, 13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<RadioSPI, 2> > Hal;

DEFREGISTER(BlindReg0, MASTERID_REGS, DREG_INTKEY, DREG_CONFBUTTONTIME, DREG_LOCALRESETDISABLE)

class BlindList0 : public RegList0<BlindReg0> {
  public:
    BlindList0 (uint16_t addr) : RegList0<BlindReg0>(addr) {}
    void defaults () {
      clear();
      // intKeyVisible(false);
      confButtonTime(0xff);
      // localResetDisable(false);
    }
};


class BlChannel : public ActorChannel<Hal, BlindList1, BlindList3, PEERS_PER_CHANNEL, BlindList0, BlindStateMachine> {
  private:
    uint8_t on_relay_pin;
    uint8_t dir_relay_pin;
  public:
    typedef ActorChannel<Hal, BlindList1, BlindList3, PEERS_PER_CHANNEL, BlindList0, BlindStateMachine> BaseChannel;

    BlChannel () : on_relay_pin(0), dir_relay_pin(0) {}
    virtual ~BlChannel () {}

    virtual void switchState(uint8_t oldstate, uint8_t newstate, uint32_t stateDelay) {
      BaseChannel::switchState(oldstate, newstate, stateDelay);
      if ( newstate == AS_CM_JT_RAMPON && stateDelay > 0 ) {
        motorUp();
      }
      else if ( newstate == AS_CM_JT_RAMPOFF && stateDelay > 0 ) {
        motorDown();
      }
      else {
        motorStop();
      }
    }

    void motorUp () {
digitalWrite(dir_relay_pin, HIGH);
digitalWrite(on_relay_pin, HIGH);

#if use_fram == yes //modified bmw
FRAM.write((fram_storage_base + on_relay_pin), error_cond); //presave channel error condition in FRAM
#endif
    }

    void motorDown () {
digitalWrite(dir_relay_pin, LOW);
digitalWrite(on_relay_pin, HIGH);

#if use_fram == yes //modified bmw
FRAM.write((fram_storage_base + on_relay_pin), error_cond); //presave channel error condition in FRAM
#endif
    }

    void motorStop () {
digitalWrite(dir_relay_pin, LOW);
digitalWrite(on_relay_pin, LOW);
 
#if fram_debug == yes //modified bmw
DPRINT("dir_relay_pin = ");DPRINTLN(dir_relay_pin); //used pin for actual channel
DPRINT("on_relay_pin = ");DPRINTLN(on_relay_pin); //used pin for actual channel
DPRINT("stop at position = ");DPRINTLN(BaseChannel::status()); //actual position for actual channel
DPRINT("Port 15 = ");DPRINTLN(DIR_RELAY_PIN);
DPRINT("Port AO = ");DPRINTLN(ON_RELAY_PIN);
/* Result
on_relay_pin (klein geschieben !) kann als offset zu fram_storage_base verwendet werden,
um die aktuelle Position des aktuellen Kanals zu speichern
*/
#endif

#if use_fram == yes //modified bmw
if (BaseChannel::status() < 201) { //value in proper range ?
FRAM.write((fram_storage_base + on_relay_pin), BaseChannel::status()); //save actual channel position in FRAM
};
#if fram_runtime_verbose > 1
DPRINT("stop at position = ");DPRINTLN(BaseChannel::status()); //actual position
#endif
#endif
    }

    void init (uint8_t op, uint8_t dp) {
on_relay_pin = op;
dir_relay_pin = dp;
pinMode(on_relay_pin, OUTPUT);
pinMode(dir_relay_pin, OUTPUT);
//motorStop(); //modified bmw
//not necessary, initial port state is LOW
//otherwise we'll save wrong position in FRAM
//at this point
BaseChannel::init();
 
#if use_fram == yes //modified bmw
FRAM.read((fram_storage_base + on_relay_pin), actual_position); //read actual channel position from FRAM
//proper range 0 - 200
//255 => first usage of FRAM or FRAM uninstalled
//220 => error e.g. power lost while in motion
//must be sync by drive to level 100 and 0
BaseChannel::updateLevel(actual_position); //set initial channel position from FRAM

#if fram_init_verbose > 3
DPRINT("set actual position to ");DPRINTLN(actual_position);
#endif
#endif
    }
};


// setup the device with channel type and number of channels
typedef MultiChannelDevice<Hal, BlChannel, 2, BlindList0> BlindType;

Hal hal;
BlindType sdev(devinfo, 0x20);
ConfigButton<BlindType> cfgBtn(sdev);
InternalButton<BlindType> btnup(sdev, 1);
InternalButton<BlindType> btndown(sdev, 2);
InternalButton<BlindType> btnup2(sdev, 3);
InternalButton<BlindType> btndown2(sdev, 4);

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if ( first == true ) {
    HMID devid;
    sdev.getDeviceID(devid);
    Peer p1(devid, 1);
    Peer p2(devid, 2);
    Peer p3(devid, 3);
    Peer p4(devid, 4);
    sdev.channel(1).peer(p1, p2);
    sdev.channel(2).peer(p3, p4);
  }
}

void setup () {
  //DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER); //modified bmw
  DINIT(57600, FHEM_MODEL); //modified bmw
  DPRINTLN(serial_number); //modified bmw
 
  //storage().setByte(0,0);
 
  #if use_I2C == yes //modified bmw
Wire.begin();
#endif

#if use_fram == yes //modified bmw
fram_chips = FRAM.begin(I2C_FAST_MODE_PLUS_MODE); //begin and return amount of installed memory chips
if(fram_chips == 0) {
#if fram_init_verbose > -1
DPRINTLN("found no FRAM-Chips");
#endif
} else {
#if fram_init_verbose > 1
DPRINT("support for ");DPRINT(fram_chips);DPRINTLN(" FRAM-Chips included");
DPRINT("total FRAM-Storage = ");DPRINTLN(FRAM.totalBytes());
#endif
};
#endif
 
 
  bool first = sdev.init(hal);
  sdev.channel(1).init(ON_RELAY_PIN, DIR_RELAY_PIN);
  sdev.channel(2).init(ON_RELAY2_PIN, DIR_RELAY2_PIN);

  buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
  buttonISR(btnup, UP_BUTTON_PIN);
  buttonISR(btndown, DOWN_BUTTON_PIN);
  buttonISR(btnup2, UP_BUTTON2_PIN);
  buttonISR(btndown2, DOWN_BUTTON2_PIN);

  initPeerings(first);
  sdev.initDone();
}

void loop() {

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



Als weitere Ergänzung benötige ich in diesem Device neben den 2 Blindchannels aber idealerweise noch 4 zusätzliche Sensorkanäle (open/close) und da komme ich mit meinen Kenntnissen überhaupt nicht weiter.  :'(
Ich brauche die, um Tor auf - Tor zu - Schlupftür auf - Tor mechanisch verriegelt anzuzeigen und auch um die Funktion zu steuern.

Könnte mir bitte jemand helfen ?

Moin und viele Grüße !
Bernd
Titel: Antw:AskSin++ Library
Beitrag von: papa am 10 September 2021, 21:57:58
Schau Dir mal das folgende Beispiel an.
https://github.com/pa-pa/AskSinPP/blob/62faa59d718c23e3831a6ddfa93401a89e272200/examples/custom/HB-SW2-SENS/HB-SW2-SENS.ino#L76
Da werden 2 SwitchChannel und ein SensorChannel in einem Device verwendet. Dazu sind die Channel in einen VirtualChannel einzubetten. Du müsstest das dann mit den 2 BlindChannel und 4 TwoStateChannel machen. Allerdings vermute ich, dass der Speicher des 328 zu knapp werden könnte.
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 11 September 2021, 02:06:20
Hi papa,

danke für Deine schnelle Antwort. Werde ich versuchen.
ZitatSchau Dir mal das folgende Beispiel an.
https://github.com/pa-pa/AskSinPP/blob/62faa59d718c23e3831a6ddfa93401a89e272200/examples/custom/HB-SW2-SENS/HB-SW2-SENS.ino#L76
Da werden 2 SwitchChannel und ein SensorChannel in einem Device verwendet. Dazu sind die Channel in einen VirtualChannel einzubetten.

Ich habe im ersten Schritt schon mal die Sensoren auf 4 erhöht und auch die Änderungen in der HMConfigAskSinPPCustom.pm gemacht. Das sieht im FHEM schon mal gut aus, die Sensoren muss ich noch testen.

Der Rest
ZitatDu müsstest das dann mit den 2 BlindChannel und 4 TwoStateChannel machen.
ist für mich deutlich schwieriger, weil ich bei den Class-Definitionen relativ schnell "den Wald vor lauter Bäumen nicht mehr sehe" und Zuordnungsschwierigkeiten habe. Bin leider nicht der C++ Profi, sondern im Lernmodus.

Mal sehen, ich mache morgen weiter...

Moin
Bernd


Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 12 September 2021, 21:14:14
Moin papa,

ok, der nächste Schritt. Wieder beginnend mit dem Original-Sketch habe ich die beiden Switche rausgenommen und die HMConfigAskSinPPCustom.pm angepaßt. Im Ergebnis habe ich ein funtionierendes Device mit nur 1 Sensor-Channel bekommen. Das macht Mut...

Beim Versuch darin jetzt 1 BlindChannel einzubauen, bin ich kläglich gescheitert. Ich bin davon ausgegangen, dass ich "nur" die Kanaldefinitionen (Blind) in das vorhandene Mixdevice integrieren muss. Aber meine Analyse, was nun Kanaldefinition und was Devicedefinition ist, ist wohl nicht so ganz richtig. Copy-Basis für den Blind ist die HM-LC-Bl1-FM

https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-LC-Bl1-FM/HM-LC-Bl1-FM.ino (https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-LC-Bl1-FM/HM-LC-Bl1-FM.ino)

Jedenfalls steh ich auf dem Schlauch und komme nicht weiter. :'(

Könntest Du bitte mal einen Blick auf den Code werfen und mir einen Tipp geben ?

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2017-10-24 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// ci-test=yes board=328p aes=no
//- -----------------------------------------------------------------------------------------------------------------------

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

//copied from https://github.com/pa-pa/AskSinPP/blob/master/examples/custom/HB-SW2-SENS/HB-SW2-SENS.ino

/* HMConfigCustom_bmw.pm
#defined from F911 with modifications

$HMConfig::culHmModel{"F912"} = {name=>"HB-SW3-SENS",st=>'custom',cyc=>'',rxt=>'',lst=>'1,3:1p.2p,4:3p',chn=>"Blind:1:1,Sen:2:2"};
$HMConfig::culHmRegModel{"HB-SW3-SENS"}   = { intKeyVisib=>1, cyclicInfoMsg=>1, sabotageMsg=>1 };
$HMConfig::culHmChanSets{"HB-SW3-SENS00"}{fwUpdate} = "<filename>";
$HMConfig::culHmChanSets{"HB-SW3-SENS01"} = $HMConfig::culHmSubTypeSets{"blindActuator"};
#$HMConfig::culHmChanSets{"HB-SW3-SENS02"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-SW3-SENS02"} = $HMConfig::culHmSubTypeSets{"THSensor"};
#$HMConfig::culHmChanSets{"HB-SW3-SENS04"} = $HMConfig::culHmSubTypeSets{"THSensor"};
#$HMConfig::culHmChanSets{"HB-SW3-SENS05"} = $HMConfig::culHmSubTypeSets{"THSensor"};
#$HMConfig::culHmChanSets{"HB-SW3-SENS06"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmRegChan {"HB-SW3-SENS01"} = $HMConfig::culHmRegType{blindActuator};
#$HMConfig::culHmRegChan {"HB-SW3-SENS02"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-SW3-SENS02"} = $HMConfig::culHmRegType{threeStateSensor};
#$HMConfig::culHmRegChan {"HB-SW3-SENS04"} = $HMConfig::culHmRegType{threeStateSensor};
#$HMConfig::culHmRegChan {"HB-SW3-SENS05"} = $HMConfig::culHmRegType{threeStateSensor};
#$HMConfig::culHmRegChan {"HB-SW3-SENS06"} = $HMConfig::culHmRegType{threeStateSensor};
$customMsg{"HB-SW3-SENS"} = sub {
  my ($msg,$target) = @_;
  my $channel = $msg->channel;
  #return $msg->processThreeState($target) if $channel == 3;
  return $msg->processThreeState($target) if $channel == 2;
  return $msg->processSwitchStatus($target) if $msg->isStatus;
  return ();
};





*/


/*trying to include blindchannel

Forum https://forum.fhem.de/index.php/topic,57486.1560.html
Da werden 2 SwitchChannel und ein SensorChannel in einem Device verwendet.
Dazu sind die Channel in einen VirtualChannel einzubetten.

Du müsstest das dann mit den 2 BlindChannel und 4 TwoStateChannel machen.

Step 1
alle switche raus, nur noch ein Mixdevice mit einem SensorChannel
Model F911 HMConfigCustom_bmw.pm angepasst

=> funktioniert !
SENS1_PIN => open   / closed
SENS2_PIN => tiltet / closed

Step 2
BlindChannel einbauen von HB-LC-Bl1-FM-2
Model F912 HMConfigCustom_bmw.pm angepasst

*/


#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

//switch raus -  #include <Switch.h>
#include <Blind.h> //added bmw
#include <ThreeState.h>

#define CONFIG_BUTTON_PIN 8
#define LED_PIN           4

//switch raus -  #define RELAY1_PIN 17
//switch raus -  #define RELAY2_PIN 16

#define SENS1_PIN A1 //old 6
#define SENS2_PIN A3 //old 3

#define ON_RELAY_PIN A0    //old 14
#define DIR_RELAY_PIN A2 //old 15

#define ON_RELAY2_PIN 16
#define DIR_RELAY2_PIN 17

#define UP_BUTTON_PIN 7
#define DOWN_BUTTON_PIN 6

#define UP_BUTTON2_PIN 5
#define DOWN_BUTTON2_PIN 3
// number of available peers per channel
#define PEERS_PER_CHANNEL 6

// number of available peers per channel

//switch raus -  #define PEERS_PER_SWCHANNEL  6
#define PEERS_PER_SENSCHANNEL 10

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

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x63,0xF9,0x12},       // Device ID //modified bmw
    "HBSwSen003",           // Device Serial //modified bmw
    {0xf9,0x12},            // Device Model //modified bmw
    0x01,                   // Firmware Version
    //bmw changed -  as::DeviceType::Switch, // Device Type
    //as::DeviceType::BlindActuator,
as::DeviceType::Switch,
{0x01,0x00}             // Info Bytes
};

// Configure the used hardware
typedef AvrSPI<10,11,12,13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>,NoBattery,Radio<RadioSPI,2> > Hal;

Hal hal;

DEFREGISTER(Reg0,DREG_INTKEY,DREG_CYCLICINFOMSG,MASTERID_REGS)
class SwSensList0 : public RegList0<Reg0> {
public:
  SwSensList0(uint16_t addr) : RegList0<Reg0>(addr) {}
};

DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)
class SensList1 : public RegList1<Reg1> {
public:
  SensList1 (uint16_t addr) : RegList1<Reg1>(addr) {}
  void defaults () {
    clear();
    msgForPosA(1); // CLOSED
    msgForPosB(2); // OPEN
    msgForPosC(3); // TILTED
    // aesActive(false);
    // eventDelaytime(0);
    ledOntime(100);
    transmitTryMax(6);
  }
};

DEFREGISTER(BlindReg0,MASTERID_REGS,DREG_INTKEY,DREG_CONFBUTTONTIME,DREG_LOCALRESETDISABLE)
class BlindList0 : public RegList0<BlindReg0> {
public:
  BlindList0 (uint16_t addr) : RegList0<BlindReg0>(addr) {}
  void defaults () {
    clear();
    // intKeyVisible(false);
    confButtonTime(0xff);
    // localResetDisable(false);
  }
};

class BlChannel : public ActorChannel<Hal,BlindList1,BlindList3,PEERS_PER_CHANNEL,BlindList0,BlindStateMachine> {
public:
  //nach oben geschoben, richtig ??  - typedef ActorChannel<Hal,BlindList1,BlindList3,PEERS_PER_CHANNEL,BlindList0,BlindStateMachine> BaseChannel;

  BlChannel () {}
  virtual ~BlChannel () {}

  virtual void switchState(uint8_t oldstate,uint8_t newstate, uint32_t stateDelay) {
    BaseChannel::switchState(oldstate, newstate, stateDelay);
    if( newstate == AS_CM_JT_RAMPON && stateDelay > 0 ) {
      motorUp();
    }
    else if( newstate == AS_CM_JT_RAMPOFF && stateDelay > 0 ) {
      motorDown();
    }
    else {
      motorStop();
    }
  }

  void motorUp () {
    digitalWrite(DIR_RELAY_PIN,HIGH);
    digitalWrite(ON_RELAY_PIN,HIGH);
  }

  void motorDown () {
    digitalWrite(DIR_RELAY_PIN,LOW);
    digitalWrite(ON_RELAY_PIN,HIGH);
  }

  void motorStop () {
    digitalWrite(DIR_RELAY_PIN,LOW);
    digitalWrite(ON_RELAY_PIN,LOW);
  }

  void init () {
    pinMode(ON_RELAY_PIN,OUTPUT);
    pinMode(DIR_RELAY_PIN,OUTPUT);
   
motorStop();
    BaseChannel::init();
  }
};

//switch raus -  typedef SwitchChannel<Hal,PEERS_PER_SWCHANNEL,SwSensList0>  SwChannel;
typedef ActorChannel<Hal,BlindList1,BlindList3,PEERS_PER_CHANNEL,BlindList0,BlindStateMachine> BaseChannel;
typedef ThreeStateChannel<Hal,SwSensList0,SensList1,DefList4,PEERS_PER_SENSCHANNEL> SensChannel;


//bmw changed - class MixDevice : public ChannelDevice<Hal,VirtBaseChannel<Hal,SwSensList0>,3,SwSensList0> {
class MixDevice : public ChannelDevice<Hal,VirtBaseChannel<Hal,SwSensList0>,2,SwSensList0> {
#define CYCLETIME seconds2ticks(60UL*60*24) // at least one message per day
class CycleInfoAlarm : public Alarm {
  MixDevice& dev;
public:
  CycleInfoAlarm (MixDevice& d) : Alarm (CYCLETIME), dev(d) {}
  virtual ~CycleInfoAlarm () {}

  void trigger (AlarmClock& clock)  {
    set(CYCLETIME);
    clock.add(*this);
    dev.sensorChannel().changed(true); // force StatusInfoMessage to central
  }
} cycle;

public:
  //switch raus -  VirtChannel<Hal,SwChannel,SwSensList0> c1,c2;
  //bmw changed - VirtChannel<Hal,SensChannel,SwSensList0> c3;
  VirtChannel<Hal,BaseChannel,BlindList1> c1;
  VirtChannel<Hal,SensChannel,SwSensList0> c2;
public:
  //bmw changed - typedef ChannelDevice<Hal,VirtBaseChannel<Hal,SwSensList0>,3,SwSensList0> DeviceType;
  typedef ChannelDevice<Hal,VirtBaseChannel<Hal,SwSensList0>,2,SwSensList0> DeviceType; //Anzahl Kanäle = 2
  MixDevice (const DeviceInfo& info,uint16_t addr) : DeviceType(info,addr), cycle(*this) {
    //switch raus -  DeviceType::registerChannel(c1,1);
    //switch raus -  DeviceType::registerChannel(c2,2);
    //bmw changed - DeviceType::registerChannel(c3,3);
DeviceType::registerChannel(c1,1);
DeviceType::registerChannel(c2,1);
  }
  virtual ~MixDevice () {}

  //switch raus -  SwChannel& switch1Channel ()  { return c1; }
  //switch raus -  SwChannel& switch2Channel ()  { return c2; }
  //bmw changed -  SensChannel& sensorChannel () { return c3; }
  BaseChannel& channel(1) ()  { return c1; }                        //das muss der blindchannel werden, aber wie ???

  SensChannel& sensorChannel () { return c2; }

  virtual void configChanged () {
    if( /*this->getList0().cycleInfoMsg() ==*/ true ) {
      DPRINTLN("Activate Cycle Msg");
      sysclock.cancel(cycle);
      cycle.set(CYCLETIME);
      sysclock.add(cycle);
    }
    else {
      DPRINTLN("Deactivate Cycle Msg");
      sysclock.cancel(cycle);
    }
  }
};
MixDevice sdev(devinfo,0x20);
ConfigButton<MixDevice> cfgBtn(sdev);
InternalButton<BlindType> btnup(sdev,1);
InternalButton<BlindType> btndown(sdev,2);

void initPeerings (bool first) {
  // create internal peerings - CCU2 needs this
  if( first == true ) {
    sdev.channel(1).peer(btnup.peer(),btndown.peer());
  }
}


void setup () {
  //DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER); //changed bmw
  DINIT(57600,"Test to include Blindchannel"); //changed bmw
  sdev.init(hal);
  //switch raus -  sdev.switch1Channel().init(RELAY1_PIN);
  //switch raus -  sdev.switch2Channel().init(RELAY2_PIN);
  sdev.channel(1).init(ON_RELAY_PIN, DIR_RELAY_PIN);
  sdev.sensorChannel().init(SENS1_PIN,SENS2_PIN);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  sdev.initDone();
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<Idle<> >(hal);
  }
}



und hier die Fehlermeldungen vom IDE

Arduino: 1.8.13 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328P (3.3V, 8 MHz)"

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino: In member function 'virtual void BlChannel::switchState(uint8_t, uint8_t, uint32_t)':

HB-SW2-SENS:170:18: error: 'switchState' is not a member of 'as::ActorChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, 6, BlindList0, as::BlindStateMachine>::BaseChannel {aka as::Channel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, as::EmptyList, 6, BlindList0, as::EmptyList>}'

     BaseChannel::switchState(oldstate, newstate, stateDelay);

                  ^~~~~~~~~~~

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino: In member function 'void BlChannel::init()':

HB-SW2-SENS:202:18: error: 'init' is not a member of 'as::ActorChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, 6, BlindList0, as::BlindStateMachine>::BaseChannel {aka as::Channel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, as::EmptyList, 6, BlindList0, as::EmptyList>}'

     BaseChannel::init();

                  ^~~~

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino: At global scope:

HB-SW2-SENS:247:16: error: expected ';' at end of member declaration

   BaseChannel& channel(1) ()  { return c1; }                        //das muss der blindchannel werden, aber wie ???

                ^~~~~~~

HB-SW2-SENS:247:24: error: expected unqualified-id before numeric constant

   BaseChannel& channel(1) ()  { return c1; }                        //das muss der blindchannel werden, aber wie ???

                        ^

HB-SW2-SENS:247:24: error: expected ')' before numeric constant

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino: In constructor 'MixDevice::MixDevice(const as::DeviceInfo&, uint16_t)':

HB-SW2-SENS:239:34: error: no matching function for call to 'MixDevice::registerChannel(as::VirtChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::ActorChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, 6, BlindList0, as::BlindStateMachine>, as::BlindList1>&, int)'

  DeviceType::registerChannel(c1,1);

                                  ^

In file included from D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/Blind.h:9:0,

                 from D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino:76:

D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/MultiChannelDevice.h:43:8: note: candidate: void as::ChannelDevice<HalType, ChannelType, ChannelCount, List0Type>::registerChannel(ChannelType&, uint8_t) [with HalType = as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >; ChannelType = as::VirtBaseChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, SwSensList0>; int ChannelCount = 2; List0Type = SwSensList0; uint8_t = unsigned char]

   void registerChannel(ChannelType& ch,uint8_t num) {

        ^~~~~~~~~~~~~~~

D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/MultiChannelDevice.h:43:8: note:   no known conversion for argument 1 from 'as::VirtChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::ActorChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, 6, BlindList0, as::BlindStateMachine>, as::BlindList1>' to 'as::VirtBaseChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, SwSensList0>&'

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino: At global scope:

HB-SW2-SENS:266:16: error: 'BlindType' was not declared in this scope

InternalButton<BlindType> btnup(sdev,1);

                ^~~~~~~~~

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino:266:16: note: suggested alternative: 'BlindReg0'

InternalButton<BlindType> btnup(sdev,1);

                ^~~~~~~~~

                BlindReg0

HB-SW2-SENS:266:25: error: template argument 1 is invalid

InternalButton<BlindType> btnup(sdev,1);

                         ^

HB-SW2-SENS:267:16: error: 'BlindType' was not declared in this scope

InternalButton<BlindType> btndown(sdev,2);

                ^~~~~~~~~

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino:267:16: note: suggested alternative: 'BlindReg0'

InternalButton<BlindType> btndown(sdev,2);

                ^~~~~~~~~

                BlindReg0

HB-SW2-SENS:267:25: error: template argument 1 is invalid

InternalButton<BlindType> btndown(sdev,2);

                         ^

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino: In function 'void initPeerings(bool)':

HB-SW2-SENS:272:19: error: no match for call to '(BaseChannel {aka as::ActorChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, 6, BlindList0, as::BlindStateMachine>}) (int)'

     sdev.channel(1).peer(btnup.peer(),btndown.peer());

                   ^

HB-SW2-SENS:272:32: error: request for member 'peer' in 'btnup', which is of non-class type 'int'

     sdev.channel(1).peer(btnup.peer(),btndown.peer());

                                ^~~~

HB-SW2-SENS:272:47: error: request for member 'peer' in 'btndown', which is of non-class type 'int'

     sdev.channel(1).peer(btnup.peer(),btndown.peer());

                                               ^~~~

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino: In function 'void setup()':

HB-SW2-SENS:283:17: error: no match for call to '(BaseChannel {aka as::ActorChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, 6, BlindList0, as::BlindStateMachine>}) (int)'

   sdev.channel(1).init(ON_RELAY_PIN, DIR_RELAY_PIN);

                 ^

In file included from D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/Device.h:12:0,

                 from D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/MultiChannelDevice.h:9,

                 from D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/Blind.h:9,

                 from D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino:76:

D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/Channel.h: In instantiation of 'void as::VirtChannel<HalType, ChannelType, List0Type>::setup(as::Device<HalType, List0Type>*, uint8_t, uint16_t) [with HalType = as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >; ChannelType = as::ActorChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, 6, BlindList0, as::BlindStateMachine>; List0Type = as::BlindList1; uint8_t = unsigned char; uint16_t = unsigned int]':

D:\Arduino\IDE\Sketchbook\AskSin\HB-SW2-SENS\HB-SW2-SENS.ino:295:1:   required from here

D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/Channel.h:415:85: error: no matching function for call to 'as::ActorChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, 6, BlindList0, as::BlindStateMachine>::setup(as::Device<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1>*&, uint8_t&, uint16_t&)'

   virtual void setup(Device<HalType,List0Type>* dev,uint8_t number,uint16_t addr) { ch.setup(dev,number,addr); }

                                                                                     ^~

D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/Channel.h:285:8: note: candidate: void as::ActorChannel<HalType, List1Type, List3Type, PeerCount, List0Type, StateMachine, List2Type>::setup(as::Device<HalType, List0Type>*, uint8_t, uint16_t) [with HalType = as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >; List1Type = as::BlindList1; List3Type = as::BlindList3; int PeerCount = 6; List0Type = BlindList0; StateMachine = as::BlindStateMachine; List2Type = as::EmptyList; uint8_t = unsigned char; uint16_t = unsigned int]

   void setup(Device<HalType,List0Type>* dev,uint8_t number,uint16_t addr) {

        ^~~~~

D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master/Channel.h:285:8: note:   no known conversion for argument 1 from 'as::Device<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1>*' to 'as::Device<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, BlindList0>*'

Mehrere Bibliotheken wurden für "AskSinPP.h" gefunden

Benutzt: D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-master

Nicht benutzt: D:\Arduino\IDE\Sketchbook\libraries\AskSinPP-V4

exit status 1

'switchState' is not a member of 'as::ActorChannel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, 6, BlindList0, as::BlindStateMachine>::BaseChannel {aka as::Channel<as::AskSin<as::StatusLed<4>, as::NoBattery, as::Radio<as::AvrSPI<10, 11, 12, 13>, 2> >, as::BlindList1, as::BlindList3, as::EmptyList, 6, BlindList0, as::EmptyList>}'

Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.


Ich sehe nicht die Fehler, die zu diesen Meldungen führen.

Moin
Bernd



Titel: Antw:AskSin++ Library
Beitrag von: Horti am 12 September 2021, 22:26:36
hier ist ein ähnliches Projekt:
https://homematic-forum.de/forum/viewtopic.php?f=76&t=69365 (https://homematic-forum.de/forum/viewtopic.php?f=76&t=69365)
Titel: Antw:AskSin++ Library
Beitrag von: tndx am 03 Oktober 2021, 14:40:47
Ich versuche gerade diesen Sketch zu kompilieren:

https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/RWE/HM-RC-8_BRC8/HM-RC-8_BRC8.ino (https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/RWE/HM-RC-8_BRC8/HM-RC-8_BRC8.ino)

Ohne Änderungen läuft alles problemlos. Versuche ich allerdings AES zu aktivieren mit

#define USE_AES
#define HM_DEF_KEY <...>
#define HM_DEF_KEY_INDEX 0


so ist die hex-Datei identisch zu der ohne AES. Auch die Deaktivierung des Defines "SENSOR_ONLY" ändert nichts an diesem Verhalten.

Muss ich noch irgendwas ändern?
Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Oktober 2021, 23:30:26
Zitat von: tndx am 03 Oktober 2021, 14:40:47

Ohne Änderungen läuft alles problemlos. Versuche ich allerdings AES zu aktivieren mit

#define USE_AES
#define HM_DEF_KEY <...>
#define HM_DEF_KEY_INDEX 0


so ist die hex-Datei identisch zu der ohne AES. Auch die Deaktivierung des Defines "SENSOR_ONLY" ändert nichts an diesem Verhalten.

Muss ich noch irgendwas ändern?
Wo sind die Defines ? Sie müssen ganz oben stehen.
Titel: Antw:AskSin++ Library
Beitrag von: tndx am 05 Oktober 2021, 07:50:48
Zitat von: papa am 03 Oktober 2021, 23:30:26
Wo sind die Defines ? Sie müssen ganz oben stehen.

Ganz oben heisst wohl, bevor AskSinPP.h eingebunden wird?

So funktioniert das jedenfalls, vielen Dank!
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 27 Dezember 2021, 15:52:42
Moin,

ich habe mal eine Frage zur AskSinPP.h
In der class AskSinBase (provides basic methods for general use) gibt es die sub readPin, die offensichtlich für Input-Services genutzt wird. Dort wird bei jedem Aufruf der Portmode
zunächst auf INPUT_PULLUP gesetzt,
dann der Input gelesen
und anschließend der Portmode auf OUTPUT und der Port auf LOW gesetzt.

Somit wechselt der Port ständig von einem hochohmigen in einen niederohmigen Zustand.
Mein Problem: Ich will eine Lichtschranke als Sensor anschließen, die Vcc als Signal liefert durch diesen Programmablauf nun laufend kurzgeschlossen wird. Keine Ahnung, wie lange dass die Lichtschranke und der Mini wohl aushalten werden...

Meine Frage: welchem Zweck dient dieses temporäre Umsetzen eines Input-Ports auf Output ?
Da ja außerdem noch eine Steuerungsmöglichkeit der externen Hardware über einen zweiten Port vorgesehen ist - könnte/sollte man nicht den "Kuzschluss" mit dieser Steuerung kombinieren, um so einen eindeutigen Input-Service zu erhalten ?

Ein Lösungsvorschlag aus meiner wirklich sehr eingeschränkten Sicht:


....
//pinMode(pinnr,OUTPUT);
        //digitalWrite(pinnr,LOW);

    if( enablenr != 0 && enablenr != 0xff) {
      digitalWrite(enablenr,LOW);
 
      pinMode(pinnr,OUTPUT);
      digitalWrite(pinnr,LOW);
 
 
    }
...


Bitte, ich bräuchte Eure Hilfe, um mit meinem Projekt voranzukommen.
Moin
Bernd
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Dezember 2021, 00:09:56
Der Code soll Strom sparen, wenn der Sensor den Eingang dauerhaft auf LOW zieht. Du kannst doch einfach die Klasse im Sketch ableiten und die Methode überschreiben. Dann kannst Du das Umachalten einfach rausnehmen.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 28 Dezember 2021, 00:36:28
Wäre es nicht geschickter, den Pin auf Input/no-pullup zu konfigurieren statt auf Low?
Das wäre High-Z, also stromneutral, ist aber nicht ganz so hart wie das Low was je nach input Pegel/Device ja auch einen hohen Strom verursachen kann, bis hin zum Kurzschluss wenn es z.B. eine Push-Pull Endstufe ist die da dranhängt.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 28 Dezember 2021, 12:56:38
Müsste mal jemand ausprobieren und durchmessen.
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 30 Dezember 2021, 00:21:17
Moin,
erst einmal vielen Dank für Eure Informationen !

ZitatDu kannst doch einfach die Klasse im Sketch ableiten und die Methode überschreiben.

Meine Antwort hat etwas länger gedauert, weil ich als IT-Oldtimer und C++Neuling erst einmal lernen mußte, was eigentlich das Ableiten einer Klasse ist und was da wie funktionieren soll. Habe viel gelesen und viel mit einem Testprogramm ausprobiert. Soweit erst mal verstanden, jedenfalls den Anfangslevel.

Bei der Testimplementation in die AskSinPP.h habe ich dann gesehen, dass die Methoden der AskSinBase alle static sind und ich habe auch nirgends das Bilden eines Objekts für AskSinBase finden können. Insofern kenne ich auch keinen Objektnamen für den Aufruf der Routinen.

Die Methode "readPin" wird von "measure" der Klassen "OnePinPosition" bzw. "TwoPinPosition" aus der Datei PinPosition.h heraus aufgerufen und zwar per direct adressing (oder wie nennt man das?) auf die Base-Class.      Beispiel: AskSinBase::readPin(sens1);

Damit ist nach meinem bisherigen Wissen  :( nix mehr mit Funktionsänderung ohne Source-Änderungen in der Lib via Ableitung. Falls ich falsch liege oder es noch ein paar Tricks gibt, wäre ich für Hilfestellung wirklich dankbar !!

ZitatDer Code soll Strom sparen, wenn der Sensor den Eingang dauerhaft auf LOW zieht.

Ok, danke für die Info. Diese Stromreduzierung spielt sich ja in geringen Größenordnungen ab und wäre wohl auch nur im Batteriebetrieb interessant. Dann wäre mein Vorschlag, den Code über die Definition USE_BATTERY_MODE zu aktivieren und deaktivieren.
Damit würde beim BATTERY_MODE dann alles durchgängig entsprechend definiert werden und im "Normal-Mode" hätte man reinrassige Input-Pins.
#ifdef USE_BATTERY_MODE
    pinMode(pinnr,OUTPUT);
    digitalWrite(pinnr,LOW);
#endif


Den Vorschlag von Tom Major finde ich gut, da vermutlich auch noch andere Anwender auf die Idee kommen könnten, statt eines einfachen Tasters einen aktiven Sensor anzuschließen.
Ich kann leider mangels vernünftiger Meßgeräte nix messen, sorry !

Edit:
oder vielleicht noch besser, da kompatibel
#ifndef USE_HIGH_IMPEDANCE_INPUT
    pinMode(pinnr,OUTPUT);
    digitalWrite(pinnr,LOW);
#endif


Titel: Antw:AskSin++ Library
Beitrag von: papa am 30 Dezember 2021, 20:57:58
Die statische Methode in AskSinBase kann nicht überladen werden, aber die measure() in OnePinPosition bzw. TwoPinPosition.

Eine generelle Lösung wäre natürlich am besten. Allerdings würde ich nur ungern weitere #defines einbauen. Man ,üsste mal Toms Vorschlag ausprobieren.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 31 Dezember 2021, 12:39:24
Ein #define wäre auch aus meiner Sicht eine schlechte Lösung, das müsste auch gut dokumentiert werden sonst übersieht man es.

Außerdem stimme ich papa zu, natürlich sollte man das am RHS testen bevor man da was ändert, ich habe keine RHS im Einsatz.

Aber nochmal zum Grund warum dieser Code überhaupt so drin ist:
Zitat von: papa am 28 Dezember 2021, 00:09:56
Der Code soll Strom sparen, wenn der Sensor den Eingang dauerhaft auf LOW zieht.

habe mir gerade noch mal den RHS3 Schaltplan und das TLE4913 datasheet angeschaut. Der TLE4913 ist ein Open-Drain Device und es werden 1M Widerstände als pull-up eingesetzt.

Was genau soll es bringen, den AVR Eingang während der gesamten Zeit auf aktiv Low zu legen (außer den kurzen Augenblick der Messung)?
- falls der TLE Low am Ausgang hat ist das aktive AVR Low irrelevant da das Low bereits da ist
- falls der TLE High(open-drain) hat fließt ein extra Strom durch den 1M R, nur wegen dem aktiven AVR Low, das ist doch unerwünscht, oder?
- falls kein Open-Drain Sensor dran ist sondern einer mit einer Push-Pull Stufe knallt es wenn dieser seinen Ausgang auf High legt
Titel: Antw:AskSin++ Library
Beitrag von: papa am 31 Dezember 2021, 15:00:22
Das ist/war doch für den RHS mit den Reed-Kontakten. Und natürlich auch für alle anderen Geräte, die mittels Schalten auf GND den Zustand signalisieren.
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 01 Januar 2022, 02:42:52
Edit:
Ich wünsche allen ein frohes und erfolgreiches neues Jahr !!!!


ich habe gerade mal mit einen absolut minimalisten Versuchsaufbau gemessen. Zur Güte des Meßgerätes sag ich lieber nix.... Aber in Größenordnungen wird es wohl stimmen.

Hardware: Pro MINI 3.3V
Sketch: HB-UNI-SenAct 4-4-SC von Jerome
Gemessen habe ich den input current an einem pin ohne Kontakt oder so. Also Input-Kurzschluß.
Modifiziert wurde in der AskSinPP.h die Methode readpin

Ergebnisse für einen passiven Sensor der gegen GND schaltet (Reedkontakt, Taster etc) :
INPUT_PULLUP         98 uA
INPUT                       0 uA
OUTPUT   (LOW)        0 uA
0 uA ist wohl nicht Null, sondern mein Meßgerät kriegt das nicht mehr zu fassen...

Bei einem aktiven Sensor (in meinem Fall also die Lichtschranke) wird bei einem High-Pegel und Definition des Ports als OUTPUT (LOW) ein Strom vom externen Sensor VCC gegen GND fließen. Das ist natürlich ungewollt, wie schon beschrieben.

ZitatWäre es nicht geschickter, den Pin auf Input/no-pullup zu konfigurieren statt auf Low?
Das wäre High-Z, also stromneutral, ist aber nicht ganz so hart wie das Low was je nach input Pegel/Device ja auch einen hohen Strom verursachen kann, bis hin zum Kurzschluss wenn es z.B. eine Push-Pull Endstufe ist die da dranhängt.

Das wäre mit diesen Messwerten genau die richtige Lösung für beide Fälle, oder ?
Titel: Antw:AskSin++ Library
Beitrag von: Sany am 02 Januar 2022, 11:31:32
Moin zusammen und ein frohes neues Jahr 2022,

(ist etwas OT, aber passt doch zu Asksin++)
obwohl schon eine ganze in fhem mit homematic und mit Arduino unterwegs, ist AskSin und der Selbstbau von Homematic-Komponenten irgendwie an mir vorbeigegangen. Kurzes schlaumachen zum Thema hat ergeben: ja, das passt und will ich haben.
Frage an die Wissenden: wo gibts z.Zt. die CC1101 (am liebsten zusammen mit den Arduinos pro mini 3,3V 8MHz) am einfachsten zu bestellen? Habe bisher oft in China bestellt, aber mit der neuen Steuerregelung ist das nicht mehr interessant, da das nächste Postzollamt ~30km weg ist. Würde nur bei einer richtig großen Bestellung lohnen.

Danke schon mal.

Sany
Titel: Antw:AskSin++ Library
Beitrag von: kadettilac89 am 02 Januar 2022, 12:05:43
Zitat von: Sany am 02 Januar 2022, 11:31:32
Habe bisher oft in China bestellt, aber mit der neuen Steuerregelung ist das nicht mehr interessant, da das nächste Postzollamt ~30km weg ist. Würde nur bei einer richtig großen Bestellung lohnen.


etwas ungenau oder ggf. falsch. Steuerbeträge unter 1 Euro werden nicht eingefordert. In dem FAll bleibt alles beim Alten. D. h. Bestellungen unter 5 Euro werden weiterhin zugestellt wie gehabt. Bei Bestellungen darüber bietet DHL die Abfertigung für einen Betrag von 6 Euro an und liefert dann zu dir nach Hause. Du zahlst dann Zoll zzgl. die Gebühr an die DHL.

Wenn der Zoll den Inahlt explizit begutachten will, oder die Wertdeklaration unglaubwürdig ist musst du weiterhin hinfahren.

Unabhängig davon, Kleinmengen CC1101 / Arduino  gehen auch über Ebay mit deutschen Händler, wenn du mehr als ein Stück bestellen willst kannst vorab auch um Rabatt bitten. Außerdem bieten einige Händler bei Aliexpress den VErsand aus europäischen Ländern an.

Titel: Antw:AskSin++ Library
Beitrag von: Gernott am 02 Januar 2022, 12:11:11
Zitat von: Sany am 02 Januar 2022, 11:31:32
da das nächste Postzollamt ~30km weg ist. Würde nur bei einer richtig großen Bestellung lohnen.

Beim Ali wird  die Steuer seit Monaten direkt  abgezogen. Ich habe in den letzten Wochen Zeugs bis über 100 € bestellt und keinerlei Aufwand mit dem Zoll gehabt. Man kann sich aus dem Ordermanager sogar die Rechnung mit ausgewiesener MWst. herunterladen.
Titel: Antw:AskSin++ Library
Beitrag von: ext23 am 02 Januar 2022, 12:35:09
Zitat von: Gernott am 02 Januar 2022, 12:11:11
Beim Ali wird  die Steuer seit Monaten direkt  abgezogen. Ich habe in den letzten Wochen Zeugs bis über 100 € bestellt und keinerlei Aufwand mit dem Zoll gehabt. Man kann sich aus dem Ordermanager sogar die Rechnung mit ausgewiesener MWst. herunterladen.

Richtig! Nur kommt vieles nicht mehr an, weil die Post alles verschlampt, ich habe da nur noch Ärger seit der Umstellung. Und zurück gehen die Lieferungen auch nicht...
Titel: Antw:AskSin++ Library
Beitrag von: Gernott am 02 Januar 2022, 12:58:51
Zitat von: ext23 am 02 Januar 2022, 12:35:09
Richtig! Nur kommt vieles nicht mehr an, weil die Post alles verschlampt, ich habe da nur noch Ärger seit der Umstellung. Und zurück gehen die Lieferungen auch nicht...
Ich vermute mal, das liegt dann eher bei Deiner Post. Ich hatte in den letzten zehn Jahren nur eine (1) verlorene Sendung aus China, bei ~30 Bestellungen pro Jahr.

P.S. Ich kann Dir Bescheid geben, wenn in der Nachbarschaft ein Haus frei wird.
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 02 Januar 2022, 13:02:08
Zitat von: papa am 31 Dezember 2021, 15:00:22
Das ist/war doch für den RHS mit den Reed-Kontakten. Und natürlich auch für alle anderen Geräte, die mittels Schalten auf GND den Zustand signalisieren.

ok verstehe. Auch für Reed-Kontakte "sollte" das High-Z Konzept funktionieren, aber muss natürlich getestet werden, da sind wir uns alle einig.  :)

p.s. China/Zoll/Post Diskussionen sind hier im AskSin++ Lib thread wirklich eine schlechte Stelle. Evtl. dem thread "Fehlerhafte CC1101 Module" benutzen?
Titel: Antw:AskSin++ Library
Beitrag von: Sany am 02 Januar 2022, 15:19:34
Zitatp.s. China/Zoll/Post Diskussionen sind hier im AskSin++ Lib thread wirklich eine schlechte Stelle. Evtl. dem thread "Fehlerhafte CC1101 Module" benutzen?
sorry fürs Kapern, mit den Infos der letzten 4 Post komme ich zurecht. Danke dafür!

...weiter mit AskSin++
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 03 Januar 2022, 00:30:37
Moin

Zitatok verstehe. Auch für Reed-Kontakte "sollte" das High-Z Konzept funktionieren, aber muss natürlich getestet werden, da sind wir uns alle einig.

ok, ein Reed-Kontakt, ein manueller Taster, ein Relais, ein Vielfachmessgerät (bei Strommessung) usw. sind prinzipiell alles nur Drahtbrücken. Damit schaltet man den Inputport gegen GND.  Es geht aber nur um die veränderten Eigenschaften des Ports zwischen den Messungen, nicht um die Messung / Zustandserkennung selbst.

Ich habe inzwischen mein Device mit der Änderung bei readPin in Betrieb.

// pinMode(pinnr,OUTPUT);
// digitalWrite(pinnr,LOW);
pinMode(pinnr,INPUT);


Angeschlossen sind ein Reed-Kontakt (Tür auf / zu), ein Schlüsselkontakt (Tür abgeschlossen / nicht abgeschlossen) und ein RFID-Reader mit einem Relaisinterface.

Alles funktioniert wie gewünscht. Ich möchte mich dafür aussprechen, dass die gute von TomMajor vorgeschlagene Änderung in die Lib kommt.

Was meint Ihr ??

Titel: Antw:AskSin++ Library
Beitrag von: papa am 03 Januar 2022, 18:45:07
Gerne - einfach nen PullRequest im GitHub machen
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 04 Januar 2022, 23:38:02
ZitatGerne - einfach nen PullRequest im GitHub machen

...ich habs versucht, mir eine ID im GIT besorgt und dachte, dass ich nun irgendwo was Sinniges hinschreiben kann, quasi die Zusammenfassung von hier. Alles was geschehen ist, dass ich ungewollt einen Fork der AskSinPP erzeugt habe. Die kann kann ich noch nicht einmal löschen...
:'( :'( :'(
Sorry, ich gebe auf, keine Ahnung, wie das gehen soll. Hoffentlich kann ich wenigstens diese ID wieder löschen !

papa, kannst Du den Fork von pwlr001d im GIT als Eigentümer des Originals löschen ????

Bernd
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 04 Januar 2022, 23:48:20
ich könnte einen PR machen, überlege aber die Änderung vorher noch mal im orangen Forum anzusprechen wegen möglicher Nebenwirkungen, sind doch mittlerweile eine Menge Leute die AskSinPP Geräte einsetzen..
Titel: Antw:AskSin++ Library
Beitrag von: pwlr am 05 Januar 2022, 12:10:48
Hi,
Zitatich könnte einen PR machen,
danke !!

Noch ein Quercheck ist aus meiner Sicht ok, es ist ja nicht eilig.
Titel: Antw:AskSin++ Library
Beitrag von: papa am 05 Januar 2022, 15:07:52
Zitat von: Tom Major am 04 Januar 2022, 23:48:20
ich könnte einen PR machen, überlege aber die Änderung vorher noch mal im orangen Forum anzusprechen wegen möglicher Nebenwirkungen, sind doch mittlerweile eine Menge Leute die AskSinPP Geräte einsetzen..
Ja, mach mal bitte. Hier gab es auch noch einne komischen Nebeneffekt.
https://forum.fhem.de/index.php/topic,124205.msg1198138.html#msg1198138
Titel: Antw:AskSin++ Library
Beitrag von: Tom Major am 05 Januar 2022, 23:32:05
Habe das Thema noch mal hier (https://homematic-forum.de/forum/viewtopic.php?f=76&t=71854) angesprochen.
Titel: Aw: AskSin++ Library
Beitrag von: efyzz am 22 Februar 2024, 21:36:31
Hallo,

ich habe mir den HB-UNI-SenAct-4-4-SC mit Batteriebetrieb gebaut. Dafür musste ich noch die HMConfig_AskSinPPCustom.pm erweitern. Ich habe dafür einfach den F331 HB-UNI-SenAct-4-4-SC kopiert und F333 genannt und den Burst aktiviert. Funktioniert soweit.

Was muss ich nun noch hinzufügen, damit auch der Batteriestatus (oder sogar der Spannungswert) in FHEM angezeigt wird?

Im Arduino Code wird per #define USE_BATTERY_MODE scheinbar schon alles aktiviert, um den Batteriestatus zu übertragen. Nur in die HMConfig_AskSinPPCustom.pm müsste es noch eingebaut werden:

$HMConfig::culHmModel{"F333"} = {name=>"HB-UNI-SenAct-4-4-SC",st=>'custom',cyc=>'',rxt=>'b',lst=>'1,3:1p.2p.3p.4p,4:5p.6p.7p.8p',chn=>"Sw:1:4,Btn:5:8"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-SC00"}{fwUpdate} = "<filename>";
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-SC01"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-SC02"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-SC03"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-SC04"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-SC05"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-SC06"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-SC07"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-4-4-SC08"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmRegModel{"HB-UNI-SenAct-4-4-SC"}  = { intKeyVisib=>1, cyclicInfoMsg=>1, sabotageMsg=>1 };
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-SC01"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-SC02"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-SC03"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-SC04"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-SC05"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-SC06"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-SC07"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-4-4-SC08"} = $HMConfig::culHmRegType{threeStateSensor};
$customMsg{"HB-UNI-SenAct-4-4-SC"} = sub {
  my ($msg,$target) = @_;
  my $channel = $msg->channel;
  return $msg->processThreeState($target) if $channel > 4;
  return $msg->processSwitchStatus($target) if $msg->isStatus;
  return ();
};

Hier mal als Beispiel der F311, der offensichtlich den Batteriestatus überträgt. Ich habe versucht, mir daraus etwas zusammen zu kopieren, aber das war leider erfolglos.

$HMConfig::culHmModel{"F311"} = {name=>"HB-UNI-Sen-CAP-MOIST",st=>'custom',cyc=>'',rxt=>'c:l',lst=>'1',chn=>"Data:1:1,Moisture:2:4"};
$HMConfig::culHmChanSets{"HB-UNI-Sen-CAP-MOIST00"}{fwUpdate} = "<filename>";
$HMConfig::culHmChanSets{"HB-UNI-Sen-CAP-MOIST01"} = {};
$HMConfig::culHmChanSets{"HB-UNI-Sen-CAP-MOIST02"} = {};
$HMConfig::culHmChanSets{"HB-UNI-Sen-CAP-MOIST03"} = {};
$HMConfig::culHmChanSets{"HB-UNI-Sen-CAP-MOIST04"} = {};
$HMConfig::culHmRegModel{"HB-UNI-Sen-CAP-MOIST"}  = { lowBatteryLimit=>1, transmitInterval=>1 };
$HMConfig::culHmRegChan {"HB-UNI-Sen-CAP-MOIST01"} = {};
$HMConfig::culHmRegChan {"HB-UNI-Sen-CAP-MOIST02"} = { highValue=>1, lowValue=>1 };
$HMConfig::culHmRegChan {"HB-UNI-Sen-CAP-MOIST03"} = { highValue=>1, lowValue=>1 };
$HMConfig::culHmRegChan {"HB-UNI-Sen-CAP-MOIST04"} = { highValue=>1, lowValue=>1 };
$customMsg{"HB-UNI-Sen-CAP-MOIST"} = sub {
  my ($msg,$target) = @_;
  my @evtEt=();
  my $cnum = $msg->payloadByte(1) & 0x3f; # get channel from byte 1 of payload
  my $device = main::CUL_HM_id2Hash($msg->from);
  my $batstat = "ok";
  $batstat = "low" if (($msg->payloadByte(0) & 0x80)==0x80);
  push @evtEt,[$device,1,"battery:".$batstat];
  my $channel = $main::modules{CUL_HM}{defptr}{$msg->channelId($cnum)};
  if( defined($channel) ) {
    my $bat = $msg->payloadByte(2);
    push @evtEt,[$channel,1,"batVoltage:".$bat/10];
    push @evtEt,[$channel,1,"state:".($bat/10)." V"];
  }
  for( my $offset=3; $offset < length($msg->payload)/2; $offset += 2 ) {
    $cnum = $msg->payloadByte($offset) & 0x3f; # get channel for next value
    $channel = $main::modules{CUL_HM}{defptr}{$msg->channelId($cnum)};
    if( defined($channel) ) {
      my $moist = $msg->payloadByte($offset+1);
      push @evtEt,[$channel,1,"humidity:".$moist];
      push @evtEt,[$channel,1,"state:".$moist." %"];
    }
    else {
      Log 1,"No channel for ".$msg->channelId($cnum);
    }
  }
  return @evtEt;
};

Vielen Dank für eure Tipps!
Titel: Aw: AskSin++ Library
Beitrag von: papa am 23 Februar 2024, 20:55:16
Probier mal folgendes
$customMsg{"HB-UNI-SenAct-4-4-SC"} = sub {
  my ($msg,$target) = @_;
  my @evtEt=();
  my $batflags = 0;
  my $device = main::CUL_HM_id2Hash($msg->from);
  my $channel = $msg->channel;
  if( $channel > 4 ) {
    @evtEt = $msg->processThreeState($target);
    # add battery value
    $batflags = $msg->payloadByte(0);
  }
  if( $msg->isStatus ) {
    @evtEt = $msg->processSwitchStatus($target);
    # add battery value
    $batflags = $msg->payloadByte(3);   
  }
  # add battery state
  my $batstat = "ok";
  $batstat = "low" if (($batflags & 0x80)==0x80);
  push @evtEt,[$device,1,"battery:".$batstat];
  return @evtEt;
};
Titel: Aw: AskSin++ Library
Beitrag von: efyzz am 23 Februar 2024, 23:40:43
Hallo papa,

vielen Dank! Schön, dass Du hier noch supportest :)

Ich habe jetzt tatsächlich ein Reading battery ok/low.
Die Batteriespannung wird leider nicht angezeigt. Aber immerhin, so komme ich schon mal weiter.

Ich habe nämlich den Eindruck, dass der HB-UNI-SenAct-4-4-SC innerhalb einiger Tage die Batterien leer zieht (Strommessung sieht eigentlich gut aus). Ich hatte vorher den HM-Sec-SD Sketch (Rauchmelder) verwendet, da hielten die Batterien gut 2 Jahre. Aber ich muss das noch ne Weile beobachten, bevor ich das Problem genauer beschreiben kann ...
Titel: Aw: AskSin++ Library
Beitrag von: papa am 24 Februar 2024, 13:11:40
Schickt er überhaupt die Batteriespannung mit ?
Titel: Aw: AskSin++ Library
Beitrag von: efyzz am 24 Februar 2024, 21:32:58
Ich habe leider nicht die geringste Ahnung (woran man das erkennt) ...
Habe diesen Sketch verwendet:
https://github.com/jp112sdl/HB-UNI-SenAct-4-4/tree/master/HB-UNI-SenAct-4-4-SC (https://github.com/jp112sdl/HB-UNI-SenAct-4-4/tree/master/HB-UNI-SenAct-4-4-SC)
Titel: Aw: AskSin++ Library
Beitrag von: papa am 24 Februar 2024, 22:50:57
Nö - nur das Low-Flag
Titel: Aw: AskSin++ Library
Beitrag von: efyzz am 27 Februar 2024, 23:06:10
OK, danke.

Ich muss jetzt erstmal weiter beobachten, warum die Geräte immer mal wieder nicht erreichbar sind. Ich bin wie gesagt von HM-Sec-SD-Sketch umgestiegen und da hatte ich keine Probleme mit nahezu leeren Batterien (ca. 2,4V unbelastet). Mit diesen schwachen Batterien waren die nun auf HB-UNI-SenAct-4-4-SC geflashten Geräte immer nach ein paar Tagen nicht mehr erreichbar. Also haben alle betroffenen Geräte nun erstmal neue Batterien bekommen. Aktuell laufen 7 von 8 stabil, einer zickt noch gelegentlich, trotz voller Batterien. Bin gespannt, wie lange die Batterien halten und ob die "low" Meldung kommt, bevor sie wieder unerreichbar sind.
Titel: Aw: AskSin++ Library
Beitrag von: Funsailor am 28 Februar 2024, 14:56:56
Hi,
ich habe hier ein HM-PBI-4-FM mit defektem Funkmodul. Das Modul habe ich getauscht (Aus einem defekten Fenstersensor) und nun kann ich das Teil sehen.... dummerweise verschlüsselt.
Ich wollte nun den Sketch "HM-PBI-4-FM" vom Jérôme nehmen.... der ist leider zu groß...

ZitatDer Sketch verwendet 18684 Bytes (130%) des Programmspeicherplatzes. Das Maximum sind 14336 Bytes.

(Im Modul ist ein Atmega 168PA drin). Es gab irgendwo mal einen Beitrag wie man da vielleicht weiterkommt, ich finde den aber nicht mehr.

Besteht überhaupt eine Möglichkeit den Sketch so weit abzuspecken das man 4K Programmspeicher spart?


Titel: Aw: AskSin++ Library
Beitrag von: efyzz am 28 Februar 2024, 22:01:12
Moin,

ich versuche mal mit meinem gefährlichen Halbwissen etwas dazu zu sagen  ;D

Die AsksinPP Projekte basieren auf einem Atmega 328. Verstehe ich Dich richtig, dass Du ein original Homematic Gerät mit einem AsksinnPP Sketch flashen willst? Das wird wohl aus verschiedensten Gründen nicht kompatibel sein ...
Titel: Aw: AskSin++ Library
Beitrag von: papa am 29 Februar 2024, 09:44:07
Zitat von: Funsailor am 28 Februar 2024, 14:56:56Hi,
ich habe hier ein HM-PBI-4-FM mit defektem Funkmodul. Das Modul habe ich getauscht (Aus einem defekten Fenstersensor) und nun kann ich das Teil sehen.... dummerweise verschlüsselt.
Ich wollte nun den Sketch "HM-PBI-4-FM" vom Jérôme nehmen.... der ist leider zu groß...

ZitatDer Sketch verwendet 18684 Bytes (130%) des Programmspeicherplatzes. Das Maximum sind 14336 Bytes.

(Im Modul ist ein Atmega 168PA drin). Es gab irgendwo mal einen Beitrag wie man da vielleicht weiterkommt, ich finde den aber nicht mehr.

Besteht überhaupt eine Möglichkeit den Sketch so weit abzuspecken das man 4K Programmspeicher spart?
Schau mal in Jeromes Repository, da gibt es auch Geräte mit 168. Auf jeden Fall geht AES dort nicht.
Es gibt ein paar Defines, welche Einfluss auf die Codegröße haben. Infos findest Du hier https://github.com/pa-pa/AskSinPP?tab=readme-ov-file#defines-to-reduce-code-size


Titel: Aw: AskSin++ Library
Beitrag von: Funsailor am 29 Februar 2024, 16:41:11
Zitat von: efyzz am 28 Februar 2024, 22:01:12Moin,

ich versuche mal mit meinem gefährlichen Halbwissen etwas dazu zu sagen  ;D

Die AsksinPP Projekte basieren auf einem Atmega 328. Verstehe ich Dich richtig, dass Du ein original Homematic Gerät mit einem AsksinnPP Sketch flashen willst? Das wird wohl aus verschiedensten Gründen nicht kompatibel sein ...

Nicht ganz richtig, siehe auch Papas Antwort
Wenn man da etwas hoch scrollt, findet man das:
C++ implementation of the AskSin protocol

    easy configuration of the device channels by using templates
    direct eeprom access for the channel data
    AES signature support
    Supported MCU:
        ATMega328
        ATMega32 (Standard Pinout)
        ATMega128 (Standard Pinout)
        ATMega644 (Bobuino Pinout is highly suggested)
        ATMega1284 (No OTA Bootloader support, yet)
        STM32F1
        ESP32 (not fully implemented)
        RP2040 (not fully implemented)
Titel: Aw: AskSin++ Library
Beitrag von: Funsailor am 29 Februar 2024, 17:12:29
Hi Papa,
danke für den Tip, ich habe die entsprechenden Sketche in Jeromes Repository gefunden.
Wenn ich die folgenden Zeilen aus den entsprechenden Dateien nutze:

#define SENSOR_ONLY
#define NORTC
#define NOCRC
#define SIMPLE_CC1101_INIT
#define NDEBUG

#define EI_NOTEXTERNAL
#define EI_ATTINY24

//saves ~646 bytes program size:
extern "C" void *malloc(size_t size) {return 0;}
extern "C" void free(void* p) {}

passt der Sketch in den 168er....

Allerdings wird dann nicht mehr viel funktonieren, da mit dem Macro
EI_ATTINY24 einige wichtige Funktionen in der EnableInterrupt.h wegfallen   ::) 

Ohne das Macro wird der Sketch ein wenig zu groß ... : 15166 Bytes (105%)

Allerdings habe ich alle 168er Sketche in Jeromes Repository versucht zu compilieren, die werden alle zu groß  ???


Titel: Aw: AskSin++ Library
Beitrag von: frank am 29 Februar 2024, 23:48:33
https://homematic-forum.de/forum/viewtopic.php?f=76&t=67975&start=10#p798043 (https://homematic-forum.de/forum/viewtopic.php?f=76&t=67975&start=10#p798043)

edit:
gerade noch gesehen.
die frage dort war ja sowieso von dir.