Neueste Beiträge

#1

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 10 Dezember 2025, 09:17:44

Dessen Werte korrelieren sehr gut mit der (momentanen) PV-Leistung

Ja, das glaube ich dir und das sieht man auch.

Das Problem ist, dass die gemessenen Werte ein Pendant in der Vorhersage brauchen um damit direkt einen Korrekturfaktor ableiten zu können.
Also:

Gemessen Lumen -> Vorhersage in Lumen  -> führt zu einem Korrekturfaktor X bei sonst gleichen! weiteren Bedingungen (Bewölkung etc.).

Gemessen rad1h -> Vorhersage in rad1h  -> führt zu einem Korrekturfaktor X bei sonst gleichen! weiteren Bedingungen (Bewölkung etc.).

Da diese Gegebenheiten (auch rad1h) nicht gemessen, sondern nur vorhergesagt werden, ergibt sich diese Vorgehensweise:

Vorhersage in rad1h X + Vorhersage von Rahmenbedingungen (Bewölkung etc.) -> Vorhersage PV in Wh/h  -> gemessen PV in Wh/h  -> führt zu Korrekturfaktor der bei der nächsten Vorhersage von rad1h X mit gleichen/sehr ähnlichen Rahmenbedingungen angewendet wird.

Umgesetzt / unterstützt durch einen Strahlungs-/Helligkeitssensor würde es sich so darstellen:

Vorhersage in Lumen X + Vorhersage von Rahmenbedingungen (rad1h, Bewölkung etc.) -> Vorhersage PV in Wh/h  -> gemessen PV in Wh/h  -> führt zu Korrekturfaktor der bei der nächsten Vorhersage von Lumen X mit gleichen/sehr ähnlichen Rahmenbedingungen (rad1h, Bewölkung etc.) angewendet wird.

Dadurch ergibt sich die Notwendigkeit eine Vorhersage in Lumen für die kommenden Stunden zu haben, was nicht gegeben ist.

Diesen Zusammnhang gibt es auch bei Verwendung eines neuronalen Netzes. Wenn man die KI mit dem gemessenen Lumen-Wert im Training füttert (was als gemessener Wert sehr sinnvoll ist), benötigt man für die Abfrage des trainierten Modells zur Prognose ebenfalls einen Eingangswert Lumen für die abgefragte Stunde. Der steht aber nicht zur Verfügung, maximal als irgendwie geartete Umrechnung des prognostizierten rad1h falls man das überhaupt umrechnen kann. Dann kann man aber auch gleich rad1h benutzen wie es aktuell getan wird ODER man hat einen Strahlungsmesser der die Solarstrahlung misst und man diese gemessenen Werte beim KI Trainung verwendet. Dann macht es wieder Sinn.

Abgesehen von der ganzen Betrachtung haben die Ungenauigkeite bei der Bewölkungsprognose deutlich mehr Einfluß auf das Ergebnis als andere Faktoren. Eine einzige größere Wolke am sonst wolkenlosen Himmel kann die Stundenprognose zerstören wenn deren Schatten genau auf die kleine Solarfläche von 10 x 10 Meter fällt. Wir sind schon ein wenig vermessen in einem solchen Mikrokosmos Stundenprognosen aufzustellen ... klappt aber irgendwie doch ganz gut über weite Strecken. 

LG,
Heiko

#2

FHEM Development / Aw: Keine commits mehr unter F...

Letzter Beitrag von Otto123 - 10 Dezember 2025, 08:48:34

@Sidey nein brauchst Du nicht. Dein Workflow wird keine nennenswerte Last verursachen.

Gestern 19:00 Uhr und 20:00 gab es noch zwei kurze Lastwellen. Seit dem ist wieder Stille eingekehrt.

#3

FHEM Development / Aw: Keine commits mehr unter F...

Letzter Beitrag von Sidey - 10 Dezember 2025, 08:32:22

Aber ob Du derzeit eine Fehlerfreie Runde drehen kannst, kann ich nicht vorhersagen. Die Belastung ist derzeit nicht von Dauer sondern eher in Impulsen. welche IP initiert das?

Ja, hat dann gestern Abend wieder funktioniert. Es waren ja auch nur 8 commits oder so um den dreh

Die IP Adresse kenne ich leider nicht. Wenn der Workflow startet, dann wird eine Azure VM mit dem Job beauftragt. Die läuft dann maximal 1 Stunde.
Beim nächsten Lauf, wird dann eine andere VM beauftragt, da ich glaube dass die VM nach dem Job zerstört wird.
Wenn es aber weiterhilft, kann ich in den Job eine Abfrage für die Adresse einbauen.

Grüße Sidey

#4

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von TheTrumpeter - 10 Dezember 2025, 06:46:40

Hättest du denn einen Strahlungsmesser für jeden String angebaut und in FHEM integriert?

Helligkeitssensor.

Dessen Werte korrelieren sehr gut mit der (momentanen) PV-Leistung, siehe Beispiele im Anhang. Ich habe wahllos ein paar Tage in der Vergangenheit aufgerufen.

Die Prognose der Strahlung würde wieder aus Rad1h, d.h. dem Wettrdienst, kommen. Ob der Recht hat, wissen wir im Vorfeld natürlich nicht.

Natürlich nicht. Aber im Nachhinein schon, falls entsprechende Sensoren vorhanden sind. Damit könnte man zumindest sicherstellen, dass die Lernwerte richtig zugeordnet werden.
Wenn die Prognose am nächsten Tag wieder falsche Rad1h Werte liefert, stimmt das IST natürlich nicht, aber falls die Werte passen, werden sie mit den dazupassenden Korrekturfaktoren angereichert und die Prognose sollte somit auch gut sein.

#5

FHEM Development / Aw: Keine commits mehr unter F...

Letzter Beitrag von Otto123 - 10 Dezember 2025, 00:37:49

ich habe jetzt noch den Chrome User Agenten 125.x.x.x und leere Agenten (die wohl bots gerne setzen) im proxy nur für svn.fhem.de geblockt.

Chrome 125 hatte heute mit 2,7 Mio Hits die Spitze.

Ich hoffe das keine Nebeneffekte. Eigentlich wollte ich heute was vernünftiges machen

#6

Anfängerfragen / Aw: qx als als sudo benötigt p...

Letzter Beitrag von Otto123 - 09 Dezember 2025, 22:56:22

was zeigt Dir in der "Docker Console" denn whoami ? Wenn da root steht ist dein Versuch mit sudo witzlos

Damit das mit dem User fhem funktioniert musst Du es so machen wie hier beschrieben.
Was genau ist da unklar?
In der "Docker Console" ungetestet, hast Du so probiert?

Code Auswählen Erweitern

File="011_fhem-nopasswd"
echo "fhem ALL=(ALL) NOPASSWD: /opt/fhem/FHEM/fhem_backup_pi.sh" >/etc/sudoers.d/$File
chmod 0440 /etc/sudoers.d/$File
Ich halte es nach wie vor für Unfug, sowohl sudo für mount und auch das Script im docker. Sowas macht man mMn außerhalb.

[Revision 30609: 59_ECOWITT_GW.pm: read weather sensor data from ECOWITT gateways]

#7

FHEM Code changes / Revision 30609: 59_ECOWITT_GW....

Letzter Beitrag von System - 09 Dezember 2025, 22:01:04

Revision 30609: 59_ECOWITT_GW.pm: read weather sensor data from ECOWITT gateways

59_ECOWITT_GW.pm: read weather sensor data from ECOWITT gateways

Source: Revision 30609: 59_ECOWITT_GW.pm: read weather sensor data from ECOWITT gateways

#8

Sonstige Systeme / Aw: Entwicklungs-Thread Modul ...

Letzter Beitrag von derHeimwerker - 09 Dezember 2025, 21:56:37

Ich schaue mir gerne ein fertig konfiguriertes Readings-Proxy Device für den Shelly-Dimmer an und übernehme dann für den xtrachannels - Befehl.

Wie kann ich da unterstützen?

#9

fronthem / smartVISU / Aw: Smartvisu V3.2.2 -> V3.5 U...

Letzter Beitrag von wvhn - 09 Dezember 2025, 21:33:12

Gemeint sind die Menüeinträge im Raummenü (rooms_menu.html oder navigaton.html - je nachdem, wie Du die Datei genannt hast). Wenn hier in den <a>-tags der Zusatz `data-ajax="false"` steht, dann zwingst Du die Visu dazu, jede Seite komplett neu zu laden, einschließlich Neustart des Websocket. Wenn der Websocket eh schon Probleme macht, verschlimmert das das Verhalten.
Also die `data-ajax="false"`einfach löschen, sofern vorhanden.

Das wird das Problem zwar entschärfen, aber nicht grundsätzlich lösen. Gelöst werden kann das nur durch ein iOS-Update, das den Fehler korrigiert.

Gruß
Wolfram

#10

Sonstiges / Aw: Ecowitt API - diverse Wett...

Letzter Beitrag von Dr. Boris Neubert - 09 Dezember 2025, 21:19:08

Hallo,

ich habe das Modul als 59_ECOWITT_GW.pm eingespielt (das API fand ich nicht passend, viele andere Module nutzen auch ein API und nennen das nicht im Modulnamen).

Habe noch zwei Perl-Fehler rausgemacht, und updateInterval umbenannt.

Jetzt ist es also offiziell.

Die anderen Vorschläge arbeite ich nach und nach ein.

Viele Grüße
Boris