Hallo,
Um mich etwas einzuarbeiten habe ich versucht in der visu.js der uzsu eine Condition mitzugeben.
--- visu.js 2015-02-21 12:00:12.948726807 +0100
+++ visu.js.patched 2015-02-21 12:04:04.000000000 +0100
@@ -255,10 +255,16 @@
var template = "";
// tabelle der zeileneinträge abschliessen
template += "<\/table>";
+ template += "<table style = 'border: 0'> <tr> <td> <form> <fieldset data-mini='true'> ";
+ // hier Bedingung für gesamte uzsu
+ template += //"<div data-role='controlgroup' data-type='horizontal' data-inline='true' >"+
+ "<tr><td><\/td><td> Bedingung<\/td><tr>"+
+ "<tr><td><\/td><td><input type='text' data-clear-btn='false' style = 'width:300px' id='uzsuCondition'"+
+ "<\/td><\/tr>";
// hier der activierungsbutton für die gesamte uzsu
- template += "<table style = 'border: 0'> <tr> <td> <form> <fieldset data-mini='true'> " +
- "<input type='checkbox' id='uzsuGeneralActive'> <label for='uzsuGeneralActive'>UZSU Activate<\/label>" +
- "<\/fieldset><\/form> <\/td>";
+ template += "<tr><td> <div data-role='controlgroup' data-type='horizontal' data-inline='true' >"+
+ "<input type='checkbox' id='uzsuGeneralActive'><label for='uzsuGeneralActive'>UZSU Activate<\/label><\/td>"+
+ "<\/fieldset><\/form><\/td>";
// jetzt kommen noch die buttons in der basisleiste mit rein
template += "<td> <div data-role='controlgroup' data-type='horizontal' data-inline='true' data-mini='true'>";
template += "<div data-role = 'button' id = 'uzsuAddTableRow'> Add Entry <\/div>";
@@ -294,7 +300,8 @@
var weekDays =['MO','TU','WE','TH','FR','SA','SU'];
// jetzt wird die tabelle befüllt
// allgemeiner Status, bitte nich mit attr, sondern mit prop, siehe https://github.com/jquery/jquery-mobile/issues/5587
- $('#uzsuGeneralActive').prop('checked',response.active).checkboxradio("refresh");
+ $('#uzsuGeneralActive').prop('checked',response.active).checkboxradio("refresh");
+ $('#uzsuCondition').val(response.condition.replace(/__/g,' '));
// auswahl format
switch(customFormat[0]){
case '0':
@@ -417,6 +424,7 @@
// bitte darauf achten, dass das zurückspielen exakt dem der anzeige enspricht.
// gesamthafte aktivierung
response.active = $('#uzsuGeneralActive').is(':checked');
+ response.condition = $('#uzsuCondition').val();
// dispatcher für format
switch(customFormat[0]){
case '0':
@@ -470,7 +478,9 @@
}
// über json interface / treiber herausschreiben
if(saveSmarthome){
- io.write(item, {active : response.active, list : response.list });
+ var fhemcondition = response.condition;
+ fhemcondition = fhemcondition.replace(/ /g,'__');
+ io.write(item, {active : response.active, condition : fhemcondition, list : response.list});
}
}
// steuerung des Popups
@@ -537,7 +547,7 @@
$(this).data('uzsu', response[0]);
}
else {
- $(this).data('uzsu', { active: true, list: [] });
+ $(this).data('uzsu', { active: true, list: [], condition: '' });
}
});
// als zweites der handler für die callbacks des click events
Die kommt auch in der UZSU_execute richtig an, wird dort aber nach dem ersten Leerzeichen, ohne die es in einer Bedingung ja nicht geht, abgeschnitten.
Meine Lösung mit dem Replacement von " " durch "__" scheint mir nicht nur suboptimal sondern sieht allzusehr nach Bastellösung aus, da in der UZSU_execute noch zurückgewandelt werden muss.
Wie macht man so etwas elegant? Den ganzen json-String in Anführungszeichen zu setzen ist mir leider nicht gelungen.
Gruß
Hans
Hallo, Hans,
an den Bedingungen denke ich auch schon einige Wochen herum.
Ich hätte aber gern pro Zeile die Möglichkeit, Bedingungen zu setzen. Dann aber muss man wieder pro Zeile einzelne WDT erzeugen, weil der ja nur eine Bedingung für alle UZSU-Zeilen kann. Ich hätte gern eine Möglichkeit, Feiertage und Ferientage mit einzubeziehen oder Türgriffsensoren usw.
Lass das bitte noch etwas reifen, wir müssen erst klären, ob das weiterhin mit dem smarthome.py-UZSU identisch erfolgen kann, oder ob wir forken müssen für fhem. Bisher haben wir versucht, das zu vermeiden...
Schau mal hier:
https://github.com/mworion/uzsu_widget/issues/13
Hallo Bernd,
Kein Thema :).
Mir ging es eigentlich auch nur darum, mich mal an js heranzuwagen. Bedingungen kann man ja auch in z.B. myUtils definieren.
Das git von mworion hatte ich vor einigen Tagen gesehen (und beschämt zu Boden geschaut: an Kompatibilität hatte ich nicht gedacht).
Bin gespannt, wie's weitergeht. Super Job, den du hier machst.
Gruß
Hans
Danke, das freut mich!
So, MWorion hat nun die V 3.99 responsive im GitHub.
Siehe ISSUE 13: https://github.com/mworion/uzsu_widget/issues/13
Wir müssen nun feststellen, welche Conditions wir genau brauchen.
Auf jeden Fall müsste die Funktion UZSU_Execute dann so angepasst werden, dass sie bei gegebenen Bedingungen pro Zeile der UZSU einen eigenen WDT erzeugt, weil der ja nur EINE Condition haben kann und nicht pro Profil eine...
Bitte sagt mir Eure Meinung, welche Ausprägungen die Conditions haben müssen, dann leite ich das an MWORION weiter.
Wollt Ihr einen einfachen Perl-String für die Condition oder lieber ein Device Comp Value - Tripel?
Danke und Gruß
Bernd
Ich würde einen Perl String vorziehen, da beim Triple eh nur der Komparator über die GUI auszuwählen wäre, Device und Value muss man sowieso eintippen.
Ich habe MWorion jetzt vorgeschlagen, es wie abgebildet zu machen.
Im FHEM Code kann dann unterschieden werden: wenn nur das erste Texfeld gefüllt ist, dann als Perl evaluieren, sonst Device comp value.
Gute Idee.
So, es ist soweit!
Mit dem aktuellen responsive_dev branch ist es MWORION gelungen, einen separaten Designtype 2 für fhem speziell mit einigen Features auszurüsten:
1. Die aktiven Variablen $we und !$we können nun an Stelle der Mo Di Mi Tagesreihe benutzt werden, um Schaltvorgänge auch von holidays und Feiertagen abhängig zu wählen. Sie werden im Designtype 2 immer zusätzlich angeboten.
2. In den expert-Einstellungen jeder Zeitreihe kann nun über eine Kombination aus fhemDevice, Vergleichsoperator und Wert oder aber über einen Perl String im Feld fhemDevice eine Bedingung formuliert werden, die dem WDT zugeordnet wird. Daraus folgt auch, dass nun wieder für jede Zeile (mit conditions) ein eigener WDT erstellt werden muss.
Nun ist die uzsu_execute in der 99_fronthem_utils.pm entsprechend anzupassen. Ich mach mich mal dran...
Um vom neuen Designtype Gebrauch zu machen, müsst Ihr in smartVISU den Designtype 2 mittels 2 im vierten Parameter ansteuern:
{{ visu.uzsu_icon(id~'UZSU', gad_uzsu, '', 2, '', '', 'bool', 'an:on,aus:off' ) }}
Das Ergebnis sieht dann so aus:
(https://forum.fhem.de/index.php?action=dlattach;topic=34140.0;attach=48526;image)
(siehe Bild-Anhang)
und liefert folgenden JSON pro Zeile:
{
"list": [{
"timeOffset": "5",
"rrule": "FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR",
"timeMin": "20:45",
"active": true,
"holiday": {
"weekend": false,
"work": false,
},
"sun": null,
"condition": {
"conditionActive": true,
"conditionType": "=",
"conditionValue": "Value",
"conditionDevicePerl": "FhemDevice"
},
"time": "20:45<sunrise+5m<21:45",
"timeMax": "21:45",
"event": "sunrise",
"timeCron": "",
"value": "0"
}],
"active": true
}
Ihr könnt Euch das git holen mit:
sudo git clone -b responsive_develop https://github.com/mworion/uzsu_widget.git UZSU_dev
@dev0 @herrmannj Einwände?
Zitat von: bgewehr am 16 März 2016, 22:35:36
Einwände?
In keinster Weise Einwände, im Gegenteil: ich finde es toll, dass und wie Du das Widget mit Michael weiterentwickelst!
Sag Bescheid, wenn ich Dich irgendwie unterstützen kann.
Eine Frage fällt mir ein: sollen wir grundsätzlich wieder einen WDT pro Zeile erstellen oder nur für diejenigen, die eine Condition haben? Das eine ist etwas einfacher als das Andere... Was meint Ihr?
Ich halte die WDT pro Zeile Variante für einfacher und durchschaubarer.
Dann fange ich mal so an. Bezeichnung: WDT_device-01_UZSU
Room UZSU
Group Device
ok?
Von mir aus: ja
Bitte testen:
https://github.com/bgewehr/fronthem-1/blob/patch-3/FHEM/99_fronthemUtils.pm
Der Perl-Zweig funktioniert noch nicht, ich habe Schwierigkeiten mit den Anführungszeichen, die werden escaped in fhem eingeliefert...
Wer steigt mit ein?
Ich werde mir im Laufe des Tages fronthem/smartvisu in der Entwicklungsumgebung installieren, dann kann ich mitreinschaun.
Es fehlt ein "} am Ende des JSON Strings, der an UZSU_execute($$) übergeben wird, sobald der Perl Zwei aktiv ist.
"condition":{"conditionActive":true,"conditionType":"Perl","conditionValue":"","conditionDevicePerl":"x
Wenn andere Conditions aktiv sind, dann sieht es so aus:
"condition":{"conditionType":"eq","conditionActive":true,"conditionValue":"0","conditionDevicePerl":"x"}
Edit: Es fehlt sogar mehr, wie man im direkten Vergleich sieht:
{"active":true,"list":[{"time":"10:40:30","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU","value":"off","timeMax":"","timeCron":"10:40:30","event":"time","condition":{"conditionActive":true,"conditionType":"eq","conditionValue":"0","conditionDevicePerl":"x"},"timeOffset":"","timeMin":"","holiday":{"weekend":false,"work":false},"active":true}]}
{"active":true,"list":[{"time":"10:40:30","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU","value":"off","timeMax":"","timeCron":"10:40:30","event":"time","condition":{"conditionActive":true,"conditionType":"Perl","conditionValue":"","conditionDevicePerl":"x
Kontaktierst Du Michael, wenn Du das so verifizieren kannst?
Was hast Du ins Device/Perl Feld geschrieben?
Damit hatte ich es probiert: (x ist ein existierendes Device)
x eq "1"
x == 1
ReadingsVal("x","state","") eq "1"
{ReadingsVal('x','state','') eq '1'}
{ReadingsVal("x","state","") eq "1"}
Was war der letzte Wert, der zu diesem Ergebnis geführt hatte?
Weiss nicht mehr genau. Wenn Du mir sagst welche Syntax richtig wäre, dann probiere ich es damit nochmal und zeige das Ergebnis.
x eq "1":
{"list":[{"event":"time","timeOffset":"","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU","value":"off","holiday":{"weekend":false,"work":false},"condition":{"conditionActive":true,"conditionDevicePerl":"x
x == 1
{"active":true,"list":[{"condition":{"conditionActive":true,"conditionDevicePerl":"x
{ReadingsVal('x','state','') eq '1'}
{"list":[{"timeOffset":"","event":"time","holiday":{"weekend":false,"work":false},"value":"off","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU","condition":{"conditionDevicePerl":"{ReadingsVal('x','state','')
ReadingsVal('x','state','') eq '1'
{"list":[{"value":"off","holiday":{"work":false,"weekend":false},"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU","timeOffset":"","event":"time","active":true,"time":"10:40:30","timeCron":"10:40:30","timeMin":"","timeMax":"","condition":{"conditionValue":"","conditionType":"Perl","conditionActive":true,"conditionDevicePerl":"ReadingsVal('x','state','')
Alle Versuche enden mit:
n_UZSU return value: unexpected end of string while parsing JSON string, at character offset XXX (before "(end of string)") at ./FHEM/99_fronthemUtils.pm line 37
99_fronthemUtils.pm line 37 ist bei mir -> $uzsu = decode_json($uzsu);
Edit: nach dem ersten Leerzeichen im Perl String ist schluss...
Edit2: wenn man den Perl String ohne Leerzeichen eingibt, dann wird die Condition richtig in den WDT eingetragen, wenn da nicht die Tüddelchen am Anfang und Ende des Strings wären. Ich glaube das war ursprünglich deine Frage. ;) Richtig?
Diese escapten "Tüddelchen" werden von USZU schon so geschickt... Könnte man simpel filtern, aber eigentlich gehören die ja erst gar nicht da hin. Auf die schnelle habe ich nichts im widget entdeckt, was das verursachen würde. Javascript ist aber auch nicht mein Ding.
Interessanterweise konnte ich es heute morgen nur noch einmal reproduzieren, dass der PerlString in Tüddelchen eingefasst in UZSU_execute ankommt, seitdem nicht mehr, egal was ich eingebe. Diese Tüddelchen konnte ich auch in der Brownserkonsole mit console.log() sehen...
Davon abgesehen vermute ich mittlerweile, dass das Abschneiden des JSON Strings in Fronthem oder Fhem-Driver passiert, habe aber noch nicht angefangen das Logging von Fronthem aufzuboren. Wahrscheinlich komme ich auch heute nicht dazu.
/Uli
Edit:
Die Abgeschnittenen JSON Strings entstehen bei mir durch das UZSU Notify, dass in $EVTPART1 den abgeschnittenen String enthält.
Wenn ich den Umweg über das Notify nicht gehe, sondern direkt im UZSU Converter die USZU_execute() aufrufe, dann ist alles schön :)
sub UZSU(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = main::fronthem_decodejson(main::ReadingsVal($device, $reading, ''));
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
$gadval = main::fronthem_encodejson($gadval);
main::UZSU_execute($device,$gadval);
$gadval =~ s/;/;;/ig;
$param->{result} = main::fhem("setreading $device $reading $gadval");
$param->{results} = [];
return 'done';
}
elsif ($param->{cmd} eq '?')
{
return 'usage: UZSU';
}
return undef;
}
Auch eine gute Idee!!!
Wie ist es beim zweiten Aufruf der UZSU in SV? Ist dann der Perl String abgeschnitten?
Ich konnte keine abgeschnittenen Perl Strings mehr feststellen, aber teste bitte selbst noch einmal.
Ich habe die UZSU Funktionen bei mir in eine eigene Datei ausgelagert. Das hat den Vorteil, dass man die Datei bei einem neuen Release einfach austauschen kann. Weiterhin habe ich das Logging, das Löschen und Anlegen der WDTs ein wenig angepasst. Wenn Du magst, dann kannst gerne das übernehmen, was Du für sinnvoll erachtest.
ToDo:
Wenn im Widget kein Wochentag angeklickert ist und man we oder !we benutzt, dann gibt es noch Warnungen. Die Zeilen beziehen sich auf die angehängte Datei.
we:
2016.03.19 09:48:15.026 1: PERL WARNING: substr outside of string at ./FHEM/99_fronthemUZSU.pm line 47.
2016.03.19 09:48:15.027 1: PERL WARNING: Use of uninitialized value $weekdays in string ne at ./FHEM/99_fronthemUZSU.pm line 51.
!we:
2016.03.19 09:51:55.197 1: PERL WARNING: substr outside of string at ./FHEM/99_fronthemUZSU.pm line 47.
2016.03.19 09:51:55.198 1: PERL WARNING: Use of uninitialized value $weekdays in string ne at ./FHEM/99_fronthemUZSU.pm line 57.
Einen hab ich noch...
Wenn man im UZSU Converter in der ReadingsVal Fn den Defaultwert auf {} setzt, dann muss man kein uzsu Reading mehr manuell anlegen. Und mein perfektionistisches ich würde das Reading sogar noch beim Löschen des WDts mit entfernen ;)
/Uli
Sehr gut! Das schau ich mir an!
Also, sehr gutes Ergebnis:
1. default {} erspart setreading... das ist wirklich einfach und gut!
2. UZSU_execute im converter aufzurufen ist ebenfalls sehr praktisch und erspart dem JSON den Umweg über das Reading, was offensichtlich besser funktioniert
Eines gefällt mir noch gar nicht!
Ich bekomme es einfach nicht mit, wenn mein perl string falsch war. Er wird dann einfach nicht umgesetzt, es entsteht irgenein WDT und ich denke, alles ist in Ordnung.
Können wir nicht ein
try...
except
setze den perl-script-value auf 'error in perl string: "ursprünglicher perl string"' setzen? Oder einen smartVISU Error oben rechts in der Ecke?
Was meint Ihr?
Die simpelste Variante, die mir dazu einfällt und kein zusätzliches Perl Modul benötigt:
eval $uzsu->{list}[$i]->{condition}->{conditionDevicePerl};
DoTrigger($device, "ERROR PERLCONDITION", 1) if $@;
...
Auf das Event könnte man dann mit einem status.notify regieren.
Ich klinke mich hier auch mal ein :)
ZitatEine Frage fällt mir ein: sollen wir grundsätzlich wieder einen WDT pro Zeile erstellen oder nur für diejenigen, die eine Condition haben? Das eine ist etwas einfacher als das Andere... Was meint Ihr?
ZitatIch halte die WDT pro Zeile Variante für einfacher und durchschaubarer.
Ein WDT pro Zeile mag einfacher sein, aber bläht es die Anzahl der WDT nicht unnötig auf?
Für eine UZSU mit 6 Zeilen benötige ich heute (ohne condition) 1 WDT, in Zukunft wären das aber 6. Da kommen schnell einige Dutzend WDT zusammen.
Mein Vorschlag wäre folgender: Nur wenn in mindestens einer UZSU Zeile eine Condition vorhanden ist, wird ein WDT pro Zeile erstellt, ansonsten 1 WDT für alle Zeilen
Dürfte mit ein paar zusätzlichen Zeilen in der fronthemUZSU_execute() umsetzbar sein, kann mich ja mal dransetzen.
Gern. Hier ist mein aktueller Stand:
https://github.com/bgewehr/fronthem-1/blob/patch-3/FHEM/99_fronthemUtils.pm
Vorschläge sind herzlich willkommen!
Ich habe grade noch folgendes im log gesehen, worauf wir achten müssen:
2016.03.21 18:40:31 4: [wdt_uzsu_Roll_EG_0] (ReadingsVal("device1","state","") > "100") - NOT accepted, must be command or condition
Was will er denn?
Hier mal auf die Schnelle noch ein Vorschlag für eine modifizierte Version der UZSU_execute, ungetestet und ohne Gewähr ;)
Für jede Zeile mit Condition wird ein seperater WDT erstellt, alle Zeilen ohne Condition werden in einem gemeinsamen WDT zusammengefasst.
Zumindest ist das der Plan :) , bin mir aber hiermit $weekdays_all = $weekdays_all.' '.$weekdays; nicht so ganz sicher.
###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
my ($device, $uzsu) = @_;
my $weekdays = "";
my $weekdays_all = ""; ## added by muk.s
my $condition_exist = 0; ## added by muk.s
my $perlString = "";
$uzsu = decode_json($uzsu);
fhem('delete wdt_uzsu_'.$device.'.*');
for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
$condition_exist = 0; ## added by muk.s
$weekdays = $uzsu->{list}[$i]->{rrule};
$weekdays = substr($weekdays,18,50);
# if the structure contains the holidays list, use it!
if ($uzsu->{list}[$i]->{holiday}->{weekend}) {
if ($weekdays ne '') {
$weekdays = $weekdays . ',';
}
$weekdays = $weekdays . '$we';
}
if ($uzsu->{list}[$i]->{holiday}->{work}) {
if ($weekdays ne '') {
$weekdays = $weekdays . ',';
}
$weekdays = $weekdays . '!$we';
}
if ($uzsu->{list}[$i]->{event} eq 'time'){
$weekdays = $weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value};
} else {
# Bugfix below: because sunset_abs from 99_sunrise_el does not work if max-time = ""
if ($uzsu->{list}[$i]->{timeMin} ne '' and $uzsu->{list}[$i]->{timeMax} ne '') {
$weekdays = $weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',"'.$uzsu->{list}[$i]->{timeMin}.'","'.$uzsu->{list}[$i]->{timeMax}.'")}|'.$uzsu->{list}[$i]->{value};
} else {
$weekdays = $weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',,)}|'.$uzsu->{list}[$i]->{value};
}
}
# if the structure contains a condition, use it!
if ($uzsu->{list}[$i]->{condition}->{conditionActive}) {
$condition_exist = 1; ## added by muk.s
if ($uzsu->{list}[$i]->{condition}->{conditionType} eq 'Perl') {
Log 4, 'uzsu Perl-Condition\n';
$perlString = $uzsu->{list}[$i]->{condition}->{conditionDevicePerl};
Log 4, 'uzsu ' . $perlString;
#$perlString =~ s/\\"/"/ig;
#Log 4, 'uzsu ' . $perlString;
$weekdays = $weekdays.' ('.$perlString.')';
Log 4, 'uzsu ' , $weekdays;
} else {
Log 4, 'uzsu non-Perl-Condition\n';
$weekdays = $weekdays.' (ReadingsVal("'.$uzsu->{list}[$i]->{condition}->{conditionDevicePerl}.'","state","") '.$uzsu->{list}[$i]->{condition}->{conditionType}.' "'.$uzsu->{list}[$i]->{condition}->{conditionValue}.'")';
}
} else {
# if the uzsu row has no condition, add row to $weekdays_all
$weekdays_all = $weekdays_all.' '.$weekdays; ## added by muk.s
}
# create single WDT with condition
if ($uzsu->{list}[$i]->{active} && $condition_exist != 0){
fhem('defmod wdt_uzsu_'.$device.'_'.$i.' WeekdayTimer '.$device.' en '.$weekdays);
fhem('attr wdt_uzsu_'.$device.'_'.$i.' room UZSU');
fhem('attr wdt_uzsu_'.$device.'_'.$i.' group '.$device);
}
## moved by muk.s to end of sub
}
# create combined WDT for all non-condition rows - added by muk.s
if ($weekdays_all ne '') {
fhem('defmod wdt_uzsu_'.$device.' WeekdayTimer '.$device.' en '.$weekdays);
fhem('attr wdt_uzsu_'.$device.' room UZSU');
fhem('attr wdt_uzsu_'.$device.' group '.$device);
}
#fhem('save'); # use only if you want to save WDT settings immediately.
}
package fronthem;
use strict;
use warnings;
Also nach etwas überlegen frage ich mich, ob das den Aufwand wert ist. Die WDT werden im Raum UZSU nach devices gruppiert und wenn es 100 sind, ist das eigentlich nicht schlimm, da sie keine Last oder sonstige Nachteile erzeugen, oder?
Ich habe als nächstes vor, die DelayedExecutionCondition anzugehen, dann passt die Filterung nach nur Condition schon wieder nicht und es wird noch komplizierter, die Fälle zu unterscheiden. Lohnt das wirklich?
Ob es sich lohnt bzw gelohnt hätte, wird sich spätestens in der Praxis zeigen :)
Vielleicht sollte man das ganze auch von einer anderen Seite angehen und das WeekdayTimer Modul entsprechend anpassen, aber das wäre ein anderer Thread.
Was hältst Du davon: ich mache erst mal die DelayedExecutionCondition und danach optimieren wir auf möglichst wenige WDT?
Hört sich gut an.
Hier der issue:
https://github.com/mworion/uzsu_widget/issues/32
Sollte eigentlich nicht so aufwendig sein.
Die DelayedExecutionCondition ist ja nur simpler True/False Flag. Im Grunde würde ein zusätzliches Feld in der UZSU widget reichen in den man einen Perl string eingibt der True bzw 1 zurückgibt und diesen als DelayedExecutionCondition attribute speichert. Wenn man das Feld, analog zu den conditions, in jeder Zeile zur Verfügung hätte, würde das die größtmögliche Flexibilität bieten. Zu überlegen wäre, ob man den String in der UZSU_execute eventuell noch nach Syntaxfehler abklopft.
Gerade mal getestet:
{(Value("Fenster_Bad") eq "auf" )}
funktioniert bestens.
Edit: Gerade gesehen, mworion hat die DelayedExecutionCondition schon im widget umgesetzt
So, hier mal eine auf das uzsu_widget V4.4 angepasste UZSU_execute.
Getestet mit SmartVisu 2.8 - funktioniert soweit.
Ich habe noch eine kleine Änderung bei der conditions auswertung eingebaut. Damit sind auch solche conditions möglich:
{ fhem("set DEVICE_X $EVENT") if( Value("device") eq "on" ) }
Schöne Ostern
###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
# for use with UZSUwidget V4.4
#
###############################################################################
sub UZSU_execute($@)
{
my ($device, $uzsu) = @_;
my $weekdays = "";
my $delayedExec ="";
my $perlString = "";
$uzsu = decode_json($uzsu);
fhem('delete wdt_uzsu_'.$device.'.*');
for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
$weekdays = $uzsu->{list}[$i]->{rrule};
$weekdays = substr($weekdays,18,50);
$delayedExec = "";
# if the structure contains the holidays list, use it!
if ($uzsu->{list}[$i]->{holiday}->{weekend}) {
if ($weekdays ne '') {
$weekdays = $weekdays . ',';
}
$weekdays = $weekdays . '$we';
}
if ($uzsu->{list}[$i]->{holiday}->{work}) {
if ($weekdays ne '') {
$weekdays = $weekdays . ',';
}
$weekdays = $weekdays . '!$we';
}
if ($uzsu->{list}[$i]->{event} eq 'time'){
$weekdays = $weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value};
} else {
# Bugfix below: because sunset_abs from 99_sunrise_el does not work if max-time = ""
if ($uzsu->{list}[$i]->{timeMin} ne '' and $uzsu->{list}[$i]->{timeMax} ne '') {
$weekdays = $weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',"'.$uzsu->{list}[$i]->{timeMin}.'","'.$uzsu->{list}[$i]->{timeMax}.'")}|'.$uzsu->{list}[$i]->{value};
} else {
$weekdays = $weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',,)}|'.$uzsu->{list}[$i]->{value};
}
}
# if the structure contains a condition, use it!
if ($uzsu->{list}[$i]->{condition}->{active}) {
if ($uzsu->{list}[$i]->{condition}->{type} eq 'Perl') {
Log 4, 'uzsu Perl-Condition\n';
$perlString = $uzsu->{list}[$i]->{condition}->{devicePerl};
Log 4, 'uzsu ' . $perlString;
#$perlString =~ s/\\"/"/ig;
#Log 4, 'uzsu ' . $perlString;
if (substr($perlString,0,1) eq "{") {
$weekdays = $weekdays.' '.$perlString;
} else {
$weekdays = $weekdays.' ('.$perlString.')';
}
Log 4, 'uzsu ' . $weekdays;
} else {
Log 4, 'uzsu non-Perl-Condition\n';
$weekdays = $weekdays.' (ReadingsVal("'.$uzsu->{list}[$i]->{condition}->{devicePerl}.'","state","") '.$uzsu->{list}[$i]->{condition}->{type}.' "'.$uzsu->{list}[$i]->{condition}->{value}.'")';
}
}
# if the structure contains a delayedExec, use it!
if ($uzsu->{list}[$i]->{delayedExec}->{active}) {
if ($uzsu->{list}[$i]->{delayedExec}->{type} eq 'Perl') {
Log 4, 'uzsu Perl-Condition\n';
$perlString = $uzsu->{list}[$i]->{delayedExec}->{devicePerl};
Log 4, 'uzsu ' . $perlString;
#$perlString =~ s/\\"/"/ig;
#Log 4, 'uzsu ' . $perlString;
$delayedExec = $perlString;
#Log 4, 'uzsu ' , $weekdays;
} else {
Log 4, 'uzsu non-Perl-Condition\n';
$delayedExec = '{ (ReadingsVal("'.$uzsu->{list}[$i]->{delayedExec}->{devicePerl}.'","state","") '.$uzsu->{list}[$i]->{delayedExec}->{type}.' "'.$uzsu->{list}[$i]->{delayedExec}->{value}.'") }';
}
}
if ($uzsu->{list}[$i]->{active}){
fhem('defmod wdt_uzsu_'.$device.'_'.$i.' WeekdayTimer '.$device.' en '.$weekdays);
fhem('attr wdt_uzsu_'.$device.'_'.$i.' room UZSU');
fhem('attr wdt_uzsu_'.$device.'_'.$i.' group '.$device);
if ($delayedExec) {
fhem('attr wdt_uzsu_'.$device.'_'.$i.' delayedExecutionCond '.$delayedExec);
}
}
#fhem('save'); # use only if you want to save WDT settings immediately.
}
}
package fronthem;
use strict;
use warnings;
Sehr gut, klasse! Ich bin noch dafür, auf die Eingabe der {} zu verzichten, weil es die Condition auch nicht will. Dann besser beide perl strings ohne {} und die Funktion fügt das hinzu, wenn nötig. Was meinst Du?
Zitat...
Ich bin noch dafür, auf die Eingabe der {} zu verzichten, weil es die Condition auch nicht will. Dann besser beide perl strings ohne {} und die Funktion fügt das hinzu, wenn nötig.
...
Eigentlich braucht man die {} ja nur wenn die condition einen fhem Befehl enthält.
Könnte man so lösen:
if (substr(trim($perlString),0,4) eq "fhem") {
$weekdays = $weekdays.' {'.$perlString.'}';
} else {
$weekdays = $weekdays.' ('.$perlString.')';
}
Der delayedExecCondition sollte es eigentlich nicht schaden grundsätzlich in {} gekabselt zu werden.
Was meinst Du?
Irgendwo steckt noch ein clitch drin >:(
chk.uzsu return value: unexpected end of string while parsing JSON string, at character offset 1338 (before "(end of string)") at ./FHEM/99_fronthemUtils.pm line 37
Ich schaue mir den Code an und probier mal, ob ich den Fehler finde.
Ich hätte es gern so, dass der Benutzer in beiden Fällen die Eingaben identisch vornehmen kann, auch für den Perl-String. Deswegen möchte ich die {} durch die Funktion bei der delayedcondition hinzufügen lassen, wenn erforderlich und nicht durch den Benutzer.
Bei der Condition braucht man ja keine {}, weil der WDT Code schon ein eval() ausführt.
Habe noch ein wenig am code geschraubt.
Als perl string bei der condition und der delayedExecCond ist nun folgende Eingabe möglich:
ReadingsVal("device2check","state","") eq "off"
oder dies hier
fhem("set DEVICE_X $EVENT") if( Value("device2check") eq "on" ) (damit kann ich einen dummy als wdt device nutzen und ein anderes device - oder auch mehrere - schalten ohne den Umweg über ein notify zu gehen)
wers mag, kann den perlString aber auch zwischen { }, ( ), oder auch {( )} packen.
Wird im code abgefangen.
Mit den einzelnen WDT's pro Zeile kann ich mich wohl doch anfreunden :) . Damit ich aber auch im FHEMWEB Frontend einen Überblick der einzelnen WDT Defs habe, wird im Raum UZSU für jedes device noch eine readingsgroup erstellt.
Ich habe den code auch noch dahingehend angepasst, das die condition in einer seperaten Variablen mitgeführt wird.
Hier mal meine letzte Version:
###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
# for use with UZSU widget V4.4
#
###############################################################################
sub UZSU_execute($@)
{
my ($device, $uzsu) = @_;
my $weekdays = "";
my $condition = "";
my $delayedExec ="";
my $perlString = "";
$uzsu = decode_json($uzsu);
fhem('delete wdt_uzsu_'.$device.'.*');
for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
$weekdays = $uzsu->{list}[$i]->{rrule};
$weekdays = substr($weekdays,18,50);
$delayedExec = "";
$condition = "";
# if the structure contains the holidays list, use it!
if ($uzsu->{list}[$i]->{holiday}->{weekend}) {
if ($weekdays ne '') {
$weekdays = $weekdays . ',';
}
$weekdays = $weekdays . '$we';
}
if ($uzsu->{list}[$i]->{holiday}->{work}) {
if ($weekdays ne '') {
$weekdays = $weekdays . ',';
}
$weekdays = $weekdays . '!$we';
}
if ($uzsu->{list}[$i]->{event} eq 'time'){
$weekdays = $weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value};
} else {
# Bugfix below: because sunset_abs from 99_sunrise_el does not work if max-time = ""
if ($uzsu->{list}[$i]->{timeMin} ne '' and $uzsu->{list}[$i]->{timeMax} ne '') {
$weekdays = $weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',"'.$uzsu->{list}[$i]->{timeMin}.'","'.$uzsu->{list}[$i]->{timeMax}.'")}|'.$uzsu->{list}[$i]->{value};
} else {
$weekdays = $weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',,)}|'.$uzsu->{list}[$i]->{value};
}
}
# if the structure contains a condition, use it!
if ($uzsu->{list}[$i]->{condition}->{active}) {
if ($uzsu->{list}[$i]->{condition}->{type} eq 'Perl') {
Log 4, 'uzsu Perl-Condition\n';
$perlString = trim($uzsu->{list}[$i]->{condition}->{devicePerl});
Log 4, 'uzsu ' . $perlString;
#$perlString =~ s/\\"/"/ig;
#Log 4, 'uzsu ' . $perlString;
# remove leading '{' and trailing '}'
if (substr($perlString,0,1) eq "{" && substr($perlString,length($perlString)-1,1) eq "}") {
$perlString = trim(substr($perlString,1,length($perlString)-2));
}
# remove leading '(' and trailing ')'
if (substr($perlString,0,1) eq "(" && substr($perlString,length($perlString)-1,1) eq ")") {
$perlString = trim(substr($perlString,1,length($perlString)-2));
}
if (substr($perlString,0,4) eq "fhem") {
$condition = ' {'.$perlString.'}';
} else {
$condition = ' ('.$perlString.')';
}
Log 4, 'uzsu '.$weekdays.' '.$condition;
} else {
Log 4, 'uzsu non-Perl-Condition\n';
$condition = ' (ReadingsVal("'.$uzsu->{list}[$i]->{condition}->{devicePerl}.'","state","") '.$uzsu->{list}[$i]->{condition}->{type}.' "'.$uzsu->{list}[$i]->{condition}->{value}.'")';
}
}
# if the structure contains a delayedExec, use it!
if ($uzsu->{list}[$i]->{delayedExec}->{active}) {
if ($uzsu->{list}[$i]->{delayedExec}->{type} eq 'Perl') {
Log 4, 'uzsu Perl-Condition\n';
$perlString = trim($uzsu->{list}[$i]->{delayedExec}->{devicePerl});
Log 4, 'uzsu ' . $perlString;
#$perlString =~ s/\\"/"/ig;
#Log 4, 'uzsu ' . $perlString;
# remove leading '{' and trailing '}'
if (substr($perlString,0,1) eq "{" && substr($perlString,length($perlString)-1,1) eq "}") {
$perlString = trim(substr($perlString,1,length($perlString)-2));
}
# remove leading '(' and trailing ')'
if (substr($perlString,0,1) eq "(" && substr($perlString,length($perlString)-1,1) eq ")") {
$perlString = trim(substr($perlString,1,length($perlString)-2));
}
$delayedExec = '{ ('.$perlString.') }';
#Log 4, 'uzsu ' , $delayedExec;
} else {
Log 4, 'uzsu non-Perl-Condition\n';
$delayedExec = '{ (ReadingsVal("'.$uzsu->{list}[$i]->{delayedExec}->{devicePerl}.'","state","") '.$uzsu->{list}[$i]->{delayedExec}->{type}.' "'.$uzsu->{list}[$i]->{delayedExec}->{value}.'") }';
}
}
if ($uzsu->{list}[$i]->{active}){
fhem('defmod wdt_uzsu_'.$device.'_'.$i.' WeekdayTimer '.$device.' en '.trim($weekdays.$condition));
fhem('attr wdt_uzsu_'.$device.'_'.$i.' room UZSU');
fhem('attr wdt_uzsu_'.$device.'_'.$i.' group '.$device);
fhem('setreading wdt_uzsu_'.$device.'_'.$i.' weekdays '.trim($weekdays) );
fhem('defmod rg_uzsu_'.$device.' readingsgroup wdt_uzsu_'.$device.'.*');
fhem('attr rg_uzsu_'.$device.' room UZSU');
if ($delayedExec) {
fhem('attr wdt_uzsu_'.$device.'_'.$i.' delayedExecutionCond '.$delayedExec);
}
}
#fhem('save'); # use only if you want to save WDT settings immediately.
}
}
package fronthem;
use strict;
use warnings;
Das sieht ja Klasse aus, das brauch ich auch.
Musste ich gleich ausprobieren und habe mir die v2.5 des UZSU Widgets https://github.com/mworion/uzsu_widget (https://github.com/mworion/uzsu_widget) und die letzte Version von Bernds fronthemUtils.pm https://github.com/bgewehr/fronthem-1/tree/patch-3/FHEM (https://github.com/bgewehr/fronthem-1/tree/patch-3/FHEM) eingebaut und ein paar neue UZSU definiert.
Im Weekdaytimer tauchen aber noch keine $we oder $!we auf, der kennt immer noch nur So-Sa - fehlt mir noch was?
Viele Grüße
thorschtn
Nimm den Code hier aus dem Thread, der passt zur 4.5! Mein fork ist noch von vorher, passe ich die Tage erst an...
Danke für die schnelle Antwort. hab aber bereits den Code von Muk.s eingebaut und keid $we im WDT!?
Dafür aber lauter Fehlermeldungen im Log:
2016.03.26 23:13:06 2: Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- HERE / at (eval 510) line 1.
Was steht im global Device unter holiday2we?
holiday2we Brandenburg
und Brandenburg sagt
NAME Brandenburg
NR 78
STATE Osterferien
TRIGGERTIME 1459033202.41422
TYPE holiday
Das ist OK. Was steht im UZSU Reading des zu schaltenden Devices?
Blöde Frage thorschtn, aber du hast das uzsu widget mit design type 2 definiert?
Sehr gute Frage!
Ja, Typ 2 ist eingestellt:
{{ uzsu.uzsu_icon('Rolladen.Alle', 'Rolladen.Alle.uzsu', 'Rolläden - alle (aktuell:nur unten)', '2', '', '', 'list', ['hoch:on', 'runter:off']) }}
Nachtrag: Der im Screenshot noch nicht aktive letzte Eintrag tauch auch nach Aktivierung nicht im WDT auf.
Nochmal:
Zitat von: bgewehr am 26 März 2016, 23:21:55
Was steht im UZSU Reading des zu schaltenden Devices?
{"active":true,"list":[{"delayedExec":{"devicePerl":"","type":"Perl","value":"","active":false},"holiday":{"weekend":false,"work":true},"condition":{"active":false,"value":"","type":"Perl","devicePerl":""},"timeMax":"","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","timeOffset":"","time":"06:45","timeCron":"06:45","value":"on","active":true,"timeMin":"","event":"time"},{"timeCron":"sunset","value":"off","event":"sunset","active":true,"timeMin":"18:30","delayedExec":{"active":false,"type":"Perl","devicePerl":"","value":""},"condition":{"value":"","type":"Perl","devicePerl":"","active":false},"holiday":{"work":false,"weekend":false},"time":"18:30<sunset+60m<21:00","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU","timeOffset":"60","timeMax":"21:00"},{"timeCron":"09:10","value":"on","active":true,"timeMin":"","event":"time","condition":{"value":"","type":"Perl","devicePerl":"","active":false},"holiday":{"weekend":true,"work":false},"delayedExec":{"active":false,"devicePerl":"","type":"Perl","value":""},"timeMax":"","time":"09:10","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU","timeOffset":"60"},{"event":"time","active":true,"timeMin":"","value":"on","timeCron":"08:55","time":"08:55","rrule":"","timeOffset":"60","timeMax":"","holiday":{"weekend":false,"work":true},"condition":{"value":"","type":"Perl","devicePerl":"","active":false},"delayedExec":{"active":false,"value":"","type":"Perl","devicePerl":""}}]}
Du schaust den falschen WDT an. Den kannst Du löschen. Im Raum UZSU sind die neuen...
Da steht nur das, was ich als Screenshot angefügt hatte...!?
Fhem neu gestartet oder reload 99_fronthemUtils.pm gemacht?
Sonst nutzt Du noch den alten Code...
Hatte ich. Auch jetzt nochmal - keine Änderung.
Aber alter Code!?
Ich habe Deine https://github.com/bgewehr/fronthem-1/tree/patch-3/FHEM/99_fronthemUtils.pm (https://github.com/bgewehr/fronthem-1/tree/patch-3/FHEM/99_fronthemUtils.pm) und dorthinein die Subroutine sub UZSU_execute($@) von Muk.s aus Antwort #46
Ich nehme alles zurück. Hab mal alles rausgeschmissen und alles neu aufgesetzt - Euren Code, meine Devices und meine uzsu's. Und siehe da, jetzt funktionierts.
Entschuldigt meine unwissenden Fragen... Ich werde mal versuchen, in meinen Sicherheitskopien zu eruieren, wo der Fehler lag....
Habt vielen Dank für Eure Geduld und auch für Eure Arbeit an FHEM und Fronthem....
Schöne Feiertage
thorschtn
Ich habe meinen fork angepasst.
Ist jetzt auf dem aktuellen Stand.
Zitat von: thorschtn am 26 März 2016, 23:51:26
Aber alter Code!?
Ich habe Deine https://github.com/bgewehr/fronthem-1/tree/patch-3/FHEM/99_fronthemUtils.pm (https://github.com/bgewehr/fronthem-1/tree/patch-3/FHEM/99_fronthemUtils.pm) und dorthinein die Subroutine sub UZSU_execute($@) von Muk.s aus Antwort #46
UZSU auf dev 4.6.
VORSICHT: neue Bezeichner im JSON! "Perl" -> "String" wegen der Kompatibilität mit smarthome.py (Python).
Mein 99_fronthemUtils.pm fork ist angepasst.
Bei der 4.6 werden die fest definierten Zeiten immer auf 00:00 gesetzt.
Def. über Sunrise/Sunset funktioniert
Ich mache einen Issue auf...
OK, Danke.
Als Workaround einfach über Sunrise/Sunset bei "earliest" und "latest" die gleiche Uhrzeit eingeben.
ist in 4.7 gefixt.
In 4.8 passt die Optik wieder besser.(http://uploads.tapatalk-cdn.com/20160328/43887e7cef3bf48a83f25ae12cc8c85a.jpg)(http://uploads.tapatalk-cdn.com/20160328/0dc5d951a38435d47e9d80f80ca0e388.jpg)
Zitat von: bgewehr am 28 März 2016, 23:00:49
In 4.8 passt die Optik wieder besser
Benutzt Du noch IOS 8.x oder hast Du die IOS 9 Popup Problematik still und heimlich gelöst?
Nein, ist nicht gelöst, wirkt sich auch nervig aus.
Das Popup geht aber ganz normal auf. Nur die abgeschnittene Seite nervt!
Mmn hängt das Problem mit der alten jqm Version zusammen, ich hatte mir das ansatzweise angesehen als IOS9 erschienen war. Damals hatte ich noch die Hoffnung, dass der Autor das fixen wird. Es sind einige Anpassungen an sv nötig, damit neuere Version funktinieren. Zur Zeit sieht es für mich aber so aus, dass die smartvisu Entwicklung eingestellt ist/wird (https://knx-user-forum.de/forum/supportforen/smartvisu/891980-umstellung-auf-2-8?p=927733#post927733).
Es ist Open Source. Wir sind die Autoren...
Zitat von: bgewehr am 11 April 2016, 07:49:51
Es ist Open Source. Wir sind die Autoren...
Yep. Mit "Entwicklung eingestellt" meinte ich auch die Releases von Apollo.
Ein kleiner Hinweis am Rande,
im 99_fronthemUtils.pm fork von bgewehr https://github.com/bgewehr/fronthem-1/tree/patch-3/FHEM/99_fronthemUtils.pm (https://github.com/bgewehr/fronthem-1/tree/patch-3/FHEM/99_fronthemUtils.pm) ist noch ein kleiner bug enthalten.
MWORION hat mit dem uzsu widget 4.8 die Bezeichnung für !WE von "work" auf "workday" geändert.
Die entsprechende Zeile (54) in der 99_fronthemUtils.pm muß wie folgt geändert werden:
if ($uzsu->{list}[$i]->{holiday}->{workday}) {
Aber Achtung: Dies gilt nur für das uzsu widget ab Version 4.8
Oh, ja, vergessen. Machst Du einen PR?
Merged!
Release v5.0 des UZSU widget verfügbar
https://github.com/mworion/uzsu_widget (https://github.com/mworion/uzsu_widget)
@Bernd: Spricht etwas dagegen, dass Du die Änderungen und das UZSU 5.0 Widget ins herrmannj/smartvisu-widgets repository eincheckst? Das könnte es Anfängern (https://forum.fhem.de/index.php/topic,52814.0.html) etwas einfacher machen die aktuelle Version zu installieren.
Zitat von: dev0 am 19 März 2016, 10:09:41
Ich habe die UZSU Funktionen bei mir in eine eigene Datei ausgelagert. Das hat den Vorteil, dass man die Datei bei einem neuen Release einfach austauschen kann.
Wäre es nicht sinnvoll, dass auch im Repository so zu machen? Dann müsste man allerdings gleichzeitig die UZSU-Teile aus der 99_fronthemUtils.pm entfernen und das FHEM-Wiki anpassen (ggf. sogar nur auf das angepasste Github-readme.md verlinken). Die Doku muss ja eh angepasst werden, da das bisher nötige Notify gelöscht werden muss.
Was meinst Du?
/Uli
Da habe ich nichts dagegen.
Mir macht im Moment eine andere Sache mehr Sorgen: Wenn man die Funktionen der UZSU intensiv nutzt, fällt irgendwann auf, dass bei Verwendung von Anführungszeichen im Perl-Bedingungsstring fhem den UZSU String mit dem aktuellen Code nicht mehr speichern kann und der String abgeschnitten wird.
Daher war ich erst mal auf Fehlersuche eingestellt, weniger auf einchecken. Dann kommt der Faktor Zeit usw.
Ich könnte hier Hilfe gebrauchen.
Checke mal meinen letzten Stand in meinen Fork ein, dann können wir zusammen den Fehler suchen...
Update:
Erledigt
Konntest Du das Problem aufspüren? Auf Github habe ich keine Änderungen entdeckt.
Nein, sorry, ich meinte das Einchecken in den Fork ist erledigt. Zur Fehlersuche komme ich grad kaum.
In der UZSU_execute wird die "uzsuGeneralActive" checkbox nicht verarbeitet. Hab mal einen PR gemacht.
Hallo,
ich habe ein neues Thema zu diesem hier gestartet https://forum.fhem.de/index.php/topic,102229.msg957712.html#msg957712
Könnte mir da vielleicht jemand helfen?
Danke im voraus
Johann
Hi
ich benutze SmartVisu V3.1 und weiss nicht welchen UZSU widget.
Mein Problem ist dass beim einfügen einer condition ZBsp: ReadingsVal(<device>,<reading>,<default>) eq "off" immer folgender Fehler erscheint:
2022.03.04 22:04:38 1: ERROR evaluating my $EVENT= $evalSpecials->{'%EVENT'};my $EVTPART0= $evalSpecials->{'%EVTPART0'};my $EVTPART1= $evalSpecials->{'%EVTPART1'};my $EVTPART2= $evalSpecials->{'%EVTPART2'};my $EVTPART3= $evalSpecials->{'%EVTPART3'};my $NAME= $evalSpecials->{'%NAME'};my $SELF= $evalSpecials->{'%SELF'};my $TYPE= $evalSpecials->{'%TYPE'};{
UZSU_execute($NAME, $EVTPART1,"save");
}: unexpected end of string while parsing JSON string, at character offset 788 (before "(end of string)") at ./FHEM/99_fronthemUtils.pm line 228.
Kann mir da jemand weiterhelfen?
Danke Andreas
Für das o.g. Problem gibt es folgende Log-Ausgaben für die Condition {(Readingsval("device2check","state","") eq "off"})
022.03.04 22:29:39 1: ERROR evaluating my $DEV= $evalSpecials->{'%DEV'};ReadingsVal(\"device2check\",\"state\",\"\") eq \"off\": Can't find string terminator '"' anywhere before EOF at (eval 24159) line 1.
Bitte um Hilfe?
Hallo Hackstall,
bei mir sieht, angepasst an deine Werte, die Condition so aus:
(Readingsval('device2check','state','') eq 'off'
also statt " Doppelhochkomma verwende ' Einfachhochkomma und keine Geschwungenenklammern!
Gruß
Johann
Danke,
werde ich nochmal probieren.
Derzeit führe ich:
UZSU_execute im converter auf und das funktioniert prima.
Gruss Andreas