inspiriert vom Heizungsthermostat-Script und weil meine homeputer-Lizenz abgelaufen ist, und ich meine Heizungssteuerung von dort nach iobroker portieren wollte, ist der Adapter HeatingControl entstanden.

Features:

• setzen der Zieltemperatur in verschiedenen Thermostaten
• beliebige Anzahl von täglichen Zeitabschnitten mit unterschiedlichen Zieltemperaturen
• Zeit und Zieltemperatur per Visualisierung konfigurierbar
• automatische Suche nach vorhandenen Thermostaten im System (über Gewerk) und Zuordnung zu Räumen
• Für den Fall, dass der Thermostat nur als Thermometer verwendet wird, behandelt der Adapter auch digitale Outputs zum Schalten der Ventile. Im Moment ist dafür nur eine einfache Ein/Aus-Regelung implementiert (die für meine Zwecke ausreichend ist). Weitere Regelungen sind aber als Idee bereits vorhanden und können implementiert werden. Es gibt nun auch einen linearen on/off mit Hysterese
• es werden bis zu zwei Outputs für Ventile unterstützt
• Outputs werden auch automatisch den Räumen zugeordnet. Dafür müssen diese dem gleichen Gewerk wie Thermostate zugeordnet sein.
• im Admin des Adapters können Räume deaktiviert werden
• Absenkung bei Abwesenheit
• Ventile ein oder aus außerhalb der Heizperiode
• Verbindung zu ical
• Verbindung zu Feiertags-Adapter
• Senden von Nachrichten per email, Signal, Telegram, discord, ...
• Kamin-Modus
• Wartungsmodus
• mehrere Profile
• Tages-Programme für
  - Montag - Sonntag
  - Montag - Freitag + Samstag - Samstag
  - jeden Tag separat

Versionen:

• 2.12.1
  Status: beta seit 25.11.2023
  NPM: ja
  github: ja
  weitere Informationen: github

• 2.11.1
  Status: stable seit 17.08.2023
  NPM: ja
  github: ja
  weitere Informationen: github

Da mich die Unzuverlässigkeit von wetherundergrund gestört hat (mal bekommt man keine Daten, mal bekommt die Daten der falschen Station) habe ich nach einer Alternativen gesucht. Gefunden habe ich https://www.daswetter.com/ und dafür habe ich nun einen Adapter geschrieben:

Man kann unter drei Alternativen wählen

• XML-Datei mit der 7-Tage-Wettervorhersage und allgemeiner Tagesüberblick

  • XML-Datei mit 5-Tage-Wettervorhersage und detaillierte Informationen für alle 3 Stunden
  • XML-Datei mit den stündlichen Wettervorhersagen

  Implementiert habe ich alle drei Varianten, man muss aber nur eine verwenden.

  

  Der Adapter enthält auch noch die zugehörigen icons, so dass man sich eine eigene Wetter-Vorschau in vis bauen kann.

  

  Falls jemand Interesse hat, der Adapter ist auf github unter

  https://github.com/rg-engineering/ioBroker.daswetter zu finden.

Ich bin dabei, den Adapter komplett zu überarbeiten. Dann wird es möglich sein, die OID's manuell für Thermostate, Aktoren und Sensoren zu konfigurieren, wenn die Geräte nicht automatisch gefunden werden. Damit kann man praktisch alle Thermostate mit dem Adapter steuern. Manche werden automatisch konfiguriert andere muss man dann manuell konfigurieren.

okay, jetzt ist es soweit, ich habe die Version 0.1.0 im github und NPM veröffentlicht.
Wichtigste Änderung vorweg: Der Adapter wurde intern komplett überarbeitet. Damit musste ich leider auch die Datenpunkte zur Profileinstellung pro Raum verschieben. Damit ist es notwendig, die Einstellungen im Vis o.ä. anzupassen
Nun zu den Neuerungen:

• Man kann nun eine nicht limitierte Anzahl von Thermostate, Aktoren und Sensoren pro Raum konfigurieren. Die alte Grenze von einem Thermostat pro Raum gibt es nicht mehr.
• die drei verschiedenen Profiltypen
  ** Montag bis Sonntag
  ** Montag bis Freitag und Samstag / Sonntag
  ** jeden Tag einzeln
  funktionieren nun
• es gibt auch die Möglichkeit, Fenstersensoren einzubinden. Damit kann man die Raum-Zieltemperatur absenken, wenn Fenster offen sind
• es gibt ein Interface zum Feiertag-Adapter. Damit kann man erkennen, ob heute ein Feiertag ist. Ein Feiertag wird dann entweder als normaler Tag oder wie ein Sonntag behandelt. das ist im admin einstellbar
• es wird weiterhin versucht, die Geräte pro Raum automatisch zu erkennen. Da das aber oft nicht so einfach ist (insbesondere bei nicht-Homematic-Geräten) gibt es jetzt die Möglichkeit, die Geräte auch manuell zu konfigurieren. Man fügt einfach ein neues Gerät im neuen Raum ein, setzt ein oder zwei Pfade (zu Zieltemperatur, aktueller Temperatur für Thermostate bzw. state zu Aktoren und Sensoren) und aktiviert das Gerät.
  Hier noch ein screenshoots vom neuen Adapter-admin:

ein Teil der Hauptkonfiguration:

die Profil-Konfiguration

zunächst die Räume

und dann die Konfiguration des Raumes, nachdem man den rot markierten Edit-Knopf gedrückt hat:

Im github und NPM liegt die 2.2.0 zum Testen bereit.

siehe auch github

Es gibt folgende Änderungen:

• issue #146: Fenstersensoren können jetzt vom Type boolean, number oder string sein. Der Wert für geschlossen / offen kann in allen drei Fällen konfiguriert werden. Die bisherige Konfiguration wird übernommen. Sobald man im admin einmal gespeichert hat, entfällt auch die diesbezügliche Warnung...
• issue #110: jeder Raum kann separat in den Modus "no heating" versetzt werden. Dazu gibt es einen neuen Datenpunkt "isActive". Wenn dieser auf false gesetzt wird, wird für diesen Raum die Aktion ausgeführt, die allgemein im admin für "no heating period" konfiguriert wurde
• issue # 185 und #184: die beiden Wartungsfunktionen im admin (ungenutzte Datenpunkte bzw. ungenutzte Konfiguration löschen) sind jetzt implementiert
• issue #207: die copy-Buttons für die vis wurden hinzugefügt
• issue #219: beim Kopieren von Profilen werden die Absenkwerte und der Profilname mit kopiert

Feedback ist wie immer willkommen...

@mcm1957 sagte in Alpha Test js-controller Kiera (v6.0):

Im Prinzip haben ALLE Adapter von rg-engineering das Problem dass die mit festgezurrten Dependencies unterwegs sind
Das betrifft:

amtronwallbox
daswetter
ebus
heatingcontrol
minmax
mysql
openhomecontrol
pvoutputorg
semp
spfspot

Die GitHub Versionen sollten - stichprobenartig geprüft - mittlerweile passende aber auch festgezurrte Versionen haben. Wann da neue Release kommen - keine Ahnung.

Ich arbeite die issues ab... dauert aber ein wenig.

Für DasWetter sollte das mit Version 3.1.14. erledigt sein.

Wäre gut gewesen, im Vorfeld (adapter-checker?) über solche Probleme informiert zu werden...

ACHTUNG: Bitte die aktuelle Version 3.0 aus github nicht installieren! Ich bin an Umbau-Arbeiten, die noch nicht abgeschlossen sind...
Es wird einen post von mir hier geben, wenn die 3.0 soweit ist...

@Smartuser sagte in Test Adapter HeatingControl v1.0.x:

Ein Blick in den Log zeigte wieder das "Fensterstatus-Problem

Was sind das für Sensoren? Ich denke, dieses Problem ist kein Poblem dieses Adapters. Das Problem hier ist eher, dass nach einem reboot der Status der Sensoren nicht automatisch aktualisiert wird, dshalb musst du die Fenster einmal öffnen und schliessen. Das kannst du prüfen, indem du einen reboot vom System mit iobroker machst und danach in den DP des Fensterstatus schaust. Da steht wahrscheinlich nichts drin...

Das Verlieren der Profile sollte nicht vorkommen. Ich bin eher der Meinung, herauszufinden, warum die Profile verloren gehen.

Bzgl. des Überschriebens durch Werte vom Thermostat bin ich dran, Änderungen zu testen. ich hoffe, das in der 1.1.0 releasen zu können...

Im github und NPM liegt die 3.0.8 zum Testen bereit.

Es gibt folgende Änderungen:

• Die unnötigen Warnungen bzgl. notwendiger Anpassung von channels wurden entfernt

Danke an @Dutchman!

Feedback ist wie immer willkommen...

@coyote @Chaot also auf jeden Fall das gleiche Problem... Die Soll-Temperaturen werden dem Adapter gemeldet, obwohl er sie nicht anfordert (oder zumindest anfordern sollte). Wenn das mit 2.0.2 weg ist, kann das ja nur an 15 Zeilen code liegen... ich schau noch mal und baue das Szenario hier nach...
https://github.com/rg-engineering/ioBroker.heatingcontrol/issues/213

rg-engineering created this issue in rg-engineering/ioBroker.heatingcontrol

closed Warnung "!!! Statechange not handled" #213

@norb-0 Der Plan ist, dass sich möglichst nichts ändert. Ich habe bei mir aber gesehen, dass ein paar neue Datenpunkte hinzugekommen sind und manche (speziell Beschreibungen und Namen) sich verschoben haben. Die sind jetzt an der gleichen Stelle, wie im Original vom ebusd (wenn man das ganze im browser direkt aufruft). Die Werte selbst waren zumindest bei mir nicht betroffen.
Hintergrund ist, dass ich eine Bibliothek, welche nicht mehr kompatibel war, entfernt habe und durch eigenen Code ersetzt habe.

@trapper ebusd - update

Der Adapter bring neuerdings zwei scripts mit

• InstallEbusd.sh
• UpdateEbusd.sh

Die liegen im Verzeichnis lib/scripts des Adapters.
Diese scripts kann man als Vorlage zur Installation oder update verwenden.
Außerdem ist das im wiki vom ebusd für die Installation beschrieben.

@lennerocker

Die Amtron 4you 500 kenne ich noch gar nicht, deshalb gehe ich erst mal davon aus, dass sie noch nicht unterstützt wird. Wir müssen also erst mal herausfinden, wie man mit dem Teil reden muss.

Wenn die Box die RestApi unterstützt, du dieses Interface aktiviert hast, könnte sie als Type "ChargeControl"
funktionieren.

Du kannst aber auch testweise im browser mal diese URL aufrufen (natürlich mit der IP, wie sie bei dir im Netzwerk eingerichtet ist)

http:// DEINE_IP /rest/full_state

@pdbjjens
Mein SHM 2.0 meldet eine SusyID 372.
Mein EM (EMETER-20.GR5) meldet eine SusyID 502 und im Tree wird "unknown SMA device S/N xxxx" angezeigt.

Die neuen EM habe ich noch nicht...

@vj77 hier kann der user iob SBFspot.db zum schreiben öffnen. Sollte da nicht der Eigentümer iobroker sein?

@tottbeck sagte in Neuer Adapter: SMA Wechselrichter mit sbfspot:

SqliteError: unable to open database file

Wie sehen die Rechte auf /home/scheth1/smadata/ und auf /home/scheth1 aus?
Ich denke immer noch, dass irgendwo Schreibrechte auf einem Ordner fehlen...

Die Erwartung wäre das woanders ein DB-File angelegt wird

genau.

@Tottbeck @VJ77 Habt ihr die Möglichkeit, in der main.js des Adapters zu editieren?

In Zeile 371 beginnt folgender Teil:

adapter.log.info("start with sqlite");

const path = require("path");

const file_path = adapter.config.sqlite_path;
const dbPath = path.resolve(__dirname, file_path.trim());

adapter.log.debug("--- connecting to " + dbPath);

const sqlite3 = require("better-sqlite3");

sqlite_db = new sqlite3(dbPath, { fileMustExist: true });
adapter.log.debug("sqlite Database is connected ...");
//DB_GetInverters();

Ihr könntet testweise aus

{ fileMustExist: true }

ein

{ fileMustExist: false }

machen.
Dann wird die Datenbank-Datei neu angelegt. Vielleicht hilft das, zu erkennen, wo better-sqlite3 die Datenbank-Datei erwartet... Natürlich ist dann der Inhalt der neu angelegten Datenbank falsch aber zur Fehlersuche evtl. hilfreich...

@martin_olw Das dauert manchmal etwas, bis die Einstellungen der whitelist vom DasWetter-Server übernommen werden.
wie hier geschrieben:
https://forum.iobroker.net/topic/77220/vis-2-widgets-für-daswetter-und-heatingcontrol/39
ist der Port wichtig Das ist der Port, auf dem die Vis erreichbar ist

Es scheint, dass es user gibt, bei denen die API von DasWetter.com noch ohne Probleme funktioniert. Bei mir ist das auch der Fall. Leider habe ich keinen Einfluß und auch keinen direkten Kontakt mehr, so dass ich derzeit nicht sagen kann, ob die Einschränkung nur vorübergehend ist, ob es nur bestimmte user betrifft oder ob die komplette Abschaltung bevorsteht.

Fakt ist, die API wird nicht mehr offiziell angeboten, stattdessen wird auf ein neues widget (https://www.daswetter.com/users/widget) verwiesen. Dieses widget habe ich für vis-2 fit gemacht. Das hilft aber nur den usern, die eine reine Anzeige der Vorhersage benötigen. Auf die einzelnen Werte kann man so nicht zugreifen...

Es gab auf den Seiten von DasWetter.com mal eine Ankündigung, dass sie die API überarbeiten. Ob das noch aktuell und ein Plan ist, kann ich nicht sagen...

@holgerwolf sagte in Vis-2 widgets für DasWetter und Heatingcontrol:

VIS-2 ist 2.9.64

Ich habe bei mir auch die 2.9.64 von vis-2 installiert und da habe ich den gleichen Fehler. Nach update auf 2.11.2 funktionieren die widgets wieder...