Twilight - Maintainership (orphan 2020)

Begonnen von Beta-User, 05 September 2020, 10:06:33

Vorheriges Thema - Nächstes Thema

Beta-User

Ups, danke, update anbei (für svn) folgt noch  ::) ...

Was die forecasting-Analyse in Weather angeht, hast du recht, dass man das im Sinne einer größeren "Fehlertoleranz" hinischtlich der gewählten Einstellungen am Device ausbauen könnte. Aber da der Code - wenn man von der "komplexen 0-Zuweisung" absieht -  eigentlich eher schlicht ist, hoffe ich auf Zuarbeit von jemand, der unbedingt was anderes haben will als die default-Einstellungen :P ::) :) ...
U.A. deswegen gibt es jetzt ja die Option, die interne Routine durch was eigenes zu ersetzen 8) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Christoph Morrison

Hast du deinen Code eigentlich auch auf GitHub? Hätte ggf. ein paar Änderungsvorschläge.

Beta-User

Jein...

Bin nur Gelegenheitsnutzer von github und nutze das eher als eine Art Zwischenablage.
Der Code von vorhin ist aber dort zu finden, und es würde mich freuen, wenn du deine Vorschläge einbringen magst (wo auch immer, oder wenn du dich der Waise wieder ganz annehmen wolltest...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

BroPi

Kleiner Zwischenbericht zur 59_Twilight.pm:0.230710/2020-11-02:

Das Bildchen zeigt jetzt eine häufigere Aktualisierung der Cloud-Werte (gestern).
Letzter cloudCover_sr kurz vor 8:00 Uhr
Letzter cloudCover_ss und cloudCover kurz vor 15:00 Uhr

Weiterhin ist mir aufgefallen, dass die Cloud-Werte wohl alle von fc1_cloud03 (Proplanta) stammen. Kann es sein, dass in diesem Programmteil:
for (my $i = 0; $i < 3 ; $i++) {
        $hour[$i] <=  4 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud03",0) :
        $hour[$i] <=  7 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud06",0) :
        $hour[$i] <= 10 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud09",0) :
        $hour[$i] <= 19 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud18",0) :
        $hour[$i] <= 22 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud21",0) :
    $ret[$i] = ReadingsNum($extDev,"fc${fc_day1}_cloud03",0);
    }
    return @ret;;
immer die dick markierte Zeile zuschlägt? Leider bin ich ein DAU und kann da nicht mitreden.

Beta-User

Kann ich nicht ausschließen, daher ja die Bitte, das zu testen.

Kannst du mal ein Log3 direkt hinter der loop-Klammer und vor "return @ret;" einfügen:
Log3( $hash, 3, "[$hash->{NAME}] Proplanta data: hours $hour[0]-$hour[1]-$hour[2], fc_day0 $fc_day0, data $ret[0]-$ret[1]-$ret[2]");
Könnte man ggf. dann noch aufbohren für die ReadingsNum-Werte, was aber komplizierter ist, evtl. kommen wir der Sache dann so schon auf die Schliche...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

BroPi

Danke!
Habe die Zeile jetzt eingefügt und warte einen Tag ab. Danach werde ich die Log-Einträge hier posten.

BroPi

#186
Hier nun die versprochenen Log-Daten eines Tages:

2020.11.05 16:33:38 3 : [HGW_Twilight_Test] Proplanta data: hours 16-8-15, fc_day0 0, data 100-100-100
2020.11.05 17:33:38 3 : [HGW_Twilight_Test] Proplanta data: hours 17-8-15, fc_day0 0, data 100-100-100
2020.11.05 18:33:38 3 : [HGW_Twilight_Test] Proplanta data: hours 18-8-15, fc_day0 0, data 100-100-100
2020.11.05 19:33:38 3 : [HGW_Twilight_Test] Proplanta data: hours 19-8-15, fc_day0 0, data 100-100-100
2020.11.05 20:33:38 3 : [HGW_Twilight_Test] Proplanta data: hours 20-8-15, fc_day0 0, data 100-100-100
2020.11.05 21:33:47 1: PROPLANTA Wetter_HGW: HtmlAcquire.590 Error: Can't get https://www.proplanta.de/Wetter/profi-wetter.php?SITEID=60&PLZ=xxxxxx....Can't connect to www.proplanta.de:443 (Temporärer Fehler bei der Namensauflösung)
2020.11.05 22:33:38 3 : [HGW_Twilight_Test] Proplanta data: hours 22-8-15, fc_day0 0, data 100-100-100
2020.11.05 23:33:38 3 : [HGW_Twilight_Test] Proplanta data: hours 23-8-15, fc_day0 0, data 100-100-100
2020.11.06 00:00:01 3 : [HGW_Twilight_Test] Proplanta data: hours 0-8-15, fc_day0 1, data 100-100-100
2020.11.06 00:33:38 3: [HGW_Twilight_Test] Proplanta data: hours 0-8-14, fc_day0 0, data 100-100-100
2020.11.06 01:33:38 3: [HGW_Twilight_Test] Proplanta data: hours 1-8-14, fc_day0 0, data 100-100-100
2020.11.06 02:33:44 3: [HGW_Twilight_Test] Proplanta data: hours 2-8-14, fc_day0 0, data 100-100-100
2020.11.06 03:33:38 3: [HGW_Twilight_Test] Proplanta data: hours 3-8-14, fc_day0 0, data 100-100-100
zwischen 4:00  und 7:00  sollte fc0_cloud06 = 75 ausgelesen werden:
2020.11.06 04:33:38 3: [HGW_Twilight_Test] Proplanta data: hours 4-8-14, fc_day0 0, data 100-100-100
2020.11.06 05:33:39 3: [HGW_Twilight_Test] Proplanta data: hours 5-8-14, fc_day0 0, data 100-100-100
2020.11.06 06:33:38 3: [HGW_Twilight_Test] Proplanta data: hours 6-8-14, fc_day0 0, data 100-100-100
zwischen 7:00  und 10:00  sollte fc0_cloud09 = 100 ausgelesen werden:
2020.11.06 07:33:38 3: [HGW_Twilight_Test] Proplanta data: hours 7-8-14, fc_day0 0, data 100-100-100
2020.11.06 08:33:39 3: [HGW_Twilight_Test] Proplanta data: hours 8-8-14, fc_day0 0, data 100-100-100
2020.11.06 09:33:39 3: [HGW_Twilight_Test] Proplanta data: hours 9-8-14, fc_day0 0, data 100-100-100
ab 9:33 war fc0_cloud09 = 75
zwischen 10:00  und 19:00  sollte fc0_cloud18 = 100 ausgelesen werden:
2020.11.06 10:33:39 3 : [HGW_Twilight_Test] Proplanta data: hours 10-8-14, fc_day0 0, data 75-75-75
2020.11.06 11:33:39 3 : [HGW_Twilight_Test] Proplanta data: hours 11-8-15, fc_day0 0, data 75-75-75
2020.11.06 12:33:38 3 : [HGW_Twilight_Test] Proplanta data: hours 12-8-15, fc_day0 0, data 75-75-75
2020.11.06 13:33:40 3 : [HGW_Twilight_Test] Proplanta data: hours 13-8-15, fc_day0 0, data 75-75-75
2020.11.06 14:33:39 3 : [HGW_Twilight_Test] Proplanta data: hours 14-8-15, fc_day0 0, data 75-75-75
fc0_cloud00 100
fc0_cloud03 87.5
fc0_cloud06 100
fc0_cloud09 100
fc0_cloud12 100
fc0_cloud15 100
fc0_cloud18 100
fc0_cloud21 100
fc1_cloud00 100
fc1_cloud03 75
fc1_cloud06 50
fc1_cloud09 12.5
fc1_cloud12 12.5
fc1_cloud15 0
fc1_cloud18 0
fc1_cloud21 0
2020.11.06 15:33:38 3 : [HGW_Twilight_Test] Proplanta data: hours 15-8-15, fc_day0 0, data 75-75-75
2020.11.06 16:33:39 3 : [HGW_Twilight_Test] Proplanta data: hours 16-8-15, fc_day0 0, data 75-75-75


Dort sind noch die zugehörigen fcx_cloud_xy vom Proplanta-Device eingetragen. Bis ca. 9:33 Uhr sieht es OK aus, wobei ich nicht sagen kann welche Cloud-Werte wirklich da waren. Ab dann wechselte  fc0_cloud09 auf 75.
Ausgelesen sollte zwischen 10:00 und 19:00 Uhr dann fc0_cloud18 mit dem Wert 100 werden.
Ab 10:33 Uhr war aber immer data 75-75-75.
Ab 14:33 Uhr gab es keinen fco_cloudxy -Wert 75 mehr. Trotzdem bleibt data 75-75-75.
Einziger Cloud-Wert mit 75 ist in Proplanta nur bei fc1_cloud03 75 zu finden.
Damit bestätigt sich meine Vermutung aus #183.

Beta-User

hmm, dann scheinen diese nummerischen Vergleiche irgendwie nicht zu klappen. Vielleicht kann mir ja einer der Perl-Gurus verraten, warum...

Kannst du mal eine Klammer um die "hour-Stationen" machen?
($hour[$i]) <= ...

Wenn du dann die DEF "änderst" (ein Leerzeichen dazufügen sollte reichen), sollten neue Log-Einträge kommen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

BroPi

Schnelltest mit Klammern bringt keine Änderung.
2020.11.06 19:09:52 3 : [HGW_Twilight_Test] Proplanta data: hours 19-8-15, fc_day0 0, data 75-75-75
Im Moment ist ein günstiger Testzeitpunkt, da der Cloud-Wert mit 75 nur einmal bei fc1_cloud03 vorkommt.
Ich wußte gar nicht, das man den Bedingungsoperator ?: caskadieren kann. Vielleicht sollten wir hier einfach if, elsif ... else verwenden. (Aber wie oben schon gesagt, bin ein Dau. Meine Meinung ist sicherlich nicht maßgebend.)

Beta-User

Na ja, es läuft ja scheinbar bis zum Ende durch, und eigentlich sieht die Log-Ausgabe auch so aus, als wären da nur Zahlenwerte in dem Array drin...

Würde trotzdem erst mal (nur) noch die Rückgabewerte aus getTwilightHours() näher zusammenrücken, vielleicht ist es ja doch ein Leerzeichen, was sich da irgendwie noch versteckt hat:
return $hour,$sr_hour,$ss_hour;
Und normalerweise macht Perl die Konvertierung von Zeichen zu Zahlenwerten automatisch, wenn es erforderlich ist, hier geht aber wohl was schief - komischerweise, ohne dass da was im Log dazu steht. Na ja, jedenfalls funktioniert es bei Weather, aber da wird auch explizit gerechnet.
Könnte man dann hier auch mit rumtricksen:
    ($hour[$i]+0) <  5 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud03",0) :
        ($hour[$i]+0) <  8 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud06",0) :
        ($hour[$i]+0) < 11 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud09",0) :
        ($hour[$i]+0) < 20 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud18",0) :
        ($hour[$i]+0) < 23 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud21",0) :
        $ret[$i] = ReadingsNum($extDev,"fc${fc_day1}_cloud03",0);
    }


Aber es hindert dich niemand dran, nach diesen Versuchen dann auch eine klassische if-elsif-Konstruktion zu basteln. Wichtiger ist, dass es am Ende funktioniert... ::)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

BroPi

Das Einfügen von (  +0) hat keine Veränderung gebracht. Dann habe ich noch eine Klammerung der Bedingungsoperationen eingefügt und nun wurde gleich fc0_cloud09 = 25 korrekt eingelesen.

($hour[$i]+0) <  5 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud03",0) : (
        ($hour[$i]+0) <  8 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud06",0) : (
        ($hour[$i]+0) < 11 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud09",0) : (
        ($hour[$i]+0) < 20 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud18",0) : (
        ($hour[$i]+0) < 23 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud21",0) :
        $ret[$i] = ReadingsNum($extDev,"fc${fc_day1}_cloud03",0)))));


Nun beobachte ich erst mal weiter. Wenn es weiterhin richtig läuft entferne ich noch (  +0), um zu sehen ob es entfernt werden kann.

BroPi

Letzter Test erfolgreich. Nachdem auch (  +0) noch entfernt wurde sind jetzt die Werte immer noch richtig, wie z.B.:
2020.11.07 14:08:18 3: [HGW_Twilight_Test] Proplanta data: hours 14-7-16, fc_day0 0, data 0-100-0

Mein Vorschlag: Code übernehmen.

$hour[$i] <  5 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud03",0) : (
        $hour[$i] <  8 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud06",0) : (
        $hour[$i] < 11 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud09",0) : (
        $hour[$i] < 20 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud18",0) : (
        $hour[$i] < 23 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud21",0) :
        $ret[$i] = ReadingsNum($extDev,"fc${fc_day1}_cloud03",0)))));


Frage: Warum werden eigentlich nicht _cloud12 und 15 mit einbezogen?
Für Twilight_Weather tagsüber würde es doch Sinn machen.

Beta-User

Hatte nur das userReading übernommen - vermeintlich "as is"....Übernehme gerne den vollständigen Vorschlag; bzw zusätzlich.: passen die Zeiten so 100% zu den Readings oder wäre nicht <7 => 06 richtiger?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

BroPi

Ja.
4, 7, 10, 13, 16, 19, und 22 wären für mich OK.

BroPi

Hier der vollständige Vorschlag:

$hour[$i] <  4 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud03",0) : (
        $hour[$i] <  7 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud06",0) : (
        $hour[$i] < 10 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud09",0) : (
        $hour[$i] < 13 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud12",0) : (
        $hour[$i] < 16 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud15",0) : (
        $hour[$i] < 19 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud18",0) : (
        $hour[$i] < 22 ? $ret[$i] = ReadingsNum($extDev,"fc${fc_day0}_cloud21",0) :
        $ret[$i] = ReadingsNum($extDev,"fc${fc_day1}_cloud03",0)))))));