widgets, zeitschalturen und baukästen

Begonnen von justme1968, 23 Januar 2015, 14:21:01

Vorheriges Thema - Nächstes Thema

justme1968

so in etwas hatte ich mir das vorgestellt. ja.

wenn der weekdaytimer aber für euch funktioniert kann ich mich auch da dran hängen. das wollte ich sowieso uns unsbhängig von einem neuen device noch machen.

gruß
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

ich hab das nicht im Einsatz. Ein dediziertes device kann schon besser sein, mal schauen was Bernd oder andere dazu sagen. Gibt es Defizite die durch ein spezielles device gelöst werden können ?

vg
jörg

bgewehr

#62
Ganz kurz die aktuelle Architektur:
Im Frontend (SmartVISU) wird eine UZSU-Schaltfläche zu einem Device (Lampe, Rollladen) zugefügt.
Im Backend (fhem) wird dem entsprechenden Device (Lampe, Rollladen) ein User-Reading uzsu einmalig manuell hinzugefügt und mit {} initialisiert.
Im Frontend Interface (fronthem) wird über einen Converter "UZSU" das Ergebnis der Benutzerkonfiguration im Frontend als strigified JSON in das Reading uzsu des passenden fhem-Device geschrieben oder eben daraus gelesen. Damit ist die UZSU Einstellung persistent gesichert, absturz- und neustartsicher und leicht wieder zu finden.

Ein fhem notify wacht über *uzsu* events und erzeugt aus dem jeweiligen JSON-String einen Weekdaytimer UZSU_devicename, der die Einstellungen aus dem JSON erhält.

(Einziger Wermutstropfen: Änderungen an den UZSU-Settings, die durch einen Neustart ohne vorheriges save in den WDT verloren gegangen sind, sind zwar im uzsu-reading der devices gespeichert, aber sie müssen durch erneuten Aufruf der betroffenen UZSU im frontend in die WDT aktualisiert werden. Es ist also ein inkonsistenter Zustand nach Absturz/Neustart möglich, der manuell behoben werden muss/kann. Nicht schön, aber für mich auch nicht schlimm, da kein Datenverlust.)


Hier der notify:

define UZSU notify .*:uzsu:.* { UZSU_execute($NAME, $EVTPART1) }


Die Funktion USZU_execute() macht dann daraus Weekdaytimer:

use JSON;

###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
  my ($device, $uzsu) = @_;
 
  $uzsu = decode_json($uzsu);
  fhem('delete wdt_'.$device.'_uzsu');
  my $weekdays_part = " ";
  for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
      my $weekdays = $uzsu->{list}[$i]->{rrule};
      $weekdays = substr($weekdays,18,50); 
      if (($uzsu->{list}[$i]->{active})) {
          $weekdays_part = $weekdays_part.' '.$weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value};
      }
  }
  fhem('define wdt_'.$device.'_uzsu'.' WeekdayTimer '.$device.' en '.$weekdays_part);
  if ($uzsu->{active}){   
     fhem('attr wdt_'.$device.'_uzsu disable 0');
  } else {
     fhem('attr wdt_'.$device.'_uzsu disable 1');
  }   
}


Das läuft jetzt schon länger stabil bei mir und ist simpel.

Mit der offiziellen Version 2.0 der SV-UZSU kann zeitgesteuert geschaltet werden. Man kann bool, numeric oder list als Werteselektoren verwenden, jeweils mit einigen Parametern.

Mit dem Release Candidate 3.0 kann auch Sunrise und Sunset mit min, max und offset geschaltet werden. Dazu wurde der JSON-String erweitert so dass es leicht fällt, aus den JSONS wieder WDT zu erstellen.

Nun soll auch noch eine Lösung für Feiertage und Ferien her, was mit der letzten Erweiterung des WDT (Tage 7 und 8) nun leicht möglich sein sollte. Dies wird erst nach Veröffentlichung der Version 3 des SmartVISU UZSU-Widgets erfolgen.

JSON-String aus RC3:

{"active":true,"list":
[{"value":"0","time":"07:00<sunrise","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","active":true,"event":"sunrise","timeCron":"sunrise","timeMin":"07:00","timeMax":"","timeOffset":""},
{"value":"0","time":"09:00<sunrise","rrule":"FREQ=WEEKLY;BYDAY=SA,SU","active":true,"event":"sunrise","timeCron":"sunrise","timeMin":"09:00","timeMax":"","timeOffset":""},
{"value":"100","time":"20:00<sunset","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","active":true,"event":"sunset","timeCron":"sunset","timeMin":"20:00","timeMax":"","timeOffset":""},
{"value":"100","time":"21:00<sunset","rrule":"FREQ=WEEKLY;BYDAY=SA,SU","active":true,"event":"sunset","timeCron":"sunset","timeMin":"21:00","timeMax":"","timeOffset":""}]}


Dieser String definiert die UZSU aus dem Bildanhang.

Damit die Surise Daten ausgewertet werden können, muss die UZSU_execute() entsprechend angepasst werden:

###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
  my ($device, $uzsu) = @_;
 
  $uzsu = decode_json($uzsu);
  fhem('delete wdt_'.$device.'_uzsu');
  if ($uzsu->{active}){
  my $weekdays_part = " ";
  for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
      my $weekdays = $uzsu->{list}[$i]->{rrule};
      $weekdays = substr($weekdays,18,50); 
      if (($uzsu->{list}[$i]->{active})) {
      if ($uzsu->{list}[$i]->{event} eq 'time'){
          $weekdays_part = $weekdays_part.' '.$weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value};
      }
        else {
          $weekdays_part = $weekdays_part.' '.$weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',"'.$uzsu->{list}[$i]->{timeMin};
if ($uzsu->{list}[$i]->{timeMax}) {
$weekdays_part = $weekdays_part.'","'.$uzsu->{list}[$i]->{timeMax};
}
$weekdays_part = $weekdays_part.'")}|'.$uzsu->{list}[$i]->{value};
        }         
      }
  }
  fhem('define wdt_'.$device.'_uzsu'.' WeekdayTimer '.$device.' en '.$weekdays_part);
  fhem('attr wdt_'.$device.'_uzsu room UZSU');
  }   
}


Damit werden dann die {sunrise_abs(...)} usw richtig gebildet.

Nächster Schritt ist die Einführung des Feiertags/Ferientags in V>3.0.

Siehe dazu auch http://github.com/mworion das USZU-Repo.

Mehr Aufwand mit noch mehr fhem Devices würde ich eigentlich nur ungern treiben... was meint Ihr?
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868

herrmannj

Hi,

ich kann da gut mit leben andere Sachen zu machen. Plots und so :)

vg
jörg

rudolfkoenig

Zitatanbei ein vorschlag für den commandref patch.
Eingecheckt.

Zitatvermutlich wäre eine darstelung mit mehr beispielen und screenshots bald besser als die lange liste der möglichen widgets.

Sowas kann man in der fhemwiki machen. Ich sehe eher zwei andere Baustellen, wozu ich aber noch keine konkreten Ideen habe: Abspaltung der widget-Beschreibung in einem separaten Dokument (doch eine Idee: hinten in den .js Dateien, analog zu den perl Modulen), und Aufspaltung der commandref, der wg. der 1.5MB selbst auf schnelleren Rechner eine merkbar lange Zeit zum Laden braucht. Allerdings kann man dann nicht mehr so einfach suchen.

ph1959de

Zitat von: rudolfkoenig am 09 April 2015, 10:22:54
... Aufspaltung der commandref, der wg. der 1.5MB selbst auf schnelleren Rechner eine merkbar lange Zeit zum Laden braucht. Allerdings kann man dann nicht mehr so einfach suchen.

<leicht off-topic>
Das mit der Suche hat noch eine andere Seite: viele (Such-)Begriffe tauchen bei mehreren Modulen auf und es passiert mir immer mal wieder, dass ich bei den Treffern dann nochmal "überprüfen" muss, ob ich wirklich noch in der Beschreibung zum "richtigen" Modul bin.

Das lässt sich allerdings seit ein paar Wochen (Monaten?) durch die Aufspaltung der Hilfe im Frontend (die möglicherweise vielen Benutzern noch nicht so geläufig ist) mittlerweile ganz gut handhaben.
<back-to-topic>

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

Joker

Wollte einfach mal Danke sagen für dieses Widget! Benutze es mit fronthem/smartVISU. Es in Betrieb zu nehmen hat einigermaßen gut funktioniert und ich konnte einen ganzen Haufen alter "at"s einfach löschen und jetzt mit der Zeitschaltuhr komfortabel ersetzen.
Super!

Was ich noch nicht so gut finde, ist dass vieles an unterschiedlichen Stellen liegt und steht:
- es gibt das mworion repo, dort ist wenn ich es richtig sehe die aktuellste Version vom Widget
- es gibt das repo von hermannj, dort gibt es auch das Widget, allerdings älter (?)
- ebenfalls von hermannj gibt es das fronthem repo, dort findet man eine Version der fronthemutils, die evtl. zu einem der beiden Widgets passt?
- dann gibt es hier im Thread gepostet Code für die Funktion UZSU_execute, die zur aktuellsten Version aus dem mworion repo passt, aber vermutlich nicht zu der im repo von herrmannj?
- dann gibt es einen Wiki-Eintrag, wo man auch Code findet, wo man dann durch sehr genaues lesen herausfinden kann, welche Version zu was passt. Die UZSU_execute zur aktuellsten Version vom Widget findet man aber scheinbar gar nicht in irgendeinem repo?

Die vielen Fragezeichen am Ende der Punkte sollen andeuten, dass ich mir das alles so denke, aber nicht sicher bin  ;) Um das zu tun, muss man das Wiki lesen, hier den Thread lesen, und idealerweise noch einiges aus anderen smartVISU-Threads im Hinterkopf haben.

Ich fände es gut wenn man den ganzen Code der zu dem Widget gehört (inclusive dem, was in die fronthemUtils muss) in EIN repo packt und dort pflegt, und in einer ebenso dort abgelegten Datei beschreibt, was wo hin muss.
Mindestens sollte man den Code aus dem Wiki entfernen, denn der ist quasi per Definition veraltet, sobald jemand was in eins der Repos eincheckt. Es würde eigentlich reichen wenn man im Wiki die Repos und die readme verlinkt, und evtl. ein paar Beispiele hineinpackt, ähnlich wie es in der FHEM commandref gemacht ist.

bgewehr

Stimmt, da müssen wir mal Ordnung schaffen, ist irgendwie gewachsen.

Eins aber möchte ich noch graderücken:
Im fronthem Repo ist die aktuell releaste V2.0 der UZSU abgelegt, die ist stabil und intensiv getestet.
Die hier angesprochene V 2.94 oder der RC 3.0 ist develop, also teilweise ungetestet und nicht offiziell released. Daher die vielen Versionen, die hier und da rumschwirren. Dieses hier ist ein Developer Thread, deswegen reden wir hier über Developer Versionen! Den code im Wiki nehme ich am WE raus!
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868

igami

Hallo zusammen,

für meine Wochenprogramme möchte ich die uzsu verweden mit folgenden Einstellmöglichkeiten:
uzsuSelect,Wochentage
uzsuDropDown,Uhrzeit in 15 Minuten Abstufungen
uzssuToggle,Tag,Nacht
Mehrere Einträge

Bekomme ich das mit dem uzsu so hin? Habe nun schon einiges ausprobiert, im Prinzip müsste ja nur bei uzsu das enable,disable gemappt werden und die Uhrzeit verfeinert.

Grüße
igami
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

bgewehr

Im Dev 3.1 GitHub vom MWorion ist es wieder möglich, den Flip mit Textausgabe zu definieren, damit z. B. Homematic Schalter direkt mit on bzw. off versorgt werden können.

https://github.com/mworion/uzsu_widget/issues/13#issuecomment-122026789

Wer kann das mal testen?
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868

dev0


Cybers

Ich habe es auch gerade eingebaut. Läuft super.
Damit kann ich jetzt sogar meine Jalousien-Zeitsteuerung über das UZSU-Widget mit verschiedenen Prozentwerten realisieren.
Der WAF von Smartvisu hat sich wieder erhöht...

Gruß, Sascha
FHEM 6.3 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

bgewehr

#72
Hallo, ich habe festgestellt, dass der neue Code für die UZSU_execute das Deaktivieren einer UZSU im SV nicht mehr korrekt in fhem umsetzt, das wdtdevice bleibt aktiv. Erwarten würde ich ein inaktives wdt mit den richtigen Zeiten usw. Also wundert Euch nicht! Der Zweig if UZSU active false muss noch ausgebaut werden! Wer hat Zeit (ich grade nicht)...?

Edit:
Ich hab's vom Handy aus gemacht:
https://github.com/herrmannj/fronthem/pull/11

Bitte um Tests und Bestätigung!
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868

dev0

Zitat von: bgewehr am 19 Juli 2015, 12:04:24
Bitte um Tests und Bestätigung!
Funktioniert. Dem wdt device wird das Attribut disable 0/1 zugeweisen, wenn das gesamte UZSU aktiviert/deaktiviert wird. Das gleichnamige Reading wird ebenfalls aktualisiert.

bgewehr

FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868