Hallo zusammen,

ich möchte gerne ausführlich das Rauchwarnmeldekonzept vorstellen, das ich zu Hause in Betrieb genommen habe und das mich voll überzeugt

Problemstellung:

1. Ich fühle mich nur sicher, wenn die RWMs kabelgebunden angeschlossen sind.
2. herkömmlich vernetzte RWMs (also alle RWMs mit gemeinsamer 2-Draht-Leitung) bringen mir den Alarm zwar auch ins Schlafzimmer, wenn im weit entlegenen Keller Rauch erkannt wird, aber was nutzt es schon, dass im ganzen Haus die RWMs piepsen ohne einen Hinweis auf den ursächlichen Raum ... Da landet man dann schnell bei teuren "boxed Lösungen" der Hersteller mit zentralem Bedienpanel - Und das dann meist auch wieder als Funklösung, was ich bei RWMs für unpassend halte.
3. was nutzt mir ein zentrales Bedienpanel, wenn ich ein oder zwei Stockwerke davon entfernt schlafe?
4. die RWMs sollten automatisch überwacht werden - Eine regelmäßige "Keep-Alive"-Prüfung wäre wünschenswert.
5. einigermaßen hübsch aussehen wäre auch toll
6. ...

Man findet sicherlich noch viele weitere Anforderungen, die ich mir einzelnen hier gar nicht bewusst machen will - Auf jeden Fall bin ich mit der nachfolgenden Lösung rundum zufrieden

Meine Lösung basiert auf:

• ioBroker
• Gira Dual-Q RWM, ArtNr 233602: https://katalog.gira.de/de_DE/datenblatt.html?id=636871 (ca. 35€)
• Gira KNX-Modul für RWM, ArtNr 234300: https://katalog.gira.de/de_DE/datenblatt.html?id=636879 (ca. 75€)

Damit nun der Alarm scharf pro getrenntem Raum gemeldet werden kann, würde man natürlich pro RWM auch jeweils ein KNX-Modul benötigen. Mein Traum (der sich erfüllte) war dabei u.a. die Kostenreduktion: Pro RWM mit KNX-Modul kann an der 2-Draht-Klemme des RWM ein weiterer RWM betrieben werden, der dann "dumm" ohne KNX-Modul ausgestattet ist. Beide Signale (lokaler Alarm und entfernter Alarm über 2-Draht-Klemme) können am KNX-Bus später unterschieden werden, um die Quelle des Alarms zuzuordnen.

Was bedeutet dies für die Kosten: Nun ja, die o.g. 35€ für den Gira-RWM sind ja vergleichbar zu anderen RWMs (jedenfalls solange man die "Q-Zertifizierung" voraussetzt).
Der Aufpreis für diese Lösung ist also alleinig das KNX-Modul - Und durch den Trick "ein Modul pro zwei RWMs" schlägt das KNX-Modul so gesehen "nur" mit dem halben Preis pro RWM-Anbringstelle zu Buche.
Fazit: Die Lösung kostet als Aufpreis gegenüber einer "dummen" Q-zertifizierten Lösung schlicht 37,50€ pro Anbringstelle mehr - Damit kann ich gut leben.
(Okay: Wer noch kein KNX hat, muss sich wohl noch das KNX-Netzteil mit IP-Gateway gönnen, aber das ist keine echte RWM-Investition, sondern allgemeine KNX-Infrastruktur.)

Wer KNX immer als überteuert abtut, sollte zum Vergleich das Homematic Einsteigerset heranziehen: 4 RWMs + Zentrale kosten bei ELV aktuell 230€ - Bei 4 RWMs komme ich mit dieser KNX-Lösung auf 4x35€ + 2x75€ = 290€, was meiner Meinung nach ein überschaubarer Aufpreis für eine verlässliche kabelgebundene Lösung ist.

Nun habe ich im gesamten Haus bereits die MDT "Glastaster Smart II", ArtNr BE-GT2* ( https://www.mdt.de/Glastaster_Smart.html ) verbaut, auf denen man Text-Meldungen signalisieren kann. In diesem Zusammenspiel (Gira-RWM + MDT-Glastaster-Smart-II) bin ich der Meinung, dass man alle erdenklichen RWM-Anforderungen elegant lösen kann:

• Am Glastaster sieht die KNX-Konfiguration wie folgt aus:
  
  

• Am KNX-RWM sieht es wie folgt aus:
  
  

• passende KNX-Gruppenadressen:
  
  (Man sieht leider, dass ich am RWM "Niclas" die 2-Draht-Klemme nicht genutzt habe - Ungenutzte 2-Draht-Klemmen verteuern das Konzept natürlich ungewollt ...)

• Dazu noch ein ioBroker-JavaScript:

var Prefix = "knx.0.Hauptgruppe.Rauchwarnmelder";
var AlarmTypes = ["Rauch","Wärme","Draht","Störung"];

AlarmTypes.forEach(function(AlarmType) {
    var LogOutput = "";
    var Count=0;

    $(Prefix + '.*' + AlarmType + '*').each(function(ObjID) { //Enumerieren der KNX-Geräte, die zum AlarmType passen
        var Ort = ObjID.replace(Prefix + '.', '').replace('_' + AlarmType, '');
        if (AlarmType=="Draht") {
            var NebenOrtOffset = Ort.indexOf('-');
            if (NebenOrtOffset!=-1) {Ort = Ort.substr(NebenOrtOffset+1) + " (" + Ort.substr(0, NebenOrtOffset) + ")";}
        }
        Ort = (Ort + " " + AlarmType).replace("_", " ");

        on({id: ObjID, change: "ne"}, function (obj) {
            if (obj.state.val) {
                var iconv = require('iconv-lite');
                setStateDelayed('knx.0.Hauptgruppe.System.Textmeldung', iconv.encode(Ort, "ISO-8859-1"), false, 0, false);
            } else {
                setStateDelayed('knx.0.Hauptgruppe.System.Textmeldung', "", false, 0, false);
            }
        });

        Count++;
        LogOutput += Ort + ", "
    });

    if (Count>0) {LogOutput = LogOutput.substr(0, LogOutput.length-2);}
    console.log("registerd " + Count + " RWM-Events for Alarmtype='" + AlarmType + "' (" + LogOutput + ")");
})

Das ioBroker-JavaScript registriert beim Starten des ioBrokers einmalig die Änderungs-Ereignisse der KNX-RWM-Status-Signale und unterscheidet dabei zwischen:

• lokalem Rauchalarm
• lokalem Wärmealarm
• Alarm von Nebenstelle an 2-Draht-Klemme
• Störung

Falls eine solche Status-Änderung eintritt, wird eine passende Meldung in das Text-Objekt "knx.0.Hauptgruppe.System.Textmeldung" geschrieben - Da dieser Text von allen Glastastern wahrgenommen und direkt dargestellt wird, habe ich den Ursprung des Alarms überall im Blick - Inkl. optimalem WAF, wie mir meine Holde bestätigte.

Am MDT-Glastaster sieht es dann wie folgt:

Handelt es sich also um einen entfernten Nebenstellenalarm per 2-Draht-Klemme, so wird der Ort der Detektion (hier "Bad") genannt und gleichzeitig wird der KNX-RWM in Klammern genannt, an dem die verantwortliche 2-Draht-Klemme mit der KNX-Welt verbunden ist. Das abschließende "D" heißt in der kompletten Text-Meldung "Draht", weil es sich eben um einen Alarm über die Draht-Klemme handelt. Leider schneiden die MDT-Glastaster schon nach 14 Zeichen ab .. ;-(
(Okay - Nicht lachen ... Die Anbringung eines RWMs im Bad ist zugegebener Maßen wirklich als sehr optional einzustufen ... Jedenfalls gab es beim Duschen noch keine Fehlalarme, da das Bad recht groß ist.)

Neben den Suffixen "Rauch" und "Draht" ist auch "Wärme" oder "Störung" möglich - passende Fotos spare ich mir hier,

Zusätzlich gibt es ein weiteres-Script, das bei jeder Text-Änderung automatisch eine E-Mail versendet - Ich werde also auch unterwegs gewarnt, wenn ich gerade nicht auf einen Glastaster schauen kann.

Ach ja: Thema "Keep alive" ist auch erledigt.
Im o.g. Screenshot senden die KNX-RWMs pro Tag eine Temperatur an den KNX-Bus. Ein weiteres ioBroker-JavaScript versorgt mich mit einer Text-Nachricht, falls das Temperatur-Update eines RWMs ausgeblieben ist. Okay: Zugegebener Weise habe ich somit kein "Keep alive" von den RWMs, die per 2-Draht-Klemme angeschlossen sind.

Und sollte mein zentraler ioBroker mal unerwartet ausfallen (was noch nie geschehen ist), werden trotzdem alle RWMs piepsen, weil KNX als dezentrales System ja weiterhin funktioniert - Allerdings wird der Text auf den Glastastern fehlen ...

Zusätzlich hat man ein Signalisierungsinstrument mit eingekauft: Sendet man an die Gruppenadresse "RWM Signal" oder "RWM Alarm" ein entsprechendes KNX-Telegramm, so gibt es zwei unterschiedliche Töne im gesamten Haus.

Wer den Verkabelungsaufwand nicht scheut und (genauso wie ich) eine kabelgebundene Brandmeldeanlage wünscht, ist meiner Meinung nach mit diesem Konzept optimal beraten und bleibt mit seinem Budget erstaunlicher Weise in Reichweite der Homematic-Lösung.

Re: Zeichenketten mit Umlauten an KNX senden UTF8 <-> ISO-8859

Problem gelöst - Hab's endlich hinbekommen Umlaute zu meinen KNX-MDT-Glastastern senden zu können

Wichtig ist, dass man nach dem Import des ETS-Projekts, den Datentyp auf mixed ändert - Dann funktioniert das Senden der Umlaute über den iconv-Weg (siehe alte oben verlinkte Topic).

Bei mir existiert nun in den JavaScript-Objekten ein State vom Typ String - Sobald irgendeine Quelle hier eine Nachricht reinschreibt, propagiere ich diese Nachricht mit dem folgenden Skript an alle gewünschten Ziele (eMail, What'sApp, KNX):

var Msg = "javascript.0.variables.NotifyMessage";
var KnxMsg = "knx.0.Hauptgruppe.System.Textmeldung";

if ($("state[id=" + Msg + "]").length == 0) { 
    createState(Msg, "", {"type": "string", "read": true, "write": true, "def": ""});
    console.log("Created variable to save messages for Notify-Events (" + Msg + ")");
}

on({id: Msg, change: "ne"}, function (obj) {
    if (getObject(KnxMsg).common.type != "mixed") {
        console.error("State for saving KNX-Messages has wrong datatype (" + getObject(KnxMsg).common.type + "). Remember to change datatype into 'mixed' after importing ETS-Project! Otherwise KNX will not receive any notifications!");
    }

    var value = obj.state.val;
    if (value) {

        // Send E-Mail-Notification
        var firstline = (value.indexOf("\n")==-1) ? value : value.substring(0,value.indexOf("\n"));
        sendTo("email", "send", {
            to: "<E-Mail-Recipient>",
            subject: ("ioBroker: " + firstline),
            text: value
        });

        // Send What's-App-Notification
        // To active CallMeBot send "I allow callmebot to send me messages" to "+34 644 263377" via What's-App. CallMeBot will return API-Key after activation.
        var recipients = {};
        recipients["+49...WhatsAppHandyNr1"]="API-Key for WhatsAppHandyNr1";
        recipients["+49...WhatsAppHandyNr1"]="API-Key for WhatsAppHandyNr2";
        for (var recipient in recipients){
            var request = require('request');
            var options = { url: "https://api.callmebot.com/whatsapp.php?phone=" + recipient + "&apikey=" + recipients[recipient] + "&text=" + encodeURIComponent(value),
                            method: 'GET',
                            headers: { 'User-Agent': 'request' }
                          };
            request(options)
        }

        // Send KNX-Notification
        if (getObject(KnxMsg).common.type == "mixed") {
            var iconv = require('iconv-lite');
            var output = iconv.encode(value + String.fromCharCode(0), "ISO-8859-1");
            setStateDelayed(KnxMsg, output, false, 0, false);
        }
   
    } else {

        // Clear KNX-Notification
        if (getObject(KnxMsg).common.type == "mixed") {
            setStateDelayed(KnxMsg, "", false, 0, false);
        }

    }

});

Bitte die Zeilen

• #2 (Hier steht das KNX-Objekt, das Eure KNX-Aktoren abonnieren. Es wird nach dem ETS-Projektimport vom Typ '''string''' sein. Das vorstehende Skript wirft dann bei jedem Meldungsversand einen Fehler, dass man den Objekt-Typ manuell auf mixed ändern soll.)
• #20 (E-Mail-Empfänger hinterlegen - Dazu muss der Adapter "email" installiert sein)
• #28- #29 (Liste von What's-App-Empfängern hinterlegen)

nach Euren Vorgaben anpassen.

Ich habe frisch den aktuellen ioBroker mit KNX 2.0.17 installiert - Bin dabei natürlich auch auf das Verzögerungsproblem gestoßen. Dazu hier ein "tail -f" des ioBroker-Logs, nachdem ich den KNX-Log-Level auf "ultra verbose" gesetzt habe:

• 09:14:08 Uhr: Wiederkehrender KeepAlive des KNX-Adapters (kommt wohl alle 10 Sekunden)
• 09:14:13 Uhr: Switch-State manuell geändert
• 09:14:18 Uhr: Senden des Telegramms mit neuem Switch-State durch den KNX-Adapter (5 Sekunden später)

Gerne das Ganze auch hier als Video: KNX-Verzögerung.mp4 (Man sieht den fortlaufenden Protokoll-Output, während ich den Switch-State in der ioBroker-GUI ändere.)

Die Verzögerung bei mir liegt normalerweise zwischen 1...9 Sekunden - Das hier vorgeschlagene Downgrade auf 2.0.13 löst das Problem.

Vage Vermutung: Wenn ich den Switch-State kurz vor einem KNX-KeepAlive sende (der ja alle 10 Sekunden kommt), habe ich nur eine kurze Verzögerung. Wenn der nächste KeepAlive aber noch lange hin ist, wartet der Adapter scheinbar das Senden ab, bis der nächste KeepAlive ansteht!? (PS: schon komisch, dass das Telegramm genau dann rausgeht, wenn um 09:14:18 Uhr der nächste KeepAlive stattfindet, oder?)

@chefkoch009 Das Problem wird schlimmer - Mein o.g. iConv-WorkAround funktioniert seit den letzten ioBroker-Updates nicht mehr!

Die ioBroker-Loggings warnten ja bereits "you are assigning a object to [...] string. [...] This warning might become an error in future versions." (siehe mein Screenshot im ersten Post zu diesem Thema)

Nun hat sich das ioBroker-Verhalten (wie im Logging angedroht) geändert: Schreibe ich das Wort "Küche" mittles iConv als Object in den String, dann wird ein JSON-Ausdruck im String gespeichert, der das Object umschreibt. Tatsächlich wird dann folgende Zeichenkette zugewiesen: {"type":"Buffer","data":[75,252,99,104,101]}

Nach den Updates können folglich nur noch "echte" Zeichenketten in einem String gespeichert werden. Somit gibt es >keine< Möglichkeit mehr den Datentypen 16.001 über den ioBroker zu füttern.

Ich möchte noch einmal vorschlagen, dass der Datentyp 16.001 vom KNX-Adapter als Object importiert wird - Als Object kann man dann auch Umlaute zuweisen, die der KNX-Adapter dann richtig als ISO 8895-1 auf den Bus schreiben kann.

@chefkoch009
Tja, ich sehe ein, dass das nicht so einfach zu entscheiden ist - Von ETS-Seite aus sind es auf definitiv immer simple Strings, weswegen Deine Umsetzung auf jeden Fall ohne Frage Sinn macht.

Andererseits ist der KNX-Adapter ja auch ein Konvertierungstool in eine andere Welt (nämlich in die ioBroker-Welt) - Und bei so einer Konvertierung kann man durchaus ganz legitim zur Entscheidung kommen, dass gewisse Datentypen konvertiert werden müssen, um in der Ziel-Welt richtig verstanden zu werden.

Und wenn Du mich fragst: ioBroker sieht Strings in ISO-8859-1-Codierung nun mal als Object an - Das muss man zugegebener Weise nicht unbedingt so machen, wird aber von dieser "Ziel-Welt" so erwartet, weswegen ich zu dem Object-Ansatz tendiere.

Will sagen: Ich versuche Dich mal weiter hin- und herzureißen

@RES_DE Ja, dann gehen wir wohl beide davon aus, dass an der leeren GA liegt. Ich werde es mal mit dem Datentyp 1.002 entsprechend Deines Vorschlags probieren. Eigentlich hatte ich 1.011 (Status) gewählt weil Standard-Schaltaktoren (in meinem Fall MDT) dies genau so für Status-Objekte vorgeben und der ioBroker damit dann keine Probleme hat.

Also so ganz gelöst sehe ich den Beitrag aber noch nicht an ... Ich probiere erst einmal mit anderen Datentypen, aber wenn kein grundsätzlicher Fehler meinerseits vorliegt müsste zur echten Lösung eigentlich der KNX-Adapter angepasst werden.

@RES_DE
Ich gehe immer vor dem erneuten Importieren der KNX-Projektdatei explizit hin und lösche die gesamte knx.0.Hauptgruppe. Insofern existieren beim Import keine ioBroker Eigenschaften für diese GA.
Es handelt sich für den ioBroker beim Import um ein gänzlich neues Objekt, das faktisch ein Boolean ist und auch als solches in der ETS gekennzeichnet ist (DPT 1.011, Status) - Da wundert mich eben die Warnung

... Invalid Type! Expected "boolean", received "string"

Hier noch ein Screenshot, woraus man auch den ETS-Datentyp erkennt:

Dabei wundert es mich aber, dass die Spalte "Länge" in der ETS leer ist - Vielleicht führt dies zur Fehlinterpretation.
Aber ich wüsste nicht, wo man das in der ETS setzen kann ... Ich vermute, dass die Spalte leer ist, weil es keine verknüpften Geräte gibt.

@Tobi68 said in KNX Adapter:

Ich habe in der ETS auch noch nen Ast Baustelle und Dimmen.. die nur am Anfang mal benutzt wurden..
Das sind alles die Sachen die ich noch mit meinem KNXler bereinigen möchte..

Zum Thema "Bereinigen": Ich gehe da ehrlich gesagt immer einen etwas radikalen Weg ...
Vor jedem Import der KNX-Projektdatei lösche ich den Bereich "knx.0.Hauptgruppe" komplett rekursiv aus den Objekten.
Dann muss man allerdings unbedingt ca. 30 Sekunden warten, bis der KNX-Adapter wieder von rot auf grün wechselt, bevor man einen neuen Import der Projektdatei durchführt.

Auf diese Weise ist für mich gewährleistet, dass meine Automation immer rein basierend auf der KNX-Projektdatei funktioniert und nicht etwa zahlreiche manuelle (und vermutlich nicht dokumentierte, weil gewachsene) Nachbearbeitungen für das funktionierenden Zusammenspiel zw. ioBroker und KNX erforderlich sind.

@Tobi68 said in KNX Adapter:

@ChefSache: woher sind die Scrip/text Zeilen die du oben mit dem schwarzen Hintergrund eingefügt hattest?
Da wollte ich mich mal an nem Abend am PC einlesen, hier am Ipad habe ich da nur Bahnhof verstanden..

Dazu gehst Du einfach in Deine KNX-Objekte und klickst auf den rechts angezeigten Editier-Stift:

Im erscheinenden Bearbeitungs-Dialog klickst Du dann auf die Karteikarte "RAW (NUR EXPERTEN)"
(Die Darstellung hat dort aber i.d.R. keinen schwarzen Hintergrund - Diese Hintergrundfarbe ist nur das normale Code-Schnipsel-Style unseres Fourms)

Mal nebenbei: Wenn Du im ioBroker ganz oben auf den "Maulschlüssel" klickst, um die Haupteinstellungen einzusehen: Ist dort ein Standort eingetragen?

Ich könnte mir nämlich vorstellen, dass date() evtl. eine Null-er-Uhrzeit liefert, falls keine TimeZone festgelegt werden kann - Und ich mutmaße, dass dies anhand des Ortes der Haupteinstellung geschieht.

@geforce121 Hm, hast Du schon einmal probiert den Blockly-Teil "Aktuelle Zeit" wie in meinem Screenshot als "anwenderformatiert" zu senden? Das sollte zwar eigentlich keinen Unterschied machen, weil ja der gleiche Formatierungs-String zum Einsatz kommt, aber bei mir sendet er definitiv keine Null-er-Uhrzeit an die MDT-Glastaster.

Ansonsten wäre glatt zu vermuten, dass "Aktuelle Zeit" bei Dir nicht richtig arbeitet.
Vielleicht irgendwelche Node-JS-Probleme?

Letztendlich führt das Blockly-Puzzleteil "Aktuelle Zeit als anwenderformatiert SS:mm:ss" zu folgendem JavaScript-Code:

formatDate(new Date(), "SS:mm:ss")

Du könntest einfach mal ein neues Skript vom Typ "Javascript" (nicht Blockly) anlegen und zum Testen Deiner Umgebung ein console.log(...) verwenden. Das müsste zu dem rot umkreisten Ergebnis führen:

Falls im Log eine Null-er-Uhrzeit erscheint, stimmt etwas mit Deinem new Date() nicht.