UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[blauholsten]

@sruhsam die Zeit ist das Intervall des blitzes. Bei dir würde die Leuchte im 10min Takt leuchten

[A Former User]

@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...

[sruhsam]

@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

[blauholsten]

@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.

[sruhsam]

@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

[sruhsam]

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

[Mike Weber]

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.

[blauholsten]

@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.

[Mike Weber]

@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.

[blauholsten]

@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.

[blauholsten]

@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.

[pmaisk]

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 ...
.........................................

1. aktiviere mit "Enable" oder " Enable with delay" - Alarmanlage ist jetzt scharf
2. 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.

[sruhsam]

@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

[Mike Weber]

@blauholsten Danke Dir. okay. dann muss ich mir etwas anderes überlegen.

[blauholsten]

@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???

[Mike Weber]

@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.

[Mike Weber]

@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)

[vandermohr]

@blauholsten
Ich habe irgendwie ein Verständnisproblem mit der "Nachtruhe".
Grundsätzlich funxt der Adapter bei mir wunderbar und ich finde den richtig gut.
Alles was bei scharf ansprechen soll, aktiviere ich bei Alarmkreis.
Alles was nicht ansprechen soll (z.B. Innenbewegungsmelder, wenn man zu Hause ist und die Aussenhülle (z.B. Fenstersensoren) scharf sein soll deaktiviere ich bei Scharf innen.
Nachtruhe erlaubt ein automatisches Aktivieren in einem vorgegebenen Zeitfenster.
Aber wenn aktiv, dann spricht bei mir jeder Sensor an. Ich bin aber im Haus bei Nachtruhe und interne Bewegungsmelder sollten dann doch nicht aktiv werden. Aber wo definiere ich das?
Was verstehe ich da nicht so wirklich?
Oder wo ist mein Verständnisproblem?
Gruß vandermohr

[blauholsten]

@vandermohr nur wenn im Benachrichtigungskreis ein hacken gesetzt ist, bekommt man während der Nachtruhe eine Meldung

[blauholsten]

@Mike-Weber hi,
Aktuell sollte es so oder so nur mit true und false gehen. Der log sagt aus, dass der state aktualisiert oder ähnliches wird, von Alarm Adapter wird dies jedoch ignoriert.