Leistungsprognose für Wechselrichter

[DS_Starter]

Hallo Alexander,

ok, ich denke mit drüber nach.

LG

[DS_Starter]

@Wzut, @all,

bitte die Version aus dem contrib ziehen. Ich habe die Zeitkorrektur für die Grafik angepasst.

@Wzut, ungeachtet dessen haben wir heute wieder den schon beobachteten Fall, dass bei Verwendung von historyHour (bei mir wenn < -4) nicht die richtigen Werte angezeigt werden. Das hatten wir schon beim letzten Monatswechsel. Vllt. finde ich den Fehler, aber wenn du bitte auch mal schauen würdest ?! 

[dk3572]

Ok dann baue ich mal so ein Attr ein.
Fand ich jetzt nicht so undurchsichtig. Dafür hab ich ja auch die Mausover hinzugefügt. 
Aber vielleicht fällt mir noch was besseres ein.

Evtl. die Icon der Consumer färben?
Z.B. grün wenn genügend Energie vorhanden.

[DS_Starter]

@Wzut, ich denke ich habe den Fehler bzgl. Monatswechsel bei Verwendung von historyHour gefunden.
Die Zeile 3742 musste von

my $ds = strftime "%d", localtime($hfcg->{0}{mktime} - (3600 * abs(($offset)-$i))); 

nach

my $ds = strftime "%d", localtime($hfcg->{0}{mktime} - (3600 * abs(($offset)+$i))); 

geändert werden. Jetzt klappt das in jeder Variante.
Kannst ja mal bitte gegenchecken. Liegt im contrib.

LG

[Wzut]

wenn die Ausgabe stimmt kann deine Änderung so falsch ja nicht sein
Ich habe mir heute Morgen mal FHEM + das Modul auf meinem neuen Laptop installiert, da ich meinem Testsystem nicht mehr traue.
Intressant ist wenn man mit so einer Jungfrau beginnt  das die Darstellung der Vergangenheit auch unschön ist - also in Bezug auf Werte die ja nicht da sein können mangels History. 

[DS_Starter]

@Alexander,

ich könnte relativ problemlos Schlüssel einfügen notafter=<Stunde> notbefore=<Stunde>.

Diese Schlüssel könnte man intern auf 2 Varianten verwenden:

1. das Modul würde normal planen, aber nicht einschalten wenn die obigen Bedingungen nicht erfüllt sind
2. das Modul darf nicht außerhalb der Zeiten planen

Das Ergebnis ist im Prinzip gleich, allerdings würden im Fall 1 die Planungsdaten consumer0X_planned_XX drin stehen die ggf. extern ausgewertet werden könnten.

Frage... welche Variante würde dir/euch denn besser gefallen ?

[DS_Starter]

@Wzut

Intressant ist wenn man mit so einer Jungfrau beginnt  das die Darstellung der Vergangenheit auch unschön ist - also in Bezug auf Werte die ja nicht da sein können mangels History. 

Mach doch mal einen Screenshot. Vllt. fällt uns was ein für diesen Fall.

Edit: ch.eick würde jetzt vermutlich sagen ... mit Datenbank wär das kein Problem.   

[DS_Starter]

Übernehmt bitte die V0.49.5 aus dem contrib. Neben kleineren Fixes ist die Verwendung von Autokorrekturfaktoren in bestimmten Situationen (bei Quality=0) verbessert.

[EinEinfach]

Frage... welche Variante würde dir/euch denn besser gefallen ?

Gefüllt gefällt mir die Variante 2 besser.

[dk3572]

@Alexander,

ich könnte relativ problemlos Schlüssel einfügen notafter=<Stunde> notbefore=<Stunde>.

Diese Schlüssel könnte man intern auf 2 Varianten verwenden:

1. das Modul würde normal planen, aber nicht einschalten wenn die obigen Bedingungen nicht erfüllt sind
2. das Modul darf nicht außerhalb der Zeiten planen

Das Ergebnis ist im Prinzip gleich, allerdings würden im Fall 1 die Planungsdaten consumer0X_planned_XX drin stehen die ggf. extern ausgewertet werden könnten.

Frage... welche Variante würde dir/euch denn besser gefallen ?

Ich wäre für Variante 1

[Wzut]

@WzutMach doch mal einen Screenshot.

Kannst du haben, aber nicht wegen der fehlenden Daten (ich sollte inzwischen wissen das Tag/Nacht vom Wetter gesteuert wird .... )
Schau dir mal den Header unter f18 an, das "klebt" teilweise unschön zusammen - liegt an deiner HTML Ausgabe - ich mach sie dir mal hübscher
Das ist jetzt der Vorteil der Jungfrau auf dem Laptop, auf meinem Testsystem läuft f18 nur noch mit vielen JS Fehlern, daher hatte ich den jetzt ewig gar nicht mehr an.

[DS_Starter]

Ja mach mal 

Aber nimm bitte die V die ich gerade eben hochgeladen habe. War auch gerade in der sub _forecastGraphicHeader drin.

[DS_Starter]

@Alexander, @Dieter,
bezüglich der Varianten notafter, notbefore konnte jetzt keine Mehrheit für eine Der Varianten festgestellt werden. 

Also habe ich auch nochmal tiefer drüber nachgedacht und tendiere zur Variante 2.

Warum ?
Gesetzt den Fall, der User hat eine Anlage mit Westausrichtung, dann würde diese Anlage Abends den höchsten Wert generieren. D.h. die Planung würde vmtl. immer in den Abendstunden liegen. Definiert er nun der Verbraucher soll nicht nach 17:00 loslaufen (weil im Winter eh dunkel ist), würde die Planung zur Zeit und im Sommer vermutlich eher nach 17:00 liegen und der Verbraucher würde nie einschalten, obwohl "must".

Man könnte zwar umkonfigurieren, aber ganhz ehrlich, wer will denn immer Hand anlegen ?
Das Beispiel ist vllt. etwas konstruiert, aber m.M. nach sollte das Modul dann die Planung für das Einschalten entsprechend nach hinten oder vorne schieben, ja nachdem.

Gibt es Einwände ? Möglicherweise sehe ich etwas falsch ...

[DS_Starter]

Hallo Alexander, @all,

es gibt nun die optionalen Schlüssel notafter/notbefore für die consumer Attribute:

consumerXX <Device Name> type=<type> power=<power> [mode=<mode>] [icon=<Icon>] [mintime=<minutes>] [on=<Kommando>] [off=<Kommando>] [notbefore=<Stunde>] [notafter=<Stunde>] [auto=<Readingname>] [etotal=<Readingname>:<Einheit>]

       notbefore   Verbraucher nicht vor angegebener Stunde (01..23) einschalten (optional)
       notafter     Verbraucher nicht vor angegebener Stunde (01..23) ausschalten (optional)

Liegt im contrib.

Achtung: der Schlüssel  ready wurde in auto umbenannt !

[MadMax]

Guten Morgen, heute Morgen hab ich ein Schock bekommen.
Der erste Balben ist riesig groß ich komme nicht bis an Ende runter.

Ich kann nacher noch die History senden.

Gruß
Max