Leistungsprognose für Wechselrichter

[ch.eick]

Der Update-Syntax dürfte sich dann auch noch bei jeder Datenbank unterscheiden.

Das ist nur für MySQL, gibt es noch was anderes

[DS_Starter]

... gibt es noch was anderes

Du alter Schelm ... 

[EinEinfach]

Der Update-Syntax dürfte sich dann auch noch bei jeder Datenbank unterscheiden.

Denkbar wäre ein Reading, was immer relativ zum aktuellen Zeitpunkt in die Zukunft schaut (Über Attribut Einstellbar +5std... +6std etc) man muss sich sozusagen entscheiden wie weit man in die Zukunft schauen will.

P.S. Die NextHour Readings gibt es nicht mehr, die man dafür misbrauchen könnte

[DS_Starter]

Ja, die Daten sind alle vorhanden.
Aber das Problem ist, dass sie sich ändern (können) und diese Änderung bei einer DB mit PK nicht (ohne Kunstgriffe) in die DB kommen. Eine DB ohne PK könnte es zwar verarbeiten, hätte dann aber wiederum eine hohe Anzahl doppelter Datensätze mit identischem Timestamp und unterschiedlichem Value. Welcher Wert siegt dann im SVG-Plot ?  Bin mir unsicher bzw. weiß es nicht. Jedenfalls ist das nicht so gewünscht denke ich.

[EinEinfach]

Aber das Problem ist, dass sie sich ändern (können) und diese Änderung bei einer DB mit PK nicht (ohne Kunstgriffe) in die DB kommen.

Das Reding soll sich auch ruhig mehrmals ändern dürfen, was die Leute damit dann später anstellen, ist nicht die Aufgabe von dem Modul.

[DS_Starter]

Stimmt auch wieder. 
Man sieht an diesem kleinen Beispiel wie vielfältig manche Sachverhalte sein können.
Ich denke mal mit drüber nach. Muß irgendwann mal anfangen die Punkte der letzen 2/3 Seiten einzuarbeiten ...

[ch.eick]

Das Reding soll sich auch ruhig mehrmals ändern dürfen, was die Leute damit dann später anstellen, ist nicht die Aufgabe von dem Modul.

Der VALUE im Eintrag ja, aber mehrfach den selben TIMESTAMP kann man nur schwerlich sortieren Deshalb verwendet man den PK.

EDIT:
Im DbLog Design ist der TIMESTAMP historisch bedingt leider nur auf die Sekunde genau implementiert.

[jual]

Ich nutze für einen eigenen Plot der Forecastwerte folgende Funktion in Verbindung mit einer DB:

Code Auswählen Erweitern

#
# Forecastwerte aus mySolarForecast in die DB schreiben, um damit ein Plot zu erstellen
#
sub PVForecast_log2()
{
   Log 3, "Aufruf von PVForecast_log2 um ".localtime();
   
   # Alte Einträge erst einmal löschen
   my $timedelete = TimeNow();
   my ($year,$mon,$day,$hour,$min) = $timedelete =~ m/(\d\d\d\d)-(\d\d)-(\d\d) (\d\d):(\d\d):\d\d/;
   
   fhem "set DBRep_PV sqlCmd delete from history where DEVICE = 'mySolarForecast' AND reading like 'PVforecast%' and TIMESTAMP>='".$timedelete."'";
   
   # alle Verhersage Readings des Device durchlaufen
   for(my $i=$hour; $i <= 24; $i++)
   {     
  # die Readings mit der Nummerierung richtig zusammen bauen (führende Nullen bei < 10)
      my $reading = ($i < 10) ? "Today_Hour0".$i : "Today_Hour".$i;
 
  #Timestamp für den Forecastwert
  my $timestamp = ($i < 10) ? "$year-$mon-$day 0$i:00:00" : "$year-$mon-$day $i:00:00";
  my $value = ReadingsNum("mySolarForecast",$reading."_PVforecast",0);
 
      # Wert in der Datenbank loggen
  fhem "set DBLog_PV addCacheLine ".$timestamp."|mySolarForecast|addlog|newForecast:".$i."|PVforecast|".$value."|";
   }
}


[ch.eick]

Ich nutze für einen eigenen Plot der Forecastwerte folgende Funktion in Verbindung mit einer DB:

Dann kann ich ja bei meiner Funktion bleiben
Ziel in diesem Thread war es ja genau ein Modul zu schaffen, bei dem man dann nicht noch etwas drum herum machen muss.
Im Wiki ist die Solar_forecast() Funktion, die auch ohne den Plentice WR, also auch mit einem Dummy oder beliebigen anderen Device anwendbar ist.
Die Autokorrektur bei mir geht jedoch nur mit Datenbank.

[DS_Starter]

Super jual.
@Christian, vermutlich wird man nicht jeden erdenklichen Anwendungsfall im Modul einbauen können.
Das Script von jual geht allerdings für jede DB 

Deswegen ein ganz allgemeiner Vorschlag.
Ich denke es wird eine ganze Menge Informationen/Fragen rund um dieses Modul geben. Angefangen über den verlangten Input , die Einstellung/Handhabung der Autokorrektur mit den Möglichkeiten der Attribute, der Grafik und Möglichkeiten des Loggings und Diagrammdarstellung.

Es wäre vermutlich sinnvoll eine Wiki-Seite für dieses Modul zu beginnen und dort solche Infos zu sammeln. Das macht es für den Einsteiger/Anwender einfacher.

Edit: Muss sich nur noch jemand finden der es tut.    Ich würde meine Zeit gern zunächst auf die Weiterentwicklung des Moduls verwenden.

[papa]

Das ist nur für MySQL, gibt es noch was anderes

Aber dafür gibt es doch REPLACE INTO

[ch.eick]

@Christian, vermutlich wird man nicht jeden erdenklichen Anwendungsfall im Modul einbauen können.
Das Script von jual geht allerdings für jede DB 

Ich verwende auch DbRep für die Kopplung. Es ist nur für alle DBs geeignet, wenn das SQL sich auf basis Funktionalitäten im SQL beschränkt.
Jual sendet auch ein SQL direkt an die Datenbank und verwendet nicht die integrierte delete Funktion im DbRep.
Das soll bitte keine Kritik sein, ich bin nicht immer ein Ketzer

[ch.eick]

Aber dafür gibt es doch REPLACE INTO

Danke, es kommt immer darauf an welches Beispiel man zuerst findet und kopiert

EDIT:

REPLACE is a MySQL extension to the SQL standard. It either inserts, or deletes and inserts. For another MySQL extension to standard SQL—that either inserts or updates—see Section 13.2.6.2, "INSERT ... ON DUPLICATE KEY UPDATE Statement".

Da ist ein kleiner Unterschied. Ein Delete und neues Insert ist weniger performant als ein UPDATE auf einen einzelnen VALUE.

Somit ist es einfach etwas anders implementiert, aber immernoch MySQL spezifisch.

[DS_Starter]

Alles gut 
Ich klink mich jetzt hier mal aus und widme mich wieder bisschen dem Code. Sonst geht da nix weiter.

[DS_Starter]

Neue V liegt im contrib.
Nun ist auch die diese Variante von EinEinfach möglich:

currentMeterDev <Device> gfeedin=<Reading>:<Einheit> contotal=<Reading>:<Einheit> gcon=-gfeedin feedtotal=<Reading>:<Einheit>

Warnings habe ich auch keine mehr bemerkt. Sagt Bescheid wenn ihr welche haben solltet.