Neueste Beiträge

#1
Frontends / Aw: eCharts in FHEM (Version 0...
Letzter Beitrag von Luc115 - 13 Mai 2025, 00:08:02
Hallo Andies,

Ich habe noch eine einfache Ergänzung, nämlich plotreplace.
plotReplace:textField-long in Zeile 1164 (eCharts_Initialize @attrList) hinzufügen, ist ausreichend.
Die Funktionalität wird im Aufruf von SVG_readgplotfile verarbeitet.

Gruß Luc
#2
Frontends / Aw: eCharts in FHEM (Version 0...
Letzter Beitrag von Luc115 - 12 Mai 2025, 23:46:08
Nabend,

Ich verwende dynamische Plotbereiche über fixedrange {sprintf("......")}. Dies wird in eCharts aber nicht ausgewertet.
in 98_SVG.pm geht das uber:
$fr = AnalyzePerlCommand(undef,$1) if($fr && $fr =~ m/^{(.*)}$/); #137800Kannst du diese auswertung bitte hinzufugen in eCharts (0.0.12.5) zeile 123

Danke, Luc
#3
Sonstige Systeme / Aw: Entwicklungs-Thread Modul ...
Letzter Beitrag von Starkstrombastler - 12 Mai 2025, 23:44:15
Zitat von: piet_pit am 12 Mai 2025, 11:34:43ich nutze ja aktuell den Shelly Pro 2 Cover, leider hat der das Feature "XtraChannels" nicht, zumindest finde ich das nicht.
Das ist nicht drin, weil ich kein Device zum Testen habe.
Allerdings werden mit xtrachannels auch nur readingsProxy Devices angelegt, das ist an sich nichts modulspezifisches.

Vorschläge schaue ich mir aber gerne an.
#4
Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...
Letzter Beitrag von Starkstrombastler - 12 Mai 2025, 23:40:58
Zitat von: cotecmania am 12 Mai 2025, 12:58:55- Beim Shelly Pro 3em kann man doch die Werte über die Webpage löschen. Ist versteckt in den Settings der Werteanzeige.
- Danach sind alle Werte auch im FHEM-Device genullt bis auf die 3 mit "_T" am Ende.
  Also werden diese wohl vom FHEM-Modul verwaltet
- Ein deletereading auf .*_T bringt nichts, die Werte erscheinen wieder mit dem selben Wert wie vorher.

Die Werte mit dem "S" sind die Energy-Werte, die der Shelly liefert. Das kannst du prüfen, indem du im Browser die Abfrage direkt an den Shelly richtest:
http://<ip-des-Shelly/rpc/EMData.GetStatus?id=0Der Shelly liefert die Werte in Wh.

Die Werte mit dem "T" werden vom Modul berechnet und sollen schnelle Änderungen zwischen Bezug und Einspeisung dann berücksichtigen, wenn der Inkrementalwert des offiziellen Zählers noch nicht erreicht ist. Das sollte aber bei einem Ferrariszähler ohne Bedeutung sein.

Daher schlage ich vor, dass du diese Berechnung ausschaltest:
attr <name> Balancing 0Allerdings (das ist im Moment noch ein kleiner Bug) musst du dafür das Intervall-Attribut vorübergehend auf 20 sec oder kleiner stellen.

Merkwürdig ist allerdings der Wert für Total_Energy_S nach Änderung des Showunits-Attributes. Das passiert bei mir im System so nicht.
Das bitte wie oben beschrieben mit dem Shelly vergleichen.

#5
FHEM Code changes / Revision 29948: 76_SolarForeca...
Letzter Beitrag von System - 12 Mai 2025, 23:20:52
Revision 29948: 76_SolarForecast: Version 1.52.0

76_SolarForecast: Version 1.52.0

Source: Revision 29948: 76_SolarForecast: Version 1.52.0
#6
Bastelecke / Aw: Entwicklung SIGNALDuino Em...
Letzter Beitrag von johnyli - 12 Mai 2025, 23:16:20
Hallo Ralf,
ich muss mich leider korrigieren. Auch in unmittelnbarer Nähe zum Access-Point (ca. 20 cm) kann ich den ESP nach ca. 1 1/2 Tgen nicht mehr erreichen.
#7
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 12 Mai 2025, 23:05:36
@all,

die V 1.52.0 ist eingecheckt und wird morgen im Update enthalten sein.
#8
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 12 Mai 2025, 22:33:17
Hallo Kai,

ich sehe bei dir keinen Fehler und habe deswegen bei mir zwei Instanzen nachgestellt.

Nordlage:

     2025-05-12 22:23:31   Tomorrow_PVforecast 38161 Wh
     2025-05-12 22:23:31   Tomorrow_SunRise 05:24
     2025-05-12 22:23:31   Tomorrow_SunSet 20:52
     2025-05-12 22:23:31   nextCycletime   22:24:06
     2025-05-12 22:23:32   state           updated
Attributes:
   alias      DWD Nordlage
   ctrlDebug  none
   event-on-change-reading .*
   graphicBeam1Color FF3636
   graphicHeaderOwnspec Autokorrektur:pvCorrectionFactor_Auto
Debug:ctrlDebug
   graphicHistoryHour 5
   graphicShowNight 0
   plantControl consForecastInPlanning=0
backupFilesKeep=3
cycleInterval=35
genPVdeviation=daily
   room       Energie->SolarVergleich
   setupInverterDev01 STP_5000 pv=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1 limit=100
   setupInverterStrings Süddach
   setupMeterDev SMA_Energymeter gcon=bezW:W contotal=bezWZ:kWh gfeedin=einW:W feedtotal=einWZ:kWh conprice=0.2958:€ feedprice=0.1269:€
   setupRadiationAPI DWD.Solar.N5872
   setupStringAzimuth Süddach=N
   setupStringDeclination Süddach=45
   setupStringPeak Süddach=5.0
   setupWeatherDev1 DWD.Solar.N5872
   verbose    2

Südlage:

     2025-05-12 22:26:44   Tomorrow_PVforecast 43323 Wh
     2025-05-12 22:26:44   Tomorrow_SunRise 05:24
     2025-05-12 22:26:44   Tomorrow_SunSet 20:52
     2025-05-12 22:26:44   nextCycletime   22:27:19
     2025-05-12 22:26:45   state           updated
Attributes:
   alias      DWD Südlage
   ctrlDebug  none
   event-on-change-reading .*
   graphicBeam1Color FF3636
   graphicHeaderOwnspec Autokorrektur:pvCorrectionFactor_Auto
Debug:ctrlDebug
   graphicHistoryHour 5
   graphicShowNight 0
   plantControl consForecastInPlanning=0
backupFilesKeep=3
cycleInterval=35
genPVdeviation=daily
   room       Energie->SolarVergleich
   setupInverterDev01 STP_5000 pv=total_pac:kW etotal=etotal:kWh capacity=5000 strings=Süddach asynchron=1
   setupInverterStrings Süddach
   setupMeterDev SMA_Energymeter gcon=bezW:W contotal=bezWZ:kWh gfeedin=einW:W feedtotal=einWZ:kWh conprice=0.2958:€ feedprice=0.1269:€
   setupRadiationAPI DWD.Solar.N5872
   setupStringAzimuth Süddach=S
   setupStringDeclination Süddach=45
   setupStringPeak Süddach=5.0
   setupWeatherDev1 DWD.Solar.N5872
   verbose    2

Die beiden Instanzen sind bis auf die Ausrichtung identisch. Die Vorhersage für morgen (Tomorrow_PVforecast) erwartungsgemäß für Südlage höher (43323 Wh) als für Nordlage (38161 Wh). Alles ohne Korrekturfaktoren.
Die Grafiken zeigen auch entsprechende Ergebnisse.

Ich kann dir jetzt keine Erklärung für dein Ergebnis geben. Ich gehe davon aus, dass du die aktuellste Version benutzt?

EDIT: Du darfst für diesen Vergleich die Autokorrektur nicht setzen oder musst sie auf "off" schalten.

Grüße,
Heiko
#9
Kalendermodule / Aw: [gelöst] Calender - Wakeup...
Letzter Beitrag von bommel-bs - 12 Mai 2025, 21:52:43
Hallo betateilchen,

der Tipp mit den cutoffOlderThan war gut. Jetzt kommt man nicht mehr durcheinander.
#10
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Univega06 - 12 Mai 2025, 21:49:03
Zitat von: 300P am 12 Mai 2025, 21:25:00Alte PV-Weisheit:
String-Nordausrichtung gibt im Sommer immer weniger Ertrag gegenüber der gleichen Anlage mit einer String-Südausrichtung. ;)
Im Winter kann es für die beiden Strings im Ertrag "gleichartiger" sein  / werden. :o

Gruß
300P

:o Soweit war ich auch schon, daher je die Feststellung das etwas nicht passt  ;)

Zitat von: 300P am 12 Mai 2025, 21:39:59
Zitat von: Univega06 am 12 Mai 2025, 21:18:55Wieso ist der Forecast für Nord höher als für Süd? Habe ich eine Fehler eingebaut? Gibt es Erfahrungen mit Anlagen, die nach Norden ausgerichtet sind?


Neben meiner Weisheiten  O:-)
- Warum / bzw. gibt es einen besonderen Grund warum :
1 x setupStringAzimuth ==>>> Sued=0  (statt beide mit dem Eintrag "S" und "N"  ? )
1 x setupStringAzimuth ==>>> Nord=N  (oder statt beide mit dem Eintrag "-180" unten "0" oben ?)

Das wäre das einzige was mir an Unterschieden dabei auffällt - die DWD-Daten sind ja gleich gewählt.

Gruß
300P


Das kommt nur vom Probieren, ob einen Unterschied macht --> Macht es aber nicht

Danke und Grüße
Kai