Modul weekprofile + FHEMWEB widget

[bismosa]

Hallo!

Gerade mal ausprobiert. Das sieht richtig gut aus! Vielen Dank!

Zur Temperatureinstellung:

Ich denke, dass ist nicht so wichtig und zudem Ansichtssache. Werte kleiner off bzw. größer on kann über FHEMWEB keiner senden.

Meiner Ansicht nach würde ich es "praktisch" finden, wenn auch andere Werte (< 4.5 bzw. > 30.5) direkt in On bzw. Off umgesetzt werden.
Falls man z.B. ein Script in den MyUtils oder ein anderes Modul verwendet, das z.B. Dynamisch bzw. berechnet die Temperaturen setzt oder auch ein Modul, bei dem die Temperatureinstellungen etwas anderes erlauben sollten...wäre dies "praktisch". Die Fehlermeldungen könnte man schnell übersehen und wundert sich dann, warum nichts funktioniert.
Aber wichtig würde ich dies nicht einstufen  Bisher ist mir kein Modul bekannt, das hier Pfuschen könnte (außer Max_Temperature  )

Gruß
Bismosa 

[Wzut]

@Risiko, ich nutze selbst weekprofile schon ewig, aber es gibt da einen Punkt der mich schon immer "gestört" hat.
Wenn ich ein MAX Device habe das bereits ein Wochenprofil in seinen Readings hat, habe aber noch kein Profil dafür in weekprofile (z.B. neu Anfang)
dann muss ich quasi einmal alle Werte abschreiben und damit das Grundprofil erstellen.
Eleganter wäre es IMHO wenn MAX entweder eine Exportfunktion hätte oder weekprofile eine Import.

Version A , Export MAX
neues Set Kommando in MAX export_weekprofile to <Ziel> , d.h. das Maxmodul würde ein set <name> profile_data <JSON> ausführe.
Hier ist mit Z.Z. noch unklar in welches Profil und wie genau der JSON String ausschauen müsste.
Edit : ich habe das set export_Weekprofile drin und klapp gut. Ziel ist ein Dropdown aller definierten weekprofile Geräte
Der zugefügte Profil Name ist gleich dem MAX Device Namen.

Version B , Import weekprofile
Wenig Arbeit für mich, dafür um so mehr für dich.

[Risiko]

Bisher ist mir kein Modul bekannt, das hier Pfuschen könnte (außer Max_Temperature  )

Na dann weißt ja auch, an wen du dich wenden musst.

[Risiko]

Version A , Export MAX

Version B , Import weekprofile

Hallo wzut,

ich finde Variante B besser. Die Funktion habe ich implizit schon. Hole ja die Wochenprofile von den Devices, wenn man weekprofile mit einem Gerät assoziiert. Stichwort master-Profile. Weiterhin geht der Import dann auch für HM, etc.

Prinzipiell geht es auch jetzt schon (aber evtl. etwas umständlich).
Nämlich so 1):
weekprofile A mit Assoziation zu device anlegen
weekprofile B mit Topics und ohne Assoziation anlegen
Masterprofil von A  nach B senden
ggf. in B kopieren


oder so 2):
weekprofile A mit Assoziation zu device anlegen
masterprofil in A kopieren
Assoziation wieder entfernen

Auf diesen Weg kann man jetzt schon Wochenprofile von einem Hersteller zum Anderen transferieren.

Natürlich wäre eine Importfunktion eleganter.
Ich denke der reine Importbefehl ist überschaubar. Das Ganze ggf. ins FHEM-Widget zu integrieren, ist schon aufwendiger.
Ein

Code Auswählen Erweitern


set weekprofile import <device>

Sollte erstmal reichen!?

Risiko.

[Wzut]

ok , wie du magst. Das aktuelle geprüfte Wochenprofil befindet sich beim nächsten 10_MAX Update im Reading .wp_json
Bsp

Code Auswählen Erweitern

.wp_json        {"Sat":{"time":["24:00"],"temp":["24.5"]},"Sun":{"time":["06:00","22:00","24:00"],"temp":["17","21","17"]},"Mon":{"time":["06:00","09:00","17:00","23:00","24:00"],"temp":["17","21","17","21","17"]},"Tue":{"time":["06:00","09:00","17:00","23:00","24:00"],"temp":["17","21","17","21","17"]},"Wed":{"time":["06:00","09:00","17:00","23:00","24:00"],"temp":["17","21","17","21","17"]},"Thu":{"time":["06:00","09:00","17:00","23:00","24:00"],"temp":["17","21","17","21","17"]},"Fri":{"time":["24:00"],"temp":["24.5"]}}

[Risiko]

Das wäre aber nicht nötig gewesen. Lese doch das Profil jetzt schon aus den Readings aus!

[Wzut]

Nunja , ich hatte ja bereits erfolgreich den Export getestet und dazu brauchte ich den fertigen String.
Da es eh ein verstecktes Reading ist wird ihn die Mehrheit eh nie zu Gesicht bekommen

[Risiko]

Hallo.

Neuer Befehl

Code Auswählen Erweitern


import_profile <device> [profilename]

ist ab morgen verfügbar.
profilename  ist <topic>:<name des Profils>
Ist profilename nicht angegeben, wird default:device verwendet.

[Beta-User]

Im Nachgang zu unserer Diskussion dahingehend, ob man die Konfigurationsdaten von weekprofile bei configDB-Nutzung auch in der DB speichern könnte:

Was configDB angeht, kann ich den Code gerne mal durchsehen,  vorab testen und dann einen patch zur Verfügung stellen?

Anbei eine Testversion als komplette .pm dazu.

Der Ausgangscode ist da im wesentlichen mal (auskommentiert) drin gelassen und das so ausgestaltet, dass erst versucht wird, in der DB zu lesen, und dann im Filesystem samt vorausgehender log-1-Meldung, wenn die Suche in der db fehlschlägt. Damit sollten heutige configDB-Nutzer kein Problem haben, weil eine evtl. vorhandene file auch gelesen wird. Allerdings ist es ggf. etwas irritierend, dass der Wechsel nach configDB danach automatisch erfolgt, sobald man das nächste mal speichert...
Habe dafür aber keine wirklich gute Idee, außer das eben so zu machen.

Im Testsystem ohne configDB war auf die Schnelle kein Problem zu erkennen, aber intensiver getestet habe ich das zugegebenermaßen nicht, daher an der Stelle auch die komplette pm mit der Bitte um weitere Mittester (ich lasse das jetzt mal unter configdB weiter laufen, bin aber (noch) kein intensiver weekprofile-Nutzer).

Gruß, Beta-User

[Risiko]

Danke Beta-User.

Ich habe es fast so übernommen. Nur wenn "configFile" gesetzt ist, wird trotz configdb die Datei verwendet.

Risiko.

[Beta-User]

Danke für die Rückmeldung!

Macht vielleicht Sinn, das nur automatisch zu übertragen, wenn der user sich "nichts" dabei gedacht hatte.

Vielleicht noch ein paar Anmerkungen:
- Wenn der user die File (mit abweichendem Pfad) nach configDB importiert hatte, ist m.E. ein filewrite ins filesysstem falsch/gegen die Erwartung. Da sollte eine komplexere Prüfung hin, wie z.B. ab hier: https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L5364.
- Evtl. wäre es eine Idee, die Änderung auch mit einem gewissen Vorlauf zu machen bzw. erst später "scharf" zu schalten. Neulich habe ich was ähnliches für RandomTimer vorbereitet, der wird auch ab featurelevel 6.1 das Reading "state" berücksichtigen, und nicht mehr auf Value() abstellen...
- Ein kurzer Kommentar in der cref wäre noch gut, wenn es so bleiben sollte (sonst ist es (fast) egal).

Bei Bedarf liefere ich gerne entsprechenden Code (auch als Patch).

[Risiko]

Danke für die Rückmeldung!
- Wenn der user die File (mit abweichendem Pfad) nach configDB importiert hatte, ist m.E. ein filewrite ins filesysstem falsch/gegen die Erwartung. Da sollte eine komplexere Prüfung hin, wie z.B. ab hier: https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L5364.

Wie soll der user das den hinbekommen haben. Bei abweichendem Pfad wird configDB nicht verwendet. Wäre meiner Meinung nach nur mit der Testversion mgl.
Oder ich verstehe nicht ganz, was du meinst.

- Evtl. wäre es eine Idee, die Änderung auch mit einem gewissen Vorlauf zu machen bzw. erst später "scharf" zu schalten. Neulich habe ich was ähnliches für RandomTimer vorbereitet, der wird auch ab featurelevel 6.1 das Reading "state" berücksichtigen, und nicht mehr auf Value() abstellen...

Ja, vielleicht. Denke aber, dass die Anzahl der "Betroffenen" gering ist. Die Meisten werden die Änderung nicht mitbekommen.
Ich sehe auch keine größere mögliche Probleme. Schauen wir mal.

- Ein kurzer Kommentar in der cref wäre noch gut, wenn es so bleiben sollte (sonst ist es (fast) egal).

Steht doch im Changelog. Sollte doch reichen. Siehe auch vorherige Anmerkung. Sehe das auch eher als Anpassung\Fix

Bei Bedarf liefere ich gerne entsprechenden Code (auch als Patch).

Danke. Wenn es größere Probleme oder Nachbesserungen (z.B. wenn sich Betateilchen nochmal meldet) gibt, komme ich gern auf das Angebot zurück.
Mal schauen...

Risiko

[Beta-User]

Wie soll der user das den hinbekommen haben.

Eine (beliebige) file in configDB zu importieren, ist kein Problem, siehe ersten Abschnitt von help zu configDB.

Vermutlich wäre es dann einfacher, wenn überhaupt configDB genutzt wird, erst zu sehen, ob die Datei in der db ist, und ansonsten nur fileread zu machen. Dann muß der Nutzer aktiv importieren; hat er es gemacht, kommt die file aus der db.

War wohl mein Gedankenfehler, automatisch in die db zu schreiben. Baue das gerne entsprechend um...

[betateilchen]

Die Funktionen FileRead(), FileWrite() und FileDelete() wurden seinerzeit exakt deshalb gebaut, damit sich Modulentwickler keine Gedanken darüber machen müssen, ob ein Anwender mit configDB arbeitet oder nicht. Was hier nun passiert ist: Man hat durch ziemlich abstrusen perl-Code dafür gesorgt, dass diese Automatismen unnötigerweise komplett gebrochen werden.

Bin im Hintergrund schon dabei, die entsprechende Unterstützung zu leisten, damit das Modul vielleicht doch noch configDB-kompatibel wird.

Wenn es größere Probleme oder Nachbesserungen (z.B. wenn sich Betateilchen nochmal meldet)

Wenn ich in einer email schreibe, dass ich mich am Wochenende ausführlich melde, dann mache ich das auch...

[betateilchen]

Mir ist noch eine Kleinigkeit aufgefallen, die allerdings nicht direkt was mit configDB zu tun hat.

Code Auswählen Erweitern


  if (!defined($hash->{PROFILES})) {
  Log3 $me, 4, "$me(writeProfileToFile): no pofiles to save";
  return;
  }


pofiles sind vermutlich für den Ar...