Zitat von: Beta-User am 18 Februar 2026, 18:25:38Zumindest Wikipedia behauptet, dass diese modulo-Funktionalität praktisch jede Programmiersprache kennen würde..Also ich habe sie wie gesagt noch nie irgendwo gesehen und ich denke Wikipedia ist auch nicht 100% Fehlerfrei. Was natürlich nicht heißt, dass es die Funktionalität gibt, ich sie nur nie in irgendeiner Programmiersprache benötigt und deshalb nicht gefunden habe. Was aber dann wieder bedeuten würde das in anderen Programmiersprachen andere einfache Wege vorhanden sind um so ein Ziel zu erreichen.
Zitat von: Per am 17 Februar 2026, 19:51:23Und weil 47 eine Primzahl ist, ist nur bei 1 und 47 der Rest 0. Wo ist also dein Problem?Wenn man es so schreibt kein Problem - nur tut das nirgendwo jemand.
47/21=2 Rest 2Da lese ich daraus, dass die 2 den Rest markiert und nicht, das Rest für die verbleibende Menge zwischen dem ganzzahligen Divisor und der zu teilenden Zahl ist.Es geht einfach um die Verständlichkeit der Schreibweise.($yday % 21 == 0)funktionieren soll.Zitat von: DS_Starter am 17 Februar 2026, 22:51:00Ich habe comforttemp nun so erweitert, dass in dem Schlüssel alternativ eine Device:Reading Kombi angegeben werden kann:Das ist hier wie im Wunderland. Kaum hat man einen Wunsch, geht er schon in Erfüllung.
comforttemp
Solltemperatur (Komforttemperatur) in den Innenräumen in °C (Pflichtangabe).
Der Wert kann fest gesetzt oder durch eine <Device>:<Reading>-Kombination geliefert werden:
<Device>:<Reading> - die Device/Reading Kombination liefert die Temperatur
Wertebereich: -40..40
Update liegt im contrib.
@Klaus,ZitatWäre dennoch irgendwie praktischer. Jetzt sehe ich zweimal täglich, dass die cfg geändert wurde. Ist aber ein Komfortproblem, zugegeben.Die Änderung ist über das rote Fragezeichen nur sichtbar, wenn man im global Device explizit autosave=0 gesetzt hat. Sonst erfolgt die Änderung völlig transparent ohne diese Signalisierung.
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/valuepinctrl set 17 op dhAus meiner Sicht erfolgreich (bis zum nächsten Reboot...):pinctrl get 17
Aus
17: ip -- | lo // GPIO17 = input
wurde
17: op -- -- | hi // GPIO17 = outputdefmod CCD2 CUL /dev/ttyAMA0@38400 0000/dev/ttyAMA0 ist unter /dev aufgeführt (oder ist es immer da?)ZitatDer entscheidende Auslöser liegt in der Art und Weise, wie das Modul den Referenztag ("Gestern") bestimmt, um die historischen Daten (z.B. batmaxsoc, also ob die Batterie voll wurde) abzurufen.
Im Code (innerhalb der Logik, die die "SoC Step1"-Ausgaben erzeugt, vermutlich _batSocTarget oder _batChargeMgmt) wird der Vergleichstag wie folgt definiert:
Perl
# Auszug aus der Logik (Snippet 22/23)
my $yday = strftime "%Y-%m-%d", localtime($t - 86400); # Datum gestern
my $batymaxsoc = HistoryVal ($name, $yday, 99, 'batmaxsoc'.$bn, 0); # gespeicherter max. SOC des Vortages
my $batysetsoc = HistoryVal ($name, $yday, 99, 'batsetsoc'.$bn, $lowSoc); # gespeicherter SOC Sollwert des Vortages
Das Datum $yday wird berechnet, indem von der aktuellen Zeit ($t) exakt 24 Stunden (86400 Sekunden) abgezogen werden.
Was passiert beim Tageswechsel?
Um 23:59:XX Uhr (Tag A):
$t - 24h verweist auf Tag A minus 1 (Vorgestern).
Das Modul prüft also die Performance von Vorgestern, um das Ziel für "Heute" (Tag A) zu bestätigen.
Ergebnis im Log: Target: 55 % (Dies ist das Ziel für den noch laufenden Tag A).
Um 00:00:00 Uhr (Tag B):
$t - 24h springt jetzt auf Tag A (Gestern, der gerade zu Ende ging).
Jetzt erst greift das Modul auf die Daten des soeben beendeten Zeittages zu (wurde maxSoC erreicht?).
Basierend auf diesem neuen Referenztag wird das Ziel für den neuen Tag B berechnet.
Ergebnis im Log: Target: 50 % (Das Modul hat vermutlich erkannt, dass die Batterie am Tag A voll wurde, und senkt das Ziel für Tag B).
Zusammenfassung
Das Verhalten ist im Code hardcodiert. Der Wechsel der Berechnungsgrundlage findet mathematisch zwingend um 00:00 Uhr statt, da sich erst zu diesem Zeitpunkt das Datum von heute - 24h ändert.
Das Reading Battery_OptimumTargetSoC repräsentiert das Ziel für den kalendarischen Tag. Würde es sich bereits zum Sonnenuntergang ändern, würde das für den Rest des Abends ein falsches Ziel (nämlich das für morgen) anwenden, was ungewollte Regelungen (z.B. Entladestopps) am späten Abend zur Folge haben könnte.
Fazit: Das Verhalten ist technisch korrekt ("Design Intent"), da das Ziel immer für den aktuellen Kalendertag gilt. Dass der Wert um 00:00 springt, ist die direkte Folge des Datumswechsels in der Variable $yday.