widgets, zeitschalturen und baukästen

[bgewehr]

OK, bitte entschuldigt. Ich bin davon ausgegangen, dass wir schon soweit klar sind, möchte aber gern nachholen, was ich bisher verpasst habe:

In smarthome.py gibt es eine UniverselleZeitSchaltUhr, kurz UZSU.

In fhem gibt es mit at die Möglichkeit, beliebige Zeitschaltungen zu bauen, aber kein UI für komplexe Konfigurationen.

Im Projekt fronthem versuchen wir nun, das SV (SmartVISU)-widget für UZSU, das für smarthome.py gemacht worden ist, auch für fhem nutzbar zu machen.

Wir befinden uns in einem Zustand, wo das widget in SV funktioniert und als Ergebnis der Definition des Benutzers ein JSON Objekt ausgibt in der Form:

Code Auswählen Erweitern


{"active":true,"list":[{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH","time":"23:00","value":1,"active":true}]}


Dies entspricht einer aktiven Zeitschaltuhr mit einer Schaltregel an den Wochentagen Mo, Die, Mi, Do um 23 Uhr, wo das verbundene fhem-device auf 1 geschaltet werden soll.

Ich versuche im Moment herauszufinden, wie die einfachste Architektur dafür sein könnte und habe folgendes gemacht:

Ein fronthem-Converter sorgt dafür, das das JSON Objekt als Userreading 'uzsu' an das zu schaltende fhem-device hinzugefügt wird.

Ein n_uzsu notify wartet auf events von Readings, die uzsu heißen

Code Auswählen Erweitern


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


und ruft dann die folgende Funktion (Prototyp, bisher ohne Schleife) aus 99_whatever.pm auf:

Code Auswählen Erweitern


###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
  my ($device, $uzsu) = @_;
  my $result = Log(1, 'UZSU execute parameters: ' . $device . ', ' . $uzsu );
  $uzsu = decode_json($uzsu);
  #$result = Log(1, 'UZSU execute params: ' . $uzsu->{active} . ', ' . $uzsu->{list}[0]->{rrule} );
 
  if ($uzsu->{active}){
  fhem('delete a_'.$device.'_uzsu1');
  fhem('define a_'.$device.'_uzsu1 at +*' . $uzsu->{list}[0]->{time} .' {fhem "set ' . $device . ' ' . $uzsu->{list}[0]->{value}.'"}');
  }   
  else {
  fhem('delete a_'.$device.'_uzsu1');
  }
}


Damit lässt sich jetzt, nach und nach die Regeln aus dem JSON abarbeiten und in at-Befehle umsetzen. Wenn die ganze Zeitschaltuhr inaktiv ist, werden alle ats gelöscht.

Sollte doch soweit gehen, ich bin aber nicht sicher, ob das der richtige Ansatz ist, daher hier meine Nachfrage.

Ich danke Euch für Eure Nachsicht und bitte erneut um Eure Aufmerksamkeit!

[rudolfkoenig]

Ich meine das ist nicht der richtige Ansatz.

"UZSU" heisst in FHEM WeekdayTimer, wenn man das aufhuebschen will, dann muesste man (fuer FHEMWEB) die Funktionen FW_summaryFn/FW_detailFn in WeekdayTimer erstellen.

[bgewehr]

Ich habe nun das Objekt WeekdayTimer verwendet und erhalte genau das Ergebnis, das ich mir gewünscht habe.

Wenn in der UZSU mehrere Zeilen definiert wurden, dann werden auch mehrere WeekdayTimer definiert. Das ist nicht ganz optimal, aber OK, denke ich, oder?

Vielen Dank!

Vielleicht könnt Ihr noch einen Blick auf meinen Code werfen und mir noch evtl. Verbesserungsvorschläge machen?

Code Auswählen Erweitern


###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
  my ($device, $uzsu) = @_;
 
  $uzsu = decode_json($uzsu);

  for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
  my $weekdays = $uzsu->{list}[$i]->{rrule};
  $weekdays = substr($weekdays,18,50);
 
  fhem('delete wdt_'.$device.'_uzsu'.$i);
  fhem('define wdt_'.$device.'_uzsu'.$i.' WeekdayTimer '.$device.' en '.$weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value});
 
  if (($uzsu->{active}) && ($uzsu->{list}[$i]->{active})) {
  fhem('attr wdt_'.$device.'_uzsu'.$i.' disable 0');
  } else {
  fhem('attr wdt_'.$device.'_uzsu'.$i.' disable 1');
    }
  }   
}


Das macht aus

Code Auswählen Erweitern


{"active":true,"list":[{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA","time":"20:00","value":1,"active":true},{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA","time":"21:00","value":0,"active":true}]}


dann

Code Auswählen Erweitern


define wdt_Leselampe_uzsu0 WeekdayTimer Leselampe en MO,TU,WE,TH,FR,SA|20:00|1
attr wdt_Leselampe_uzsu0 disable 0

define wdt_Leselampe_uzsu1 WeekdayTimer Leselampe en MO,TU,WE,TH,FR,SA|21:00|0
attr wdt_Leselampe_uzsu1 disable 0


Perfekt, oder?

[rudolfkoenig]

Ich bin noch verwirrt, es klingt fuer micht verkehrt herum: du kriegst eine Zeitspezifikation aus blauem Himmel, mit dem man mehrere Weekdaytimer anlegt. Normal waere fuer mich, dass der Benutzer erst ein Weekdaytimer anlegt, und dann die Einstellungen dazu anpasst.

[bgewehr]

Das hat mit der Verwendung von SmartVISU zu tun. Dort wird von einem Zeitschalt Uhr Widget der JSON String ausgegeben. Diesen richtig zu verarbeiten war mein Ziel.


Gesendet von iPhone mit Tapatalk

[justme1968]

ich würde die einzelnen zeilen in den gleichen WeekdayTimer stecken. das problem dabei ist nur das man dann nicht selektiv disable setzen kann.

was auch noch fehlt ist einen bestehenden timer zu ändern statt neue zu erzeugen. in zusammenhang damit steht auch das zur zeit nur die angabe von festen zeitpunkten möglich ist. ein auf sunrise oder sunset basierender zeitpunkt würde verloren gehen wenn wir nicht im json eine kodierung dafür vorsehen.

da vermutlich die meisten schaltzeiten relativ zum sonnenauf- oder -untergang definiert werden halte ich das für sehr wichtig.

[ZeitlerW]

Hallo zusammen,

ich bin ja mehr als glücklich darüber, daß sich jemand dieses Themas annimmt. (> 40 weekday - timer manuell zu pflegen ist halt auch eine Aufgabe )

Vielleicht könnte man auch noch eine Lösung für die <condition> finden z.B. ein Devicestate true/false. Ich bräuchte das z.B. für die Jalousieen als Sperrobjekt, damit diese nicht runterfahren wenn die Terrassentür offen ist

vG
Wolfgang

[Elektrolurch]

Zitat:
Ich bräuchte das z.B. für die Jalousieen als Sperrobjekt, damit diese nicht runterfahren wenn die Terrassentür offen ist

Ich werte dazu aus:
1. Einen Türkontakt
2. einen auf der Terrasseinstallierten BWM.
3. Die Außenbeleuchtung
und erst wenn alle drei ok sind, wird das Rollo an der Terrassentür heruntergefahren, ansonsten wird der Auftrag um 10 Minuten verzögert erneut gestartet.
Aussperren gehört der Vergangenheit an.

[bgewehr]

Also für die Conditions kann man was vereinbaren, das ändert sich ja nicht sooo oft. Ein direktes Frontend ist dann ja vielleicht nicht nötig. Man könnte in SmartVISU die Zeiten konfigurieren und am fronthem Converter den String der Conditions als Parameter hinzufügen. Mal sehen.

Was die Sonne anbelangt, bin ich einen Schritt weiter gekommen.

Die SA+ Auswahl z. B. macht aus SA+ 00:30 ein {sunrise(1800)} als Zeit für die Regel. Zur Auswahl stehen --, SA+, SA-, SU+, SU-. Das könnte reichen, oder?



Gesendet von iPhone mit Tapatalk

[bgewehr]

Mal davon ab, der kundige Nutzer kann dies auch einfach genauso in das Time-Feld schreiben, würde auch funktionieren. Meint Ihr, dass das genügen würde?


Gesendet von iPhone mit Tapatalk

[ZeitlerW]

Hallo bgewehr,

das mit SA / SU paßt IMHO.


Conditions und der kundige Nutzer ...
naja grundsätzlich das ist erst mal kein Problem, es hilft mir schon erst mal die weekday-timers zu organisieren.
Spätere Erweiterungen sind ja dadurch nicht ausgeschlossen.

vG
Wolfgang

[RoBra81]

alle widgets funktionieren in der raum und in der detail ansicht. lassen sich per webCmd und readingGroup verwenden. die aktualisierung per longpoll funktioniert in allen drei einsatzbereichen.

Hallo,

ich wollte die widgets mal ausprobieren und bekomme es auch im Raum per webCmd und in der detail ansicht zum Laufen. Nun wollte ich eine ReadingsGroup bauen, aber das bekomme ich einfach nicht hin.

Mein Dummy (mit notify für die Readings):

Code Auswählen Erweitern

--------------------------------------------------------------------------------
define XX.xx.RA.Player.Helper dummy
attr XX.xx.RA.Player.Helper setList DG.sz.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player DG.wz.RA.Player_sync:uzsuSelect,DG.sz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player OG.ba.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,DG.sz.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player OG.ez.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,DG.sz.RA.Player,OG.ku.RA.Player OG.ku.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,DG.sz.RA.Player
attr XX.xx.RA.Player.Helper webCmd DG.wz.RA.Player_sync
define XX.xx.RA.Player.Helper.not notify XX.xx.RA.Player.Helper:.* setreading XX.xx.RA.Player.Helper $EVENT

Der Versuch einer ReadingsGroup:

Code Auswählen Erweitern

define XX.xx.RA.Player.Helper.RG readingsGroup XX.xx.RA.Player.Helper:OG.ez.RA.Player_sync\
XX.xx.RA.Player.Helper:DG.wz.RA.Player_sync\
XX.xx.RA.Player.Helper:DG.sz.RA.Player_sync,!test\

attr XX.xx.RA.Player.Helper.RG commands { 'test' => 'DG.sz.RA.Player_sync:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player'}

Was muss ich tun, um die Widgets in die ReadingsGroup zu bekommen?

Vielen Dank
Ronny

[justme1968]

wie bei setList: vor dem : muss der name des readings stehen. nicht der device name.

Code Auswählen Erweitern

attr XX.xx.RA.Player.Helper.RG commands { 'test' => 'test:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player'}

gruss
  andre

[RoBra81]

Das hatte ich auch schon erfolglos probiert. Ich habe es dann mit einem anderen Dummy hinbekommen in dem ich das state-reading verwendet habe. Ich bekomme es aber leider nicht für einen Dummy mit mehreren Readings wie in meinem Beispiel hin...

[justme1968]

das ist völlig unabhänig von der anzahl der readings.

Code Auswählen Erweitern

define dd dummy
attr dd room rg2
define rg2 readingsGroup dd:r1,r2
attr rg2 commands { r1 => 'r1:uzsuSelect,DG.wz.RA.Player,OG.ba.RA.Player,OG.ez.RA.Player,OG.ku.RA.Player', r2 => 'r2:uzsuSelect,a,b,c,d',  }
attr rg2 room rg2

wie sieht es bei dir im browser aus? ist im log etwas zu sehen?

gruss
  andre