Hast du das genommen?
Dann würde es eine andere Fehlermeldung geben.
Das eine ist PHP Code, das andere eine Ausgabe mit print_r. Nicht verwechseln.
Michael
Ja stimmt. :+1 Beides sind Key=>Value Arrays
Mit welchem Zeistempel?
Also ziemlich genau der Zeitpunkt an em ich das Script ausgeführt habe.
Interessant daran ist, dass der Unix Zeitstempel für 11Uhr eigentlich dem in Position 54 des obigen Arrays entspricht und da ist halt eben keine 0 als Wert sondern 1,7547.
Warum aber hat er die Arraypaare 1-53 nicht geschrieben, da die doch in der Vergangnheit liegen? Checkt der vor dem Schreiben das komplette Array ab und verweigert das komplette Schreiben, sobald da ein Wert ungültig ist.
Versuchst du, Sätze in die Zukunft zu schreiben? Das wird nicht gehen.
Wenn die Archivierung eingeschaltet wird, wird ein Initalsatz geschrieben mit dem aktuellen Wert und der aktuellen Uhrzeit.
Dann - so meine Vermutung- wird das Array überprüft und mit der obigen Fehlermeldung abgelehnt, da wohl Sätze in der Zukunft liegen.
Kann ja so nicht sein, auch neue Werte sind ja immer in der Zukunft des Alten 
@Dr.Niels hat es in einem anderen Beitrag schon geschrieben.
Ist der Zeitstempel zu neu (bis zu einer Minute alt), dann klappt das nicht.
Damit ist die aktuelle Zeit gemeint.
Michael
Was wäre, wenn der Solcast und dein Server unterschiedliche Systemzeiten verwenden?
Vielleicht ist der Solcast auf Sommerzeit?
Das war vor 1 1/2 Jahren. Vielleicht hat sich das geändert. Zumindest in die Doku ist die Einschränkung nicht eingeflossen.
Auch ist es mir beim Übertragen von Werten von einer Variablen in eine andere nicht aufgefallen.
Oder bekommt man beim Lesen des Archivs auch nicht die neuesten Werte?
Werte aus der Zukunft können wohl nicht ins Archiv eingetragen werden. Das wurde hier auch schon diskutiert AC_ADDLOGGEDVALUES für Zukunftswerte
Da hatte dann @Dr.Niels das Problem dabei weiter erläutert.
Man könnte vielleicht jedes mal 24h vom Timestamp abziehen und dann abspeichern und wenn man sie braucht addiert man die Zeit wieder dazu.
Das war ja meine Idee, um damit umzugehen. Das problem ist ja auch bei anderen Systemen bekannt. Ich hab mal vor Jahren Module für ABB SCADA System geschrieben die über OPC mit dem System kommuniziert haben und die kannten auch nur aktuelle und Vergangenheiswerte. Es führte einfach kein Weg rein, dass man da Prognostizierte Werte in die Zukunft schreiben konnte. letztendlich haben wir dann eine zusätzliche Oracle-Datenbank aufgesetzt, die parallel lief und in der man das konnte. Allgemein würde ich sagen, dass Systeme, die keine Zukunftsdaten erfassen können in einem Zeitalter in dem man sehr viel mittels Prognosen optimieren kann, nicht mehr zeitgemäß sind.
Es ist ja nicht so, dass es keine Lösung gäbe, jedoch würde das einen ziemlichen Umbau in IPSymcon bedeuten. InfluxDB kann zum Beispiel auch Daten in die Zukunft schreiben und ist zudem um Größenordnungen performanter und effizienter als das was als Datenbank unter IPSymcon werkelt. Ich hab das Grafana Modul mit IPS am Laufen und manchmal braucht es gut 4-5 Sekunden bis ein Graph aufgebaut ist, obwohl beide Systeme auf ein und dem selben Rechner laufen. Bei einer InfluxDB-Verbindung zu Grafana geht das in Sekundenbruchteilen. Vielleict liegt das aber auch an der Umsetzung des Grafana Moduls. Da bin ich mir nicht sicher.
Das Problem der Datenbankperformance wird umso brennender, wenn man versucht über IPSymcon zum Beispiel ein Energiedatenmanagement aufzubauen was zwingend Echtzeitdaten braucht. Ich habe das mal versucht und dazu muss ich meine Wechselrichter, das Batteriemanagementsystem und den Einspeisezähler im Sekundenrhytmus auslesen. Wenn ich das aber mache, bekomme ich Performanceprobleme und die Datenbank ist ziemlich schnell riesengroß. Letztendlich hilft dann immer nur das Löschen der Werte, die älter als ein paar Stunden sind.
1 „Gefällt mir“
Ich nutze auch Grafana, schon wegen der Optik und unzähligen grafischen Möglichkeiten. Ich habe einen Server im Internet mit SQL-Datenbank. Die IPSymcon Variablen gehen über das Modul ArchivMySQL dorthin und die Grafana Dashboards greifen darauf zu. Auch eine Gastherme mit EMS+ Bus lese ich so aus und habe nahezu Echtzeitdaten. Ich musste in der Datenbankkonfiguration nur mal die MaxConnections hochstellen, weil ich mittlerweile zu viele Projekte mit Zugriffen habe. Weil es gut läuft hab ich mir eine Lösung mit InfluxDB bis jetzt noch offen gehalten. Auf dem Server im Internet kann ich komfortabel Backups machen lassen und ich bin soweit zufrieden.
Also ich hab die Daten jetzt zeitversetzt um zwei Tage zurück versetzt im Archiv. Rechnen kann man damit jetzt schon, wenn man eben einfach dann wieder 48h dazu addiert.
Was mache ich allerdings mit Diagrammen (IPSymcon, HighCharts, Grafana)? Gibt es da eine Möglichkeit die Zeitstempel während der Anzeige so zu verbiegen, dass wieder die korrekten Zeiten angezeigt werden? Dann könnte ich in einem Diagramm die Prohnose und die real gemessenen Werte anzeigen lassen, wenn ich die rückgespeicherten Prognosedaten quasi aus der Vergangenheit wieder in die Gegenwart mappe.
ich arbeite noch nicht lange mit IPS, aber 20 Jahre mit Datenbanken.
Die Graphiken die man im IPS View machen kann erinnern mich an das letzte Jahrhundert.
Da müssen die IPS macher also schnell etwas unternehmen. Sonst wird IPS zum Spielzeug.
Es macht keinen Sinn ein lokale IP Symcon System zu haben und dann cloud datenbanken nbenbei.
Gerade bei Daten die man häufig abfragen muss um genaue Daten zu haben sind dann die Möglichkeiten in IPS sehr begrenzt, es kommt dann schnell die Meldung „Zu viele Werte für einen Rohgraphen“ da kann selbst die alte Homematic CCU mehr Datenpunkt in den Diagrammen anzeigen.
Das wichtigste heute ist doch eine gescheite Datenbank, am Angebot liegt es nicht.
Schau mal bei den Spezialschaltern. Da gibt es die Einstellungen, um das Limit hochzusetzen. Im Standard ist ein sehr konservativer Wert gesetzt.
Danke für den Hinweis, aber ich habe keine Einstellungen dafür gefunden.
Ist nicht schwer zu finden.
Der zweite und dritte von oben.
Michael
Danke für die Hilfe. Hat funktioniert.
Ich habe bei mir auf einem eher unterdurchschnittlichen System beide auf 100.000 stehen und keine Probleme.