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

[andreaskos]

Danke für dein Feedback @sigi234

Das Skript soll ja nur die Alarmanlage abbilden. Auf welche Art die Scharf- oder Unscharf-Schaltung erfolgt, obliegt dann dem User. Das heißt, wie die Datenpunkte angesprochen werden, ob über eine Code-Eingabe, eine Zeitschaltuhr oder andere kreative Ideen (zB in Abhängigkeit der Anwesenheit) ist nicht Teil davon.

Betreffend der Namen müssen diese eben in ioBroker gepflegt werden. Ich wollte so wenig Eingaben wie möglich haben, deshalb dieser Weg. Ein Alias-Name wäre dann eine zusätzliche Eingabe. Natürlich möglich, aber ioBroker bietet diese Möglichkeit ja schon von sich aus.

Die ausgelösten Sensoren als JSON-String zur Verfügung zu stellen find ich super! Ich nehme es mal in meine ToDo-Liste auf. Ebenso, dass zusätzlich je eine getrennte Liste für Außenhaut und Innenraum-Melder geführt wird.

[andreaskos]

Ich habe einmal die Idee von @Homer-J eingearbeitet. Es gibt jetzt je zwei Number-Datenpunkte:

Input.SwitchNumber gibt die Schaltzustände ein wie folgt:
0 ... unscharf schalten
1 ... scharf intern schalten
2 ... scharf extern schalten
3 ... verzögert scharf extern schalten

Output.ActiveNumber gibt Auskunft über den tatsächlichen Zustand mit den Ziffern:
0 ... unscharf
1 ... intern scharf
2 ... extern scharf
3 ... Eingangsverzögerung aktiv
4 ... Ausgangsverzögerung aktiv

Es werden dafür die eingebenen Texte unter Einstellungen am Anfang des Skripts benutzt.

[Homer.J.]

@andreaskos funktioniert mit der Homeapp :+1: leider sind aber die Nummer vertauscht deswegen hatte ich 1 als extern scharf und 2 als intern scharf kann ich das für mich selber anpassen. ?
Hab es für mich angepasst und funktioniert Klasse.
Danke für das schnelle umsetzen.

[Tirador]

Sehr schönes Skript. Ich finde es auch gut, wenn nicht alle Funktionen hier integriert sind, sondern wirklich nur die Kernfunktionen einer Alarmlösung.

Für die Benachrichtigung bei Alarm oder fehlerhaften Scharfschalten etc. Zum Beispiel in der VIS Oberfläche, per Licht, telegram oder Email verweise ich Mal auf den MessageHandler:

https://forum.iobroker.net/topic/32207/script-messagehandler-nachrichten-protokollieren-vis

Eine Integration sollte durch die Datenpunkte dieses Skripts prima durchführbar sein.

[Tirador]

Ich habe das Skript nun installiert und teste gerade etwas herum:

Folgendes ist mir noch unklar (siehe Bild dazu unten):

• Output State "alarm" steht auf true, obwohl State AlarmText = "Alles OK" (Meine Vermutung ist, dass die Zustände nicht zurückgesetzt werden, wenn ein vorheriger Alarm eingetreten ist)
• Datenpunkt Input "SwitchNumber" ist 1, Output der "ActiveNumber" ist aber 2

Ich habe übrigens im Nachrichtenskript angefangen Nachrichten für dieses Alarmanlagenskript zu ergänzen:

[Homer.J.]

@andreaskos kannst du vielleicht noch Fenstergriffe mit einarbeiten wo der Status mit Zahlen ist,
0 geschlossen, 1 gekippt, 2 geöffnet.
Funktioniert auch so hat sich also erledigt.
Grüße

[Tirador]

@Homer-J hast du dein MDCSS Alarmanlagenview auf dieses Skript bereits angepasst?

Ich meine dieses hier:

https://forum.iobroker.net/topic/19970/suche-alarmanlagen-views/43

Kannst du vielleicht die neueste Version bereitstellen?

[Homer.J.]

@Tirador bin gerade beim anpassen, wenn es fertig ist kein Problem.

[Tirador]

@Homer-J das wäre prima.

[pix]

Hallo,

tolle Arbeit, super Skript. Werde wohl demnächst mal mein altes Skript von 2016 ersetzen.

Ich habe einige Vorschläge zum Skript:

• die Javascript Instanz lässt sich durch instance abfragen. createState() darf eh nur in der Instanz, in der das Skript läuft States anlegen (und im neuen 0_userdata-Pfad)
• Bitte beim Anlegen von Datenpunkten auch Rollen vergeben (Liste möglicher Werte).
• die Ausgabe des Sensor Namens hast du über common.name schon realisiert ("Die Namen der Melder sollten gut gepflegt sein"). Es gibt aber sehr viel mehr Infos im Objekt, die man ausgeben könnte

on({
    id: idTrigger,
    change: "ne"
}, function(obj) {
        log("obj.id " + obj.id);
        log("obj.name " + obj.name);
        log("obj.deviceName " + obj.deviceName);
        log("obj.deviceId " + obj.deviceId);
        log("obj.channelId " + obj.channelId);
        log("obj.channelName " + obj.channelName);
        log("obj.common.name " + obj.common.name);
        log("obj.common.desc " + obj.common.desc);
        log("obj.state.ts (formatiert) " + formatDate(obj.state.ts, "TT.MM.JJJJ SS:mm:ss"));
});

Ist die Subscription von Rollen nicht geplant? So kann man leicht zB alle Bewegungsmelder eines Raumes oder die Tür-Fenster-Kontakte auf einmal überwachen, die z.B. einer Rolle "Alarmsensoren_Aussenhaut" zugeordnet sind. Das reduziert die Wartungsarbeit beim Wechsel von Sensor-Hardware.

const motion_kizi = $("channel[state.id=*.MOTION](rooms=Kinderzimmer)");
motion_kizi.on(function(obj){
    if (obj.state.val && (getState(idAlarmanlage).val === 1 || getState(idAlarmanlage).val) ) { // wenn Alarmanlage ein
       setState("scene.0.licht_kinderzimmer_alles_ein", true);  // alle Lichter an
       // weitere Aktionen
   }
});

Top Arbeit :+1:
Pix

[Homer.J.]

Hi @andreaskos hab jetzt mal meine komplette Anlage umgestellt irgendetwas passt da noch nicht, wenn ich jetzt meine Alarmanlage aktiviere dauert es nicht lang das irgendein Kontakt auslöst obwohl sich kein Status verändert hat soll heißen es wurde weder ein Fenster geöffnet noch ging ein Bewegungsmelder.
Es wir aber komischerweise in dem Datenpunkt Alarming Detector genau der auslösende Kontakt angezeigt obwohl sich nichts ändert.

[andreaskos]

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?

@pix

• 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

[andreaskos]

@Homer-J
Ah - das kann nur am

change: "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.

[Homer.J.]

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

[andreaskos]

Hab es erneut angepasst. change "ne" bei der Melderauswertung und ein paar kleine Korrekturen, u.a. für die Textausgabe bei AlarmText

[pix]

@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

[andreaskos]

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!

[Tirador]

Steuerung

@andreaskos

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

[Vorlage] Generisches Fensteroffenskript + Vis

[andreaskos]

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

[andreaskos]

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.