Hauptmenü

Neueste Beiträge

#1
DOIF / Aw: Wie gestalte ich die Bedin...
Letzter Beitrag von Marko1976 - 18 Februar 2026, 18:16:00
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.
Das beste Beispiel was ich bisher gefunden habe schrieb:
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.

@Damian
Tut mir leid wenn ich keinen Oeranten "Mudolo" kenne. Ich habe sowas jedenfalls nicht in der Grundschule gelernt und da ich keine Kinder habe habe ich die neumodischen Veränderungen im Schulwesen nicht mitbekommen. Auch kenne ich so einen Operanten weder aus php, noch VB, noch Basic oder einer anderen Programmiersprache die mir geläufig ist.

@betateilchen
Sorry, aber die verlinkte Seite bringt mich überhaupt nicht weiter. Wenn da wenigstens die zu erwartenden Ergebnisse hinter den Rechenoperationen stehen würden, so dass man Rückschlüsse ziehen könnte. aber da steht im Prinzip "9 % 5" - Was soll einem das jetzt sagen wenn man die Funktio nicht kennt?
Deine Erklärung im letzten Post ist das was man braucht, genau wie das was @Per geschrieben hat. Da kann ich was mit anfangen. Dennoch habe ich das Problem wie
($yday % 21 == 0)funktionieren soll.
$yday ergibt 47 (gestern gesehen, damit nicht wieder alles durcheinander kommt), das durch 21 gerechnet ist 2,238... . Also eine Ganzzahl von 2 und einen Rest von 5. Beides stimtmt nicht mit 0 überein, ist also negativ. Es würde rechnerisch nur am 21,., 42., 63. Tag des Jahres etc. aufgehen und true ergeben. Also nicht jede 2., 3., 4. Woche, sondern wenn dann nur an einzelnen Tagen, welcher dann mit dem angegebenen Wochentag in der Uhrzeit übereinstimmen muss. Ansonsten würde die Bedingung nie wahr werden oder habe ich es immer noch nicht verstanden?

Da wäre es ja sinnvoller man läst den Wochentag in der Urhzeit weg und nimmt in Kauf das für die Bedingung die Woche in diesem Jahr zb. von Sonntag-Samstag geht und im kommenden Jahr dann von Montag-Freitag und 2028 von Dienstag-Montag etc..
#2
Sonstige Systeme / Aw: Bresser Wetterstation 868M...
Letzter Beitrag von elektron-bbs - 18 Februar 2026, 17:52:16
OK, das passt.
Deviation ist so etwa 80 kHz:
#3
Hard- und Firmware / Aw: Wie CUL aus CCD2 auf Raspb...
Letzter Beitrag von Beta-User - 18 Februar 2026, 17:41:06
Ziemlich sicher findenst du das im fhem-Wiki (zum Pi), dort unter serielle Geräte.
#4
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von klaus.schauer - 18 Februar 2026, 17:35:25
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:

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.
Das ist hier wie im Wunderland. Kaum hat man einen Wunsch, geht er schon in Erfüllung.

Danke dafür
#5
Hard- und Firmware / Wie CUL aus CCD2 auf Raspberry...
Letzter Beitrag von ToJu - 18 Februar 2026, 17:26:57
Moin.
Nach einem Update (frische Installation von Raspbian GNU/Linux 13 (trixie) auf einem Raspberry Pi Model B Plus Rev 1.2) bekomme ich den "CUL-Anteil" von meinem CCD2 nicht mehr aktiviert. Mit älternen Betriebsystemversionen hat die Anleitung von hier https://busware.de/tiki-index.php?page=CCD2_Installation funktioniert:
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/value

Meine Recherche hat ergeben, dass ich unter Trixie das entsprechend so versuchen sollte:
pinctrl 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 = output

In FHEM (unverändert) konfiguriert mit
defmod CCD2 CUL /dev/ttyAMA0@38400 0000
Das device /dev/ttyAMA0 ist unter /dev aufgeführt (oder ist es immer da?)

Was muss ich noch tun? Wo kann ich den Fehler suchen?

Viele Grüße
Torben

P.S.: Es geht mir nur um den CUL, das Display spielt erstmal keine Rolle.
#6
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Wolle02 - 18 Februar 2026, 17:10:12
Moin Heiko,

ich will dir natürlich Dein Fhem-frei gönnen. Das hast du Dir auch wahrlich redlich verdient. Ist schon toll, was Du hier auf die Beine gestellt hast. Vielen Dank nochmal an der Stelle.

Ich hab aber noch ein kleines Wehweh bei mir mit dem ich etwas rumhadere. Ich glaube wir hatten das Thema auch schonmal kurz angeschnitten, aber ich habe es auch wieder etwas aus den Augen verloren. Ist also nichts systemkritisches.
Es geht um den Zeitpunkt wann der Battery_OptimumTargetSoC_01 bei mir immer aktualisiert wird. Es gab mal eine Zeit da hat das toll funktioniert, so wie ich das aus der Dokumentation und Deinen Erläuterungen im Hinterkopf hatte. Nämlich, dass der Battery_OptimumTargetSoC_01 zum Ende eines jeden Sonnentages aktualisiert wird, je nach Prognose des zu erwartenden Solarertrages, um Platz in der Batterie für die Aufnahme zu schaffen, und/oder je nach dem wie die Einstellungen für low, up und maxSOC gewählt sind und ob der BatterieSOC im Laufe des Tages maxSOC erreicht hat oder nicht (jeweils In- oder Decrementierung um 5%).
Das hatte alles gut funktioniert und am Ende des Sonnentages wurde bei mir Battery_OptimumTargetSoC_01 neu eingestellt.

Seit einer gewissen Zeit funktioniert das leider gar nicht mehr zuverlässig am Ende eines Sonnentages, sondern hin und wieder unregelmäßig, aber hauptsächlich findet die Aktualisierung nachts um 00:00 Uhr statt. Das ist blöd, weil die Batterie dann manchmal schon zu weit entladen wurde und es dadurch bei mir zu Zwangsladungen kommt.
Ich habe heute Nacht mal ein Debug laufen lassen. Hier ist das Ergebnis (ich habe das Log als Dokument hochgeladen, weil sonst das Forum streikt)


Kannst du da eventuell mal drüber schauen, ob Du hier einen Grund erkennst warum das so ist?

Ich habe auch mal die KI befragt und sie gab mir als Ergebnis folgendes mit auf den Weg:

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.

Vielen Dank für Deine Mühe.

Gruß
Wolle
#7
Heizungssteuerung/Raumklima / Aw: LAN-Anbindung für BSB-Bus ...
Letzter Beitrag von W.hatever - 18 Februar 2026, 17:07:22
Tach
Zum Thema takten habe ich meine Einstellungen soweit heruntergeschraubt, das der Brenner nie auf den sollwert kommt und immer ~2 Grad hinterherheizt. Sobald er nämlich den sollwert erreicht, würde er abschalten.
Das geht natürlich nur, wenn der Brenner weit genug runter moduliert.
Evtl ist das ja mal eine andere Sichtweise dazu.
#8
Bastelecke / Aw: Entwicklung SIGNALduinoAdv...
Letzter Beitrag von DerD - 18 Februar 2026, 17:07:04
Hier nun die Version mit Modul und Breakouts, Pin6/7 habe ich mit GND auf eine Stiftleiste raus gezogen. Die Layouts der Module nach einfügen manuell nachgebseert. Viel Luft ist bei Standardeinstellungen und 0,25mm Leiterbahnen aber nicht mehr. Bin aber auch nicht Kicad Experte, und lerne bei jedem Punkt dazu.

Was die Adapterplatinen angeht: die haben zwar Durchkontaktierungen auf die Unterseite, diese sollten aber mit Lötstopp abgedeckt und damit isoliert sein. Falls doch ein Risiko zu den Lötaugen der Module besteht, würde ich überkleben mit Isolierband vorschlagen. Umgekehrt, also bestücken mit MMs besteht aus meiner Sicht gar kein Risiko.

Eine Frage noch: das LAN Modul würde ich von unten her anlöten, nicht oben drauf wie üblich. Gibt es da Bedenken?

Dann würde ich nämlich dann die Boardbestellung abschicken. Ich habe noch nie boards so bestellt, daher bin ich mir sicher dass irgendetwas bestimmt nicht 100%ig passt, trotz erfolgreichem DRC. Also Nachsicht damit.

Edit: bisher heißt das Teil Pico_sDuino. Bessere Vorschläge?
#9
FHEM Code changes / Revision 30869: 76_SolarForeca...
Letzter Beitrag von System - 18 Februar 2026, 16:40:46
Revision 30869: 76_SolarForecast: contrib version 2.2.0

76_SolarForecast: contrib version 2.2.0

Source: Revision 30869: 76_SolarForecast: contrib version 2.2.0
#10
FHEM Code changes / Revision 30868: 76_SolarForeca...
Letzter Beitrag von System - 18 Februar 2026, 16:40:46
Revision 30868: 76_SolarForecast: contrib version 2.2.0

76_SolarForecast: contrib version 2.2.0

Source: Revision 30868: 76_SolarForecast: contrib version 2.2.0