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
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
Hallp pah,
Zitat
- 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
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.
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
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.
ZitatEtwas 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
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
Zitat von: martinp876 am 18 April 2014, 16:32:05
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?
Halte ich auch für unwahrscheinlich...
Aber was nun, 0x8100 oder 0xF200 ?
Sollte Martin jetzt verbindlich definieren.
LG
pah
@pah
http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen
ZitatHB = Home Brew = HomeMatic Eigenentwicklungen, Nachbauten und Erweiterungen
Du bist ja schnell.
Zitat von: Prof. Dr. Peter Henning am 18 April 2014, 17:18:25
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
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...)
Hier.
http://www.fhemwiki.de/wiki/Kategorie:HomeBrew
LG
pah
super danke
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
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
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:
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
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
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*)®s.ch0.l0},
{1, 1, 0, 0x06, 1, 0x0006, 0x0000, (void*)®s.ch1.l1},
{1, 3, 6, 0x07, 22, 0x0007, 0x0000, (void*)®s.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
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
Status Update:
- neuer Codeblock für das Modul CUL_HM definiert, der HB-1W-KEY Messages auswertet.
- Codeergänzungen für das Hilfsfile HMConfig.pm definiert.
- Arduino-Sketch HB-1W-KEY kommuniziert schon ganz gut mit diesem Modul
Es erweist sich als ziemlich kompliziert, die Abläufe in der Asksin-Library aufzuschlüsseln...
@Tobias: Das ist eine andere Herangehensweise. Ich definiere nicht 1-Wire Devices in FHEM - sondern ein neuartiges HomeMatic-Device, eben HB-1W-KEY. Die 1-Wire-Devices auf dem Bus sind nur diesem Gerät bekannt - denn es soll ja, weil sicherheitskritisch, unabhängig von FHEM arbeiten können.
LG
pah
Hallo pah,
ist es dann nicht besser dem Firmata Sketch eine Funkkomponente zu können?
So wie Firmata jetzt interagiert finde ich es schon Klasse! Funktioniert per USB und Ethernet. Jetzt müsste nur noch Funk dazukommen. Ob nun per RFM12B oder CC1101 über Panstamp/JeeLink oder CUL ist eigentlich egal...
Sonst müsste ja für jedes 1wireDevice ein eigenes HB-Device kreiirt werden.....:(
Oh, das kann man natürlich machen.
Aber da ich meine Zeit sehr stark einteilen muss, werde ich es sicher nicht tun.
LG
pah
Zitat von: ntruchsess am 12 Mai 2014, 10:24:34
So ganz egal ist das nicht. Die genannten Funkmodule arbeiten in den ISM-Bändern, in denen man nicht völlig frei funken, sondern pro Gerät maximal 1% der Zeit aktiv sein darf. Das schränkt die Echtzeittauglichkeit, wie Du sie von Firmata gewohnt bist, deutlich ein. Ich habe letztes Jahr Firmata über 'PanStream' (http://forum.fhem.de/index.php/topic,12487.msg83812.html#msg83812) implementiert, hat prinzipiell funktioniert, der PanStream müsste aber noch deutlich optimiert werden - das implementierte Handshaking mit Acknowledge-packeten ähnlich TCP ist wg. der Latenz recht ineffektiv und kostet zu viel Bandbreite was (wegen der 1%-regel) die Verbindung ziemlich ausbremst
Ok, mir persönlich ist es egal... aber vieleicht ist auch WLAN eine Alternative? Es gibt ja diese netten WLAN FunkModule (http://www.aliexpress.com/item/Free-Shipping-serial-TTL-RS232-to-802-11-b-g-n-converter-Embedded-WiFi-Module/659755905.html) die 1-3 serielle Schnittstellen zur Verfügung stellen
Zitat von: ntruchsess am 12 Mai 2014, 10:24:34
Die genannten Funkmodule arbeiten in den ISM-Bändern, in denen man nicht völlig frei funken, sondern pro Gerät maximal 1% der Zeit aktiv sein darf.
Das wiederum stimmt so auch nicht.
Das Gerät darf natürlich immer aktiv sein. Nur alle gesendeten Nachrichten dürfen nicht mehr Zeit als 36s pro Stunde verbrauchen (1%-Regelung)
ZitatDas schränkt die Echtzeittauglichkeit, wie Du sie von Firmata gewohnt bist, deutlich ein.
Auch nur bedingt. Wenn man Sensoren / Schalter usw. einsetzt, können diese Ereignisse natürlich in Echtzeit senden.
Und wenn man bedenkt das normale Messages nur wenige Millisekunden benötigen, dann kann man mit 36s Zeit in einer Stunde schon rech viele Nachrichten verschicken
"Dauersender" sind hier natürlich ausgenommen. Aber wer möchte schon mit ständig sendenden Geräten sein Funkband "zumüllen".
Gruß
Dirk
Zitat von: ntruchsess am 12 Mai 2014, 11:03:10
WLAN wäre prima geeignet. Mit so einem WLAN<->Seriell Modul ist das mehr eine Hardwarebastelei (der Sketch sieht ja nur eine Serielle Schnittstelle, das Modul müsste man als TCP-Client im Modus 'RAW' konfigurieren - Gegenstelle wäre die IP-Addresse/Port des FRM-moduls), mit einem Wifi-shield müsste man noch ein bischen war am Sketch machen.
Die ENC28J60 Module arbeiten aber nicht per RX/TX sondern per SPI
Aber die Diskussion ist wohl wieder besser hier (http://forum.fhem.de/index.php/topic,10744.msg167689.html#msg167689) aufgehoben ;)
Zitat von: ntruchsess am 12 Mai 2014, 17:04:26
Funktioniert garantiert nicht befriedigend (und legal), wenn man versucht darüber 20 1-Wire-sensoren im 5 Sekunden-takt zu pollen.
Pollen finde ich grundsätzlich nicht schön.
Daher könnte der AVR den 1Wire Master spielen lassen. Dieser pollt dann die angeschlossenen Sensoren.
Bei Änderungen kann dieser Events über Funkt (AskSin, SWAP, was auch immer) wegschicken.
Die Schwellwerte muss man natürlich entsprechend konfigurieren.
Gruß
Dirk
Zitat von: ntruchsess am 12 Mai 2014, 17:57:20
Im Kontext des Firmata-protokolls (und ausschließlich darauf bezog sich meine Aussage) ist der AVR per Definition nicht der Master. Und genau deshalb ist das Firmata-protokoll nicht besonders gut für die Anbindung über ISM-Band-funkfrequenzen geeignet.
Ja, das hab ich daraus entnommen.
Das war lediglich ein Vorschlag wie das ganze ohne Polling Over The Air auskommen würde.
... nicht dass sich wer wundert. Ich hab meine Offtopic-Beiträge zur Firmata gerade alle entsorgt.
Wie ist eigentlich der Stand der Dinge hier?
Suche eine Möglichkeit, meine iButtons per Funk an zu binden und würde am liebsten bei 868Mhz bleiben