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

[mehrwiedu]

@eubecker

Vielen Dank für die Infos. Ich werte das gerade einmal gegen die Funktionen des Adapters aus.

Da es bei Dir keinen poweron State gibt, habe ich bereits eine Vermutung, muss das aber noch verifizieren. Was mir dabei noch helfen könnte, wären Screenshots aus der DREO App, welche Optionen Dir dort zur Verfügung stehen. So wie hier bei mir, wo der poweron State quasi ein globaler Ein/Aus Schalter für alle Funktionen des Ventilators ist. Bedeutet, wenn Rotor auf Stufe 1 läuft und Mainlight auf 30% an ist und mit poweron ausgeschaltet wird, setzt poweron = true beim Einschalten auch wieder den Fan auf Stufe 1 und Mainlight auf an und 30% Brightness.
Das ist aber die DREO Logik und nicht explizit in der SDK entwickelt.

Ich habe nur diese Logik der Abhängigkeit von poweron mit übernommen, da es bei allen meinen Ventilatoren der Fall ist und ich das als Standard aller Ceiling Fans mit Licht angenommen hatte. Da es nun wahrscheinlich nachweislich nicht bei allen Ventilatoren so von DREO umgesetzt ist, muss ich diese Abhängigkeit wahrscheinlich auflösen und anders implementieren.

Auch könntest Du noch einen Screenshot anhängen, der die vom Adapter angelegten Friendly States zeigt. Also einmal neben den RAW States den gesamten Baum. Aber bitte Seriennummern usw. vorher unkenntlich machen, falls sie sichtbar sind.

[eubecker]

@mehrwiedu sagte:
Da es bei Dir keinen poweron State gibt, habe ich bereits eine Vermutung, muss das aber noch verifizieren. Was mir dabei noch helfen könnte, wären Screenshots aus der DREO App,
Tja, meiner hat keinen Hauptschalter wie es scheint (außer dem radikalen an der Wand :-) )
Er merkt sich den letzte Status, also mach Strom aus/an das, was bei dir wohl zusätzlich der poweron macht.

Auch könntest Du noch einen Screenshot anhängen, der die vom Adapter angelegten Friendly States zeigt. Also einmal neben den RAW States den gesamten Baum.

Was meinst du damit? In meinem letzten Post waren ZWEI Bilder, das 2. eingeklappt (warum auch immer..gefunden und korrigiert), ist es das was du suchst?

[mehrwiedu]

@eubecker

vielen Dank nochmal für Deine Meldung hier im Forum und vielen Dank für die bisherigen Tests und die Logs – die waren tatsächlich sehr hilfreich.

Ich habe soeben ein GitHub-Issue dafür angelegt und ich werde das Verhalten im SDK genauer untersuchen.

Im Moment sieht es danach aus, dass dein DR-HCF001S im Gegensatz zu den anderen Deckenventilatoren (z. B. DR-HCF007S) keinen poweron-State bereitstellt.

Die RAW-States werden bei dir korrekt aktualisiert (fanon, lighton, windlevel, mode, brightness usw.), der Adapter erhält also alle Änderungen. Die aufbereiteten (“Friendly”) States scheinen sich momentan jedoch noch auf die Existenz von poweron zu verlassen. Genau das möchte ich jetzt korrigieren, damit möglichst alle Gerätegenerationen sauber unterstützt werden.

Eine Bitte hätte ich noch:

Falls dir in der DREO-App ein Firmware-Update angeboten wird, installiere es bitte vorerst nicht.

Selbst wenn ein Firmware-Update das Verhalten ändern oder einen poweron-State hinzufügen sollte, möchte ich den Adapter so entwickeln, dass auch Geräte mit älterer Firmware vollständig unterstützt werden. Ich möchte keine Kompatibilität erzwingen, indem der Adapter ein Firmware-Update voraussetzt.

Als Nächstes werde ich auf Basis deiner Rückmeldungen eine Testversion des SDK bzw. Adapters erstellen, in der ich diese Gerätegeneration speziell berücksichtige.

Sobald diese Testversion fertig ist, melde ich mich hier im Thread mit einer Schritt-für-Schritt-Anleitung, wie du sie bei dir installieren kannst. So können wir die Lösung gemeinsam verifizieren, bevor sie in eine offizielle Version des Adapters einfließt.

Vielen Dank nochmals für deine Unterstützung. Solche Rückmeldungen sind für das Projekt enorm wertvoll, weil dadurch Unterschiede zwischen verschiedenen Gerätegenerationen erkannt werden und man den Adapter robuster für alle DREO-Nutzer machen kann.

Gruß
mehrwiedu

[mehrwiedu]

@eubecker sagte:

Was meinst du damit? In meinem letzten Post waren ZWEI Bilder, das 2. eingeklappt (warum auch immer..gefunden und korrigiert), ist es das was du suchst?

Ja, exakt. Das war, was ich meinte. Nun habe ich aber tatsächlich zunächst alle Infos beieinander um Dir eine entsprechende Testumgebung aufzubauen, wenn ich das SDK um die Abhängigkeit des poweron States gefixt habe.

Interessanterweise haben mein Standventilator und sogar der Luftbefeuchter ebenfalls einen poweron State und daher hatte ich diese Voraussetzung als gegeben angenommen. Eventuell hat es auch tatsächlich etwas mit einem Firmwarestand zu tun und nicht unbedingt mit der Geräteklasse. Aber wie auch immer dieser Zustand des fehlenden poweron bei Deinem DR-HCF001S zustande kommt, muss das im SDK gefixt werden.

Ich melde mich hier, sobald ich die Änderungen eingebaut habe. Bis dahin, falls in der App angeboten, bitte noch kein Firmware Update machen. Nach unseren Tests und der Implementierung sollte ein Firmware Update unkritisch sein.

[eubecker]

Danke, App meint, die Firmware sei aktuell.

[mehrwiedu]

@eubecker sagte:

Danke, App meint, die Firmware sei aktuell.

Hallo @eubecker ,

vielen Dank nochmal für Deine Rückmeldung und für das Testen des Adapters.

Ich habe inzwischen eine Korrektur implementiert. Das Problem betrifft DREO-Geräte, deren Cloud-Status keinen separaten poweron-Datenpunkt liefert. Dadurch konnten einige Friendly States nicht korrekt arbeiten.

Die Korrektur steht jetzt als Beta zum Testen bereit:

• Adapter: 0.1.2-beta.1
• SDK: 0.1.2

Ich habe die Beta bereits erfolgreich auf meiner produktiven ioBroker-Installation mit meinen DREO-Geräten getestet. Dabei wurden Änderungen weiterhin aus der DREO-App korrekt in den .raw- und .friendly-States übernommen. Ebenso wurden Änderungen über die Friendly States korrekt an die DREO-App und an die physischen Geräte übertragen. Sprich, an den bisherigen Funktionen gab es keine Überraschungen.
Neu hinzugekommen ist die Behandlung von Geräten ohne "poweron" State, die ich nicht testen kann, da mir ein solches Gerät fehlt. Das müsstest Du bitte einmal mit Deinem DR-HCF001S übernehmen.

Installation der Beta

Da sich der Adapter derzeit noch nicht im offiziellen ioBroker-Repository befindet, erfolgt die Installation direkt über npm. Am einfachsten ist es, wenn Du per SSH Zugriff auf Deine ioBroker Installation hast. Hier dann folgenden Befehl eingeben. Einfach kopieren, ins Terminal einfügen und ENTERN.

cd /opt/iobroker

iobroker stop dreo-cloud.0

npm install iobroker.dreo-cloud@0.1.2-beta.1 \
  --save-exact \
  --registry=https://registry.npmjs.org/

iobroker upload dreo-cloud

iobroker start dreo-cloud.0

Bitte prüfe anschließend, ob im Log bzw. in der Adapterliste die Version 0.1.2-beta.1 angezeigt wird.

Falls Du keinen Zugriff über SSH hast oder das so nicht möchtest, wähle den herkömmlichen und meist empfohlenen Weg über den ioBroker Admin:

1. ioBroker Admin öffnen.
2. Zum Bereich Adapter wechseln.
3. Falls nötig, oben rechts den Expertenmodus aktivieren.
4. Auf das GitHub-/Octocat-Symbol klicken.
5. Im Dialog den Reiter NPM auswählen.
6. Als Paketname eingeben: iobroker.dreo-cloud
7. Als Version auswählen oder eintragen: 0.1.2-beta.1
8. Installation starten.
9. Nach Abschluss prüfen, ob in der Adapterliste 0.1.2-beta.1 angezeigt wird
10. Falls die Instanz nicht automatisch wieder läuft, dreo-cloud.0 im Bereich Instanzen starten.

Alternativ kann im selben Dialog je nach Admin-Version auch der vollständige npm-Paketbezeichner eingetragen werden: iobroker.dreo-cloud@0.1.2-beta.1

Was ich gerne kontrollieren würde

1. DREO-App → ioBroker

Bitte ändere die betroffene Funktion in der DREO-App und prüfe:

• Aktualisiert sich der entsprechende State unter .raw?
• Aktualisiert sich der entsprechende State unter .friendly?
• Entspricht der Friendly State dem tatsächlichen Zustand des Geräts?

2. ioBroker → DREO-App und Gerät

Ändere anschließend den entsprechenden Friendly State in ioBroker und prüfe:

• Wird die Änderung in der DREO-App übernommen?
• Reagiert das physische Gerät korrekt?
• Wird der neue Zustand anschließend wieder korrekt nach ioBroker zurückgemeldet?

Falls Dein Gerät weitere Funktionen unterstützt, die auch bereits in Friendly States übersetzt wurden:

• Weitere betroffene Friendly States

Rückmeldung

Hilfreich wären folgende Informationen:

• installierte Adapter-Version = 0.1.2.-Beta.1 ?
• welche Friendly States getestet wurden
• Funktioniert der Weg DREO-App → ioBroker?
• Funktioniert der Weg ioBroker → DREO-App?
• Reagiert das physische Gerät korrekt?
• Gibt es Fehlermeldungen im Adapter-Log?

Wenn die Tests erfolgreich sind, kann ich die Korrektur als stabile Version 0.1.2 veröffentlichen und das GitHub-Issue anschließend schließen.

Vielen Dank für Deine Unterstützung und das ausführliche Testen!

[eubecker]

Installiert hab ich schon mal erfolgreich, Testen folgt morgen. Danke schon mal!

[eubecker]

So, nun getestet...

@mehrwiedu sagte:
installierte Adapter-Version = 0.1.2.-Beta.1 ?

Ja

welche Friendly States getestet wurden
fan/on: geht (steuern und aktualisieren bei Änderung über FB oder App)
fan/speed: geht
fan/mode: aktualiseren geht, ändern nicht, ist readonly, im RAW ebenso
light/main/brightness,colorTemperature,on: geht

Was fehlt, mir aber nicht so wichtig ist: Der Propeller kann Quittungspieps abgeben. Ist im RAW muteon, was RO ist und in den Freindly nicht auftaucht.

Gibt es Fehlermeldungen im Adapter-Log?

Nein.
Insgesamt sieht das schon sehr gut aus!

[eubecker]

eubecker sagte:

Was fehlt, mir aber nicht so wichtig ist: Der Propeller kann Quittungspieps abgeben. Ist im RAW muteon, was RO ist und in den Freindly nicht auftaucht.

Ah, ist wohl unter Settings, aber auch da RO.

[mehrwiedu]

Das hört sich doch schonmal sehr positiv an. Danke für Deine Tests.

Es sind insgesamt noch nicht alle .raw States in Friendly States übernommen. Das wäre dann ein korrekter Zustand in Deinem Objektbaum.

Magst Du mir den vielleicht auch einmal noch als Screenshot mit anhängen?

Der fan.mode ist auch noch nicht übersetzt, da er numerische Werte liefert, die in der App als „Normal, Natur, Schlaf“ auszuwählen sind und teilweise über andere Schaltungen in der App mit beeinflusst werden. Hier bin ich aber generell dran dies auch beschreibbar zu machen. Zumindest wollte ich im ersten Schritt die Funktionen der Fernbedienung abgebildet haben. Dazu gehört natürlich auch muteon und der Fan.mode, bzw. der Timer.

Fokus lag zunächst auf den Main Functions neben App und Fernbedienung eine Schaltung über normale Wandtaster zu realisieren. Licht, Helligkeit, Fan on/off und Geschwindigkeit.

Für weitere und komplexere Bedienungen außerhalb der Sprachsteuerung und App in einer Visualisierung oder WLAN/Zigbee Schalter mit mehr Schaltfunktionen als ich sie über Wandtaster und Shelly realisieren kann, werde ich natürlich auch noch weitere RAW States einbinden. Sie sollten halt nur einen praktischen Nutzen neben der App und der eventuell auch vorhandenen Sprachsteuerung haben. Und hier haben wir wahrscheinlich alle unterschiedliche Ansprüche. 😉

Muteon ist so etwas, wozu man sich einmal entscheidet und dann höchstwahrscheinlich keine Option am Wandtaster benötigt, es wiederkehrend ein oder auszuschalten.

Wenn ich Deine Friendly States (als Screenshot), die jetzt automatisch neu in der Beta angelegt wurden noch mit der tatsächlich umgesetzten Funktion des SDK vergleichen kann, dann kann ich mit Sicherheit sagen, ob dies auch wirklich alle sind, die aktuell angelegt werden und es sukzessive um weitere States ergänzen.

Danke Dir nochmal.

[eubecker]

@mehrwiedu sagte:

Das hört sich doch schonmal sehr positiv an. Danke für Deine Tests.

Ja, super!

Es sind insgesamt noch nicht alle .raw States in Friendly States übernommen. Das wäre dann ein korrekter Zustand in Deinem Objektbaum.

Magst Du mir den vielleicht auch einmal noch als Screenshot mit anhängen?

Der fan.mode ist auch noch nicht übersetzt, da er numerische Werte liefert, die in der App als „Normal, Natur, Schlaf“ auszuwählen sind und teilweise über andere Schaltungen in der App mit beeinflusst werden. Hier bin ich aber generell dran dies auch beschreibbar zu machen.
Das wäre schön, auf jeden Fall interessanter also der Mute, den hatte ich nur der Vollständigkeithalber erwähnt.

Muteon ist so etwas, wozu man sich einmal entscheidet und dann höchstwahrscheinlich keine Option am Wandtaster benötigt, es wiederkehrend ein oder auszuschalten.

Sehe ich auch so.

Danke Dir nochmal.

Ich hab zu danken!

[eubecker]

Ich weiß nicht, ob das immer gleich ist, bei Mode wäre ein "Klartext" schön.

Hier ist
1=Normal
2=Natur
3=Schlaf
4="Umkehren"
Wobei Umkehren=Normal mit umgedrehter Drehrichtung ist. Warum es 2+3 nicht mit der Aufwärts-Richtung gibt, weiß wohl nur DREO :-) Allerdings nutze ich auch nur 1+4

[mehrwiedu]

@eubecker sagte:

Ich weiß nicht, ob das immer gleich ist, bei Mode wäre ein "Klartext" schön.

Hier ist
1=Normal
2=Natur
3=Schlaf
4="Umkehren"
Wobei Umkehren=Normal mit umgedrehter Drehrichtung ist. Warum es 2+3 nicht mit der Aufwärts-Richtung gibt, weiß wohl nur DREO :-) Allerdings nutze ich auch nur 1+4

Bei den Bezeichnern für den Fan.mode bin ich grade dran. Die kommen, ebenso wie die Bezeichner der „predefines“, sprich Favoriten in der App, nicht über die WebSocket. Bei den Favoriten werde ich wohl keine Chance haben, die auch „freundlich“ in die Objekte zu übernehmen, weil sie wahrscheinlich lokal in der App gesetzt sind. Bei den Bezeichnern für den Fan.mode könnte ich, da sie wohl numerisch immer identisch sind, im SDK eine Übersetzung implementieren.

Ich muss noch ein paar Endpunkte finden und mir die HTTP Verfügbarkeit noch ansehen. Eventuell habe ich da dann noch eine Möglichkeit.

In dem Zuge setze ich auch gerade die muteon, timeron, timeroff States, sowie das Schlaflicht noch um. Genaue Beschreibung der Möglichkeiten aus dem Adapter heraus liefere ich dann ebenfalls.

Was wahrscheinlich aber über den Adapter nicht steuerbar sein wird, ist der Scheduler. Der wird lokal am Gerät ausgeführt. Ich habe noch gar keinen Plan wie die „scheid“ generiert wird, und ob die Cloud die überhaupt verarbeitet. Möglicherweise läuft es darauf hinaus, dass es nur ein Info State geben wird, der lediglich anzeigt ob ein lokal erstellter Zeitplan aktiv ist.