Hi,

Dieses Script dient zur Steuerung von Homematic und Nicht-Homematic Heizungsthermostaten inkl Fußbodenheizungen mit Ihren Besonderheiten bei der Steuerung.

Das Script liegt jetzt in der Version 2.1 vor.

Seit der ersten Version des Heizungsscripts im April 2017 hat sich viel getan. Vieles unter der Haube.

Das Script wird auch vielfach erfolgreich eingesetzt für nicht HM-Geräte, die über FHEM in ioBroker angesteuert werden oder auch direkt über ioBroker adapter wie ZWAVE, MAX etc. HM-IP Geräte funktionieren mitterweile ebenso gut wie native Homematic Geräte - wired oder Funk.

Ihr braucht nicht den gesamten Thread durchzulesen. Vielmehr versuche ich einigermassen up to date mit der Dokumentation zu sein.

Wichtige Dinge stehen also hier im post.

Die Version 2.1 wurde ausschliesslich mit Subscriptions getestet s ( was bedeutet, dass es nur noch läuft, wenn es eine Änderung in Bedingungen gibt oder der nächste Wochenplan-Slot ansteht.) Wenn also jemand noch CRON nutzt, dann bitte melden. Evt. Fehler schaue ich mir dann dediziert an.

Ab hier werde ich auch alternative Views anbieten. Der erste View enthält 3 Profile (Danke an Kugelkopf für die Vorlage ) (Wochenplanung zum Anpassen innerhalb des Views).

Da dieser View aber sehr groß ist und nicht jeder mit Profilen arbeiten möchte habe ich den gleichen View mit nur einem Profil hochgeladen. Dies bedeutet 160 Widgets weniger aber auch weniger Komfort im Umgang mit Profilen.

Generell könnt Ihr euch die Views gestalten wie ihr wollt. Es gibt keine Script oder CSS Codings.

Was gibt es also Neues ?

2 Views ( einer mit 3 Profilen und einer mit einem Profil)

Neu zur Version 2.1

• Manuelle Aenderungen sind überarbeitet.

• Sporadisch auftauchende manuelle Temperaturen sollten jetzt gefixt sein

• Manuelle Aenderungen bleiben erhalten nach Aenderung von Profil/schedule, SoftBoost etc. bis zum geplanten Ablauf

• ICLA Aktivierung jetzt über die Views (nicht mehr ueber das Script

• Profil Selektion über ICAL komplett überarbeitet

• Globale und Raumprofile haben jetzt eine Subscription

• Mehrere gleichzeitige Profile im Google Kalender:Jetzt wird immer die höchste Profilnummer gewählt (vorher war es immer 1)

• ICAL Selektion läesst sich pro Raum ausschalten. Zwei Vorteile

• Event Profil Nummer im View braucht es nicht mehr, da jetzt alles über das aktivie Profil gesteuert wird

• Räume lassen sich von der global profil auswahl ausschliessen

• Es wird nicht immer wieder auf die ICAL Selektion zurückgestellt. Pflege alternativer Profile ist somit möglich mit anschliessender neuer aktivierung des Profils

• Ein neuer View (Herzlichen Dank an Kugelkopf für die Alternative ProfilSelektion innerhalb des Views) mit alternativer Profilselektion (max 3)

• SoftBoost jetzt möglich um über eine einstellbare Zeit einen Raum aufzuheizen (Max Temp)

• Neue Views

• View jetzt mit zusätzlichen Feldern für ICAL Aktivierung und Softboost

• View mit 3 Profilen zum umschalten

• Alternativer View mit 1 Profil - dafür kleiner (weniger Widgets)

• Die Installation der Views hat sich geändert und funktioniert jetzt über Widget Import (schneller)

• Dokumentation

• FAQs erweitert(z.B. wie ICAL aktiviert wird)

• View Installation - Beschreibung wie der View erstellt wird - (jetzt Widget Import)

Hier ist nochmal der komplette Funktionsumfang (wie in der Doku dokumentiert

! ````

• Unterstützung von verschiedenen Thermostaten o Alte HM-Wandthermostate

! o Neue HM-Thermostate (Wandthermostate und Heizkörperthermostate) o Homematic IP (Wand- und Heizkörperthermostate)
! o Unterstützung von Nicht-Homematic Thermostaten
! - Absenkung der Heizungsthermostate auf die „Fenster-Offen“-Temperatur
! - eingebundene Thermostate reagieren wie bei native Homematic mit Gruppenbildung. Manuelle Anpassungen werden erkannt und synchronisiert
! - Wochenprogramm mit bis zu 6 Zeiten/Temperaturen je Tag (Montag – Sonntag) und ein separates Feiertags-Programm (somit 8 Zeilen je Woche mit je 6 Zeiten/Temperaturvorgaben)
! - Feiertagszeile kann auch für Urlaub bei Anwesenheit genutzt werden)
! - Einfacher Verweis auf den Vortag („wie Vortag“- Funktion)
! - Möglichkeit der Planung mit bis zu 9 Profilen
! Dient z.B. für Schichtplanung oder dem einfachen Umschalten bei Ferienhäusern, etc)
! o Wochenprogramm je Profil
! o Diverse Profilparameter wie (Grad Celsius Absenkung oder Anhebung von Temperaturen und Definition einer Mindesttemperatur)
! o Aktivierung / Deaktivierung von Profilen manuell oder über Google Kalender
! - Verwendung von Raumparameter für
! o die Eingaben einer manuellen Temperatur
! o die Vorhaltezeit der manuellen Temperatur in Minuten
! o die Anzeige der Gültigkeit bis für die manuelle Temperatur o Reset der manuellen Temperatur
! o das automatische Setzen des manuellen Modus

! - Verwendung von globalen Parametern (manuell oder über Google Kalender), die für alle Räume und Profile gleich gültig sind für da
! o An/Abwesenheit, (Absenkung bei Abwesenheit)
! o Urlaub, (Absenkung bei Urlaub)
! o Party, (Absenkung bei Party)
! o Gäste (Anhebung bei Gäste)
! - Für die o.g. globalen Parameter können je Raum-Profil Temperaturanpassungen in Grad Celsius vorgenommen werden. Diese können negativ/positiv oder null sein.
! - Lieferung eines Views der rel. schnell für weitere Räume kopiert werden kann. Der View ist so aufgebaut, dass (fast) alle Eingaben per Touch bedient werden können. Der View beinhaltet für Raum und Profil das Wochenprogramm, die Profilparameter, die Raumparameter und die globalen Parameter
! - Automatisierungen
! o Findung eines Profils durch z.B. Google Kalender über ICAL
! z.B. für Schichtpläne durch Integration mit z.B. Google Kalender (ICAL)
! o Findung von Feiertagen über den Feiertagsadapter oder alternativ ICAL
! o Findung von Temperaturparameter (z.B. Gäste, Party, Urlaub Abwesend, Urlaub Anwesend etc.) durch Integration mit z.B. Google Kalender (ICAL)
! o Automatische Abwesenheitsabsenkung falls gewünscht (Integration mit einer An/Abwesenheitssteuerung)
! - Automatische Temperaturanpassungen können nicht unter eine je Raum/Profil bestimmbare Mindesttemperatur sinken
! - Automatische Einstellung des manuellen (MANU) Modus (für die neuen Thermostate)
! - Handling von manuellen Änderungen (z.B. am Thermostat oder über Alexa)
! o Erkennung von manuell eingestellten Temperaturen.
! o Einstellung der Vorhaltedauer von manuell eingestellten Temperaturen je Raum (in Minuten)
! o Darstellung der Zeit bis zu der die manuelle Temperatur gültig ist (Datum/Uhrzeit)
! o Sofortige Erkennung von Temperaturanpassung am Thermostat durch Subscription
! o Funktioniert auch ohne Direktverknüpfung
! - Verschlußsensoren
! o Temperaturabsenkung auch für nicht direkt verknüpfte Geräte
! o Sofortige Erkennung von „Verschluss offen" durch Subscription

• 3-stufiges Logging

! o Stufe 1 – Speicherung der letzten Temperaturfindung in Datenpunkte und Anzeige im View
! o Stufe 2 – erweitertes online-Logging (einstellbar)
! o Stufe 3 – Externes Logging in Excel Format (einstellbar)
! - Steuerung von separaten Wohneinheiten (z.B. Einliegerwohnung und Hauptwohnung) mit unabhängigen Parametern. (durch Kopie des Programmes und weiteren Einstellungen zur Separierung )
! Neu ab 2.0
! - Programm Trigger: Das Programm kann jetzt automatisiert bei Bedarf gestartet werden. Die Trigger zum Start befinden sich auf globaler/Profil oder Raumebene. Wenn beispielsweise ein ICAL Event auf „true“ gesetzt wird“, dann werden für alle Räume Temperaturen neu gerechnet.
Somit wird nur bei Bedarf und auch nur für relevante Räume ein Programmlauf notwendig. Das spart Ressourcen und ist auch intuitiver im Vergleich zum Schedule, der z.B. alle 2 Minuten läuft. Es kann aber auch weiterhin mit Schedule gearbeitet werden.
! - Handling von manuellen Änderungen erweitert durch Zurücksetzen der manuellen Temperatur bei Schedule Wechsel. Die bisherige Funktionalität ist dabei erhalten geblieben (Wechsel nach einer einzugebenden Anzahl Minuten oder Verhinderung von manuellen Temperaturen )
! - Ausnahmeliste für Sensoren: Sensoren können durch eine Tabelle von der Steuerung ausgeschlossen werden. Somit ist eine Änderung der Gewerke bei zusätzlichen Sensoren im Raum nicht notwendig. (z.B. wenn ein Sensor zur Alarmsteuerung (Innenhaut) im Einsatz ist aber nicht zur Heizungssteuerung)
! - Neuer Datenpunkt „Source_Next_Temp“ : Durch diesen Datenpunkt wird die nächste anzusteuernde Temperatur vorausgesagt und gespeichert. Damit kann z.B. eine Fußbodenheizung, die bauartbedingt träge reagiert, im Vorfeld eingesteuert werden. Die Steuerung der Temperaturen erfolgt dabei über das Setzen einer manuellen Temperatur in Verbindung mit dem Rücksetzen „zum Wechsel des Schedules“. Scripte für diese Steuerung werden separat zur Verfügung gestellt. Siehe Link im Heizungsscript Thread.
! - Datenpunkt „Source_last_Program_Run“: Dieser Datenpunkt zeigt auf globaler Ebene den letzten Programmlauf an. Nun, da nur bei Bedarf ein Programmlauf stattfindet (Trigger basiert), wird der letzte Programmlauf auch auf Raumebene geführt.

! - Neuer View: Es wird ein neuer View zur Verfügung gestellt. Der View zeigt wie gewohnt die verschiedenen Ebenen der Datenstruktur (Global/Raum/Profil) und biete auch die mehr Möglichkeiten für Geräte spezifische Informationen. (z.B. Voltage, Boost. etc.)
! - Mehr Gerätevoreinstellungen: In der Konfiguration werden mehr Beispielkonfigurationen gelistet für Homematic Geräte, IP-Geräte und nicht Homematic Geräten
! Neu ab 2.1
! - Manuelle Aenderungen sind überarbeitet.
+ Sporadisch auftauchende manuelle Temperaturen sollten jetzt gefixt sein
+ Manuelle Aenderungen bleiben erhalten nach Aenderung von Profil/schedule, SoftBoost etc. bis zum geplanten Ablauf

• ICLA Aktivierung jetzt über die Views (nicht mehr ueber das Script
• Profil Selektion über ICAL komplett überarbeitet
  • Globale und Raumprofile haben jetzt eine Subscription
  • Mehrere gleichzeitige Profile im Google Kalender:Jetzt wird immer die höchste Profilnummer gewählt (vorher war es immer 1)
  • ICAL Selektion läesst sich pro Raum ausschalten. Zwei Vorteile
    • Event Profil Nummer im View braucht es nicht mehr, da jetzt alles über das aktivie Profil gesteuert wird
    • Räume lassen sich von der global profil auswahl ausschliessen
    • Es wird nicht immer wieder auf die ICAL Selektion zurückgestellt. Pflege alternativer Profile ist somit möglich mit anschliessender neuer aktivierung des Profils
  • Ein neuer View (Herzlichen Dank an Kugelkopf für die Alternative ProfilSelektion innerhalb des Views) mit alternativer Profilselektion (max 3)
• SoftBoost jetzt möglich um über eine einstellbare Zeit einen Raum aufzuheizen (Max Temp)
• Neue Views
  • View jetzt mit zusätzlichen Feldern für ICAL Aktivierung und Softboost
  • View mit 3 Profilen zum umschalten
  • Alternativer View mit 1 Profil - dafür kleiner (weniger Widgets)
• Die Installation der Views hat sich geändert und funktioniert jetzt über Widget Import (schneller)
• Dokumentation
  • FAQs erweitert(z.B. wie ICAL aktiviert wird)
  • View Installation - Beschreibung wie der View erstellt wird - (jetzt Widget Import)

! ````

Viel Spass mit dieser Lösung.

Looxer

Hinweis Subscriptions Funktion:

Die Aenderung eines globalen Parameters führt in vielen Fällen zu Anpassungen der SollTemperaturen und damit zu erhöhten Funkaktivitäten.

Ich selber arbeite mit 15 mit der CCU verbundenen Thermostaten (es sind mehr, viele sind aber mit Wandthermostaten verknüpft und belasten somit nicht den CCU Dutycycle) und komme bei -4 maligen Aenderungen auf einen um 15 % erhöhten Duty Cycle. Es gibt aber viele Abhängigkeiten. Ich möchte also darauf aufmerksam machen, die globalen Parameter nicht uebermaessig oft innerhalb von wenigen Minuten zu ändern. Das gibt es im Prinzip auch bei der Schedule Funktion. Allerdings bei einem update alle paar Minuten ist das eher unkritisch.

Hinweise, wenn das Programm Thermostate/Sensoren nicht erkennt:

Falls die Thermostate/Sensoren nicht eingelesen werden, dann gibt es vermutlich Ungereimtheiten beim SetUp der Räume/Gewerke. Es empfiehlt sich folgende Vorgehensweise:

1. Überprüfen, dass die Thermostate / Sensoren in der CCU wirklich den richtigen Gewerken und Räumen zugeordnet sind

2. Überprüfen, dass in den ioBroker Aufzählungen (rooms und functions) die Räume und Gewerke gelistet sind. Irgendwelche $functions oder $rooms sollten nicht auftauchen.

3. Bei Ungereimtheiten in den Aufzählungen könnt ihr versuchen manuell zu korrigieren. Wenn bei den Aufzählungen nur CCU Räume und Gewerke vorhanden sind, dann empfiehlt sich einmal die rooms und functions komplett zu loeschen.

4. nachdem geändert wurde muss der REGA adapter und auch die HM-rpc Adapter neu geladen werden ( bei den Instanzen). Bitte zuerst den REGA Adapter starten und mindestens 30 Sekunden warten. Dann erst die RPC Adapter starten. Falls das nicht klappt bitte ioBroker neu starten

Open Issues:

• Im Zusammenhang mit "View in Widget " widgets und auch container widgets gibt es drei Fehler im VIS, die ich hier und auch in Trello reportet habe. Ich hoffe auf einen Fix. Leider hat sich da aber noch nicht viel getan:

http://forum.iobroker.net/viewtopic.php … =60#p84526

• Es gibt noch ein kleines Problem mit den manuellen Temperaturen: Hin und wieder wird eine manuelle Temperatur (im Widget) nicht angenommen und muss nochmal eingestellt werden. Dies passiert aber nicht immer. Ich schaue mir das noch an

• Ich habe es noch nicht geschafft die Dokumention auf den Stand 2.1 zu heben. Aber dafür gibt es die FAQ die einen Abschnitt über ICAL beinhalten und es gibt auch die Installationshinweise der Views. In nächster Zeit werde ich auch die Doku auf 2.1 bringen

Und jetzt Script, View, Docu:

View1 mit 1 Profil

View2 mit 3 Profilen

Installationsanleitung Schritt für Schritt wie die Views erstellt werden

Docu:

FAQs (unbedingt lesen )

Das Script

Hi,
Das vorliegende Script logged Servicemeldungen von der CCU/AccessPoint/HCU-

Für welche Umgebungen eignet sich das Skript?

• CCU (bzw. Raspberry Pi-Ersatz)
• CCU FUNK
• CCU Wired
• HMIP Access Point (Achtung: „GeraeteIDTrigger“ muss auf „true“ gesetzt sein)
• HMIP HCU Cloud (Achtung: „GeraeteIDTrigger“ muss auf „true“ gesetzt sein)

Es handelt sich dabei nicht um ein „entweder-oder“ – die Instanzen werden parallel überwacht.

Was kann das Skript?

• Überprüfung der Servicemeldungen: Das Skript prüft, ob Servicemeldungen vorliegen.
• Speicherung der Servicemeldungen: Servicemeldungen werden in Lang- und Kurztexten (Text, JSON, HTML) gespeichert.
• Zählung von Servicemeldungen: Es werden Zählungen nach Meldungsarten und insgesamt gespeichert.
• Erstellung der erforderlichen Datenpunkte: Das Skript legt automatisch die notwendigen Datenpunkte an.
• Reaktion auf Geräteänderungen: Es reagiert entweder auf Veränderungen auf Geräteebene (viele Subscriptions – z.B. 298 bei 80 Geräten) oder, standardmäßig, auf Veränderungen der Anzahl der in der CCU gemeldeten Servicemeldungen (1 Subscription)
• Historie: Es wird eine Historie geführt, die auch zeigt, wann Servicemeldungen wieder aufgehoben wurden.
• HMIP Access Point/HCU Support: Wenn der Access Point genutzt wird, muss auf die Geräte-ID getriggert werden (da der REGA-Datenpunkt fehlt).
• Externe Log-Datei: Es kann ein externes Log im Excel-Format fortgeschrieben werden. Hierin werden alle Servicemeldungen langfristig fortgeschrieben
• Heizungsgruppenmeldungen: Heizungsgruppenmeldungen sind standardmäßig deaktiviert. Sie können jedoch bei Bedarf aktiviert werden.
• Servicemeldungen Bestätigung: Das Skript bestätigt auf Wunsch CCU Servicemeldungen.
• Flexible Messaging Services: Es können email', 'whatsApp', 'Signal','Telegram', 'Pushover', 'Pushsafer oder auch SPRACHE zum versenden von Servicemeldungen eingestellt werden. Das Versenden kann per MessageType vereinbart werden.
• Flexibles Tabellenwerk: Anpassungen für z.B. neue MessageTypes von Servicemeldungen bei neuen Geräten können ohne Programmierung im Tabellenwerk konfiguriert werden

Einfache Nutzung: Das Skript ist sofort lauffähig, vorausgesetzt, die Instanzen (CCU etc.) sind korrekt eingerichtet.
Das Skript arbeitet in der aktuellen Version stabil und zuverlässig.

Zusätzliche Hinweise:

In der Standardkonfiguration des Skripts werden 2 Subscriptions und 1 Schedule erstellt.
Ich verwende das Skript mit einer Subscription auf Ebene Einzel-ID (Einstellung „GeraeteIDTrigger“). Bei dieser Konfiguration wird eine Warnung im Log angezeigt, wenn mehr als 100 Subscriptions von dem Servicemeldungs-Skript erstellt werden.
Diese Grenze kann in den „Instanzen JavaScript“-Einstellungen angepasst werden. Für diesen Anwendungsfall sind keine Performance-Probleme zu erwarten.
Channel Selector: Das Skript verwendet statische Channel-Selector. Das bedeutet, dass Änderungen an den Datenstrukturen durch die CCU (z.B. das Löschen oder Hinzufügen von Geräten) nicht bekannt sind, solange das Skript nicht neu gestartet wird.
Falls Geräte hinzugefügt oder gelöscht werden, muss das Skript neu gestartet werden.

und hier das Script:
Servicemeldungen_Vol2_3-31.txt

Dazu stelle ich zwei Views für VIS zur Verfügung:

Den View gibt es für das JSON Format also auch für das HTML Format. Beide sehen weitestgehend identisch aus

1. JSON View: Diese View ist für die Darstellung der JSON-Datenpunkte gedacht. Die Datenpunkte sind auf „javascript.0....“ ausgerichtet, was ggf. angepasst werden muss. Die View kann in VIS über „view importieren“ geladen werden. Der Inventwo-Adapter muss installiert sein. Falls du VIS2 nutzt, empfiehlt sich momentan die HTML-Variante.
   View_SM_JSON.txt

2. HTML View: Diese View zeigt die HTML-Datenpunkte an. Auch hier müssen die Datenpunkte ggf. angepasst werden. Die View kann ebenfalls in VIS über „view importieren“ geladen werden. Die verwendeten Widgets sind klassische ioBroker-Widgets und funktionieren sowohl in VIS1 als auch in VIS2.
   View_SM_HTML.txt

Die Views enthalten einen Push-Button. Wenn der gedrückt wird, wird die Meldungshistorie ohne Nachfrage gelöscht

Da das Skript bei niedrigem Batteriestand automatisch die erforderlichen Batterien überprüft, müssen die Geräte mit den Batterien in eine Liste eingetragen werden. Mit dem folgenden Script kannst du überprüfen, ob die Liste vollständig ist. Alle Geräte mit unbekannten Batterien werden aufgelistet. Du kannst mir diese Liste dann zur Verfügung stellen, und ich pflege sie gerne ein.
hier das Checkscript:
Batterie-Check-1-1.txt

Zusätzlich stelle ich ein Tool zur Verfügung, das alle ioBroker-Subscriptions auflistet. Dies steht nicht direkt im Zusammenhang mit dem Servicemeldungsskript, ist aber hilfreich, um transparent zu sehen, was insgesamt abonniert wurde. Über eine Variable kann die Liste auch auf ein bestimmtes Skript eingeschränkt werden. Das Ergebnis kann in eine externe Datei geschrieben werden.
Hier das script
ListSubscriptions_1.0

Hi,
ich habe das script -zunachest fuer mich- komplett umgeschrieben.

• effizienter gestaltet
• Historie
• Subsrciption auch auf REGA (also nur 1) wenn gewünscht
• alle message-services zum Senden integiert (email, whatsapp, telegram, signal etc)

@Cash: wenn fuer dich ok und falls interesse von anderen wuerde ich dafuer einen einen neuen Thread aufmachen

vG Looxer

Liebe Community,
aus sehr persönlichen Gründen habe ich mich in den letzten Monaten zurückgezogen bzw. zurückziehen müssen.
Was das Script betrifft habt ihr zurecht angemerkt, dass es recht umfangreich ist. Auch ist es nicht immer einfach den Einstieg zu finden.
Eine Weiterentwicklung ist aus o.g. Grunde von mir nicht möglich. Allerdings nutze ich das Script selber und sollte es in Zukunft mal Probleme geben z.B.
mit Fehlern aufgrund von neuen ioBroker Entwicklungen (z.B. JS-Controller etc) , dann werde ich wahrscheinlich -auf Nachfrage- noch Fixes bereitstellen können.
Es ist gut, dass es jetzt einen Adapter gibt, der in die Richtung geht. Für alle Neueinsteiger ist es der richtige Weg. Der Adapter braucht vermutlich noch etwas Zeit um die Script Funktionalität abzudecken. Mitarbeit hilft aber, wie ich selbst bestätigen kann

Vielen Dank an alle, die mich bei der Entwicklung unterstützt haben oder die auch mit supported haben.

In diesem Sinne möge der ioBroker mit euch sein.

Liebe Grüße.

Looxer

Hi,
neue Versionen sind online.

Servicmeldungsscript Version 1.05:

• Fix fuer Status 0 fuer historische Meldungen. Text aus Tabelle: StandardstatusMessages verwendet // Text angepasst in Tabelle fuer 0
• Batteriemeldung erweitert
• Telegram Instanz und User hinzugefügt
• WICHTIGE Aenderung fuer REGA subscription: Intelligenterer Umgang bei vielen Aenderungen von Anzahl der Servicmeldungen aus der CCU

Batteriescript Version 1.1

• doppelte Listungen verhindert, wenn alle Geräte gelistet werden
• Native IDs für aa und aaa batterien hinzugefügt // Danke an Quarkmax

Hi,

die Funktionalität des Scriptes ist soweit ausentwickelt. (für den Moment)
Ich habe noch ein bischen Sanitäres gemacht im Coding, das Logging verbessert
und eine check routine eingeführt, falls die Gruppen Definitionen inkonsistent eingestellt werden.
Es gibt dann eine harte Fehlermeldung und Programmabbruch.

Die Version 1.20 ist hochgeladen und steht im ersten Post zum Download bereit.

vG Looxer

Hi,

Version 2.10 ist jetzt online.

• HMIP Accesspoint / HCU-cloud vollstaendig implementiert (Tests ausstehend). In diesem Zuge wurde mehr generalisiert. Also einstellbar gemacht ueber das Tabellenwerk. Die Routinen duerften damit auch stabiler geworden sein.
• Overheat und Undervoltage Alarm hinzugefuegt
• Performance Verbesserung Faktor 4- Urspruenglich lag der Zeitverbrauch fuer die Hauptroutine bei 11 ms. Nach dem letzten Update dann bei 4 ms und nun nur noch bei maximal 1 ms. (in meiner Systemumgebung)

edit: noch schnell die Version 2.11 nachgeschoben. Ich konnte HMIP AcessPoint/HCU teilweise testen. z.B. funktionieren die subscriptions etc.

vG Looxer

Hi,
ich habe einen Versuch gemacht neben JSON und TEXT auch eine HTML Version zu erstellen und das sieht ganz gut aus.
Der untenstehende ScreenPrint sieht ähnlich aus wie die JSON Version ist aber komplett aus einem generierten HTML Datenpunkt entstanden.

Wäre ja was für z.B. @sigi234, solange VIS2 noch Probleme macht mit dem Inventwo Widget.
oder eben auch für Fälle wo JSON nicht gut passt.

Ist das von Interesse ?

vG Looxer

Screenshot mit einem HTML Datenpunkt

Hi,
kleine Info:
ich habe mir das Thema "Sticky" genauer angesehen und beschlossen die automatische Bestätigung von Servicemeldungen einzubauen.
Das scheint mir nicht so sehr schwierig. Auf diese Art und Weise können dann auch Sticky Meldungen ohne Bestätigung in der CCU gezeigt werden.
Kommt demnächst.
Hinweis: Sticky Meldungen gibt es nur bei Homematic-Classic.

vG Looxer

Hi,
Version 3.20 ist jetzt online.
Folgende Änderungen gibt es:

• Doppelte Nachrichten im messageCollector verhindern
• Vermeidung Meldung "keine Servicemeldungen..." in der Historie wenn bereits vorhanden
• Wartezeit für Rega-Trigger wieder auf 5s
• Sticky-Meldungen der CCU koennen automatisch bestaetigt werden

Details zur automatischen Bestaetigung von Servicemeldungen:
Zunächst mal hat sich die Funktion sehr gut in das Gesamtkonzept des Scriptes eingepasst - ohne Verbiegungen
Das Ganze ist nur relevant fuer HM-Classic Geräte, da es keine STICKY Meldungen für Homematic IP Geraete gibt.

Es wurde eine neue Variable implementiert, die standardmaessig auf true sitzt: AutoBestaetigungCCUMeldungen = true
Bei true wird eine Unterroutine aufgerufen, die die Bestaetigung vornimmmt wenn die Message bereits obsolet ist
Beispiel: UnreachMessage lag vor ist aber zwischenzeitlich nicht mehr relevant, dann wird die entsprechende STICKY_UNREACH Message bestaetigt.
Hinweis: Wenn die Sticky-Messages automatisch bestaetigt werden sollen, dann empfiehlt es sich die AutoBestaetigung der CCU auszuschalten (Systemeinstellungen der CCU in der Benutzerverwaltung)

zudem wurden im MessengerScope, also die Tabelle für den Nachrichtenversand die StickyMeldungen STICKY_UNREACH und STICKY_SABOTAGE aufgenommen.
Der Grund ist, dass man für diese Meldungen normalerweise keine Nachrichten empfangen möchte, da ja bereits durch UNREACH und SABOTAGE erfolgt.
Also sollte in der Tabelle "Messengerscope" für diese messageTypes alle Nachrichten auf false stehen.

Wenn jemand überhaupt keine STICKY-Messages sehen möchte, dann können die entsprechenden Zeilen einfach in der Tabelle Alarmtypes auskommentiert werden.
Somit werden diese Meldungen ignoriert.

sähe dann so aus

const alarmTypes = [
    { key: 'UNREACH_ALARM',                     suffixes: ['UNREACH_ALARM','unreach' ] },//UNREACH_ALARM = HM-Classic & HMIP-CCU - unreach = HMIP Accesspoint
//    { key: 'STICKY_UNREACH_ALARM',              suffixes: ['STICKY_UNREACH_ALARM'] },
    { key: 'CONFIG_PENDING_ALARM',              suffixes: ['CONFIG_PENDING_ALARM','configPending'] }, //configPending ist eine HMIP Meldung
    { key: 'UPDATE_PENDING_ALARM',              suffixes: ['UPDATE_PENDING_ALARM'] },
    { key: 'LOWBAT_ALARM',                      suffixes: ['LOWBAT_ALARM', 'LOW_BAT_ALARM','lowBat'] }, //LOWBAT_ALARM = HM-Classic - LOW_BAT_ALARM = HMIP CCU - lowBat = HMIP Accesspoint
    { key: 'DEVICE_IN_BOOTLOADER_ALARM',        suffixes: ['DEVICE_IN_BOOTLOADER_ALARM'] },
    { key: 'ERROR',                             suffixes: ['ERROR','DUTY_CYCLE'] },                  // error ist ein Sammler fuer hier nicht definierte Meldungen
    { key: 'FAULT_REPORTING',                   suffixes: ['FAULT_REPORTING'] },
    { key: 'SABOTAGE_ALARM',                    suffixes: ['SABOTAGE_ALARM','sabotage'] }, // sabotage ist eine HMIP Meldung
//    { key: 'STICKY_SABOTAGE_ALARM',             suffixes: ['STICKY_SABOTAGE_ALARM'] },
    { key: 'ERROR_NON_FLAT_POSITIONING_ALARM',  suffixes: ['ERROR_NON_FLAT_POSITIONING_ALARM'] },
    { key: 'OVERHEAT_ALARM',                    suffixes: ['ERROR_OVERHEAT_ALARM'] },
    { key: 'UNDERVOLTAGE_ALARM',                suffixes: ['ERROR_UNDERVOLTAGE_ALARM'] },
];

vG Looxer

@sigi234
aber du hast das doch schon für die Servicemeldungen gemacht ?

@sigi234
die Scenarien ist das was du an der oberfläche aktivieren oder deaktivieren kannst.
Die Zuordnung eines Filters ist wichtig. Damit wird der Scope der zu überwachenden Räume/Geräte eingestellt.

Dann erfolgt die Festlegung wie die Alarmierung erfolgen soll (Alert)

Die Prio ist dann noch on top und entscheidet welches Scenario gewählt werden soll, wenn ein Geräte mehreren Scenarien zugordnet ist.

Mach erst mal 1 oder 2 Scenarien

Beispiel:
z.B. Nachtruhe oder so. Dann ordnest du deine ganzen innen Sensoren zu. (Filter "innen")
evt macht es Sinn beim Filter einige Datenpunkte auszuschliessen. (z.B. möchte man ja die Fenster im Schlafzimmer ggf geöffnet lassen)

2. Scenario könnte das "Abwesend Scenario sein" auch könnte der Filter auf innen stehen. Diesmal ohne Ausschluss,

Das 2. Scenario sollte eine höhere Priorität haben. Dann wird es vorangig selektiert, wenn es denn akiviert ist.
Somit sind auch die Schlafzimmerfenster alle eingeschlossen bei Abwesenheit.

muss man etwas drüber nachdenken. Die Möglichkeiten sind sehr umfassend. Das soll eben eine gute Grundlage für mehr Automatisierung sein

vG Looxer

@sigi234
ich weiß nicht, ob es da Unterschiede gibt zwischen VIS1 und VIS2
das ist ja ein HTML Basic Widget. Dementsprechend entscheidet die Höhe des Widgets über die Anzahl der Zeilen.

oder verstehe ich was falsch ?

@sigi234

@sigi234 sagte in [Vorlage] Alarmanlage mit erweiterten Funktionen:

Arbeite mit VIS2

ist mir bekannt - wie gesagt - sag Bescheid. In diesem Fall lade ich den Fix asap hoch

@sigi234
ja, das ist leider keine userfreundliche GUI
Tueren musst du in Hochkomma setzen, also 'Tueren'

Bei Ausschluss von Tueren muss es dann so gehen: '-Tueren'

ohne Hochkomma erwarte javasscript, dass es eine definierte variable mit Namen Tueren gibt.

Hinweis: mir ist gerade ein Fehler aufgefallen, dass beim Aufruf der View mit den Räumen Seiteneffekte in VIS auftreten können.
Falls das bei dir der Fall ist, dann habe ich schon den Fix

vG Looxer

@sigi234
das funktioniert erst wenn du die Filter (mindestens 1 ) erstellt hast und mindestens 1 Scenario mit Filter erstellt hast.

Ich habe jetzt eine Meldung eingebaut, die eine Note für diesen Fall rauswirft

@sigi234
kannst du mir deine Scenario Definition zeigen ?

@sigi234
den Typo habe ich korrigiert. danke.
ja, du kannst löschen was du nicht brauchst, Allerdings sollten die Tabellen noch erhalten bleiben:

const AlertAusgabeDevices = { }
damit gibt es eben keine Eintragungen. Die Referenz hast du ja immer hier im Forum zum Wiederherstellen

Statusboard - dto
const ControlDevices = [ { } ]

zur Raumübersicht. die wird immer gefüllt aber dafür braucht es auch Definitionen in raumDefinition

vG Looxer

Hi,

Im ersten post habe ich das script hinterlegt, sowie die views fuer HTML und JSON.
Wenn ihr mit dem JSON klar kommt, dann ist das zu bevorzugen, da die HTML Generierung ausgeschaltet werden kann und somit
sowohl die Generierung also auch die Datenpunkte entfallen.

Bitte schaut euch die Erklärungen im ersten post zu den 5 wichtigen Schritten.
Ich schreibe in den ersten post auch noch ein paar Hinweise zum debugging rein

bitte beachtet, dass dies die erste Version außerhalb meiner Testumgebung ist.
Es gibt sicher noch Fehler und die können auch schon sehr schnell auftreten.

vG Looxer

Ich habe dem View die Übersicht über den Status der Räume hinzugefügt.(
Beim aktivieren und deaktivieren von Scenarios sind die Auswirkungen somit direkt sichtbar im View.
(Danke an Sigi für die Anregung)