Floureon Wifi Raumthermostat

[clumsy]

weiss zufällig grad jemand ob das die gleichen sind, reps. das gleihce protokoll verwenden und es mit denen auch gehen würde?
https://de.aliexpress.com/item/16A-AC-220-V-WIFI-Heizung-Thermostat-Wasser-Elektrische-Heizung-System-WIFI-Thermostat-APP-Steuert-f/32889325428.html?spm=a2g0s.9042311.0.0.15dd4c4dUMuboH

Kurzer update: ich hab die oben verlinkten Thermostate unterdessen bekommen und mal kurz getestet. Bisher scheint alles problemlos zu funktioneren!

Vielen Dank an @Wzut für das Modul!! Klasse Sache!!

[Wzut]

Danke fürs Feedback, dann werde ich das KETOTEK beim nächsten Update mit in die Modelliste aufnehmen (attr model) für die FHEM Statistik
Nur aus Neigier : mit welcher Smartphone App (Hysen / Beok Home ) hast du die Grundeinstellung gemacht ? 

[clumsy]

Ich habs mit der "Room Heat" app aus dem App-Store gemacht, glaub die China-Version, nicht die EU, die wollte er bei mir nicht installieren ("in meinem Land nicht verfügbar"...). Version:18.12227.1124

Wenn du noch irgendwas an Debug-Infos brauchst oder so, lass mich wissen!

[Starkstrombastler]

@clumsy
Wie verhalten sich denn die KETOTEK bzgl der Hintergrundbeleuchtung?


Gesendet von iPhone mit Tapatalk

[clumsy]

Nur nach Tastendruck an für ca. 10sek.... und wie schon jemand beschrieben hat, wenn man nicht verstellen will bleibt eigentlich nur off/on...

[clumsy]

Ich hätte noch eine Frage an @Wzut (oder auch alle anderen, falls das jemand beantowrten kann): weist Du ob in dem BEOK Protokoll irgendwelche weiteren Informationen abgefragt werden können? Insbesondere RSSI vom WiFi Modul würde mich interessieren!

Auch ist mir nicht ganz klar, wie die App initial mit dem Thermostaten kommuniziert um die WiFi einstellungen zu transferieren. Weiss da jemand was drüber? Evtl. könnte man auch das in das Modul einbauen sonst...

[Wzut]

ja ja ist mir schon klar ... du würdest am liebsten auf das Smartphone zur Ersteinrichtung ganz verzichten
Aber sorry , alles was ich an Kommunikation zum Thermostat kennen ist eigentlich nur 1:1 abgeschrieben vom Autor des Broadlink Python Scripts.
Der hatte damals ein altes Smartphone als Netzwerksniffer missbraucht und hat versucht alles was zwischen den beiden Geräten übertragen wird zu entschlüsseln. Daher ist es gut möglich das man vllt. das Display extra steuern kann, aber da es die App nicht macht gibt es dafür eben kein Beispiel.
Ja es wäre schön gewesen wenn der Autor auch den Anfang beim Anmelden mitgeschnitten hätte, aber der fehlt halt bisher ebenfalls.
Es sei denn es macht sich jemand anderes mal die Mühe das in irgendeiner Form nachzuholen. 

[ch.eick]

Hallo.

Trotzdem vielen Dank und Lobhudelei für die bisherige Leistung.

Ich vermute, dass bei der Initialisierung des Thermostats durch die App die Aktivierung der ersten dhcp Adresse initiiert wird. Alleine durch das Thermostat konnte ich in der FritzBox kein neues Gerät sehen, dass über dhcp eine Adresse bekommen hat. Um auf die App zu verzichten müsste zumindest das zu sehen sein.
Für diesen Versuch hatte ich  am Thermostat FAC auf 10 gesetzt, jedoch habe ich bisher immer noch nicht verstanden, was der Unterschied von FAC = 10 und FAC =32 ist. In der Mini Dokumentation steht nur FAC "10 or 32: Wifi mode open".

Ich bekomme irgend wann noch ein weiteres geliefert und könnte es dann mit dem Mitlesen mal probieren. Mein Solaris Rechner bringt ja alle mit und ich lass mich bei den Kollegen mal aufschlauen

Viele Grüße
    Christian

[Wzut]

Ich denke die machen das wie heute fast alle WiFi Geräte (vgl ESPEasy/ Tasmota) : Ist keine SSID eingetragen macht das Gerät einen eignen AP auf mit einer der App bekannten SSID und ohne Password. Die App bucht sich dann auf diesen ein und überträgt die zuvor eingetippten eigenen WLAN Parameter, danach erfolgt ein reboot und schon ist es im eigenen Netz sichtbar.

[ch.eick]

Okay, das klingt plausibel.

Dann würde ich bei dem nächsten neuen Thermostat folgende Schritte machen:

1. Am Thermostat FAC auf 10 setzen.
2. Mit einem Wifi Scanner mir die Netze in der Umgebung anschauen.
3. Das gefundene Dokumentieren
4. Versuchen es mit einem Scanner mit zu schneiden

Gruß
   Christian

[clumsy]

Ich dachte eigentlich auch, dass es einen eigenen AP macht, bin jedoch nicht so sicher, da 1. der AP sich nicht scannen lesst (auch wenn die SSID hidden ist, müsste es ein scanner finden) und 2. beim übertragen der Daten das Handy immernoch auf den "alten" AP verbunden ist (es kann ja nicht gleichzeitig auf 2 AP's verbinden).

Eine andere Variante wäre auch noch dass die Daten per BT(LE) an das Gerät übertragen werden.

Ich bin jetzt dann zwar ne Weile weg, aber evtl. schaff ichs mal noch etwas zu sniffen... jenachdem wieviel Zeit noch vor dem Abflug bleibt

und @Wzut: nicht falsch verstehen, das war keine Kritik sondern eine Frage und Vorschlag (be dem ich auch gerne mithelfe), das Modul ist super!! Echt gute Arbeit!!

Schönes WE!

STefan

[clumsy]

Noch eine Frage zu den "weekprofile": kann es sein, dass das BEOK immer das "default" topic verwendet aus dem weeprofile? Ich benutze weekprofile mit Topics, erhalte aber vom BEOK Modul immer ein "profile not found" zurück, ausser wenn ich das default profile angebe... auch wenn das active_topic im weekprofile ein anderes ist!

[Wzut]

wie gibst du es denn ein ?
z.B. set myBeok weekprofile mywp:Bad
verwendet die Ausgabe die kommt wenn du in der Kommandzeile get mywp profile_data Bad eingibst.
D.h. ich prüfe nicht ob es das wp Device oder das Profil wirklich gibt sondern leite es 1:1 direkt an das wp Device mittels get weiter.
Angezeigte Fehler sind die direkte Rückgabe des wp Moduls. 

[clumsy]

Ich verwende es genau so.

Weekprofile kennt zwar solche "Topics" um gesamthaft änderungen zu machen, nimmt das "active topic" aber nicht als Rückgabewert für die Kommandos sondern immer das Default.

Also ich habe z.b. 2 Topics "Sommer" und "Winter" und darunter je ein Profile "Bad".  Wenn ich nun "get <weekplan> profile_data Sommer:Bad" mache erhalte ich das Profil für den Sommer. Analog dazu mit Winter. Wenn man nun aber einfach "get <weekprofile> Bad" macht, dann erhält man das Profil "Bad" aus dem Topic "default" (weil kein Topic angegeben ist), das ist auch so im Wiki dokumentiert. Wenn es im Default nun aber kein "Bad" gibt, erhölt man eben genau den Fehler.

Mit den anderen Thermostaten (z.B. hmhz's) funktioniert das, weil vom Weekprofile device akitv der plan gesetzt wird wemm man ein "set <weekplan> restore_topic <Topic>" macht. Dann updated er alle Devices in denen entsprechende Profile definiert sind und setzt das Reading "active_topic"...

Dass wenn man ohne Topic eine Anfrage an das weekprofile Modul macht immer das "default" und nicht das "active_topic" zurückgeliefert wird ist sicher in gewissen Anwendungen nicht optimal, aber eben halt bewusst so gemacht und dokumentiert. Ich habe dazu auch im entsprechenden Thema mal geschrieben, mal sehen ob der Autor sich dazu äussert. Für mich wäre es schon auch logischer wenn man kein Topic angibt, den Plan des "active_topic" zurück zu liefern bei einem "get".

Solange das so ist, muss eben der Client eigentlich herausfinden, welches Topic grad aktiv ist und dann mit "get <weekprofile> profile_data <Topic>:<Profile>" das entsprechende Profil abholen. Sind halt ein paar Aufrufe mehr, erst im <weekprofile> nachsehen ob Topics aktiviert sind (steht im Attribut "useTopics" und dann aus dem Reading "active_topic" das aktuelle herauslesen, bevor man dann das richtige Profil abholt....

Ansonsten eben, mal sehen ob der Autor im anderen Thema antwortet...

[kabanett]

@Wzut
Nochmals vielen Dank für dieses Modul!!! Seid deinem letzten Update läuft es bei mir perfekt. Inklusiv Wochenplan!

@clumsy
Kann es an der Verwendung von Topics liegen?
Ich selbst nutze es wie von Wzut beschrieben. Also weekprofile für Thermostat anlegen (bei mir "Hzg_Wohnzimmer_Wochenprofil") , darunter hab ich je ein Profil für Sommer/Winter angelegt (Also sind es jetzt drei inkl. Default). Das ganze wird dann mit dem at bisher sicher ausgeführt (define Hzg_Wohnzimmer_TempSet at *00:05 set Wohnzimmer_Thermostat weekprofile Hzg_Wohnzimmer_Wochenprofil:Winter).

Gruß