HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Kabellose und kabelgebundene Sender und Empfänger der klassischen Homematic-Serie

Moderator: Co-Administratoren

Gluehwurm
Beiträge: 12432
Registriert: 19.03.2014, 00:37
System: in Planung
Hat sich bedankt: 105 Mal
Danksagung erhalten: 380 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von Gluehwurm » 22.04.2021, 13:34

Das ist das, was sich hinter dem Begriff "Freiheit" verbirgt. Jeder darf, solange es nicht auf Kosten anderer ist, usw., mit seinem Geld machen, was er will. Oder wollen wir jetzt ein neues Thema über Dinge eröffnen, die mal unnützerweise angeschafft wurden??

Das Gute an "Freiheit" ist auch, man ist innerhalb des Rahmens niemandem rechenschaftspflichtig. Jemand anderes muss die jeweilige Entscheidung/Verhalten nicht verstehen.

Habe auch keinen "IchverdienedamitGeld"-Link oder einen Spendenaufruf gesehen. Daher darf er das
Raphael729 hat geschrieben:
22.04.2021, 10:29
werde ich mir erstmal einen neuen HM-Sec-Key kaufen in der Hoffnung das dass Problem gelöst ist
tun, wenn es ihm gefällt. 8)

dtp
Beiträge: 10655
Registriert: 21.09.2012, 08:09
System: CCU
Wohnort: Stuttgart
Hat sich bedankt: 320 Mal
Danksagung erhalten: 501 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von dtp » 22.04.2021, 13:49

Nun ja, der Hinweis war ja vermutlich weniger monetärer als vielmehr funktioneller Art, denke ich mal. Sprich, er darf gerne noch mal in eine KeyMatic investieren, könnte aber aufgrund der manuellen Bedienung wieder auf dieselben Probleme stoßen. Allerdings erschließt sich mir damit immer noch nicht, warum sich die KeyMatic selbständig gemacht hat.
CCU3 mit stets aktueller FW und den Addons "CUxD" und "Programmedrucken", ioBroker auf Synology DiskStation DS718+ im Docker-Container;
einige Projekte: zentrales Push-Nachrichten-Programm zPNP, DoorPi-Videotürsprechanlage, An- und Abwesenheitsdetektion per Haustürschloss, zentrales Programm zur Steuerung von Beschattungsgeräten zBSP.

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von Xel66 » 22.04.2021, 14:11

dtp hat geschrieben:
22.04.2021, 13:49
Allerdings erschließt sich mir damit immer noch nicht, warum sich die KeyMatic selbständig gemacht hat.
Mir auch nicht und es ist in meiner Installation in nunmehr sechs Jahren Nutzung auch noch nicht passiert. Und erfahrungsgemäß ist auf Aussagen, dass kein steuerndes Programm vorhanden ist, absolut kein Verlass. Da braucht man auch den Anwender nichts zu unterstellen. Mir sind immer wieder Threads untergekommen, in denen die Anwender steif und fest behauptet haben, dass es kein Programm mit Bezug zum Aktor etc. gibt und am Ende kam dann doch raus, dass dort noch irgendein vergessenes Programm/Script in den Tiefen der CCU gelauert hat (was nur mal so zum Testen angelegt wurde), von dem der Anwender glaubte, dass es dieses nicht mehr gäbe oder er es deaktiviert hätte oder was auch immer. In Systemen, in denen Programme direkt per ProgramExecute aufgerufen werden, ist auch das Deaktivieren von Programmen kein Garant.

Ursache kann der auf der Fernbedienung kauende Hund ;-) oder auch ganz normal ein Programm sein, dessen Bedingungsprüfung auch zum Systemstart angestoßen würde, welches aber durch einen Absturz der ReGa und nachfolgendem Start durch den Watchdog getriggert wurde. Der Möglichkeiten sind da erfahrungsgemäß viele und meist hat der ensprechenden Anwender sich das Ei auch noch selbst durch "unglückliche Wahl" der Trigger eines Programms selbst gelegt. Viele greifen dann auf diesen unsäglichen Workaround zurück. Auch ich nutze ja diese Systemvariable in einigen Scripten, denn sonst würde ich bei jedem Start mit wertlosen Statusmeldungen (Push, Mail, TTS) zugeschüttet, die durch das Setzen von Defaultwerte, die Statusabfrage von Aktoren oder das erstmalige Setzen eines gültigen Sensorwertes getriggert werden. Daher unterdrücke ich diese Statusmeldungen in den ersten fünf Minuten nach Systemstart und gebe beim Wechsel auf Normalbetrieb nur eine Info über den erfolgten Neustart via Push und Mail aus.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Raphael729
Beiträge: 12
Registriert: 21.02.2021, 12:22
System: CCU
Hat sich bedankt: 1 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von Raphael729 » 22.04.2021, 14:14

Xel66 hat geschrieben:
22.04.2021, 10:51
Genau an der altenativen Nutzung des Drehrades bzw. des Schlüssels liegen ja die Ursachen für die vermeintliche Fehlfunktion. Die Keymatic kann sich nur an den Endpunkten (abgeschlossen oder geöffnet) kalibrieren und die eigene Stellung feststellen, nachdem der Anwender sie "verdreht" hat. Sie hat dann folglich den Zustand "unbekannt" (wenn nicht per Zufall genau auf die Lichtschranke gedreht wurde), weil sie eben keinen echten Drehwinkelsensor besitzt. Die gradgenauen Angaben sind zeitliche Interpolationen der Motoransteuerung, ähnlich der Behanghöhe von Rollladenaktoren.

Um sich zu kalibrieren, macht sie dann bein nächsten Befehl einen vollen Lauf in Richtung des "nächsten" durch den Befehl bestimmten Endpunkt. Will man also nur aufschließen, dann läuft sie eben bis in die Endlage. Und das ist in diesem Falle eben "geöffnet" (Falle eingezogen). Und nur durch die zwischenzeitlichen mechanischen Betätigungen ist sie gezwungen, häufig auch in die Endlage "verschlossen" zu laufen. Dass das ein mechanisches Getriebe aus Plastikzahnrädchen nicht lange mitmacht und auf Dauer die Keymatic schrottet, dürfte angesichts der Stellkräfte selbst dem technisch unbedarftesten Anwender logisch erscheinen.
Es ist eben ein reines Level 8-Problem
Ja, es liegt an meiner Fehlbedienung, ich habe bestimmungsgemäß (denn dafür ist es ja da) im wahrsten Sinne des Wortes "am Rad gedreht" (zu oft) und wenn man das ein paar Jahre lang tut, funktioiniert das immer fehlerfrei, wird dann nach Jahren aber plötzlich dadurch quittiert, das der Motor 2x hintereinander die Tür öffnet weil es sich so halt selbsttätig kalibriert.
Insbesondere wenn man garnicht aufschließen wollte und das schloss seit Stunden nicht bedient hat.
Darf ich HÖFLICH nach der Quelle für diese Erklärung fragen oder erschliest sich Dir das einfach weil Du halt im Gegensatz zu mir kein Layer 8 User bist?

Dankbare Grüße

Raphael

dtp
Beiträge: 10655
Registriert: 21.09.2012, 08:09
System: CCU
Wohnort: Stuttgart
Hat sich bedankt: 320 Mal
Danksagung erhalten: 501 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von dtp » 22.04.2021, 14:19

Xel66 hat geschrieben:
22.04.2021, 14:11
Mir sind immer wieder Threads untergekommen, in denen die Anwender steif und fest behauptet haben, dass es kein Programm mit Bezug zum Aktor etc. gibt und am Ende kam dann doch raus, dass dort noch irgendein vergessenes Programm/Script in den Tiefen der CCU gelauert hat (was nur mal so zum Testen angelegt wurde), von dem der Anwender glaubte, dass es dieses nicht mehr gäbe oder er es deaktiviert hätte oder was auch immer.
Ein kurzer Klick auf die Buttons "Programme" und "Direkte" hinter dem jeweiligen Gerät in der Geräteliste der Einstellungen kann da sehr aufschlussreich sein. ;)

Hilft natürlich nicht bei Skripten, aber da gibt es andere Mittel und Wege, wie z.B. das Programmedrucken-Addon.
Xel66 hat geschrieben:
22.04.2021, 14:11
Viele greifen dann auf diesen unsäglichen Workaround zurück.
Auf diese Polemik bzw. Provokation werde ich nun nicht schon wieder eingehen. 8)
Zuletzt geändert von dtp am 22.04.2021, 14:23, insgesamt 1-mal geändert.
CCU3 mit stets aktueller FW und den Addons "CUxD" und "Programmedrucken", ioBroker auf Synology DiskStation DS718+ im Docker-Container;
einige Projekte: zentrales Push-Nachrichten-Programm zPNP, DoorPi-Videotürsprechanlage, An- und Abwesenheitsdetektion per Haustürschloss, zentrales Programm zur Steuerung von Beschattungsgeräten zBSP.

Raphael729
Beiträge: 12
Registriert: 21.02.2021, 12:22
System: CCU
Hat sich bedankt: 1 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von Raphael729 » 22.04.2021, 14:21

Xel66 hat geschrieben:
22.04.2021, 14:11
dtp hat geschrieben:
22.04.2021, 13:49
Allerdings erschließt sich mir damit immer noch nicht, warum sich die KeyMatic selbständig gemacht hat.
Mir auch nicht
ok, Du brauchst auf meine letzte Frage nicht zu antworten :D

Danke und Gruß

Raphael

Gluehwurm
Beiträge: 12432
Registriert: 19.03.2014, 00:37
System: in Planung
Hat sich bedankt: 105 Mal
Danksagung erhalten: 380 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von Gluehwurm » 22.04.2021, 14:32

Vielleicht hilft es zwischendurch mal per Programm oder Fb gezielt abzuschliessen.

SoerenR
Beiträge: 656
Registriert: 19.03.2019, 10:10
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 44 Mal
Danksagung erhalten: 57 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von SoerenR » 22.04.2021, 16:50

Raphael729 hat geschrieben:
22.04.2021, 14:14
Darf ich HÖFLICH nach der Quelle für diese Erklärung fragen oder erschliest sich Dir das einfach weil Du halt im Gegensatz zu mir kein Layer 8 User bist?
Ich stell mal die These in den Raum das es leider die Erfahrungen sind. Die Technik selbst ist selten das Problem. Meistens sitzt das Problem davor, leider schon oft selbst vor der Funktionierenden Technik gesessen....
Gruß Sören

RaspberryMatic // Philips Hue // KNX // HomeKit // und ein paar Spielerreien

Raphael729
Beiträge: 12
Registriert: 21.02.2021, 12:22
System: CCU
Hat sich bedankt: 1 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von Raphael729 » 22.04.2021, 17:25

SoerenR hat geschrieben:
22.04.2021, 16:50
Ich stell mal die These in den Raum das es leider die Erfahrungen sind.
Das kann wohl kaum die Erklärung hierfür sein:
Xel66 hat geschrieben:
22.04.2021, 10:51
Genau an der altenativen Nutzung des Drehrades bzw. des Schlüssels liegen ja die Ursachen für die vermeintliche Fehlfunktion.
SoerenR hat geschrieben:
22.04.2021, 16:50
Die Technik selbst ist selten das Problem. Meistens sitzt das Problem davor, leider schon oft selbst vor der Funktionierenden Technik gesessen....
Ja, das kann ich bestätigen, ich arbeite seit > 20 Jahren im EDV Support, darum habe ich ja auch in meinem Einganspost umfangreich berichtet und sogar angeboten
Raphael729 hat geschrieben:
21.04.2021, 21:55
Ich habe K E I N E Programme und K E I N E Direktverknüpfungen die in irgend einer Form meinen HM-Sec-Key-S steuern.
Ich kann gern hier die leeren Screenshots der Bereiche "Einstellungen --> Geräte --> HM-Sec-Key-S -->"Direkte und Programme" posten.

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

Beitrag von Xel66 » 22.04.2021, 21:09

Raphael729 hat geschrieben:
22.04.2021, 14:14
Darf ich HÖFLICH nach der Quelle für diese Erklärung fragen oder erschliest sich Dir das einfach weil Du halt im Gegensatz zu mir kein Layer 8 User bist?
Auch ich bin Layer 8 User aber ich verstehe mich nicht selbst als Problem (das mögen manche anders sehen ;-)). Und ich antworte Dir trotzdem auf die Frage, bzw. habe es eigentlich schon getan. Immer dann wenn Du am Rad drehst, hat mit einigermaßen Sicherheit die Keymatic den Status "unbekannt". Und jede Funktion (Direktvernküpfung, Programm, Script welches Status setzt) wird versuchen, die Keymatic in einen Status ungleich "unbekannt" zu bringen, denn diesen Status kann man nicht von der CCU via WebUI setzen, sondern er wird von der Keymatic bei Handbedienung gesetzt. So ist das System nun mal angelegt.
Raphael729 hat geschrieben:
22.04.2021, 17:25
Ich habe K E I N E Programme und K E I N E Direktverknüpfungen die in irgend einer Form meinen HM-Sec-Key-S steuern.
Mag ja alles sein, dass Dir das so angezeigt wird. Die Erfahrungen in ein paar Jahren in diesem Forum hier lehrt aber genau gegenteiliges. Du bist definitv nicht der erste, der behauptet, dass es keine Programme/Scripte mit Zugriff auf den Aktor gibt und wirst auch definitiv nicht der letzte sein. Und genau einen Punkt hast Du nicht aufgeführt, der aber äußerst relevant ist und gern übersehen wird, weil nämlich eine Ansteuerung im WebUI nicht direkt abfragbar ist. Dieser Punkt ist Scripting. Und Anwender mit IT-Background haben gern eine Affinität zu Scripten, selbst für simpelste logische Operationen. Grundproblem: Das System arbeitet im Gegensatz zu anderen Systemen strikt ereignisorientiert und Scripte sind eigenlich nicht für die Ausführung von Standardaufgaben gedacht (zumindest vom Hersteller, und darum supportet er auch kein Scripting) und darum führen Scripte leider auch in der WebUI ein Schattendasein. In anderen Umgebungen werden Scipte in den Hintergrund geschickt und machen da ihre Abfragen und Aktionen. In der Homematic-Umgebung müssen ReGa-Scripte Bestandteil eines Programms und müssen damit immer durch ein Ereignis oder zyklisch getriggert werden.

Du schreibst auch dass dieser Vorgang keinen Zeitstempel aktualisiert hat. Das ist m.E. auch schlichtweg nicht möglich, denn wenn die Keymatic ihre Statusänderung an die CCU gemeldet hat, dann sollte dieses im Zeitstempel dokumentiert sein. Als Ursache kommt theoretisch auch eine "leere" Batterie in einer Fernbedienung in Betracht. Auch hier sollte aber ein Zeitstempel aktualisiert worden sein, wenn sich die Fernbedienung im Empfangsbereich der CCU befunden hat. Greift das alles nicht, ist von einem elektronischen Defekt der Keymatic auszugehen. Damit wärst Du aber der Erste. Bei mir ist es zwar noch nicht vorgekommen, aber ich habe auch meine unliebsame Erfahrung mit einem Sensor mit "leerer" Zelle und daher wechsele ich die Zellen bei der ersten Batteriewarnung (lasse ich mir per Push zusenden), auch wenn sie wieder gegangen ist.
dtp hat geschrieben:
22.04.2021, 14:19
Auf diese Polemik bzw. Provokation werde ich nun nicht schon wieder eingehen. 8)
[OT] Das ist weder Polemik noch Provokation sondern schlichtweg meine Meinung. Und die rührt einzig und allein in der ständig wiederholten Behauptung falscher Tatsachen (alle Programme würden bei Systemstart getriggert usw.), die auch nicht durch noch so häufige Wiederholung an Wahrheitswert gewinnen. Du hast Dich zu unrecht angesprochen gefühlt.

Und das oftmals (meist) praktizierte Vorgehen ist nun mal das Einfügen dieses Blödsinns in alle Programme (und nur dieses macht es zu einem Blödsinn) mit mehr als fragwürdigen Begründungen. Man kann diesen Workaround durchaus praktisch nutzen. Ein Beispiel, wie und warum ich das Verhalten dieser speziellen Systemvariable nutze, habe ich ja bereits beschrieben. Aber der globale Einsatz ist und bleibt Blödsinn und dokumentiert, dass der Anwender nicht weiß, wie die Programme arbeiten. Und das liegt meist an der Ignoranz der einschlägigen Beschreibungen und weil hier im Forum eben diesbezüglich falsche Darstellungen kursieren.

Und nicht zuletzt ist davon auszugehen, dass genau dieses Verhalten durch den Hersteller beabsichtigt war, weil es im Grunde auch zielführend ist, ein System gemäß den aktuellen Gegebenheiten (Uhrzeit, Status, Sensorwerte) hinzustellen. So hat es schließlich der Anwender programmiert. Beispiel: der Rollladen, dessen Programm so programmiert ist, dass er nachts geschlossen sein soll, wird bei einem nächtlichen Systemstart runtergefahren. Da ist nichts falsch dran. Dieses kommt erst recht zum Tragen, wenn z.B. ein Backup eingespielt wird. Dort sind nämlich auch Status gespeichert, die ggf. an aktuelle Gegebenheiten angepasst werden müssen (z.B. wird ein im Winter gezogenes Backup beim Einspielen im Sommer die Heizung starten). Da wäre es dann zielführend, wenn das durch die Automatik geradegezogen wird. [/OT]

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Antworten

Zurück zu „HomeMatic Aktoren und Sensoren (klassisch)“