Gui (pgm2|FHEMWEB) für Wochenprofil

Begonnen von Risiko, 18 Januar 2015, 18:32:45

Vorheriges Thema - Nächstes Thema

Risiko

Hallo.

Ich habe die Änderungen für HM eingepflegt. MAX geht auch noch  ;)
Anbei der aktuelle Stand.

Risiko

JoeALLb

Zitat von: Thorsten Pferdekaemper am 03 Dezember 2015, 19:01:33
Hi,
aha, die Homematic-Dinger haben ein restore-Kommando. Damit habe ich bisher nichts gemacht. Es sieht auch nicht so aus, als ob es da einen einfachen Weg gibt, das in's Gui mit aufzunehmen.
Vielleicht will's ja jemand anders machen.
Gruß,
   Thorsten
sas muss man gar nicht. reichen würde es,  wenn man die zentralen Zeitprofile editieren kann. Die Restore-funktion hat nicht direkt der DN, sondern die fhem-virtuelle HM-zentrale. Damit kann ich jedem thermostat sagen, welches Profil für ihn gilt, und prüfen, ob er noch übereinstimmt. vorallem im Zusammenhang mit Wandtermostaten wichtig und hilfreich.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Thorsten Pferdekaemper

Zitat von: JoeALLb am 04 Dezember 2015, 06:53:14
sas muss man gar nicht. reichen würde es,  wenn man die zentralen Zeitprofile editieren kann. Die Restore-funktion hat nicht direkt der DN, sondern die fhem-virtuelle HM-zentrale. Damit kann ich jedem thermostat sagen, welches Profil für ihn gilt, und prüfen, ob er noch übereinstimmt. vorallem im Zusammenhang mit Wandtermostaten wichtig und hilfreich.
Hi,
das habe ich schon verstanden, trotzdem ist mir das momentan zu viel Aufwand, um es mal so zum Spaß zu implementieren. Wenn ich es selbst benutzen würde, dann wäre das was anderes.
Gruß,
   Thorsten
FUIP

willyk

Zitat von: locodriver am 03 Dezember 2015, 17:06:57
@Thorsten: Na klar  ;)

Die Listen können für mehrere Thermostate verwendet werden und ich lade die Listen in der Nacht in die Geräte, wenn sich der Heizmodus für den Folgetag ändert.
So muss nicht in jedem Gerät die Liste editiert (laden, ändern, schreiben) werden sondern nur einmal und nachts wird sie bei Bedarf geschrieben.

Uwe
Zitat von: Risiko am 02 Dezember 2015, 19:05:54
Weiterhin steht auch das Speichern und Wiederherstellen von Profilen auf den Plan.
Erste Ansätze gibt es hier von wzut:
http://forum.fhem.de/index.php?topic=42002.new;topicseen#new

Na das hört sich doch richtig gut an !

Wenn man das schlau zusammenmischt, könnte man ganz neue Funktionen bereitstellen. Z.B.:

- Anlegen von Profilen, z.B.  "Bad", "Bad Schulferien", "Bad Urlaub"
- Änderungsmöglichkeit für die Profile
- Verknüpfung der Profile mit Kalender und Anwesenheitserkennung
- Laden des aktuellen Profils auf die HT / WT, abhängig von den verfügbaren Credits

Den letzten Punkt könnte man mit dem Skript von wzut realisieren.
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

locodriver

ZitatWenn man das schlau zusammenmischt, könnte man ganz neue Funktionen bereitstellen. Z.B.:

- Anlegen von Profilen, z.B.  "Bad", "Bad Schulferien", "Bad Urlaub"
- Änderungsmöglichkeit für die Profile
- Verknüpfung der Profile mit Kalender und Anwesenheitserkennung
- Laden des aktuellen Profils auf die HT / WT, abhängig von den verfügbaren Credits

ZitatIch habe mir vorgenommen, dass ganze zum Modul auszubauen und HM, MAX und andere Thermostat soweit wie mgl. zu unterstützen.
Wenn das Modul fertig ist, kann man dann besser widgets für FHEMWEB oder FTUI bauen.

Weiterhin steht auch das Speichern und Wiederherstellen von Profilen auf den Plan.
Erste Ansätze gibt es hier von wzut:
http://forum.fhem.de/index.php?topic=42002.new;topicseen#new

Genau..., das könnte dann evtl. ein universelles Modul für alle Zeitpläne werden, die die gleiche Syntax benutzen; d.h. es müssen nicht nur Heizpläne sein...

Uwe

fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster

Thorsten Pferdekaemper

Zitat von: locodriver am 04 Dezember 2015, 11:22:39
Genau..., das könnte dann evtl. ein universelles Modul für alle Zeitpläne werden, die die gleiche Syntax benutzen; d.h. es müssen nicht nur Heizpläne sein...
Naja, Gleiche Syntax. MAX und HM sind da schon unterschiedlich.
FUIP

Risiko

Zitat von: Thorsten Pferdekaemper am 04 Dezember 2015, 11:52:44
Naja, Gleiche Syntax. MAX und HM sind da schon unterschiedlich.
Ja genau das sollte das Modul ja abfangen.  Eine einheitliche Schnittstelle Richtung Anwendung und GUI und die Aufbereitung entsprechend der Hardware in die andere Richtung.

masterpete23

Zitat von: Risiko am 03 Dezember 2015, 19:05:28
Hallo.

Ich habe die Änderungen für HM eingepflegt. MAX geht auch noch  ;)
Anbei der aktuelle Stand.

Risiko

Hi,

ich habe den Befehl aus seite 1 und das pm von risiko genommen
Ergebnis ist das BIld - wo kann ich suchen?
Was sind eigentlich die Vorraussetzungen?

JoeALLb

Die Readings deines Devices sind vermutlich leer. eventuell ein getconfig absetzen?
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

masterpete23

Sorry das war mein Fehler. Auf der falschen fhem Instanz eingespielt

Gesendet von meinem Huawei Honor 7


Andi35

Hallo Zusammen.

Erst mal Danke für diese super Arbeit. Ich bin ziemlicher Laie was diese Programmierung an geht, und deshalb auf solche vorgefertigten Lösungen angewiesen.
Ich habe also das Wochenprogramm bei mir in FHEM ein gebaut, und bin super zufrieden damit.
Jedoch habe ich, wie schon durch den User Mr.Heat hier eingebracht, im Wohnzimmer zwei Max Thermostate. Bei diesen musste ich mit dem Wochenprogramm immer jedes Thermostat einzeln programmieren, weil die Raumlösung (wie bei original Max Software) hier nicht funktioniert. Das heißt, das Wochenprogramm wird immer nur auf dem Thermostat ausgeführt, auf welchem es auch Programmiert wurde.
Ziemlich umständlich und es schleichen sich schnell Fehler ein.
Jetzt haben ich hier ---> http://forum.fhem.de/index.php/topic,42002.new/topicseen.html#new eine für mich praktikable Lösung gefunden. Ich habe mir einen Schalter Dummy erstellt, mit welchem ich über max-backup bei Betätigung zuerst das Wochenprogramm des einen Thermostates in eine backup Datei sichere, und danach dieselbe Datei in den zweiten Thermostat ein lese.
So muss immer nur ein Wochenprogramm geändert werden und danach einmal der Dummy Schalter betätigt werden. Und schon habe ich das Wochenprogramm auch auf dem zweiten Thermostaten.

Ich weiß nicht, ob es dafür schon eine andere Lösung gibt. Gefunden habe ich jedenfalls nichts. Vielleicht hilft dieser Beitrag auch einfach den Profis hier, beim erstellen einer professionelleren Lösung.

martinp876

Ich finde das Frontend super.
Leider passt mir das Backend garnicht in den kram. Sieht man den system Gedanken ist es nicht brauchbar. Warum?
Es geht mit der Entscheidung los, wie das system aufgesetzt sein sollte. Das system sollte alle Parameter verwalten. Das device ist eine Außenstelle, für die Verwaltung kommt es nicht in Frage.
Betrachtet man nun wochenprogramme sollten diese in der zentrale hinterlegt sein. Für hm habe ich dies mit templisten in einem file realisiert. Über Details kann man streiten, nicht über den Ansatz.
Das feature Temperatur listen files für wochenprogramme kann man auch einfach auf max uebertragen, besser eigentlich so verallgemeinern dass es ein Ansatz ist der für beide passt. Sicher auch noch für andere Systeme.

Nun kommt dies Frontend zum tragen. Es sollte nicht die devices bearbeiten sondern die templates in den/dem templistfiles . ich wünsche mir eine Instanz, ich wählen ein template aus dem file, bearbeiten und speichere es.

Kurz um, wenn das tool wochenprogramme in files verwaltet ist es abstrakt, universell und super.
Es müssten folgende Funktionen addiert werden:
Auswahl eines files
Erkenne und auswählen der templates/wochenprogramme aus dem file
Einfügen eines neuen templates in das file mit default settings
Löschen eines templates aus dem file
Verwalten einer Liste von template files

Ich hoffe die technische Idee ist verstanden. Was für Vorteile verspreche ich mir vom Ansatz file Verwaltung:
In hm realisiert ist das teilen von templisten zwischen den Thermostaten.
Man kann profile umschalten, auf thermostatbasis oder per file für die ganze Wohnung
Der zustand der Thermostaten ist prüfbar. Falls etwas geändert wurde im RT kann ich es finden und korrigieren lassen- alles schon in hm existent.
Die Sicherung der listen ist möglich, der Austausch von RTS einfach.

HM hat schon alle optionen- nur das sehr coole Frontend zum editieren der tempfiles eben nicht.


Nachdem ich so viel Werbung gemacht habe - seht ihr die Vorteile und macht aus dem maxwochemprogramm ein fhemwochenprogrammtemplatefileverwaltungstool?
Wäre echt cool

martinp876

Ich finde das Frontend super.
Leider passt mir das Backend garnicht in den kram. Sieht man den system Gedanken ist es nicht brauchbar. Warum?
Es geht mit der Entscheidung los, wie das system aufgesetzt sein sollte. Das system sollte alle Parameter verwalten. Das device ist eine Außenstelle, für die Verwaltung kommt es nicht in Frage.
Betrachtet man nun wochenprogramme sollten diese in der zentrale hinterlegt sein. Für hm habe ich dies mit templisten in einem file realisiert. Über Details kann man streiten, nicht über den Ansatz.
Das feature Temperatur listen files für wochenprogramme kann man auch einfach auf max uebertragen, besser eigentlich so verallgemeinern dass es ein Ansatz ist der für beide passt. Sicher auch noch für andere Systeme.

Nun kommt dies Frontend zum tragen. Es sollte nicht die devices bearbeiten sondern die templates in den/dem templistfiles . ich wünsche mir eine Instanz, ich wählen ein template aus dem file, bearbeiten und speichere es.

Kurz um, wenn das tool wochenprogramme in files verwaltet ist es abstrakt, universell und super.
Es müssten folgende Funktionen addiert werden:
Auswahl eines files
Erkenne und auswählen der templates/wochenprogramme aus dem file
Einfügen eines neuen templates in das file mit default settings
Löschen eines templates aus dem file
Verwalten einer Liste von template files

Ich hoffe die technische Idee ist verstanden. Was für Vorteile verspreche ich mir vom Ansatz file Verwaltung:
In hm realisiert ist das teilen von templisten zwischen den Thermostaten.
Man kann profile umschalten, auf thermostatbasis oder per file für die ganze Wohnung
Der zustand der Thermostaten ist prüfbar. Falls etwas geändert wurde im RT kann ich es finden und korrigieren lassen- alles schon in hm existent.
Die Sicherung der listen ist möglich, der Austausch von RTS einfach.

HM hat schon alle optionen- nur das sehr coole Frontend zum editieren der tempfiles eben nicht.


Nachdem ich so viel Werbung gemacht habe - seht ihr die Vorteile und macht aus dem maxwochemprogramm ein fhemwochenprogrammtemplatefileverwaltungstool?
Wäre echt cool

locodriver

Ich stimme Martin voll und ganz zu  :).

Siehe Post #67 von mir als Beispiel für Templisten.

Schönen 3. Advent!

Uwe
fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster

masterpete23

Zitat von: JoeALLb am 04 Dezember 2015, 23:54:59
Die Readings deines Devices sind vermutlich leer. eventuell ein getconfig absetzen?
nun habe ich es auf der richtigen instanz - wie sende ich ein getconfig?