Temperaturkurven frieren ein

[swissembedded]

Hallo zusammen

ich habe gerade eine neue Installation vom Demo gemacht (Openhab 1.6.2 mit Java 1.6.0_45). Die Kurven sind für eine Stunden gelaufen und dann stehen geblieben.
Ich bin gerade dran eine Steuerung für den Eigenverbrauch in Openhab zu programmieren und kämpfe dort mit den Kurven. Das ganze ist für mich jetzt ein Indiz, dass die Geschichte auch in der Demo gar nicht stabil läuft. Wie sind da Eure Erfahrungen. Woran könnte es klemmen?
Alles ist out of the box, das einzige was ich im Start.bat geändert habe ist der Pfad auf java.exe

Gruss Dani

[udo1toni]

Also hier läuft das schon seit V1.2 ziemlich stabil. Kam schon mal vor, dass ein rrd-File korrupt war (vor allem nach einem ungeplanten Neustart...), dann half aber Löschen und neu anlegen lassen immer.
Aber es gibt andere, die da Probleme haben. der wichtigste Punkt mit Charts aus rrd4j ist, dass zwingend jede Minute ein Wert persistiert werden muss, es reicht nicht bei Änderung zu persistieren. Weiter sollten sich die Werte in vernünftigen Regionen bewegen, wenn da Riesensprünge zwischen den Werten sind, kann das Erzeugen der Charts auch schief gehen.

Ansonsten kann ich Grafana als Frontend mit InfluxDB als Backend sehr empfehlen, das ist dann zwar nicht elegant in openHAB eingebunden, aber die Grafiken sind (gerade im Vergleich mit denen von openHAB) extrem schick und außerdem dynamisch (also Zoom in/out und wahlweise autorefresh)

Als Unterbau ist Java 6 wahrscheinlich nicht mehr gut geeignet, inzwischen sind wir ja schon bei Java 8 angekommen, ich meine mich zu erinnern, dass einige Bindings schon zwingend mindestens Java 7 voraussetzen, auch Oracle empfiehlt, immer eine aktuelle Version zu nutzen - erst recht auf potentiellen Angriffszielen, also an erster Stelle Rechnern mit Webdiensten.

[swissembedded]

Java 7 geht auch nicht, java 8 scheint zu gehen. Mal schauen. Danke für den Tip, ich dachte irgendwo gelesen zu haben man solle java 6 für openhab nehmen, weil es nicht mit 7 und 8 läuft.

[swissembedded]

Habe nun noch die Leistungsmessung vom Haushalt integriert und es hat nach einer Stunde wieder geklemmt, trotz java 8.
Persistance rrd4j sieht so aus, habe ich genau unter der Zeile mit der Temperature aus der Demo eingefügt:
Power*,Power_Chart* : strategy = everyMinute, restoreOnStartup
Energy*,Energy_Chart* : strategy = everyMinute, restoreOnStartup

[udo1toni]

Welche Hardware nutzt Du?

[swissembedded]

Danke für Deine Hilfe. Ich benutze folgendes D0 Lesegerät über Ethernet . http://www.solar-komplett.ch/de/swissEmbedded_EMDO101_Steuergeraet.a3037.2.htm
Das EMDO101 hat einen Autoread mode, dabei muss man nur eine Verbindung zum TCP/IP Port aufbauen und das Gerät fährt einen Lesezyklus nach IEC6205621 -21 Protocol Mode C. Das ganze habe ich mit einem Landis & Gyr Zähler getestet ohne Openhab mit Telnet sowie mit einem Testtool von Landis & Gyr. Ab und zu wird mal ein Zeichen falsch gelesen. Vielleicht alle 100 Lesungen. Das Gerät hat auch eine RS485, bin gerade dran einen Treiber für den Ego Smart Heater und Microwechselrichter mit Laderregler am Schreiben, damit kann man dann den Überschuss der Solaranlage entweder in die Batterie stecken und in den Wassertank.
Zusätzlich lese ich die Produktion der Solaranlage mit Openhab aus. Im Log scheinen die Werte aber alle ok.

Für die D0 Schnittstelle, habe ich den IEC6205621meter Binding von Openhab aufgebohrt, dieses unterstützt nun auch das Auslesen über Ethernet mit dem Gerät.
Das Setup ist die ganze Nacht durchgelaufen und ich sehe in der ganzen Nacht einen Lesefehler. Die daraus berechnete Leistung an einer Messung negativ. Habe nun die Validierung der Leistungswerte nochmals verbessert. Denke es liegt aber eher nicht an den Mechanismus selber.

Auf meiner Windoze 7 64 bit Kiste sehe ich aber auch bei der reinen Demo ab und zu Fehler bei der Temperaturkurve. Deshalb wird die wohl auch nicht immer dargestellt.
"Error during the execution of rule Set random room temperatures
java.lang.IllegalStateException: Could not invoke method: org.openhab.model.script.actions.BusEvent.postUpda te(org.openhab.core.items.Item,org.openhab.core.ty pes.State) on instance: null"

Wenn jetzt aber ein Minutenwert ungültig ist, sollte doch nicht die Kurve ein Problem sein? Bei den Tarifkurven sehe ich die Fehler nicht.

Was mir auch noch auffällt, ist das die Statistik nicht geht.Ich berechne nach Beispiel den TarifToday, quasi letzte Meterlesung Minus Messung um Mitternacht.
stopTarif1 = Tarif1.maximumSince(now.toDateMidnight).state as DecimalType
startTarif1 = Tarif1.minimumSince(now.toDateMidnight).state as DecimalType
tmp1 = (stopTarif1 - startTarif1)
postUpdate(Tarif1Today, tmp1)

da kommt immer 0 raus. Muss ich die Werte auch noch in db4o speichern, ist wohl ein anderes Problem?

[swissembedded]

Den db4o Eintrag scheint für den TarifToday notwendig, aber achtung everyChange und EveryHour hier als strategy ist anders wie beim rrd4j. die kurven frieren immer noch ein :-(

[udo1toni]

Also, die Tempertaurkurven könnten eventuell durch fehlerhafte Werte durcheinander geraten. Das ist in der Demo ja ein Zufallswert. In dem Moment, wo nicht für jede Minute mindestens ein Messpunkt zur Verfügung steht, klappt die Auswertung mit der Chartengine nicht, die ist auf feste Abstände angewiesen.
Wenn du maximumSince und MinimumSince benutzt, ist es eventuell wichtig, die Quelle der daten anzugeben. Wenn Du in der openhab.cfg db4o als default-Persistence definiert haben solltest, wird er sonst immer versuchen, dort die Werte abzurufen.

[swissembedded]

aha, da kommen wir der Sache näher. D.h. es wird wenn ein Minutenwert fehlt, nicht einfach der letzte Wert genommen? Der D0 Zähler wird zwar alle 60 Sekunden ausgelesen, aber das Auslesen geht halt ein paar Sekunden. Der Triggermechanismus retriggered scheinbar erst, sobald der Prozess abgeschlossen ist, d.h. die Werte kommen so vielleicht alle 70 Sekunden. Das würde erklären, wieso es immer ein paar Minuten geht (Kurven frieren wenn es mal geht nach ein paar Minuten wieder ein).
Was macht denn die Zeile in rrd4j genau? Ich dachte das schreibt einfach jede Minute den letzten Wert weg, wenn halt seit 2 Stunden der Wert nicht mehr aktualisiert worden ist, dann wird halt 120 Mal der gleiche Wert geschrieben?
Power*,Power_Chart* : strategy = everyMinute, restoreOnStartup

[swissembedded]

Habe die Frequenz nun auf 40 Sekunden erhöht, jetzt sieht es mit den Daten besser aus. Man müsste also einen Mechanismus basteln der mindestens einen Wert pro Minute generiert, egal ob neue Werte anliegen oder nicht. Schon etwas speziell :-(

[swissembedded]

Auch wieder hängen geblieben...