Nachdem ich mich nun lange gequält habe, frage ich nochmal das FHEM-Forum.
Das letzte Mal war es auch ein Bug im Code, was mich Stunden gekostet hat.
Mittlw. habe ich eine hohe Anzahl an Komponenten von Homematic im Betrieb.
Bei manchen musste ich mich wirklich abquälen. Das muss ich jetzt mal loswerden. Insbesondere beim KeyMatic,
wo das Pairing, Peering, Dualset, Singleset alles andere als einfach erklärt ist.
Schlüssel hinzufügen, entfernen usw.
Genaugenommen ist die AES-Konfiguration eher "sehr schlecht" beschrieben. Was aesKeyNbr usw. bedeutet.
Irgendwie ist man sich nicht sicher, ob eine AES-Signierung wirklich aktiv ist.
Was ist der richtige Vorgang, um ein Pairing hinzubekommen?
Muss ich die Komponente erst mit der Homematic-Software pairen? Ich benutze den Homematic-Lan-Adapter.
Der Key wurde ja schon früher geändert. Kann ich dann einfach auf sign=on setzen? Oder muss ich noch
expectAES setzen? Fragen über Fragen, die mich nachts quälen. :)
Aber: FHEM ist ein großartiges Projekt, wo viele ambitionierte Entwickler eine Menge Hirnschmalz verbraten haben.
Vielen Dank an Alle, die sich in ihrer Freizeit so viel Zeit nehmen und das wohl herstellerumfangreichste System geschaffen haben. Danke!
Aber zurück zum Thema:
Die Steckdose "HM-ES-PMSw1-Pl" nimmt kein "sign" entgegen und deshalb ist "AES" nicht aktivierbar.
Wenn ich die Komponente über die Homematic-Software "paare", geht's.
Wenn ich das Attribut auf den Channel Sw (Switch) "sign=on" setze, bekomme ich als Fehlermeldung:
sign failed: supported register are intKeyVisib lgActionType lgCtDlyOff lgCtDlyOn lgCtOff lgCtOn lgCtValHi lgCtValLo lgMultiExec lgOffDly lgOffTime lgOffTimeMode lgOnDly lgOnTime lgOnTimeMode lgSwJtDlyOff lgSwJtDlyOn lgSwJtOff lgSwJtOn localResDis pairCentral shActionType shCtDlyOff shCtDlyOn shCtOff shCtOn shCtValHi shCtValLo shOffDly shOffTime shOffTimeMode shOnDly shOnTime shOnTimeMode shSwJtDlyOff shSwJtDlyOn shSwJtOff shSwJtOn
Gerade bei den Steckdosen ist es eine sehr wichtige Funktion, da u.U. sensiblere oder gefährlichere Geräte als
nur Licht geschaltet werden.
Hat sich denn noch Niemand mit der sichereren Schaltweise und dem Gerät beschäftigt?
Hmmm...
Please help.
ZitatBei manchen musste ich mich wirklich abquälen. Das muss ich jetzt mal loswerden. Insbesondere beim KeyMatic,
wo das Pairing, Peering, Dualset, Singleset alles andere als einfach erklärt ist.
Schlüssel hinzufügen, entfernen usw.
fasse es doch einmal zusammen, wo
- es hakt
- wie man es erklären kann
pairen ist immer gleich - für alle Devices
peeren eigentlich auch
dual und single ist eh nur "kür", da es nur einen default zu verfügung stellt.
Wenn du erklärst, was du willst/hast kann man templates für keymatic definieren (HMInfo), die man dann nutzen kann zum Prüfen der Installation sowie zum Setzen.
ZitatGenaugenommen ist die AES-Konfiguration eher "sehr schlecht" beschrieben. Was aesKeyNbr usw. bedeutet.
wie genau die zuordnung gemacht wird, wenn man den Schlüssel öfter ändert ist nicht 100% klar - da kannst du gerne Infos schicken
ZitatIrgendwie ist man sich nicht sicher, ob eine AES-Signierung wirklich aktiv ist.
da solltest du entsprechende Readings bekommen, wenn eine Transaktion mit AES ausgeführt wurde - kommt da nichts? Dann bitte rohmessages und die Events dazu
ZitatWas ist der richtige Vorgang, um ein Pairing hinzubekommen?
http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen
ZitatMuss ich die Komponente erst mit der Homematic-Software pairen?
Gute Idee ist immer, die HMId der HM-SW und die in FHEM gleich zu setzen. Dann ist pairing sowieso nur einmal notwendig.
Ein pairing mit HM-SW ist notwendig, wenn man AES Schlüssel an das Device übertragen will. Dass dies nur mit HMSW funktioniert ist auch beschrieben (wiki hast du schon gelesen - oder?)
Zuerst muss ein Schlüssel vergeben werden. FHEM unterstützt nicht das Verteilen des Schlüssels auf die HM Komponenten. Hierzu ist die HM Konfigurationssoftware (HM-PC-Software) notwendig oder eine CCU. ZitatKann ich dann einfach auf sign=on setzen? Oder muss ich noch expectAES setzen?
sign setzt, dass der Channel AES haben will - von wer auch immer kommands an ihn sendet
expectAES (wie der Name schon sagt) bedeuted, dass der sensor (gibt es nur dort) erwarten sollte, dass der Channel, an den er den Trigger senden wird, voraussichtlich eine AES signatur haben will. Was das ändert ist mir nicht 100% klar - aber ich vermute, dass das Device nach einem trigger länger wach bleibt, um auf die Anfrage zu warten.
schicke einmal die registerlisten aller Kanäle des PMSw1.
mache in Device ein
saveConfig <filename>
und schicke das File
Hallo martinp876,
ersteinmal danke für deine sehr nette und ausführliche Antwort. Man merkt richtig, wie Du dir Mühe gibst.
Was ich nicht verstehe ist, wann der AES-Key an die Einheit übertragen wird, wenn ich diese mit der HM-Software verbinde. Bleibt der Key
auch erhalten, wenn ich sie aus der HM-Software entferne, also ablerne?
Muss ich nicht in FHEM ein Pairing durchführen, damit ich nicht die Einheit und alle Attribute bekomme? Wenn ich das nicht mache,
müsste ich doch alles manuell anlegen. Ist das richtig?
Ich habe z.B. ein 4-fach Schalter "HM-LC-SW4-DR" für das Hutschienensystem. Da kann ich einfach sign auf "on" setzen. Das
hat der anstandslos akzeptiert. Habe das Device aber nie über die HM-Software gepairt, nur mit FHEM. Habe ich nun AES,
wenn im Eventlog "aesKeyNbr: 00" steht?!?
Hier der Auszug der Steckdosen-Einheit, wo ich kein AES setzen kann. Irgendwie scheint da in FHEM echt der Wurm drin zu stecken.
Die Steckdosen per AES schalten zu können, liegt mir sehr am Herzen.
#======== store device data:Pwr_Boiler === from: 2014-08-12 17:59:03
#--- entity:Pwr_Boiler
setreading Pwr_Boiler D-firmware 1.4
setreading Pwr_Boiler D-serialNr {removed}
set Pwr_Boiler regBulk RegL_00: 02:01 0A:32 0B:13 0C:21 18:00 00:00
# timestamp of the readings for reference
# 2014-07-13 10:50:58 :RegL_00:
#--- entity:Pwr_Boiler_Pwr
set Pwr_Boiler_Pwr regBulk RegL_01: 08:00 7A:01 7B:08 7C:00 7D:27 7E:10 7F:00 80:64 81:00 82:64 83:64 00:00
# timestamp of the readings for reference
# 2014-07-13 10:50:59 :RegL_01:
#--- entity:Pwr_Boiler_SenF
# Peer Names:
set Pwr_Boiler_SenF peerBulk 00000000,
set Pwr_Boiler_SenF regBulk RegL_01: 08:00 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:13 8A:9C 8B:00 8C:00 8D:13 8E:74 00:00
# timestamp of the readings for reference
# :peerList
# 2014-07-13 10:51:05 :RegL_01:
#--- entity:Pwr_Boiler_SenI
# Peer Names:
set Pwr_Boiler_SenI peerBulk 00000000,
set Pwr_Boiler_SenI regBulk RegL_01: 08:00 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:07 8A:D0 8B:00 8C:00 8D:03 8E:E8 00:00
# timestamp of the readings for reference
# :peerList
# 2014-07-13 10:51:02 :RegL_01:
#--- entity:Pwr_Boiler_SenPwr
# Peer Names:
set Pwr_Boiler_SenPwr peerBulk 00000000,
set Pwr_Boiler_SenPwr regBulk RegL_01: 08:00 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:4E 8A:20 8B:00 8C:00 8D:27 8E:10 00:00
# timestamp of the readings for reference
# :peerList
# 2014-07-13 10:51:01 :RegL_01:
#--- entity:Pwr_Boiler_SenU
# Peer Names:
set Pwr_Boiler_SenU peerBulk 00000000,
set Pwr_Boiler_SenU regBulk RegL_01: 08:00 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:09 8A:60 8B:00 8C:00 8D:08 8E:98 00:00
# timestamp of the readings for reference
# :peerList
# 2014-07-13 10:51:04 :RegL_01:
#--- entity:Pwr_Boiler_Sw
# Peer Names:
set Pwr_Boiler_Sw peerBulk 00000000,
# timestamp of the readings for reference
# :peerList
======= finished ===
ZitatWas ich nicht verstehe ist, wann der AES-Key an die Einheit übertragen wird, wenn ich diese mit der HM-Software verbinde
für die HM-SW bin ich nicht verantwortlich und HM veröffentlicht es nicht. Es gibt so viele Fälle....
Im Normalfall sollte die SW den key schnellstmöglich übertragen - an jedes Device.
Zitatbleibt der Key auch erhalten, wenn ich sie aus der HM-Software entferne, also ablerne?
sollte so sein. Es ist sicher immer ein key vorhanden - beim Ablernen müsste sonst ein default-key gesetzt werden... hm - gesehen habe ich da noch nichts. Gute Frage, wir eQ3 sich den Systemwechsel eines Device vorstellt.
ZitatMuss ich nicht in FHEM ein Pairing durchführen, damit ich nicht die Einheit und alle Attribute bekomme?
eine config message des Device ist notwendig, damit FHEM das Device erkennen kann und alle Parameter einrichtet.
Pairen ist das eintragen der HMId von FHEM in das Device. Erst dann ist FHEM berechtigt, kommandos an das Device zu schicken (AES ist noch einmal ein Level on-Top).
ZitatWenn ich das nicht mache,müsste ich doch alles manuell anlegen.
einmal anlernen am Device drücken (ohne pairen) und es werden alle systemrelevanten Attribute angelegt oder auch upgedated. Man KANN bei der Gelegenheit auch pairen. Das Device akzeptiert das pairen (wenn es nicht schon gepairt ist) während seiner config Phase. Daher überlappen sich die beiden Aktionen im Normalfall.
ZitatHabe ich nun AES, wenn im Eventlog "aesKeyNbr: 00" steht?!?
Das Device sollte bei allen Eingriffen (register setzen, Schalten,..) eine AES signatur erfragen, wenn es eingeschaltet ist. DieFrage ist nur, welcher key verwendet wird - es gibt wohl einen (weng sicheren, weil bekannten...) default-key. Ich kennen ihn übrigens nicht...
key-number ist nur die Nummer des key, nicht der key.
Sign scheint beim PMSw1 unterstützt zu werden - werde ich einbauen. Heute voraussichtlich nicht mehr :(
Vielen, vielen Dank! Deine Antworten helfen ungemein weiter!
Ich werde ein paar Ideen und Lösungen auch mal demnächst hier im Forum posten.
Perl ist nicht gerade meine Sprache. Entwickelst du auch? Es wäre super, wenn gerade die neue Generation der Homematic-Steckdosen mit der AES-Sache implementiert wäre.
Ein großes Dankeschön schonmal im voraus!
ist in SVN - morgen auch per Update
Das ging aber sehr schnell! Vielen Dank!
das register sign hat nun seinen platz in chn2 (messwert-channel) gefunden. schön, dass es existiert. wäre es von der logik nicht besser im device- oder aktor-channel aufgehoben? wahrscheinlich gibt auch hier eq3 die vorlage?
SwitchES01_Pwr type:powerMeter -
list:peer register :value
1: averaging :1 s
1: sign :off
1: txMinDly :1 s
1: txThrCur :2 mA
1: txThrFrq :unused
1: txThrPwr :unused
1: txThrVlt :6.4 V
gruss frank
exact - kommt von eQ3. Da es dem Kanal zugeordnet ist kann man das Schalten eines jeden Kanals mit AES versehen - oder nicht.
AES erzeugt einen durchaus relevanten Overhead - und einen Delay. Daher scheint es eQ3 so sinnvoll. Es pauschal einzurichten ist eher wenig sinnvoll.
AES auf device - level könnte es auch geben - habe aber noch kein Bit dafür identifiziert
Nabend,
ich habe auch gerade versucht mein HM-ES-PMSw1-Pl auf AES umzustellen. Leider funktioniert es nicht.
Ich habe die Firmware des HM-ES-PMSw1-Pl mit der Homematic Software auf Version 1.6 upgedatet. Danach habe ich ebenfalls in der Homematic Software meinen Key gesetzt (hatte davor noch keinen). Ich konnte bei allen Channels das sign einschalten, nur beim wichtigen "Switch" channel geht es nicht.
Hier bekomme ich die Meldung:
cannot calculate value. Please issue set pws01_Sw getConfig first - invalid
Das Kommando set pws01_Sw getConfig führt er auch brav aus. Ich kann aber kein Register R-sign sehen.
Hier noch meine "Konfig"
#======== store device data:pws01 === from: 2014-10-24 01:04:38
#--- entity:pws01
setreading pws01 D-firmware 1.4
setreading pws01 D-serialNr KEQ0xxxxxx
setreading pws01 .D-devInfo 3F0100
setreading pws01 .D-stc 51
set pws01 regBulk RegL_00: 02:81 0A:54 0B:86 0C:23 18:00 00:00
# timestamp of the readings for reference
# 2014-10-24 00:42:51 :RegL_00:
#--- entity:pws01_Pwr
set pws01_Pwr regBulk RegL_01: 08:01 7A:01 7B:08 7C:00 7D:27 7E:10 7F:00 80:64 81:00 82:64 83:64 00:00
# timestamp of the readings for reference
# 2014-10-24 00:42:53 :RegL_01:
#--- entity:pws01_SenF
# Peer Names:
set pws01_SenF peerBulk 00000000,
set pws01_SenF regBulk RegL_01: 08:01 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:13 8A:9C 8B:00 8C:00 8D:13 8E:74 00:00
# timestamp of the readings for reference
# :peerList
# 2014-10-24 00:42:58 :RegL_01:
#--- entity:pws01_SenI
# Peer Names:
set pws01_SenI peerBulk 00000000,
set pws01_SenI regBulk RegL_01: 08:01 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:07 8A:D0 8B:00 8C:00 8D:03 8E:E8 00:00
# timestamp of the readings for reference
# :peerList
# 2014-10-24 00:42:55 :RegL_01:
#--- entity:pws01_SenPwr
# Peer Names:
set pws01_SenPwr peerBulk 00000000,
set pws01_SenPwr regBulk RegL_01: 08:01 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:4E 8A:20 8B:00 8C:00 8D:27 8E:10 00:00
# timestamp of the readings for reference
# :peerList
# 2014-10-24 00:42:54 :RegL_01:
#--- entity:pws01_SenU
# Peer Names:
set pws01_SenU peerBulk 00000000,
set pws01_SenU regBulk RegL_01: 08:01 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:09 8A:60 8B:00 8C:00 8D:08 8E:98 00:00
# timestamp of the readings for reference
# :peerList
# 2014-10-24 00:42:57 :RegL_01:
#--- entity:pws01_Sw
# Peer Names:self01,
set pws01_Sw peerBulk 00000000,251B5001,
set pws01_Sw regBulk RegL_03:self01 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:21 8B:14 8C:63 00:00
# timestamp of the readings for reference
# self01, :peerList
# 2014-10-24 00:56:18 :RegL_03:self01
======= finished ===
Fhem ist auf dem aktuellen Stand.
Liegt das eventuell an der neuen Firmware?
solltest du aber - in den Kanälen
Nabend,
ja, ich kann das sign in jedem Kanal setzen, nur nicht auf dem _sw Kanal und genau dieser wird ja zum ein und aus schalten benötigt.
Hier noch was in meiner fhme.save zu dem Device steht. Hier sieht man auch, dass es in dem _sw kein sign gibt.
setstate pws01 2014-04-07 18:58:24 .D-devInfo 3F0100
setstate pws01 2014-04-07 18:58:24 .D-stc 51
setstate pws01 2014-10-28 01:10:04 .protLastRcv 2014-10-28 01:10:04
setstate pws01 2014-10-26 02:12:17 Activity alive
setstate pws01 2014-10-24 00:40:22 CommandAccepted yes
setstate pws01 2014-04-07 18:58:24 D-firmware 1.4
setstate pws01 2014-04-07 18:58:24 D-serialNr KEQ0xxxxxx
setstate pws01 2014-10-24 00:42:51 PairedTo 0xxxxxxx
setstate pws01 2014-10-24 00:21:41 R-intKeyVisib visib
setstate pws01 2014-10-24 00:21:41 R-localResDis off
setstate pws01 2014-10-24 00:21:41 R-pairCentral 0xxxxxxx
setstate pws01 2014-10-24 00:42:51 RegL_00: 02:81 0A:54 0B:86 0C:23 18:00 00:00
setstate pws01 2014-05-04 23:19:09 powerOn -
setstate pws01 2014-10-28 00:37:52 state CMDs_done
setstate pws01_Pwr 1013.3
setstate pws01_Pwr 2014-04-07 19:09:05 R-averaging 1 s
setstate pws01_Pwr 2014-10-24 00:31:42 R-sign on
setstate pws01_Pwr 2014-04-07 19:09:05 R-txMinDly 8 s
setstate pws01_Pwr 2014-04-07 19:09:05 R-txThrCur 100 mA
setstate pws01_Pwr 2014-04-07 19:09:05 R-txThrFrq 1 Hz
setstate pws01_Pwr 2014-04-07 19:09:05 R-txThrPwr 100 W
setstate pws01_Pwr 2014-04-07 19:09:05 R-txThrVlt 10 V
setstate pws01_Pwr 2014-10-24 00:42:53 RegL_01: 08:01 7A:01 7B:08 7C:00 7D:27 7E:10 7F:00 80:64 81:00 82:64 83:64 00:00
setstate pws01_Pwr 2014-10-28 01:10:04 boot off
setstate pws01_Pwr 2014-10-28 01:10:04 current 0
setstate pws01_Pwr 2014-10-28 01:10:04 eState E: 1013.3 P: 0 I: 0 U: 237.2 f: 49.97
setstate pws01_Pwr 2014-10-28 01:10:04 energy 1013.3
setstate pws01_Pwr 2014-05-04 23:19:09 energyOffset 0
setstate pws01_Pwr 2014-10-28 01:10:04 frequency 49.97
setstate pws01_Pwr 2014-10-28 01:10:04 power 0
setstate pws01_Pwr 2014-10-28 01:10:04 state 1013.3
setstate pws01_Pwr 2014-10-28 01:10:04 voltage 237.2
setstate pws01_SenF 49.97
setstate pws01_SenF 2014-10-24 00:21:48 R-cndTxCycAbove off
setstate pws01_SenF 2014-10-24 00:21:48 R-cndTxCycBelow off
setstate pws01_SenF 2014-10-24 00:21:48 R-cndTxDecAbove 200
setstate pws01_SenF 2014-10-24 00:21:48 R-cndTxDecBelow 0
setstate pws01_SenF 2014-10-24 00:21:48 R-cndTxFalling off
setstate pws01_SenF 2014-10-24 00:21:48 R-cndTxRising off
setstate pws01_SenF 2014-04-07 19:09:21 R-ledOnTime 0.5 s
setstate pws01_SenF 2014-10-24 00:40:26 R-sign on
setstate pws01_SenF 2014-10-24 00:21:48 R-transmitTryMax 6
setstate pws01_SenF 2014-10-24 00:21:48 R-txThrHiFrq 50.2 Hz
setstate pws01_SenF 2014-10-24 00:21:48 R-txThrLoFrq 49.8 Hz
setstate pws01_SenF 2014-10-24 00:42:58 RegL_01: 08:01 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:13 8A:9C 8B:00 8C:00 8D:13 8E:74 00:00
setstate pws01_SenF 2014-10-28 01:10:04 state 49.97
setstate pws01_SenI 0
setstate pws01_SenI 2014-10-24 00:21:45 R-cndTxCycAbove off
setstate pws01_SenI 2014-10-24 00:21:45 R-cndTxCycBelow off
setstate pws01_SenI 2014-10-24 00:21:45 R-cndTxDecAbove 200
setstate pws01_SenI 2014-10-24 00:21:45 R-cndTxDecBelow 0
setstate pws01_SenI 2014-10-24 00:21:45 R-cndTxFalling off
setstate pws01_SenI 2014-10-24 00:21:45 R-cndTxRising off
setstate pws01_SenI 2014-04-07 19:09:13 R-ledOnTime 0.5 s
setstate pws01_SenI 2014-10-24 00:40:09 R-sign on
setstate pws01_SenI 2014-10-24 00:21:45 R-transmitTryMax 6
setstate pws01_SenI 2014-10-24 00:21:45 R-txThrHiCur 2000 mA
setstate pws01_SenI 2014-10-24 00:21:45 R-txThrLoCur 1000 mA
setstate pws01_SenI 2014-10-24 00:42:55 RegL_01: 08:01 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:07 8A:D0 8B:00 8C:00 8D:03 8E:E8 00:00
setstate pws01_SenI 2014-10-28 01:10:04 state 0
setstate pws01_SenPwr 0
setstate pws01_SenPwr 2014-10-24 00:21:43 R-cndTxCycAbove off
setstate pws01_SenPwr 2014-10-24 00:21:43 R-cndTxCycBelow off
setstate pws01_SenPwr 2014-10-24 00:21:43 R-cndTxDecAbove 200
setstate pws01_SenPwr 2014-10-24 00:21:43 R-cndTxDecBelow 0
setstate pws01_SenPwr 2014-10-24 00:21:43 R-cndTxFalling off
setstate pws01_SenPwr 2014-10-24 00:21:43 R-cndTxRising off
setstate pws01_SenPwr 2014-04-07 19:09:09 R-ledOnTime 0.5 s
setstate pws01_SenPwr 2014-10-24 00:39:57 R-sign on
setstate pws01_SenPwr 2014-10-24 00:21:43 R-transmitTryMax 6
setstate pws01_SenPwr 2014-10-24 00:21:43 R-txThrHiPwr 200 W
setstate pws01_SenPwr 2014-10-24 00:21:43 R-txThrLoPwr 100 W
setstate pws01_SenPwr 2014-10-24 00:42:54 RegL_01: 08:01 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:4E 8A:20 8B:00 8C:00 8D:27 8E:10 00:00
setstate pws01_SenPwr 2014-10-28 01:10:04 state 0
setstate pws01_SenU 237.2
setstate pws01_SenU 2014-10-24 00:21:46 R-cndTxCycAbove off
setstate pws01_SenU 2014-10-24 00:21:46 R-cndTxCycBelow off
setstate pws01_SenU 2014-10-24 00:21:46 R-cndTxDecAbove 200
setstate pws01_SenU 2014-10-24 00:21:46 R-cndTxDecBelow 0
setstate pws01_SenU 2014-10-24 00:21:46 R-cndTxFalling off
setstate pws01_SenU 2014-10-24 00:21:46 R-cndTxRising off
setstate pws01_SenU 2014-04-07 19:09:17 R-ledOnTime 0.5 s
setstate pws01_SenU 2014-10-24 00:40:18 R-sign on
setstate pws01_SenU 2014-10-24 00:21:46 R-transmitTryMax 6
setstate pws01_SenU 2014-10-24 00:21:46 R-txThrHiVlt 240 V
setstate pws01_SenU 2014-10-24 00:21:46 R-txThrLoVlt 220 V
setstate pws01_SenU 2014-10-24 00:42:57 RegL_01: 08:01 22:64 30:06 84:00 85:C8 86:00 87:00 88:00 89:09 8A:60 8B:00 8C:00 8D:08 8E:98 00:00
setstate pws01_SenU 2014-10-28 01:10:04 state 237.2
setstate pws01_Sw off
setstate pws01_Sw 2014-10-26 08:39:38 CommandAccepted yes
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgActionType jmpToTarget
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgCtDlyOff geLo
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgCtDlyOn geLo
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgCtOff geLo
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgCtOn geLo
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgCtValHi 100
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgCtValLo 50
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgMultiExec on
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgOffDly 0 s
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgOffTime unused
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgOffTimeMode absolut
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgOnDly 0 s
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgOnTime unused
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgOnTimeMode absolut
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgSwJtDlyOff off
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgSwJtDlyOn on
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgSwJtOff dlyOn
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-lgSwJtOn dlyOff
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shActionType jmpToTarget
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shCtDlyOff geLo
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shCtDlyOn geLo
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shCtOff geLo
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shCtOn geLo
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shCtValHi 100
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shCtValLo 50
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shOffDly 0 s
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shOffTime unused
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shOffTimeMode absolut
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shOnDly 0 s
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shOnTime unused
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shOnTimeMode absolut
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shSwJtDlyOff off
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shSwJtDlyOn on
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shSwJtOff dlyOn
setstate pws01_Sw 2014-10-24 00:21:49 R-self01-shSwJtOn dlyOff
setstate pws01_Sw 2014-10-24 00:56:18 RegL_03:self01 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:21 8B:14 8C:63 00:00
setstate pws01_Sw 2014-10-28 00:37:46 deviceMsg off (to HMLAN0)
setstate pws01_Sw 2014-10-28 00:37:46 level 0
setstate pws01_Sw 2014-10-28 00:37:46 pct 0
setstate pws01_Sw 2014-10-24 00:56:17 peerList self01,
setstate pws01_Sw 2014-10-28 00:37:46 recentStateType info
setstate pws01_Sw 2014-10-28 00:37:46 state off
setstate pws01_Sw 2014-10-28 00:37:46 timedOn off
Scheint mir eher an der neuen Firmware 1.6 zu liegen. Diese ganze self01 Geschichte war vor dem UPdate auch noch cniht da.