[erledigt] state eines dummys nur teilweise umändern. ist das möglich?

Begonnen von the ratman, 22 März 2017, 14:56:30

Vorheriges Thema - Nächstes Thema

the ratman

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?
→do↑p!dnʇs↓shit←

bartman121

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.


the ratman

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.
→do↑p!dnʇs↓shit←

Damian

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.



Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

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...
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

the ratman

#5
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?
→do↑p!dnʇs↓shit←

Damian

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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

the ratman

#7
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
→do↑p!dnʇs↓shit←

the ratman

#8
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

→do↑p!dnʇs↓shit←

Damian


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]
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

the ratman

#10
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
→do↑p!dnʇs↓shit←

Damian

OK ich sehe jetzt, was du meinst. Das uzsu-widget "uzsuTimerEntry" kannte ich noch nicht. Ich werde mir das morgen mal genauer anschauen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

the ratman

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.
→do↑p!dnʇs↓shit←

Damian

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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

the ratman

#14
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?
→do↑p!dnʇs↓shit←