CCU-Historian v2.4.0-beta3 ... noch ein paar Fragen

[g55]

Hi mal wieder
erst mal vielen Dank an @Mathias für das stetige Engagement . Ich hab schon auch im GitHUB gesehen, dass du den CCU-Historian weiter entwickelst. Vielen Dank auch vom mir !!
Ich hab den CCU-Historian in den letzten Tagen gehörig "durchgenudelt" ... vielleicht ist mir auch nach eingehendem Lesen des Handbuchs doch etwas entgangen ... ich hätte da noch ein paar "Auffälligkeiten":

• Meldungsanalyse :
  Soweit ich das kapiert hab, müssen dafür auch die Datenpunkte der einzelnen Geräte aktiviert sein. Soweit, so gut. Hab ich gemacht für LOW%BAT, %UNREACH, %ERROR% in der Datenbank. Jetzt erscheinen diese Datenpunkte natürlich auch in der Liste der Datenpunkte , ist dadurch sehr unübersichtlich, hier will ich eigentlich nur die DPs sehen, für die ich auch für Diagramme haben will.
  Wenn ich diese DPs in der Datenbank als "versteckt" markiere, sind die zwar aus der Datenpunktliste verschwunden, jedoch auch in der Meldungsanalyse
• Neue DP = False + MetaDaten
  OK, Hatte ich schon mal hier gepostet.
  bei "false" werden eben die Metadaten nicht aktualisiert, sodass ich nur anhand der ID raten kann (oder im WebUI / SDV gezielt suchen), welches Gerät das nun ist.
• Datenpunktkonfiguration
  ok, ich hab den CCU-Historian als AddOn aufm RPi3 mit piVCCU3 installiert. Is a bisserl eng mit dem RAM, aber geht noch. Wenn ich jedoch die Datenpunktkonfiguration aufrufe, dauert des eben etwas länger und mein Firefox aufm PC "qualmt" sogar bez. CPU-Zeit ... sind auch etwas mehr als 1000 Datenpunkte. Für die Konfiguration von Diagrammen insofern für mich grad eigentlich unbrauchbar.
• Diagramm-Limits
  Ich habe schon einige Diagramme definiert und als Links in der config hinterlegt. Jedoch ist die Skalierung der y-Achse immer "flexibel", je nach Zeit-Intervall. Eigentlich möchte ich feste Skalierungen der y-Achse bei den Diagrammen, nur blicke ich grad net durch, wie das geht ? im Handbuch sehe ich was von einer Datei namens "trenddesigns.groovy", hab ich eben k.A., wo die hin muss

Ich weis ja nicht, ob es möglich, bzw. sinnvoll + machbar wäre, meine Fragen/Anregungen sind :

• Meldungsanalyse : Welche DPs werden hier eigentlich benötigt + müssen diese aktiv + nicht versteckt sein ?
  Ich persönlich würde bevorzugen, diese zwar aktiv = protokolliert zu setzen, aber in der Datenpunktliste möchte ich die nicht sehen = versteckt.
• Neue DP = False + MetaDaten : ich würde mich sehr freuen, wenn neue Geräte auch mit Metadaten (trotz "false" in der config) versehen werden können
• Datenpunktkonfiguration : besteht hier evtl. die Möglichkeit, das seitenweise einzulesen, z.B. in 20er/100er oder sonst was Schritten, damit der Seitenaufbau im Browser schneller geht ?
• Diagramm-Limits : bin für jeden Tipp dankbar, wie ich bei meinen definierten Diagrammen auch ein festes Limit = Y-Achse 1/2 von-bis definieren könnte.

soweit mein Feedback. Ich freue mich über jegliche Rückmeldung und jeden Tipp hierzu.
VG + besten Dank.

[Mathias]

Vielen Dank für das Feedback!

Meldungsanalyse : Welche DPs werden hier eigentlich benötigt + müssen diese aktiv + nicht versteckt sein ?
Ich persönlich würde bevorzugen, diese zwar aktiv = protokolliert zu setzen, aber in der Datenpunktliste möchte ich die nicht sehen = versteckt.

Für die Meldungsanalyse werden alle Datenpunkte berücksichtigt die die CCU als Service-Datenpunkte markiert. Beispiele: UNREACH, LOWBAT, LOW_BAT, CONFIG_PENDING, ERROR, ERROR_CODE, ERROR_NON_FLAT_POSITIONING, ERROR_OVERHEAT, ERROR_SABOTAGE, SABOTAGE, UPDATE_PENDING. Diese sollten also nicht in der Datenpunktkonfiguration deaktiviert werden (Haken bei Inaktiv). Ob sie versteckt sind, ist egal.

Neue DP = False + MetaDaten : ich würde mich sehr freuen, wenn neue Geräte auch mit Metadaten (trotz "false" in der config) versehen werden können

Dies ist bereits implementiert und kommt mit der V2.4.0-beta.4.

Datenpunktkonfiguration : besteht hier evtl. die Möglichkeit, das seitenweise einzulesen, z.B. in 20er/100er oder sonst was Schritten, damit der Seitenaufbau im Browser schneller geht ?

Das passt leider nicht zum angedachten Workflow in der Datenpunktkonfiguration: Einmalig alle Datenpunkte laden, Filtern, Datenpunktkonfiguration ändern, Filtern, Datenpunktkonfiguration ändern, ..., Geänderte Konfiguration übernehmen. Das Laden ist nur einmalig, danach können beliebig viele Datenpunkte immer wieder gefilter und konfiguriert werden.

Wieviele Sekunden dauert denn der Seitenaufbau? Sicherlich hilft ein ordentlicher Rechner für den CCU-Historian am meisten.

Diagramm-Limits : bin für jeden Tipp dankbar, wie ich bei meinen definierten Diagrammen auch ein festes Limit = Y-Achse 1/2 von-bis definieren könnte.

Die trenddesigns.groovy sollte neben der Datei ccu-historian.jar liegen. Bei einer Installation als Add-On wird aber zurzeit noch eine Konfigurationsoption falsch gesetzt (base.scriptDir). Dies ist aber in V2.4.0-beta.4 behoben.

Per Trend-Design kann der Auto-Range abgeschaltet werden (s.a. Foren-Beitrag). Der nötige URL-Parameter t zur Auswahl des Designs muss aber zurzeit noch manuell in der Adresszeile hinzugefügt werden. Es ist aber eine Auswahlbox geplant. Hinweis: Wenn Trend-Designs in der Datei trenddesigns.groovy anstatt ccu-historian.config abgelegt werden, so ist das Präfix webServer. von den Optionen zu entfernen.

Viele Grüße
Mathias

[g55]

Vielen Dank für deine Rückmeldung

Für die Meldungsanalyse werden alle Datenpunkte berücksichtigt die die CCU als Service-Datenpunkte markiert. Beispiele: UNREACH, LOWBAT, LOW_BAT, CONFIG_PENDING, ERROR, ERROR_CODE, ERROR_NON_FLAT_POSITIONING, ERROR_OVERHEAT, ERROR_SABOTAGE, SABOTAGE, UPDATE_PENDING. Diese sollten also nicht in der Datenpunktkonfiguration deaktiviert werden (Haken bei Inaktiv). Ob sie versteckt sind, ist egal.

jep, so geht das gut. Ich hatte wohl noch nen Fehler bei meinen Tests ... jetzt sind diese DPs aktiv + versteckt, Meldungsanalyse geht und diese DP stören mich nicht in der Datenpunktanalyse.

Dies ist bereits implementiert und kommt mit der V2.4.0-beta.4.

Super + besten Dank.

Wieviele Sekunden dauert denn der Seitenaufbau? Sicherlich hilft ein ordentlicher Rechner für den CCU-Historian am meisten.

Na ja, der Seitenaufbau dauert mit dem CCUHistorian als addon aufm RPi3 schon ca. 1 min., aufm Laptop nach Kopieren der DB immer noch 20 sec. OK, ist akzeptabel, man konfiguriert ja nicht immer jeden Tag ... nur eben bei Tests

Die trenddesigns.groovy sollte neben der Datei ccu-historian.jar liegen. Bei einer Installation als Add-On wird aber zurzeit noch eine Konfigurationsoption falsch gesetzt (base.scriptDir). Dies ist aber in V2.4.0-beta.4 behoben.

Per Trend-Design kann der Auto-Range abgeschaltet werden (s.a. Foren-Beitrag). Der nötige URL-Parameter t zur Auswahl des Designs muss aber zurzeit noch manuell in der Adresszeile hinzugefügt werden. Es ist aber eine Auswahlbox geplant. Hinweis: Wenn Trend-Designs in der Datei trenddesigns.groovy anstatt ccu-historian.config abgelegt werden, so ist das Präfix webServer. von den Optionen zu entfernen.

jep, hab ich im GitHUP auch gelesen. Kaum packt man die trenddesigns.groovy an die richtige Stelle und ändert die config entsprechend, funktionieren die festen y-Skalen auch super. Hast alles im WIKI sehr gut beschrieben. Ich denke, dass ich das jetzt auch einigermaßen verstanden hab. Geht jedenfalls auch in der config selbst, gerade getestet, da eben mit "webserver.".

Ich freue micht schon auf die nächste Beta4. Werde noch ein wenig weiter testen, hab janoch nicht alle DPs + Diagramme, die ich gerne hätte, auch definiert