[Alt/Depratched] Neues Modul - MAX_Temperatur (MAX set desired temperature)

Begonnen von bismosa, 14 Mai 2019, 20:56:00

Vorheriges Thema - Nächstes Thema

bismosa

Achtung!
Dieses Modul wird hier nicht mehr weiter gepflegt ("deprecated"). Es wurde umbenannt in MAX_Temperature und ist im normalen FHEM-Update zu finden.
Eine Umstellung kann leicht erfolgen mittels "Defmod". Hier einen neuen Namen erstellen (ggf. später umbenennen) und den Modulnamen in MAX_Temperature ändern.
Danach bitte vorhandene MAX_Temperature-Devices löschen.
Das alte Modul kann aus dem Updateprozess entfernt werden mit:
update delete https://raw.githubusercontent.com/bismosa/FHEM/master/controls_MAX_Temperatur.txt
Neues Modul: https://forum.fhem.de/index.php/topic,107152.0.html

Hallo!

In diesem Thread
https://forum.fhem.de/index.php?topic=77678.0
hatte Wzut mal ein tolles Modul erstellt. Im laufe der Zeit hatte ich dieses ein wenig angepasst. Da ich hier in letzter Zeit einige PERL-Warnings im Log hatte und selbst nicht mehr durch den Code gestiegen bin habe ich jetzt ein neues Modul (inkl. deutscher Doku) dafür geschrieben.
Wie es immer so ist...es wurde aufwendiger als gedacht. Aber ich denke mit dem Ergebnis kann man denke ich schon etwas anfangen.
Erstmal danke an Wzut für die Idee! Ich nutze das Tool ständig.

Wofür ist dieses Tool:
Es bietet eine "bessere" bzw. erweiterte Möglichkeit die MAX-Heizkörperthermostate oder die MAX-Wandthermostate einzustellen.

- Setzen der Temperatur für ein oder mehrere Heizkörperthermostate.
- Setzen der Temperatur und der Zeit (Urlaubsmodus).
- Setzen des Modus (Automatik/Manual).
- Gruppen können für dieses Modul festgelegt werden.
- Es können einzelne Devices hinzugefügt oder auch ausgeschlossen werden.
- Das Layout für die Auswahlfelder kann beliebig angepasst werden.

Es kann entweder ein festes Device oder alle Thermostate|Raumthermostate gesteuert werden. Je nach Definition wird entweder nur das Device oder eine Auswahlliste für das zu steuernde Gerät angezeigt.
Alle Thermostate/Wandthermostate
define MaxTemp Max_Temperatur
define MaxTemp Max_Temperatur T

Nur Heizkörperthermostate
define MaxTemp Max_Temperatur HT

Nur Wandthermostate
define MaxTemp Max_Temperatur WT

Fest eingestelltes Thermostat
define MaxTemp Max_Temperatur 123456

Das Layout für die Auswahlboxen kann in der Position angepasst werden. Als HTML. Details siehe Doku.

Es können eigene Gruppen über die Attribute erzeugt werden. Beispiel:
Untergeschoss:Max_Device1,Max_Device2,Max_Device3 Obergeschoss:Max_Device4,Max_Device5
So kann dann auch mal eben schnell für das ganze Haus die Heizung auf Abwesenheit etc. gestellt werden. Ohne das jedes Device einzeln ausgewählt werden muss.
Für Fans von "structure"...diese lässt sich über das Attribut "addDevices" hinzufügen.
Genauso lassen sich auch über "IgnoreDevices" einzelne Devices ausblenden.

Wird in dem Modul ein Device ausgewählt, werden einzelne Readings von dem gewählten Gerät (oder bei einer Gruppe für alle Devices) mit angezeigt...dann hat man einen Überblick, wie das entsprechende Device gerade eingestellt ist.

Um nicht die Device-Namen auswählen zu müssen, ist es möglich einen Alias zu vergeben. Somit wird aus einem "Max_HT_Wohnzimmer" ein "Wohnzimmer" und ist übersichtlicher bedienbar. Siehe Attribut "DevicesAlias".

Im Anhang ein Bild, wie es aussehen kann.

Installation:
Ich habe das Modul bei Github. Dann ist eine Installation recht einfach:
Alle meine Module:
Auf Updates prüfen (update check):
update check https://raw.githubusercontent.com/bismosa/FHEM/master/controls_all.txt
Auf die neueste Version updaten (update all):
update all https://raw.githubusercontent.com/bismosa/FHEM/master/controls_all.txt
Alle meine Module zum regulären FHEM Updateprozess hinzufügen (update add):
update add https://raw.githubusercontent.com/bismosa/FHEM/master/controls_all.txt
update check
update all

Nur dieses Modul:
Auf Updates prüfen (update check):
update check https://raw.githubusercontent.com/bismosa/FHEM/master/controls_MAX_Temperatur.txt
Auf die neueste Version updaten (update all):
update all https://raw.githubusercontent.com/bismosa/FHEM/master/controls_MAX_Temperatur.txt
Nur dieses Modul zum regulären FHEM Updateprozess hinzufügen (update add):
update add https://raw.githubusercontent.com/bismosa/FHEM/master/controls_MAX_Temperatur.txt
update check
update all

Wie immer...ich habe mir alle Mühe gegeben die meisten Fehler zu eliminieren...garantieren kann ich jedoch für nichts.  :)
Viel Spaß damit!

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

Zitat von: bismosa am 14 Mai 2019, 20:56:00
Wie es immer so ist...es wurde aufwendiger als gedacht.
Ach und ich dachte schon das geht nur mir so .... :)
Anyway ich halte es mit dem Spruch "das Bessere ist der Feind des Guten",
mal schauen ob ich die Woche über die Zeit finde ein bissel dein Sourecode zu lesen und anschliessend zu meckern  8)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bismosa

Zitat von: Wzut am 14 Mai 2019, 21:14:35
mal schauen ob ich die Woche über die Zeit finde ein bissel dein Sourecode zu lesen und anschliessend zu meckern  8)
Viel Glück! Bestimmt geht das noch viel besser...aber im Gegensatz zum vorherigen ist das schon ein weiter Schritt vorwärts  :)
Bitte beachte nur...ich bin nur Hobbyprogrammierer  8)

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wirelesskabel

Raspberry Pi B3+, 8er-Relaiskarte, MapleCUN, Max!(HKT/WT/FK), WS980

Wzut

Wegen OT im MAX Thread :
Vorschlag
1. Nenne das Modul um von MAX_Temperatur in MAX_Temperature um den englischen Modulnamen  zu folgen
2. Erstelle (notfalls mit Google) einen englischen Command.ref Teil , selbst wenn der wie bei DOIF kürzer als der deutsche ist, es nun mal Plicht ihn zu haben.
3. checke das Modul ein

Mehr Reklame : Du  erweiterst das Wiki -> https://wiki.fhem.de/wiki/MAX#N.C3.BCtzliche_kleine_Erweiterungen um ein Beispiel bzw. den Hinweis auf dein Modul
Ich erwähne verlinke es dann noch zusätzlich innerhalb der 10_MAX command.ref
Schreibe im MAX Forum einen Reklame Thread den ich dann dort anpinnen kann, ich fürchte das geht hier in Codeschnipsel einfach unter.

Wenn du noch irgendwelche Änderungen/Anpassungen/Ergänzungen für das Modul innerhalb von 10_MAX brauchst melde dich, wir werden schon Lösungen finden :)

Beim durchlesen des aktuellen Codes  bin ich da über den Punkt set $mode $temp gestolpert, da gibt es im 10_MAX Code noch ein offenes  ToDo von M. Gehre hier müssen wir z.B. aufpassen das wir synchron bleiben.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bismosa

Hallo!

Zitat von: Wzut am 02 Januar 2020, 16:32:16
3. checke das Modul ein
Ja. Das wäre vermutlich die "beste" Lösung. Allerdings habe ich da noch das Problem, das ich nur Hobbyprogrammierer bin und bestimmt noch viele Fehler drin habe.
Ob ich alle FHEM-Erfordernisse erfüllt habe...keine Ahnung. Abgesehen von der offensichtlich fehlenden Englischen Anleitung sind da bestimmt noch andere Dinge nicht ganz konform.
Ich habe mich auch bisher nicht mit dem Einchecken beschäftigt, da ich nicht zwingend Maintainer sein möchte. Einmal erstellt ist so etwas schnell wieder aus dem Sinn und die nächsten Projekte stehen an  :)
Ich weiß nicht einmal, ob viel Interesse an dieser Möglichkeit besteht. Es gibt gerade mal 4 Installationen...aber ich habe auch keine Werbung dafür gemacht.

Wäre es vielleicht ein Weg, wenn ich die Commandref nachpflege(und das Modul umbenenne), das Du das Modul einfach von mir übernimmst? Du bist ja auch der Initiator davon...beim Pflegen kann ich ja so gut es geht dann helfen  :)
Dann würde das alles in einer Hand bleiben  ;)

ZitatWenn du noch irgendwelche Änderungen/Anpassungen/Ergänzungen für das Modul innerhalb von 10_MAX brauchst melde dich, wir werden schon Lösungen finden :)
Aktuell wäre da die Umschaltung zwischen Auto/Manuell. Hier gibt es das "Problem", dass die Temperatureinstellung nur mit Übergabe einer neuen Temperatur möglich ist. Gibt man die Temperatur "0" vor, dann wird unter Beibehaltung der aktuellen Temperatur umgeschaltet.
- Ist es möglich eine Modusumschaltung hinzuzufügen, das die vorher eingestellte Temperatur (genauso wie beim Umschalten an den Thermostaten) bleibt
- Schön wäre es, wenn es dann eine direkte Umschaltmöglichkeit im Modul geben würde
Ich hatte auch eine Issue auf meinem Github: https://github.com/bismosa/FHEM/issues/1
Da sind wir dann darauf gekommen, es mit der Temperatur von "0" umzusetzen

Und was hier bestimmt noch sehr viele Interessiert...wenn Du einen Weg findest den Thermostaten regelmäßig eine aktuelle Temperatur zu entlocken (ohne den Scanner) würden sich bestimmt viele freuen  :)

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

bismosa

Hallo!

Kleines Update. Ich habe die Zeit heute gleich genutzt um die Doku in Englisch hinzuzufügen und das Modul umzubenennen:
https://github.com/bismosa/FHEM/blob/master/FHEM/98_MAX_Temperature.pm

Ich verteile dies jedoch erstmal nicht als Update über meine Repo, da das umbenennen einige Schwierigkeiten mit sich bringt...es müssen z.B. alle Geräte neu angelegt werden.

Du darfst den Code frei verwenden / modifizieren / veröffentlichen etc. Ob nun mit oder ohne Quellenangabe ist mir auch egal.
Solltest Du es wirklich irgendwann mit offiziell einchecken, werde ich das bei mir im Github schreiben und meine (dann veraltete Version) entfernen.  :)

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

Na also geht doch :)  also kein Grund dich immer kleiner zu machen als du bist (Hobbyprogger) , ich hab es auch nur durch abschreiben bei anderen gelernt ....
Beim Durchsehen sind mir bisher nur ein paar Kleinigkeiten aufgefallen (z.B. doppelte Zeilen beim Ersetzen von Leerzeichen hash->{NOTIFYDEV} nicht auf eigenen Namen sondern auf global , etc) und lass es mal gegen commandref_join laufen :
root@newraspi:/opt/fhem# perl ./contrib/commandref_join.pl | grep MAX_Temperature
*** EN FHEM/98_MAX_Temperature.pm: Unbalanced tr (5, last line ok: 962)
*** DE FHEM/98_MAX_Temperature.pm: Unbalanced tr (5, last line ok: 1169)


Zitat von: bismosa am 03 Januar 2020, 12:44:27
Du darfst den Code frei verwenden / modifizieren / veröffentlichen etc. Ob nun mit oder ohne Quellenangabe ist mir auch egal.
na na egal ist Handkäse .... ich werde es vermutlich am WE einchecken und in der MAINTAINAER.txt bekommt es in der Spalte MAINTAINER einen Doppeleintrag genau wie mein SIP Modul.

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bismosa

Hallo!

Danke das Du Dir das angeschaut hast. Stimmt...sind ein paar Fehler in den HTML-Tags gewesen...copy/paste  :)
Die sind schon bereinigt. Das war noch einfach  :)

Der Rest ist schwieriger für mich:
Zitatdoppelte Zeilen beim Ersetzen von Leerzeichen
Du Meinst sicherlich diese:
$DDSelected =~ s/ / /g;
$DDSelected =~ s/ / /g; #ACHTUNG! Kein richtiges leerzeichen!!! Siehe http://www.fileformat.info/info/unicode/char/00a0/index.htm

Hier wird erst ein echtes Leerzeichen und danach ein geschütztes Leerzeichen "U+00A0" ersetzt. Da war ich schon ein paar mal drauf reingefallen. Der Unterschied ist nur nicht sichtbar.

Zitathash->{NOTIFYDEV} nicht auf eigenen Namen sondern auf global
Sorry...Keine Ahnung was Du damit meinst? Meinst Du diese Zeile (129)?
$hash->{NOTIFYDEV} = $name;
Wenn ich mich recht erinnere, dann soll hier auf keine Events von den Thermostaten reagiert werden.

Mir stellt sich die Frage, ob ich dann einfach den Part aus meinem Github lösche oder eine Update-Datei erstelle, die das Modul 98_Max_Temperatur.pm in "unused" verschiebt. Dadurch würde ich aber ggf. direkt in eine FHEM-Installation eingreifen, da die Geräte dann entfernt werden....

Zitatich werde es vermutlich am WE einchecken und in der MAINTAINAER.txt bekommt es in der Spalte MAINTAINER einen Doppeleintrag genau wie mein SIP Modul.
Auch damit bin ich einverstanden   :)

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

Zitat von: bismosa am 03 Januar 2020, 16:59:18
danach ein geschütztes Leerzeichen "U+00A0" ersetzt. Da war ich schon ein paar mal drauf reingefallen. Der Unterschied ist nur nicht sichtbar.
--snipp--
$hash->{NOTIFYDEV} = $name;
--- snipp ---
Mir stellt sich die Frage, ob ich dann einfach den Part aus meinem Github lösche
- Ohh ok, ich sehe wirklich keinen Unterschied in meinem Editor
- Ich bin der Meinung als damals von Markus Bloch diese notify Liste eingeführt wurde das er geschrieben hat das wenn man sie temporär nicht braucht sie aber im Ini aufgeführt ist man sie auf das bisherige global setzen soll :
$hash->{NOTIFYDEV} = 'global';
- von git habe ich Null Ahnung , du wirst schon wissen was und wie du es am Besten machst :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

[OT] von Hobbyprogrammierer zu Hobbyprogrammierer: Willkommen im Club!
Das mit der doppelten Maintainerschaft ist eine gute Sache, so bin ich auch in die Dinge reingewachsen!

Vielleicht hilft es was: Im Modul 98_Heating_Cntrol.pm gibt es einen "Überleitungscode" von Heating_Control zu WeekdayTimer; hatte das so verstanden, dass es für die, die die alte Version schon nutzen, was ähnliches braucht, weil das Modul anders heißt...
(Würde das ggf. über ein "keyword" für einen "Übergangs-"define lösen, also
"define myTransfer MAX_Temperature MAX_Temperatur_Module_Transfer"). Vermutlich kennen Nicht-Hobbyisten andere Wege, aber das feedback für "meine" Funktion war ok, ich hab die Routine nur anders ausgelöst (aus Heating_Control aus, das aber via update (noch) verteilt wird)  ;) .

In diesem Sinne: Viel Erfolg!
[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

noch ein kleiner Fehler :
die Auswahlliste  der Temperaturen zeigt boost, 4.5 , 5 usw. die 4.5 sollte da raus,  denn 4.5 = off
am Ende stimmt es 30.0, on  da on = 30.5 (siehe MAX_ParseTemperature in MaxCommon.pm )
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Zitat von: bismosa am 02 Januar 2020, 17:53:22
Und was hier bestimmt noch sehr viele Interessiert...wenn Du einen Weg findest den Thermostaten regelmäßig eine aktuelle Temperatur zu entlocken (ohne den Scanner)
wenn man das set set desired temperature auto (aktuelle Temp -0,5) until heute Stunde:00/30 immer 5 Minuten davor absetzt ?
Dann geht er doch alle halbe Stunde für 5 Minuten in den Partymodus und schickt seine aktuelle Temp ?
Durch den Partymodus und selbständige Rücksetzen spart man 110 Credits gegenüber dem Scanner :) allerdings ist die kleinste Frequenz dann max 30 Minuten und nicht wie beim Scanner 3,6,9,12,15,21,24,27,30 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

bismosa

Hallo!

Sorry...bin nicht eher dazu gekommen.

Zitat$hash->{NOTIFYDEV} = 'global';
Habe ich ausgetauscht. Soweit ich das sehe, hat dies keine Auswirkungen auf die Funktion des Moduls. Ich will damit nur ein "Rücksetzen" der Notify-Devices erzwingen um die Events zu begrenzen.

die Auswahlliste  der Temperaturen zeigt boost, 4.5 , 5 usw. die 4.5 sollte da raus,  denn 4.5 = off
Ok. Ebenfalls korrigiert.

Zitatwenn man das set set desired temperature auto (aktuelle Temp -0,5) until heute Stunde:00/30 immer 5 Minuten davor absetzt ?
Dann geht er doch alle halbe Stunde für 5 Minuten in den Partymodus und schickt seine aktuelle Temp ?
Durch den Partymodus und selbständige Rücksetzen spart man 110 Credits gegenüber dem Scanner :) allerdings ist die kleinste Frequenz dann max 30 Minuten und nicht wie beim Scanner 3,6,9,12,15,21,24,27,30
Ja. allerdings ist dies dann immer noch (wie beim Scanner auch) ein Eingriff in die Steuerung. Es wird auch nur die Temperatur gesendet, wenn das Ventil wirklich sich verändert.
Ich hatte da mal ein Test gemacht und habe die Boost-Position ein paar schritte von der aktuellen Position gesetzt und dann für wenige Sekunden ein Boost ausgeführt. Das klappt...das Ventil verfährt wirklich nur sehr wenig und die Temperatur wird übermittelt. Aber die Credits...das ging gar nicht.

@Beta-User
Danke für den Tipp mit dem Überleitungscode. Ich denke bei 4 Installationen brauche ich dies nicht. Ich werde ein Update einspielen, mit dem Hinweistext auf das "neuere" Modul direkt in der Gerätezeile. Dazu noch einen Hinweis in der Doku.
Das Update dafür ist schon vorbereitet  :)

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Wzut

ich habe es eben eingechecked, bitte erstelle aus deinem ersten Beitrag eine Kurzfassung und poste sie im MAX Forum, ich kann dann den Fred anpinnen und ziehe die URL in den Modulen als Doku nach.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher