Hi,
ich bin jetzt mal dazu gekommen, AES mit dem CUL zu testen.
Musste erstmal noch ne VCCU anlegen, hab dann einen "hmKey" definiert und mit "assignHmKey" auf die Geräte verteilt, sowie die "sign" Register auf on gesetzt.
Scheint alles zu funktionieren - zumindest hab ich in den Readings dann sowas stehen:
aesCommToDev ok 2015-07-07 15:54:32
aesKeyNbr 02 2015-07-07 15:54:32
Das ist ja aber jetzt anscheinend nur vom CUL zu den Geräten - wie sieht es mit der anderen Richtung aus?
Also wenn ich in den Geräten das "aesCommReq" Attribut setze, kann ich dann auch irgendwo erkennen, ob das funktioniert?
Hi,
Zitat von: Virsacer am 07 Juli 2015, 16:22:25
Scheint alles zu funktionieren - zumindest hab ich in den Readings dann sowas stehen:
aesCommToDev ok 2015-07-07 15:54:32
aesKeyNbr 02 2015-07-07 15:54:32
Gut :-)
Zitat
Das ist ja aber jetzt anscheinend nur vom CUL zu den Geräten - wie sieht es mit der anderen Richtung aus?
Also wenn ich in den Geräten das "aesCommReq" Attribut setze, kann ich dann auch irgendwo erkennen, ob das funktioniert?
Ist noch nicht implementiert, mittlerweile ist mir allerdings wenigstens einigermassen klar, wie ich das machen werde. Ist aber eine groessere Aktion, kann also noch etwas dauern.
Gruss
Michael
Achso, danke für die Info :)
Dann bin ich mal gespannt :D
Hallo,
ich habs mal ganz uebel zusammengehackt. Kannst Du den angehaengten Patch bitte mal testen, ob der bei Dir funktioniert?
Danke & Gruss
Michael
Hi,
es hilft, wenn man es auch an einem Geraet mit mehreren Kanaelen testet...
Neuer Patch, jetzt einfacher und auch mehrkanaltauglich.
Gruss
Michael
Oh, danke, das ist ja nett von dir :)
Da muss ich mal schauen, dass ich das auch möglichst bald schaffe mal zu testen...
Hallo,
gab noch ein paar Fixes, jetzt wird AES bei deutlich oefter angefordert und das ACK richtig gesendet.
Gruss
Michael
Also "aesCommToDev" wird auch hier aktualisiert :D
Und an der LED vom HM-SEC-RHS kann ich sehen, dass das Senden jetzt länger dauert :)
Allerdings werden meine DOIFs jetzt doppelt ausgeführt!? :o
Das DOIF-Problem hab ich mit "cmdpause" gelöst - das "aesCommToDev" hat da wohl zu mehrfachen Events geführt...
Aber ich hab noch gemerkt, dass zumindest bei meinem HM-LC-Sw1PBU-FM das getConfig nicht richtig funktioniert :-\
Zitat von: Virsacer am 09 Juli 2015, 23:14:33
Aber ich hab noch gemerkt, dass zumindest bei meinem HM-LC-Sw1PBU-FM das getConfig nicht richtig funktioniert :-\
Wahrscheinlich fordere ich für zu viele Nachrichten eine Bestätigung an. Muss ich mal mit einem offiziellen Interface vergleichen.
Gruß
Michael
Zitat von: mgernoth am 10 Juli 2015, 13:54:26
Wahrscheinlich fordere ich für zu viele Nachrichten eine Bestätigung an. Muss ich mal mit einem offiziellen Interface vergleichen.
Sollte (zumindest fuer den Aktor fuer Markenschalter) jetzt gefixed sein.
Gruss
Michael
Danke, aber nein, die Register werden noch nicht richtig ausgelesen...
Hallo,
Und jetzt?
Habe es jetzt mal mit einem Schalter probiert, der meiner Produktivumgebung nicht bekannt ist...
Gruss
Michael
Leider nein, aber vielleicht hilft das weiter:
Internals:
CUL_MSGCNT 108
CUL_RAWMSG A0A23800229F480EC712A80::-62:CUL
CUL_RSSI -62
CUL_TIME 2015-07-12 10:11:57
DEF 29F480
IODev CUL
LASTInputDev CUL
MSGCNT 108
NAME Light
NR 45
NTFY_ORDER 50-Light
STATE Nack
TYPE CUL_HM
lastMsg No:23 - t:02 s:29F480 d:EC712A 80
peerList self01,self02,
protCmdDel 5
protLastRcv 2015-07-12 10:11:57
protNack 3 last_at:2015-07-12 10:11:57
protResnd 3 last_at:2015-07-12 10:11:56
protSnd 88 last_at:2015-07-12 10:11:55
protState CMDs_done_Errors:1
rssi_at_CUL min:-62.5 avg:-61.83 max:-61 cnt:56 lst:-62
CHANGETIME:
Readings:
2015-07-12 10:11:57 CommandAccepted no
2015-06-10 12:22:19 D-firmware 2.3
2015-06-10 12:22:19 D-serialNr LEQ0234650
2015-07-12 10:11:01 PairedTo 0xEC712A
2015-06-10 12:26:17 R-intKeyVisib visib
2015-06-10 12:26:17 R-pairCentral 0xEC712A
2015-07-12 10:11:22 R-self01-lgActionType set_jmpToTarget
2015-07-12 10:11:22 R-self01-lgCtDlyOff set_geLo
2015-07-12 10:11:22 R-self01-lgCtDlyOn set_geLo
2015-07-12 10:11:22 R-self01-lgCtOff set_geLo
2015-07-12 10:11:22 R-self01-lgCtOn set_geLo
2015-07-12 10:11:22 R-self01-lgCtValHi set_100
2015-07-12 10:11:22 R-self01-lgCtValLo set_50
2015-07-12 10:11:22 R-self01-lgMultiExec set_on
2015-07-12 10:11:22 R-self01-lgOffDly set_0 s
2015-07-12 10:11:22 R-self01-lgOffTime set_unused
2015-07-12 10:11:22 R-self01-lgOffTimeMode set_absolut
2015-07-12 10:11:22 R-self01-lgOnDly set_0 s
2015-07-12 10:11:22 R-self01-lgOnTime set_unused
2015-07-12 10:11:22 R-self01-lgOnTimeMode set_absolut
2015-07-12 10:11:22 R-self01-lgSwJtDlyOff set_off
2015-07-12 10:11:22 R-self01-lgSwJtDlyOn set_off
2015-07-12 10:11:22 R-self01-lgSwJtOff set_off
2015-07-12 10:11:22 R-self01-lgSwJtOn set_dlyOff
2015-06-10 12:26:19 R-self01-shActionType jmpToTarget
2015-06-10 12:26:19 R-self01-shCtDlyOff geLo
2015-06-10 12:26:19 R-self01-shCtDlyOn geLo
2015-06-10 12:26:19 R-self01-shCtOff geLo
2015-06-10 12:26:19 R-self01-shCtOn geLo
2015-06-10 12:26:19 R-self01-shCtValHi 100
2015-06-10 12:26:19 R-self01-shCtValLo 50
2015-07-09 23:06:48 R-self01-shOffDly 8 s
2015-06-10 12:26:19 R-self01-shOffTime unused
2015-06-10 12:26:19 R-self01-shOffTimeMode absolut
2015-07-12 10:11:22 R-self01-shOnDly set_6 s
2015-06-10 12:26:19 R-self01-shOnTime unused
2015-06-10 12:26:19 R-self01-shOnTimeMode absolut
2015-06-10 12:26:19 R-self01-shSwJtDlyOff dlyOff
2015-06-10 12:26:19 R-self01-shSwJtDlyOn dlyOn
2015-06-10 12:26:19 R-self01-shSwJtOff dlyOff
2015-06-10 12:26:19 R-self01-shSwJtOn dlyOn
2015-06-10 12:26:19 R-self02-lgActionType jmpToTarget
2015-06-10 12:26:19 R-self02-lgCtDlyOff geLo
2015-06-10 12:26:19 R-self02-lgCtDlyOn geLo
2015-06-10 12:26:19 R-self02-lgCtOff geLo
2015-06-10 12:26:19 R-self02-lgCtOn geLo
2015-06-10 12:26:19 R-self02-lgCtValHi 100
2015-06-10 12:26:19 R-self02-lgCtValLo 50
2015-06-10 12:26:19 R-self02-lgMultiExec on
2015-06-10 12:26:19 R-self02-lgOffDly 0 s
2015-06-10 12:26:19 R-self02-lgOffTime unused
2015-06-10 12:26:19 R-self02-lgOffTimeMode absolut
2015-06-10 12:26:19 R-self02-lgOnDly 0 s
2015-06-10 12:26:19 R-self02-lgOnTime unused
2015-06-10 12:26:19 R-self02-lgOnTimeMode absolut
2015-06-10 12:26:19 R-self02-lgSwJtDlyOff on
2015-06-10 12:26:19 R-self02-lgSwJtDlyOn on
2015-06-10 12:26:19 R-self02-lgSwJtOff dlyOn
2015-06-10 12:26:19 R-self02-lgSwJtOn on
2015-06-10 12:26:19 R-self02-shActionType jmpToTarget
2015-06-10 12:26:19 R-self02-shCtDlyOff geLo
2015-06-10 12:26:19 R-self02-shCtDlyOn geLo
2015-06-10 12:26:19 R-self02-shCtOff geLo
2015-06-10 12:26:19 R-self02-shCtOn geLo
2015-06-10 12:26:19 R-self02-shCtValHi 100
2015-06-10 12:26:19 R-self02-shCtValLo 50
2015-06-10 12:26:19 R-self02-shOffDly 0 s
2015-06-10 12:26:19 R-self02-shOffTime unused
2015-06-10 12:26:19 R-self02-shOffTimeMode absolut
2015-06-10 12:26:19 R-self02-shOnDly 0 s
2015-06-10 12:26:19 R-self02-shOnTime unused
2015-06-10 12:26:19 R-self02-shOnTimeMode absolut
2015-06-10 12:26:19 R-self02-shSwJtDlyOff on
2015-06-10 12:26:19 R-self02-shSwJtDlyOn on
2015-06-10 12:26:19 R-self02-shSwJtOff on
2015-06-10 12:26:19 R-self02-shSwJtOn off
2015-07-05 18:46:22 R-sign on
2015-07-12 10:11:53 RegL_00: 02:81 0A:EC 0B:71 0C:2A 15:FF 18:00
2015-07-12 10:11:54 RegL_01: 08:01
2015-07-12 10:11:55 aesCommToDev ok
2015-07-12 10:11:24 aesKeyNbr 02
2015-07-12 10:11:54 aesReqTo VCCU
2015-07-10 23:05:54 deviceMsg off (to VCCU)
2015-07-10 23:05:54 level 0
2015-07-10 23:05:54 pct 0
2015-07-12 10:11:37 peerList self01,self02,
2015-07-10 23:05:54 recentStateType info
2015-07-12 10:11:57 state Nack
2015-07-10 23:05:54 timedOn off
Helper:
AESchallenge 1a9aeb359547
AESmsg A0E23A01029F480EC712A0230065724
AESrr 0
HM_CMDNR 35
cSnd 01EC712A29F48000040000000000,01EC712A29F48001040000000001
getCfgList all
getCfgListNo ,3
mId 0069
peerIDsRaw ,29F48001,29F48002,00000000
rxType 1
AESacksPend:
HASH(0x1bdc428)
238002EC712A29F48000
Io:
newChn +29F480,01,01,02
nextSend 1436688717.28459
rxt 0
vccu VCCU
p:
29F480
01
01
02
Mrssi:
mNo 23
Io:
CUL -60
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat 00
Role:
chn 1
dev 1
prs 1
Rssi:
At_cul:
avg -61.8303571428572
cnt 56
lst -62
max -61
min -62.5
Shadowreg:
RegL_03:self01 02:00 03:00 04:32 05:64 06:26 07:FF 08:28 09:FF 0A:01 0B:41 0C:41 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:64 8C:66 00:00
Role:
Rspwait:
Attributes:
DbLogExclude .*
IODev CUL
IOgrp VCCU
aesCommReq 1
autoReadReg 4_reqStatus
devStateIcon on:light.on off:light.off
expert 2_full
firmware 2.3
group switch
icon Switch
model HM-LC-Sw1PBU-FM
peerIDs 00000000,29F48001,29F48002,
room Homematic
serialNr LEQ0234650
subType switch
webCmd on:off:toggle
Nochwas:
Gestern Abend (also noch mit der vorherigen Version) hat mein Fenstersensor rot geblinkt, aber das DOIF wurde trotzdem ausgeführt!?
Konnte das jetzt aber nicht mehr reproduzieren...
Zitat von: Virsacer am 12 Juli 2015, 10:20:08
Leider nein, aber vielleicht hilft das weiter:
Hmm, letzte Version fuer dieses WE im Anhang, hoffentlich tut die jetzt :-)
Zitat
Nochwas:
Gestern Abend (also noch mit der vorherigen Version) hat mein Fenstersensor rot geblinkt, aber das DOIF wurde trotzdem ausgeführt!?
Konnte das jetzt aber nicht mehr reproduzieren...
Evtl. hat der Fenstersensor das ACK mit der richtigen AES-Response nicht empfangen und deswegen rot geblinkt. Worauf triggerst Du? Bei AES ist trig_aes... das richtige und Du musst dann manuell den state anschauen.
Gruss
Michael
Danke, habs jetzt aber noch nicht getestet...
Ja, das kann sein...
Mein Trigger ist in dem Fall
[Window] eq "open"
Zitat von: Virsacer am 13 Juli 2015, 17:58:22
Mein Trigger ist in dem Fall
[Window] eq "open"
Hmm, ich habe DOIF noch nie benutzt, aber das ueberprueft die AES-Signatur nicht.
Habe gerade mal was zusammengebastelt, was hier in meinem Testsystem mit einer Fernbedienung funktioniert:
([FB_KeyMatic_light:?trig_aes_VCCU.*ok] and [FB_KeyMatic_light] =~ "Short") (set Lampe_Decke_AZ toggle)
Wichtig ist hierbei, wirklich auf das Event trig_aes_xxx zu reagieren.
Gruss
Michael
Das DOIF reagiert jedesmal, wenn sich irgendein Reading von Window ändert und überprüft, ob der state "open" ist - mit der AES-Signatur hat das nix zu tun :D
Ich werde das mal testen, die Woche siehts aber gerade zeitlich schlecht aus...
Hi,
Zitat von: Virsacer am 14 Juli 2015, 17:30:51
Das DOIF reagiert jedesmal, wenn sich irgendein Reading von Window ändert und überprüft, ob der state "open" ist - mit der AES-Signatur hat das nix zu tun :D
Yep, das ist genau das Problem. Den state kann man von aussen "setzen", ohne die Signaturfrage zu beantworten. Nur direkt nach dem trig_aes-Event (deswegen das :? ) kann man sich sicher sein, dass der Status authentisiert ist.
Ich hab das jetzt auch mal in meinem Prod.-System mit einem TFK implementiert:
([Balkontuere_AZ:?trig_aes_VCCU.*ok] and [Balkontuere_AZ] eq "open")
Zitat
Ich werde das mal testen, die Woche siehts aber gerade zeitlich schlecht aus...
Waere klasse, hier siehts mittlerweile gut aus, getConfig, regSet und so laeuft alles durch :-)
Gruss
Michael
Mache lieber ein
([Balkontuere_AZ:?trig_aes_VCCU.*ok] and [?Balkontuere_AZ] eq "open")
draus ;).
Zitat von: Ralli am 14 Juli 2015, 18:49:03
Mache lieber ein
([Balkontuere_AZ:?trig_aes_VCCU.*ok] and [?Balkontuere_AZ] eq "open")
draus ;).
Danke :-)
Haette ich in der Dokumentation zu DOIF nie gefunden, weil es nirgends eine einfach Uebersicht der moeglichen Operatoren gibt, nur Beispiele, aus denen man sich alles zusammenkratzen muss...
Gruss
Michael
Zitat von: mgernoth am 14 Juli 2015, 18:01:44Yep, das ist genau das Problem. Den state kann man von aussen "setzen", ohne die Signaturfrage zu beantworten.
Aber das widerspricht doch genau dem Sinn von der Signatur: Dass der Status nur akzeptiert wird, wenn er von einem legitimierten Gerät kommt :o
Zitat von: Virsacer am 16 Juli 2015, 18:08:04
Aber das widerspricht doch genau dem Sinn von der Signatur: Dass der Status nur akzeptiert wird, wenn er von einem legitimierten Gerät kommt :o
Verhaelt sich genauso, wie bei einem echten HM-IO (siehe hier (http://forum.fhem.de/index.php?topic=25665.0)). Da ich moechte, dass sich alle IOs gleich verhalten, muesste Martin das Verhalten von 10_CUL_HM bei aesCommReq global aendern. Einfach auf trig_aes triggern sollte aber eigentlich funktionieren (man koennte bei trig_aes den Status in ein eigenes Reading kopieren, um immer einen authentisierten Status zu haben).
EDIT: z.B. so:
define Authenticate_State notify .*:trig_aes_.*:.ok.* {\
fhem "setreading $NAME AESstate ".ReadingsVal($NAME, "state", $EVENT)\
if ((time() - time_str2num(ReadingsTimestamp($NAME,"state",0))) < 15)\
}
Wobei die Zeitabfrage eher Paranoia ist, ein Trigger sollte nur kommen, wenn der State uebertragen wurde.
Gruss
Michael
Hm, ok - Ich finde das Verhalten etwas seltsam, aber nungut...
Bin noch nicht dazu gekommen, aber werde es auf jeden Fall testen ;)
Hi,
Zitat von: Virsacer am 19 Juli 2015, 12:54:35
Hm, ok - Ich finde das Verhalten etwas seltsam, aber nungut...
Ist hauptsaechlich darin begruendet, dass die Informationen in unterschiedlichen Nachrichten kommen. Also zuerst die Statusaenderung und danach noch die AES-Signatur.
Zitat
Bin noch nicht dazu gekommen, aber werde es auf jeden Fall testen ;)
Habe mal die aktuelle Version angehaengt, ist eigentlich nur das Logging geaendert. Signaturnachrichten haben jetzt Level 4, Debug Level 5.
@Martin: Kannst Du Dir das mal bitte anschauen, wenn Du Zeit hast und evtl. uebernehmen? Danke :-)
Viele Gruesse
Michael
Zitat von: mgernoth am 19 Juli 2015, 13:20:39
Ist hauptsaechlich darin begruendet, dass die Informationen in unterschiedlichen Nachrichten kommen. Also zuerst die Statusaenderung und danach noch die AES-Signatur.
Also das ist kein Grund...
Die Devices speichern ja auch die Befehle zwischen und führen sie erst aus, wenn die Signatur kommt
Habs jetzt nur mal kurz getestet:
getConfig funktioniert und das Triggern mit [Window:?trig_aes_VCCU.*ok] auch.
Allerdings hatte ich jetzt auch noch keine nicht angekommenen Signaturpakete...
EDIT:
Hab jetzt auch die fehlende Signatur getestet, indem ich in der VCCU den Key verändert habe - State wird aktualisiert, aber der Trigger nicht ausgelöst
Das funktioniert also auch, aber dass der State sich vorher ändert sollte trotzdem noch korrigiert werden, damit es "werkseitig" sicher ist :)
Hi,
Zitat von: Virsacer am 21 Juli 2015, 18:50:40
Also das ist kein Grund...
Doch, das ist der Grund, warum Fhem sich im Augenblick so verhält. 10_CUL_HM ist halt an der Stelle Eventgetrieben und parst alle einkommenden Nachrichten.
Dass das nicht ideal ist, sehe ich aber auch so (und es macht das Anfordern der Signaturen für nicht-Trigger-Nachrichten eigentlich nutzlos).
Zitat
Die Devices speichern ja auch die Befehle zwischen und führen sie erst aus, wenn die Signatur kommt
Das war übrigens mein erster Versuch, die Signaturprüfung mit CUL zu implementieren. Ich habe die Nachrichten gecached, musste sie aber teilweise Parsen um herauszufinden, ob sie überhaupt eine Signatur benötigen...
Das ist mir dann total um die Ohren geflogen. Und als ich gesehen habe, dass das bei normalen HM-IOs auch nicht gemacht wird, habe ichs erstmal so implementiert.
Zitat
Habs jetzt nur mal kurz getestet:
getConfig funktioniert und das Triggern mit [Window:?trig_aes_VCCU.*ok] auch.
Allerdings hatte ich jetzt auch noch keine nicht angekommenen Signaturpakete...
EDIT:
Hab jetzt auch die fehlende Signatur getestet, indem ich in der VCCU den Key verändert habe - State wird aktualisiert, aber der Trigger nicht ausgelöst
Gutgut :-)
Zitat
Das funktioniert also auch, aber dass der State sich vorher ändert sollte trotzdem noch korrigiert werden, damit es "werkseitig" sicher ist :)
Ja, schon. Nur habe ich die Befürchtung, dass das eine größere Änderung der 10_CUL_HM nach sich zieht, das kann aber nur Martin beurteilen, mit fehlt immer noch der ganze Überblick über das Modul.
Viele Grüße
Michael
Zitat
10_CUL_HM ist halt an der Stelle Eventgetrieben und parst alle einkommenden Nachrichten.
Ok, DAS ist ein Grund ;)
Zitat
Dass das nicht ideal ist, sehe ich aber auch so (und es macht das Anfordern der Signaturen für nicht-Trigger-Nachrichten eigentlich nutzlos).
Ja, schon. Nur habe ich die Befürchtung, dass das eine größere Änderung der 10_CUL_HM nach sich zieht, das kann aber nur Martin beurteilen, mit fehlt immer noch der ganze Überblick über das Modul.
Dann ist ja gut, wenn du das genauso siehst und das irgendwann noch umgebaut wird :)
Hab aber noch einen Fehler bemerkt:
"set Thermostat_Clima desired-temp 18" funktioniert nicht mehr :o
Zitat von: Virsacer am 22 Juli 2015, 09:05:08
Hab aber noch einen Fehler bemerkt:
"set Thermostat_Clima desired-temp 18" funktioniert nicht mehr :o
Huh?
Was ist das für ein Thermostat? HM-CC-RT-DN? Wandthermostat?
Wie sind die AES-Settings bei Dem Ding (also sign auf dem Kanal und aesCommReq)?
(HM-CC-RT-DN und passenden WT habe ich, hängen aber an meinem System mit HMCFGUSB. Kann ich aber zum Testen umhängen, brauche nur Details)
Gruß
Michael
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...
Zitat von: Virsacer am 22 Juli 2015, 23:15:02
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
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
Ja, läuft wieder :)
Danke!
ZitatJa, 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...
Zitat von: Virsacer am 26 Juli 2015, 08:54:15
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 (http://forum.fhem.de/index.php/topic,39430.0.html) 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
rund ist das noch nicht.
Zumindest repeater werden nicht korrekt eingearbeitet.
Das prinzip ist ok.
Ich stelle es einmal online.
Hallo Martin,
Zitat von: martinp876 am 26 Juli 2015, 18:07:33
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
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 :o
Zitat von: Virsacer am 07 August 2015, 10:52:33
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 :o
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
Ok, ja das wars - danke :)
Kann man event-on-update-reading auch negieren? Also irgendwie so in der Art: (?!aesCommToDev)
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
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).
Hallo,
Zitat von: Ralli am 08 August 2015, 13:55:48
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
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 :)
Hallo,
Zitat von: Virsacer am 10 August 2015, 09:21:03
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
2015.08.10 10:36:33.186 4: CUL_Parse: CUL A 0F 0A 8610 34A7E2 000000 0A9D090E00402B -52.5
2015.08.10 10:36:33.288 4: CUL_send: CULAs 09 18 A112 E1245A 34A7E2
2015.08.10 10:36:33.447 4: CUL_Parse: CUL A 0A 18 8002 34A7E2 E1245A 002B -52.5
2015.08.10 10:36:33.549 4: CUL_send: CULAs 10 19 A001 E1245A 34A7E2 00040000000000
2015.08.10 10:36:33.766 4: CUL_Parse: CUL A 1A 19 A010 34A7E2 E1245A 020101020109010AEC0B710C2A0E0A0F012C -52
2015.08.10 10:36:33.867 4: CUL_send: CULAs 11 19 A002 E1245A 34A7E2 0402C2F67786C202
2015.08.10 10:36:33.982 4: CUL_Parse: CUL A 1A 19 A010 34A7E2 E1245A 020101020109010AEC0B710C2A0E0A0F012B -52.5
2015.08.10 10:36:34.083 4: CUL_send: CULAs 11 19 A002 E1245A 34A7E2 0402C2F67786C202
2015.08.10 10:36:34.261 4: CUL_Parse: CUL A 19 19 A003 34A7E2 E1245A 549377E3D836B7070F954A5588660B292C -52
2015.08.10 10:36:34.363 4: CUL_send: CULAs 0E 19 8002 E1245A 34A7E2 009f0d7e10
2015.08.10 10:36:34.518 4: CUL_Parse: CUL A 18 1A 8010 34A7E2 E1245A 02110012151600180019001A0000002B -52.5
2015.08.10 10:36:34.619 4: CUL_send: CULAs 11 1A A002 E1245A 34A7E2 0486717277132202
Meinst du so?
Hi,
Zitat von: Virsacer am 10 August 2015, 10:40:01
2015.08.10 10:36:34.518 4: CUL_Parse: CUL A 18 1A 8010 34A7E2 E1245A 02110012151600180019001A0000002B -52.5
2015.08.10 10:36:34.619 4: CUL_send: CULAs 11 1A A002 E1245A 34A7E2 0486717277132202
Meinst du so?
Genau.
Da hab ich beim Umbau anscheinend meinen Check für das Response-Required-Flag in dem Fall vergessen...
Im Anhang mal ein Cleanup-Patch, der auch diesen Check wieder enthält. Hoffentlich behebt der das Problem.
Viele Grüße
Michael
Ja, funktioniert wieder 8)
Danke :)