Monatsrückblick Oktober 2026 ist online!

[mrdimixx]

Aktuelle Test Version | V0.6.1
Veröffentlichungsdatum | 24.10.2026
Github Link | https://github.com/mrdimixx/ioBroker.remko

Hallo zusammen,

der Adapter ioBroker.remko ist jetzt im latest-Repository verfügbar und ich suche Tester.

Was macht der Adapter?
Er liest und steuert REMKO Wärmepumpen mit Smart-Web / Smart-Control (Firmware 4.26 und neuer)
lokal über MQTT – ohne Cloud und ohne zusätzlichen MQTT-Broker. Alles, was er braucht
(Zugangsdaten, Register-Datenbank mit Einheiten, Grenzen und Texten), liest er direkt aus der
Weboberfläche der Wärmepumpe.

• Datenpunkte folgen dem Menü der Steuerung (Information, Einstellungen, Status, Übersicht …)
• wie in der Weboberfläche werden nur Werte angelegt, die bei eurer Anlage tatsächlich vorhanden sind
• eigener Ordner für den Kältekreis (Heißgas, Sauggas, Flüssigkeit, Verdampfer, Expansionsventil, 4-Wege-Ventil)
• Schreiben wählbar: aus / nur Benutzermenü (empfohlen) / alle Parameter
• optional zusätzlich Service-, Experten- und Inbetriebnahme-Menü

Voraussetzungen

• REMKO Wärmepumpe mit Smart-Web / Smart-Control, Firmware 4.26 oder neuer
• Weboberfläche der Wärmepumpe im Netzwerk erreichbar (IP-Adresse eintragen, mehr braucht es meist nicht)

Getestet mit: REMKO WKF 100, Smart-Web Firmware 4.28.
Rückmeldungen zu anderen Modellen (WKF, WSP, LWM, KWT …) sind sehr willkommen!

Hinweis für Umsteiger von älteren Versionen: Seit 0.6.x sind die Objekt-IDs englisch
(z. B. settings.domestic_hot_water statt einstellungen.warmwasser). Alte Objekte werden
automatisch entfernt, History-Einstellungen werden übernommen – Skripte und VIS müssen
aber angepasst werden.

Links

• GitHub: https://github.com/mrdimixx/ioBroker.remko
• npm: https://www.npmjs.com/package/iobroker.remko

Fehler bitte am besten als Issue auf GitHub melden, gern mit Debug-Log und Angabe von
Wärmepumpenmodell und Firmware-Version.

Gruß mrdimixx

[Bluefox]

@mrdimixx Danke, schön dass es jetzt einen lokalen REMKO-Adapter gibt.

Zwei Punkte vom kurzen Blick ins Repo:

• applyLayout() läuft nach jedem Vollabgleich und löscht alle Objekte, die laut Anzeigebedingung gerade nicht sichtbar sind. Wenn ein Register aus der Bedingung in diesem Durchlauf nicht geantwortet hat, wird der Wert zu NaN und die Bedingung damit false. Dasselbe passiert, wenn der Nutzer z. B. den Betriebsmodus umstellt. Der Datenpunkt verschwindet dann samt common.custom, also History-Einstellungen, und kommt später ohne sie wieder. Skripte und VIS, die darauf zeigen, hängen in der Zwischenzeit auch in der Luft. Ich würde Objekte nur beim Start bzw. bei der Migration auf die neuen IDs löschen, im laufenden Betrieb höchstens neue anlegen. Oder ausgeblendete Werte per Schalter stehen lassen.
• this.client.on('message', ...) ruft das async onMessage() ohne catch auf. Wirft dort z. B. setStateAsync einen Fehler, gibt das eine unhandled rejection und der Adapter wird neu gestartet. Ein .catch(e => this.log.error(...)) reicht da.

[mrdimixx]

@Bluefox Danke für den Blick in den Code – beide Punkte waren berechtigt und sind in v0.6.2 behoben:

• Objekte werden im laufenden Betrieb nicht mehr gelöscht, nur noch neue angelegt.
  Werte, die gerade durch eine Anzeigebedingung ausgeblendet sind (Register hat noch nicht
  geantwortet, Betriebsmodus umgestellt …), behalten ihr Objekt samt common.custom und werden
  weiter aktualisiert. Beim Start werden nur noch wirklich veraltete Objekte entfernt: alte IDs
  nach einer Umbenennung, Register, die mit der eingestellten Menüstufe gar nicht vorkommen
  können, und leere Ordner.
• onMessage() hat jetzt ein catch – Fehler landen im Log statt als unhandled rejection.

v0.6.2 ist auf npm veröffentlicht und läuft bei mir.

Gruß mrdimixx