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

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,
ausgehend von dem Servicemeldungen (all inclusive) Script von Cash habe ich eine neue Version erstellt.

Warum neu erstellt? Ich habe das Script selber im Einsatz gehabt und mich schwer getan mit Erweiterungen. Daher habe ich mich entschlossen, das Script komplett neu zu schreiben. Es ist nun stark modular aufgebaut was Pflegeaufwand reduziert und Erweiterungen leichter möglich macht

Was kann das Script ?

• Vor allem zunächst mal checken, ob Servicemeldungen vorliegen
• Servicemeldungen werden gespeichert in Lang und Kurztexten
• Zählungen von Servicemeldungen nach Meldungsarten und Gesamt werden gespeichert
• Die erforderlichen Datenpunkte werden vom Script angelegt
• Das Script reagiert entweder auf Veränderungen auf Geräteebene (viele Subscriptions – bei mir sind es 270 bei 80 Geräten) oder (auf Wunsch) immer dann, wenn die CCU eine Veränderung der Anzahl der in der CCU festgestellten Servicemeldungen meldet. (1 Subscription)
• Messaging Services können genutzt werden und nach message types konfiguriert werden
• Wenn die subscription auf Geräteebene gesetzt wurde, dann wird eine Historie mitgeführt. Dort ist z.B. auch ersichtlich, wann bestimmte Meldungen wieder aufgehoben wurden. Das geht nicht, wenn die Subscription auf „CCU Anzahl Servicemeldungen“ gestellt ist
• Wenn die subscription auf Geräteebene gesetzt wurde, dann kann auch ein externes LOG im Excel Format fortgeschrieben wird (für langfristige Speicherung) Das geht nicht, wenn die Subscription auf „CCU Anzahl Servicemeldungen“ gestellt ist
• Das Script ist sofort lauffähig. Die Einstellungen sind alle optional.
• Ich habe die Heizungsgruppenmeldungen ausgelassen. Aus meiner Sicht sind die nicht hilfreich. Sie können aber jederzeit wieder aktiviert werden.
• Das Script selber bestätigt keine Servicemeldungen. Ich gehe davon aus, dass dies in der CCU entweder manuell oder automatisch geschieht (kann eingestellt werden

Ich habe die prinzipiellen Funktionen bisher getestet aber nicht jedes einzelnes Gerät mit den unterschiedlichen Meldungsarten. Korrekturen sollten aber, bedingt durch den modularen Aufbau, einfach möglich sein. Ich nutze das Script selber, daher supporte ich gerne.

Ich nutze das Script mit Subscription auf Ebene Einzel-ID, weil mir die Historie von Servicemessages wichtig ist. Es gibt eine Warnung im log, wenn von einem script mehr als 100 subscriptions erstellt werden. Dies kann im Admin heraufgesetzt werden. Es ist nicht grundsätzlich ein Performance Problem mit vielen Subscription verbunden. Wenn allerdings viele Subscriptions viele Änderungen bedeuten, dann ist die Performance sehr wohl beeinträchtigt. Das dürfte für diesen Fall aber nicht gelten.

Wer sich nicht wohl führt mit der Anzahl der Subscriptions kann auf die CCU-Meldungen umstellen. Dann wird nur eine einzige Subscription erstellt.

noch ein Hinweis:
Das Script arbeitet mit Channel_Selector. Die sind statisch, d.h., dass Aenderungen an den Datenstrukturen durch die CCU nicht bekannt sind, solange das Script nicht neu gestartet wird. (z.B. loeschen oder hinzufügen von Geraeten)
Bei Loeschen und hinzufuegen von neuen Geräten muss das Script also auch neu gestartet werden.
(Die Alternative wären RegEx Subscriptions gewesen, die ich aber aus verschiedenen Gründen verworfen habe)

und hier das Script:
Servicemeldungen_Vol2_1-20.txt

Da das script bei niedrigem Batteriestand gleich die erforderlichen Batterien checkt, ist es erforderlich die Geräte mit den Batterien in eine Liste einzutragen.
Ob diese Liste vollstaendig ist kann mit dem u.g. Script gecheckt werden. Alle Geräte mit unbekannten Batterien werden gelistet.
Diese koennt ihr mir dann zur Verfuegung stellen und ich pflege diese gerne ein

hier das Checkscript:
Batterie-Check-1-1.txt

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

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,

ich habe ein kleines Programm geschrieben, dass die Anwesenheit aufgrund des TR64 adapters auswertet.

Voraussetzung ist, dass der Adapter TR64 installiert ist und natürlich eine Fritzbox vorhanden ist.

Die Anwesenheiten werden sehr zuverlässig gemessen mit IOS oder Android oder was auch immer. Natürlich dürfen die Telefone sich nicht vom WLAN abmelden was sowohl bei IOS nicht mehr passiert und auch nicht bei Android (es sei denn, dass sie so eingestellt sind)

Meine Erfahrung ist, dass es 10 Minuten dauert bis eine Abwesenheit festgestellt wird und ca. 1 Minute bis die Anwesenheit festgestellt ist.

Folgende Funktionen sind realisiert:

• Anwesenheitsdarstellung im Bereich javascript ( ist aber quasi nur eine Dopplung vom TR64)

• Anwesenheitsermittlung (ist irgendwer im Hause)

• Liste der anwesenden Personen

• Kommt Geht pro person

• JSON Liste der Anwesenheiten mit den letzten Kommt/Geht Zeiten

• auf Wunsch wird ein LOG geführt, dass die Geht/Kommt Zeiten historisch mitschreibt.

• Anbindung der Anwesenheitssimulation. Wenn gewünscht wird die Anwesenheitssimulation eingeschaltet. Die Anwesenheitssimulation gibt es hier:

http://forum.iobroker.net/viewtopic.php … simulation

• 6 User sind einstellbar. Falls gewünscht können weitere User hinzugefügt werden (mit kleiner Programmerweiterung) - reduzierbar auf 6 user im Einstellbereich des Programmes

vG Looxer

Anwesenheitsliste als Json

Programm:

Ich habe die AWS wiederentdeckt und nutze es jetzt wieder.
Mir ist der Adapter zur Aufzeichnung des schaltverhaltens bekannt. Finde ich persönlich aber zu umständlich
Der gesamte Code ist nun modernisiert und damit effizienter.
Falls also jemand das Programm noch nutzt -

vG Looxer

Hi,
ich habe eine neue Version im ersten post hinterlegt.
In dieser Version kann jedes Astro-Keyword verwendet werden.
wenn debug auf true steht werden alle astrozeiten gelistet. Daran kann man sich ganz gut orientieren.

sieht zur Zeit so aus:
Astrokeyword nadir: Datum: 28:07 ----- Uhrzeit 01:39
Astrokeyword dawn: Datum: 27:07 ----- Uhrzeit 05:09
Astrokeyword nauticalDawn: Datum: 27:07 ----- Uhrzeit 04:13
Astrokeyword nightEnd: Datum: 27:07 ----- Uhrzeit 02:49
Astrokeyword night: Datum: 28:07 ----- Uhrzeit 00:29
Astrokeyword nauticalDusk: Datum: 27:07 ----- Uhrzeit 23:05
Astrokeyword dusk: Datum: 27:07 ----- Uhrzeit 22:08
Astrokeyword sunset: Datum: 27:07 ----- Uhrzeit 21:27
Astrokeyword sunsetStart: Datum: 27:07 ----- Uhrzeit 21:23
Astrokeyword goldenHour: Datum: 27:07 ----- Uhrzeit 20:38
Astrokeyword solarNoon: Datum: 27:07 ----- Uhrzeit 13:39
Astrokeyword goldenHourEnd: Datum: 27:07 ----- Uhrzeit 06:40
Astrokeyword sunriseEnd: Datum: 27:07 ----- Uhrzeit 05:54
Astrokeyword sunrise: Datum: 27:07 ----- Uhrzeit 05:50

vG Looxer

Hi,
Version 1.1 ist jetzt hochgeladen mit ein paar weiteren Code Optimierungen aber auch Funktionen

• neben dem debug log kann auch ein minilog aktiviert werden fuer transparenz aber weniger meldungen
• Jetzt werden die schedules nur geplant wenn AWS aktiv ist. Das Programm wird also nicht mehr unnötig durchlaufen, nämlich dann nicht, wenn AWS gar nicht aktiv ist

Habt ihr die neue Version bereits ausprobiert ?

vG Looxer

Hi,

Version 1.20 ist online.
Ein größerer Sprung

• Code optimiert und stellenweise umgeschrieben
• Einstellungsbereich strukturiert
• Funktional: Es ist nun möglich, für jeden Nachrichtenservice (z. B. E-Mail, WhatsApp usw.) individuell festzulegen, ob eine kurze oder lange Meldung versendet werden soll.

Bitte beachten und das galt auch schon für die alten Versionen

• Die Instanzen müssen stimmen.
• Eine 9 eingeben, wenn eine Instanz nicht benötigt wird
• Die Instanz für CuxD bitte nirgendwo eingeben
• Ansonsten sind die Instanznummern natürlich mit den Instanzen HMRPC des ioBrokers abzugleichen

vG Looxer

@zahnheinrich
Hi,
ich habe für die nächste Version erhebliche Änderungen eingebaut.
Lohnt sich daher nicht in die alte Version zu schauen.
Die kommt dann heute oder morgen, falls ich nicht erhebliche Probleme finde.

vG Looxer

@zahnheinrich
Danke für den Hinweis.
Es ist also auch nicht möglich Wired separariert von der HMIP Instanz als eigene Instanz zu konfigurieren ?

vG Looer

@sigi234
Danke dir. habe ich korrigiert.
vG Looxer

@zahnheinrich
bei HMIPW hast du im screen print einmal "Error_Undervoltage_Alarm"

Frage:
gibt es bei HM wired auch 2 instanzen, also je eine für HM-Classic und eine fuer HMIP?
Das wäre ja noch gar nicht eingebaut.

vG Looxer

@flkontakt
Hi,
vielen Dank für die Rückmeldung. Freut mich, dass es zunächst mal läuft.
Das mit dem Kurztext hatte ich schon auf der Liste. Dauert aber noch etwas.

vG Looxer

Version 1.12 ist online

• Für Wired sind die jetzt bekannten Alarme hinzugefügt
• für HMIP und Classic sind die Alarme erweitert auf Overheat und Undervoltage

vG Looxer

super, vielen Dank für die Infos. Habe ich auch gleich eingebaut.
Testen kann ich ja leider nicht. Ich hoffe, dass es jetzt bei euch läuft.
Ich habe auch Overheat_Alarm und under_voltage Alarm für die HMIP/Classic Geräte gleich mit eingebaut

Script kommt gleich

vG Looxer

@flkontakt sagte in [Vorlage] Servicemeldungen Volume2:

Frage: müsste ich meine HM-Einstellungen so anpassen?
const HMClassicInstanz = 0;
const HMIPInstanz = 1; (bei mir Cuxd)
const GruppenInstanz = 3; (bei mir die Heizungsgruppen)
const WiredInstanz = 2; (bei mir Wired)

Hi,

bitte erstmal so einstellen:

const HMClassicInstanz = 0;
const HMIPInstanz = 9
const GruppenInstanz = 9
const WiredInstanz = 9

Bitte so einstellen. Wired erstmal rauslassen und Gruppen brauchst du nicht und IP hast du nicht.
Für wired muss ich noch eine neue Version machen, aufgrund deiner Infos. Wenn die da ist, dann kannst du
wiredInstanz auf 2 stellen.

vG Looxer

@flkontakt
Bitte nutze Version 1.11
Wired war bisher nicht berücksichtig. Dafür habe ich eine eigene Einstellung hinzugefügt.
Ich bin nicht sicher, ob es überhaupt Servicemeldungen gibt. Dafür bräuchte ich deine Hilfe das herauszufinden und natürlich welche das sind. Dafür wären die Datenstrukturen für Wired hilfreich. Aso gibt es datenpunkte für:

LOWBAT
UNREACH
STICKY_UNREACH
CONFIG_PENDING
UPDATE_PENDING
DEVICE_IN_BOOTLOADER
ERROR
ERROR_NON_FLAT_POSITIONING
FAULT_REPORTING
SABOTAGE (ist wahrscheinlich relevant)
ERROR_REDUCED
STICKY_SABOTAGE
USBH_POWERFAIL
U_SOURCE_FAIL

Wenn ich weiß welche Datenpunke es fuer Alarm-Situationen gibt, dann kann ich das Coding für Wired entsprechend anpassen.
Trotzdem sollte die 1.11 schon einigermaßen laufen.

vG Looxer