Hauptmenü

AttrVal -> TimeSpec

Begonnen von remo, 10 Februar 2021, 14:00:49

Vorheriges Thema - Nächstes Thema

Otto123

#15
Hi,

ist erstmal nicht logisch und leider durch mich nicht nachvollziehbar. Funktioniert bei mir 1:1 mit deinem Code:
define dummy_Sonnenaufgang dummy
define dummy_Sonnenuntergang dummy
define at_Sonne1 at +*01:00 { my $s = sunrise_abs();; fhem("set dummy_Sonnenaufgang $s");; $s = sunset_abs();; fhem("set dummy_Sonnenuntergang $s");; }
set at_Sonne1 execNow
define AT_TEST5 at *{ReadingsVal('dummy_Sonnenaufgang','state','')} {}

Ergebnis
Internals:
   CFGFN     
   COMMAND    {}
   DEF        *{ReadingsVal('dummy_Sonnenaufgang','state','')} {}
   FUUID      6025449b-f33f-27f7-8d3c-b410587d16c9c7c7
   NAME       AT_TEST5
   NR         508624
   NTM        06:57:54
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 06:57:54
   TIMESPEC   {ReadingsVal('dummy_Sonnenaufgang','state','')}
   TRIGGERTIME 1613109474
   TRIGGERTIME_FMT 2021-02-12 06:57:54
   TYPE       at
   READINGS:
     2021-02-11 15:52:11   state           Next: 06:57:54
Attributes:

Kein Fehler.
Muss irgendwie an Deinem Setup liegen?

Allerdings kannst Du doch einfach direkt at mit sunrise und sunset definieren?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

remo

#16
Hallo Otto,

mit

set at_Sonne1 execNow

funktioniert die Definition von

define AT_TEST5 at *{ReadingsVal('dummy_Sonnenaufgang','state','')} {}

bei mir auch ohne Probleme - ohne nicht.

Sollte ich dann vor jedem at-define ein set at_xxx execNow ausführen?




ZitatAllerdings kannst Du doch einfach direkt at mit sunrise und sunset definieren?


Das ist richtig.
Hatte ich bisher auch.
Aber wenn für meine Bedürfnisse der "Sonnenaufgang" mal zu einer anderen Zeit stattfinden soll brauch ich nur an einer Stelle den Reading-Wert ändern und
meine gesamten Devices, deren ats davon abhängen ändern sich automatisch.

"Sonnenaufgang" ist in diesem Fall vielleicht nicht das repräsentativste Beispiel. Ich möchte das selbe Konstrukt auch noch für Dämmerung verwenden...





Otto123

#17
Naja execNow löst doch nur das Schreiben in den Dummy aus. solange der noch leer ist kann es ja nicht funktionieren!? Ich wollte keine Stunde warten.
Nachdem es jetzt ein paar Stunden so gelaufen ist und der dummy durch DEIN at mehrfach überschrieben wurde, funktioniert es immer noch. ;D
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

remo

ZitatIch wollte keine Stunde warten.

Nicht?! :D


{ReadingsVal('dummy_Sonnenaufgang','state','')}

Als Eingabe in das FHEM-Textfeld gibt aber den passenden Wert aus.
Auch ohne execNow ... ?!

Otto123

#19
Aber set Dummy ist set Dummy, wer das ausführt ist egal  :o

BTW Sonnenaufgang und Dämmerung sind für mich ziemlich gleich gelagert - aber egal. Du willst es über Dummies - so sei es.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

remo

#20
ZitatAber set Dummy ist set Dummy, wer das ausführt ist egal
Richtig, deshalb bin ich verwundert. Doch nun scheint es zu funktionieren. Abwarten ...

ZitatSonnenaufgang und Dämmerung sind für mich ziemlich gleich gelagert
Auch richtig.

Aber guck mal:
define dummy_Sonne_schummer dummy
define dummy_Sonne_daemmer dummy

define at_Sonne2 at +*01:00 { my $s = sunset_abs("HORIZON=-0.50",0);; fhem("set dummy_Sonne_schummer $s");; $s = sunset_abs("HORIZON=-3.79",0);; fhem("set dummy_Sonne_daemmer $s");; }


Ein Teil meiner Rollläden fahren um sunset_abs("HORIZON=-0.50",0) und der Rest um sunset_abs("HORIZON=-3.79",0)
Bekannterweise ändern sich die Uhrzeiten täglich - Richtung Sommer später, Richtung Winter früher.

Ich hab 12 Rollläden.
Bei 4 Rollläden habe ich das at bisher mit
define at_xxx at *{sunset_abs("HORIZON=-0.50",0)} {..} definiert, bei den restlichen 8 mit
define at_xxx at *{sunset_abs("HORIZON=-3.79",0)} {..}

Sechs (Außen)Lampen hängen dort auch noch mit dran.

Soll heißen, wenn mir das Einschalten der Lampen / das Fahren der Rollläden zu früh oder spät ist, musste ich bisher 18 ats editieren.

Nun definiere ich die 18 ats einmalig neu mit z.B.:

define AT_TEST7 at *{ReadingsVal('dummy_Sonne_schummer','state','')} {}
define AT_TEST8 at *{ReadingsVal('dummy_Sonne_daemmer','state','')} {}


Wenn mir JETZT die Uhrzeiten nicht passen brauche ich nur noch die HORIZON-Werte an einer einzigen Stelle, nämlich in at_Sonne2 abändern und alle anderen 18 ats bekommen das automatisch mit.



Puh, ich hoffe das war halbwegs verständlich erklärt?!  :o


EDIT:

allzu oft passt man die Zeiten ja nicht an. Das stimmt schon. Wenn es einmal passt, passt es eben.
Mir geht es dabei hauptsächlich um Konsistenz. Und wenn man mal etwas ändern muss, tut man das eben an einer bis zwei Stellen, statt an 18 ...

Otto123

#21
Ich weiß Dummies kosten kein Geld :)

Aber zur Übersichtlichkeit tragen sie nicht unbedingt bei. Denk mal drüber nach, einen Dummy mit mehreren Readings auszustatten, anstatt nur den state zu setzen. Entweder mit setreading oder mit setList und readingList ...
Oder man könnte die readings auch an dem Zentralen at schreiben ...
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

remo

Ok. Danke für den Hinweis!

Ich werde jetzt erstmal zwei-drei Tage beobachten, ob das Verhalten meinen Erwartungen entspricht.
Dann werde ich noch einmal über die Optimierung nachdenken.

Ich danke für deine Hilfe und wünsche einen schönen Abend ;)

remo

Hallo,

so, der Test war bedingt erfolgreich.

die Dummies selbst:

dummy_Sonne_daemmer
dummy_Sonne_schummer


werden automatisch und korrekt gesetzt.


Getestet mit:

{ReadingsVal('dummy_Sonne_daemmer','state','')}
{ReadingsVal('dummy_Sonne_schummer','state','')}



Die ats wiederum haben sich nicht selbstständig aktualisiert:

define AT_TEST8 at *{ReadingsVal('dummy_Sonne_daemmer','state','')} {}
define AT_TEST7 at *{ReadingsVal('dummy_Sonne_schummer','state','')} {}


Bei beiden stehen bei Next: noch die "alten" Uhrzeiten von gestern drin.

Ich habe die Defines der ats direkt in der fhem.cfg und erst wenn ich Save fhem.cfg klicke (also die Defines neu ausgeführt werden) ändern sich auch die entsprechenden Uhrzeiten unter Next:

... Ist das normales Verhalten?


MadMax-FHEM

Zitat von: remo am 12 Februar 2021, 10:40:13
... Ist das normales Verhalten?

Ja.

Habe ich ja hier bereits geschrieben: https://forum.fhem.de/index.php/topic,118660.msg1130980.html#msg1130980

Du brauchst noch "irgendwas" (z.B. notify), was beim Verändern der Uhrzeit im dummy eben das at neu anlegt/ändert: defmod...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

remo

Gut. Ok.
Klingt plausibel.
Ich habe zu defmod auch nochmal in der Doku nachgelesen.

defmod AT_TEST7 at *{ReadingsVal('dummy_Sonne_schummer','state','')} {}
defmod AT_TEST8 at *{ReadingsVal('dummy_Sonne_daemmer','state','')} {}


Schmeißt erst einmal keine Fehler.
Reicht das so aus oder habe ich defmod falsch verstanden?

Otto123

#26
Daran habe ich gestern auch noch gedacht, aber: Was ist denn der Unterschied zu der Form mit *{sunrise()}. Da wird doch auch jeden Tag ein neues at gesetzt? Siehe mein Zitat aus #1 bzw. Doku zu at. Das at weiß das es bei {sunrise} etwas anderes machen muss - kann sein?
Was wiederum für meine Variante sprechen würde. Man kann ja das at mit sunrise definieren und die Parameter von sunrise aus einem Dummy lesen :) - falls man wirklich ständig den Sonnenaufgang manipulieren will :)

BTW: die Verwendung der abs Funktionen im at (siehe #20) erscheint zwar irgendwie "optisch" gut, ist aber für die Abläufe des Wechsel der Sonnenläufe (Winter und Sommersonnenwende) falsch.

Zu #25 Da wäre modify auch ein probates Mittel https://fhem.de/commandref_DE.html#modify
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

remo

Dankeschön für den Input.

Ich wünsche ein schönes Wochenende!

remo

Hallo,

ich muss dieses Thema nochmals aufgreifen.

Bezugnehmend auf meine Bewässerungssteuerung:
https://forum.fhem.de/index.php/topic,116443.105.html



Ich habe einen Dummy mit selbst angelegten Readings:

Internals:
   CFGFN      ./FHEM/004_bewaesserung.cfg
   FUUID      606ee4ad-f33f-1ce0-6906-73363ca3f3c75138
   NAME       dummy_BewaesserungAuto_VorneSeite
   NR         447
   STATE      off
   TYPE       dummy
   READINGS:
     2021-04-08 13:13:07   duration        45
     2021-04-08 13:13:12   fri             X
     2021-04-08 13:13:08   mon             X
     2021-04-08 13:13:13   sat             -
     2021-04-08 13:13:05   start           00:15
     2021-04-08 13:10:37   state           off
     2021-04-08 13:13:14   sun             X
     2021-04-08 13:13:11   thu             -
     2021-04-08 13:13:09   tue             X
     2021-04-08 13:13:10   wed             -
Attributes:
   alias      vorne + Seite
   devStateIcon on:ios-on-green:off off:ios-off:on .*:ios-NACK:off
   group      01_Zeitprogramme (autom. sprengen/wässern)
   readingList state start duration mon tue wed thu fri sat sun
   room       BEWÄSSERUNG
   setList    state:on,off
start:00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,00:00
duration:15,30,45,60,90,120,180 mon:X,- tue:X,- wed:X,- thu:X,- fri:X,- sat:X,- sun:X,-
   sortby     1
   webCmd     :start:duration:mon:tue:wed:thu:fri:sat:sun
   webCmdLabel :Start:Dauer:Mo:Di:Mi:Do:Fr:Sa:So


So weit. So gut.

Dann erzeuge ich mir ein at:

define at_BewaesserungAuto_VorneSeite at *{ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start','')} { magic }


Bei jedem save oder Save fhem.cfg erhalte ich allerdings folgende Fehlermeldung:
"ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start','')" must return a timespec and not .



Füge ich in meine Config vor Erzeugung des at ein setreading dummy_BewaesserungAuto_VorneSeite start 23:00 ein,
speichert FHEM ohne Fehlermeldung -
kommentiere ich das setreading ... wieder heraus, bringt FHEM wieder o.g. Fehlermeldung.

Das setreading dummy_BewaesserungAuto_VorneSeite start 23:00 kann ich in meiner Config aber nicht stehen lassen,
da sich sonst jedes Mal wenn ich eine Änderung speichere (save oder Save fhem.cfg) der Wert des Readings start des Dummys
wieder auf den festen Wert 23:00 zurücksetzt.

Ich benötige das für meine Steuerung aber dynamisch und möchte nicht / kann nicht jedes Mal die Zeiten wieder von Hand korrigieren.


Ich hoffe ich habe das Problem halbwegs verständlich schildern können.



Liebe Grüße

Otto123

Naja das Problem wird mir klar:
Beim define wird der Wert aus dem Dummy ausgelesen und fertig. Damit das funktioniert muss er zu dieser Zeit drinstehen.
Wenn z.B. in der config erst das at und dann der dummy definiert wird funktioniert das beim start von FHEM nicht.

Der Fehler mit dem save ist bei mir nicht nachvollziehbar. Aber Du editierst ja direkt - da ist alles anders :)

ersatzweise musst Du sowas definieren:
ReadingsVal('dummy_BewaesserungAuto_VorneSeite','start','11:11')
Wie das Ganze aber dynamisch funktioniert ist mir schon wieder unklar geworden.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz