Arduino Asksin library

[jab]

Hi trilu,

ich habe noch eine Kleinigkeit entdeckt in der AskSin.cpp:

Code Auswählen Erweitern


// check if we have to add another peer, if not return the status of adding the first peer
if (peer[4] == 0) return ret;

daraus habe ich folgendes gemacht:

Code Auswählen Erweitern


// check if we have to add another peer, if not return the status of adding the first peer
if (peer[4] == 0 || peer[3] == peer[4]) return ret;


Wenn ich in FHEM peerChan 0 xxx single mache wird bei der Quelle (=remote) der zweite Channel auf 0 gesetzt. Beim Ziel (=Aktor) wird der zweite Channel auf den ersten gesetzt. Keine Ahnung was richtig(er) ist. Ist auch kein richtiger Bug, da er danach ja eh nochmal checkt ob der peer schon existiert.

@martin: Ist das gewollt, dass das unterschiedlich ist?

Code Auswählen Erweitern


10 7B A0 01 1A B1 50 20 85 57 01 01 20 85 57 03 00 (l:17)
10 7C A0 01 1A B1 50 20 85 57 03 01 20 85 57 01 01 (l:17)


Ich implementiere gerade Defaults für die Register Listen wenn man peers hinzufügt. Das haben die Originalaktoren ja auch. Also ein Default für Aktorchannels (Liste 3) und einen für Remotechannels (Liste 4).


Gruß,
Jan

[trilu]

kurzer status mal zwischendurch - ich bin jetzt fast fertig mit dem neuen eprom handling und dem dazugehörigen destillRegs script.
damit liegt die asksin library in zukunft im arduino library ordner und die sketches wo auch immer, die abhängigkeit der register.h
ist dann zum sketch und nicht mehr zur lib. bei der gelegenheit konnte ich auch gleich noch ein bischen ram einsparen

ich werde jetzt in den nächsten tagen die funktionen der asksin lib ins neue format bringen und hoffe das es dann bald eine neue plattform
zum weiter testen geben wird.

aussehen wird die register.h dann in zukunft so:

Code Auswählen Erweitern

//- ----------------------------------------------------------------------------------------------------------------------
//- channel slice definition ---------------------------------------------------------------------------------------------
uint8_t sliceStr[] = {
    0x01,0x02,0x0a,0x0b,0x0c,0x18,
    0x04,0x08,0x09,
    0x01,
}; // 10 byte


//- ----------------------------------------------------------------------------------------------------------------------
//- Channel device config ------------------------------------------------------------------------------------------------
struct s_regDevL0 {
    // 0x01,0x02,0x0a,0x0b,0x0c,0x18,
    uint8_t  burstRx;                    // 0x01, s:0, e:0
    uint8_t                      :7;     //       l:0, s:7
    uint8_t  intKeyVisib         :1;     // 0x02, s:7, e:8
    uint8_t  pairCentral[3];             // 0x0a, s:0, e:0
    uint8_t  localResDis;                // 0x18, s:0, e:0
};

struct s_regChanL1 {
    // 0x04,0x08,0x09,
    uint8_t                      :4;     //       l:0, s:4
    uint8_t  longPress           :4;     // 0x04, s:4, e:8
    uint8_t  sign                :1;     // 0x08, s:0, e:1
    uint8_t                      :7;     //       l:7, s:0
    uint8_t  dblPress            :4;     // 0x09, s:0, e:4
    uint8_t                      :4;     //
};

struct s_regChanL4 {
    // 0x01,
    uint8_t  peerNeedsBurst      :1;     // 0x01, s:0, e:1
    uint8_t                      :6;     //
    uint8_t  expectAES           :1;     // 0x01, s:7, e:8
};

struct s_regDev {
    s_regDevL0 l0;
};

struct s_regChan {
    s_regChanL1 l1;
    s_regChanL4 l4;
};

struct s_regs {
    s_regDev ch0;
    s_regChan ch1;
    s_regChan ch2;
    s_regChan ch3;
    s_regChan ch4;
    s_regChan ch5;
    s_regChan ch6;
} regs; // 60 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, 3, 0x0006, 0x0000, (void*)&regs.ch1.l1},
    {1, 4, 6, 0x09, 1, 0x0009, 0x0000, (void*)&regs.ch1.l4},
    {2, 1, 0, 0x06, 3, 0x000f, 0x0000, (void*)&regs.ch2.l1},
    {2, 4, 6, 0x09, 1, 0x0012, 0x0018, (void*)&regs.ch2.l4},
    {3, 1, 0, 0x06, 3, 0x0018, 0x0000, (void*)&regs.ch3.l1},
    {3, 4, 6, 0x09, 1, 0x001b, 0x0030, (void*)&regs.ch3.l4},
    {4, 1, 0, 0x06, 3, 0x0021, 0x0000, (void*)&regs.ch4.l1},
    {4, 4, 6, 0x09, 1, 0x0024, 0x0048, (void*)&regs.ch4.l4},
    {5, 1, 0, 0x06, 3, 0x002a, 0x0000, (void*)&regs.ch5.l1},
    {5, 4, 6, 0x09, 1, 0x002d, 0x0060, (void*)&regs.ch5.l4},
    {6, 1, 0, 0x06, 3, 0x0033, 0x0000, (void*)&regs.ch6.l1},
    {6, 4, 6, 0x09, 1, 0x0036, 0x0078, (void*)&regs.ch6.l4},
}; // 143 byte


//- ----------------------------------------------------------------------------------------------------------------------
//- handover to AskSin lib -----------------------------------------------------------------------------------------------
RPDB::s_devDef dDef = {
    6, 13, sliceStr, cnlDefType,
}; // 6 byte


//- ----------------------------------------------------------------------------------------------------------------------
// - eeprom definition ---------------------------------------------------------------------------------------------------
// define start address  and size in eeprom for magicNumber, peerDB, regsDB, userSpace 
RPDB::s_eeprom ee[] = {
    {0x0000, 0x0002, 0x0092, 0x00ce,}
    {0x0002, 0x0090, 0x003c, 0x0000,}
}; // 16 byte


@jan
ich hatte mir auch schon mal gedanken gemacht zur default befüllung wenn geppeert wird.
was ich gerne noch in die AskSin implementieren würde, ist eine art registrar für channel module.

damit würde man dem channel modul die asksin lib bekannt machen und der asksin lib das channel modul.
dadurch könnte man beim hinzufügen eines neuen peers einen event auslösen und als rückantwort vom channel modul gibt es die defaultwerte...
so ein registrar hätte dann auch den charm, das statusanfragen, etc nicht aus jedem modul als string oder funktionsaufruf verschickt werden,
sondern das modul meldet wenn sich ein status geändert hat und die asksin lib entscheidet ob der status gesendet wird, oder ein ack
oder was auch immer....

viele grüße
horst

[trilu]

ganz vergessen, es wird auch eine neue default betankung beim booten, bzw nach einem reset geben

das format sieht dann so aus:

Code Auswählen Erweitern

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

uint8_t regs03[] PROGMEM = {0x10,0x02,0x03,0x04};
uint8_t regs04[] PROGMEM = {0x11,0x02,0x03,0x04};
uint8_t regs05[] PROGMEM = {0x12,0x02,0x03,0x04};
uint8_t regs06[] PROGMEM = {0x13,0x02,0x03,0x04};
uint8_t regs07[] PROGMEM = {0x13,0x02,0x03,0x05};
uint8_t regs08[] PROGMEM = {0x15,0x02,0x03,0x04};

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};
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};
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};
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};
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, 6, 4, 0, 1, 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},
};
RPDB::s_dtRegs dtRegs = {
// amount of lines in defaultRegsTbl[], pointer to defaultRegsTbl[]
13, defaultRegsTbl
};


hier setze ich z.b die Id der zentrale
uint8_t regs01[] PROGMEM = {0x00,0x00,0x65,0x19,0x63};

wohin die lib das schreiben soll erfährt sie hier:
// peer(0) or regs(1), channel, list, peer index, len, pointer to payload
   {1, 0, 0, 0, 5, regs01},
es wird also in den regs bereich geschrieben, für channel 0, list0, peer index 0


damit lassen sich dann default werte für den ersten start setzen, oder nach einem device reset...

[gandy]

Hallo Horst,

darf ich bei der Gelegenheit nochmal das Thema Variablen Deklaration und PROGMEM abschneiden In neueren Versionen des avr-gcc scheint es zwingend nötig zu sein, diese als const zu deklarieren, was sicher nicht verkehrt ist, da diese Variablen ja durch PROGMEM im read-only Speicher landen und somit als nicht veränderlich gesehen werden müssen.  Das hat auch Auswirkung auf die ein oder andere Funktion, die nicht zu verändernde Argumente ebenfalls als const deklarieren sollte.

Nur ein Gedanke am Rande

beste Grüße,
Andy.

[trilu]

Klar darfst du 
Ich hatte das Thema schon wieder komplett verdrängt,  da meine Arduino mit Avr gcc 4. 3. 2 arbeitet und da macht es anscheinend keinen Unterschied.
Ich bau das aber ein...  Ist ja eigentlich nur eine Kleinigkeit

Viele Grüsse
Horst

[trilu]

Mal wieder ein Update nach längerer Zeit. Da es mich so sehr gestört hat, das die AskSin.h/cpp nicht von der Register.h getrennt werden konnte, hatte ich mich entschlossen die Library noch einmal von vorne anzufangen. Auf dem github ist jetzt das Ergebnis.

Ich habe die Register.h und die Definition des Devices komplett umgestellt. Eigene Register.h kann wie gehabt mit destillRegs.pm generiert werden.
Zusätzlich habe ich mal ein Dummy Modul mit reingepackt, daran sollte man gut erkennen wie das Registrieren eines Moduls in der AskSin lib arbeitet.
In diesem Modul gibt es ein Default Load wenn ein neues Peer hinzugefügt wird. Auch sonst sollte jede Kommunikation aus so einem Channelmodul möglich sein.

Ich werde die Tage noch ein Relais und ein Sensor Modul bauen. Die Library habe ich gerade gegen die HM Config Soft getestet und sie sollte ohne Probleme laufen.
Einzig, ihr müsst in der Datei: rf_rc-4-2.xml

supports_aes="false"
2x auf false setzen...

Peeren des Devices mit einem Dimmer und einem PCB Schaltmodul hat auch problemlos geklappt. Sogar das nötige Burst Signal für das Schaltmodul funzt...

Viel Spass beim testen
Horst

[mmatt]

Ich werde die Tage noch ein Relais und ein Sensor Modul bauen.
Horst

Hallo trilu

Neues Relais Modul..., da hätte ich doch eine Bitte:
Kannst Du beim neuen Relais Modul einen Taster vorsehen (programmieren), damit man am Aktor selber, das Relais auch schalten kann. Wie das beim HM_LC_SW1_BA_PCB auch der Fall ist.
Schön währe auch, wenn der PowerMode 2 (für den Batteriebetrieb) funktioniert

Grüsse Martin

[trilu]

jau, das mit dem taster hatte ich auch schon gemerkt, ich weiss nur noch nicht wie ich es umsetze.

hast du den power mode2 schon getestet? ich hatte bisher erst 0 und 4 getestet

[jab]

Moin,

Man kann doch den Taster einfach mit dem Gerät selber peeren. Mache ich bei mir auch so und funktioniert super.


Gruß
Jan

[mmatt]

@trilu
Bei mir hat der Relais-Sketch mit Power Mode 0 immer funktioniert.
Sobald ich den im Mode 2 gesetzt habe, konnte ich den Aktor nur innerhalb weniger Meter vom CUL entfernt schalten.
Ist aber schon ein Weilchen her als ich das ausprobiert habe.

Das Umsetzen mit einem Taster ist wirklich nicht einfach, man müsste wohl einen Interrupt-Pin für den Taster vom Arduino verwenden, und den Aktor falls er dann im Sleep-Mode (Power Mode 2) ist aufwecken, das Relais schalten und den Status über Funk senden, dannach den Aktor wieder schlafen legen.
Ich glaube PIN 2 (wo jetzt die LED drann ist) ist währe ein externer Interrupt möglich.

@jab
Ja, das würde wohl gehen, ist aber eine teure Lösung

Güsse Martin

[trilu]

bei der pcb ist das über den config taster gelöst. das button modul ist ja bereits fertig und wird auch über interrupts angesteuert. sind pin change interrupts, also von jedem pin verwendbar.
das mit dem internen pairen funktioniert bereits, aber nur ab channel 1. der config taster ist aber channel 0 und dahinter liegt keine peer liste....
möchte ich auch ungern machen, ich hätte das zeug gerne hm kompatibel.

ich schau mir mal die original pcb an und versuche zu verstehen wie hm das macht. da gibts bestimmt ein flag in list0 über das das verhalten konfiguriert wird...

[trilu]

Gibt es hier jemanden der Eins der beiden Geräte sein Eigen nennt und mir ein paar Infos dazu liefern könnte?

HomeMatic Funk-Temperatursensor, außen
HomeMatic Funk-Temperatur-/Luftfeuchtesensor OTH

Viele Grüße
Horst

[jjf]

Gibt es hier jemanden der Eins der beiden Geräte sein Eigen nennt und mir ein paar Infos dazu liefern könnte?

HomeMatic Funk-Temperatursensor, außen  Ja.

Viele Grüße
Horst

Gruss,
Joachim

[Dirk]

Gibt es hier jemanden der Eins der beiden Geräte sein Eigen nennt und mir ein paar Infos dazu liefern könnte?

Ansonsten haben die Heizungstermostate auch einen "Wetter-Kanal" auf dem Temperatur und Feuchte gesendet werden.

Hier ist übrigens das erste Ergebniss von der Lib welches seit etwa 1-2 Wochen auch produktiv im Einsatz ist
http://forum.fhem.de/index.php/topic,19657.0.html

Vielen Dank noch mal an Trilu.

Gruß
Dirk

[trilu]

ok, dann fang ich mal an ein sensor modul für temperatur zu stricken.
kann mir dafür jemand bitte die register liste auslesen?
in fhem auf das device gehen und get regList eingeben...

zusätzlich stellt sich mir die frage, werden die sensor werte zyklisch gesendet, oder nur nach änderung?
wie sieht so eine message aus?

viele grüße
horst