wichtiges UPDATE für controller 7.2.2 im stable

[mehrwiedu]

Hallo zusammen,

ich möchte euch einen möglichen neuen, noch jungen ioBroker-Adapter für smarte Geräte von DREO vorstellen, den ich aus eigenem Bedarf zunächst privat entwickelt habe. Nun hat er aber einen Stand erreicht, so dass er anderen Usern eventuell auch einen Nutzen bringen könnte:

(hoffe, ich darf das hier ohne vorherige Absprache einfach posten)

GitHub:
https://github.com/mehrwiedu/ioBroker.dreo

Der Adapter ist ursprünglich aus einem persönlichen Bedarf entstanden. Ich verwende mehrere DREO-Deckenventilatoren und wollte sie nicht nur über die DREO-App oder per Alexa steuern, sondern auch direkt in ioBroker einbinden.

Mein konkretes Ziel war vor allem die Bedienung über klassische Wandtaster. Bei mir kommen dafür Shelly 1 Gen4 zum Einsatz. Ein kurzer, doppelter, dreifacher oder langer Tastendruck kann dadurch beispielsweise Licht, Ventilator, Geschwindigkeit und Helligkeit steuern.

Die Sprachsteuerung war für mich weniger der Schwerpunkt, da der offizielle Alexa-Skill von DREO bereits sehr gut funktioniert und die Sprachbedienung damit bereits zuverlässig abgedeckt ist.

Eigene TypeScript-SDK als Grundlage

Der ioBroker-Adapter greift nicht direkt und unstrukturiert auf die DREO-Cloud zu. Ich habe zunächst eine eigene TypeScript-SDK entwickelt:

@mehrwiedu/dreo-api

Darauf setzt der ioBroker-Adapter als möglichst dünne Integrationsschicht auf.

Voraussetzung: separater DREO-E-Mail-Account

Für die Nutzung des Adapters wird derzeit ein separater DREO-Account benötigt, der klassisch mit E-Mail-Adresse und Passwort angelegt wurde.

Der eigentliche Hauptaccount kann weiterhin beliebig eingerichtet sein, beispielsweise über Apple Login, Google Login oder E-Mail und Passwort. Dieser Hauptaccount wird jedoch nicht direkt im Adapter verwendet.

Stattdessen wird ein zweiter DREO-Account auf E-Mail-Basis angelegt. Anschließend wird das komplette DREO-Zuhause vom Hauptaccount mit diesem Zweitaccount geteilt. Im Adapter werden dann die Zugangsdaten dieses Zweitaccounts hinterlegt.

Ich habe diesen Weg bewusst so gewählt, weil es meiner Philosophie entspricht, den produktiv genutzten Hauptaccount von ioBroker und der SDK zu trennen. So bleibt der eigentliche DREO-Zugang unabhängig vom Adapter bestehen. Auch bei möglichen Störungen, Fehlern oder Wartungsarbeiten an ioBroker oder der SDK soll die Bedienung über die offizielle DREO-App weiterhin zuverlässig möglich sein.

Der aktuell zuverlässig getestete Ablauf ist daher:

1. Zweitaccount mit E-Mail-Adresse und Passwort anlegen.
2. Das gesamte DREO-Zuhause mit diesem Account teilen.
3. Die Zugangsdaten des Zweitaccounts im ioBroker-Adapter eintragen.

Ob auch das Teilen einzelner Geräte dauerhaft und zuverlässig funktioniert, ist derzeit noch nicht abschließend geprüft. Für den aktuellen Stand sollte deshalb das vollständige Zuhause geteilt werden.

Parallele Bedienung über verschiedene Steuerwege

Die DREO-Geräte können weiterhin unabhängig über verschiedene Wege bedient werden:

• über die DREO-App mit dem Hauptaccount
• über die DREO-App mit dem geteilten Zweitaccount
• über die jeweilige Fernbedienung
• über Alexa-Sprachbefehle bei aktiviertem DREO-Skill
• über ioBroker und den DREO-Adapter

Diese Steuerwege behindern sich nicht gegenseitig. Änderungen, die über einen der Wege vorgenommen werden, werden über die Cloud beziehungsweise die WebSocket-Verbindung übernommen. Dadurch stehen in ioBroker und in den DREO-Apps jeweils die aktuellen und korrekten Gerätezustände zur Verfügung.

Die SDK übernimmt unter anderem:

• Anmeldung an der DREO-Cloud
• Token-Erneuerung
• Geräteerkennung
• Auflösung der Gerätefähigkeiten
• WebSocket-Verbindung für Statusänderungen
• Wiederverbindung nach Verbindungsabbrüchen
• Lesen und Schreiben von Gerätezuständen

Die Trennung zwischen SDK und Adapter war mir wichtig, damit die eigentliche DREO-Logik nicht fest mit ioBroker verbunden ist und gegebenenfalls auch in anderen Projekten genutzt werden kann.

Aktuell getestete Geräte

Der Adapter wird derzeit mit folgenden Geräten praktisch getestet:

• DREO DR-HCF007S Deckenventilator
• DREO DR-HPF002S Standventilator
• DREO DR-HHM001S Luftbefeuchter

Bei mir werden aktuell fünf Geräte zuverlässig erkannt:

• drei DR-HCF007S Deckenventilatoren
• ein DR-HPF002S Standventilator
• ein DR-HHM001S Luftbefeuchter

Die Geräte werden über die DREO-Cloud erkannt und Statusänderungen über eine WebSocket-Verbindung an ioBroker übertragen.

Aktueller Schwerpunkt

Mein bisheriger Schwerpunkt lag bewusst auf den Basisfunktionen der Deckenventilatoren.

Dazu gehören insbesondere:

• Ventilator ein und aus
• Geschwindigkeitsstufe
• Betriebsmodus
• Hauptlicht ein und aus
• Helligkeit des Hauptlichts
• Farbtemperatur
• Atmosphärelicht
• Timer
• Stummschaltung

Einige Hauptfunktionen des getesteten Standventilators sind noch nicht vollständig als benutzerfreundliche States umgesetzt beziehungsweise noch nicht abschließend zugeordnet.

Der Standventilator wird bereits erkannt und kann grundsätzlich gesteuert werden. Die genaue Bedeutung einzelner Rohwerte muss jedoch noch vollständig verifiziert und anschließend sauber in die Friendly-State-Struktur übertragen werden.

Geräteabhängige Datenpunkte

Der Adapter legt nicht bei jedem Gerät pauschal dieselben Datenpunkte an. Die Struktur richtet sich nach den tatsächlich erkannten Fähigkeiten des jeweiligen Geräts.

Beispiele für derzeitige Friendly States sind:

• power.on
• fan.on
• fan.speed
• fan.mode
• fan.oscillationMode
• light.main.on
• light.main.brightness
• light.main.colorTemperature
• light.atmosphere.on
• light.atmosphere.brightness
• light.atmosphere.preset
• display.on
• timer.on
• timer.off
• settings.mute
• settings.childLock

Ein Standventilator bekommt beispielsweise nicht automatisch ein vermeintliches Hauptlicht, nur weil das Gerät intern einen Zustand mit einem ähnlich klingenden Namen meldet.

Auch der Luftbefeuchter wird nicht fälschlich als Ventilator dargestellt.

Zusätzlich stehen die von DREO gelieferten Rohzustände weiterhin zur Verfügung. Neue oder noch nicht eindeutig verstandene Funktionen können dadurch zunächst beobachtet werden, bevor sie einen benutzerfreundlichen Datenpunkt erhalten.

Friendly States werden noch weiter überarbeitet

Die aktuelle Friendly-State-Struktur ist noch nicht endgültig.

Bei einigen Funktionen hat sich erst durch praktische Tests gezeigt, dass die interne Bezeichnung von DREO nicht direkt als verständlicher ioBroker-State übernommen werden sollte.

Ein Beispiel ist die Displayfunktion des Standventilators.

Der interne Wert entspricht nicht einfach einem klassischen Display an oder Display aus.

Die Logik ist vielmehr:

• false: Das Display schaltet sich nach einer gewissen Zeit automatisch aus.
• true: Das Display bleibt dauerhaft eingeschaltet.

Der derzeitige Friendly State display.on ist deshalb wahrscheinlich nicht präzise genug benannt. Eine verständlichere Bezeichnung wäre beispielsweise:

display.alwaysOn

oder eine vergleichbare Bezeichnung, die das tatsächliche Verhalten besser beschreibt.

Auch andere numerische Werte sollen künftig verständlicher dargestellt werden.

Verständliche Bezeichnungen für Betriebsarten

Der State fan.mode enthält derzeit einen numerischen Wert. Diese Zahlen entsprechen jedoch konkreten Betriebsarten wie beispielsweise:

• Normal
• Turbo
• Schlaf
• Natur
• weitere gerätespezifische Modi

Die genaue Zuordnung kann je nach Gerätetyp und Firmware unterschiedlich sein und muss deshalb zunächst zuverlässig verifiziert werden.

Anschließend sollen die Zahlenwerte in ioBroker mit verständlichen Bezeichnungen versehen werden.

Technisch soll weiterhin mit den ursprünglichen Zahlenwerten gearbeitet werden. In ioBroker, VIS oder anderen Oberflächen könnte dann aber direkt angezeigt werden, welche Betriebsart hinter dem aktuellen Wert steht.

Beispielhaft:

1 = Normal
2 = Turbo
3 = Schlaf
4 = Natur

Die tatsächliche Zuordnung wird erst übernommen, wenn sie für den jeweiligen Gerätetyp bestätigt wurde.

Verständliche Anzeige der Oszillation

Auch fan.oscillationMode wird derzeit als numerischer Wert dargestellt.

Beim getesteten Standventilator beschreiben die Werte voraussichtlich:

0 = Aus
1 = Horizontal
2 = Vertikal
3 = Horizontal und vertikal

Auch hier soll der ursprüngliche Zahlenwert erhalten bleiben, damit Skripte und Automationen weiterhin eindeutig damit arbeiten können.

Im ioBroker-Objektbaum, in VIS oder anderen Oberflächen soll aber zusätzlich beziehungsweise über eine Werteliste direkt erkennbar sein, welcher Oszillationsmodus aktiv ist.

Aus meiner Sicht wäre es dafür am sinnvollsten, die Zahlenwerte über die ioBroker-Metadaten mit sprechenden Bezeichnungen zu hinterlegen. Dadurch bleibt der State numerisch und beschreibbar, während Oberflächen gleichzeitig die verständliche Bedeutung anzeigen können.

Ein separater zusätzlicher Infostate wäre dann wahrscheinlich nicht erforderlich.

Unterschied zur Home-Assistant-Integration

Der Adapter ist keine Portierung der bestehenden Home-Assistant-Integration.

Mein Ansatz besteht aus einer eigenständigen TypeScript-SDK und einem darauf aufbauenden ioBroker-Adapter.

Der Schwerpunkt liegt auf:

• einer sauberen Trennung zwischen DREO-Logik und ioBroker
• automatischer Erkennung der Gerätefähigkeiten
• WebSocket-basierten Echtzeitaktualisierungen
• ioBroker-typischen, beschreibbaren States
• der Einbindung in eigene Skripte und Wandtastersteuerungen
• dem Erhalt der Rohdaten für Analyse und spätere Erweiterungen
• einer geräteabhängigen Friendly-State-Struktur

Die bestehende Home-Assistant-Integration war natürlich ein wichtiger Hinweis darauf, dass sich DREO-Geräte grundsätzlich in ein Smart-Home-System integrieren lassen.

Die Architektur, die TypeScript-SDK und die konkrete Umsetzung dieses Projekts sind jedoch eigenständig.

Beispiel: Steuerung über einen Shelly-Wandtaster

Bei mir ist ein Shelly 1 Gen4 hinter einem klassischen Wandtaster verbaut.

Die Bedienung eines DREO-Deckenventilators ist beispielsweise so aufgebaut:

• einfacher Tastendruck: Hauptlicht ein oder aus
• doppelter Tastendruck: Ventilator ein oder aus
• dreifacher Tastendruck: Geschwindigkeitsstufe wechseln
• langer Tastendruck: Helligkeit des Hauptlichts wechseln

Die Steuerung läuft direkt über die States des DREO-Adapters.

Eine zusätzliche Infrarot- oder Funkfernbedienung ist dadurch für diese Bedienung nicht mehr erforderlich. In meinem bisherigen Aufbau wurden zwei Deckenventilatoren noch über einen Broadlink angesteuert. Diese Steuerung kann nun vollständig durch den DREO-Adapter ersetzt werden.

Der Broadlink, den ich im Anfang dafür benutzt habe, wird in meinem Aufbau damit nicht mehr benötigt. Zumal es damit auch teilweise raumübergreifend hier und da mal ein Sendeproblem gab und der WAF darunter sehr gelitten hat.

Aktueller Stand

Der Adapter befindet sich noch in einer frühen Entwicklungs- und Testphase.

Bereits umgesetzt und praktisch geprüft sind unter anderem:

• Installation direkt aus dem öffentlichen GitHub-Repository
• automatische Installation der SDK über npm
• Anmeldung in der EU-Region
• Erkennung mehrerer DREO-Gerätetypen
• WebSocket-Verbindung
• Statusaktualisierungen
• beschreibbare Datenpunkte
• geräteabhängige Objektstruktur
• Wiederanmeldung nach abgelaufenen Tokens
• Wiederverbindung nach WebSocket-Abbrüchen
• Steuerung von Deckenventilatoren über Friendly States
• Steuerung über Shelly-Wandtaster und JavaScript

Der aktuelle Versionsstand ist zunächst: 0.1.0

Noch offene Punkte

Zu den nächsten Schritten gehören unter anderem:

• weitere Funktionen des Standventilators zuordnen
• Friendly States weiter überarbeiten
• numerische Betriebsarten mit verständlichen Bezeichnungen versehen
• Oszillationsmodi verständlich darstellen
• Funktionen des Luftbefeuchters genauer zuordnen
• weitere beschreibbare States systematisch testen
• Grenzwerte und Abhängigkeiten prüfen
• automatisierte Adaptertests ergänzen
• weitere DREO-Geräte testen
• dynamische Erkennung neu hinzugefügter Geräte weiter ausbauen
• Dokumentation erweitern

Installation zum Testen

Der Adapter kann derzeit direkt aus GitHub installiert werden:

https://github.com/mehrwiedu/ioBroker.dreo

Die SDK ist als npm-Paket verfügbar und wird bei der Installation des Adapters automatisch mit installiert:
@mehrwiedu/dreo-api

Da es sich noch um eine frühe Version handelt, sollte der Adapter vorerst nur von Anwendern getestet werden, die mit GitHub-Installationen, ioBroker-Logs und der ioBroker-Objektstruktur vertraut sind.

Rückmeldungen zu weiteren Geräten

Ich freue mich besonders über Rückmeldungen zu weiteren DREO-Geräten.

Interessant wären dabei insbesondere:

• genaue Modellbezeichnung
• erkannte Datenpunkte
• Rohzustände des Geräts
• fehlende Funktionen
• unpassend zugeordnete Friendly States
• Ergebnisse von Schreibtests
• Logausgaben bei Problemen

Bitte keine DREO-Zugangsdaten, Tokens oder andere persönliche Daten im Forum veröffentlichen.

Das Projekt ist aus meinem eigenen Smart-Home-Setup und meinen persönlichen Anforderungen entstanden. Ich möchte es aber gerne so weiterentwickeln, dass auch andere ioBroker-Nutzer ihre DREO-Geräte sinnvoll und möglichst verständlich einbinden können.

Falls das hier nicht gewünscht ist oder in einem falschen Unterforum steht, bitte ich es zu verschieben oder zu löschen. Ich bin zwar schon sehr lange Mitglied hier im Forum, aber eher im Hintergrund aktiv und nicht wirklich in einer aktiven Entwickler Rolle unterwegs. Dieses Projekt hielt ich aber für teilenswert und wollte es daher der Community nicht vorenthalten.

Gruß, mehrwiedu

[mcm1957]

⚠ ACHTUNG - pre-alpha Adapter mit Namenskonflikt⚠

Dieser Adapter ist derzeit noch im Zustand PRE-ALPHA. Es fehlen derzeit zahlreiche Standardkomponenten eines ordnungsgemäßen Adapters. Insbesondere sind die verpflichtenden Standardtests nicht vorhanden oder werden nicht erfolgreich ausgeführt. Weiters ist der Name ioBroker.dreo bereits vom Adapter https://github.com/alexandertartler-web/ioBroker.dreo belegt sodass eine Veröffentlichung des hier angebotenen Adapters auf npm oder im Repository unter diesem Namen nicht möglich ist.

Von einer Installation muss derzeit für produktive Zecke und für Benutzer die sich nicht als 'Early - Tester' einstufen explizit abgeraten werden.

@mehrwiedu
Damit's nicht falsch rüber kommt:

DANKE dass du Zeit für einen ioBroker Adapter aufwendest.

Bitte RENAME den Adapter sodass er einen verfügbaren Namen verwendet. Sinnvollerweise solltes du zum Neuanlegen des Repositories den adapter creator verwenden damit auch alle derzeit fehlenden Komponenten - insbesondere testing - gleich richtig angelegt werden. Bitte auch durchlesen https://github.com/Jey-Cee/iobroker-ai-developer-guide.

Falls es Fragen gibt bitte in unseren Telgramm oder Discord Entwicklerchannels melden. Invites auf www.iobroker.dev.

P.S. Eine Parallelentwicklung ist hier durchaus sinnvoll da der Adapter von alexandertartler-web leider im review hängt und der Dev bisher nicht reagiert hat.

[mehrwiedu]

Vielen Dank für dein ausführliches Feedback und auch für die aufmunternden Worte!

Du hast mit deinen Punkten absolut recht. Der Adapter ist in erster Linie aus meinem eigenen Bedarf entstanden und läuft inzwischen produktiv bei mir zu Hause. Deshalb lag mein Fokus bisher vor allem auf einer sauberen SDK-Architektur und der eigentlichen Funktionalität – weniger auf den formalen Anforderungen für eine offizielle Aufnahme in das ioBroker-Repository.

Den bereits existierenden DREO-Adapter von Alexander habe ich tatsächlich erst gestern entdeckt. Bis dahin war ich davon ausgegangen, dass es aktuell noch keinen nativen ioBroker-Adapter für DREO gibt. Deshalb ist meine Implementierung völlig unabhängig entstanden. Ich habe Alexander inzwischen kontaktiert und würde mich freuen, wenn sich daraus eine Zusammenarbeit ergibt. Bevor zwei Projekte dauerhaft parallel laufen, sollte man zumindest miteinander gesprochen haben.

Die Hinweise zum Adapter Creator, den fehlenden Standardtests und den weiteren Anforderungen für eine offizielle Veröffentlichung nehme ich gerne mit. Das ist auf jeden Fall mein Ziel, sobald die eigentliche Entwicklung etwas weiter fortgeschritten ist. Vielen Dank auch für den Link zum AI Developer Guide und den Hinweis auf die Entwicklerkanäle – das schaue ich mir in Ruhe an.

Unabhängig davon wird das zugrunde liegende TypeScript-SDK natürlich weiterentwickelt. Der Adapter selbst ist bewusst sehr schlank gehalten und nutzt dieses SDK als Grundlage. Dadurch lassen sich neue Geräte und Funktionen künftig deutlich einfacher ergänzen.

Nochmals vielen Dank für das konstruktive Feedback und die Unterstützung!

[mcm1957]

@mehrwiedu
Schön dass dich mein Feedback nicht verwirrt / belastet hat. Es ist immer schwer die richtigen Worte zu finden.

Persönlich glaube ich, dass dein Adapter gerne angenommen werden wird da es mir leider nicht gelungen ist den Dev des existierenden Adapters zu einer Reaktion zu veranlassen (und wenn es nur ein "ich mach erst im Oktober weiter" wäre) und ich keinen betriebsbereiten Adapter für 'dreo' kenne.

Bitte frag wirklich wenn du wo Hilfe brauchts oder Fragen hast.

Persönlich würde ich dir raten den Adapter unter einem freien Namen mittels adapter creator neu anzulegen und dann die Codeteile in diesen Adapter "rüberzukopieren". Damit ersparts du dir das Ändern des Repos und des Namens an diversen Stellen und das Standardsetup sollte dann auch gleich passen.

Aber wie gesagt - meine persönliche Meinung dazu. Andere arbeiten anders und das ist auch ok.

Falls ich hier im Forum grad mal weniger aktiv bin, erreichts du mich via Telegramm Devchannel (auch mcm1957 dort)

mcm1957

P.S: Wenn Alexander den Namen freigibt ist das natürlich auch OK diesen zu verwenden. npm erlaubt nur (im Setup das ioBroker benutzt) keine 2 Adapter mit demselen Namen.