Hallo zusammen,
in Verbindung mit meiner Alarmanlage wollte ich nun auch beim Homematic-MP3-Funkgong (HM-OU-CFM-PL) AES aktivieren und dazu "R-sign" beider Kanäle (MP3 und LED) auf "on" setzen.
Leider erscheint nach dem Abschicken des Befehls
set FunkGongHM_MP3__DG_Eingang sign on
per GUI oder Commandozeile folgende Meldung:
cannot calculate value. Please issue set FunkGongHM_MP3__DG_Eingang getConfig first - invalid
Alle andere Funktionen laufen bisher ohne Probleme. Bisher macht nur die Aktivierung von AES Zicken.
Weiß jemand Rat?
Gruß
Leeloo
Nachtrag 1: Ein ConfigCheck liefert übrigens keine Einträge/Fehler.
Nachtrag 2: getConfig habe ich schon x-mal ausgeführt, aber ohne Erfolg
Nachtrag 3: Hier gab es schon einmal ein ähnliches Problem https://forum.fhem.de/index.php/topic,21756.msg152184.html#msg152184 (https://forum.fhem.de/index.php/topic,21756.msg152184.html#msg152184). Die Lösung war damals eine Software-Anpassung.
Nachtrag:
Scheinbar fehlt hier das Register "R-Sign"
Ggf. ähnlich wie Thread: https://forum.fhem.de/index.php?topic=55104.msg468240#msg468240 (https://forum.fhem.de/index.php?topic=55104.msg468240#msg468240)
Zur vollständigen Übersicht habe ich folgendes beim FunkGongHM__DG_Eingang gesetzt.
attr FunkGongHM__DG_Eingang expert 251_anything
set FunkGongHM__DG_Eingang regSet intKeyVisib visib
Anbei die Lists der Channels (LED und MP3) von FunkGongHM_LED__DG_Eingang:
--------
=>FunkGongHM_LED__DG_Eingang
Internals:
CFGFN /opt/fhem/mycfg/99_alarm.cfg
DEF 3BA00301
NAME FunkGongHM_LED__DG_Eingang
NR 1068
NTFY_ORDER 50-FunkGongHM_LED__DG_Eingang
STATE off
TYPE CUL_HM
chanNo 01
device FunkGongHM__DG_Eingang
peerList self01,
Readings:
2016-07-05 14:31:48 CommandAccepted yes
2016-07-05 18:56:38 R-self01-lgActNum 7
2016-07-05 18:56:38 R-self01-lgActTypeLed orangeL
2016-07-05 18:56:38 R-self01-lgActionType jmpToTarget
2016-07-05 18:56:38 R-self01-lgCtDlyOff geLo
2016-07-05 18:56:38 R-self01-lgCtDlyOn geLo
2016-07-05 18:56:38 R-self01-lgCtOff geLo
2016-07-05 18:56:38 R-self01-lgCtOn geLo
2016-07-05 18:56:38 R-self01-lgCtValHi 100
2016-07-05 18:56:38 R-self01-lgCtValLo 50
2016-07-05 18:56:38 R-self01-lgMultiExec on
2016-07-05 18:56:38 R-self01-lgOffDly 0 s
2016-07-05 18:56:38 R-self01-lgOffTime unused
2016-07-05 18:56:38 R-self01-lgOffTimeMode absolut
2016-07-05 18:56:38 R-self01-lgOnDly 0 s
2016-07-05 18:56:38 R-self01-lgOnTime 6 s
2016-07-05 18:56:38 R-self01-lgOnTimeMode absolut
2016-07-05 18:56:38 R-self01-lgSwJtDlyOff no
2016-07-05 18:56:38 R-self01-lgSwJtDlyOn no
2016-07-05 18:56:38 R-self01-lgSwJtOff dlyOn
2016-07-05 18:56:38 R-self01-lgSwJtOn no
2016-07-05 18:56:38 R-self01-shActNum 7
2016-07-05 18:56:38 R-self01-shActTypeLed orangeL
2016-07-05 18:56:38 R-self01-shActionType jmpToTarget
2016-07-05 18:56:38 R-self01-shCtDlyOff geLo
2016-07-05 18:56:38 R-self01-shCtDlyOn geLo
2016-07-05 18:56:38 R-self01-shCtOff geLo
2016-07-05 18:56:38 R-self01-shCtOn geLo
2016-07-05 18:56:38 R-self01-shCtValHi 100
2016-07-05 18:56:38 R-self01-shCtValLo 50
2016-07-05 18:56:38 R-self01-shMultiExec off
2016-07-05 18:56:38 R-self01-shOffDly 0 s
2016-07-05 18:56:38 R-self01-shOffTime unused
2016-07-05 18:56:38 R-self01-shOffTimeMode absolut
2016-07-05 18:56:38 R-self01-shOnDly 0 s
2016-07-05 18:56:38 R-self01-shOnTime 6 s
2016-07-05 18:56:38 R-self01-shOnTimeMode absolut
2016-07-05 18:56:38 R-self01-shSwJtDlyOff off
2016-07-05 18:56:38 R-self01-shSwJtDlyOn on
2016-07-05 18:56:38 R-self01-shSwJtOff dlyOn
2016-07-05 18:56:38 R-self01-shSwJtOn dlyOff
2016-07-05 18:58:23 RegL_03.self01 02:00 03:00 04:32 05:64 06:00 07:26 08:00 09:FF 0A:01 0B:14 0C:63 24:32 25:07 26:00 27:00 28:00 29:00 2A:00 2B:FF 82:00 83:00 84:32 85:64 86:00 87:26 88:00 89:FF 8A:21 8B:10 8C:00 8D:32 8E:07 A4:32 A5:07 A6:00 A7:00 A8:00 A9:00 AA:00 AB:FF 00:00
2016-07-05 18:58:22 peerList self01,
2016-07-05 14:31:48 recentStateType ack
2016-07-05 14:31:48 state off
Helper:
dlvl 00
dlvlCmd ++A011F112343BA0030201000000
peerIDsRaw ,3BA00301,00000000
Expert:
def 1
det 1
raw 1
tpl 1
Role:
chn 1
Shadowreg:
Tmpl:
Attributes:
fp_001_DG 235,850,1,FunkGongHM_LED__DG_Eingang,
group System_realDevices
icon light_led
model HM-OU-CFM-PL
peerIDs 00000000,3BA00301,
room SYSTEM
webCmd press short:press long
--------
=>FunkGongHM_MP3__DG_Eingang
Internals:
CFGFN /opt/fhem/mycfg/99_alarm.cfg
DEF 3BA00302
NAME FunkGongHM_MP3__DG_Eingang
NR 1069
NTFY_ORDER 50-FunkGongHM_MP3__DG_Eingang
STATE off
TYPE CUL_HM
chanNo 02
device FunkGongHM__DG_Eingang
peerList self02,
Readings:
2016-07-05 14:31:48 CommandAccepted yes
2016-07-05 18:56:39 R-self02-lgActNum 1
2016-07-05 18:56:39 R-self02-lgActTypeMp3 0
2016-07-05 18:56:39 R-self02-lgActionType jmpToTarget
2016-07-05 18:56:39 R-self02-lgCtDlyOff geLo
2016-07-05 18:56:39 R-self02-lgCtDlyOn geLo
2016-07-05 18:56:39 R-self02-lgCtOff geLo
2016-07-05 18:56:39 R-self02-lgCtOn geLo
2016-07-05 18:56:39 R-self02-lgCtValHi 100
2016-07-05 18:56:39 R-self02-lgCtValLo 50
2016-07-05 18:56:39 R-self02-lgIntense vol_100
2016-07-05 18:56:39 R-self02-lgMultiExec on
2016-07-05 18:56:39 R-self02-lgOffDly 0 s
2016-07-05 18:56:39 R-self02-lgOffTime unused
2016-07-05 18:56:39 R-self02-lgOffTimeMode absolut
2016-07-05 18:56:39 R-self02-lgOnDly 0 s
2016-07-05 18:56:39 R-self02-lgOnTime unused
2016-07-05 18:56:39 R-self02-lgOnTimeMode absolut
2016-07-05 18:56:39 R-self02-lgSwJtDlyOff no
2016-07-05 18:56:39 R-self02-lgSwJtDlyOn no
2016-07-05 18:56:39 R-self02-lgSwJtOff dlyOn
2016-07-05 18:56:39 R-self02-lgSwJtOn no
2016-07-05 18:56:39 R-self02-shActNum 1
2016-07-05 18:56:39 R-self02-shActTypeMp3 0
2016-07-05 18:56:39 R-self02-shActionType jmpToTarget
2016-07-05 18:56:39 R-self02-shCtDlyOff geLo
2016-07-05 18:56:39 R-self02-shCtDlyOn geLo
2016-07-05 18:56:39 R-self02-shCtOff geLo
2016-07-05 18:56:39 R-self02-shCtOn geLo
2016-07-05 18:56:39 R-self02-shCtValHi 100
2016-07-05 18:56:39 R-self02-shCtValLo 50
2016-07-05 18:56:39 R-self02-shIntense vol_100
2016-07-05 18:56:39 R-self02-shMultiExec off
2016-07-05 18:56:39 R-self02-shOffDly 0 s
2016-07-05 18:56:39 R-self02-shOffTime unused
2016-07-05 18:56:39 R-self02-shOffTimeMode absolut
2016-07-05 18:56:39 R-self02-shOnDly 0 s
2016-07-05 18:56:39 R-self02-shOnTime unused
2016-07-05 18:56:39 R-self02-shOnTimeMode absolut
2016-07-05 18:56:39 R-self02-shSwJtDlyOff off
2016-07-05 18:56:39 R-self02-shSwJtDlyOn on
2016-07-05 18:56:39 R-self02-shSwJtOff dlyOn
2016-07-05 18:56:39 R-self02-shSwJtOn dlyOff
2016-07-05 18:58:25 RegL_03.self02 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 24:00 25:01 26:00 27:00 28:00 29:00 2A:00 2B:FF 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:10 8C:00 8D:00 8E:01 A4:00 A5:01 A6:00 A7:00 A8:00 A9:00 AA:00 AB:FF 00:00
2016-05-01 18:56:28 level set_0
2016-07-05 18:58:22 peerList self02,
2016-07-05 14:32:02 recentStateType info
2016-07-05 14:32:02 state off
Helper:
peerIDsRaw ,3BA00302,00000000
Expert:
def 1
det 1
raw 1
tpl 1
Role:
chn 1
Shadowreg:
Tmpl:
Attributes:
fp_001_DG 280,849,1,FunkGongHM_MP3__DG_Eingang,
group System_realDevices
icon audio_loudness
model HM-OU-CFM-PL
peerIDs 00000000,3BA00302,
room SYSTEM
webCmd press short:press long:playTone replay
Gibt es jemand, der helfen kann oder gar beim HM-OU-CFM-PL (MP3 - Funkgong)
R-sign=on einstellen konnte?
Warum sollte man das tun ? Wer hat denn Interesse daran, einen Funkgong unberechtigt zu aktivieren ?
Bei aller Freude an der Digitalisierung - aber dieser modernen Version des "Schellenkloppens" (oder wie auch immer es im jeweiligen Lokaldialekt genannt wird) gebe ich wenig Aussicht auf Erfolg.
LG
pah
Erst mal Danke für das Feedback.
Es geht mir jedoch hierbei weniger um die unberechtigte Aktivierung. Dazu kann ich Ihr Argument noch teilen.
Die unberechtigte Deaktivierung eines Alarms (Led , MP3) steht hier eher im Vordergrund.
Klar, kann jemand das Gerät einfach aus der Steckdose ziehen. Das geht aber nur, wenn bereits ein Zugriff auf das Objekt möglich ist.
Auch könnte der Strom für ganze Haus abgeschaltet werden, aber dann hat man andere Probleme,....
Konkretes Beispiel, bei dem eine unberechtigte Deaktivierung eine wichtige Rolle spielt:
Bei uns wird dieses Gerät als "inhouse- Alarm" eingesetzt, um u.a. Fehlerzustände von Geräten zu melden
z.B.
- Wasserleitung undicht => LED= blinkt gelb
und
- als Alarmsignal (Alarmanlage an=LED grün ; Einbruch => LED=blinkt rot und MP3=laute Sirene).
Dieser "inhouse-Arlarm" dient dazu das Haus abzusichern, wenn wir uns darin befinden.
Falls sich jemand unberechtigten Zutritt verschafft hat, dann möchten wir geweckt werden.
Also aus meiner Sicht wäre es sinnvoll AES beim HM-OU-CFM-PL (MP3 - Funkgong) einzusetzten, um eine unberechtigte Deaktivierung zu verhindern.
Gruß
Leeloo
Ich bleibe dabei, dass ich das nicht für sinnvoll halte.
Ein Einbrecher, der durch das Mitsniffen des Verkehrs (z.B. zwischen einem Handsender und einem Türöffner, so wie das inzwischen immer häufiger im Automobilbereich geschieht) einfach mal die Tür öffnen kann, ist durchaus denkbar. Dass dieser aber durch längere Vorbereitungszeit herausfinden kann, welches interne Gerät er deaktivieren muss, scheint mir für einen Privathaushalt überzogen. Lässt sich übrigens auf einfachste Weise selbst zur Alarmierung nutzen: Wenn jemand um 3 Uhr in der Frühe meine Alarmierung ausschaltet, liegt klar eine Sabotage vor.
Viel wahrscheinlicher ist, dass der Einbrecher sich einen richtig kräftigen Sender besorgt und einfach alle HomeMatic-Empfänger lahmlegt, Wegen der verwendeten Frequenzmodulation ist das ohne großen technischen Aufwand machbar.
LG
pah
Interessante Aspekte, die ich ggf. auch teilen kann/werde.
Wahrscheinlich gibt/gab es diese Debatte bereits, wenn nicht können wir den Thread gerne eröffnen und eine Debatte führen, wann und wie AES sinnvoll in die Hausautomation integriert werden kann.
In etwa so: "AES in der Hausautomatisierung: Grenzen, Risiken und Möglichkeiten zur Minderung der Risiken"
Teile dazu stehen bereits, recht ausführlich und somit transparent für Interessierte, im Wiki. Danke dafür :)
Aber jetzt zu den zwei interessanten Aspekten Ihrer Erläuterungen.
A)
Zitat
....Lässt sich übrigens auf einfachste Weise selbst zur Alarmierung nutzen: Wenn jemand um 3 Uhr in der Frühe meine Alarmierung ausschaltet, liegt klar eine Sabotage vor.
Dieser Hinweis ist korrekt und richtig. Eine Alarmanlage die diese Programmlogik beinhaltet ist sicherer als eine ohne diese Ergänzung.
Danke für diesen Hinweis, meine Alarmanlage wird sicher in den nächsten Tagen dbzgl. erweitert. ;)
Übrigens, diese Logik lässt sich 1:1 auf den Türöffner anwenden.
ZitatWenn jemand um 3 Uhr in der Frühe meine Tür öffnet, liegt klar eine Sabotage vor.
Da dieser Aspekt/dieses Argument sich nun sicherlich auf viele Komponenten in der Hausautomatisierung ausweiten läßt,
sich dabei bei jeder Komponente wahrscheinlich unzählige Diskussionen anschließen werden, ob es nun sinnvoll ist im jeweiligen Fall, AES zu nutzen oder nicht,
wäre es meiner Ansicht nach konsequenter die Komponenten, die eine AES-Funktionalität von Haus aus mitbringen, in vollen Umfang von FHEM zu unterstützen.
Entdeckt jemand, dass die AES-Funktion bei einer Homematic-Komponente fehlt, fehlerhaft und inkonsequent ist. Dann wird nicht darüber diskutiert, ob es nun generell sinnvoll ist oder nicht. Da mit Homematic, dies Option grundsätzlich realisierbar wäre, versuchen wir diese auch in FHEM hinzubekommen.
Aus meiner Sicht ist diese Vorgehensweise zielführender und bedarf in Summe weniger Aufwand.
B)
ZitatViel wahrscheinlicher ist, dass der Einbrecher sich einen richtig kräftigen Sender besorgt und einfach alle HomeMatic-Empfänger lahmlegt, Wegen der verwendeten Frequenzmodulation ist das ohne großen technischen Aufwand machbar.
Dieser Aspekt war mir gar nicht bewußt und die techn. Umsetzung ist mir noch völlig fremd. :(
Da es aus Ihrere Sicht jedoch wohl mit einfachsten Mitteln realisiert werden kann, gehört dieser Hinweis wohl eindeutig in den Bereich "Grenzen".
Ein Störsender stellt somit die "Sicherheit" aller Funk-Komponeten in Frage, unabhängig von AES.
AES-Komponeten bieten hier keine zusätzliche Sicherheit. Wenn das so stimmt, dann ist dieser Hinweis im Wiki sicherlich sehr hilfreich und wichtig.
Sorry für meine ggf. naive Nachfrage zu diesem Bereich. Wie gesagt, für mich ist dieser Zusammenhang neu.
Kann das Risiko eines "Störsender" ähnlichen dem "Workaround" aus Abschnitt A minimiert werden?
Etwa:
Wenn meine Zentrale um 3 Uhr in der Frühe x von y Komponenten nicht erreichen kann, liegt wahrscheinlich eine Sabotage vor.
Gruß
Leeloo
Diese Nachfragen sind nicht überflüssig, sondern sogar sehr wichtig.
Nochmal zum AES: Der Signaturmodus verdoppelt, grob gesagt, die Funklast: Kommando, Challenge, Response. Kommando und Response sind Aussendungen der Hauszentrale (oder des auslösenden Senders). Da für diese auch die 1%-Regel gilt, kann dadurch eine deutliche Verzögerung entstehen.
Das reine Öffnen der Tür um 1 Uhr in der Frühe ist nicht unbedingt eine Sabotage - vielleicht komme ich von einer Dienstreise (unwahrscheinlich...) oder einem Ball (schon eher ...).
Eine professionelle Intrusion Detection arbeitet mit Mustern von Events. In FHEM lässt sich das sehr schön mit dem Device sequence realisieren - beispielsweise wird meine Alarmanlage ausgeschaltet, indem zwei Köpfe in einer bestimmten Sequenz bedient werden (es gibt natürlich, um den WAF zu erhöhen, auch noch eine einfachere Möglichkeit...).
Beispielsweise könnte eine Alarmanlage für 15 Minuten unscharf geschaltet werden, indem erst das Garagtentor und dann innerhalb von 10 Minuten die Haustür betätigt werden. Oder ein Alarm wird ausgelöst, wenn nachts die Tür geöffnet, das Licht aber nicht angeschaltet wird.
Ich hatte auch schon überlegt, das in das Modul 95_Alarm.pm einzubauen, habe aber bisher noch nicht sgefunden, was sich nicht mit sequence erledigen ließe.
LG
pah
Um Ihren Gedanken weiter zu führen,...
demnach sollten alle Geräte die an einer solchen
sequence mitwirken auch
R-Sign=on erhalten.
Diese Schlußfolgerung kommt meinem Argument natürlich entgegen.
ZitatEntdeckt jemand, dass die AES-Funktion bei einer Homematic-Komponente fehlt, fehlerhaft und inkonsequent ist. Dann wird nicht darüber diskutiert, ob es nun generell sinnvoll ist oder nicht. Da mit Homematic, dies Option grundsätzlich realisierbar wäre, versuchen wir diese auch in FHEM hinzubekommen.
Unabhängig davon kann aus meiner Sicht, das von Ihnen aufgeführte Risiko "Störsender", nicht mit einer
sequence gemindert werden.
Zur Erweiterung der Integration von HM-OU-CFM-PL in FHEM :
Ich habe mir die "HMConfig.pm" gestern mal näher angesehen und verschiedenes ausprobiert. Leider konnte ich den HM-OU-CFM-PL (MP3 - Funkgong) nicht sauber integrieren. Mir war es nicht möglich den Code so zu ändern, dass ich das Register R-Sign setzen konnte.
Leider ist noch nicht ganz klar, in welchem Abschnitt die "calculation" gemacht wird.
cannot calculate value. Please issue set FunkGongHM_MP3__DG_Eingang getConfig first - invalid Gruß
Leeloo
Zitatdemnach sollten alle Geräte die an einer solchen sequence mitwirken auch R-Sign=on erhalten.
Nur, wenn es sich um die Alarm
auslösung handelt, oder um das direkte Schalten eines sicherheitskritischen Gerätes.
LG
pah
Zitatdemnach sollten alle Geräte die an einer solchen sequence mitwirken auch R-Sign=on erhalten.
Klar bzw. Logisch, war ja auch so gemeint. Aber sicher ist sicher ;)
Schön, jetzt haben wir zusätzliche Kenntnisse bzgl. der Nutzung von AES in der Hausautomatisierung zusammen getragen. :D
Im konkreten Fall "HM-OU-CFM-PL (MP3 - Funkgong)" können wir also festhalten:
Da es sich beim HM-OU-CFM-PL (MP3 - Funkgong), um ein
sicherheitskritisches Gerätes handeln kann, wäre es sinnvoll hierbei auch R-Sign=on nutzen zu können.
Zusätzlich handelt es sich dabei um eine Komponente, die diese Funktionalität von Haus aus unterstützt. Weshalb wir versuchen werden diese Funktionalität auch in FHEM zu implementieren.
Zur Implementierung:
Wie lässt sich dies nun in FHEM realisieren?
Reicht eine Anpassung in "HMConfig.pm"?
=> Wenn "Ja", welche?
=> Wenn "Nein", was muss noch angepaßt werden?
Vorarbeit zum Coding:
Zeilen in der HMConfig.pm die mMn mit der gewünschten Implementierung in Zusammenhang stehen:
Zeile 190 => Erweiterung unklar
,"0075" => {name=>"HM-OU-CFM-PL" ,st=>'outputUnit' ,cyc=>'' ,rxt=>'' ,lst=>'3' ,chn=>"Led:1:1,Mp3:2:2",}
Zeile 1082 und 1083 => Erweiterung um jeweils ein "
,sign =>1"
,"HM-OU-CFM-PL01" =>{ ActTypeLed =>1,sign =>1}
,"HM-OU-CFM-PL02" =>{ ActTypeMp3 =>1,Intense =>1,sign =>1}Gruß
Leeloo
ZitatDa es sich beim HM-OU-CFM-PL (MP3 - Funkgong), um ein sicherheitskritisches Gerätes handeln kann, wäre es sinnvoll hierbei auch R-Sign=on nutzen zu können.
Pardon, aber das sehe ich immer noch nicht. Von so etwas darf die Alarmierung nicht abhängen - man denke nur an den Fall, dass der Hausbewohner gerade die Haare föhnt.
LG
pah
Zitat- man denke nur an den Fall, dass der Hausbewohner gerade die Haare föhnt.
?Mit Verlaub, was will mir der Autor mit diesen Worten in Wirklichkeit mitteilen?
Ich kann darin keinen Beitrag zur konstruktiven Diskussion erkennen.
Gruß
Leeloo
Nun, dann ganz langsam zum Mitschreiben: Die Audio-Leistung des MP3-Funkgongs ist nicht so groß, dass man ihn im Nebenraum hören würde, wenn man sich gerade die Haare föhnt.
LG
pah
Ah,... jetzt ja.
Dieser Anwendungsfall ist so realitätsfern, dass ich nicht gleich darauf gekommen bin.
Aber seien Sie versichert, mit einer entsprechenden Audio-Datei sowie einer guten Platzierung des Alarmgebers im Haus,
hört man den Alarm sogar, wenn im gleichen Haus Schlagzeug spielt wird.
Sogar am Drum-Set selbst kann man dann das Signal noch hören.
Letzteres ist ein Beispiel aus der Praxis, da ich so beim Schlagzeugspielen informiert werde, wenn jemand an der Haustür klingelt.
Um auf Nummer sicher zu gehen, dass dies nicht als nächstes Gegenargument genutzt wird.
Die wahrscheinlich eines Einbruchs sinkt natürlich signifikant, wenn im Haus ein Schlagzeug zu hören ist.
Gruß
Leeloo
ZitatDie wahrscheinlich eines Einbruchs sinkt natürlich signifikant, wenn im Haus ein Schlagzeug zu hören ist.
oder das gegenteil ist der fall, da die einbruchgeräusche im lärm untergehen. :)
ich denke absolute sicherheit kann es nicht geben.
daher sollte jeder das tun, womit er/sie sich am wohlsten/sichersten fühlt.
@frank: Ja, ja und nochmals Ja. :)
Jede Medaille hat ihre Kehrseite.
Im Fall: AES / R-Sign beim HM-OU-CFM-PL bräuchten wir aber erst einmal eine Medaille ;)
Gruß
Leeloo