Hauptmenü

Neueste Beiträge

#1
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von moskito - 30 März 2026, 00:17:25
@denis.robel
Es ist - wie so oft - eine Frage der Perspektive, was rein oder raus ist.  :)

packInputPower int RO W Battery discharge power
outputPackPower int RO W Battery charge power
outputHomePower int RO W Output to home

Alle Werte sind hier zu finden: https://github.com/Zendure/zenSDK/blob/main/docs/en_properties.md

Gruß
Danny
#2
Solaranlagen / Aw: {gelöst] SolarForecast - P...
Letzter Beitrag von grappa24 - 29 März 2026, 23:42:45
noch ein joke am Rande:

nachdem ich nun evccc mit dem jsonReading zwecks Erstellung der PV-Vorhersage gefüttert hatte, hat es sich evcc nicht nehmen lassen, jeden einzelnen Wert (start, end, value) via MQTT zu veröffentlichen und in FHEM letztlich als Reading anzulegen.
Mehr noch, insgesamt hat mir evcc auf diesem Weg über 1000 (Tausend) Readings angelegt  ::) und mir mein FHEM lahmgelegt.

Ich hab dann das komplette MQTT-evcc Device gelöscht und mit nur den benötigten Readings neu angelegt, autocreate auf 0 gesetzt und event-on-change-reading benutzt. Plötzlich war Ruhe im Karton.
#3
Solaranlagen / Aw: {gelöst] SolarForecast - P...
Letzter Beitrag von grappa24 - 29 März 2026, 23:25:44
genau der Tipp hat mir noch gefehlt ;)
#4
Solaranlagen / Aw: {gelöst] SolarForecast - P...
Letzter Beitrag von DS_Starter - 29 März 2026, 23:16:43
Noch ein Tipp ...
wenn euch der Inhalt des userReadings zu viel wird und deswegen die Ansicht des Device zu unübersichtlich, könnt ihr auch ein versteckes Reading verwenden.
Das geht mit einem "." vor dem Readingnamen, also so:

userReadings  .jsonReading:nextCycletime.* { main::forecast_json($NAME) }

Das Reading ist normal vorhanden, aber in der Detailansicht nicht aufgeführt. Mit einem "list" sieht man den Inhalt. Beim Abruf ist natürlich auch ".jsonReading" zu verwenden.
#5
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 29 März 2026, 23:02:11
@all,

folgende Problematik habe ich festgestellt.
Wie viele von euch auch habe ich ein gutes Modell (eigentlich mehrere) für die Verbrauchsvorhersage trainiert. In diesem Modell (ca. 1 Jahr Daten) ist die Anwesenheit (Digit 0|1) enthalten, wobei nur wenige Tage  Anwesenheit=0 (ca. 10-15) in den Trainingsdaten vorhanden sind, sonst Anwesenheit=1.

Nun war ich 2 Tage weg und somit die aktuelle Anwesenheit=0. Die Verbrauchsprognose ist während dieser Zeit sehr deutlich! zu hoch ausgefallen. Sobald ich wieder zu Hause war und somit Anwesenheit=1 wurde die Prognose wieder sehr gut.

Ich bin die Thematik mit meiner LLM durchgegangen und das Kernproblem ist fast sicher ein Klassenungleichgewicht – das Modell hat schlicht nicht genug ,,gelernt, was Abwesenheit bedeutet", was wohl ein klassisches Problem mit unbalancierten Klassen ist. Das ändert sich natürlich sobald mehr Daten für Abwesenheit gesammelt sind.
Aber ich wollte euch das mitteilen falls ihr bei euch änliches Verhalten feststellt.

Ich werde mir Gedanken machen ob/wie ich dieser Problematik im Code begegnen kann, z.B. durch Presence-gewichtete Lag-Features.
#6
Solaranlagen / Aw: {gelöst] SolarForecast - P...
Letzter Beitrag von grappa24 - 29 März 2026, 22:54:28
@Dieter: Schön, dass es jetzt läuft
@Heiko: Danke für die Arbeit am wiki und insb. für die "Normierung"

Nach einem Tag Arbeit und Recherche an diesem "doofen" evcc Template war ich so froh, dass ich diesen blöden Fehler (.power anstatt .value) gefunden hatte, dass ich nicht mehr an die Abstrahierung des Codes gedacht habe - obwohl, ein wenig Transferleistung hat ja noch niemandem geschadet.  ;)
Wir haben uns viel zu sehr daran gewöhnt, schlüsselfertige Lösungen zu übernehmen ohne sie zu verstehen und zu hinterfragen. Das ist eine Erfahrung, die ich insb. auch im Umgang mit KI gemacht habe.
#7
SVG / Plots / logProxy / Aw: Im SVG ist die Achse recht...
Letzter Beitrag von Homalix99 - 29 März 2026, 22:43:43
Hallo Rudi,

am nächsten Tag wurden die einlaufenden Daten korrekt angezeigt. Falls das Verhalten erneut auftreten sollte (wovon ich nicht ausgehe) werden ich die entsprechenden Indizien liefern.
Vielen Dank erst mal.
#8
Multimedia / Aw: Squeezebox Modul - erste V...
Letzter Beitrag von ChrisD - 29 März 2026, 22:10:29
Hallo,

Du kannst die Module mit dem FHEM-Befehl
update add https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/sb/controls_squeezebox.txtautomatisch mit FHEM aktualisieren lassen.

Grüße,

ChrisD
#9
Bastelecke / Aw: Entwicklung SIGNALduinoAdv...
Letzter Beitrag von Ralf9 - 29 März 2026, 22:07:11
Mir ist nicht klar was bei Dir bei der USB Version nicht passt.
Da gibts mehrere Möglichkeiten: Störungen, etwas am raspi pico oder am Rechner wo der raspi pico mit usb verbunden ist.
Bei mir läufts problemlos mit 2 verschiedenen Raspi Pico und bei @tndx funktionierts auch.
Hast Du den pico sduino auch mal am Windows PC mit einem seriellen Monitor, z.B. der Arduino IDE, getestet?
Hast Du mal versucht ob die Steckdosen Fernbedienung vom sduino erkannt wird?

Wenn bei 868 MHz das FSK Protokoll bei https://github.com/merbanan/rtl_433 nicht bekannt ist, wirds schwierig.
Außer der Frequenz müssen auch noch Datarate, DEVIATN und sync passen.
Die Datenrate ist der Kehrwert von der Datenbitlänge
Der Frequenzhub (DEVIATN) ist  (obere Frequenz - untere Frequenz) / 2
https://forum.fhem.de/index.php?topic=106594.msg1148604#msg1148604
siehe auch hier
https://forum.fhem.de/index.php?topic=78809.msg1358006#msg1358006

Ich habe jetzt auch das Lan Modul in die Platine eingelötet. Ich habe alles über Buchsenleisten steckbar gemacht.
Es hat auf Anhieb problemlos funktioniert.
Es muss die rote Betriebsled leuchten, wenn das Lan Kabel gesteckt ist, muss die grüne LED leuchten und die gelbe blinken.
Das Lan kabel muss am Anfang schon gesteckt sein.
Wenns über DHCP nicht funktioniert, kann auch die USB Firmware geflasht werden und dort mit Wi die IP Addresse geändert werden.
#10
Verbrauchsmessung / Aw: HTTPMOD: Aktueller Strompr...
Letzter Beitrag von f_sieler - 29 März 2026, 21:47:02
Ich bin seit 6/2023 Tibber-Kunde und werde schon sehr lange erst stündlich und nun viertelstündlich abgerechnet.
Sicher, es gab Ausfälle bei der Datenübermittlung die aber nie länger als zwei Stunden waren.
Die 22,19 Cent/kWh errechnet Tibber sicher am Monatsende aus dem Gesamtpreis und dem Verbrauch.
Ich muss erst noch beobachten wie gross die Abweichung zum Preis in der Tibber-App ist.