Hallo Martin,
ich habe seit ein paar Tagen (kann leider nicht mehr genau sagen seit wann), das Problem, dass meine vcc anscheinend den AES-Key vergißt, oder vergißt ihn zu übertragen.
Gemerkt habe ich das ganze, als ich vor meiner Haustür stand und die Keymatic nicht mehr schalten konnte (per FHEM).
Ich habe später dann in FHEM and der Keymatic gesehen, dass zwar versucht wurde den öffnen Befehl zu senden, denn state stand auf set_unlock. Das kannte ich schon von früher und weiß, dass das meistens der Fall ist, wenn die AES signierte Übertragung nicht klappt.
Als nächstes habe ich dann meine Handfernbedienung genommen, die ja ebenfalls mit dem gleichen Schlüssel ausgestattet ist und siehe da die Tür ließ sich damit problemlos öffnen und schließen.
Also, dann habe ich versucht meine Homematic an der Kellertüre mit FHEM zu schalten: nix!
Vielleicht hilft ja ein shutdown restart: nein, das Problem bestand auch danach noch.
Dann habe ich mir mal das Attribut hmKey an der vccu angeschaut: da war der korrekte Schlüssel drin.
Dann habe ich spaßeshalber einfach dss Attribut mit dem selben Inhalt nochmal neu geschrieben (einfach per attr-Button in den device-Details der vccu) und siehe da: alle Keymatics ließen sich sofort wieder per FHEM schalten.
Heute leider schon wieder vor verschlossener Tür gestanden.
Exakt das selbe Problem.
Ach ja: Im Log-File ist diesbezüglich leider rein gar nichts zu sehen, außer dass ich hin und wieder HMLAN disconnects habe, die habe ich aber quasi schon immer.
Wie gesagt, kann ich auch leider nicht genau sagen seit wann das Problem auftritt und weiß auch nicht, wo man eventuell ansetzen kann. Wenn du irgendwelche logs o.ä. brauchst, sag mir bitte was genau und ich werde versuchen zu liefern. Leider kann ich das verhalten auch nicht forcieren.
Gruß Benni.
Also ich hatte vor kurzem das Problem auch mal. Die vccu hat die Keys nicht an die HM-LANs verteilt bekommen. Der Grund dafür war damals eine fehlerhafte Config, irgendein halb-angelegtes Device oder sowas, leider weiß ich die Details auch nicht mehr. Auf jeden Fall hat die vccu mit einem Fehler abgebrochen bevor sie dazu kam die Keys zu verteilen oder sowas.
Zur Sicherheit kannst Du die Keys auch zusätzlich in den HM-LAN Devices hinterlegen, dann sollte das "die Tür geht nicht auf" nicht mehr vorkommen.
Gruß Marcel
Hallo Marcel,
danke für den Tip!
Ich habe den Key jetzt auch mal noch in den HMLANs hinterlegt.
"Defekte" oder halb angelegte devices habe ich aber keine, zumindest nicht, dass ich das irgendwie bemerken würde.
Nichts desto trotz scheint es da aber ein Problem zu geben?
Gruß Benni.
Zitat"Defekte" oder halb angelegte devices habe ich aber keine, zumindest nicht, dass ich das irgendwie bemerken würde.
mach mal "get hminfo configCheck".
einen
configCheck habe ich vor meiner letzten Antwort schon gemacht. ;D
Sieht, wie gesagt im Prinzip sauber aus, lediglich ein paar fehlende Temperaturlisten, was aber eigentlich kein Problem sein sollte. Ich hab bei denen
tempListTmpl trotzem mal auf 0 gesetzt, da kümmere ich mich später drum.
Zitat
configCheck done:
templist mismatch
HM_1D2909_Climate: file: ././tempList.cfg for HM_1D2909_Climate does not exist
HM_2061BC_Climate: file: ././tempList.cfg for HM_2061BC_Climate does not exist
HM_206340_Climate: file: ././tempList.cfg for HM_206340_Climate does not exist
OG.EZ.WT.Wandthermostat_Climate: file: ././tempList.cfg for OG.EZ.WT.Wandthermostat_Climate does not exist
WW.TC.Clima.Inside_Climate: file: ././tempList.cfg for WW.TC.Clima.Inside_Climate does not exist
Da checke ich eigentlich immer, wenn ich mal wieder neue Geräte angelernt oder gepeert habe und räume dann auch entsprechend auf.
Ich abe auch schon nach NO-TYPE Geräten gesucht. Habe ich aber auch keine.
das verteilen der schlüssel müsstest du mit "attr hmlan logIDs sys" erkennen können (logeinträge mit Y..). vergessen hat der hmlan die schlüssel wahrscheinlich nach einem reboot. damit der log nicht zu gross wird, würde ich das bei "hmlan:cond=disconnected" einschalten und bei "hmlan:cond=ok" wieder ausschalten.
vielleicht erreichen ihn die schlüssel ja auch gar nicht.
Reboot könnte passen:
Zitat
uptime 000 08:52:24.725
logging werde ich jetzt mal einrichten.
Ich denke, der Schlüssel wird manchmal korrekt verteilt, aber eben nicht immer.
Nach einem reboot erwarte ich, daß er verteilt wird. Schon wurde kompliziert: wird die vccu zuerst eingerichtet? In welcher Reihenfolge kommen die Attribute im config file?
Koennte das der Fehler sein?
Ich werde prüfen dass AES nach dem init an alle IOs der vccu gesendet wird. Ferner wenn AES geändert wird und wenn die ioliste geändert wird. Bin mir nicht sicher, dass alle 3 eingebaut sind.
Ach und dann noch nach einen reboot des io, besser disconnect.
Zitat von: Benni am 29 Januar 2016, 18:28:47
uptime 000 08:52:24.725
Das war übrigens die uptime von meinem HMLAN1 (also von dem, der die Keymatic normalerweise bedient (
IOgrp=ccu:HMLAN1 ich habe ja mehrere.) Es ging also um den Reboot des HMLANs.
fhem.cfg habe ich schon lange keine mehr, ich setze
configDB ein.
Ich habe mal ein
configdb list ausgeführt, wobei ich keine Ahnung habe in wie weit das die tatsächliche Reihenfolge beim einlesen der config beim FHEM-Start wiederspiegelt. Da werden die
HMLANs weit nach der
ccu aufgeführt.
Ich gehe einfach mal davon aus, dass das dort soweit passt.
Also dann werde ich jetzt erst mal nix machen und abwarten ;)
Wenn du doch noch irgenwelche Logs brauchst, einfach Bescheid geben, bin zu allen Schandtaten bereit .
Und danke schon mal! 8)
Eben hatte ich schon wieder so ein Tür-Erlebnis und das trotz dass der Key ja inzwischen auch im hmKey des HMLAN auch eingetragen ist. :-\
im Log nachgeschaut und im uptime des HMLAN und siehe da, vor knapp 4 Stunden hat er anscheinend einen Reboot durchgeführt und dabei wohl wieder den Key vergessen.
Jetzt habe ich mal das Logging, wie von Frank vorgeschlagen, eingeschaltet und am HMLAN mal den Stecker gezogen. Anschließend habe ich bis zum condition ok eine ganze Menge einträge vom HMLAN im Log, u.a. auch einen mit meinem hmKey (hmKey, hmId und HMLAN-SerialNr habe ich unkenntlich gemacht):
2016.01.30 14:52:38 1: HMLAN_Parse: HMLAN1 new condition timeout
2016.01.30 14:52:38 1: 192.168.178.231:1000 disconnected, waiting to reappear (HMLAN1)
2016.01.30 14:52:38 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.01.30 14:53:05 0: HMLAN_Send: HMLAN1 I:-24FE1F
2016.01.30 14:53:43 1: 192.168.178.231:1000 reappeared (HMLAN1)
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:A23A***
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:C
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2413F3,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+23C74E,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+21AE4E,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+33C48B,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2AE55A,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2558B0,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+261135,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2EB8C4,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+345702,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+22F974,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2AE826,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2EB18E,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2A54F8,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2E8842,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2624E2,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+247646,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+22B0F6,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+238AE5,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+22B40E,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2684C8,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+35B096,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+24A77A,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2D3551,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+209CAB,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+23D28F,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2B1943,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2EB8CA,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+255869,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+23BA81,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+238A9D,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+1EDB4D,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+20FF3C,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+1FC1F1,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+345FE3,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+26236D,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+209CB2,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+250577,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2CCDCE,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2CB008,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+247D88,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+26244E,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+1D2909,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+23D36F,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+238AFF,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+238B22,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2E87E1,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2066A5,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+345741,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+241705,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+1EDBA0,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2E2608,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+238A95,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+22F978,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+23CD19,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+35967F,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+20FF5C,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+345E79,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2E87CF,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2DB437,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+345F78,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+3458D6,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+206340,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2389F7,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2E8888,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+153376,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+20FE93,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+238940,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2E284C,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+343C76,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2061BC,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2388CA,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+206606,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+1FCD78,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2549E0,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+247EE5,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+2CCD5B,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+258B57,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:+1EE06A,00,01,00
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:Y01,01,<an dieser stelle steht mein hmKey>
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:Y02,00,
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:Y03,00,
2016.01.30 14:53:43 0: HMLAN_Send: HMLAN1 I:T1E3F6ED7,04,00,00000000
2016.01.30 14:53:43 1: HMLAN_Parse: HMLAN1 new condition init
2016.01.30 14:53:43 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ******* d:23A*** O:23A*** t:0000D2D4 IDcnt:0000 L:0 %
2016.01.30 14:53:43 1: HMLAN_Parse: HMLAN1 new condition ok
Das allerbeste ist aber, dass nach diesem Reboot durch Stromlos-Schaltung die Bedienung meiner KeyMatics ohne weiteres zutun wieder funktioniert hat.
Es scheint also eher, als ob nicht die vccu den AES-Key vergißt oder sie vergißt, diesen zu übertragen, sondern der HMLAN selbst. :o
Und nun?
ZitatDas allerbeste ist aber, dass nach diesem Reboot durch Stromlos-Schaltung die Bedienung meiner KeyMatics ohne weiteres zutun wieder funktioniert hat.
Es scheint also eher, als ob nicht die vccu den AES-Key vergißt oder sie vergißt, diesen zu übertragen, sondern der HMLAN selbst.
dass nach hmlan reboot der key weg ist, ist ja normal, daher sollte der key immer wieder neu gesetzt werden (Y-cmd), so wie im log. in bestimmten situationen gibt es wohl probleme, die du nun aufspüren must. :)
=> komt Y-cmd nach jedem disconnect? funktioniert danach jedes mal tür öffnen? vielleicht vergisst der hmlan auch zwischendurch => defekt?
Zitat von: frank am 30 Januar 2016, 16:20:58
in bestimmten situationen gibt es wohl probleme, die du nun aufspüren must. :)
Na ja, die Situation Reboot nach stromlos schalten sorgt anschenend für ein erneutes übertragen/setzen des keys (wie im log).
Die Situation eines unerwarteten Reboots aber wohl nicht.
Die Frage hier ist wahrscheinlich erst mal, wieso kommt es überhaupt zum unerwarteten Reboot?
Keine Ahnung, ob und wie sich das rausfinden ließe.
Zitat
=> komt Y-cmd nach jedem disconnect? funktioniert danach jedes mal tür öffnen? vielleicht vergisst der hmlan auch zwischendurch => defekt?
keine Ahnung, das werde ich jetzt die nächste Zeit mal überprüfen.
Im moment funktioniert noch alles.
Das logging habe ich jetzt auf jeden Fall erst mal dauerhaft aktiv.
ZitatDie Frage hier ist wahrscheinlich erst mal, wieso kommt es überhaupt zum unerwarteten Reboot?
Keine Ahnung, ob und wie sich das rausfinden ließe.
hiermit wirst du ein wenig schlauer. http://forum.fhem.de/index.php/topic,20776.0.html (http://forum.fhem.de/index.php/topic,20776.0.html)
Ok, ziemlich viel zu lesen ;D das muss ich mal in Ruhe durchgehen.
Ich habe übrigens noch 2 HMLANs laufen, die haben zwar auch gelegentliche disconnects, aber keine Reboots, wie der eine HMLAN. Die anderen sind aber auch deutlich ungünstiger in meinem Netzwerk angebunden (über dLAN) als der, der im Moment Probleme macht. Der hängt nämlich direkt an der Fritzox, als einziger an einem LAN-Port und der hatte bisher eigentlich gar keine disconnects.
Na ja, wie gesagt, ich werde mich da mal durcharbeiten. :-\
Auf jeden fall mal vielen Dank für die Unterstützung soweit. 8)
Die vccu stellt den key bereit. Hmlan muss ihn beim starten holen. Die vccu vergisst also erst einmal nichts.
Hmlan muss den key mit jedem y Kommando senden. Sollte hmlan schon wach sein und vccu noch nicht existent dann gibt es auch keinen key. Ebenso wenn hmlan startet und die Attribute sind noch nicht da.
Die confdb arbeitet sicher wie fhem.cfg: jede Einstellung wird sofort eingetragen, die Reihenfolge ist nahezu beliebig. Bei fhem.cfg kann ich sie durch die Reihenfolge bestimmen, kann sich aber bei einem save verschieben.
Wo ist das log her? Zeitlich? War das ein disconnect, reboot,...?
das Log ist beim Aus- und wieder Einschalten (Netzstecker gezogen) des HMLAN entstanden.
Seither hatte ich auch keinen Disconnect und keinen weiteren unerwarteten Reboot mehr:
Auszug aus dem List des HMLAN:
Zitat
...
uptime 000 21:47:01.415
...
Readings:
...
2016-01-30 14:53:43 Xmit-Events timeout:3 ok:5 disconnected:5 init:5
2016-01-30 14:53:43 cond ok
2016-01-31 12:39:30 loadLvl low
2014-03-08 13:28:03 prot_ERROR-Overload last
2015-03-24 20:40:23 prot_Warning-HighLoad last
2016-01-30 14:52:38 prot_disconnected last
2016-01-30 14:53:43 prot_init last
2015-12-04 20:21:28 prot_keepAlive last
2016-01-30 14:53:43 prot_ok last
2016-01-30 14:52:38 prot_timeout last
2016-01-30 14:53:43 state opened
Kurzer Zwischenbericht:
Der HMLAN läuft nun seit dem Reboot durch Netzstecker ziehen am 30.01. (http://forum.fhem.de/index.php/topic,48366.msg400709.html#msg400709) ohne einen einzigen Disconnect durch.
D.h. es hat seither auch kein unerwarteter Reboot mehr stattgefunden.
Dementsprechend lassen sich auch alle AES-Devices (Keymatics) immer noch schalten.
Vielleicht gilt auch bei einem HMLAN hin und wieder die Devise "Reboot tut gut" :-\
Er lief davor mehrere Monate (!) ununterbrochen durch.
Koennte also am disconnect liegen. Evtl. Muss man ein clear senden.... Mal sehen
Am WE hatte ich das Problem leider doch wieder. :(
Nach reconnect hatte der HMLAN keinen Schlüssel mehr und konnte die Türen nicht öffnen.
Ich habe mir jetzt erst mal ein notify eingerichtet, das auf den reconnect des HMLAN lauscht (cond: ok) und dann das hmKey-Attribut der vccu einmal neu setzt (natürlich mit dem selben key).
Mein Verdacht bleibt aber nach wie vor, dass es am HMLAN liegen könnte (defekt?). Werde demnächst mal den, der Probleme macht und die Haustür bedient gegen einen der anderen beiden austauschen.
Ich werde berichten ....