Arduino Asksin library

[Dirk]

so wirklich tief bin ich nicht in den änderungen von dirk drin. hab sie einfach übernommen und festgestellt, dass der rest nicht mehr funzt. hätte vielleicht vorher schauen soll was bei einem merge alles verbogen ist

Was war denn da genau das Problem?
die Änderungen sollten eigentlich alle kompatibel gewesen sein.

[PeterS]

Hallo unimatrix und trilu

Ich habe mir auf Seite 32 nochmal die Infos zum Paket destillRegs durchgelesen:

Ich habe jetzt mal einen GIT für die Library erstellt, derzeit ist erst mal nur das versprochene Paket destillRegs hochgeladen.
destillRegs beruht auf der Idee von martin876 hier im Forum, ist ein Perl Script um einen großen Teil der Register.h automatisch zu erstellen.

Das Paket besteht im Wesentlichen aus 3 Teilen:
destillRegs, das Perl Script
devDefinition.pm, um die eigentliche Funktionalität des Devices zu konfigurieren
RegConfig.pm, enthält alle derzeit bekannten Variablen der HM Devices

Alle 3 Files müssen in einem Directory sein, Aufruf ist dann einfach "perl destillRegs.pl"
Was dann auf der Konsole raus kommt, muss in die Register.h kopiert werden.

Verstandene Schritte:
a) Alle 3 Dateien werden in den FHEM-Ordner kopiert
a) Man läßt sich die Register per "get  DEVISE regList" anzeigen
b) Wie nutzt man den jetzt der Input für das File "devDefinition.pm" ?
c) Startet ihr die "perl destillRegs.pl" aus FHEH heraus ?
d) Dann muss noch der Header ergänzt werden und das Ergebnis in eine Register.h kopiert werden ?

Baukasten ist vll. übertrieben. Natürlich muss man sich mit der Lib etwas beschäftigen. Mit dem Perl-Script legt man sich die passende register.h für die gewünschte Anzahl von Kanälen an und dann kommen noch ein paar Zeilen in den Sketch und dann ist die Firmware eigentlich schon fertig.

Was dann noch gemacht werden muss, ist auf der FHEM Seite das entsprechende Device zu implementieren. Das geht aber aber auch recht übersichtlich. man braucht ja nix völlig neues. Für ein Device mit Buttons und Relais kann man sich an der Custom-Firmware des Unterputz-Aktors orientieren. Der hat 2 Buttons und 2 Switches - muss man nur skalieren.

Gruss Peter

[unimatrix]

Was war denn da genau das Problem?
die Änderungen sollten eigentlich alle kompatibel gewesen sein.

glaube da war gar keins. Ich hatte nur angemerkt, dass man in der register.h ja die Default HMID drin lassen muss. Denn diese ersetzt ja dann dein Script per SED. Ich glaube es war ein Mißverständnis. Alles gut.

[unimatrix]

@PeterS: Die ausgabe von RegList kannst du nicht direkt verwenden. Es ist nur eine Vorlage, nach der du dann die devDefinition.pm anpassen kannst. Dort kommen die Register einfach in die entsprechenden Hashes.

Das Perl-Script hat mit FHEM nichts zu tun. Es ist nur ein Werkzeug zur Erzeugung der register.h mit den entsprechenden Slices, Eeprom-Adressen usw. Das wäre sonst viel Handarbeit.

[PeterS]

@unimatrix:  Danke für die Infos
@trilu:
- Wäre eine Versionsnummer für die Library nicht sinnvoll?
- Für wann ist die neue Version geplant? 

Mit meinem Projekt (4 digitale Eingänge / 4 digitale Ausgänge) komme ich leider nicht richtig voran.
Könnte mir jemand die Register.h dafür erstellen.
Besser wäre natürlich noch  6 digitale Eingänge und 6 digitale Ausgänge. Beim Arduino mini und Panstamp kann ja noch die analogen Eingänge als digitale verwenden 

Gruss Peter

[trilu]

Hallo Zusammen,

wie versprochen habe ich angefangen mit der neuen Library. Zu finden ist sie hier: https://github.com/trilu2000/NewAskSin
Ist aber erst der Anfang - ich habe mit dem Datenbankmodul begonnen. Es enthält jetzt auch eine Testroutine, die alle wesentlichen
Funktionen testet. Die Hardwareanbindung ist in einen Hardware Abstraction Layer ausgegliedert.

Die Registerdefinition in der register.h ist auch komplett neu, sowie die Behandlung der HM Id und Serial.
Das ganze folgt jetzt diesem Aufbau:
(http://forum.fhem.de/index.php?action=dlattach;topic=14140.0;attach=17576)

Viele Grüße
Horst
@PeterS - Über Versionsnummern habe ich mir keine Gedanken gemacht, ich dachte dafür gibt es den GIT?
Nachdem ich das nicht professionell mache und immer weiter progge wenn ich Zeit habe, kann ich dir leider nicht
sagen wann du mit der neuen Version rechnen kannst.

[PeterS]

Hallo trilu
Die Versionsnummer sollte nur eine Anregung sein, damit man sich auch in Forenbeiträgen darauf beziehen kann  Bsp: Ist in Version X.YY gefixt

Es gibt nun eine Homematic-Komponente HM-MOD-Re-8 mit 8-Ausgängen: http://www.elv.de/homematic-8-kanal-empfangsmodul.html

Könnte jemand diese in eine Register.h pressen, sobald diese in der HMConfig.pm aufgenommen wurden ?

Gruss Peter

[unimatrix]

Hallo Peter,

der neue Bausatz wird ja incl. EQ-3 Firmware kommen. Ich gehe davon aus, dass er 8 Kanäle haben wird und die internen 8 Taster nicht als eigene Kanäle zur Verfügung stehen werden sondern nur intern als Kanaltaster nutzbar sind. Das gleiche wie bei den Aktoren.

Damit dieser Bausatz in FHEM funtkioniert, muss er in HMConfig eingebaut werden. Das sollte nicht allzu schwierig sein.

Eine Register.h benötigst du aber nur, wenn die diese Eq-3 Firmware durch eine CustomFW ersetzen willst (z.B. um auch die internen Taster zu nutzen) - das scheint mir hierbei aber nicht das allerdringenste zu sein. Es gibt ja genug Projekte. Mit einer EQ3-FW für einen 8-Kanalaktor könnte ich gut leben...

Lustigerweise habe ich mir gerade am Wochenende mein Panstamp 12-Kanal Output Modul (8 Relais, 4 x 0-10V )zusammengebaut und die AskSin Lib darauf geflasht mit einem 8-Kanal Device. Was allerdings in der jetzigen Version der Lib ziemlich speichereng wird da vieles im SRAM behalten wird.  Ich werde das für die Fußbodenheizungssteuerung einsetzen. Funktioniert noch nicht so gut, liegt wohl an meiner selbstgebauten Drahtantenne...kann empfangen aber nicht senden...

[unimatrix]

Übrigens eine Register.h für einen 8-Kanal Aktor würde ungefähr so aussehen. Wenn man da mehrere Peers braucht gibts aber EEProm Platzprobleme.

Code Auswählen Erweitern


#include <AskSinMain.h>
#define SER_DBG

const uint8_t devParam[] PROGMEM = {
0x11,                                    // The firmware version, 1 byte
0xF1, 0x01,                              // model ID, describes HM hardware. we should use high values due to HM starts from 0
'P','X','0','0','0','0','0','0','0','1', // The serial 10 bytes, needed for pairing   (Default for flash tool)
0x10,                                    // Subtype ??
0x41, 0x01, 0x00,                        // Device Info, 3 byte, describes device, not completely clear yet. includes amount of channels
0xFF, 0xF0, 0x01                         // The HM-ID 3 bytes, needed for pairing     (Default for flash tool)
};

HM::s_devParm dParm = {
5,                                       // send retries, 1 byte, how often a string should be send out until we get an answer
700,                                     // send timeout, 2 byte, time out for ACK handling
devParam                                 // pointer to devParam, see above
};
HM::s_modtable modTbl[] = {
    {0,0,(s_mod_dlgt)NULL},
    {0,0,(s_mod_dlgt)NULL},
    {0,0,(s_mod_dlgt)NULL},
    {0,0,(s_mod_dlgt)NULL},
    {0,0,(s_mod_dlgt)NULL},
    {0,0,(s_mod_dlgt)NULL},
    {0,0,(s_mod_dlgt)NULL},
    {0,0,(s_mod_dlgt)NULL},
    {0,0,(s_mod_dlgt)NULL},
}; // 136 byte

//- ----------------------------------------------------------------------------------------------------------------------
//- channel slice definition ---------------------------------------------------------------------------------------------
uint8_t sliceStr[] = {
    0x02,0x05,0x0a,0x0b,0x0c,0x12,
    0x08,
    0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
}; // 29 byte


//- ----------------------------------------------------------------------------------------------------------------------
//- Channel device config ------------------------------------------------------------------------------------------------
struct s_regDevL0 {
    // 0x02,0x05,0x0a,0x0b,0x0c,0x12,
    uint8_t                      :7;     //       l:0, s:7
    uint8_t  intKeyVisib         :1;     // 0x02, s:7, e:8
    uint8_t                      :6;     //       l:0, s:6
    uint8_t  ledMode             :2;     // 0x05, s:6, e:8
    uint8_t  pairCentral[3];             // 0x0a, s:0, e:0
    uint8_t  lowBatLimitBA;              // 0x12, s:0, e:0
};

struct s_regAktorL1 {
    // 0x08,
    uint8_t  sign                :1;     // 0x08, s:0, e:1
    uint8_t                      :7;     //
};

struct s_regAktorL3 {
    // 0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
    uint8_t  shCtDlyOn           :4;     // 0x02, s:0, e:4
    uint8_t  shCtDlyOff          :4;     // 0x02, s:4, e:8
    uint8_t  shCtOn              :4;     // 0x03, s:0, e:4
    uint8_t  shCtOff             :4;     // 0x03, s:4, e:8
    uint8_t  shCtValLo;                  // 0x04, s:0, e:0
    uint8_t  shCtValHi;                  // 0x05, s:0, e:0
    uint8_t  shOnDly;                    // 0x06, s:0, e:0
    uint8_t  shOnTime;                   // 0x07, s:0, e:0
    uint8_t  shOffDly;                   // 0x08, s:0, e:0
    uint8_t  shOffTime;                  // 0x09, s:0, e:0
    uint8_t  shActionType        :2;     // 0x0a, s:0, e:2
    uint8_t                      :4;     //
    uint8_t  shOffTimeMode       :1;     // 0x0a, s:6, e:7
    uint8_t  shOnTimeMode        :1;     // 0x0a, s:7, e:8
    uint8_t  shSwJtOn            :4;     // 0x0b, s:0, e:4
    uint8_t  shSwJtOff           :4;     // 0x0b, s:4, e:8
    uint8_t  shSwJtDlyOn         :4;     // 0x0c, s:0, e:4
    uint8_t  shSwJtDlyOff        :4;     // 0x0c, s:4, e:8
    uint8_t  lgCtDlyOn           :4;     // 0x82, s:0, e:4
    uint8_t  lgCtDlyOff          :4;     // 0x82, s:4, e:8
    uint8_t  lgCtOn              :4;     // 0x83, s:0, e:4
    uint8_t  lgCtOff             :4;     // 0x83, s:4, e:8
    uint8_t  lgCtValLo;                  // 0x84, s:0, e:0
    uint8_t  lgCtValHi;                  // 0x85, s:0, e:0
    uint8_t  lgOnDly;                    // 0x86, s:0, e:0
    uint8_t  lgOnTime;                   // 0x87, s:0, e:0
    uint8_t  lgOffDly;                   // 0x88, s:0, e:0
    uint8_t  lgOffTime;                  // 0x89, s:0, e:0
    uint8_t  lgActionType        :2;     // 0x8a, s:0, e:2
    uint8_t                      :3;     //
    uint8_t  lgMultiExec         :1;     // 0x8a, s:5, e:6
    uint8_t  lgOffTimeMode       :1;     // 0x8a, s:6, e:7
    uint8_t  lgOnTimeMode        :1;     // 0x8a, s:7, e:8
    uint8_t  lgSwJtOn            :4;     // 0x8b, s:0, e:4
    uint8_t  lgSwJtOff           :4;     // 0x8b, s:4, e:8
    uint8_t  lgSwJtDlyOn         :4;     // 0x8c, s:0, e:4
    uint8_t  lgSwJtDlyOff        :4;     // 0x8c, s:4, e:8
};

struct s_regDev {
    s_regDevL0 l0;
};

struct s_regAktor {
    s_regAktorL1 l1;
    s_regAktorL3 l3;
};

struct s_regs {
    s_regDev ch0;
    s_regAktor ch1;
    s_regAktor ch2;
    s_regAktor ch3;
    s_regAktor ch4;
    s_regAktor ch5;
    s_regAktor ch6;
    s_regAktor ch7;
    s_regAktor ch8;
} regs; // 366 byte

//- ----------------------------------------------------------------------------------------------------------------------
//- channel device list table --------------------------------------------------------------------------------------------
s_cnlDefType cnlDefType[] PROGMEM = {
    // cnl, lst, pMax, sIdx, sLen, pAddr, pPeer, *pRegs;                                                                                                                                        // pointer to regs structure

    {0, 0, 0, 0x00, 6, 0x0000, 0x0000, (void*)&regs.ch0.l0},
    {1, 1, 0, 0x06, 1, 0x0006, 0x0000, (void*)&regs.ch1.l1},
    {1, 3, 2, 0x07, 22, 0x0007, 0x0000, (void*)&regs.ch1.l3},
    {2, 1, 0, 0x06, 1, 0x0033, 0x0000, (void*)&regs.ch2.l1},
    {2, 3, 2, 0x07, 22, 0x0034, 0x0008, (void*)&regs.ch2.l3},
    {3, 1, 0, 0x06, 1, 0x0060, 0x0000, (void*)&regs.ch3.l1},
    {3, 3, 2, 0x07, 22, 0x0061, 0x0010, (void*)&regs.ch3.l3},
    {4, 1, 0, 0x06, 1, 0x008d, 0x0000, (void*)&regs.ch4.l1},
    {4, 3, 2, 0x07, 22, 0x008e, 0x0018, (void*)&regs.ch4.l3},
    {5, 1, 0, 0x06, 1, 0x00ba, 0x0000, (void*)&regs.ch5.l1},
    {5, 3, 2, 0x07, 22, 0x00bb, 0x0020, (void*)&regs.ch5.l3},
    {6, 1, 0, 0x06, 1, 0x00e7, 0x0000, (void*)&regs.ch6.l1},
    {6, 3, 2, 0x07, 22, 0x00e8, 0x0028, (void*)&regs.ch6.l3},
    {7, 1, 0, 0x06, 1, 0x0114, 0x0000, (void*)&regs.ch7.l1},
    {7, 3, 2, 0x07, 22, 0x0115, 0x0030, (void*)&regs.ch7.l3},
    {8, 1, 0, 0x06, 1, 0x0141, 0x0000, (void*)&regs.ch8.l1},
    {8, 3, 2, 0x07, 22, 0x0142, 0x0038, (void*)&regs.ch8.l3},
}; // 187 byte


//- ----------------------------------------------------------------------------------------------------------------------
//- handover to AskSin lib -----------------------------------------------------------------------------------------------
HM::s_devDef dDef = {
    8, 17, sliceStr, cnlDefType,
}; // 6 byte


//- ----------------------------------------------------------------------------------------------------------------------
//- eeprom definition ----------------------------------------------------------------------------------------------------
// define start address  and size in eeprom for magicNumber, peerDB, regsDB, userSpace
HM::s_eeprom ee[] = {
    {0x0000, 0x0002, 0x0042, 0x01b0,},
    {0x0002, 0x0040, 0x016e, 0x0000,},
}; // 16 byte




//- -----------------------------------------------------------------------------------------------------------------------
// - defaults definitions -------------------------------------------------------------------------------------------------
const uint8_t regs01[] PROGMEM = {0x00,0x00,0x00,0x00,0x00};
//const uint8_t regs02[] PROGMEM = {0xff,0xff,0xff};

const uint8_t regs03[] PROGMEM = {0x1f,0xa6,0x5c,0x06};
const uint8_t regs04[] PROGMEM = {0x1f,0xa6,0x5c,0x05};
//const uint8_t regs05[] PROGMEM = {0x12,0x02,0x03,0x04};
//const uint8_t regs06[] PROGMEM = {0x13,0x02,0x03,0x04};
//const uint8_t regs07[] PROGMEM = {0x13,0x02,0x03,0x05};
//const uint8_t regs08[] PROGMEM = {0x15,0x02,0x03,0x04};

//const uint8_t regs09[] PROGMEM = {0x20,0x02,0x03,0x04,0x00,0x00,0x00,0x00,0x22,0x02,0x03,0x04,0x00,0x00,0x00,0x00,0x24,0x02,0x03,0x04,0x25,0x02,0x03,0x04};
//const uint8_t regs10[] PROGMEM = {0x30,0x02,0x03,0x04,0x31,0x02,0x03,0x04,0x32,0x02,0x03,0x04,0x33,0x02,0x03,0x04,0x34,0x02,0x03,0x04,0x35,0x02,0x03,0x04};
//const uint8_t regs11[] PROGMEM = {0x40,0x02,0x03,0x04,0x41,0x02,0x03,0x04,0x42,0x02,0x03,0x04,0x43,0x02,0x03,0x04,0x44,0x02,0x03,0x04,0x45,0x02,0x03,0x04};
//const uint8_t regs12[] PROGMEM = {0x50,0x02,0x03,0x04,0x51,0x02,0x03,0x04,0x52,0x02,0x03,0x04,0x53,0x02,0x03,0x04,0x54,0x02,0x03,0x04,0x55,0x02,0x03,0x04};
//const uint8_t regs13[] PROGMEM = {0x60,0x02,0x03,0x04,0x61,0x02,0x03,0x04,0x62,0x02,0x03,0x04,0x63,0x02,0x03,0x04,0x64,0x02,0x03,0x04,0x65,0x02,0x03,0x04};

s_defaultRegsTbl defaultRegsTbl[] = {
// peer(0) or regs(1), channel, list, peer index, len, pointer to payload
{1, 0, 0, 0, 5, regs01},
// {1, 1, 1, 0, 3, regs02},

// {0, 1, 4, 0, 4, regs03},
// {0, 1, 4, 1, 4, regs04},
// {0, 1, 4, 2, 4, regs05},
// {0, 1, 4, 3, 4, regs06},
// {0, 1, 4, 4, 4, regs07},
// {0, 1, 4, 5, 4, regs08},

// {0, 2, 4, 0, 24, regs09},
// {0, 3, 4, 0, 24, regs10},
// {0, 4, 4, 0, 24, regs11},
// {0, 5, 4, 0, 24, regs12},
// {0, 6, 4, 0, 24, regs13},
};
HM::s_dtRegs dtRegs = {
// amount of lines in defaultRegsTbl[], pointer to defaultRegsTbl[]
1, defaultRegsTbl
};




[gandy]

Hi,

Lustigerweise habe ich mir gerade am Wochenende mein Panstamp 12-Kanal Output Modul (8 Relais, 4 x 0-10V )zusammengebaut und die AskSin Lib darauf geflasht mit einem 8-Kanal Device. Was allerdings in der jetzigen Version der Lib ziemlich speichereng wird da vieles im SRAM behalten wird.  Ich werde das für die Fußbodenheizungssteuerung einsetzen. Funktioniert noch nicht so gut, liegt wohl an meiner selbstgebauten Drahtantenne...kann empfangen aber nicht senden...

bei mir wären das 9 Heizkreise in der FBH - dafür brauche ich keine Analogoutputs. Denkst Du das passt in den Panstamp rein? Dann hätte ich einen guten Grund mich näher mit der AskSin Lib auseinanderzusetzen

Danke und Grüße,
Andy.

[unimatrix]

Die Kanäle "passen" da schon rein in den Panstamp. Aber das fertige Output-Board hat nunmal nur 8 Relais. Das schöne daran ist nur, dass es das so schon fertig gibt und man nix basteln muss.

[trilu]

@unimatrix - hast du dir mal das eeprom zeug von der neuen asksin angeschaut?
ist das für dich ok, verbesserungsbedarf?

[unimatrix]

@trilu: finde das mit den Peers interessant gelöst. Vor allem sehr übersichtlich.

Hattest du das so geplant, dass man dann einfach die HAL "austauscht" wenn man z.B. ein externes I2C EEPROM dran hat?

Bei meinen Tests mit dem externen EEProm wurde klar dass man das Timing irgendwie berücksichtigen muss. Wenn das EEProm noch im Schreibzyklus ist, nimmt es keine neuen Daten an. Man muss das entweder abprüfen oder anders dafür sorgen, dass zwischen zwei Schreibzugriffen eine Mindestzeit von ca. 5 ms liegt.

Ich war an der Dimmerklasse nicht untätig, aber es sind noch viele Details zu machen. Ich hoffe ich kann dir bald eine Version geben. An ein paar "Kleinigkeiten" habe ich mir die Zähne ausgebissen.

[trilu]

ja, entweder hal austauschen oder anpassen.
du könntest z.b. nur die höheren adressen ins externe eeprom schreiben

z.b. so

Code Auswählen Erweitern


void setEEPromBlock(uint16_t addr,uint8_t len,void *ptr) {
if (addr < 1000) {
eeprom_write_block((const void*)ptr,(void*)addr,len);
} else {
i2c_eepromwrite....
}

}



auf das timing muss man beim internen eeprom keine rücksicht nehmen, das macht der schreibbefehl. aus dem kommt man erst nach einer gewissen wartezeit raus.
16 byte schreiben braucht um die 20ms. ist aber ok, mehr wird nie auf einmal geschrieben und timeout kommt erst nach 300ms bei hm...

[gandy]

Habt ihr als Alternative für ein externes EEprom schonmal ein I2C FRAM in Betracht gezogen, zB ein Ramtron FM24CL16B? Hier sollte es keinerlei Probleme mit den Timing geben.

Beste Grüße,
Andy.