AES (mit CUL) einrichten

[mgernoth]

Ja, das ist ein HM-CC-RT-DN
Channel 2 um genau zu sein

Ich hab das Device und alle Channels auf R-sign on und aesCommReq 1 stehen...

Ich nehme an, dass Du nicht burst benutzt, sondern das normale wakeup? Dann zerschiesse ich mit der Signaturanforderung höchstwahrscheinlich die Messagequeue...
Mal sehen, wie ich das fixen kann.

Gruß
  Michael

[mgernoth]

Hi,

anscheinend ist es keine gute Idee, eine Signatur fuer eine Nachricht ohne ACK-request anzufordern. Im Anhang ein neuer aesCommReq-Patch der das fixen sollte.

Gruss
  Michael

[Virsacer]

Ja, läuft wieder

Danke!

[Virsacer]

Ja, läuft wieder

Hm, irgendwie bleibt er doch noch manchmal hängen

Ein "burstXmit" bewirkt nur, dass er genau das "burstXmit" abarbeit und dann wieder bei "3 CMDs pending" bleibt...

Und die 3 sind genau die 3 set's, die seit dem Letzten, das ausgeführt wurde, noch hätten ausgeführt werden sollen...

[mgernoth]

Hm, irgendwie bleibt er doch noch manchmal hängen

Ein "burstXmit" bewirkt nur, dass er genau das "burstXmit" abarbeit und dann wieder bei "3 CMDs pending" bleibt...

Und die 3 sind genau die 3 set's, die seit dem Letzten, das ausgeführt wurde, noch hätten ausgeführt werden sollen...

Hmm...
Wenn Martin im anderen Thread sein OK gibt, baue ich diesen Patch komplett um, dann sollte (hoffentlich) auch gleich das Problem mit geloest sein. Sieht so aus, als ob ich bisher doch die Queue zerschiesse oder zumindest der Trigger zum abarbeiten fehlt.

Gruss
  Michael

[martinp876]

rund ist das noch nicht.
Zumindest repeater werden nicht korrekt eingearbeitet.
Das prinzip ist ok.
Ich stelle es einmal online.

[mgernoth]

Hallo Martin,

rund ist das noch nicht.

Ja...
Und jetzt habe ich alles umgebaut, Sorry

Der angehaengte Patch verarbeitet jetzt Nachrichten, fuer die eine Signatur angefordert wird nur, wenn die Signatur korrekt war. Jetzt ist das ganze einfacher (kein ACK-cache, ...).

Da ich dieses Verhalten im anderen Thread schon fuer HMLAN implementiert hatte und ich Teile des Patches gebraucht habe, enthaelt dieser Patch jetzt die Funktionalitaet fuer CUL und HMLAN.

@Martin: Wenn Du ganz viel Zeit hast

Viele Gruesse
  Michael

[Virsacer]

Ich habe jetzt (mit der SVN-Version) das Problem, dass manchmal ein Event getriggert wird, aber anscheinend noch der alte Wert in den Readings ist:

Also ich mach das Fenster zu, aber es wird "DOELSEIF ([Window] eq "open")" ausgeführt

[mgernoth]

Ich habe jetzt (mit der SVN-Version) das Problem, dass manchmal ein Event getriggert wird, aber anscheinend noch der alte Wert in den Readings ist:

Also ich mach das Fenster zu, aber es wird "DOELSEIF ([Window] eq "open")" ausgeführt

Hmm, Du musst auf die Zustandsänderung reagieren. Wenn ich DOIF richtig verstehe, wird das ausgeführt, sobald irgendein Event vom Gerät kommt und es den Zustand "open" hat. Wahrscheinlich ist das bei Dir jetzt das Event "aesCommToDev:pending". -> Doku zu DOIF lesen, da muss irgendwo ein ? rein, wahrscheinlich ([Window:?open]).

Gruß
  Michael

[Virsacer]

Ok, ja das wars - danke

Kann man event-on-update-reading auch negieren? Also irgendwie so in der Art: (?!aesCommToDev)

[mgernoth]

Hallo,

aesCommToDev landet bei der Version im SVN manchmal im Channel eines Geraets, statt im Geraet selbst. Angehaengt ist noch ein kleiner Patch, der das behebt.
Ich hatte Martin schonmal eine Version des Patches geschickt, die angehaengte gefaellt mir aber besser.

Viele Gruesse
  Michael

[Ralli]

Wobei das witzigerweise bei mir dazu geführt hat, dass die AES-Signatur-Abfrage von Tastern nun tatsächlich zuverlässig funktioniert (HM-USB bzw. HM-LAN).

[mgernoth]

Hallo,

Wobei das witzigerweise bei mir dazu geführt hat, dass die AES-Signatur-Abfrage von Tastern nun tatsächlich zuverlässig funktioniert (HM-USB bzw. HM-LAN).

Das sollte von diesem letzten Patch unbeeinflusst sein. Die AES-Signatur selbst ist aber an keinen Channel gebunden, deshalb sollte das aesCommToDev auch nicht in einem Channel landen. Das ist alles, was dieser Patch behebt. Die großen AES-Änderungen bleiben davon unberührt und die Signaturanfragen sollten weiterhin funktionieren (nicht signierte Daten werden nicht mehr verarbeitet).

EDIT: Der Patch betrifft eh nur den CUL, beim HMLAN war es schon korrekt.

Viele Grüße
  Michael

[Virsacer]

Ich habe gerade mal bei einem HM-CC-RT-DN ein "clear all" & "getConfig" gemacht:
Irgendwo bleibt er da wieder mit einem "aesCommToDev pending" hängen :/

2. Edit: 1. Edit hat sich erledigt

[mgernoth]

Hallo,

Ich habe gerade mal bei einem HM-CC-RT-DN ein "clear all" & "getConfig" gemacht:
Irgendwo bleibt er da wieder mit einem "aesCommToDev pending" hängen :/

Kannst Du mal bitte Nachrichten mitloggen? Ich komme wahrscheinlich bis naechste Woche nicht dazu, das selbst auszuprobieren...

Viele Grüße
  Michael