Test Adapter Alarm 3.6.x
-
Hallo Profis, bin ziemlich neu hier und sorry, wenn ich was falsch gemacht habe aber ich habe mich auch mal an den Adapter gewagt und muss auch sagen, ist schon ein tolles Teil. Bin gerade am testen der Version 1.2.2 und habe ein paar Fragen an die, die den Adapter besser kennen als ich .... oder diesen sogar programmiert haben
1.) Wenn die Anlage scharf ist (use.enable = true) und ein Sensor des Alarmkreisen auf true geht, dann bleibt der "status.alarm_flash" und der status.silent_flash" immer auf false, auch nach Ablauf der Verzögerungszeit. Ist das so gewollt ?
2.) Wenn ein Sensor nur auf Benachrichtigung gesetzt ist, wird im info.log "Alarmanlage meldet Veränderung während der Nachtruhe bei: "Sensor Benachrichtigung"
3.) Bei Panikalarm wird als status.state_list "night rest(4)" eingetragen ? egal welche Zustand die Anlage hat ....
Grüße aus dem Aichtal ......
Stephan -
@sruhsam sagte in Test Adapter Alarm 1.1.x:
Hallo Profis, bin ziemlich neu hier und sorry, wenn ich was falsch gemacht habe aber ich habe mich auch mal an den Adapter gewagt und muss auch sagen, ist schon ein tolles Teil. Bin gerade am testen der Version 1.2.2 und habe ein paar Fragen an die, die den Adapter besser kennen als ich .... oder diesen sogar programmiert haben
1.) Wenn die Anlage scharf ist (use.enable = true) und ein Sensor des Alarmkreisen auf true geht, dann bleibt der "status.alarm_flash" und der status.silent_flash" immer auf false, auch nach Ablauf der Verzögerungszeit. Ist das so gewollt ?
Kann ich nicht nachstellen, habe es eben ausprobiert! Wenn der stille Alarm ist blinkt ...silent und bei alarm ...alarm.
Hast du eine Zeit konfiguriert???2.) Wenn ein Sensor nur auf Benachrichtigung gesetzt ist, wird im info.log "Alarmanlage meldet Veränderung während der Nachtruhe bei: "Sensor Benachrichtigung"
War ein Fehler, in der neuen Version behoben, danke!
3.) Bei Panikalarm wird als status.state_list "night rest(4)" eingetragen ? egal welche Zustand die Anlage hat ....
War ein Fehler, in der neuen Version behoben, danke!
-
@blauholsten
Habe bei „Blitzlichtzeit bei Einbruch“ und bei „Blitzlichtzeit bei stillem Alarm“ je 600sec stehen, aber das sind ja die Zeiten wie lange ausgelöst werden soll. Habe noch die Alarmverzögerung auf 60 sec stehen. Ausgang Status.burglar_alarm geht nach der Verzögerung auf „True“ aber Status.alarm_flash bleibt immer auf „false“
Gruß Stephan -
@sruhsam die Zeit ist das Intervall des blitzes. Bei dir würde die Leuchte im 10min Takt leuchten
-
@blauholsten sagte in Test Adapter Alarm 1.1.x:
@sruhsam die Zeit ist das Intervall des blitzes. Bei dir würde die Leuchte im 10min Takt leuchten
Achsoooo ich hab das auch falsch verstanden... Ich bitte darum, die Anleitung in die Konfig zu implementieren, den blauen Balken hast du ja schon gemacht, fehlt nur noch der Text ..
Das Hin- und Herspringen zur Github Seite ist weniger schön und nervt, da braucht sich keiner zu wundern, wenn das Readme nicht gelesen wird...
-
@blauholsten
alles klar, konnte flash nun positiv testen. Das schöne ist, mann kann auch z.B. mit 0.5 arbeiten, sofern die nachfolgenden System das schnelle Blinken auch verarbeiten können. Mit Version 1.2.3 sind auch die anderen beiden Themen vom Tisch.... super support! Klasse Arbeit ...Habe alle Schaltfolgen mal im Detail durchgetestet und dokumentiert und konnte keine Unklarheiten mehr feststellen.
Frage: ist das so gewollt, dass wenn ein Sensor nur mit Benachrichtigung von false auf true geht eine Benachrichtigung nur im scharfgeschalteten- und im Nachtruhe-Zustand versendet wird, nicht aber im "Scharf innen" Zustand.
Gruß
Stephan -
@sruhsam sagte in Test Adapter Alarm 1.1.x:
Frage: ist das so gewollt, dass wenn ein Sensor nur mit Benachrichtigung von false auf true geht eine Benachrichtigung nur im scharfgeschalteten- und im Nachtruhe-Zustand versendet wird, nicht aber im "Scharf innen" Zustand.
Hallo,
kann ich leider nicht nachstellen, bei mir gingen die Tests. -
@blauholsten
hab dies auch nochmals überprüft. war mein Fehler, da dies nicht angezeigt wurde, aber im logfile stand dann die Nachricht auch beim schalten von "scharf innen".
Schau immer direkt im IoBroker.Objekte auf den alarm.status, doch der aktualisiert sich manchmal nicht. Mein Problem, muss mal prüfen, hab erst seit neuem ein RPI4 auf welchem der IoBroker und CCU3 läuft.So long
Gruß
Stephan -
Hallo,
wie macht Ihr denn die Blockierung des Scharf Zustands auf dem VIS:Beispiel:
Anlage ist nur durch PIN deaktivierbar, aber wenn z.B. die Anlage Scharf ist, kann ja noch immer ohne PIN mit dem entsprechenden Buttons auf "Scharf innen" oder "Nachtruhe" gewechselt werden. Wenn nun die Sensoren des Innekreises nur auf Innenkreis ohn Benachrichtigung stehen, kann ja eingebrochen werden, ohne dass alarmiert oder benachrichtigt wird.Ziel sollte eigentlich sein, dass aus einem scharfen Zustand nur durch deaktivieren um- bzw. abgeschaltet werden kann, oder habe ich ein Denkfehler.
Gruß
Stephan -
Hallo Zusammen,
ich habe in der Version 1.2.3 folgendes Problem: scheinbar meldet die CCU (habe zwei, passiert bei beiden) bei bestimmten Geräten, z.B. nachdem diese z.B. gestört waren eine Änderung. Der Wert von STATE ist das dann zwar immer noch z.B. auf false, jedoch ist der Zeitstempel der letzen Änderung aktualisiert. Dies führt dann jedoch dazu, dass die Alarmanlage auslöst, obwohl der Wert sich gar nicht geändert hat und auch nicht kritisch ist, da die Tür ja noch zu ist.
Daher Idee: Wäre es möglich bei der Liste der überwachten Objekte noch den Werte von State anzugeben, welcher überwacht wird. Das würde auch helfen, z.B. bei Aktoren mit 3 Werten, also offen,geschlossen,gekippt noch genauer zu prüfen. Aber vor allem würden ungewollte Änderunge, bzw. Updates nicht zum Auslösen füren. Auch wäre es ja nicht "schlimm" wenn man das Fenster bei aktivierter Anlage schliesst, sonder nur öffnet. Also den State auf false triggen, true wäre okay. Hoffe ist verständlich.
Dazu: Ich habe bei meiner alten eigenen blockly Prüfung, neben der obene genannten Logig nur auf geänderte Werte geprüft.
Danke. Sonst läuft alles wirklich prima, nur halt doch einige Fehlarlame bei den Homematic Fensterkontakten.
-
@Mike-Weber morgen,
Dass kann eigentlich nicht sein! Es werden nur Veränderung getriggert. Stell den Adapter auf debug und beobachte in der Situation den Log. -
@blauholsten guten morgen, ja, mache ich, habe ich auf debug gestellt. m.E. wird ja der Zeitstempel auf Änderung durch die CCU gesetzt, daher löst es ja aus. Daher ja die Idee, zusätzlich ggfs. optional den Wert zu validieren. Also sprich ist es true oder false.
-
@sruhsam hi,
Ich verstehe deine Frage nicht ganz. Ich mache es wie folgt, steuern tue ich die Anlage über den list state und wenn die Anlage auf Einbruch geht, lasse ich über diesen ein Widget erscheinen mit dem ich die Anlage mit Pin deaktivieren muss.
-
@Mike-Weber ich habe ca. 30 dieser Kontakte im Einsatz und konnte das nicht feststellen. Wie gesagt, ich habe eben nochmal im Code geschaut es wird definitiv nur getriggert wenn der Wert sich ändert. Dies war nämlich einer der ersten Änderungen die ich nach dem Initial gemacht habe.
-
Hallo, erstmal ein dickes Lob an den Entwickler dieses Adapters. Ich verfolge hier nun ca. seit Version 0.7 und testete bisher nur im Hintergrund mit. Jetzt wollte ich aber produktiv gehen, und da ist mir ein kritischer Bug (Backdoor) aufgefallen. Folgendes Szenario in Version 1.2.3 ...
.........................................- aktiviere mit "Enable" oder " Enable with delay" - Alarmanlage ist jetzt scharf
- klicke schnell nacheinander "Enable with delay" dann sofort "Enable" dann sofort "Enable with delay" - Alarmanlage deaktiviert sich, DARF NICHT PASSIEREN
So kann jeder deaktivieren der eigentlich nur "Einschaltbuttons" sieht.
...........................................
Desweiteren sollte der Countdown der Funktion "Enable with delay" gelöscht werden sofern man diese Funktion/den Alarm , während des Countdowns, dann doch noch per "Enable" einschaltet.
...........................................
Und perfekt wäre es, wenn der Countdows nach dem runterzählen nicht mehr auf "0" steht, sondern nach der null nur eine leere Stelle anzeigen würde. So sieht man keine unnötige Zahl ("0") im GUI wenn der Countdown nicht mehr aktiv ist. -
@blauholsten
Hallo Danke für Deine Antwort ...
mach ich genauso, habe auf meinem VIS die Buttons "scharfschalten verzögert", "innen scharf" und "Nachruhe". Mit diesen Buttons steuer ich den DP use.list "enable with delay(3)", sharp inside(2) oder night rest(4).mit einem PIN-Pad gebe ich bei gültigem PIN den DP use.list auf disabled(0) aus, somit geht die Anlage -egal aus welchem Zustand- auf "unscharf".
Soweit so gut. Wenn nun aber die Anlage "scharf" ist, kann diese ja auch ohne PIN auf den Zustand "Nachtruhe" geschaltet werden. Hier hätte ich gedacht, dass es doch Sinnvoll ist, dass wenn die Anlage "scharf" ist, nur ein "unscharf" möglich sein sollte, um genau dies zu verhindern. Somit wird verhindert, dass ein umschalten aus dem Zustand "scharf" ohne PIN nicht möglich ist.
Und jetzt ist mir auch mein Denkfehler klar geworden. Wenn die Anlage scharf ist, und ein Einbrecher löst den stillen Alarm aus, und schaltet dann durch den Button auf den Zustand Nachtruhe, wird aus dem stille Alarm trotzdem ein normaler Alarm, da immer die Ursache der Auslösung Priorität hat.
Vielleicht ist aber trotzdem das mit dem Zwang des "unscharf" schaltes aus dem Zustand "scharf" eine gute Idee ???
Gruß
Stephan -
@blauholsten Danke Dir. okay. dann muss ich mir etwas anderes überlegen.
-
@Mike-Weber im debug Log sollte man das aber erkennen können, ich könnte mir nur vorstellen, dass die states kurz auf null und dann wieder auf den alten wert gesetzt werden???
-
@blauholsten ja, das kann sein, tritt auch nur bei der nicht IP-Serie auf, ich habe jetzt mal das Debug Log aktiviert. Sobald es erneut auftritt melde ich mich. Die Geräte zu tauschen, wäre ja auch kein Problem. Ich dachte nur, dass es dennoch sinnvoll ist, nicht NUR bei Änderung auszulösen, sondern den State, also true oder false zu "checken". Oder wird dies schon gemacht.
-
@blauholsten wobei was echt komisch ist, das im Debug Log die ganze Nacht folgende Änderungen protkolliert werden, dies der Fenster- und Türkontakte.
Beispiele:
War defintiv keiner wach.
Anlage löst aber auch nicht aus.
2020-08-04 01:59:01.099 - debug: alarm.0 (13231) state hm-rpc.2.0023DA49A3CE1C.1.STATE changed: 0 (ack = true)
2020-08-04 03:00:37.554 - debug: alarm.0 (13231) state hm-rpc.1.0007D8A98BB18F.1.STATE changed: 0 (ack = true)
