Zeitprofil in Tablet UI

Begonnen von MarkoP, 06 Dezember 2019, 15:11:08

Vorheriges Thema - Nächstes Thema

MarkoP

Hallo, bin noch Neu hier, sollte der Threat also falsch positioniert sein, bitte verschieben.

Ich bin auf der Suche nach einer Möglichkeit ein Zeitprofil für die Schaltung einer Lampe oder Thermostat über Tablet UI zu realisieren.
Meine Suche im Forum hat leider bisher keine verwertbaren Treffer geliefert.

Ich stelle mirdas ganze so vor, dass in einem PopUp in Tablet ui für jeden Tag eine Anfangs und Endzeit (besser sogar jeweils mehrere) Uhrzeiten angegeben werden und einem Profilnamen zugeordnet werden. So dass man am Ende mehrere Profile mit mindestens einem Schalttermin zum Ein-/Ausschalten pro Tag hat. Dieses Profil soll dann dem Device zugeordnet und von diesem "abgearbeitet" werden. Ich denke es ließe sich eventuell am ehesten mit WeekdayTimer realisieren, aber keine Ahnung, bin halt noch neu.

Hat jemand eine Idee zur Umsetzung oder vielleicht sogar schon fertige Codesnipsel die ich umarbeiten kann?
Fhem-Server läuft per Bridge mit eigener IP auf einem Docker-Container auf meinem NAS. Alle Geräte haben eine statische IP im Netzwerk und laufen im gleichen Subnetzwerk. DHCP ist deaktiviert. DNS läuft über den Router (Fritzbox Cable), alternative über Googles 8.8.8.8

rabehd

Auf den ersten Blick würde ich sagen, dass gehört unter Frontends.
Aber für mich ist das Herangehen falsch, und damit wäre es eine Anfängerfrage.

TabletUI ist für mich eine Oberfläche, die FHEM "schön" darstellt und Befehle übermittelt (Button drücken).
Das Problem muss also durch/im Device in FHEM gelöst werden. TabletUI zeigt die Werte des Device an und kann z.B. ein Profil wechseln.

Erzähle mal welche Lampen und Thermostate du steuern willst. Dafür gibt es bestimmt schon Module, mir fallen welche ein.
Auch funktionierende Lösungen kann man hinterfragen.

Beta-User

Für den WeekdayTimer gibt es afaik ein entsprechendes Widget für Tablet-UI, darüber lassen sich aber (bislang noch nicht) (vermutlich andere als weekprofile) Profile nicht einfach so wechseln, sondern damit wird die DEF direkt bearbeitet.

Temperaturprofile kann man (u.a. auch) recht dynamisch und (unter FHEMWEB direkt) mit weekprofile wechseln (auch, wenn der WeekdayTimer ein Profil von weekprofile verwenden soll), ob das aber unter TabletUI klappt bzw. sinnvoll dargestellt werden kann, ist eine andere Frage, die ich nicht beantworten kann...

Gehört tendenziell wirklich nach Frontends.
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

Prof. Dr. Peter Henning

Nicht notwendigerweise, man kann es auch unter Automatisierung sehen...

Das Modul YAAHM liefert genau das gewünschte- allerdings nicht mit Popups.

LG

pah

MarkoP

Erstmal danke fürt die Antworten, war leider etwas beschäftigt in den letzten Tagen, daher die verspätete Rückmeldung.

@rabehd
Ich möchte damit zum Beispiel alle Heizkörperthermostate steuern, quasie genau wie die Profile die man direkt im Thermostat einrichten kann, nur halt Oma-gerecht umgesetzt (am Thermostat selber würde meine Freundin verrückt werden, da muss alles einfach un simple sind)
Anderes Beispiel sind z.b. die Wohnzimmerlampen die zu regelmäßigen Zeiten ein- und ausgeschaltet werden, was man ja mit dem at-befehl so einrichten kann. Ich fände es nur schön, wenn man verschiedene Profile hätte, die unterschiedliche Zeiten nutzen wegen Wechselschicht etc..

@Beta-User
Dein Ansatz besteht - wenn ich es richtig verstehe - darin, die Profile im Device selbst anzulegen und über die Weboberfläche nur auszuwählen bzw. zu aktivieren, richtig?

@Prof. Dr. Peter Henning
Das Modul sagt mir nichts, bin eben noch Anfänger in der ganzen Materie. Gibt es irgendwelche aussagekräftigen Dokumentation dazu oder kann man im fhem-Forum dazu was finden?
Fhem-Server läuft per Bridge mit eigener IP auf einem Docker-Container auf meinem NAS. Alle Geräte haben eine statische IP im Netzwerk und laufen im gleichen Subnetzwerk. DHCP ist deaktiviert. DNS läuft über den Router (Fritzbox Cable), alternative über Googles 8.8.8.8

Beta-User

Zitat von: MarkoP am 09 Dezember 2019, 09:27:10
@Beta-User
Dein Ansatz besteht - wenn ich es richtig verstehe - darin, die Profile im Device selbst anzulegen und über die Weboberfläche nur auszuwählen bzw. zu aktivieren, richtig?
...kommt drauf an, über was wir reden...

Vorab: Mit TabletUI habe ich keine Erfahrung. Für mich war FHEM bisher eher ein Dienst im Hintergrund, mit Schwerpunkt auf "Automatisierung".

So habe ich z.B. für meine Homematic-Thermostate Temperaturlisten angelegt (siehe https://wiki.fhem.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten), die eben dann z.B. via notify dann gewechselt werden, wenn Ferien (oder eben nicht) sind. Die zu bearbeiten und ggf. für's neue Schuljahr anzupassen, ist aber eben wenig komfortabel...
Man kann dasselbe erreichen, wenn man weekprofile nutzt, das z.B. dann auch MAX-Thermostate versorgen kann (oder eben WeekdayTimer). weekprofile hat einen eigenen Editor für FHEMWEB, der ist recht komfortabel, aber wie man das nach TabletUI bringt? K.A....

Aber mit diesen Lösungen wechselt man schlicht "kurz mal" zwischen verschiedenen (vordefinierten) Profilen hin und her. MMn. ist das im Regelfall auch völlig ausreichend, wenn man das braucht, kann man ja immer auch eine "override"-Funktion definieren, die z.B. in bestimmten Räumen dann manuell eine bestimmte Temperatur für einen definierten Zeitraum (ab jetzt usw.) einstellt...

Das ganze bis hierher betraf dann ausschließlich Temperaturlisten!

Wenn es genereller sein soll:
Für WeekdayTimer (der kann neben Temperaturlisten auch beliebige Befehle) gibt es ein Widget (zumindest für die FUIP-Variante). Damit kann man die DEF des WeekdayTimer direkt bearbeiten (im "classic"-Modus ohne weekprofile-Unterstützung), das scheint auch kompfortabel zu sein, hat halt den Nachteil, dass man die Änderungen separat speichern muß, sonst sind die nach einem Neustart weg.

MMn. zäumst du das Pferd von hinten auf, indem du mit der Visualisierung anfängst, ohne bereits zu wissen, was du konkret steuern willst (z.B. für Rollläden gäbe es dann noch AutoShuttersControl).

Du solltest mMn. erst ein konkretes Stück Hardware nehmen und davon ausgehend klären, was du eigentlich brauchst.



@pah: Ist nicht alles irgendwie "Automatisierung"? (Und was sucht der WeekdayTimer dann unter "Kalender"?) Der TE fragte mMn. nach einem Browserinterface in einer bestimmten Ausrichtung, und das ist eben weniger Automatisierung im Sinne dieses Forums, sondern Frontend, oder?...
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

Prof. Dr. Peter Henning

ZitatGibt es irgendwelche aussagekräftigen Dokumentation dazu oder kann man im fhem-Forum dazu was finden?
FHEM-Wiki oder FHEM-Buch.

Allgemein sollte man als Anfänger beim Suchen nach Hilfe immer eine bestimmte Reihenfolge einhalten, siehe Anlage.

LG

pah

MarkoP

@Beta-User
Ist schon festgelegt was ich will, wie gesagt, Lampen und Thermostate halt. Das ich da jetzt keine fixe Artikelbezeichnung nennen kann sollte klar sein, denn obwohl ich bereits entsprechende Hardware zu Hause habe, weiß ich die Bezeichnung natürlich nicht auswendig.

Nehmen wir als Beispiel das Heizkörperthermostat:
Mein Ziel ist halt einfach die Eingabe der Werte für entsprechende Profile nicht mehr am Heizkörperthermostat selbst zu machen, sondern über eine Eingabemaske. Da ich als Virtualisierung Tablet ui nutze ist das dann die Folge, dass die Eingabe darin erfolgen soll. Es geht einfach darum, dass meine Freundin oder auch andere unerfahrene Benutzer Zeiten ändern können ohne Kenntniss vom Thermostat selbst haben zu müssen.

@Prof. Dr. Peter Henning
Danke für den Link, den Kenne ich noch nicht. Diue ersten Schritte und das Heimautomatisierung mit Fhem habe ich beides tatsächlich schon gelesen, aber wahrscheinlich mehr als die Hälfte bereits wieder vergessen. Wenn man das nicht direkt mehrmals real umsetzen kann geht es oft links rein, rechts raus. Darum sammle ich solche Nachschlagewerke immer um jederzeit noch mal reinschauen zu können.
Fhem-Server läuft per Bridge mit eigener IP auf einem Docker-Container auf meinem NAS. Alle Geräte haben eine statische IP im Netzwerk und laufen im gleichen Subnetzwerk. DHCP ist deaktiviert. DNS läuft über den Router (Fritzbox Cable), alternative über Googles 8.8.8.8

Beta-User

OK, dann bist du hier bei Automatisierung also falsch, du suchst ausschließlich was für TabletUI.

Suche mit den von mir genannten Stichworten liefert:
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

rabehd

Bleiben wir beim Heizkörperthermostat und der Herangehensweise von Beta-User, welche ich unterschreiben würde.

Ich habe Thermostate von Homematic. Die sind in fhem eingebunden.
Ich käme somit nie auf die Idee die Profile am Thermostat einzustellen. Das geht doch ganz einfach (das richtige Device vorausgesetzt, ich glaube weekprofile). Damit lassen sich verschiedene Profile anlegen und editieren. Bei Bedarf (Event) lädt man das hoch. Das Ändern passiert so selten, dass ich nicht auf die Idee käme es in TabletUI oderetwas ähnlichem zu tun. Dafür reicht mir FHEMweb am PC.
Für mich ist ein Profil etwas zeitlich stabiles.


Zusätzlich zum aktuellen Profil  übersteuere ich manuell die Temperatur und überwache sie (Stichwort Wecker).
Auch funktionierende Lösungen kann man hinterfragen.

MarkoP

Zitat von: rabehd am 09 Dezember 2019, 14:09:07
Für mich ist ein Profil etwas zeitlich stabiles.

Da gebe ich dir grundssätzlich recht. Mir geht es konkret um die Anpassung von Wechselschichten.
Bedeutet in einer Woche mit Frühschicht (8-15 Uhr) sehen die Profilzeiten natürlich anders aus als in einer Woche mit Spätschicht (12-19 Uhr).

Wenn ich einfach nur ein fixes Profil anlege heize ich egal wann immer die halbe Schicht für nichts.
Fhem-Server läuft per Bridge mit eigener IP auf einem Docker-Container auf meinem NAS. Alle Geräte haben eine statische IP im Netzwerk und laufen im gleichen Subnetzwerk. DHCP ist deaktiviert. DNS läuft über den Router (Fritzbox Cable), alternative über Googles 8.8.8.8

Beta-User

Ebend. Für sowas erstellt man zwei Profile (oder ggf. noch ein weiteres für Urlaub zu Hause) und wechselt; da muß man nichts im UI rumbasteln, sondern reagiert z.B. auf calendar-Events...

Die einzige Frage die bleibt, ist, was in Bezug auf eine konkrete Hardware die praktikabelste Vorgehensweise ist; CUL_HM eröffnet (teilweise) andere Optionen als MAX oder ZWave oder HMCCUDEV.

Bin dann mal raus, ich habe nicht den Eindruck, dass du ernsthaft an Vorschlägen interessiert bist, sondern v.a. erst mal ignorierst, was dir nichts sagt oder nicht zu deiner aktuellen Gedankenwel paßt :( .
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

rabehd

@Beta-User: Den Eindruck habe ich auch.

Somit wäre ich auch erstmal raus.
Auch funktionierende Lösungen kann man hinterfragen.

MarkoP

Sorry, aber was ist daran so schwer zu verstehen, dass ich meiner Freundin die Möglichkeit einräumen will selber Zeiten festzulegen auch wenn diese von der Bedienung der Hardware Null Ahnung hat. Eure Vorschläge sind sicher sinnvoll aber sie bringen nicht das Ziel was ich will, warum sollte ich sie also beachten.

Ich könnte mir das Leben viel einfacher machen wenn meine Freundin sich mal mit der Technik auseinander setzten würde, aber sie macht es halt nicht, also bleibt mir nichts anderes übrig als alles so einzurichten, dass sie es als DAU eben auch bedienen kann. Denn die Zeiten sind von ihr und leider Gottes variable abhängig von der Jahreszeit. Allerdings sagt sie nicht wann sich wieder mal was ändert, so dass dann wieder mal für nichts geheizt wird wenn ich es mit Wochen verzögerung merke und anpasse.
Wenn das für euch nicht nachvollziehbar ist, kann ich nichts dafür.
Das ich es eben so machen will hat also seine festen und unabänderlichen Gründe. Entweder dies geht oder nicht, aber es bringt mir rein gar nichts ständig völlig andere Wege - ja sogar welche die ich begründeterweise im vornherein ausgeschlossen habe - vorgeschlagen zu bekommen.

Das ist genauso als wenn ich sage ich will mir einen neuen Ford und nichts anderes kaufen und jemand sagt: "Schau mal da und da, da steht ein guter Toyota".

Was die Hardware angeht hatte ich geschrieben, dass es sich um Homematic-Thermostate bzw. Phllips Hue-Lampen handelt.
Erstere werden per CUL angesprochen, letztere über dessen Hub. Doch davon war bisher nie die Rede bzw. die Frage danach.

Wenn ihr raus seid, weil ihr dafür kein Verständnis habt, kann ich es nicht ändern. Es bringt mich aber genauso wenig vom Ziel ab wie die Vorschläge die ich aus genannten Gründen eben ausschließen muss Manchmal läuft das Leben eben nicht wie man will und es ist nicht der einfachste Weg sondern nur der schwerste Weg möglich. Ich würde mir auch wünschen das es anders ginge, tut es aber nun mal nicht. Also hat das nichts mit Ablehnen zu tun, sondern einfach damit, dass es nicht das Ziel bringt das notwendig ist.
Fhem-Server läuft per Bridge mit eigener IP auf einem Docker-Container auf meinem NAS. Alle Geräte haben eine statische IP im Netzwerk und laufen im gleichen Subnetzwerk. DHCP ist deaktiviert. DNS läuft über den Router (Fritzbox Cable), alternative über Googles 8.8.8.8

Beta-User

Sorry zurück, aber das, was du willst, ist sehr wohl zu verstehen. Ich verstehe nur nicht, warum du die vorhandenen Vorschläge nicht aufgreifst...

Also nochmal die summary: Was das Licht angeht, kannst du das mit WeekdayTimer lösen; dafür gibt es ein TFUI-Widget. (Ändert jemand die DEF, kannst du dich ja benachrichtigen lassen  ;) ...)

Für die HM-Thermostate würde ich an deiner Stelle mal das weekprofile-widget ansehen. Könnte sein, dass das das macht, was du willst (und evtl. noch einfachere Möglichkeiten für technikferne Menschen bietet, zwischen verschiedenen Szenarien umzuschalten). Wenn's einheitlich sein soll, kannst du auch dafür den WeekdayTimer nehmen, und vermutlich wirft das auch Events, dmait man Info hat, wenn "jemand" was umstellt...
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