Floureon Wifi Raumthermostat

Begonnen von chris_kmn, 07 Dezember 2017, 20:23:29

Vorheriges Thema - Nächstes Thema

Wzut

@clumsy,
ich nutze weekprofile zwar schon recht lange für meine MAX! und HM HTs, aber mit den Topics hast du mich jetzt auf dem linken Fuss erwischt.
D.h. ich kannte das bis heute überhaupt nicht :( Ich habe jetzt commandref und Wiki gelesen, aber um ehrlich zu sein kapiert habe ich es noch nicht.
Ich würde dir vorschlagen bis das geklärt ist leg dir ein neues zusätzliches WP Device an ohne Topics und mach da deine Tagesheizpläne für das BEOK.
(so wie kabanett es auch macht) Im Wiki steht u.a.
ZitatMit dem Befehl restore_topic kann man dann zwischen unterschiedlichen Kategorien wechseln. Die Wochenpläne werden automatisch an die Thermostate übertragen
das wird dann eh nicht gehen da WP ja das BEOK Modul nicht direkt unterstützt.

Zitat von: kabanett am 16 Februar 2019, 17:41:53
define Hzg_Wohnzimmer_TempSet at *00:05 set Wohnzimmer_Thermostat weekprofile Hzg_Wohnzimmer_Wochenprofil:Winter
da bin ich aktuell dran, d.h. die nächste Version benötigt kein zusätzliches at mehr, das wird beim ersten Durchlauf nach Mitternacht automatisch gemacht.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

clumsy

@kabanet: Ja, es liegt an der Verwendung der Topics, das scheint im BEOK (noch) nicht vorgesehen, Beschrieb weshalb s.o.....

Die Idee der Topics ist ja eben, dass man nicht für ein Thermostat 2 unterschiedlich benamste Profile machen muss, sondern verschiedene "Topics" hat unter welchem für (sämtliche) Thermostate das entsprechende Profil ist, z.B. eben Sommer/Winter/Ferien/etc... damit man global sagen kann "Ferien" und alle Thermostate kriegen dann das Profil aus dem anderen Topf, sozusagen, ohne dass man sich unterschiedlichste namen merken, resp. definieren muss (eg. Winter_Bad, Winter_Wohnzimmer, Winter_Kueche, Sommer_Bad, Sommer_Wohnzimmer, etc.)...

clumsy

@Wzut: wie gesagt, prinzipiell kein Problem, ich kann schon für die BOEK's eigene Profile im Topic "default" machen, dann funktionierts schon... Wollte ja lediglich Rückmeldung geben, dass da noch eine kleine "Inkompatibilität" besteht! Ist aber ja nicht funktional problematisch oder so...

Ich denke es wäre in deinem Modul relativ einfach zu Lösen, indem du vor der Zeile 454 (Git Version) my $json = CommandGet(undef,"$wpd profile_data $wpp"); 2 zusätzliche Aufrufe machst, einmal um das Attribut "useTopics" aus $wpd ausliest, falls dies "1" ist das Reading "active_topic" aus $wpd liest und das Resultat dem $wpp mit doppelpunkt voranstellst... Wenns für dich ok ist und du möchtest, kann ich auch mal versuchen das in deinem Modul versuchen zu coden...


clumsy

Mir ist grad noch etwas aufgefallen, ich hab weeprofile mit je 7 EInträgen erstellt für den Thermostaten. Irgendwie scheint die Übertragung jedoch um 1 verschoben, bei den weekprofilen ist ja immer die Periode BIS wann die Temperatur gilt. Bei (meinem) Thermostat ist die Periode jeweils AB wann die Temperatur gilt. SObald ich ein weekprofile übertrage verschiebts mir die Temperaturen.
Sat 00:00-08:00 19.0 °C 08:00-09:00 23.0 °C 09:00-11:30 19.0 °C 11:30-12:30 19.0 °C 12:30-22:30 19.0 °C 22:30-23:30 23.0 °C 23:30-24:00 19.0 °C
führt zu
day-profile1-temp 19.0
day-profile1-time 08:00

Was eine Periode verschoben ist... (müsste ja ab 8:00 23° sein)....

kabanett

@clumsy
Schau mal in diesen Beitrag die Grafik von Wzut an https://forum.fhem.de/index.php/topic,80703.msg901303.html#msg901303
Das von bis ist hier nicht gültig. Schaltzeiten sind nur rechts. Kann man aber gut erkennen!

@Wzut
Mit der Übermittlung des weekprofile aus deinem Modul heraus wäre schon toll! Ich hätte da noch eine Bitte. Ist es möglich auch ein set auf Auto optional zu senden?
Momentan mach ich das anders, aber so wäre es schöner. Hintergrund: Frauchen stellt ab und an mal um. ;)
Hardware: Fhem auf Raspi3 / selbtsbau CUL 433 und 868 MHz / MAX Thermostate / IT-Dosen nur noch Weihnachten / diverse ESP Aktoren/Sensoren / X10 Fernbedienung / Shelly 1, 1L, 2, 2.5, Dimmer, RGB2 / LaCrosseGateway / Zigbee2531 / diverse Zigbee Aktoren/Sensoren

clumsy

@kabanett stimmt, danke, das hab ich überlesen!

Aber eigentlich wäre es ja Programmtechnisch recht einfach zu lösen jeweils die Temperatur der Folge Periode zu nehmen für die Übertragung, so würde der Weeklpan auch "richtig"  aussehen... Auch nicht tragisch, rein kosmetisch, aber falls @Wzut mal langweilig ist ;)

Vielen dank auf jeden Fall schon mal!

STefan

Wzut

Zitat von: kabanett am 17 Februar 2019, 11:27:01
Ist es möglich auch ein set auf Auto optional zu senden?
Das wäre dann ein Fall für das Attribut keepAuto, da wechseln andere HTs am nächsten Schaltpunkt in den AutoModus, mal schauen

@clumsy, das kannst du drehen wie du willst aber es bleibt immer eine Zeit zuviel, Entweder die erste oder die letzte, ich hatte auch versucht das begründen.
a. speichert Weekprofile nur die Endzeiten , d.h Start ist immer das Ende des Vorgängers, dadurch ist der letzte zuviel.
oder man muss den ersten Schaltpunkt verwerfen und startet mit Beginn des zweiten.
b. hat WP diesen Gewalt Schaltpunkt um 0:00 Uhr   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

clumsy

@Wzut klar, hast natürlich schon recht... Für mich wars einfach verwirrend, dass die Perioden nicht stimmen (in der Anzeige im FHEM)... Ich hätte intuitiv wohl den ersten Temp-Wert verworfen damit die Perioden stimmen... aber das ist nach jedem seinem eigenen Geschmack.

Es ist ja richtig dokumentiert und das ist entscheidend. Also wer lesen kann ist klar im Vorteil ;) mein Fehler...

Noch wegen den Weekprofile Topics, ich hab mir das nochmals kurz angesehen. Man könnte die Zeile 454:
my $json = CommandGet(undef,"$wpd profile_data $wpp");
ersetzen durch
    my $topic = "";
    if (AttrNum($wpd, "useTopics", 0) > 0) {
        $topic = ReadingsVal($wpd, "active_topic", "");
        if ($topic ne "") {
            $topic=$topic . ":";
        }
    }
    my $json = CommandGet(undef,"$wpd profile_data $topic$wpp");

Dannklappts sowohl mit wie auch ohne WP-Topics... Hoffe das ist ok für dich, dass ich das hier poste...

Schönen Sonntag noch!

STefan



Wzut

Zitat von: clumsy am 17 Februar 2019, 15:45:25
Hoffe das ist ok für dich, dass ich das hier poste...
ja sicher, wenn es so geht werde ich das in der Art in die nächste Version übernehmen, THX
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Starkstrombastler

Ein wichtiger Vorteil dieser Thermostate ist, dass sie auch autonom (also ohne App oder Fhem) funktionieren. Hierfür werden zwei Profile unterstützt:
- Werktags mit 6 Schaltpunkten
- Wochenende mit 2 Schaltpunkten
Mit dem Attribut LOOP kann festgelegt werden, ob Samstag oder Samstag und Sonntag als Werktag behandelt werden sollen.

Hierbei kommt es aber zu einem Datenversatz zwischen Fhem und meinen Thermostaten:
Einstellung am Thermostat        Reading loop in Fhem
12345    123456.7
123456    1234567
1234567    ? ? ?
in der anderen Richtung:
Set Loop in Fhem        Wert für Loop im Thermo
12345.67    <leer>
123456.7    12345
1234567    123456

Entsprechend merkwürdig verhalten sich dann die Schaltzeiten, wenn man loop via Fhem eingestellt hat :( 
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

Wzut

sollte natürlich nicht so sein, wird beim nächsten Update gefixt, THX4INFO
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Zur Info : Ich werde heute Abend eine neue Version einchecken
Fix :
a. Loop Mode , das Modul verwendet intern 0-2 , das Themostat aber 1-3. Der Fehler ist auch in der Broadlink Pyhton Doku

b. Unterstützung von Topics wie von clumsy vorgeschlagen. Da ich das Thema WP Topics immer noch nicht verstanden habe und nicht verwende. müsst ihr testen ob es so nun passt.

ToDo : der Vorschlag von kabanett auf Automatik Mode prüfen.
Ich sehe hier zwei Möglichkeiten der Umsetzung :
a. beim ersten Lauf eines neuen Tages wird das neue Tagesprofil an das Thermo übertragen und der aktuelle Status gelesen. Ist diese nicht auto
entscheidet ein neues Attribut keepAuto ob nun vom Modul aus der auto Modus wieder gesetzt wird oder im manu Mode bleiben darf.

b. ähnlich wie a. allerdings erfolgt die Prüfung nicht nur 1x am Tag sondern jeweils beim erreichen eines Schaltpunktes, d.h, 6 x Tag.
Auch hier entscheidet das Attribut keep Auto ob der Modus gewechselt werden soll oder nicht. Diese Variante entspricht in etwa dem Verhalten der MAX! HTs mit ihrem Attribut keepAuto ist aber etwas aufwändiger in der Umsetzung

Meinungen / Vorschläge ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

clumsy

@Wzut erstma Danke!!!

Zitatb. Unterstützung von Topics wie von clumsy vorgeschlagen. Da ich das Thema WP Topics immer noch nicht verstanden habe und nicht verwende. müsst ihr testen ob es so nun passt.
Bei mir läuft das mit Topics seit ner WOche eigentlich problemlos, was ich nicht getestet habe ist, obs auch ohne Topics geht ;) Aber müsste eigentlich schon...

bez. den ToDo's: wenn ich das Ding richtig verstehe, gibt es 2 "Auto" Modi (zusätzlich zum Manuellen), nämlich dass die Temp. von Hand zwar angepasst wurde aber der Modus immernoch auf Auto ist, da wird dann wohl automatisch beim nächsten Schaltzeitpunt wieder auf die Plan-Temperatur umgeschalten. Im gegensatz zum Manuellen Modus, bei dem die Temp. nicht mehr zurück geschalten wird.

In den Readings ist das glaub auch so abgebildet mit den Readings "mode" und "temp-manual". Also müsste es doch eigentlich auch möglich sein, dass man eine (vorübergehende) abweichedne Temperatur via Command absetzt welches "nur" die Desired-Temp ändert aber nicht den Auto Modus... D.h. das würde eh dein Vorschlag b) abdecken.

Das würde bedeuten, dass das "rückschalten auf Auto" eigentlich "nur" dazu verwendet wird, einen fälschlicherweise auf Manuell geänderten Thermostat wieder auf Auto zu stellen. Da der Zeitpunkt dazu wohl von jedem etwas anders gewünscht wird (ich z.b. mache das um 3Uhr morgens oder so), wäre evtl. noch eine Variante c) aus dem Attribut "keepAuto" eher ein Attribut "resetAuto" zu machen, bei dem man eine Zeit (und oder Datum/Wochenteag,etc) angeben kann wann auf Auto zurückgestellt werden soll. So wird es übrigens i.a. auch bei anderen Gebäudeleitsystememn gemacht. Nur so als Idee....

kabanett

Hallo

@Wzut
Vorschlag a. mache ich momentan. So ist zumindest nach spätestens einem Tag die Autofunktion wieder hergestellt.
Persönlich würde ich den Vorschlag b. bevorzugen. Erstens, da ich es von meinen MAX Thermos so kenne. Zweitens, ist nur ein entsprechender Zeitabschnitt am Tag betroffen.

@clumsy
Ist schon richtig was du schreibst. Setzt voraus, dass sich die Bediener auch daran halten nur die Temperatur zu verstellen. Ich habe meinen Mädels zwar eine Einweisung gegeben, aber die drücken trotzdem gerne noch rum bis die Hand erscheint ;) Ist ja grundsätzlich nicht schlimm wenn man den WAF noch erhöhen würde ;D

Gruß

Gruß

Hardware: Fhem auf Raspi3 / selbtsbau CUL 433 und 868 MHz / MAX Thermostate / IT-Dosen nur noch Weihnachten / diverse ESP Aktoren/Sensoren / X10 Fernbedienung / Shelly 1, 1L, 2, 2.5, Dimmer, RGB2 / LaCrosseGateway / Zigbee2531 / diverse Zigbee Aktoren/Sensoren

clumsy

@Kabanett da geh ich völlig einig mit dir, ich hab ein ähnliches Problem mit dem WAF bei mir... nur möchte ich selbst bestimmen, wann zurück gestellt wird, sonnst kommt meine Liebste um 0:30 in oder aus der Dusche und friert weil um 0:05 die Heizung ausgeschalten hat, nachdem sie sie um 23:30 doch extra manuell eingeschalten hat....  ;D und der WAF ist wieder i.A....