ein dummy, wie er jetzt aussieht und auch super funzt:defmod homObot_Timer dummy
attr homObot_Timer DbLogExclude .*
attr homObot_Timer alias homObot Fahrerlaubnis
attr homObot_Timer fp_Grundriss 920,631,2,homObot,
attr homObot_Timer fp_Quer 594,1604,2,homObot Fahrerlaubnis,
attr homObot_Timer setList state:uzsuTimerEntry
attr homObot_Timer userReadings userTag { my @a = split '\|',ReadingsVal($name,"state", 0);;$a[0] },\
userZeit { my @a = split '\|',ReadingsVal($name,"state", 0);;$a[1] },\
userOnOff { my @a = split '\|',ReadingsVal($name,"state", 0);;$a[2] }
attr homObot_Timer webCmd state
setstate homObot_Timer Mo,Mi,Fr|17:00|enabled
setstate homObot_Timer 2017-03-22 12:40:04 state Mo,Mi,Fr|17:00|enabled
setstate homObot_Timer 2017-03-22 12:40:04 userOnOff enabled
setstate homObot_Timer 2017-03-22 12:40:04 userTag Mo,Mi,Fr
setstate homObot_Timer 2017-03-22 12:40:04 userZeit 17:00
mein problem:
ich schalte über z.b. meine urlaubsliste div. geräte, wie auch den bot aus.
das ist ja auch noch kein problem, da ich ja nur den status von "userOnOff" ensprechend befüllen muß.
das dumme daran ist, dass dann der state und somit auch die anzeige auf der grafischen oberfläche auf "enabled" stehen bleibt was leicht verwirrend ist, weil ja eigentlich schon alles mein reading mit "disabled" abfrägt.
nun die frage:
kann man z.b. von nem doif weg den state "Mo,Mi,Fr|17:00|enabled" auch auf "disabled" ändern, ohne tage und uhrzeit zu verändern?
Was alle immer mit DOiF haben :)
Schau dir Mal das Attribut stateformat an. Vermutlich reicht es den bot nur ein anderes Reading als stateformat zu verpassen.
ich mag halt doif ... bin quasi damit aufgewachsen ... hier herrscht eine notify-freie zone *lach*
und .. leider nicht
es wird dann zwar als state meine userOnOff angezeigt, aber das state-reading an sich bleibt gleich.
ändere ich den state per doif (oder sonst was), passiert mal gar nix. das scheint wohl die uzsu wenig zu beeindrucken.
So etwas kann man beliebig in Perl programmieren, hier mal eine Lösung mit DOIF-Mitteln:
([myreading] eq "enable") (set homObot_Timer [homObot_Timer:state:"(.*)disable"]enable)
DOELSE
(set homObot_Timer [homObot_Timer:state:"(.*)enable"]disable)
Wichtig ist, das der jeweilige Zweig nur ausgeführt wird, wenn das "Richtige" drin steht, also auf enable setzen, wenn disable drin steht und umgekehrt, sonst ist der Status kaputt.
Ich persönlich würde den zusammengesetzten Status immer aus den einzelnen Teilen aktiv zusammensetzen, wenn sich einer dieser Teile ändert.
Hier mal eine Lösung mit bisschen Perl, hier erfolgt mit dem ?-Operator eine Abfrage, ob wirklich der andere Zustand drin steht, hier wird also nichts kaputt gemacht.
([myreading] eq "enable") (set homObot_Timer {("[homObot_Timer]" =~ "(.*)disable"?"$1enable":"[homObot_Timer]")})
DOELSEIF...
wow - ich kapiers zwar nicht, aber ich schreib mal ab *g*
irgenwie bin ich aber zu blöd dafür:
ich nehm mal deine perl-version und stell sie mal in das doif, dass die feiertage regelt([homObot_Timer:userOnOff] eq "enabled") (set homObot_Timer {("[homObot_Timer]" =~ "(.*)disabled"?"$1enabled":"[homObot_Timer]")})
DOELSEIF
([feiertage_allgemein:state] eq "Urlaub" and [05:00|0123456])
(
set [homObot_Timer:userOnOff] disabled;
set Arbeitstag_BeginntAnAus Aus;
)
DOELSEIF
([feiertage_allgemein:state] eq "none" and [05:00|0123456])
( set [homObot_Timer:userOnOff] enabled; ))
passiert leider nix wenn ich die entsprechenden cmd_2 oder 3 händisch schalte. muß ich das für disabled nochmal machen?
ich hab grad das gefühl, dass wer lacht ...
nachtrag:
error set enabled disabled; set Arbeitstag_BeginntAnAus Aus; : Please define enabled first
nachtrag2:
jetzt glaub ich an gar nix mehr Please define [homObot_Timer:userOnOff] first kann ich kein userreading beschreiben, oder hab ich wieder nen knick in der leitung?
in dem fall müsste ich also direkt den state ändern und hoffen, dass das userreading alles mitbekommt?
dafür sollte man deinen code ja sogar mißbrauchen können, oder?
Du könntest auch deinen Dummy homObot_Timer mit all seinen Readings gleich als DOIF definieren und dort zusätzlich das Attribut state setzen:
attr homObot_Timer state [$SELF:userTag][$SELF:userZeit][$SELF:userOnOff]
dann wird dieser immer die aktuellen Informationen im Status darstellen, ohne dass du dich drum kümmern musst.
als erstes mal: vielen dank, dass du dir gedanken machst - ich würd auf solche ideen gar ned kommen!
kann dein doif überhaupt irgendwas nicht? *g*
hmm, mich würds ja freuen, das würde auch mit setList state:uzsuTimerEntrygehen? ich denke mal blind, dass gäbe das selbe problem wie mit nem dummy, oder?
das is ja der einzige grund, warum ich den ganzen sermon veranstalte. hatte vorher lauter einzelne dummys für die steuerung und man weiß ja das der waf auch was fürs auge braucht.
ich geh mal probieren - hoffe, ich darf weiterhin auf deine gehirnzellen zurückgreifen, weil mir schwant böses *g*
ich glaub, ich erklär mal, was das ganze überhaupt soll - nicht, dass du dir deine girnzellen verbratest für nix *g*
1) ich wollte diese uzsu im state, damit meine bot-einstellungen was gleich schauen.
2) dann mußt ich den state in meine 3 readings teilen, damit ich die brauchbar in mein doif kriege (ich liebe zwar doif, komme aber eben drauf, dass ich nicht mal 5% davon verwende scheinbar).
3) und nun hab ich eben das problem mit enabled/disabled
so - lässt mir keine ruhe, also mal neu denken
grundgedanke - ein bissi anders rum mal:
ich brauche ein doif, dass mir einen teil eines status in nem dummy ändert. das muß nicht mal gegengeprüft werden, weil die (teil)änderung des states ja das userreading mitändern müsste, wie wenn ich einfach den knopf für disabled/enabled drücke.
deine idee dazu:(
[feiertage_allgemein:state] eq "Urlaub"
)
(set homObot_Timer [homObot_Timer:state:"(.*)disabled"]enabled)
DOELSEIF
(
[feiertage_allgemein:state] ne "Urlaub"
)
(set homObot_Timer [homObot_Timer:state:"(.*)enabled"]disabled)
der (teil)state des dummys würde sich brav ändern, aber es wird der rest des states gekilled, bzw. steht blödsinn drinnen wie z.b.state ,|23:00|disabled 2017-03-23 10:54:41
userOnOff disabled 2017-03-23 10:54:41
userTag , 2017-03-23 10:54:41
userZeit 23:00 2017-03-23 10:54:41
Vielleicht kannst du darauf aufbauen:
DOIF (Bedingung zum Setzen von Tag) (setreading $SELF [$SELF:userTag] [Reading mit dem Tag])
DOELSEIF (Bedingung zum Setzen von onoff) (setreading $SELF [$SELF:userOnOFF] [Reading mit onOFF])
DOELSEIF (Bedingung zum Setzen von userZeit) (setreading $SELF [$SELF:userZeit] [Reading mit userZeit])
attr ... state [$SELF:userTag][$SELF:userZeit][$SELF:userOnOff]
jetzt versteh ich echt nur mehr bahnhof ...
das problem scheint mir das uzsu-widget (das fürs web-frontend, nicht für die tablet ui - siehe beitrag 1 --> https://forum.fhem.de/index.php/topic,32660.0.html ) zu sein, und ich nicht mal wüsste, was ich für bedienungen für tag oder stunde nehmen sollte.
ich kann einfach meine eigenen userreadings nicht überschreiben, weil sie dem state vom widget logischer weise egal zu sein scheinen und was beim setzen des states des widgets rauskommt, steht oben.
ich glaub, wir reden da aneinander vorbei - oder ich bin wieder zu blöd zum kapieren, was du meinst
ich bastel mal - vielleicht kapier ich ja, was gemeint is
OK ich sehe jetzt, was du meinst. Das uzsu-widget "uzsuTimerEntry" kannte ich noch nicht. Ich werde mir das morgen mal genauer anschauen.
oh, das wär geil!
krieg grad n schlechtes gewissen ... ich will dich ned ausnutzen!
ich bin da auch nur zufällig drüber gestolpert ... ist halt endlich mal ne möglichkeit, dass auch z.b. ein floorplan ohne riesen gfx.gedöns was gleichschaut *g*
wird halt scheints auch nimma weiter entwickelt. manche widgets hacken da ein wenig.
Also DOIF kann natürlich mit uzsuTimerEntry nicht umgehen, weil es die Mechanismen nicht kennt.
Aber
(Bedingung für enable)
(set homObot_Timer {("[homObot_Timer]" =~ "(.*)disabled"?"$1enabled":"[homObot_Timer]")})
DOELSE
(set homObot_Timer {("[homObot_Timer]" =~ "(.*)enabled"?"$1disabled":"[homObot_Timer]")})
funktioniert bei mir wie gewünscht.
nicht nur bei dir *bg*
VIELEN, VIELEN dank!
nur, damit ich auch weiß, was ich da nun habe:
das ist nun aber echt nur kühr. keine antwort macht mich auch ned böse *g* aber dafür hast sicher gleich was zu lachen ...
gleich vorweg: ich werd perl und andere sprachen nie kapieren, aber vielleicht kapier ich ja wenigstens teile daraus.
{("[homObot_Timer]" =~ "(.*)disabled"?"$1enabled":"[homObot_Timer]")}
tu mir fast schon leicht, versteh nur nicht, warum .* in klammern steht, oder is das wieder so ein "fhem kanns, perl kanns nur anders" zeug?
die idiotenübersetzung wäre wohl:
guck, ob am ende des states von homObot_Timer disabled steht und tausche es mit enabled. $1 ist mir halt ned klar wofür oder setzt das quasi alles von (.*) wieder ran?
und nach : wird einfach zurückgeschrieben, oder?
Zitat von: the ratman am 24 März 2017, 13:50:49
{("[homObot_Timer]" =~ "(.*)disabled"?"$1enabled":"[homObot_Timer]")}
die idiotenübersetzung wäre wohl:
guck, ob am ende des states von homObot_Timer disabled steht und tausche es mit enabled. $1 ist mir halt ned klar wofür oder setzt das quasi alles von (.*) wieder ran?
und nach : wird einfach zurückgeschrieben, oder?
ja.
$1 ist das, was in (.*) steht und das ist alles, war vor disabled steht - das gehört zu RegEx. Und dem Perlprogrammierer muss man noch sagen , dass er [homObot_Timer] gegen den aktuellen Status von homObot_Timer tauschen muss. Und dem FHEM-User muss man sagen, dass er in einem FHEM-Befehl in {(...)} Perl-Welt einbauen kann.
ah, dann wars ja gar ned so falsch - thx für die info ...
und nun lass ich dich in ruhe und warte mal ab, was dir noch so an ideen für doif kommen *bg*
Kleine Fingerübung zum uzsu-widget, siehe https://forum.fhem.de/index.php/topic,69573.msg610919.html#msg610919