[GELÖST] AES mit 2. HM-LAN-CFG (wird nicht zum Empfänger)

[ronny332]

Hallo zusammen,

nachdem ich mir schon einen "Rüffel" für zu schnell gestellte Fragen gefangen habe, welcher auch mit einer Suche zu lösen gewesen wäre, hier eine hoffentlich gut durchdachte Frage, welche ich auch nach längerer Suche nicht lösen konnte:

In meinem Haus arbeiten einige optische Fensterkontakte (HM-SEC-SCo) und ein paar Schlosssteller (HM-SEC-KEY). Die Funktion ist mit Fhem seit dem Einbau gegeben, auch AES funktioniert problemlos.

Im Keller war die Reichweite des ersten HM-LAN-CFG allerdings knapp am Limit (-80 bis -95db, schwankend), daher kam ein weiterer HM-LAN-CFG dazu.

Code Auswählen Erweitern


define HMLAN1 HMLAN 10.0.0.41:1000
attr HMLAN1 addvaltrigger 1
attr HMLAN1 hmId XXXXXX
attr HMLAN1 hmKey 01:XXXXXX
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 room CUL_HM
attr HMLAN1 verbose 2
attr HMLAN1 wdTimer 25

define HMLAN2 HMLAN 10.0.0.44:1000
attr HMLAN2 addvaltrigger 1
attr HMLAN2 hmId XXXXXX
attr HMLAN2 hmKey 01:XXXXXX
attr HMLAN2 hmLanQlen 1_min
attr HMLAN2 room CUL_HM
attr HMLAN2 verbose 2
attr HMLAN2 wdTimer 25


Hier beispielhaft die Konfiguration für einen Fenster Kontakt:

Code Auswählen Erweitern


define hm_sco_ugWaschkueche CUL_HM XXXXXX
attr hm_sco_ugWaschkueche IODev HMLAN2
attr hm_sco_ugWaschkueche actCycle 024:01
attr hm_sco_ugWaschkueche actStatus alive
attr hm_sco_ugWaschkueche autoReadReg 0_off
attr hm_sco_ugWaschkueche expert 2_full
attr hm_sco_ugWaschkueche firmware 1.0
attr hm_sco_ugWaschkueche model HM-SEC-SCo
attr hm_sco_ugWaschkueche peerIDs 00000000,
attr hm_sco_ugWaschkueche room ug_waschkueche
attr hm_sco_ugWaschkueche serialNr LEQXXXXXX
attr hm_sco_ugWaschkueche subType threeStateSensor
define FileLog_hm_sco_ugWaschkueche FileLog ./log/hm_sco_ugWaschkueche-%Y.log hm_sco_ugWaschkueche


Gesendet wird über HMLAN2, wie ich einfach mal vermute, da HMLAN1 in der gleichen Sekunde etwas empfängt, was wohl das Kommando von HMLAN2 ist:

Code Auswählen Erweitern


HMLAN HMLAN1 UNKNOWNCODE A0D07B011BEDA112EC3D9800100FF::-57:HMLAN1


Die Antwort kommt natürlich auf beiden HMLANs an, genutzt wird allerdings entgegen nicht mit AES verschlüsselten Aktoren/Sensoren immernoch HMLAN1 als LASTInputDev. Besonders bei einem Fensterkontakt geht hier schon mal eine Antwort verloren, hier sind die Werte zu HMLAN1 besonders schlecht, HMLAN2 greift hier nicht ein.

Für einen einzigen (nicht sonderlich anders behandelten) Schlosssteller hat sich das LASTInputDev geändert, gerade dieser war aber noch sehr nah an HMLAN1 dran, auch wenn die Werte jetzt 4db besser sind.

Bei allen via AES verschlüsselten Geräten habe ich ein getConfig laufen lassen.

Kann mir bitte jemand die Erleuchtung bringen, oder eine Quelle, wo ich die Antwort nachlesen kann ?.

[tpm88]

Ich gehe mal davon aus, daß beide HMLAN die gleiche hmId haben??

Wenn ja, solltest Du eine vccu einrichten und mit preferedIO arbeiten. http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU
Wenn nein, versteh ich das Problem nicht. Dann sollte ja ein Fensterkontakt immer nur mit seinem nächstgelegenen HMLAN gepaired sein. Der andere HMLAN wird dann auch nicht antworten.

Gruß
Tobias

[Pfriemler]

Kann AES-Verschlüsselung mit fallweise wechselnden Io's überhaupt funktionieren? Ich würde schon deswegen die von Tobias genannte Variante empfehlen, also die HM-LANs von einer vCCU verwalten lassen und die Geräte auf das jeweils besser erreichbare HMLAN festnageln. Ich komme hier gottseidank mit einem aus, kann daher aktiv nichts beisteuern.

[ronny332]

Hallo,

Vielen Dank, der Link sollte doch weiterhelfen .

Die Funktion ist gegeben, vorhin hatte ich nur mit einem Wandtaster Probleme beim anlernen, was sich erst durch eine kurzzeitige Deaktivierung des HMLAN2 lösen lies.
Beide Geräte sind identisch eingerichtet, damit auch die HM-Id.

[ronny332]

Hallo nochmals,

das sieht doch schon ganz anders aus nach dem Umbau auf den virtuellen Controller. Die "UNKNOWNCODE" Meldungen sind direkt weg, einen Test mit dem Fensterkontakt konnte ich noch nicht machen (noch im Büro).

In jedem Fall scheint VCCU der Ansatz zu sein, der fehlte. Ich danke Euch!

[tpm88]

Prima.

Wenn alles ok ist, kannst Du noch den Threadtitel editieren und ein "Gelöst" einfügen...

[ronny332]

Alles funktioniert, nur dieser eine "entfernte" Fenster Kontakt nicht.

Er wird weiterhin mit HMLAN1 als letztes IO Device angezeigt und scheint HMLAN2 komplett zu ignorieren (mit 5 anderen Fenster Kontakten und 3 Schlossstellern funktioniert es seit der Umstellung VCCU problemlos).

Mittlerweile habe ich den Kontakt auch komplett zurückgesetzt und neu angelernt, es bleibt bei HMLAN1 als Bezug (obwohl es beim normalen anlernen bewusst nur über HMLAN2 geschehen ist).

Im Anhang sind zwei Screenshots von der aktuellen Situation. Aus meiner Sicht ist da alles glatt, es gibt von der Konfiguration auch keine Unterschiede zwischen diesem einen Sensor und den 5 anderen. 2 davon laufen über fehlerfrei über HMLAN2.

[frank]

Er wird weiterhin mit HMLAN1 als letztes IO Device angezeigt

das verstehst du falsch.

angezeigt wird "LASTInputDev". das bedeutet, dass der letzte funkspruch, der in fhem von diesem device empfangen wurde, vom hmlan1 registriert wurde. hmlan2 wird ihn bestimmt auch empfangen haben. über hmlan1 gehts wohl schneller. sobald ein befehl von irgendeinem io empfangen ist, werden die selben befehle, durch andere io empfangen, nicht nochmal ausgewertet. 

als dein prefered io wird wie eingestellt unter Internals IODev hmlan2 angegeben. dieser sendet die befehle von fhem zum device.

[ronny332]

Hallo,

jein, das war mir schon bewusst, leider kommt es aber "ständig" zu MISSING ACKs gar keinen Meldungen durch den Sensor (vermutlich gibt er irgendwann auf nach seinen Fehlversuchen).

Um das Thema hier nicht überzustrapazieren (nochmals Vielen Dank für all die Hilfe), setze ich das Thema auf gelöst. Das Hauptproblem wurde durch die Verwendung von VCCU gelöst, den Rest werde ich morgen angehen, einen "frischen" Fensterkontakt habe ich hier noch liegen, ggf. ist er etwas kooperativer.