76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[TheTrumpeter]

irgendwo weiter vorn kam mal der Verdacht auf, im Modul gibt es ein Memory Leak. Wir (kask/ich) konnten es nicht nachvollziehen was nicht heißen soll dass evtl. bei einer bestimmsten Konfiguration soetwas nicht vorkommen kann.

Das habe ich wohl mal aufgebracht bzw. hinterfragt ob es eventuell so sein könnte. Mittlerweile bin ich durch Zufall einen Schritt weiter und habe fhempy_local als Ursache ausgemacht.

(Wie bin ich draufgekommen: Bei/nach einem "update" wird fhempy_local automatisch neu gestartet. Ich habe einmal nach einem Update, wo keine von mir genutzten Module aktualisiert wurden, vergessen "shutdown restart" zu machen und habe dann zufällig gesehen, dass die RAM-Auslastung nach dem "update" drastisch nach unten ging. Ein paar Tage später war die RAM-Auslastung wieder über meiner Benachrichtigungsschwelle. Nach einem händischen "fhempy_local restart" war der RAM wieder frei.)

[DS_Starter]

Morgen liegt eine neue Version im Update.
Es ist nur etwas Codepflege und der Hinweis aus #807 / #808 umgesetzt.

LG

[Dracolein]

Ich schmeiße entspr. des Thread-Titels aus Eigeninteresse nochmal eine "Idee zur Weiterentwicklung" ein:

https://forum.fhem.de/index.php?topic=115259.msg1316942#msg1316942

    

[DS_Starter]

Moin Dracolein,

ich habe mir den Beitrag #792 von Bismosa und deinen Link durchgelesen.
Dabei habe ich nur Hinweise und Beispiele gefunden wie man das HTML für FTUI3 zusammenbastelt aber keine Dinge die ich im Modul verändern sollte um FTUI besser zu unterstützen.
Kann aber sein ich habe etwas nicht gesehen bzw. überlesen.
Kannst du bzw. Bismosa mir Tipps geben mit welchen Modulanpassungen FTUI3 besser unterstützt würde?

Ich bentze selbst kein FTUI und bin deswegen da auch nicht so firm, bzw. in javascript generell. 

LG

[Mr.X]

Morgen liegt eine neue Version im Update.
Es ist nur etwas Codepflege und der Hinweis aus #807 / #808 umgesetzt.

LG

Danke!!

[bismosa]

Hallo!

@DS_Starter
Eigentlich gibt es da an diesem Modul nicht wirklich was zu verbessern. Der "Workaround" mit dem zusätzlichem Script im HTML

Code Auswählen Erweitern

<script>
  function FW_cmd(text){
      ftuiApp.fhemService.sendCommand(text.replace("/fhem?XHR=1&cmd=",""))
  }
</script>
funktioniert problemlos. Also könnte höchstens eine Variante FTUI3 etwas bringen, bei dem die Links verändert sind.
Tut aber aus meiner Sicht nicht not. Das macht nur das Modul noch komplizierter. 
Gerne kann mein Schnipsel oder ein Verweis darauf in die Hilfe/in den get Befehl übernommen werden.

Das Problem liegt da eher im FTUI3 selbst bei mir. Dafür müssen einige Änderungen vorgenommen werden. Leider scheint die Entwicklung dort nur langsam voran zu gehen. Dazu kann sich aber nur setstate äußern.
@Dracolein
Einfach mal ausprobieren und schauen, ob es nicht ohne die Änderungen der FTUI-Files funktioniert. Vielleicht liegt es ja wirklich nur an mir.

Gruß
Bismosa

[tobi01001]

Hallo!

@DS_Starter
Eigentlich gibt es da an diesem Modul nicht wirklich was zu verbessern. Der "Workaround" mit dem zusätzlichem Script im HTML

Code Auswählen Erweitern

<script>
  function FW_cmd(text){
      ftuiApp.fhemService.sendCommand(text.replace("/fhem?XHR=1&cmd=",""))
  }
</script>
funktioniert problemlos. Also könnte höchstens eine Variante FTUI3 etwas bringen, bei dem die Links verändert sind.
Tut aber aus meiner Sicht nicht not. Das macht nur das Modul noch komplizierter. 
Gerne kann mein Schnipsel oder ein Verweis darauf in die Hilfe/in den get Befehl übernommen werden.

Das Problem liegt da eher im FTUI3 selbst bei mir. Dafür müssen einige Änderungen vorgenommen werden. Leider scheint die Entwicklung dort nur langsam voran zu gehen. Dazu kann sich aber nur setstate äußern.
@Dracolein
Einfach mal ausprobieren und schauen, ob es nicht ohne die Änderungen der FTUI-Files funktioniert. Vielleicht liegt es ja wirklich nur an mir.

Gruß
Bismosa

Schaut mir recht kompliziert aus?!
ich habe ein Userreading (trigger muss man sich je nach Perfomrance überlegen) im SolarforeCast device (alternativ in einem weblink) und lade das über content in FTUI3:

Code Auswählen Erweitern

attr mySolarForeCast userReadings html { FHEM::SolarForecast::pageAsHtml ('mySolarForeCast', '-', 'flow_noHead_noCons') }
und

Code Auswählen Erweitern

<ftui-grid-tile row="8" col="2" height="8" width="4">
            <ftui-grid-header>PV / Verbrauch</ftui-grid-header>   
            <ftui-row align-items="center">
            <ftui-content align-items="center" [content]="mySolarForeCast:html"></ftui-content>
            </ftui-row>
        </ftui-grid-tile>

@DS_Starter:
Kann man davon ausgehen, dass Events im Modul mindestens dem ctrlInterval entsprechen?


Gruß,
Tobias

[Dracolein]

Hast Du damit keine Performanceprobleme? Dann wäre das eine super Lösung

[DS_Starter]

@DS_Starter:
Kann man davon ausgehen, dass Events im Modul mindestens dem ctrlInterval entsprechen?

Im Prinzip ja, trifft aber nicht auf alle Readings zu weil es auch von anderen Parametern abhängt.
Das Reading nextCycletime würde sich m.M. nach am Besten dafür eignen.
Deswegen gleich der Hinweis dem userReading immer einen Trigger mitzugeben sonst kann es wirklich auf die Performance schlagen, also etwa:

Code Auswählen Erweitern

attr mySolarForeCast userReadings html:nextCycletime.* { FHEM::SolarForecast::pageAsHtml ('mySolarForeCast', '-', 'flow_noHead_noCons') }


[tobi01001]

Hast Du damit keine Performanceprobleme? Dann wäre das eine super Lösung

Nein, keine Performance-Probleme, allerdings auch recht viel performance und reserve. Wie das z.B. auf einem Pi als Server aussehen wird, kann ich nicht sagen. Aber solange keine Aktualisierung der Grafik selbst erfolgt, sollte das doch statisch sein?

Habe jetzt zum Test mal eine FTUI3 HTML-Seite angelegt, die nur das enthält und über die Entwicklertools die Network-Performance angeschaut.

Das ganze wird im Schnitt in der als ctrlInterval eingestellten Zeit aktualisiert (wenn du den Hinweis von DS_Starter direkt umsetzt, exakt zum ctrlInterval). Dazwischen passiert faktisch nichts. Sollte also performant sein. Über einen entsprechenden Trigger des Userreadings (könntest du ja auch in ein at packen), kann man das Intervall auch selbst festlegen...

Gruß,
Tobias

Code Auswählen Erweitern

<!DOCTYPE html>
<html>
<head>
  <script src="ftui.js"></script>
  <link href="ftui.css" rel="stylesheet">
  <link href="themes/ftui-theme.css" rel="stylesheet">
  <link href="favicon.ico" rel="icon" type="image/x-icon" />
  <meta name="viewport" content="width=device-width">
  <meta name="mobile-web-app-capable" content="yes">
  <meta name="toast_position" content="topLeft">
  <meta name="debug" content="0">
  <title>Home Tablet UI</title>
</head>
<body>
<ftui-grid shape="round">
<ftui-grid-tile row="16" col="1" height="1" width="13"> <!-- Menu -->
<ftui-row>
<ftui-column>
<ftui-tab view="home" fill="solid" shape="round" active>
<ftui-icon name="home"></ftui-icon>
</ftui-tab>
</ftui-column>
</ftui-row>
    </ftui-grid-tile>
    <ftui-tab-view id="home"> <!-- view home -->
<ftui-grid-tile row="8" col="2" height="8" width="4">
<ftui-grid-header>PV / Verbrauch</ftui-grid-header>
<ftui-row align-items="center">
<ftui-content align-items="center" [content]="mySolarForeCast:html"></ftui-content>
</ftui-row>
</ftui-grid-tile>
</ftui-tab-view>
 </ftui-grid>
</body>
</html>


[Dracolein]

Habs eingebaut, gemeinsam mit dem <style> Codeschipsel erhalte ich eine taugliche Darstellung und augenscheinlich ohne spürbare Performanceprobleme. Coole Sache, wenn das so bleibt

[Gisbert]

Hallo DS_Starter,
Hallo alle SolarForecast-Interessierten,

wahrscheinlich bin ich nicht der erste der darüber stolpert - vielleicht gibt es auch keine gute Lösung.

Zunächst mal ein großes Kompliment an den Modul-Autor DS_Starter. Die geführte Installation des Moduls hat super funktioniert, auch eine Batterie konnte ich einfach definieren anhand der sehr guten Beschreibung zu den jeweiligen Attributen.

Was mir aufgefallen ist, ist der deutlich zu hohe Verbrauch, der Wert beim Häuschen und bei der Lampe, die identisch sind.
Meine Vermutung ist, dass die Wandlungsverluste DC/AC als Verbrauch aufgeführt sind, was den realen Verbrauch entsprechend erhöht.

Ich hab einen DEYE 12kW-3 Phasen-WR. Beim Attribut setupInverterDev habe ich die DC-Werte für die Leistung genommen, es  gibt wohl auch AC-Werte, allerdings dann auch gleich 2 unterschiedliche Register, aber bei der Energie (etotal) gibt es nur 1 Register. Also etwas verwirrend, was denn die besseren (richtigeren?) Daten sind.

Dann noch eine Frage, warum der Wert beim Häuschen und der Lampe identisch sind. Ist das so beabsichtigt und immer so?

Viele Grüße Gisbert

[300P]

Dann noch eine Frage, warum der Wert beim Häuschen und der Lampe identisch sind. Ist das so beabsichtigt und immer so?

Nur wenn im SF-Device von dir "Verbraucher" konfiguriert worden sind gibt es naturgemäß einen Unterschied zwischen "Haus" und "Lampe".
=>> Haus  = Gesamtverbrauch
=>> Lampe = Gesamtverbrauch - evtl. Verbrauchsmessungen der angelegten Verbraucher)

Für die einzelnen Verbraucher werden dann die ermittelten Verbrauchswerte vom Wert "Haus" abgezogen und am jeweiligen Verbraucher anhängend angezeigt (soweit konfiguriert)

Gruß
300P

[DS_Starter]

Hallo Gisbert,

freut mich dass dir die Guided Procedure gut geholfen hat. 

Bezüglich setupInverterDev musst du dem Key "pv" den Wert der Erzeugung zuordnen der nicht evtl. durch den Batterieladeanteil vermindert wird. Ich hoffe es gibt ein solches Reading beim Deye. Im Setup der Batterie muß der Key pin bzw. pout die richtigen Werte bzgl. der aktuellen Lade/Entladeleistung liefern. Aus diesen ganzen Werten berechnet das Modul dann unter Berücksichtigung der Meterwerte (Grid in/out) den laufenden Verbrauch des Hauses.

Vllt. erkennt man anhand der Readingnamen beim Deye deren Bedeutung?

LG,
Heiko

[kask]

@Gisbert
Die Lampe kannst du ausblenden bzw. nicht anzeigen lassen. Ich meine es ist das attr "flowGraphicShowConsumerDummy"

Das haus zeigt dir die kalkulierten Werte aus PV,Smartmeter und Batterie.
Alles was die PV bringt und aus dem Netzkommt rein/raus kommt und die Batterie rein/raus geht wird zusammengerechnet und ergibt den Verbrauch.
Um das plausibel zu halten solltest du die AC-Werte aus dem Umrichter und der Batterie nutzen.
Ansonsten fliessen immer die Wandlerverluste in deine Werte als Verbrauch. Ist ja auch Verbrauch.