Umfassendes Alarmanlagen-Skript
-
Cool, vielen Dank für euer Feedback!
Ich möchte kurz Feedback geben zu den Punkten:
@Tirador
Solche Dinge passieren, wenn von einem scharf-Zustand auf einen anderen scharf-Zustand geschaltet wird, in deinem Fall direkt von scharf extern auf scharf intern. Ein Rückesetzen wird immer nur beim Schalten auf unscharf durchgeführt (auch die Texte stimmen nur so). Ich wollte das vorerst nicht per Programmierung sperren. Jetzt mit der Möglichkeit über den Number-Datenpunkt zu schalten passiert das natürlich noch leichter. Sollte ich das Abfangen im Code? Was soll dann aber passieren?- Ah, super - ich hab mich gefragt, ob etwas gibt, die Intanz abzufragen, aber dann nicht mehr nachgesehen - Danke!!
- OK, ich werd Rollen mitvergeben.
- Subscription auf Rollen ist auch cool. Ich muss zugeben, dass ich mich mit Rollen bisher kaum auseinander gesetzt habe. Das würde die Pflege deutlich vereinfachen. Kann ein Melder auch mehrere Rollen haben? Oder wie kann ich sonst damit umgehen, dass ein Melder gleichzeitig zB die Außenhaut-Rolle haben kann UND auch ein verzögerter Melder sein kann?
LG Andreas
-
@Homer-J
Ah - das kann nur amchange: "any"liegen bei der Melderauswertung. Du hast Sensoren, die ein regelmäßiges Update liefern, oder? Das war auf jedenfall ein Fehler. Das periodische Aussenden der Zustände ist ja eh gang und gäbe, keine Ahnung warum ich das so gemacht hab. Ich stelle es um auf
change: "ne"Auch beim richtigen Setzen des AlarmText passt noch etwas nicht übrigens.
-
@andreaskos ich habe alles Homematic und Homematic ip. Hab jetzt mal any gegen ne getauscht.
Weißt du was auch noch cool wäre, du schreibst ihr baut auch telenot Alarmanlagen die habe ich auch bei mir im Büro, die kann man ja über Chip aktivieren deaktivieren kannst du das vielleicht mit einbauen das wäre mal richtig genial.
Ich nutze jetzt schon einen RFID Reader. -
Hab es erneut angepasst. change "ne" bei der Melderauswertung und ein paar kleine Korrekturen, u.a. für die Textausgabe bei AlarmText
-
@andreaskos Natürlich kann ein Datenpunkt mehrere Rollen haben. Zum Beispiel haben meine Bewegungsmelder die Rollen
- Sicherheit - zur Abfrage in der Alarmanlage und für andere sicherheitsrelevante Skripte (Wassermelder, Funkschlüssel, etc.)
- Alarmanlage_innen und Alarmanlage_aussen - zur genaueren Abfrage in der Alarmanlage (Hülle und innen oder bei dir extern und intern)
- Batterie betrieben - zur Abfrage im Batterieskript
Ich benutze noch die Rollen (oder in ioBrokerAdmin "functions" genannt) "Taster", "PIR", "Schalter", "Fernbedienung", "Wassermelder", "Briefkasten"
Dadurch lassen sich einzelne Geräte direkt einer Funktion zuordnen. Das geht auch bei DIY-Umbauten. Ein für den Briefkasten umgebauter Tür-Fenster-Kontakt soll nicht in der Alarmanlage ausgewertet werden, nur weil er ursprünglich Tür- und Fensterzustände melden sollte.
Dazu gibt es noch den Raum, um weiter spezialisieren.
Pix
-
Ah - ok. Ja, mit Functions hab ich schon mal gearbeitet, verstehe!
Die Melder würden eh wie bei dir in Außenhülle und Innenraum unterschieden, extern und intern ist ja nur der Schaltzustand, das ist nicht das gleiche.
Danke für diese Hinweise!
-
Steuerung
"Solche Dinge passieren, wenn von einem scharf-Zustand auf einen anderen scharf-Zustand geschaltet wird, in deinem Fall direkt von scharf extern auf scharf intern. Ein Rückesetzen wird immer nur beim Schalten auf unscharf durchgeführt (auch die Texte stimmen nur so). Ich wollte das vorerst nicht per Programmierung sperren. Jetzt mit der Möglichkeit über den Number-Datenpunkt zu schalten passiert das natürlich noch leichter. Sollte ich das Abfangen im Code? Was soll dann aber passieren?"
Ich denke das gehört zur vernünftigen Steuerung dazu, dass solche "Zwischenzustände" nicht existieren.
Grundsätzlich ist ein "Zurücksetzen" des Alarms ja pinzipbedingt nicht verkehrt. Technisch sollte es aber unterbunden sein, dann den Zustand auf einen anderen ALARM-Modus zu setzen. D.h. es müsste eine Fehlermeldung geben, wenn man den Modus intern/extern scharf wechselt und es existiert ein ALARM.Redundante Datenpunkte
Grundsätzlich würde ich es begrüßen, wenn Du die redundanten Datenpunkte/States wieder aus dem Skript entfernst, um zusätzliche "Klarheit" zu schaffen. D.h. durch den Switch gibt es ja alle Möglichkeiten der Steuerung. die folgenden Datenpunkte könnten entfernt werden:
Das gilt natürlich analog für die Ausgabe-Datenpunkte. Ich sehe darin keinen Mehrwert (auch für eine VIS-Aufbereitung nicht).
Räume/Funktionen
Die Idee mit den Rollen/Funktionen fände ich auch Klasse. Das ermöglicht ausserdem später die Ausgaben nochmal anders aufzubereiten, d.h. an der Zuteilung der Räume und Funktionen selbst ist eine Ausgabe für VIS später möglich.
Als Orientierung wie man das umsetzt verweise ich mal auf das Fensterskript von Pitini, welches ähnliche Optionen bietet (d.h. den Fenstern werden Funktionen und Räume zugeordnet). Das Skript stellt eine Liste der offenen Fenster als HTML-Tabelle für VIS zur Verfügung. Das könnte ich mir analog für das Alarm-Skript vorstellen, um zu erkennen welcher Sensor angeschlagen hat. -
OK, dann versuche ich, das wechseln der Schaltzustände von scharf intern auf scharf extern (oder umgekehrt) zu verhindern. Ich würde aber dann auch ohne anstehenden Alarm den Wechsel verbieten. Der Error "Fehler bei der Scharfschaltung" sollte dann ja auch dafür verwendet werden können.
Der Ursprung der drei boolschen Datenpunkte für die Schaltzustandseingabe- und -anzeige ist das KNX Sicherheitsmodul von ABB, mit dem ich schon oft gearbeitet hab und es damit auch liebgewonnen hab.
Ich verwende diese Datenpunkte dabei am liebsten. Der Mehrwert im Falle des ioBroker-Skripts besteht darin, dass diese zum Beispiel ganz einfach mit einer Code-Tastatur (oder sonst einer Hardware-Schaltstelle), die true/false liefert, verbunden werden können. Einfach, indem die beiden States mit einer Subscription gekoppelt werden. 2 Codes für extern und intern (d.h. jeweils ein Relais, das anzieht) - fertig.
Genau auf diese Art könnte auch der Wunsch von @Homer-J umgesetzt werden, wo er schreibt:telenot Alarmanlagen die habe ich auch bei mir im Büro, die kann man ja über Chip aktivieren deaktivieren kannst du das vielleicht mit einbauen das wäre mal richtig genial.
Ebenso verwende ich die Ausgabe-Datenpunkte, für zB true/false Status-Anzeigen. Insofern sind sie nicht tatsächlich redundant. Nur eine zusätzliche Möglichkeit für die Schaltzustandseingabe und -anzeige. Ich verwende kaum eine Visualisierung dafür.
Was die Liste der Melder angeht, so würde ich nach meinem Gefühl eher auf einen JSON-String setzen, das ist noch universeller als HTML. Daraus kann man sich dann ja eine beliebige HTML-Struktur erstellen für seine eigene Visu.
Danke mal wieder für die Inputs @Tirador ! - Die Arbeit geht mir also nicht aus...
LG Andreas -
OK, die nächste Version ist da:
- Die Melder werden aus den ENUMs geholt, by default von diesen:
"Alarmanlage_Aussenhaut"
"Alarmanlage_Innenraum"
"Alarmanlage_Verzoegert" - Direktes Wechseln von einem Scharf-Zustand zu einem andern wird verhindert.
- Instanz muss nicht eingegeben werden, sondern kommt von der Variable instance
Nächstest ToDo: Ausgabe der ausgelösten Melder in 3 JSON-Strings, einmal alle Melder, einmal nur Außenhaut und einmal nur Innenraum-Melder.
- Die Melder werden aus den ENUMs geholt, by default von diesen:
-
@andreaskos Hallo Andreas kannst du mal bitte ein Beispiel Arrays für die Melder mit ins Script packen, hab jetzt schon einiges Probiert bekomme es aber nicht ans laufen. Danke
Grüße
-
Hi! Du brauchst keine Arrays mehr anlegen im Skript, das wurde mit der letzten Version geändert.
Einfach drei Aufzählungen anlegen. Dazu gehst du im ioBroker-Admin auf Aufzählungen. Falls die in der Auswahl links nicht angezeigt werden, dann kannst du sie einblenden.
Dort dann die drei neuen Aufzählungen unter "Functions" (Funktionen) anlegen und die States einfügen deiner Sensoren.
Achtung auf die Groß/Kleinschreibung bei der id!
Hast du das gemeint? -
@andreaskos
Hab es musste nur die Funktion neu anlegen.Kleiner Fehler in deinem Script ist mir noch aufgefallen. Soll sicher Innenraum heißen.
const functionIndoor = "Alarmanlage_Inneraum";Beim Bewegungsmeldern sollte doch eigentlich nur Motion Triggern oder. ?
man muss die Funktion per Hand anlegen und nicht über die CCU dann geht es.
Wieder Klasse Arbeit von dir.
-
Danke für dein Feedback @Homer-J !
Ja - klassischer Copy-Paste-Fehler, sorry. Innenraum sollte es heißen, genau. -
Hi @Tirador hab jetzt meine Vis auf das Script angepasst nochmal Vielen Dank an Andreas für die Umsetzung.
Funktioniert hervorragend.
Hab noch meine Pineingabe mit integriert.
Hier mal 2 Screenshots wie meine Vis jetzt Aussieht.
Sag Bescheid ob du es haben willst dann stelle ich alles hier ein.Grüße
Hier meine Alarmanlage als Vorlage.
Bitte die einzelnen View genau so anlegen wie die Textdatei heißen dann sollte es sofort funktionieren ansonsten alles an die eigene Struktur anpassen.
Voraussetzung ist das [Projekt] MDCSS v2: Material Design CSS Version 2 von Uhula.
Für die Pineingabe das Blocklyscript ist auch dabei und angepasst, es muss nur der vierstellige Pin im Datenpunkt PW_Auswertung eingegeben werden.Viel Spaß.
-
-
@Homer-J sagte in Umfassendes Alarmanlagen-Skript:
Viel Spaß.
Alarmanlage.rarDanke, wollte es auch mal testen, aber da fehlen einige Pages im Rar?
-
Morgen @sigi234 war mir was durchgerutscht, hab ich ergänzt sollte jetzt alles da sein.
-
@Homer-J sagte in Umfassendes Alarmanlagen-Skript:
Morgen @sigi234 war mir was durchgerutscht, hab ich ergänzt sollte jetzt alles da sein.
Ok, da gibt es noch einen Fehler bei der cardAlarmanlageFenster:
-
@Homer-J sagte in Umfassendes Alarmanlagen-Skript:
es muss nur der vierstellige Pin im Datenpunkt PW_Auswertung eingegeben werden.
Wo?
-
@sigi234 wo die 2054 steht dort deinen gewünschten Pin eintragen.
Es kann sein das ich die Fenster gruppiert habe löse diese mal auf, dann sollte es gehen.
Hab die Gruppierung jetzt raus genommen.
