Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[mehrwiedu]

Aktualisierung: Der hier ursprünglich genannte Prototyp ioBroker.dreo wurde eingestellt und archiviert.
Die Weiterentwicklung erfolgt unter:
https://github.com/mehrwiedu/ioBroker.dreo-cloud
Aktuelle npm-Version: iobroker.dreo-cloud@0.1.1

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:

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:

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.

[mehrwiedu]

@mcm1957

Nein, keine Sorge. Das hat mich in keiner Weise belastet, sondern nur weiter nach vorn gebracht. Ich habe bisher ausschließlich nur für mich entwickelt und tatsächlich war bisher nichts dabei, von dem ich geglaubt hätte, dass es auch anderen nützlich sein könnte. Dazu waren die UseCases meist viel zu speziell auf meine Bedürfnisse abgestellt. Auch mein SDK war im Anfang nur eine fixe Idee zur Umsetzung von Schaltereignissen. Somit ist dieses Projekt tatsächlich mein erstes öffentliches Projekt. Und man darf mich in dem gesamten Begleitprozess noch als „grün hinter den Ohren“ bezeichnen.

Daher vielen Dank für deine offene Rückmeldung und das konkrete Angebot zur Unterstützung.

Nach deinem Hinweis halte ich es inzwischen ebenfalls für sinnvoll, nicht länger auf eine mögliche Reaktion des anderen Entwicklers zu warten. Ob und wann der Name dreo tatsächlich frei wird, ist derzeit nicht absehbar. Die eigentliche Weiterentwicklung sollte davon nicht abhängig sein.

Ich werde den Adapter daher zeitnah unter einem freien Namen mit dem Adapter Creator neu anlegen und die bereits funktionierenden Bestandteile anschließend kontrolliert übernehmen.

Das bestehende Projekt bleibt dabei zunächst als funktionierende Referenz erhalten. Die eigentliche DREO-Logik liegt ohnehin in meinem separaten TypeScript-SDK, sodass der neue ioBroker-Adapter weiterhin nur eine schlanke Integrationsschicht darauf bilden wird.

Sollte Alexander den ursprünglichen Namen später doch freigeben, könnte man die Situation noch einmal bewerten. Ich möchte die weitere Arbeit daran aber nicht mehr von dieser ungewissen Entscheidung abhängig machen.

Vielen Dank auch für dein Hilfsangebot. Darauf werde ich bei Fragen zum Creator, zu den Standardtests oder zum Review-Prozess sicherlich gerne zurückkommen.

Gruß, mehrwiedu

[mehrwiedu]

Update: Adapter neu aufgebaut und öffentlich veröffentlicht

Hallo zusammen,

ich möchte ein kurzes Update zum aktuellen Stand geben.

Die Hinweise zum Namenskonflikt, zum Adapter Creator und zu den fehlenden Standardkomponenten habe ich vollständig aufgegriffen.

Der bisherige Prototyp ioBroker.dreo wurde nicht weitergeführt. Das alte Repository ist inzwischen als veraltet gekennzeichnet und archiviert.

Der Adapter wurde unter einem neuen, freien Namen mit dem aktuellen ioBroker Adapter Creator vollständig neu aufgebaut:

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

npm:
https://www.npmjs.com/package/iobroker.dreo-cloud

Aktuelle Version:
0.1.1

Der neue Paketname lautet:

iobroker.dreo-cloud

Der Namespace in ioBroker lautet:

dreo-cloud

Was inzwischen umgesetzt wurde

Der neue Adapter enthält jetzt unter anderem:

• die aktuelle ioBroker-Adapterstruktur
• vollständige Paket- und Adaptermetadaten
• Admin-Konfiguration für EU- und US-Region
• TypeScript-Prüfung und ESLint
• automatisierte Paket- und Konfigurationstests
• Tests mit Node.js 22 und 24
• Tests unter Linux, Windows und macOS
• GitHub Actions für Prüfung und Veröffentlichung
• npm Trusted Publishing mit Provenance
• automatischen GitHub-Release bei neuen Versionstags
• FamilyTree-basierte Geräteerkennung
• Unterstützung geteilter DREO-Zuhause
• WebSocket-basierte Live-Aktualisierungen
• automatische Token-Erneuerung
• automatische WebSocket-Wiederverbindung
• bidirektionales Lesen und Schreiben unterstützter States
• Laufzeiterkennung neu hinzugefügter Geräte
• automatische Erzeugung von RAW- und Friendly-States

Produktiv getestet

Der Adapter läuft inzwischen produktiv in meiner eigenen ioBroker-Installation.

Getestet wurden bislang:

• 3 × DREO DR-HCF007S Deckenventilator
• 1 × DREO DR-HPF002S Standventilator
• 1 × DREO DR-HHM001S Luftbefeuchter

Praktisch geprüft wurden unter anderem:

• Geräteerkennung
• WebSocket-Verbindung
• Zustandsänderungen von der DREO-App nach ioBroker
• Schreibzugriffe von ioBroker zu den DREO-Geräten
• Ventilator ein und aus
• Lüftergeschwindigkeit
• Hauptlicht ein und aus
• Helligkeit des Hauptlichts
• automatisches Einschalten abhängiger Funktionen
• Neustart und erneute Verbindung des Adapters

Auch meine Steuerung über Shelly 1 Gen4 Wandtaster wurde mit dem neuen Adapter in allen drei Räumen erfolgreich getestet:

• einfacher Tastendruck: Hauptlicht ein oder aus
• doppelter Tastendruck: Ventilator ein oder aus
• dreifacher Tastendruck: Lüfterstufe wechseln
• langer Tastendruck: Helligkeit wechseln

Installation

Der Adapter kann jetzt direkt über npm beziehungsweise über die Experteninstallation in ioBroker installiert werden.

Paketname:

iobroker.dreo-cloud

Repository:

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

npm:

https://www.npmjs.com/package/iobroker.dreo-cloud

Eine Installation aus dem alten Repository ioBroker.dreo sollte nicht mehr erfolgen.

Die zugrunde liegende TypeScript-SDK wird weiterhin automatisch als Abhängigkeit installiert:

@mehrwiedu/dreo-api

Aktueller Entwicklungsstand

Die Basisfunktionen sind produktiv nutzbar und wurden mit den oben genannten Geräten getestet.

Trotzdem befindet sich das Projekt weiterhin in einer frühen öffentlichen Testphase. Besonders hilfreich wären Tests mit weiteren DREO-Gerätetypen, beispielsweise:

• Luftreiniger
• Heizgeräte
• Klimageräte
• weitere Ventilatoren
• weitere Luftbefeuchter

Der Adapter legt unbekannte beziehungsweise noch nicht eindeutig zugeordnete DREO-Werte zunächst als schreibgeschützte RAW-States an. Dadurch lassen sich neue Geräte untersuchen, ohne Funktionen anhand unsicherer Annahmen zuzuordnen.

Rückmeldungen und Fehlerberichte

Fehlerberichte und Testergebnisse bitte im neuen Repository eintragen:

https://github.com/mehrwiedu/ioBroker.dreo-cloud/issues

Bitte keine DREO-Zugangsdaten, Tokens, vollständigen Seriennummern, WLAN-Daten oder andere persönliche Informationen veröffentlichen.

Vielen Dank nochmals an @mcm1957 für die klaren Hinweise und die Unterstützung. Der Rat, den Adapter mit einem freien Namen und dem aktuellen Adapter Creator neu aufzubauen, war genau der richtige Weg.

Gruß
mehrwiedu

[mcm1957]

DANKE für die Anpassungen und das Feedback.

Bitte passe den TITEL diese Topic an - wenn du Zeit hast. Er sollte lauten:

Test Adapter dreo-cloud V0.1.x

Bitte das nicht als Schikane empfinden. Der passende Titel macht klar um welchen Adapter es genau geht und erleichtert auch die Suche im Forum da mit der Angabe "Test Adapter xxx" dieses Topic rasch gefiunden wird ohne gefühlte 200 Topics zu listen wo in einem Beitrag nur der Adaptername erwähnt wird da ein iob diag Listing drinnen ist.

DANKE

[eubecker]

Hallo,
ich habe meinen Deckenventilator eingebunden, lt. Log sieht alles gut aus, aber weder kann ich den Ventilator steuern, noch ändern sich die Werte, wenn ich am Ventilator per App oder FB was ändere.
Irgendwelche Tipps, was ich tun/gucken kann?

Log-Auzug:
2026-07-25 10:02:49.758 - debug: dreo-cloud.0 (255857) States create System PubSub Client
2026-07-25 10:02:49.760 - debug: dreo-cloud.0 (255857) States create User PubSub Client
2026-07-25 10:02:49.858 - debug: dreo-cloud.0 (255857) States connected to redis: 127.0.0.1:9000
2026-07-25 10:02:50.186 - info: dreo-cloud.0 (255857) starting. Version 0.1.1 in /opt/iobroker/node_modules/iobroker.dreo-cloud, node: v22.23.1, js-controller: 7.2.2
2026-07-25 10:02:50.248 - info: dreo-cloud.0 (255857) DREO Cloud adapter started.
2026-07-25 10:02:50.249 - info: dreo-cloud.0 (255857) Using @mehrwiedu/dreo-api 0.1.0.
2026-07-25 10:02:50.250 - info: dreo-cloud.0 (255857) DREO cloud region configured: EU.
2026-07-25 10:02:50.251 - info: dreo-cloud.0 (255857) Connecting to DREO cloud...
2026-07-25 10:02:50.254 - info: dreo-cloud.0 (255857) [SDK] Logging in against region EU
2026-07-25 10:02:50.515 - debug: dreo-cloud.0 (255857) [SDK] Sending authenticated POST request to /api/app/index/family/room/devices.
2026-07-25 10:02:50.647 - debug: dreo-cloud.0 (255857) [SDK] Sending authenticated GET request to /api/user-device/device/state.
2026-07-25 10:02:50.845 - info: dreo-cloud.0 (255857) [SDK] WebSocket connected.
2026-07-25 10:02:50.847 - info: dreo-cloud.0 (255857) Connected to DREO cloud.
2026-07-25 10:02:50.848 - debug: dreo-cloud.0 (255857) [SDK] Sending authenticated POST request to /api/app/index/family/room/devices.
2026-07-25 10:02:50.932 - debug: dreo-cloud.0 (255857) [SDK] Sending authenticated GET request to /api/user-device/device/state.
2026-07-25 10:02:50.968 - info: dreo-cloud.0 (255857) Resolved 1 DREO device(s).
2026-07-25 10:02:50.969 - debug: dreo-cloud.0 (255857) DREO device serial number: xxxx
2026-07-25 10:02:50.969 - info: dreo-cloud.0 (255857) DREO device: Propeller (DR-HCF001S)
2026-07-25 10:03:05.861 - debug: dreo-cloud.0 (255857) [SDK] DREO WebSocket keepalive sent.

Ergänzung: Auf GitHub habe ich gelesen, dass man einen 2. Account braucht, den man im Adapter angibt. Ist das noch aktuell?
Falls ja: Wie mache ich das?
Ich habe einen 2. Account angelegt und in der App mit dem 1. Account einen "Teilen-Link" erstellt. Wenn ich den anklicke, lande ich aber auf der dreo-Website, wo steht, dass ich ein Gerät teilen will. Aber wie kann ich das annehmen? Wenn ich auf dem Tab, wo ich mit dem 2. Account in der Dreo-App angemeldet bin, nachschaue, ist da nichts zu sehen und einen "internen Posteingang in der App finde ich nicht.