FHEM Forum

Hallo,

mir ist heute zum 2. mal aufgefallen, das ich meine Keymatic nicht mehr mit FHEM und HMLAN steuern lies. Dem bin ich auf den Grund gegangen. Also habe ich kurz den HMLAN mit der Windows Software verbunden und dann wieder mit FHEM. Danach ging das steuern wieder mit FHEM. Ich habe dann den HMLAN Stromlos gemacht und danach ging es wieder nicht und ich musste ihn erneut mit der Windows Software verbinden.

Da ich alles andere noch steuern konnte (Licht etc.) gehe ich davon aus, das es das es an meinem eigenen AES Signierung-Schlüssel liegt. SChienbar wird der Schlüssel nicht dauerhaft im HMLAN gespeichert und wenn der HMLAN Stromlos wird, müsste FHEM den Schlüssel neu setzen.

Gibt es dafür ein Atrtibbut, so ähnlich wie man die HMID setzt, in der CommandRef habe ich nichts gefunden:


attr HMLAN1 hmId AACCEE

Oder liegt es doch an etwas anderem, das es nach einem Stromausfall nicht mehr geht?

hallo samsi,

kann ich dir leider nicht sagen. AES nutze ich nicht. ich denke aber dass es doch einige nutzen. Und die werden wohl nicht immer die windows-SW zwischenschalten.
Demnach müsste es etwas anderes sein...

wenn du bereit bist, die init-sequenz des HLMAN mit der PC-SW zu loggen kann ich es durchsehen. Gerne auch per pm

Gruss Martin

Hallo,

habe es gerade mal mit Wireshark mitgeschnitten. Das Passwort wird tatsächlich bei der Initialisierung übertragen, und zwar so, wie es in der keys Datei im Ordner BidcosService von der Windows software abgespeichert wurde. Ist vermutlich nur ein Hash des eigentlichen Passworts.

Ich hab das Passwort aber in der Datei die ich dir schicke mal ersetzt.

Anstelle von ABCDEF12345678901234567890123456 steht dort mein richtiges Passwort.


Grüße

EDIT: Habe gerade mal geschaut das was in der Keys gespeichert wird und an den HMLAN übertragen wird ist ein MD5 Hash des originalen Passwortes.

Hallo,

als ich versucht habe die AES-Kommunikation zu reverse-engineeren, habe ich mir folgendes notiert:


Setting a key (Position 0x01, Index 0x10):
< Y01,10,00112233445566778899AABBCCDDEEFF
> I00,10,00,00

Deleting a key (Position 0x01):
< Y01,00
> I00,00,00,00

Getting key index:
< Y
> I00,00,00,00


Die 0x10 ist der Schlüsselindex (wird genutzt um Geräte mit verschiedenen Schlüsseln erreichen zu können und z.B. einen Key-Exchange durchzuführen). Die Geräte kennen den Index "ihres" Schlüssels. Die Windows-Software kann mehrere Keys mit jeweiligem Index in der keys-Datei abspeichern. Index 0x00 ist der HM-Defaultschlüssel.

Wenn ich 00_HMLAN.pm richtig lese, wird ein als Attribut hmKey am HMLAN abgelegter Schlüssel bei der Initialisierung mit Key-Index 01 an den HMLAN übertragen. Evtl. wäre es hier praktisch, den Key-Index auch noch in einem Attribut zu speichern.

Gruß
  Michael

Hallo,

 ich habe auch mehrere Keys in der Bidcos Keys DAtei, insgesamt 3 stück und 2 davon tauchen auf:


Y02,02,ABCDEF12345678901234567890123456 (Key 2)
Y01,03,ABCDEF12345678901234567890123456 (Key 3 bzw. Current Key)

Den ersten Key (also den HM-DEfaultkey)  habe ich aber nicht im Mitschnitt gefunden.

hi,


somit ist Y01, Y02... eine Speicher für keys

aktuell werden sie in fhem immer zu null gesetzt


HMLAN_Send:  LANIf1 I:C
HMLAN_Send:  LANIf1 I:Y01,01,
HMLAN_Send:  LANIf1 I:Y02,00,
HMLAN_Send:  LANIf1 I:Y03,00,
HMLAN_Send:  LANIf1 I:Y03,00,

Es ist kein Problem, diese Werte zu senden. Michael, du weisst, wie man ihn generiert? Es ist wohl immer ein 16 byte wert, ascii-hex übertragen.
wir können das in einem Attribut speichern, oder besser den Wert eingeben und dann kodiert speichern.
Wenn du die codierungsvorschrift schickst, kann ich es probieren

Danke Martin

ps:
nachtrag - es gibt ja noch das attribut "hmkey" - trage deinen key einfach einmal dort ein.
Falls mehr keys benötigt werden können wir dies erweitern

Gruss Martin

Hallo Martin,

Zitat von: martinp876 schrieb am Mi, 25 September 2013 22:25somit ist Y01, Y02... eine Speicher für keys

Ja, genau.

Zitataktuell werden sie in fhem immer zu null gesetzt

Nicht ganz:

ZitatHMLAN_Send:  LANIf1 I:Y01,01,

Das setzen eines leeren Keys an einem anderen Index als 00 ist ungültig, damit wird der Key in Slot 01 nicht angefasst (und der von Windows gesetzte Key auch nicht überschrieben).

ZitatHMLAN_Send:  LANIf1 I:Y02,00,
HMLAN_Send:  LANIf1 I:Y03,00,
HMLAN_Send:  LANIf1 I:Y03,00,

Die Keys in den anderen Slots werden aber hiermit in der Initialisierungsphase gelöscht.

ZitatEs ist kein Problem, diese Werte zu senden. Michael, du weisst, wie man ihn generiert? Es ist wohl immer ein 16 byte wert, ascii-hex übertragen.

Ja, das ist wie Samsi sagte der MD5-Hash (128bit) des in die Windows-Software eingegebenen Passworts.

Zitatwir können das in einem Attribut speichern, oder besser den Wert eingeben und dann kodiert speichern.
Wenn du die codierungsvorschrift schickst, kann ich es probieren


use Digest::MD5 qw(md5);

my $key = unpack('H*', md5($passwort));


Zitatnachtrag - es gibt ja noch das attribut "hmkey" - trage deinen key einfach einmal dort ein.
Falls mehr keys benötigt werden können wir dies erweitern

Ja, das nimmt aber immer Keyindex 1. Da die Geräte ihren Keyindex kennen, wird die Kommunikation nur funktionieren, wenn der richtige Key mit dem richtigen Index gespeichert ist (Bei Samsi ist es beispielsweise 3). Also sollte der Index auch noch in ein Attribut.

Gruß
  Michael

Hallo Michael,

ich fände es gut, wenn man in der FHEM.cfg nur den Hash speichert,den kann sich ja jeder aus der Windows Software raus kopieren, dann hat er auch gleich den richtigen Index. Es gibt ja immer noch leute, die nehmen für alles das gleiche Passwort, es sollte deshalb nicht im Klartext in der Config stehen.

Hallo Michael
ok, baue ich einmal ein. Danke

@Samsi,
stimme ich absolut zu. Die Eingabe kann man im klartext machen stelle ich mir vor. oder eben auch also hash

Gruss Martin

ist eingebaut.

du hast 3 keys. Bei der Eingabe wird, wenn er nicht encrypted ist die encryption gestartet.
Sollte ein key vorliegen, also er aussehen wie ein key, wird er nicht konvertiert sondern so genommen. Das erlaubt auch das speichern der des coded keys in fhem.cfg.

siehe Version 3965,teste doch einmal

hast du eine Idee, wozu die 3 gebraucht werden? könnte man in der Beschreibung aufnehmen

Ach ja, das setzen des Attibutes bringt eine rückmeldung. geht nicht anders, da ich sonst den Inhalt nicht modifizieren kann.

Gruss Martin

Hallo Martin,

ich denke nicht das es nur 3 sind, denn jedes mal wenn ich den key in der Windows Software ändere, kommt ein neuer Eintrag dazu. Ich denke die werden gebraucht, da es ja manche Geräte gibt, bei denen man die Anlerntaste drücken muss, erst dann kann er den neuen Key updaten.
Wenn jetzt ein User das nicht weiss (und das wird vermutlich vielen Usern am Anfang so gehen) und mehrmals den Schlüssel ändert, hat er plötzlich 10 Geräte mit 5 verschiedenen Keys.

Geht jetzt ein Gerät in den Anlernmodus, nachdem der User den Schlüssel schon zum 5. mal geändert hat und gibt an das er eine Signierung mit key 01 erwarted, dann kann der Adapter das entsprechend auch durchführen. Außerdem ist das System so auch dann noch funktionsfähig falls auf einigen Aktoren der Key nicht geändert werden konnte, wenn der Aktor mitteilt, mit welchem Key er die Signierung erwartet.

Ist allerdings nur eine Vermutung, aber ich denke so müsste es ein, sonst würde nach einem Schlüsselwechsel absolutes Chaos herrschen und der HMLAN müsste erst mal alle Keys die er kennt durchprobieren und zurück funken bis er den richtigen hat.

Viele Grüße

Hi,

kann ich mir nicht vorstellen, dass HM keys "durchprobiert". HMLAN kennt wohl auch keine Tabelle einer Zuordnung... oder, wo ich es gerade so schreibe, evtl doch.
Ich muss jedes Device im HMLAN bekanntgeben - da sind auch werte dabei, die ich nicht kenne. Könnte sein, dass dabei auch die Nummer des keys ist.
FHEM müsste dann die Zuordnung verwalten.

Das der Grund ein verzögertes Anlernen des keys ist kann ich mir doch nicht vorstellen.

Immerhin muss man sicherstellen, dass die Sensoren und die Aktoren auch miteinander können. Also ist eigentlich nur ein Key systemweit sinnvoll.

Unterm Strich ist es unklar.

Funktioniert es bei dir, wie es jetzt eingebaut ist?

Gruss Martin

Hallo Martin

Zitatkann ich mir nicht vorstellen, dass HM keys "durchprobiert"

Eben,ich auch nicht (ich meinte nur wenn er die keys nicht indizieren würde, müsste er alle durchprobieren). Deshalb gibt die Software vermutlich dem HMLAN immer die komplette INDZIERTE Liste mit allen Schlüssel. Wenn dann irgend ein Gerät eine Signierung am HMLAN anfordert braucht es nur noch seinen Keyindex mitzusenden und HMLAN weis sofort mit welchem Key es die Antwort erstellen muss.

ZitatAlso ist eigentlich nur ein Key Systemweit sinnvoll.

Richtig. Aber als ich meinen Key das erste mal geändert hatte, stand ich genau vor dem Problem, das die Keymatic sofort den neuen Key übernommen hatte, die angelernten Handsender aber nicht. Damit HMLAN aber den Key später bei den Handsendern ändern kann muss es ja auch den vorherigen Key kennen, denn ohne den alten key kann es ja nicht mit dem Handsender kommunizieren um den neuen Key zu speichern. Da HMLAN aber nicht genau weiss ob wirklich bei allen Geräten der Key geändert wurde, müssen folglich alle bisherigen Keys im HMLAN gespeichert werden.

Ich denke das es bei mir mit 3 Key ausreichen wird. Wenn aber jemand schon 5 mal den Schlüssel geändert hat und der aktuelle Schlüssel index 5 hat, das er dann auch 5 keys übertragen müsste, oder zumindest so das man den index für einen key, nämlich den aktuellsten, frei wählen kann.

Wenn Du mir sagt was ich in die fhem.cfg eingeben muss, teste ich es mal.


Ich werd jetzt erst mal updaten und hoffen das danach noch alles wie vorher läuft ;)

 

Hallo Martin,

ich habe es eben getestet, funktioniert einwandfrei. Wenn ich den key3 mit dem Schlüssel setze geht  meine Keymatic. Setze ich den falschen key geht sie erwartungsgemäß nicht mehr.

Setze ich den aktuellen Schlüssel an hmkey2, geht Sie auch nicht. Wenn also jemand schon bei index 5 ist, wird er den richtigen key nicht setzen können.

Beim speichern der fhem.cfg kommt  Error: hmKey3 set to (und dann Mein Key) funktionert aber trotzdem.

Allerdings wenn ich den HMLAN kurz vom Strom nehme wird der Key nicht neu übertragen. Ich muss dann die fhem.cfg einfach noch mal speichern, damit es geht.

Ich sage auf jeden Fall schon mal Danke ;)

hi samsi,

das mit dem HMLAN init werde ich nachreichen - mein Fehler.

den Fehler beim Speichern kann ich nicht reproduzieren.

Die Liste der keys zu verlängern bedeuted, das format zu aendern - ich kann ja keine Parameter 1-99 vorsehen. Man könnte den key dann eingeben mit nummer,trennzeichen,key. also
1:key.

somit konnte man einige keys zulassen, aber die nummer des keys wählbar machen. Vor dem einbau hätte ich gerne stabilere infos...

unklar ist auch das format. bisher kenne ich
Y01,00
Y02,00
Y03,00
 
wobei die 00 die nummer des schlüssels sein KÖNNTE. oder die Y01. auch unklar.

Gruss Martin

Hi Martin,

Zitat von: martinp876 schrieb am Sa, 28 September 2013 08:38Die Liste der keys zu verlängern bedeuted, das format zu aendern - ich kann ja keine Parameter 1-99 vorsehen. Man könnte den key dann eingeben mit nummer,trennzeichen,key. also
1:key.

Ja, das ist eine gute Idee.

Zitatunklar ist auch das format. bisher kenne ich
Y01,00
Y02,00
Y03,00

wobei die 00 die nummer des schlüssels sein KÖNNTE. oder die Y01. auch unklar.

Ja 00 ist die Nummer des (in diesem Fall HomeMatic Default-)Schlüssels.

Das Format ist:
YSlot,Index,Key

Der Slot ist der HMLAN interne Speicherplatz, der Index ist die "Version" des Schlüssels, wobei 00 (ein evtl. folgender Schlüssel wird ignoriert) wieder den HomeMatic Defaultschlüssel setzt.

Die Geräte geben den Schlüsselindex in einem Signing-Request mit an, damit weiss der HMLAN welchen Schlüssel er verwenden muss (und merkt sich dann wahrscheinlich den Key-Index zum jeweiligen Gerät).
Ich hatte damals noch mehr rausgefunden (u.a. auch den Schlüsselaustausch entschlüsseln können), aber anscheinend die Sniffs nicht aufgehoben. Was ich nicht rausbekommen habe, war was genau bei einer Signing-Response verschlüsselt wurde.

Gruß
  Michael

Hallo Martin,,

Zitatden Fehler beim Speichern kann ich nicht reproduzieren.

Der Fehler kommt nur wenn ich bei edit files auf fhem.cfg speichern klicke.

Wenn ich das Attribut übers Web Interface setze kommt der fehler nicht.

Vielleicht weil ich nur den 2. und 3. Key setze, den ersten aber nicht?

Hi Michael,

aufgenommen habe ich es auch einmal - aber so weit war ich lange nicht.

dann werde ich
hmKey <key>
hmKey2 <key>
hmKey3 <key>

erlauben und alternativ
hmKey no1:<key>
hmKey2 no2:<key>
hmKey3 no3:<key>

in beliebigen Mischungen der formate.

Zu beachten ist, dass devices beim HMLAN angemeldet werden. dabei werden weitere Datenfelder übertragen - die kann ich nicht dekodieren. Ich denke nicht, dass der HMLAN die zuordnung Key zu Device speichert - temporär schon, aber nicht non-volatil. das muss, genau wie den key, die Zentral senden. Wie weiss ich aber nicht.

Gruss Martin

Hi Martin,

Zitat von: martinp876 schrieb am Sa, 28 September 2013 12:13Zu beachten ist, dass devices beim HMLAN angemeldet werden. dabei werden weitere Datenfelder übertragen - die kann ich nicht dekodieren. Ich denke nicht, dass der HMLAN die zuordnung Key zu Device speichert - temporär schon, aber nicht non-volatil. das muss, genau wie den key, die Zentral senden. Wie weiss ich aber nicht.

Ja, temporär lernen meinte ich. Es ist gut möglich, dass die Zuordnung in den Datenfeldern drin stand, dummerweise hab ich den Sniff nicht mehr...
Das ist aber nicht so dramatisch, weil das letzte Byte der Challenge eines Geräts den vom Gerät benutzten Key-Index angibt, und so kann der HMLAN dann aus der Kommunikation (volatile) lernen, welches Gerät welchen Key gesetzt hat.

Gruß
  Michael

SW ist abgegeben...

Hi Martin,

mit der aktuellen Version (00_HMLAN.pm 3968) habe ich folgende Situation bei 15 HM-LC-Bl1PBU-FM:

• 9 ohne AES sign, funktionieren fehlerfrei
• 1 mit AES, funktioniert fehlerfrei
• 5 mit AES, liefern durchgängig AESreject und fahren nicht

Wenn ich mir die Log-Einträge ansehe mit "stat:0030 d:??", sehe ich folgendes Muster für "d:??":

d:04 1AB518 RolloSchalter02
d:04 1AF52B RolloSchalter04
d:04 1AF995 RolloSchalter07
d:04 1B711B RolloSchalter05
d:00 1B82AA RolloSchalter03
d:04 20BCB3 RolloSchalter10


Nun ist RolloSchalter03 genau derjenige der mit AES problemlos funktioniert (d:00), während die mit d:04 allesamt nicht funktionieren. Ist die Zahl hinter d: der Schlüsselindex? In der bidcos keys datei habe ich tatsächlich 4 Schlüssel stehen; warum der eine dann aber ausgerechnet Index 0 verwenden sollte ist mir unklar.

Anbei das Log vom Versuch, RolloSchalter01..11 auf 100% zu fahren (fhem-2013-09-30.log-1) - Danach habe ich die Schalter mit AES-Problem manuell gefahren (fhem-2013-09-30.log-2)

Bin sehr bereit, weitere Tests zu fahren

Viele Grüße,
Andy.

Hi Andy,

guter Hinweis, kann ich aber nicht beantworten.
das D: kommt ja vom device - und nach meinen Beobachtungen immer mit der AES message. Könnte also die Nummer des codes sein, der genutzt werden soll.

du kannst testhalber dein key4 setzen - auf einen freien platz im hmKey -also
attr <hmlan> hmkey2 4:<mykey>

Gruss Martin

Hi Martin,

hatte ich versucht, verlief aber etwa so:

attr HMLAN1 hmKey2 4:.....
illegal number:4


Edit: Hab nochmal kurz 00_HMLAN.pm angesehen, da wird auf Länge==2 getestet, werde also heut abend nochmal mit der richtigen Syntax versuchen (gut, ich hätte auch gleich nachsehen können bevor ich rummeckere ;-) ):

attr HMLAN1 hmKey2 04:.....



Gibt es einen Grund für die Beschränkung auf 3 Keys? Siehst Du eine Möglichkeit direkt die keys Datei einzulesen und alle darin befindlichen Keys zu verwenden? Hat sicher keinen Sinn, beliebig viele durchnummerierte hmKey Attribute vorzusehen...

Interessanterweise sind in meiner keys-Datei die ersten drei Schlüssel-codes identisch, erst der vierte (und aktuell genutzte) ist anders. Wohl ein kleiner trial-error-Unfall meiner ersten Zeit mit HomeMatic...

Grüße,
Andy.

Hallo Andy,

ich habe bisher keine werte grösser Y03 gesehen.

was steht in deiner key-datei? Kannst du diese posten - gerne auch die keys aus-x-en

man müsste dann ein Attribut mit den Dateinamen vergeben... mal sehen.

Gruss Martin

Hi Martin,

hier meine anonymisierte keys Datei. Beachte, Keys 1,2 und 3 sind identisch; Key 4 ist der zuletzt Eingegebene und Aktive:

Current Index = 4
Key 1 = 00112233445566778899AABBCCDDEEFF
Key 2 = 00112233445566778899AABBCCDDEEFF
Key 3 = 00112233445566778899AABBCCDDEEFF
Key 4 = FFEEDDCCBBAA99887766554433221100
Last Index = 3



Nachdem ich nun
attr HMLAN1 hmKey2 04:FFEEDDCCBBAA99887766554433221100eingegeben hatte, funktionierte alles perfekt, auch wenn ich nach wie vor Log-Einträge mit AESreject bekomme.

Vielleicht handelt es sich bei "stat:0030" doch nicht so sehr um einen Fehlercode als den Hinweis, dass eine Signierung angefragt wurde? Zum Vergleich zur Situation heute Morgen nochmal ein Log mit funktionierendem KeyId-4 in fhem-2013-09-30.log-3

Beste Grüße und nochmal vielen Dank für Deinen unermüdlichen Einsatz!
Andy.

Hallo Andy,

da hast du also sicher recht.
das bringt folgende dinge ans Licht:
d:xx ist die Nummer des AES-keys mit dem das Device arbeitet.
mit '0100' zeigt HMLAN an, dass eine AES message empfangen wurde
mit '0030' wird angezeigt, dass die message beantwortet wurde
was gesendet wurde kann man nicht sehen, ist aehnlich den ACKs, die HMLAN sendet.

Anhand deiner Daten möchte ich aktuell das einlesen einer Datei nicht implementieren - vielleicht später. immerhin muss man es parsen... duplikate entfernen.
ich kann mir vorstellen, dass es nicht mehr als 3 mögliche Einträge gibt. Das sollte machbar sein.
was ich einbauen werde ist ein Reading, welchen AES-key das device gerne hätte (also nur die Nummer, klar).
das Reading könnte "AESkeyNbr" heissen.


Gruss Martin

Hallo Martin,

nachdem nun alles sehr lange sehr gut funktionierte, bin ich auf etwas neues gestoßen: Für ein paar weitere Komponenten, die zu weit von meinem HMLAN entfernt ist, habe ich mir einen weiteren HMLAN zugelegt. Den und die daran gepairten Komponenten will ich allerdings ganz ohne AES betreiben (insbesondere auch ohne eigene AES Keys). Nachdem ich nun den HMLAN2 in FHEM eingebunden hatte, lief zunächst noch alles gut, bis plötzlich die RolloSchalter am HMLAN1 (mit eigenen Keys) nicht mehr steuerbar waren. Beheben konnte ich das erst, nachdem ich die Key-Attribute von HMLAN1 auch in HMLAN2 gesetzt hatte.

Deshalb meine Frage: Werden die Keys pro HMLAN Instanz verwaltet oder werden die Keys für alle Instanzen gleichermassen verwendet? Spielt die Reihenfolge der defines eine Rolle?

Im Moment funktioniert mit dem Workaround wieder alles, will nur verstehen wie's gedacht ist :-)

Beste Grüße,
Andy.

Hallo Andy,

die keys sollten/müssen je HMLAN definiert werden.
Wenn du mit 2 HMLAN arbeitest - wie sind die aufgesetzt? Folgendes musst du entscheiden:
a) HMLAN1 und 2 sollten unterschiedliche HMIds haben
b) du solltest das Attribut IODev bei jedem HM-Device setzen. Automatische Zuordnung macht hier keinen Sinn.

Ist das so? Welches IODev wurde bei dem fraglichen Rollo angezeigt?

Gruss Maritn

Danke Martin für den Hinweis, ich hatte tatsächlich fälschlicherweise angenommen, dass die FHEM-Entity des neu angelernten Device "weiss" welches sein IOdev sein sollte. Könnte diese Information nicht als Default aus der Information aus dem HM-Device abgeleitet werden?

Jedenfalls waren die IODev schnell für alle HM-Devices manuell gesetzt, nun funktioniert alles perfekt.

Eine andere Sache ist mir noch aufgefallen: Bei allen meinen HM-Devices steht das Reading aesKeyNbr auf "FF". Ich hatte Dich seinerzeit so verstanden, dass hier der key-index zu finden sein soll.

In den Logeinträgen habe ich gesehen, dass bei verschiedenen stat:xxxx auch unterschiedliche d:yy zu sehen sind. Hier eine Tabelle, für welche stat-Werte welche d-Werte bei den einzelnen Entities zu sehen sind:

stat	0000	0001	0021	0030	0040	0041	0050	0100	0201
BewegungsmelderEingang	d:FF	d:FF	----	----	----	----	----	----	d:FF
DisplayKeller	d:FF	d:FF	----	----	----	----	----	----	----
FensterSensor01	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor02	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor03	d:FF	----	----	----	d:01	----	d:01	d:FF	----
FensterSensor04	d:FF	----	----	----	d:01	----	d:01	d:FF	----
FensterSensor05	d:FF	----	----	----	----	----	----	----	----
FensterSensor06	d:FF	----	----	----	----	----	----	----	----
FensterSensor07	d:FF	----	----	----	d:01	----	d:01	d:FF	----
FensterSensor08	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor09	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor10	d:FF	----	----	----	----	----	----	----	----
FensterSensor11	d:FF	----	----	----	----	----	----	----	----
FensterSensor12	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor13	d:FF	----	----	----	----	----	----	----	----
FensterSensor14	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor15	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor16	d:FF	----	----	----	----	----	----	----	----
FensterSensor17	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor18	d:FF	----	----	----	----	----	----	----	----
FensterSensorKeller	d:FF	d:FF	----	----	d:01	d:01	----	d:FF	----
LichtDimmer01_dev	d:FF	d:FF	----	----	----	----	----	----	----
RolloSchalter01	d:FF	d:FF	d:00	d:04 d:00	----	----	----	d:FF	----
RolloSchalter02	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter03	d:FF	d:FF	d:00	d:00	----	----	----	d:FF	----
RolloSchalter04	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter05	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter06	d:FF	d:FF	d:00	d:00	----	----	----	d:FF	----
RolloSchalter07	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter08	d:FF	d:FF	d:00	d:00	----	----	----	d:FF	----
RolloSchalter09	d:FF	d:FF	d:00	----	----	----	----	d:FF	----
RolloSchalter10	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter11	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter12	d:FF	d:FF	d:04	----	----	----	----	d:FF	----
RolloSchalter13	d:FF	d:FF	d:04	----	----	----	----	d:FF	----
RolloSchalter14	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter15	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
Schalter6fach_01	d:FF	----	----	----	----	----	----	----	----
TH_Keller	d:FF	d:FF	----	----	----	----	----	----	----
TH_Loggia	d:FF	----	----	----	----	----	----	----	----
TH_Schlafzimmer	d:FF	----	----	----	----	----	----	----	----
TuersensorEingang	d:FF	d:FF	----	----	d:01	d:01	----	d:FF	----
TVPanelSupplySwitch	d:FF	d:FF	d:03	----	----	----	----	d:FF	----

Ein Sonderfall ist hier RolloSchalter01, den ich im Lauf des Monats mal zurückgesetzt habe und der seitdem auf dem "Standard"-AES-key besteht.

Hoffe das hilft, ansonsten kann ich auch gern konventionelle Log-Einträge beisteuern :-)

Beste Grüße,
Andy.

Hallo Andy,

Bei IODev gibt es einen Fortschritt:
- attribut IODev wird automatisch beim pairen gesetzt (auch überschrieben). Gesetzt wird das IODev,  von dem das pairen ausgelöst wurde
- sollte kein IODev eingetragen sein wird nich einmal gesucht

Stat und AES:

die Nummer des AES keys wird in d: benannt bei (Stat & 0x0020) - also bit 5 gesetzt.

Status 0x0200 signallisiert high-load (10 % bis Overload)

Falls verfügbar kannst du einen logausschnitt mir status 0x0050 schicken - den habe ich noch nie gesehen.

kritisch sehe ich TVPanelSupplySwitch - der ist auf AES key 03, alle anderen  sind auf nummer 04.


Gruss Martin

Hallo Martin,

super, das automatische setzen werde ich beim nächsten Schwung Hardwareanlernen gleichmal testen, die meisten gehen über HMLAN1 und nachdem HMALN2 bei mir danach definiert ist, waren die letzten Anlernversuche immer zweistufig (anlernen mit autocreate, IOdev einstellen, dann nachholen was ohne IOdev nicht geklappt hat, weil HMLAN2 ausserhalb der Reichweite lag).

Dass meine Devices unterschiedliche AES keys benutzen liegt sicher daran, dass ich in mehreren Wellen angelernt habe, ab und an mal versuchsweise den Schlüssel neu setzte (kriegt anscheinend trotz identischem Hash nen neuen Index) und nicht jedesmal alle Geräte neu angelernt habe. Deshalb sitzen die meisten (seitdem nicht zurückgesetzten) SEC-RHS (FensterSensor) auch auf AES key 01. Mache RolloSchalter habe ich in jüngster Vergangenheit auf Werkseinstellungen zurückgesetzt, dann aber die AES Signierung mit Werks-AES key aktiviert, ich vermute das sind die mit 00 statt 03/04?

Status 0x0050 finde ich in meinem Logfile im Zusammenhang mit dem "babbelnden" FensterSensor07 - das betreffende Logile (FensterSensor07-babble.log-anfang) findest du in dem betreffenden Threadbeitrag http://forum.fhem.de/index.php/topic,17759.msg117426.html#msg117426 . Darin sind:

196CA9 FensterSensor03
196A3F FensterSensor04
196980 FensterSensor07

Bei FS03 und FS04 kann ich mich erinnern, beim Schließen rot gesehen zu haben - ein späterer Versuch wurde dann mit grün quittiert und ich habs erstmal ad acta gelegt. Was mit dem FS07 geschah, lern ich ja vielleicht noch...

Grüße,
Andy.

der Status 0050 kommt alternativ zu 0040. Es scheint also 0040 & 0010 zu sein - diese sind ggf getrennt auszuwerten.
Die Messages 0050 und 0040 sind alle eine Art Info des HMLAN. Die Messages wurden schon mit dem Status 0100 verarbeitet.

HMLAN sender in dem Bit-bereich infos wie "messages wurde gesendet" oder "Antwort auf gesendete Messages empfangen/nicht Empfangen".

Deutungen können noch abgegeben werden :)

Hallo Martin,

ich habe ein AES Problem mit dem Tür/Fenster Sensor HM-SEC-SC. Obwol ich die AES-Keys in FHEM genau wie in der Bidcos-Datei der Windows-Software gesetzt habe, kann ich keine Befehle an den Sensor senden (z.B. Register abfrage). Das Sensor Attribut "aesKeyNbr" zeigt "FF" an, was mich überrascht. In meiner Windows Bidcos-Datei gibt es nur 5 Keys und keine 255 (falls ich FF als Hex-Zahl interpretiere). Hast Du einen Verdacht wo das Problem liegen könnte? Außerdem habe ich noch nicht verstanden, wie ich empfangene Pakete prüfen kann ob sie von einem Sender mit korrektem AES-Key stammen. Die Befehle lesen kann ich natürlich, aber woher weiss ich, dass sie wirklich von dem korrekten Sender stammen?

Vielen Dank für deine Arbeit an der HMLAN-Anbindung.
Viele Grüße

Fabian

Hallo Fabian,

hex ist richtig, ist alles hex hier. 255 kommt, wenn kein Key genutzt wird.

ZitatAußerdem habe ich noch nicht verstanden, wie ich empfangene Pakete prüfen kann ob sie von einem Sender mit korrektem AES-Key stammen.

kann ich auch nicht... Es läuft normal so, dass jemand (meist die Zentrale) einen request stellt. So AES eingeschaltet am empfänger antwortet er mit einer AES-anfrage die vom initiator korrekt beantwortet werden muss. Bekommt der Empfänger eine korrekte Antwort wird der ursprüngliche Request abgearbeitet und es kommt ein Bestätigung an den Sender.

ZitatDie Befehle lesen kann ich natürlich, aber woher weiss ich, dass sie wirklich von dem korrekten Sender stammen?

Du meinst, das jemand deinen Aktor gehäckt haben könnte und du eine AES-anfrage von der Zentrale starten willst? Habe ich nicht probiert...


Wenn bei key-nummer immer FF drin steht ist AES evtl garnicht aktiviert - kannst du einen mitschnitt schicken?

Gruss Martin

@Samsi: Du sagst, dass die Windowssoftware einfach den MD5 Hash des Passworts überträgt. Hast du mal geschaut was sie überträgt wenn man keinen Key angibt? Also kann man den Default AES Key so rausbekommen? Ein anderer Versuch wäre mal der md5 Hash von dem leeren String (also d41d8cd98f00b204e9800998ecf8427e). Hast du Lust das mal zu probieren?

Gruß,
Jan

Hallo Martin,

vielen Dank für deine schnelle Antwort.

Ich habe ein Teil des Problems mit dem HM-SEC-SC Sensor gelöst: Ich wusste nicht, dass ich nach einem Set getConfig kurz die Pair-Taste drücken muss um die Register abzufragen. Die AES Verschlüsselung scheint zu funktionieren (Gegentest mit gelöschtem Key funktionierte nicht.)

Allerdings liest FHEM den offen/geschlossen Zustand auch mit falschem AES schlüssel korrekt ein. Soweit ich verstanden habe ist ja auch bei AES "signing" ein mitlesen der gesendeten Nutzdaten immer möglich. Dies ist für mich auch grundsetzlich kein Sicherheitsproblem, solange ich sicherstellen kann, dass der gesendete Befehl nur von einem autorisierten Sender kommt. In folgendem Szenario könnte dies andernfalls ein Problem sein: Fernbedienung sendet an FHEM, FHEM öffnet per Key-Matic die Tür.

Keymatic prüft natürlich ob FHEM autorisiert ist, aber wie kann ich in FHEM prüfen ob die Fernbedienung authorisiert war? Fall ich das AES-Challenge-Response Verfahren richtig vertstanden habe, müsste ich dazu irgendeinen Wert in FHEM abfragen können der mir anzeigt ob die Challenge Reponse vom Sender ( hier die Fernbedienung) an FHEM korrekt war. Gibt es diese Möglichkeit oder falls nicht, kann man das implementieren?

Vielen Dank und viele Grüsse
Fabian

Hi Fabian,

man kann in der FB je peer eines Tasters einschalten "expextAES". Dann liegt es an FHEM einen AES-request zu senden, den die FB beantworten muss.
Du nutzt einen virtuellen Aktor...
dieser Code fehlt in FHEM - das ist korrekt. Ich denke, man könnte ihn einbauen...

Gruss Martin

@Martin:

das wäre nicht schlecht, dann könnte man auch seine Alarmanlage über einen Handsender schalten. Wenn ich es richtig verstehe bekommt man momentan das Notify des Handesenders auf jeden Fall und kann nicht erkennen ob es ein autorisierter Handsender war. Also das wäre nicht schlecht, nur ein Notify zu bekommen, wenn die AES Challenge Response korrekt war.

@Jan
Werde ich mal ausprobieren. Ich installiere mal die HMLAN Software auf einem anderen PC neu , schau was in den Keys Dateien steht und logge dann mal mit, was er bei der ersten Verbindung zum HMLAN macht.

Hallo,

ich bin relativ neu bei FHEM. Ich habe einen HMLAN  und verschiedene Rolladen-Aktoren, die ich über Webinterface mit fhem oder direkt über einen gepeerten Schalter  steuern möchte.
FHEM läuft auf einem RaspberryPi.

Ich möchte diese Aktionen über AES gesichert ausführen. Ich habe dazu einen eigenen AES Schlüssel erzeugt und ihn in hmkey eingetragen.
Bei den Aktoren habe ich das Register sign auf on gestellt. Der Wert  aesKeyNbr zeigt immer noch FF.

• Was muss ich noch tun?
• Was habe ich übersehen?
• Wie kann ich sonst noch prüfen, ob die Kommunikation über AES läuft?

Hallo,

ZitatIch habe dazu einen eigenen AES Schlüssel erzeugt und ihn in hmkey eingetragen.

Das geht nicht. Du musst das mit der Windows Konfigurationssoftware machen, nur diese überträgt dann auch den Schlüssel an die Geräte (bei den schaltern musst Du dafür evtl. die anlernen Taste Drücken, wenn sie batteriebetrieben sind, das sonst der Schlüssel nicht übertragen werden kann). Das eintragen in hmkey stellt nur sicher, das HMLAN auch ein entsprechend signierte Antwort geben kann. Aber dazu müsste der Schlüssel erst über die Windows Software an alle Geräte verteilt werden.
Testen kannst Du es dann, indem du HMLAN kurz stromlos machst (damit er den key vergisst) und dann mit FHEM versucht zu steuern, ohne erst ohne hmkey und dann mit hmkey. Ohne darf es nicht gehen und mit muss es dann gehen.

Da die keys ach einen Index besitzen, solltest Du dir die Datei Bidcos-Service/keys von der Windows Software ansehen. Da stehen alle keys mit index drin (falls du versehentlich schon mehrere hast)

Grüße

Das mit dem Schlüssel übertragen auf die Aktoren usw. ist die eine Sache nur wie kann ich die AES Kommunikation aktivieren in den Geräten.
In der Windows Software finde ich keine Möglichkeit das zu de- oder aktivieren.

Hallo,

schau die mal die REgsiter expextAES und sign an. Ich glaube mit sign schaltest du das beim Aktor an und mit expext AES sagst du dem Sender das der Aktor AES erwartet. Ganz sicher bin ich mir da aber jetzt auch nicht.
Grüße

Sollte so stimmen.
sign wird je kanal gesetzt - im Empfänger von Kommandos
expextAES wird im Sender gesetzt, wenn zu erwarten ist, dass der peer AES anfragen wird.

Gruss Martin

@Samsi

ZitatDu musst das mit der Windows Konfigurationssoftware machen

Das habe ich. Zu diesem Zeitpunkt war der betreffende Aktor aber noch gar nicht vorhanden.
Den Schlüssel habe Ich aus der Datei Bidcos-Service/keys von der Windows Software.

Die Frage ist dann auch, ob ich die Geräte an die Windows-Software anlernen muss.
Irgendwo im Wiki steht, dass das nicht empfehlenswert ist. Ist das jetzt Käse?

Wenn die Geräte angelernt werden müssen, dann hat natürlich kein Aktor den neuen Key.
Geht das Anlernen da auch mit Befehl von der Software aus? Wenn nicht, dann habe ich ein Problem.
Die Aktoren sind ja eingebaut und nicht ohne weiteres erreichbar ( In Verteilerdosen, Lampenbaldachinen ...).
Außerdem haben viele keinen Taster angeschlossen, weil keine schaltende Leitung hin geht (sonst bräuchte ich ja keinen Funk ;-) )

Der Key wird doch im HMLAN gespeichert. Eigentlich müsste doch der den Schlüssel verteilen?
Es ist schon mühsam, wenn ich immer erst ein Windows in einer virtuellen Maschine herauskramen muss, nur um irgendwelche Initialisierungen zu machen, wenn ein neuer Aktor dazukommt.
Ich arbeite normalerweise nur mit Linux. Ich wollte mir auch die Mühe sparen, mich in die Windowssoftware einzuarbeiten.

Bis zu den Schaltern (Sensoren) bin ich noch gar nicht gekommen

Ich habe bisher nur einen Key.

ZitatZu diesem Zeitpunkt war der betreffende Aktor aber noch gar nicht vorhanden....
Die Frage ist dann auch, ob ich die Geräte an die Windows-Software anlernen muss.

ja, muss angelernt sein

ZitatIrgendwo im Wiki steht, dass das nicht empfehlenswert ist. Ist das jetzt Käse?

setze die HMId für die Windows SW gleich der von FHEM. Dann musst du nicht noch einmal pairen

ZitatWenn nicht, dann habe ich ein Problem. Die Aktoren sind ja eingebaut und nicht ohne weiteres erreichbar (

versuche es über die Seriennummer zu machen.

Zitat
Der Key wird doch im HMLAN gespeichert. Eigentlich müsste doch der den Schlüssel verteilen?

HMLAN ist ein IO, keine Zentrale. Wenn die Zentrale (windows-SW) sagt "verteilen" dann wird er verteilt. FHEM hat dies nicht implementiert.

Gruss Martin

Danke für die klaren Antworten.

HMid für Windows  habe ich jetzt gleich gesetzt zu FHEM. Ich hatte eigentlich erwartet, dass so etwas in "Einstellungen" zu finden ist.
Statt dessen muss man googeln und dann Konfigurationsdateien ändern. 

Das mit der Seriennummer funktioniert mit Aktoren, nicht aber mit Batterie betriebenen Schaltern.
Vor allem nicht, wenn der Schalter im OG und der Rechner im Keller steht. Also ausbauen! (HM-SCl-3-FM)

Bei der Windowssoftware  ist es angenehm, dass die Beschreibungen direkt da stehen, wo man sie auch benötigt.
In FHEM muss ich immer ein Fenster mit der manchmal kärglichen Beschreibung offen haben und im andern Fenster FHEM bedienen.
Bei einem Touchpad ist das mühsam. Wie wäre es mit einem Tooltip mit der Beschreibung, wenn man auf ein Register zeigt?

Gibt es hier eine Wunschliste?
1. Platz : AES verteilen auch mit FHEM

Bei jedem neuen Gerät, das ich mit AES betreiben will (ich werde, denn ich möchte vermeiden, dass irgendein Spaßvogel mir das Licht ausschaltet!),
muss ich also die Windowssoftware auspacken.

ZitatGibt es hier eine Wunschliste?
1. Platz : AES verteilen auch mit FHEM

Hallo Zeitisen, dann programmiere da doch einfach, wenn es Dir so wichtig ist.

Gruß Joachim

Wenn das so einfach wäre, würde ich es doch glatt machen.
Aber mir fehlt zum einen noch das Know how. Nach zwei Wochen Homematic muss ich mich wohl noch als blutigen Anfänger bezeichnen.
Außerdem ist Perl nicht gerade meine Lieblingssprache.

Zum anderen fehlt mir die Zeit. Meine Freizeit verbringe ich gerade damit, Sensoren und Aktoren zu paramtrieren und zu verbauen.

ZitatZum anderen fehlt mir die Zeit. Meine Freizeit verbringe ich gerade damit, Sensoren und Aktoren zu paramtrieren und zu verbauen.

Dir ist schon klar, dass dieses Projekt von uns allen in der Freizeit betrieben wird.
Also freu Dich über dass was schon alles geht, und schraube Dein Anspruchdenken etwas herab.

ZitatHMid für Windows  habe ich jetzt gleich gesetzt zu FHEM. Ich hatte eigentlich erwartet, dass so etwas in "Einstellungen" zu finden ist.
Statt dessen muss man googeln und dann Konfigurationsdateien ändern. 

Wenn Dir Googeln und Das Ändern von Konfigurationsdateien zu anstrengend ist, dann bist Du hier falsch.
FHEM ist unheimlich mächtig, und sticht wahrscheinlich jedes zur Zeit vorhandene Programm aus, es ist allerdings nötig, sich eine nicht unerhebliche Menge an Wissen anzueignen. Wenn Du dazu bereit bist, dann bist Du hier richtig

Gruß Joachim

Autsch.
Wahrscheinlich habe ich das verdient.

Mein zweiter Name ist Ungeduld, und es geht nicht so voran, wie ich mir es vorgestellt habe.
Wenn ich das mit AES mal am Laufen habe, werde ich zumindest ein Wiki Howto dafür schreiben.

Das Ändern von Konfigurationsdateien ist mir nicht zu anstrengend. Ich hätte nur vom kommerziellen Hersteller der Konfigurationssoftware  etwas anderes  erwartet.

Ich bin noch dabei, die vielen kleinen Mosaiksteinchen zusammen zu setzen, um ein Verständis für das Ganze zu bekomnmen
Und dabei läuft mir irgendwie die Zeit davon.

Noch funktioniert das ganze bei mir nicht.

Ich habe jetzt die hmId von FHEM umgerechnet in Dezimal und dann in die Datei  ids vom Homematic Konfigurator eingetragen.( Kann man irgendwie verifizieren, ob das erfolgreich war?)

Dann habe ich alle verfügbaren Komponenten an Homematic Konfigurator angelernt.
Bei zwei Aktoren habe ich umgestellt auf "Gesichert". Dazu muss man die Baumstruktur öffnen und im Kanal in der Spalte "Übertragungsmodus" auf das weiße Feld klicken, wo normalerweise "Standard" steht.

Das Umstellen auf " Gesichert" geht geht ohne weiteres Nachfragen. Das Zurückstellen erfordert aber den Anlernmodus  durch Drücken der entsprechenden Taste und damit physikalischen Zugriff.

Nach dem die betreffenden Aktoren mit AES funktioniert haben, wollte ich das Ganze mit FHEM prüfen.
Also Homematic Konfigurator beenden, Netzwerkkabel vom Raspberry wieder rein.
Wegen der gleichen hmId sollte das jetzt funktionieren, auch ohne dass das Attribut hmkey gesetzt ist, weil der Key noch im HMLAN steht.
Ist das so korrekt?

Genau das funktioniert nicht. protEvt_AESerrReject wird hochgezählt und auf die Zeit des  letzten Versuchs gesetzt.

Nächster Versuch: Ich will den hmkey setzen. Dabei sollten nach Doku sowohl der Key selbst als  auch die Eingabe des Hashwertes möglich sein.
Ich versuche zunächst den Key selbst. Dabei kommt die Fehlermeldung: "illegal number: " . Das kann ja eigentlich nicht sein, den ein Key kann keine illegalen Zahlen haben ( abgesehen von den Problemen mit & in älteren CCU firmwares)
Den  Key habe ich ohne vorgestelltes 01: eingegeben. Die Schreibweise ist mir hier nicht ganz klar.

[edit]
Ich habe jetzt heraus gefunden, warum das nicht geht. Mein Key enthält einen ":" . Damit fällt die Abfrage, ob hash oder Key auf die Nase. Mit diesem Code ist ein ":" im Key überhaupt nicht erlaubt:
if ($aVal =~ m/:/){#number given
($no,$val) = split ":",$aVal;
return "illegal number:$no" if (hex($no) < 1 || hex($no) > 255 || length($no) != 2);
}
Anmerkung: Ich verstehe die Perl Syntax nur eingeschränkt. Klar ist mir hier nur, dass  der : als Aufteilungsmarke zwischen Nr und hash genutzt wird.
Abhilfe: als Unterscheidung "01: " definieren. Leerzeichen sind in einem Key nicht erlaubt. Damit ist eine Unterscheidung zuverlässig möglich.


Nach dem Fehlschlag mit dem Key selbst nächster Versuch mit dem Hashwert. und vorangestelltem 01: . Dabei sollte der Wert ja unverändert bleiben. Als Ergebnis kommt aber ein anderer Wert heraus.. Das bedeutet doch wohl, dass der Hash für einen Key gehalten und in einen Hash umgerechnet wurde. Ich meine aber mich dunkel zu errinnern, dass ich das ganz am Anfang schon einmal so gemacht habe und es funktionierte.
Hat sich etwas geändert?
Wie sind die erlaubten Eingabeformate definiert?

Habe ich etwas übersehen?
Mache ich etwas falsch?

Updates habe ich am 14.12014 und am 23.1.2014 gemacht.
Mein Softwarestand:
# $Id: fhem.pl 4709 2014-01-21 18:00:07Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 4718 2014-01-22 23:31:06Z martinp876 $
# $Id: 01_FHEMWEB.pm 4648 2014-01-14 19:23:34Z rudolfkoenig $
# $Id: 92_FileLog.pm 4664 2014-01-16 09:45:47Z rudolfkoenig $
# $Id: 00_HMLAN.pm 4718 2014-01-22 23:31:06Z martinp876 $
# $Id: 98_HMinfo.pm 4718 2014-01-22 23:31:06Z martinp876 $
# $Id: 99_SUNRISE_EL.pm 4537 2014-01-03 08:28:59Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 98_autocreate.pm 4648 2014-01-14 19:23:34Z rudolfkoenig $
# $Id: 91_eventTypes.pm 2982 2013-03-24 17:47:28Z rudolfkoenig $
# $Id: 91_notify.pm 4664 2014-01-16 09:45:47Z rudolfkoenig $
# $Id: 98_openweathermap.pm 4347 2013-12-08 16:49:02Z betateilchen $
# $Id: 33_readingsGroup.pm 4714 2014-01-22 16:29:16Z justme1968 $

Hallo,

ZitatIch habe jetzt die hmId von FHEM umgerechnet in Dezimal und dann in die Datei  ids vom Homematic Konfigurator eingetragen.( Kann man irgendwie verifizieren, ob das erfolgreich war?)

Schließe den HMLAN an FHEM an und versuche ob Du die Aktoren steuern kannst (wenn sie schon vorher FHEM bekannt waren) .

Bsp.:
Anlernen an FHEM mit 123456
Probieren ob der Aktor steuerbar ist
Wechsel zu winSoft
Anlernen an Winsoft mit 123456
Wechsle zu FHEM
Schauen ob der Aktor noch zu steuern ist -> Ja:OK nein:Nicht OK

Die Software macht beim Anlernen nichts anderes als die HMID des HMLANS in das Gerät zu programmieren. Hast Du unterschiedliche IDs in FHEM und WinSoft, würde die sich immer gegenseitig überschreiben.



"Das Umstellen auf " Gesichert" geht geht ohne weiteres Nachfragen. Das Zurückstellen erfordert aber den Anlernmodus  durch Drücken der entsprechenden Taste und damit physikalischen Zugriff."
Bei Batteriebetrieben musst auch beim einschalten anlernen drücken, sonst kann er nicht übertragen. Schau am besten rechts oben in der Windows Software, das steht ob noch Übertragungen anstehen.

ZitatWegen der gleichen hmId sollte das jetzt funktionieren, auch ohne dass das Attribut hmkey gesetzt ist, weil der Key noch im HMLAN steht.
Ist das so korrekt?

Richtig, der HMLAN behält die keys bis er stromlos gemacht wird. ICh würde Sie sicherheitshalber aber trotzdem gleich in FHEM angeben. Man weiß ja nie.

ZitatDen  Key habe ich ohne vorgestelltes 01: eingegeben. Die Schreibweise ist mir hier nicht ganz klar.

01: brauchst Du. Das ist der Index des keys und du musst alle Keys so angeben wie sie in der keys datei mit index stehen (falls du schon mehrmals den AES  key geändert hast).

also ungefähr so muss es dann in der fhem.cfg bzw. bei den Attributen im Webfrontend  stehen: hmkey 01:00aa00124432affddeecc

Grüße

Ich habe jetzt bei einem Rolladenaktor wieder auf "Standard" - Übertragung gestellt.

Nach dem Schalten mit winsoft habe ich umgesteckt auf FHEM: Die Bedienung funktioniert. Also ist die hmId gleich.
Wieso aber ist das Steuern des mit AES gesicherten Aktors nicht möglich, obwohl der HMLan durchläuft?

Dieses Mal funktionierte das Zurückstellen auf "Standard" ohne Anlernmodus. Kann es sein, dass der Empfangspegel zu schwach war?. An Ort und Stelle war RSSi auf -80. Das Bedienen funktionierte aber. Jetzt liegt das Teil wieder auf dem Schreibtisch.
Batteriebetriebene Geräte müssen quasi erst aufgeweckt werden. Ist mir klar.

Natürlich möchte ich die Keys eintragen. Aber in der bestehenden Software ist mein Key nicht eintragbar. Ich meine, auch den Hash aus dem File keys kopiert und eingefügt zu haben und die Darstellung hat sich nicht geändert. Wenn ich das jetzt mache, wird der Hash verändert also Hash vom Hash?
Wie soll den die Syntax nun lauten? 
xx:yyyyyyyyyyyyyyyyyyyyyyyyyy
mit xx = [01 .. 99] und yy..yyy ein Hashwert

Stehen in der keys Datei jetzt Hashwerte oder Keys? Ich denke doch Hashwerte.
Dann dürfte sich bei der obengenannten Schreibweise der Wert selbst nach der Eingabe nicht mehr ändern. Softwarefehler? Leider kann ich den Pearl code auf die Schnelle nicht entziffern.

Das Problem mit der Eingabe des Hash hat sich geklärt:

Beim Kopieren wurden irgendwo die letzten vier Stellen abgeschnitten.
Nach dem der Hashwert jetzt vollständig eingegeben wurde, bleibt er auch unverändert erhalten.
Damit war sofort ein Schalten des bei Betrieb mit winsoft verschlüsselten Aktors möglich.

Jetzt bleibt also noch die Frage, wieso das Steuern des mit AES gesicherten Aktors nicht möglich war , obwohl der HMLan durchlief.
Offensichtlich wird der AES-Wert doch öfter zum HMlan geschrieben.

Vielen Dank noch einmal an alle, die sich die Mühe gemacht haben, mir weiter zu helfen.

ZitatJetzt bleibt also noch die Frage, wieso das Steuern des mit AES gesicherten Aktors nicht möglich war , obwohl der HMLan durchlief.
Offensichtlich wird der AES-Wert doch öfter zum HMlan geschrieben.

Also wenn falsche keys in FHEM hinterlegt waren, werden diese natürlich in den HMLAN beim anschließen geschrieben. Nur wenn Du in FHEM keine keys eingetragen hast, bleiben die durch die winsoft geschreibenen keys im HMLAN bis zum Stromausfall bestehen.