Neueste Beiträge

#1

Automatisierung / Aw: DBLog, eine oder mehrere ...

Letzter Beitrag von rabehd - 07 April 2026, 15:13:48

Ich nutze nur eine DB.
Dafür werden jeden Tag jeweils verschiedene Ausdünn- und Löschaktionen ausgeführt.

#2

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 07 April 2026, 14:53:27

Hallo Wolle02,

Hier ist immer von der Syntax <Reading>:<Regex> oder <Reading>:<Einheit> die Rede. Müssen hier die Readings tatsächlich im SF-Device vorhanden sein oder wäre hier eher <Device>:<Reading>:<Regex> usw. richtig?

Nein, nicht im SF-Device. Es wird davon ausgegangen, dass diese Readings im Consumer-Device, also typischerweise der Wallbox vorhanden sind. Das sollte ich wahrscheinlich in der Hilfe notieren.
Sollten andere Devices notwendig werden, müsste ich diese Möglichkeit erst noch vorsehen.

#3

FHEMWEB / Aw: Keine Aktualisierung Statu...

Letzter Beitrag von vniklas - 07 April 2026, 14:49:24

Ich probiere erstmal, wenn ich nicht weiterkomme melde ich mich, danke

#4

Automatisierung / Aw: DBLog, eine oder mehrere ...

Letzter Beitrag von betateilchen - 07 April 2026, 14:42:53

Weiterhin nutze ich eine DB für Werte die nur ein paar Wochen aufbewahrt und dann gelöscht werden. Ein weitere DB ist für die Langzeitspeicherung von Werten die mir wichtig sind.

Eine solche Aufteilung in Kurzzeit- und Langzeitspeicherung hat sich bei mir auch seit ein paar Jahren gut bewährt. Kurzzeit bedeutet bei mir drei Tage, länger werden dabei keine Daten gespeichert.

Die Langzeitspeicherung benutze ich hauptsächlich, um "historische" SVG plots erzeugen zu können. Dazu werden monatlich die Werte sinnvoll ausgedünnt. Dieses DbLog device wird von meiner produktiven FHEM-Instanz beschrieben, die historischen SVG werden aber von einer anderen FHEM Instanz erzeugt, die nur lesend auf die Datenbank zugreift und selbst keine Werte in die DB schreibt.

[NUR]

#5

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Wolle02 - 07 April 2026, 14:26:27

Es ist schon wieder eine ganze Menge geworden und es sind auch recht bedeutende Dinge dabei. Ich halte es für sinnvoll die Version einzuchecken, sie enthält:

- neuer Schlüssel plantControl->consForecastBase
- Einbindung des String Inverter Mapping check in den Konfigurationscheck
- Konfigurationscheck prüft con in aiRawData
- veränderte Berechnung und Darstellung von weiteren KI Drift Parametern
- comforttemp wird automatisch in plantControl verschoben
- BugFix in reductionState  -> Forum https://forum.fhem.de/index.php?msg=1360810
- neuer Schlüssel aiControl->aiConAbsOversample
- Einbindung von BEV-Consumern (aktuell NUR Datensammlung und Speicherung)
- Härtung der Anzeigefunktion von pvHistory
- Speicherung neuer BEV-Werte in pvHistory & aiRawData
- Bugfix in Legacy Vorhersage für den kommenden Tag -> Forum: https://forum.fhem.de/index.php?msg=1361272
- Bearbeitung der CommandReferenz
- kleine Änderungen im Grafikheader (Benennung CON und Verwendung von aktuellen Umgebungswerten statt gegättete Werte) 

Moin Heiko,

danke für das neue Release. Bislang hatte ich meine Wallbox als Consumer eingebunden; ich würde diesen Consumer nun einfach durch den neuen BEV-Consumer ersetzen. Eine Frage zur Hilfe. Hier steht:

evid   Der Schlüsselwert identifiziert ein angeschlossenes Elektrofahrzeug eindeutig.
<Reading>:<Regex> - Der angegebene reguläre Ausdruck wird auf den Readingswert angewendet. Passt der Ausdruck, wird der
  Consumer in SolarForecast aktiviert.
batCap   Gibt die nominale Batteriekapazität an. Die Angabe kann erfolgen durch:
Ganzzahl: 0..X - die Batteriekapaziät in Wh ohne Angabe der Einheit
<Reading>:<Einheit> - Reading welches die Kapazität liefert und die Einheit der Wertes (Wh, kWh)
etotal   Der Schlüssel ist eine Pflichtangabe mit der oben angegebenen Syntax. Der Wert ist die gesamte verbrauchte Ladeenergie.
pcurr   Der Schlüssel ist eine Pflichtangabe mit der oben angegebenen Syntax. Der Wert ist die aktuelle Ladeleistung.
power   Maximale Ladeleistung des Fahrzeugs bzw. der Wallbox mit der oben definierten Syntax.
currSoC   <Reading> - Reading des Devices welches den aktuellen Batterie-SoC des Fahrzeugs in % liefert.
   Das Reading muß einen Wert im Bereich 0 < X <= 100 liefern.
targetSoC   Optionale Angabe des Ziel-SoC für die Ladesession. Die Angabe kann alternativ festgelegt werden durch:
Ganzzahl: 0..100 - der Ziel-SoC in % als feste Einstellung (default: 80)
<Reading> - Reading welches den Ziel-SoC in (0..100 %) liefert.

Hier ist immer von der Syntax <Reading>:<Regex> oder <Reading>:<Einheit> die Rede. Müssen hier die Readings tatsächlich im SF-Device vorhanden sein oder wäre hier eher <Device>:<Reading>:<Regex> usw. richtig?

#6

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von grappa24 - 07 April 2026, 11:52:30

Code Auswählen Erweitern

consumer07  name='Formentor' state='on' mode='mustNot' planningstate='noSchedule' info='von extern umgeschaltet'
consumer07_currentPower   3477.49 WInteressante info zum BEV consumer

[Revision 31090: 76_SolarForecast: contrib Version 2.5.2]

#7

FHEM Code changes / Revision 31090: 76_SolarForeca...

Letzter Beitrag von System - 07 April 2026, 11:40:19

Revision 31090: 76_SolarForecast: contrib Version 2.5.2

76_SolarForecast: contrib Version 2.5.2

Source: Revision 31090: 76_SolarForecast: contrib Version 2.5.2

#8

TabletUI / Aw: [FTUI 3] Charts

Letzter Beitrag von cotecmania - 07 April 2026, 11:39:24

Kann man in FTUI3-Chart die Achsenbeschriftungen ausblenden ?

Habs selbst gefunden : no-x und no-y

#9

Wunschliste / Aw: Casambi - API-Integration

Letzter Beitrag von pkr - 07 April 2026, 11:26:34

Hallo zusammen,

Ich habe mich dessen mal angenommen (basierend auf einer Implementierung von lian).
Schaut mal unter github.com/akumap/esp32-casambi, das basiert auf einer günstigen ESP32-Gateway-Hardware.

Die Konfiguration muss einmalig aus der Cloud heruntergeladen werden, danach ist alles offline (und schnell .

#10

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 07 April 2026, 10:40:48

Ich werde eine Zeitsperre für die Meldungen einbauen, dass sie nur alle X Minuten kommen falls die Situation auftritt.

Habe ich gemacht und als V2.5.2 ins contrib geladen wenn die aktuelle OpenMeteo Situation nerven sollte. Alternativ das SF auf verbose 0 temporär stellen.