DOIF geht seit gestern nicht mehr - Update?

Begonnen von 87insane, 12 April 2019, 08:03:41

Vorheriges Thema - Nächstes Thema

CoolTux

Wenn Deine Formatierung stimmt (bin zu faul Klammern zu zählen) dann ist der setreading Befehl innerhalb der foreach Schleife.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

87insane

Jo, hab ich auch gesehen. Das wäre ne Performance Sache. Allerdings ist die Frage, warum das doif auf einmal nicht mehr reagiert.
LastAlarm wird auf die korrekte Uhrzeit gesetzt. Aber doif schnappt sich die Zeit nicht mehr. Wenn ich manuell setreading gerät Reading Zeit mache, geht es sofort auch in das doif über. So war es bis vor ein paar Tagen auch mit dem notify. Hatte es echt lange im Einsatz und habe es geliebt :)

CoolTux

Zitat von: 87insane am 14 April 2019, 12:40:06
Jo, hab ich auch gesehen. Das wäre ne Performance Sache. Allerdings ist die Frage, warum das doif auf einmal nicht mehr reagiert.
LastAlarm wird auf die korrekte Uhrzeit gesetzt. Aber doif schnappt sich die Zeit nicht mehr. Wenn ich manuell setreading gerät Reading Zeit mache, geht es sofort auch in das doif über. So war es bis vor ein paar Tagen auch mit dem notify. Hatte es echt lange im Einsatz und habe es geliebt :)

Mach das Notify erstmal stimmig und dann schauen wir weiter.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

87insane

Was heist denn stimmig? Ob das nun jede Runde oder nur einmal gesetzt wird hat bisher ja auch keine Rolle gespielt.
Weis auch nicht aus dem kopf ob die variablen auserhalb der schleife noch laufen. Wenn ja gehört das ja nur eine klammer weiter runter. Aber das ist für mich gerade echt neben Sache.

Werde es am pc direkt anpassen aber das klärt leider noch nicht die frage. So wie es scheint, hast du dazu aber schon eine Idee. :)

Hatte in einem thread aus 2014 gelesen das aus einem notify heraus ein setreading kein event erzeugt. Das ist vermutlich eine veraltete Info, da es ja ging. Wurde an dem Konstrukt ggf. Ein Update durchgeführt von einem von euch? Ich mache immer brav fhem updates aber es zeigt sich mal wieder, das ich das besser nicht machen sollte. Never Change a Running System^^

Gesendet von meinem LG-H850 mit Tapatalk


CoolTux

Eine direkte Idee noch nicht. Meine Meinung ist aber immer erst einmal das offensichtliche gerade rücken auch wenn es eventuell nichts direktes mit dem Problem zu tun hat.
Woher weißt Du es kein Event kommt? Hast du zur Auslösezeit den Eventmonitor offen gehabt?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

87insane

Jap ... Habe (was man hier nicht sieht) mit dem Kollegen von oben schon diverse PNs geschrieben und er hatte auch so seine Ideen. Daraus die Essens hatte ich dann hier veröffentlicht für die nach Welt.



Gesendet von meinem LG-H850 mit Tapatalk


CoolTux


readingsSingleUpdate( $defs{$NAME}, 'LastAlarm', $lastalarmalexa,1);


Statt dem setreading bitte einmal das testen. Ausserhalb der Schleife. In der Hoffnung daß der Wert von lastalarmalexa dann auch passt.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

87insane

Teste ich sobald ein pc in der nähe ist. Die werte an sich bzw das Ergebnis hat immer gepasst. Wenn dein Vorschlag wieder ein event erzeugt, gehts sicher wieder.

Nach wie vor frage ich mich, warum es auf einmal nicht mehr geht. An notify wurde laut Changelog ja auch nichts mehr groß verändert. An setreading soweit ich dazu was gefunden habe, auch nicht mehr. Komisch, komisch

Gesendet von meinem LG-H850 mit Tapatalk


87insane

Also das setreading hab ich mal über das handy weiter nach unten gesetzt. Das klappt auch und ist enorm schneller.

Im Event Monitor sehe ich wie LastAlarm gesetzt wird. Das doif nimmt die Zeit aber erst wenn ich in dem doif auf DEF klicke und danach auf speichern. So als würde man es eben frisch anlegen. Wenn ich einen anderen wecker stelle, übernimmt das doif dies nicht. Erst wieder wenn DEF+speichern.

Die andere Variante würde ich lieber am pc testen. Mein handy ist dafür nicht geeignet. Da aber anscheinend wieder ein event kommt, ist das ja schon mal gut.

Gesendet von meinem LG-H850 mit Tapatalk


CoolTux

Meine erste Vermutung.
Im Millisekunden Takt feuert das setreading. Dies löst Events aus die eventuell zu schnell hintereinander kommen.
Jetzt muss man schauen warum das DOIF nicht reagiert.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux


([ECHO_123:"LastAlarm"] and [?ECHO_123:LastAlarm] != 0)


Ich weiß nicht hundertprozentig in das so stimmt. Das erste soll auf das Event von LastAlarm reagieren und das zweite dann nur abgefragt werden.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

87insane



Zitat von: CoolTux am 14 April 2019, 16:38:21

([ECHO_123:"LastAlarm"] and [?ECHO_123:LastAlarm] != 0)


Ich weiß nicht hundertprozentig in das so stimmt. Das erste soll auf das Event von LastAlarm reagieren und das zweite dann nur abgefragt werden.

Hat locker 5 monate so geklappt.
Das erste soll reagieren wenn in dem Alarm Reading etwas passiert. Das zweite soll nur verhindern das es ausgeführt wird wenn 0 drin ist. Siehe notify... So stelle ich das quasi ab wenn zb Sonntag kein wecker an ist und man länger im dunklen schlafen will.

Kann es aber als test, genau wie das andere weiter oben einbauen.

Gesendet von meinem LG-H850 mit Tapatalk


87insane

Guten Morgen zusammen,

leider kam ich erst sehr spät zur weiteren Bearbeitung. Anbei das Ergebnis.....

Das notify wertet die Zeit des letzten Weckers aus. Dies klappt auch sauber. Das Reading LastAlarm wird gesetzt.
Leider ist das Verhalten des DOIFs aber noch gleich (schlecht).

Anbei mal was ich so gesammelt habe....

1. Wecker gesetzt (via App oder lokal mit der Sprache an der Alexa)
2. Warten bis FHEM - Alexa das mitbekommen hat und durch das notify das Reading geschrieben wird

EventMonitor - Auswertung letzter Wecker:
2019-04-17 10:34:39 echodevice ECHO_123 alarm_02_originalTime: 18:35:00.000
2019-04-17 10:34:39 echodevice ECHO_123 alarm_02_status: on
2019-04-17 10:34:39 echodevice ECHO_123 alarm_count: 2
2019-04-17 10:34:39 echodevice ECHO_123 LastAlarm: 18:35


Hier sieht man auch, dass das Reading gesetzt wurde. Danach schaue ich im DOIF und sehe weiterhin nichts.
Klicke ich auf DEF und danach auf modify im DOIF, springt die Zeit direkt auf die, die in LastAlarm steht.

Leider ändert es auch nichts, wenn ich das via "readingsSingleUpdate( $defs{$NAME}, 'LastAlarm', $lastalarmalexa,1);"
versuche. Das Verhalten von DOIF bleibt gleich.
So wie ich das sehe, wird ein EVENT erzeugt, welches auch die Zeit zeigt, welche es sein sollte.

Komme hier nicht mehr weiter. Ich verstehe es einfach nicht....

87insane

#28
Hab noch einen Fehler entdeckt bzw. das notify ein wenig schöner gemacht:


(ECHO_90F00818720600GX:alarm_.._status:.(on|off)) {
my $k = "0";
my $alarmoff = "0";
my $schleifennr = "1";
my $lastalarmalexa = "0";
#Log 1, "VOR SCHLEIFE lastalarmalexa: $lastalarmalexa";
foreach $k (1..ReadingsVal("$NAME", "AlarmCount", ""))
{
$schleifennr = sprintf("%02d", $k);
my $wecker = ReadingsVal("$NAME", "alarm_".$schleifennr."_originalTime" ,"0");
$wecker =~ s/:00.000$//;
#Log 1, "IN SCHLEIFE lastalarmalexa: $lastalarmalexa";
#Log 1, "IN SCHLEIFE schleifennr: $schleifennr wecker: $wecker lastalarmalexa: $lastalarmalexa";
if (ReadingsVal("$NAME", "alarm_".$schleifennr."_status", "") eq "on" && "$wecker" gt "$lastalarmalexa")
{
$lastalarmalexa = $wecker;
#Log 1, "GEFUNDEN lastalarmalexa: $lastalarmalexa";
}

elsif (ReadingsVal("$NAME", "alarm_".$schleifennr."_status", "") eq "off")
{
$alarmoff = $alarmoff + 1;

if (sprintf("%02d", $alarmoff) eq sprintf("%02d", ReadingsVal("$NAME", "AlarmCount", "")))
{
$lastalarmalexa = "keiner";
#Log 1, "KEIN lastalarmalexa: $lastalarmalexa";
}
}
}
        fhem("setreading $NAME LastAlarm $lastalarmalexa")
}


So ist es etwas schneller und die Prüfung auf alle Wecker = off klappt etwas schneller.

Es wird also nur einmal am Ende das Reading gesetzt. Ein Event wird wie oben im Beitrag erzeugt. DOIF interessiert es weiterhin nicht mehr.
PS: Ich weiß das am Ende das sprintf nicht nötig ist. War nur zum testen....

CoolTux

Dann solltest Du bitte einmal ein list vom aktuellen DOIF zeigen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net