Ich habe die Beobachtung gemacht, dass die keymatic immer nach einem Neustart von fhem (z.B. nach Absturz) automatisch auf oder abschliesst.
Habt ihr das gleiche Problem und eine Lösung dafür?
Hatte schon überlegt mit einem DOIF auf ([global:"Initialized"]) nach dem Neustart zur Sicherheit immer automatisch abzuschliessen, aber eine schöne Lösung ist das nicht...
Hi,
also dafür gibt es keinen Grund. Da wirst Du wohl irgendetwas definiert haben was einen Befehl ausführt. Ich denke das geht sonst gar nicht.
Bei mir ist das noch nie passiert.
Such mal mit grep (cmdalias Wiki) nach einem möglichen Schaltbefehl.
Gruß Otto
hmm, habe ein grep auf den Device-Namen sowie auf cmdalias über die fhem.cfg gemacht, aber ich habe keinen Befehl, der soetwas tut...
Wie steuerst Du Homematic? Welcher IO?
Ich meine wenn Du Recht hättest, dann müsste FHEM ja wahllos Steuerbefehle beim Systemstart an irgendwelche IOs senden.
Du kannst ja mal verbose 5 an der Keymatic einschalten und einmal neu starten. Man müsste ja im Log sehen ob da Befehle gesendet werden.
IOgrp ist vccu, IODev ist mal ein RM_HmUART, mal ein HMLAN.
Habe meine keymatic auf "inhibit on", aber das sollte ja auch nichts damit zu tun haben...
...noch eine Idee: Könnte es mit der fhem.save zusammenhängen?
D.h. beim letzten "Save" war die keymatic offen, d.h. in der fhem.save steht unlocked. Beim Absturz von fhem nachts ist abgeschlossen, sodass er aufschliesst, um den Status aus der fhem.save wieder herzustellen?
in der fhem.save steht doch nur setstate drin? Das führt doch nicht zu einem Schaltbefehl?
Ich habe es mal mit verbose 5 getestet mit folgendem Ergebnis:
Keymatic war augeschlossen und hat nach Neustart selbstständig abgeschlossen.
Das "include fhem.save" war es nicht, erst einige Zeit später hat er abgeschlossen und es kam Folgendes im Log:
2019.10.29 21:11:19.462 5: CUL_HM Keymatic protEvent:CMDs_pending pending:5
2019.10.29 21:11:19.462 3: CUL_HM set Keymatic statusRequest
2019.10.29 21:11:19.464 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:4
2019.10.29 21:11:20.071 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:4
2019.10.29 21:11:20.072 5: CUL_HM Keymatic sent ACK:2
2019.10.29 21:11:20.147 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:20.418 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:3
2019.10.29 21:11:20.684 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:20.699 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:20.885 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:3
2019.10.29 21:11:20.886 5: CUL_HM Keymatic sent ACK:2
2019.10.29 21:11:20.897 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:21.315 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:2
2019.10.29 21:11:21.335 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:21.483 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:21.670 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:2
2019.10.29 21:11:21.671 5: CUL_HM Keymatic sent ACK:2
2019.10.29 21:11:21.847 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:2
2019.10.29 21:11:21.849 5: CUL_HM Keymatic sent ACK:2
2019.10.29 21:11:22.047 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:2
2019.10.29 21:11:22.047 5: CUL_HM Keymatic sent ACK:2
2019.10.29 21:11:23.459 4: CUL_HM_Resend: Keymatic nr 2
2019.10.29 21:11:23.979 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:2
2019.10.29 21:11:23.980 5: CUL_HM Keymatic sent ACK:2
2019.10.29 21:11:23.991 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:24.233 5: CUL_HM Keymatic protEvent:CMDs_done_Errors:1
2019.10.29 21:11:24.249 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:24.259 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:28.642 5: CUL_HM Keymatic protEvent:CMDs_done
2019.10.29 21:11:28.642 5: CUL_HM Keymatic sent ACK:2
2019.10.29 21:11:28.675 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:28.682 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:45.517 5: CUL_HM Keymatic protEvent:CMDs_done
2019.10.29 21:11:45.518 5: CUL_HM Keymatic sent ACK:2
2019.10.29 21:11:45.552 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:11:45.557 4: CUL_HM Keymatic dupe: dont process
2019.10.29 21:12:02.569 5: CUL_HM Keymatic protEvent:CMDs_pending pending:1
2019.10.29 21:12:02.570 3: CUL_HM set Keymatic statusRequest
2019.10.29 21:12:02.573 5: CUL_HM Keymatic protEvent:CMDs_processing... pending:0
2019.10.29 21:12:03.089 5: CUL_HM Keymatic protEvent:CMDs_done
2019.10.29 21:12:03.090 5: CUL_HM Keymatic sent ACK:2
2019.10.29 21:12:03.105 4: CUL_HM Keymatic dupe: dont process
Kann mir aber noch immer nicht erklären, was die Ursache ist...
Ich glaube ich habe die Ursache gefunden:
Ich habe eine HM-Dis-WM55 Funk Statusanzeige. Wie im Wiki beschrieben habe ich eine fhem_user.cfg angelegt mit
set dis_01 displayWM short line1 e:{myLineA(1,0)}
...
die bei der Systeminitialisierung eingebunden wird.
In der 99_myUtils habe ich dann das Abschliessen der Keymatic auf die Taste des HM-Dis-WM55 gelegt und diese Funktion wird offenbar mit den set-Zeilen der fhem_user.cfg aufgerufen. Muss man erstmal drauf kommen...
Einfachste Lösung wäre wohl, dass ich die Keymatic-Befehle in der 99_myUtils nur ausführe, wenn der Neustart länger als x Sekunden her ist:
if (ReadingsVal("sysmon","fhemuptime",-1) > 300) {
{fhem ("set Keymatic lock")};
}
aber ich sehe da nur statusrequest ::) kein set lock
Ich habe mal ein normales open gemacht
2019.10.29 21:36:10 5: CUL_HM HM_535F7A protEvent:CMDs_pending pending:1
2019.10.29 21:36:10 3: CUL_HM set HM_535F7A open
2019.10.29 21:36:10 5: CUL_HM HM_535F7A protEvent:CMDs_processing... pending:0
2019.10.29 21:36:10 5: CUL_HM HM_535F7A sent ACK:2
2019.10.29 21:36:10 4: CUL_HM HM_535F7A dupe: dont process
2019.10.29 21:36:10 5: CUL_HM HM_535F7A protEvent:CMDs_done
2019.10.29 21:36:11 4: CUL_HM HM_535F7A dupe: dont process
2019.10.29 21:36:11 4: CUL_HM HM_535F7A dupe: dont process
2019.10.29 21:36:17 5: CUL_HM HM_535F7A protEvent:CMDs_done
2019.10.29 21:36:17 5: CUL_HM HM_535F7A sent ACK:2
2019.10.29 21:36:17 4: CUL_HM HM_535F7A dupe: dont process
2019.10.29 21:36:17 4: CUL_HM HM_535F7A dupe: dont process
paralle im FileLog sieht es so aus:
2019-10-29_21:36:10 HM_535F7A set_open
2019-10-29_21:36:10 HM_535F7A locked
2019-10-29_21:36:11 HM_535F7A aesCommToDev: pending
2019-10-29_21:36:11 HM_535F7A aesCommToDev: ok
2019-10-29_21:36:17 HM_535F7A lock: unlocked
2019-10-29_21:36:17 HM_535F7A unlocked
Ok da hab ich jetzt zu lange gebraucht.
Ich würde die Tasten direkt peeren und nicht den Umstand über 99_myUtils machen. Oder ich habe es nicht verstanden ;)
Direkt peeren zwischen HM-Dis-WM55-Taster und Keymatic geht leider nicht, schon nur da ich inhibit auf on habe.
Ist etwas kompliziert zu verstehen, wenn man kein HM-Dis-WM55 hat. Details zur Funkanzeige findet man unter https://wiki.fhem.de/wiki/HM-Dis-WM55_Funk_Statusanzeige (https://wiki.fhem.de/wiki/HM-Dis-WM55_Funk_Statusanzeige)
Danke für die Hilfe
Test war gerade positiv, Problem ist also gelöst.
Musste noch ein "setreading sysmon fhemuptime 0" ins fhem_user.cfg hinzufügen, da die fhem_user.cfg offenbar vor der Initialisierung von fhemuptime ausgeführt wurde.
Du bist sicher, dass der Status vom Wiki noch aktuell ist?
ein get hm models liefert
display HM-DIS-WM55 00D3 config 1, 1-10 Dis,
Schaut für mich aus wie supportet. Aber ich habe es nicht, ich kann nur theoretisch mitreden. Besonderheit mit der keymatic ? Kann auch noch sein.
Hast Du das peeren einfach mal probiert?
Ok inhibit ist ein Argument. Aber wozu ist die normale Bedienung verhindert?
habs nicht probiert, aber ich nutze ohnehin inhibit aufgrund kindersicherung (sperrung tasten) und security (keine fernbedienung etc)
über zentrale / fhem funktioniert es ja gut, von daher kein bedarf das zu ändern...