Arduino Asksin library

[Dirk]

AES werde ich stand heute nicht implementieren koennen. Ich weiss derzeit nicht wie verschluesselt wird und was unverschluesselt im string steht.

Das ist klar. So war das auch nicht gemeint.
Aber vielleicht könnte der Aktor "so tun" als ob er den neuen Schlüssel angenommen hat. Quasi nur einen ACK dafür schickt.
Beim anschliessenden Initialen Konfigurationsaustauch sollte der Aktor dann auf allen entsprechenden Kanälen ein Ausgeschaltetes AES signalisieren. Auch sollten sich die entsprechenden Register nicht aktivieren lassen.

Aber vermutlich läuft es auf ein eigenes XML-File heraus, sofern man das Device per HMM-Lan-SW konfigurieren möchte.

Beim druecken vom config taster wird der pairing string gesendet. Fhem muss dann darauf antworten. Passiert das bei dir?

Das hier wird hesendet:

Code Auswählen Erweitern

<- 1A 29 A2 00 5F B7 4A 1A CA E5 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)<0>(300556)
-> 0A 29 80 02 1A CA E5 5F B7 4A 00 (l:11)<0>(300693)


Ich habe den Test noch mal mit der HM-LAN-SW ohne eigenen Schlüssel wiederholt.
So wird der "Taster"  erkannt, aber ist noch nicht nutzbar weil:

Code Auswählen Erweitern

Konfigurationsdaten stehen zur Übertragung an

Also auch hier erfolgt kein Konfigurationsaustausch.
Das EEprom vom Arduino ist auch noch recht leer. Lediglich die HM-LAN-ID ist eingetragen.

Um irgendwas zu fixen brauch ich zumindest einen anhaltspunkt wo es hakt. Bei mir funzt das pairing,  das peeren und das register lesen,  insofern kann ich auch nicht fixen...

Ja, der Fluch des Entwicklers
Was für Infos kann ich dir noch schicken?

Ich nutze die letzte version der um config soft.

Ich denke die habe ich auch. Grade noch mal runtergeladen und nackig in eine VM eingespielt.

Zum anlernen geh ich in der config soft auf anlernen,  dann geht ein dialog auf und das ding zaehlt von 60 sekunden runter. Dann drueck ich die config taste und im log wird der pairing string gesendet,  daraufhin kommen einige Ack und config strings und im dialog fenster steht das ein neues geraet gefunden wurde...  thats it

Gleiche Vorgehensweise hier.

Aber dann können die "Konfigurationsdaten nicht übertragen werden. Anbei mal ein Log.

Code Auswählen Erweitern

<- 1A 34 A2 00 5F B7 4A 1A CA E5 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)<0>(420507)
<0>-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(420739)
<0>-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(420937)
<0>-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(421136)
<0><- 0A 01 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421206)
<0>-> 13 02 A0 01 1A CA E5 5F B7 4A 00 08 02 01 0A 1A 0B CA 0C E5 (l:20)<0>(421500)
<0><- 0A 02 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421515)
<0>-> 0B 03 A0 01 1A CA E5 5F B7 4A 00 06 (l:12)<0>(421804)
<0>config changed
<- 0A 03 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421810)
<0>-> 10 04 A0 01 1A CA E5 5F B7 4A 00 04 00 00 00 00 00 (l:17)<0>(422105)
<0><- 18 04 A0 10 5F B7 4A 1A CA E5 02 01 00 02 01 0A 1A 0B CA 0C E5 18 00 00 00 (l:25)<0>(422117)
<0>-> 11 04 A0 02 1A CA E5 5F B7 4A 04 BF 29 8F C1 A0 9D 00 (l:18)<0>(422258)
<0>-> 10 0D A0 01 1A CA E5 5F B7 4A 01 04 00 00 00 00 01 (l:17)<0>(422703)
<0><- 12 0D A0 10 5F B7 4A 1A CA E5 02 04 00 08 00 09 00 00 00 (l:19)<0>(422809)
<0>-> 11 0D A0 02 1A CA E5 5F B7 4A 04 76 E0 46 08 69 54 00 (l:18)<0>(422961)
<0>l> 0B 1E A2 58 18 6F 30 18 60 F1 00 00 (l:12)<0>(435093)
<0>l> 0E 1E 82 02 18 60 F1 18 6F 30 01 01 00 00 25 (l:15)<0>(435226)
<0>


Gruß
Dirk

[trilu]

Das mit dem AES ist leider nicht so einfach. Der Master schickt einen AES String und erwartet natürlich einen AES String zurück, dieser wird auch geprüft.
Also irgendwas funktioniert nicht und blöderweise sieht der Antwortstring jedes mal anders aus, also einfach merken geht auch nicht...

Das ist eine perfekte Kommunikation - der ausgehende String ist ein Pairing String,
der zurückkommende ist ein ACK, also alles OK

Code Auswählen Erweitern

<- 1A 29 A2 00 5F B7 4A 1A CA E5 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)<0>(300556)
-> 0A 29 80 02 1A CA E5 5F B7 4A 00 (l:11)<0>(300693)


Code Auswählen Erweitern

<- 1A 34 A2 00 5F B7 4A 1A CA E5 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)<0>(420507) - pairing string
-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(420739) - einleiten der config für kanal 0
-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(420937)
-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(421136)
<- 0A 01 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421206) - ACK für das einleiten der config von deinem device
-> 13 02 A0 01 1A CA E5 5F B7 4A 00 08 02 01 0A 1A 0B CA 0C E5 (l:20)<0>(421500) - schreiben der pair id in list0
<- 0A 02 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421515) - ACK von deinem device
-> 0B 03 A0 01 1A CA E5 5F B7 4A 00 06 (l:12)<0>(421804) - message zum beenden der config
    config changed - event aus dem main sketch
<- 0A 03 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421810) - ACK von deinem device
-> 10 04 A0 01 1A CA E5 5F B7 4A 00 04 00 00 00 00 00 (l:17)<0>(422105) - config param request für channel 0
<- 18 04 A0 10 5F B7 4A 1A CA E5 02 01 00 02 01 0A 1A 0B CA 0C E5 18 00 00 00 (l:25)<0>(422117) - config antwort für channel 0 von deinem device
-> 11 04 A0 02 1A CA E5 5F B7 4A 04 BF 29 8F C1 A0 9D 00 (l:18)<0>(422258) - ACK-proc von der zentrale
-> 10 0D A0 01 1A CA E5 5F B7 4A 01 04 00 00 00 00 01 (l:17)<0>(422703) - anfrage nach list1 channel 1
<- 12 0D A0 10 5F B7 4A 1A CA E5 02 04 00 08 00 09 00 00 00 (l:19)<0>(422809) - antwort von deinem device, es gibt nur register 08 und 09, beide sind leer
-> 11 0D A0 02 1A CA E5 5F B7 4A 04 76 E0 46 08 69 54 00 (l:18)<0>(422961) - ACK-proc von der zentrale

l> 0B 1E A2 58 18 6F 30 18 60 F1 00 00 (l:12)<0>(435093)                gehört zu einem anderen gerät, da l> am anfang
l> 0E 1E 82 02 18 60 F1 18 6F 30 01 01 00 00 25 (l:15)<0>(435226)


Was sagt uns jetzt das Log? Du hast am Anfang ein Problem mit der Kommunikation, das Einleiten der config wurde 3 mal gesendet und erst dann beantwortet. Störung im Funk, zu nah an der Zentrale, hier ist vieles denkbar...

Zweites Problem, die config Soft will immer noch AES, ich vermute du hast nicht für alle Channel das AES ausgeschaltet.

[Dirk]

Das mit dem AES ist leider nicht so einfach.

Das war nur eine Idee wie man hier ggf. ansetzen könnte. Das das nicht so einfach geht, ist mir klar.
Eigentlich will ich nur verhindern dass hier überhaupt ein Schlüsseltausch vorgenommen wird.

Zweites Problem, die config Soft will immer noch AES, ich vermute du hast nicht für alle Channel das AES ausgeschaltet.

Tja, und hier versucht sich die Katze in den Schwanz zu beißen.
Also, leere Config der HM-LAN-SW, Also keine weiteren Geräte sind angelernt und kein eigener Schlüssel gesetzt.
EEprom vom Arduino wurde geleert.
AES kann vom Device erst abgeschaltet werden wenn die Initiale kommunikation geklappt hat.
Also wie muss man nun vorgenen?

[Dirk]

Vergessen:

Das ist eine perfekte Kommunikation - der ausgehende String ist ein Pairing String,
der zurückkommende ist ein ACK, also alles OK

Dann sollte anschließend doch Register usw. in Richtung FHEM übertragen werden oder?
Jedenfalls sollte nach "CMDs_processing..." doch noch was kommen?
Ausser "CMDs_done_Errors:1" Passiert hier nix weiter.

[trilu]

nun, dann hast du den rest der kommunikation vergessen zu posten
wenn das device in fhem bekannt ist, kommt manchmal nur ein ACK auf den pairing string.

wenn noch ausstehende befehle da sind, sollten die nach einem pairing kommen. du kannst ja mal get config in fhem drücken und schauen was im log passiert.

mit AES ausschalten meine ich das hier:
wo bei mir standard steht, steht bei dir garantiert noch gesichert. drück mal auf das weisse standard, dann kommt das fenster wie in bild2, hier wechselst du von gesichert auf standard. das musst du bei allen 6 kanälen wiederholen...

[Dirk]

wenn das device in fhem bekannt ist, kommt manchmal nur ein ACK auf den pairing string.

Das Pairing in FHEM klappt scheinbar.
Aber jede weiter Kommunikation klappt wohl nicht.
Was passiert bei dir denn nach einem getConfig?
Kannst du Register vom Device auslesen?
Irgendwo fehlt hier noch was bei mir.

mit AES ausschalten meine ich das hier:

Das ist mir schon klar.
Aber dieser Schritt kann erst nach dem erfolgreichem Pairing funktionieren.
Nachdem das Device in der SW gefunden wurde, gibt es aber noch "Konfigurationsdaten die zur Übertragung anstehen". Und diese werden auch bei erneutem Drücken der Configtaste nicht übertragen.
Daher findet keine weitere Kommunikation mehr statt.
Alle weiteren Einstellungsversuche incl. der Versuch AES am Kanal abzuschalten wird mit
"Die Übertragung der Daten zum Gerät konnte nicht ordnungsgemäß durchgeführt werden. ..." quitiert.

[trilu]

jetzt weiss ich was du meinst, geht bei mir auch nicht - weder mit original remote oder meinem nachbau.
vermutlich hat martin was an der fhem anbindung gebastelt ))))

mit der config soft von hm funzt das ding wie gewohnt....

[Dirk]

Ich habe im XML-File aes_default mal auf false gesetzt.
Damit klappt das dann auch mit der HM-LAN-SW.

Konfigurieren usw. Funktioniert also so.
Aber mit ungepatchtem XML-File nicht.

mit der config soft von hm funzt das ding wie gewohnt....

Jetzt ist die Frage was machst du anders als ich.
Oder hast du die Register für AES im EEPROM vorher deaktiviert?

Versuch doch mal das Anlernen an der HM-LAN-SW mit vorherigem Clearen des EEPROM.
Klappt das bei dir dann?

[Dirk]

Nachtrag:

Peeren mit einem HM_LC_SW1_BA_PCB klappt so übrigens auch einwandfrei.
Incl. Burst.

Super Arbeit. Jetzt müssen wir nur noch Rausfinden warum das bei mir mit dem Original-XML nicht klappt.

[trilu]

Die register für AES sind per default deaktiviert. Die hm soft geht aber von AES per default aus. Meine versuche das AES im xml auszuschalten sind gescheitert. Hat die config soft ignoriert.
Ich habe jetzt mal Fhem auf den neuesten Stand gebracht, das eeprom gelöscht und wollte neu anlernen, was soll ich sagen, jetzt hab ich das gleiche problem 

Ich vermute, Martin hat was an den Hm modulen gedreht...

Pairing funktioniert. In der fhem.cfg wird das device auch noch angelegt, aber getconfig bleibt hängen. Das passiert aber nicht nur mit meinem device sondern auch mit dem original wm55.

In der hm config soft kann ich das device ganz normal anlernen. Reset des eeproms. Kontrolle mit e, alles 00. Dann in der config soft auf neues gerät anlernen - am device die konfig taste drücken und jede menge log einträge...

Danach dann gesichert auf standard in allen kanälen ändern und dann kann ich wie gewohnt peeren...

Wegen der fhem module habe ich martin mal angeschrieben...

Ganz vergessen zu erwähmen, ich nutze den hm usb cfg stick

[Dirk]

Meine versuche das AES im xml auszuschalten sind gescheitert.

Das zugehörige File währ: rf_rc-4-2.xml
Dieser Eintrag muss auf false gestezt werden:
/device/channels/channel[index:1]/aes_default
Ohne false ist nix mit anlernen

am device die konfig taste drücken und jede menge log einträge...

Hm, mir verweigert es dann jede weitere Kommunikation eben mit dem hinweis dass vorher noch Daten zu übertragen währen. Was auch nachvollziehbar währ, da AES per default ja aktiv ist und da keine Kommunikation erfolgreich sein sollte.

Ganz vergessen zu erwähmen, ich nutze den hm usb cfg stick

Ich hab einen HM-Lan hier. Vielleicht gibt es da auch bei diesem oder dem USB-Stick einen Bug wodurch sich der Unterschie erklären lies.

[trilu]

Starte mal den Hm lan und die config soft neu,  dann sollten die ausstehenden aktionen weg sein.

[Dirk]

Nein, die sind erst weg wenn sie zum Gerät übertragen worden. So ist es auch bei anderen Geräten, oder nachdem man das Gerät gelöscht hat.

Ich habe den "Taster" jetzt übrigens mal mit einem Dimmer gepeert. Die langen Tastendrucke sind scheinbar noch nicht ganz korrekt. Das schaue ich mir aber noch mal näher an.

[Dirk]

Ich habe den "Taster" jetzt übrigens mal mit einem Dimmer gepeert. Die langen Tastendrucke sind scheinbar noch nicht ganz korrekt. Das schaue ich mir aber noch mal näher an.

Da ist noch ein Bug in HM::sendPeerREMOTE
Der Eventcounter darf sich nur bei jedem kurzen Tastendruck erhöhen.
Beim langen Tastendruck wird der Eventcounter bei jeder Übertragung unverändert gesendet. Erst nach dem loslassen muss der Eventcounter eins hochgezählt werden. Ansonsten funktioniert das Toggledim nicht, und die Lampe "blinkt" beim langen Tastendruck.

Gruß
Dirk

[trilu]

Das sollte kein problem sein zu ändern.
Wie ist die logic des counters?

Short zaehlt immer 1 hoch.
Long zaehlt beim key release eins hoch?