ich habe möglicherweise eine Lösung gefunden (gegoogelt),die die Lade-Hänger im IE und FF vermeidet. Ich hab unter folgendem Link ein Beta Installerfile bereit gestellt.
Update wie sonst auch: Code aus dem File in das im IPS-Objektbaum vorhandene Install-File einkopieren und ausführen.
Anschließend das User-Config Script einmalig manuell starten.
Weiterhin ist ein Forecast-Modul (siehe Pic 2 Postings weiter oben) enthalten, was noch nicht fertig ist (kann also Fehlermeldungen erzeugen, kann momentan noch keine DAU-Eingaben in den TimeSlots abfangen). Das soll aber nicht Gegenstand des Tests sein: mir geht es primär darum, herauszufinden, ob der Analyzer im FF besser läuft (bei mir tut er es)
Arbeitsweise des „BugFixes“: die Sparklines werden nun nicht mehr alle parallel bei Aufruf der Seite vom Browser gerendert, sondern in Paketen nacheinander. Das sieht komisch aus, scheint aber das Problem zu beheben.
Falls ich ausreichend positives Feedback bekomme, bau ich das so in die kommende Version ein
Besser, aber noch nicht perfekt. Es ist folgendes Muster zu erkennen:
Wenn ich das WF direkt auf den Analyser lade, es also vorher dort geschlossen habe, dann klappt es. Nachdem sich alle Sparklines geladen haben, ruckelt sich die Tabelle abschließend zurecht.
Wenn ich das WF auf irgendeiner anderen Seite (TabPane) lade, dann klappt es nur zu ca. einem Drittel. Danach kommt schon das finale Ruckeln und zwei Drittel bleiben auf Loading, darunter die beiden rechts oberhalb der Tabelle.
Das habe ich zwei-, dreimal über Kreuz probiert - Ergebnis reproduzierbar. Danach habe ich das WF auf das TabPane des Agg-Managers geladen - dann klappt es beim Umschalten auf den Analyser überhaupt nicht und es steht überall „Loading“. Schließe ich jetzt das WF… Dann gilt wieder Nr. 1.
nicht ganz. Wenn man das WF nicht direkt auf den Analyser startet steht über all nur Loading. Egal von welchem Tab ich das aufrufe. Wenn nicht lädt, lädts nicht. Auch nicht zu einem Drittel. Wenns lädt dann alles.
ok, danke Euch fürs Testen und Feedback.
Ich hätte noch einen Versuch. Wenn der nicht klappt, wird der FF von der Liste der supporteten Browser gestrichen :mad:.
quick&dirty könnt Ihr mal folgende Parameter runterschrauben (rot eingerahmt, Script „create WFE-Table“)
per default stehen die Werte auf 50 und 20. Bei mir treten mit den Werten im Pic keine Probleme auf.
Korrektur: man sollte zum testen auch den betroffenen Brwoser nehmen.
Fazit: FF kommt mit den Sparklines (bzw. mit der Menge) nicht zurecht und kommt damit auf die Blacklist.:mad:
vielen Dank das Du dieses tolle Projekt mit uns teilst!
Ich habe alles installiert, es gibt keine offensichtlichen Mängel, jedoch komme ich nicht dazu die Features dieses Projektes zu nutzen, da meine DB schon sehr groß ist und der IPS-Rechner nicht so der allerschnellste ist…
Es kommt zu einer Fehlermeldung in der …\DB cleaner\read DB…
Ich bekomme beim Löschen von Daten die FEhlermeldung im IPS-Logger „Division by Zero“ im Skript „create WFE-Table“ in Zeile 618.
Sagt das jemanden etwas?
Joachim
Sorry: Das ist mir jetzt unangenahme: Der Dank galt selbstverständlich Werner!
das ist eine nicht abgefangene Fehlermeldung und kein Problem. Ich hab den aktuellen Code bei mir schin heftig umgehäkelt, so dass ich es nicht exakt nachprüfen kann, denke aber, dass ich diese fehlermeldung inzwischen im Script abfange. Ob das so ist, merkt Ihr im nächsten Update
Hallo
Hab ein Problem mit der Fehlererkennung.
Hier ein Beispiel :
Drei geloggte Werte
00:42:03 - 125,1
00:44:03 - 124,8
00:45:05 - 125,3
Der mittlere wird mir als Fehler angezeigt , warum ?
bei den oben genannten Daten handelt es sich um fehlerhafte Datensätze (auch explizit so beschrieben), keine Datenbankfehler!
Fehlerhaft deswegen, weil es in der IPS-Welt keine Kombination „Zähler-Variable“ + fallende Werte geben darf/sollte/dürfte. Evtl. andere Intensionen des Users (einen Standard-Wert auf eine Zähler-Variable zu loggen) sind in IPS nicht parametrisierbar und daher nicht auswertbar
Hintergrundinformationen dazu sind hier beschrieben: Link und von der Projekthomepage verlinkt
Das Tool ist klasse - gibt es doch viel Transparenz und Möglichkeiten des Eingriffs.
Ich nutze seit ca. 3 Jahren IPS und logge auch seit dieser Zeit viele Variablen.
Öfters schon hatte ich mich gefragt wieviele Datensätze wohl geloggt werden (insbesondere bei Float Werten),
aber mich nie ernsthaft damit beschäftigt.
Dann vor 4 Tagen ging es los - es wurden meine Graphen nur noch an ca. 2-4h / Tag dargestellt…
… die üblichen Ideen z.B. Start / Stop / Neustart brachten immer nur für kurze Zeit Besserung.
Dann bin ich auf dieses Thema gestoßen…
… erst mal Datenbank überprüft und repariert (2,2 GB)
… dann den Analyser installiert
… der wollte erst gar nicht starten… immer gab es Fehlermeldungen dass mehrere Variablen nicht existieren oder falsch definiert sind.
… die Lösung war dann ein manuelles Starten des „Read DB“ Scriptes… meine Laufzeiten mit 400 sec waren erheblich über den eingestellten max. 60 sec also erst mal den Parameter hochschrauben.
Soweit so gut…
… alle geloggten Werte die bei mir mehr als 1 Mio Einträge haben sind vom Typ Float… hier sehe ich einen Ansatz zur weiteren Verdichtung der Daten
a) für die historischen Daten (Löschen von Mehrfachwerten mit einer gewissen Genauigkeit z.B. reicht bei Temperaturen in der Regel eine Messung von 12,5 Grad statt vielen Daten im Sekundentakt mit 12,34566565 + 12,3460454 etc.)
b) wie könnte man dieses Loggen von Floatwerten bei neuen Daten schon automatisch Begrenzen, damit all die Nachkommastellen z.B. „[0_EG\FHT80_Wintergarten\Position] = 96,484375“
gar nicht erst gespeichert werden?
Das Thema a) wäre doch eine tolle Erweiterung für das Script
und b) hier wäre ich auch für einen Tip dankbar.
zu
a) nein, das wird für dein Vorhaben nicht möglich sein: man kann immer nur Datensätze für Zeiträume löschen (was aber demnächst als neues Feature eingebaut wird), benötigt würde aber das Löschen für gezielten Datensätze. Deutlich effektiver ist Datenreduktion durch größere Intervalle (und ggf. Durchschnittsbildung vor dem Speichern) - funktioniert aber eben nicht rückwirkend
b) in dem Du vor dem Speichern die php-Funktion „round“ nutzt und die Anzahl der Stellen begrenzt. Allerdings wird das deinem eigentlichen Anliegen (Speicherplatz sparen) nicht nützen
Okay, das gilt für ein Datum. Der Datenverlauf wird in der DB aber m.W. nur über Änderungen gespeichert. Runden reduziert Änderungen (solange das Auffüllen nicht zufällig geschieht).
Mit anderen Worten: Wenn ich die Temperartur auf ganze Grad runde und es einen Tag lang z.B. zwischen 11,6 und 12,4 Grad bleibt, dann speichert die DB praktisch keine Daten, da es dauerhaft (gerundet und aufgefüllt) 12,00000… Grad bleiben.
So ist zumindest meine nichtprofessionelle Vorstellung der Materie.
