HB-1W-KEY auf PanStamp mit AskSin

[Prof. Dr. Peter Henning]

Hallo Liste,

beim Usertreffen in KA habe ich ja die iButton-Ankopplung auf den Arduino gezeigt. Inzwischen habe ich das temporär auf einem PanStamp laufen und in HomeMatic eingebunden.

Auf dem PanStamp läuft also der 1-Wire Master, der alle 250 ms den angechlossenen 1-Wire-Bus abfragt. Wenn einer der angemeldeten iButtons entdeckt wird, schaltet der PanStamp den Türöffner und beleuchtet steuert eine 3-Farben-LED in der Farbe an , die diesem iButton zugeordnet ist. Gleichzeitig wird mit Hilfe der AskSin-Library eine Meldung an FHEM abgesetzt, das funktioniert schon sehr gut.

Dafür habe ich bisher die bei der AskSin-Library mitgelieferten Beispiele aufgebohrt, möchte das aber gerne jetzt auf eine ordentlichere Basis stellen.

Ich stelle das also hier mal zur Diskussion:

- Wie sollte in solches neues HM-Device heißen ? Ich habe für den Moment HM-1W-KEY gewählt. Mit gleicher Berechtigung könnte man HM-SEC-1WKEY nehmen.
- Welche Kanäle sollte ein solches Device haben: Einen für die Meldung der iButtons, 2 Kanäle um ggf. Licht etc. zu schalten, 2 weitere Kanäle für eventuelle weitere Tasten ?

Darüber hinaus wäre ich dankbar, wenn ich einen Hinweis auf eine ausführlichere Dokumentation der "destillRegs"-Utility bekommen könnte.

LG

pah

[betateilchen]

Hallo Peter,

schau Dir doch mal den Thread zum Selbstbau-Wettersensor hier im Homematic-Bereich an, darin sind eigentlich genau die von Dir gestellten Fragen zu Registern etc. beantwortet.

http://forum.fhem.de/index.php/topic,20620.0.html

[Dirk]

Hallp pah,

- Wie sollte in solches neues HM-Device heißen ? Ich habe für den Moment HM-1W-KEY gewählt. Mit gleicher Berechtigung könnte man HM-SEC-1WKEY nehmen.

Zur Benamung vom Wettersensor habe ich mir auch schon Gedanken gemacht, wenn auch noch nicht abschließend.
Aber vielleicht können wir das hier besprechen.

Da die "offiziellen" Bezeichnungen mit "HM-" beginnen könnte man für Eigenentwicklungen vielleicht einen alternativen Präfix.
Vielleicht "HB-" für HomeBrew?
Oder hat jemand eine Andere Idee?

Ansonsten versuche ich mich an diese Schema zu halten:
http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen

Vermutlich müssen wir das auch erweitern.

Gruß
Dirk

[betateilchen]

Am Anfang des Namens würde ich das HM nicht verändern, denn es gibt durchaus Fälle, in denen man per devspecarray arbeiten möchte und sich darauf verläßt, dass Komponenten im Homematic Protokoll mit HM- beginnen.

[Prof. Dr. Peter Henning]

Hallo ihr beiden.

1. Natürlich habe ich den Thread zum Wettersensor gelesen - das destillregs.pl tut ja bei mir auch schon. Es gibt aber m.E. keine konsistente und übersichtliche Doku. Dafür habe ich volles Verständnis, das ist ja noch im Stadium einer andauernden Entwicklung - würde aber dennoch gerne dazu beitragen, dass die Anwendung einfacher wird.

2. Ich habe auch das Namensschema gelesen. Abgesehen davon, dass ELV das inkonsistent verwendet, ist aber auch das Schema nicht sehr ordentlich definiert.

Die Idee mit dem HB-Präfix finde ich übrigens sehr gut, auch deshalb, weil die Markenbezeichnung "HomeMatic" geschützt ist.

Oberste Klasse wäre also HB - HomeBrew

Nehmen wir danach die (hauptsächliche) Funktion, oder die (hauptsächliche) Hardware ?

Also HB-1W-KEY oder HB-KEY-1W ?

Etwas mehr Semantik wäre hier nicht schlecht.

LG

pah

[martinp876]

HB am anfang ist nicht verkehrt. Schon jetzt fangen nicht alle mit HM an - es gibt Schueco..., Roto..., KS... und viele andere.
Will man HM devices anzeigen sollte man besser nach dem TYPE suchen - nur der sagt die Wahrheit.

Das Model ist key - daher ist ein eindeutiger Name Pflicht. "HB-" ist also nicht verkehrt - "HB-1W" finde ich gut.

Ich würde - wegen besseren Sortierens - 1W vor-stellen.

Etwas mehr Semantik wäre hier nicht schlecht.

Die Namen werden von HM vorgegeben - man kann dort gerne Anregungen einkippen.
Dass man aus Namen die komplette Bedeutung ablesen kann ist eh unwahrscheinlich. Die Gruppe der Eigenbauten kann man frei gestalten.
Wichtig wäre noch die ID. Die muss bei der Anlermessage kommen und muss eindeutig sein. HM zählte einfach noch - ist etwa bei 0x00d2.
Für eigenbau sensoren, die ja nicht koordiniert gebaut werden könnte man bereiche vergeben, damit sich die Entwickler nicht in die Quere kommen.
Ich schlage den Bereich ab 0x8000 vor. 1w konnte z.B. 0x8100 bis 0x81ff belegen.
Generell stellt sich die Frage, ob und wie ihr die Dinge freigeben wollt. Z.B. HW-anleitung/FW und dann die Konfig dazu - aus einer Hand. Wer nur eigenbau betreibt kann diese in einer eigenen Gruppe (quasi "Private")


Zu den Kanälen:
Üblich ist je Funktion ein Kanal. Also einer je taster, einer je aktor. Daran sollte man sich dringend halten, das ist HM standard. Eventuelle Sensoren konnen manchmal in einem Kanal zusammengefasst werden. Feuchte und temperatur - oder eine Liste von Wetterdaten. Alles andere ist zu trennen.
Man kann sonst auch keinen einstellungen vornehmen (peeren und konfigurieren). Das kann dein Device gemäß HM semantik?

Gruss Martin

[Prof. Dr. Peter Henning]

Pairen ja, peering habe ich noch nicht getestet.

OK, ich bleibe also bei HB-1W-KEY. Ich habe mir erlaubt, das gleich ins Wiki einzubauen.

Im Hinblick auf die Priorität des schon existierenden Eigenbaus"Wettersensor" ist hiermit die eindeutige ID festgelegt auf 0x8101.
EDIT: OK, wenn Dirk bei seinem Wert bleibt, nehme ich eben 0x8000

Natürlich wird das auch komplett freigegeben (wenn es fertig ist - kann durchaus noch eine Weile dauern).

LG

pah

[Dirk]

Ich schlage den Bereich ab 0x8000 vor. 1w konnte z.B. 0x8100 bis 0x81ff belegen.

Ich habe beim Wettersensor mit 0xF101 begonnen, wenn man mal annimmt dass der Hersteller von unten beginnt ist es vermutlich unwarscheinlich das man sich in die Quere kommt.
Dann könnte pah ja bei 0xF200 beginnen.
Und mehr als 255 Entwickler mit eigener Hardware werden wir bestimmt nicht haben oder?

[Prof. Dr. Peter Henning]

Halte ich auch für unwahrscheinlich...

Aber was nun, 0x8100 oder 0xF200 ?

Sollte Martin jetzt verbindlich definieren.

LG

pah

[Dirk]

@pah
http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen

HB = Home Brew = HomeMatic Eigenentwicklungen, Nachbauten und Erweiterungen

Du bist ja schnell.

Aber was nun, 0x8100 oder 0xF200 ?

Ich war erster, Daher bin ich für 0xF200

Aber Martin ist der Homematic-(Funk)-Man. Daher soll er das Festlegen

[martinp876]

ich denke beides gibt HM genug Luft. werfen wir eine Münze

0xF200

Wo werden wir dies dokumentieren?  Eine Tabelle wäre schon - evtl in Wiki (mein User ist immer noch gesperrt - entriegelt keiner...)

[Prof. Dr. Peter Henning]

Hier.

http://www.fhemwiki.de/wiki/Kategorie:HomeBrew

LG

pah

[martinp876]

super danke

[trilu]

Ich finde es total cool das du dich an die AskSin lib traust! Mir fehlt im Moment leider ein wenig die Zeit um hier aktiv weiter zu machen.
Wird aber bestimmt wieder, dauert nur noch etwas...

Ich versuche mal ein wenig Licht ins Dunkel zur destillRegs zu bringen.
Mit der destillRegs soll es möglich sein sich automatisch den Inhalt der Register.h generieren zu lassen. Am einfachsten ist es hier, auf ein bestehendes Device aufzubauen. Ich mach das mal am Beispiel eines HM_LC_SW1_BA_PCB.
Zuerst schauen wir uns die Register in FHEM an - das geht mit einem get <euer Device> regList

Code Auswählen Erweitern

list:         register | range              | peer     | description
   0: confBtnTime      |   1 to 255min      |          | 255=permanent
   0: intKeyVisib      |     literal        |          | visibility of internal channel options:visib,invisib
   0: ledMode          |     literal        |          | LED mode options:on,off
   0: localResDis      |     literal        |          | local reset disable options:on,off
   0: lowBatLimitBA    |   5 to 15V         |          | low batterie limit, step .1V
   0: pairCentral      |   0 to 16777215    |          | pairing to central
   1: powerUpAction    |     literal        |          | behavior on power up options:on,off
   1: sign             |     literal        |          | signature (AES) options:on,off
   1: statusInfoMinDly | 0.5 to 15.5s       |          | status message min delay
   1: statusInfoRandom |   0 to 7s          |          | status message random delay
   1: transmitTryMax   |   1 to 10          |          | max message re-transmit
   3: lgActionType     |     literal        | required |  options:toggleToCntInv,off,toggleToCnt,jmpToTarget
   3: lgCtDlyOff       |     literal        | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
   3: lgCtDlyOn        |     literal        | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
   3: lgCtOff          |     literal        | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
   3: lgCtOn           |     literal        | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
   3: lgCtValHi        |   0 to 255         | required | Condition value high for CT table
   3: lgCtValLo        |   0 to 255         | required | Condition value low for CT table
   3: lgMultiExec      |     literal        | required | multiple execution per repeat of long trigger options:on,off
   3: lgOffDly         |   0 to 111600s     | required | off delay
   3: lgOffTime        |   0 to 111600s     | required | off time, 111600 = infinite
   3: lgOffTimeMode    |     literal        | required | off time mode options:minimal,absolut
   3: lgOnDly          |   0 to 111600s     | required | on delay
   3: lgOnTime         |   0 to 111600s     | required | on time, 111600 = infinite
   3: lgOnTimeMode     |     literal        | required | on time mode options:minimal,absolut
   3: lgSwJtDlyOff     |     literal        | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
   3: lgSwJtDlyOn      |     literal        | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
   3: lgSwJtOff        |     literal        | required | Jump from off options:on,off,dlyOn,no,dlyOff
   3: lgSwJtOn         |     literal        | required | Jump from on options:on,off,dlyOn,no,dlyOff
   3: shActionType     |     literal        | required |  options:toggleToCntInv,off,toggleToCnt,jmpToTarget
   3: shCtDlyOff       |     literal        | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
   3: shCtDlyOn        |     literal        | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
   3: shCtOff          |     literal        | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
   3: shCtOn           |     literal        | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
   3: shCtValHi        |   0 to 255         | required | Condition value high for CT table
   3: shCtValLo        |   0 to 255         | required | Condition value low for CT table
   3: shOffDly         |   0 to 111600s     | required | off delay
   3: shOffTime        |   0 to 111600s     | required | off time, 111600 = infinite
   3: shOffTimeMode    |     literal        | required | off time mode options:minimal,absolut
   3: shOnDly          |   0 to 111600s     | required | on delay
   3: shOnTime         |   0 to 111600s     | required | on time, 111600 = infinite
   3: shOnTimeMode     |     literal        | required | on time mode options:minimal,absolut
   3: shSwJtDlyOff     |     literal        | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
   3: shSwJtDlyOn      |     literal        | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
   3: shSwJtOff        |     literal        | required | Jump from off options:on,off,dlyOn,no,dlyOff
   3: shSwJtOn         |     literal        | required | Jump from on options:on,off,dlyOn,no,dlyOff


Was man jetzt sieht sind die möglichen Register des Devices. Wenn man jetzt erweitern oder verändern möchte,
kann man sich die möglichen Register in der HMConfig.pm ansehen. Wirklich eigene Register würde ich im Moment noch nicht
definieren, da die Einbindung in FHEM gerade im Wettersensor Thread geklärt wird.

In der HMConfig.pm gibts ab Zeile ~250 so was hier

Code Auswählen Erweitern

my %culHmRegDefShLg = (# register that are available for short AND long button press. Will be merged to rgister list at init
#blindActuator mainly   
  ActionType      =>{a=> 10.0,s=>0.2,l=>3,min=>0  ,max=>3       ,c=>'lit'      ,f=>''      ,u=>''    ,d=>1,t=>""             ,lit=>{off=>0,jmpToTarget=>1,toggleToCnt=>2,toggleToCntInv=>3}},
  OffTimeMode     =>{a=> 10.6,s=>0.1,l=>3,min=>0  ,max=>1       ,c=>'lit'      ,f=>''      ,u=>''    ,d=>0,t=>"off time mode",lit=>{absolut=>0,minimal=>1}},
  OnTimeMode      =>{a=> 10.7,s=>0.1,l=>3,min=>0  ,max=>1       ,c=>'lit'      ,f=>''      ,u=>''    ,d=>0,t=>"on time mode" ,lit=>{absolut=>0,minimal=>1}},
  MaxTimeF        =>{a=> 29.0,s=>1.0,l=>3,min=>0  ,max=>25.4    ,c=>''         ,f=>10      ,u=>'s'   ,d=>0,t=>"max time first direction"},
  DriveMode       =>{a=> 31.0,s=>1.0,l=>3,min=>0  ,max=>3       ,c=>'lit'      ,f=>''      ,u=>''    ,d=>0,t=>""             ,lit=>{direct=>0,viaUpperEnd=>1,viaLowerEnd=>2,viaNextEnd=>3}},
#dimmer mainly                                                                                 
  OnDly           =>{a=>  6.0,s=>1.0,l=>3,min=>0  ,max=>111600  ,c=>'fltCvT'   ,f=>''      ,u=>'s'   ,d=>0,t=>"on delay"},
  OnTime          =>{a=>  7.0,s=>1.0,l=>3,min=>0  ,max=>111600  ,c=>'fltCvT'   ,f=>''      ,u=>'s'   ,d=>0,t=>"on time, 111600 = infinite"},


Das ist die Auflistung der bekannten Registervariablen die über die verschiedenen HM Geräte genutzt werden.

So, aber zurück zur destillRegs und wie es geht - die destillRegs "kompiliert" aus dem Inhalt des Files devDefinition.pm die Inhalte für Register.h
Also müssen jetzt die Inhalte der devDefinition.pm angepasst werden. Der Inhalt sieht dann so aus:

Code Auswählen Erweitern

use strict;
#Beispiel
# ========================switch =====================================
# battery powered 6 channel switch
#   "006C" => {name=>"HM-LC-SW1-BA-PCB"        ,st=>'switch'            ,cyc=>''      ,rxt=>'b'      ,lst=>'3'            ,chn=>"",},
# 1 device
# 1 kanal
# 6 peers je kanal erlaubt
#----------------define reglist types-----------------
package usrRegs;
my %listTypes = (
   regDev   =>{ intKeyVisib=>1, ledMode=>1, lowBatLimitBA=>1, pairCentral=>1,
                      },
   regChan =>{ sign          =>1,    #|     literal        |          | signature (AES) options:on,off
                         lgActionType  =>1,    #|     literal        | required |  options:toggleToCntInv,off,toggleToCnt,jmpToTarget
                         lgCtDlyOff    =>1,    #|     literal        | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
                         lgCtDlyOn     =>1,    #|     literal        | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
                         lgCtOff       =>1,    #|     literal        | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
                         lgCtOn        =>1,    #|     literal        | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
                         lgCtValHi     =>1,    #|   0 to 255         | required | Condition value high for CT table
                         lgCtValLo     =>1,    #|   0 to 255         | required | Condition value low for CT table
                         lgMultiExec   =>1,    #|     literal        | required | multiple execution per repeat of long trigger options:on,off
                         lgOffDly      =>1,    #|   0 to 111600s     | required | off delay
                         lgOffTime     =>1,    #|   0 to 111600s     | required | off time, 111600 = infinite
                         lgOffTimeMode =>1,    #|     literal        | required | off time mode options:minimal,absolut
                         lgOnDly       =>1,    #|   0 to 111600s     | required | on delay
                         lgOnTime      =>1,    #|   0 to 111600s     | required | on time, 111600 = infinite
                         lgOnTimeMode  =>1,    #|     literal        | required | on time mode options:minimal,absolut
                         lgSwJtDlyOff  =>1,    #|     literal        | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
                         lgSwJtDlyOn   =>1,    #|     literal        | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
                         lgSwJtOff     =>1,    #|     literal        | required | Jump from off options:on,off,dlyOn,no,dlyOff
                         lgSwJtOn      =>1,    #|     literal        | required | Jump from on options:on,off,dlyOn,no,dlyOff
                         shActionType  =>1,    #|     literal        | required |  options:toggleToCntInv,off,toggleToCnt,jmpToTarget
                         shCtDlyOff    =>1,    #|     literal        | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
                         shCtDlyOn     =>1,    #|     literal        | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
                         shCtOff       =>1,    #|     literal        | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
                         shCtOn        =>1,    #|     literal        | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
                         shCtValHi     =>1,    #|   0 to 255         | required | Condition value high for CT table
                         shCtValLo     =>1,    #|   0 to 255         | required | Condition value low for CT table
                         shOffDly      =>1,    #|   0 to 111600s     | required | off delay
                         shOffTime     =>1,    #|   0 to 111600s     | required | off time, 111600 = infinite
                         shOffTimeMode =>1,    #|     literal        | required | off time mode options:minimal,absolut
                         shOnDly       =>1,    #|   0 to 111600s     | required | on delay
                         shOnTime      =>1,    #|   0 to 111600s     | required | on time, 111600 = infinite
                         shOnTimeMode  =>1,    #|     literal        | required | on time mode options:minimal,absolut
                         shSwJtDlyOff  =>1,    #|     literal        | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
                         shSwJtDlyOn   =>1,    #|     literal        | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
                         shSwJtOff     =>1,    #|     literal        | required | Jump from off options:on,off,dlyOn,no,dlyOff
                         shSwJtOn      =>1,    #|     
         },
     );
#      -----------assemble device -----------------
my %regList;
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regChan",peers=>6};

sub usr_getHash($){
  my $hn = shift;
  return %regList       if($hn eq "regList"      );
  return %listTypes     if($hn eq "listTypes"       );
}


Was wurde jetzt definiert?
Ein Gerät mit einem Channel 0 und Channel 1, wobei der Channel 1 Platz für 6 Peers haben soll
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regChan",peers=>6};
Channel 0 wird aus der Variable regDev befüllt, Channel 1 aus regList

Wollt ihr jetzt ein Device mit mehr Channel, so muss das hier entsprechend definiert werden - etwa so:
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regChan",peers=>6};
$regList{2}={type => "regChan",peers=>6};
$regList{3}={type => "regChan",peers=>6};
Das wäre jetzt ein Device mit 3 Kanälen, die aber alle gleich sind. So würde aus dem Relay Sketch ein 3 Relay Sketch.

Braucht ihr unterschiedliche Variablen für die Kanäle, dann müsst ihr das so machen:
$regList{0}={type => "regDev",peers=>1};
$regList1{1}={type => "regChan",peers=>6};
$regList2{2}={type => "regChan",peers=>6};
Natürlich müsst ihr dann auch die Variablen zur regList1 und regList2 zuordnen. Gleich mehr dazu...

Wenn euch 6 Peers pro Kanal nicht reichen, dann könnt ihr hier entsprechend mehr Platz reservieren.
Aber Vorsicht - pro Peer werden 4 Byte für die Peer Adresse benötigt und zusätzlich die Anzahl der Bytes in List3/4.
In unserem Beispiel sind das 22 byte.
D.h. 26 byte pro Peer, bei einem Dimmer sind das dann etwa 70byte pro Peer. Da wird der EEprom schnell zu klein.

Das Füllen der Variablen ist dieser Teil - ich nehme mal den Channel 0 weil hier nicht so viele Variablen drin sind

Code Auswählen Erweitern


      regDev =>{ intKeyVisib=>1, ledMode=>1, lowBatLimitBA=>1, pairCentral=>1,
              },


Hier werden dem Kanal 0 folgende Variablen zugewiesen:
intKeyVisib - visibility of internal channel options:visib,invisib (derzeit noch nicht in der AskSin implementiert)
ledMode - LED mode options:on,off
lowBatLimitBA - low batterie limit, step .1V
pairCentral - pairing to central (der muss immer im Kanal 0 sein, sonst kann das Device nicht mit der Zentrale gepairt werden)

Wenn jetzt die devDefinition.pm soweit fertig ist, dann kann man die destillRegs.pl in einer Shell aufrufen.
perl destillRegs.pl

In der Shell bekommt man jetzt den Inhalt für die Register.h

Code Auswählen Erweitern


HM::s_modtable modTbl[] = {
    {0,0,(s_mod_dlgt)NULL},
    {0,0,(s_mod_dlgt)NULL},
}; // 24 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_regChanL1 {
    // 0x08,
    uint8_t  sign                :1;     // 0x08, s:0, e:1
    uint8_t                      :7;     //
};

struct s_regChanL3 {
    // 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_regChan {
    s_regChanL1 l1;
    s_regChanL3 l3;
};

struct s_regs {
    s_regDev ch0;
    s_regChan ch1;
} regs; // 139 byte


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

    {0, 0, 0, 0x00, 6, 0x0000, 0x0000, (void*)&regs.ch0.l0},
    {1, 1, 0, 0x06, 1, 0x0006, 0x0000, (void*)&regs.ch1.l1},
    {1, 3, 6, 0x07, 22, 0x0007, 0x0000, (void*)&regs.ch1.l3},
}; // 33 byte


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


//- ----------------------------------------------------------------------------------------------------------------------
//- eeprom definition ----------------------------------------------------------------------------------------------------
// define start address  and size in eeprom for magicNumber, peerDB, regsDB, userSpace
HM::s_eeprom ee[] = {
    {0x0000, 0x0002, 0x001a, 0x00a5,},
    {0x0002, 0x0018, 0x008b, 0x0000,},
}; // 16 byte


Sollten noch Fragen sein, immer gerne

Viele Grüße
Horst

[Tobias]

Ich würde vorschlagen sich jetzt nicht nur auf die IButtons zu konzentrieren. Wünschenswert wäre das jeder DSxxxx Baustein eine eigene HB-Kennung bekommt.
Also nur den Sketch ohne nennenswerte Änderung auf den Panstamp aufspielen und alle im angeschlossenen 1wireNetz Devices (DS2408/06/13 , DS18B20, DS2438, DS2450 etc...) werden angelegt