Problem mit mapdb <> jdbc

[int5749]

Hallo zusammen,

ich habe mehrere Datenbanken konfiguriert, unter anderem natürlich MapDB für den letzten Status eines Items und dann z.B. noch JDBC für meine Anwesenheitssimulation und Energiedaten. Im Grundsatz funktioniert das alles auch eine ganze Weile, bis dann auf einmal meine JDBC Datenbank mit Items geflutet wird, nämlich alles auch der MapDB. Im Anschluß ist die JDBC Abfrage dann (warum auch immer) berfordert, das richitge Item für die Anwesenheitssimulation zu finden :-/
Parallel laufen noch influx, rrd4j und natürlich die logging; bei diesen DBs konnte ich bisher keine Probleme feststellen

Der default für persistence ist als rrd4j konfiguriert.

Items meiner jdbc.persist

Code: Alles auswählen

Strategies {
	everyMinute	: "0 * * * * ?"
	everyHour 	: "0 0 * * * ?"
	everyDay 	: "0 0 0 * * ?"
	everyMidnight 	: "50 59 23 * * ?"

	// if no strategy is specified for an item entry below, the default list will be used
	default = everyChange
}

Items {
	gLights_auto* : strategy = everyChange,restoreOnStartup //Items für die Simulation

	House_EnergyIn : strategy = everyMinute,restoreOnStartup
	House_EnergyOut : strategy = everyMinute,restoreOnStartup
	House_Energy_Chart* : strategy = everyMidnight,restoreOnStartup
	House_Energy_Import_Day : strategy = everyMidnight,restoreOnStartup

	GhostMode : strategy = everyChange,restoreOnStartup
}

Hier stellt sich mir jetzt die Frage: Warum landen in der JDBC.DB auf einmal Items mit Status aud der MapDB??

[udo1toni]

Vermutlich wird zu irgendeinem Zeitpunkt die jdbc.persist "vergessen". In der Folge gibt es keine Konfiguration für die Persistence mehr und folglich werden alle Items persistiert.

Es war eine ganz dumme Idee, 1. rrd4j unsichtbar zu installieren und 2. eine nicht vorhandene Konfiguration als "persistiere einfach alles!(!!)[!!!!]" zu interpretieren, nur weil es neue Anwender gibt, die nicht verstehen, dass eine Persistence zunächst eingerichtet werden muss.

Sorry für den Rant, hilft hier nicht, musste aber gerade mal raus...
Mein Tipp: Mach einen Issue dazu auf, es ist ein Fehlverhalten von openHAB (welches sehr gut erklärbar ist, mit shitty Entscheidungen der Entwickler beim Übergang auf OH3)

[int5749]

Vermutlich wird zu irgendeinem Zeitpunkt die jdbc.persist "vergessen". In der Folge gibt es keine Konfiguration für die Persistence mehr und folglich werden alle Items persistiert.

Oh, das ist Mist.

Es war eine ganz dumme Idee, 1. rrd4j unsichtbar zu installieren und 2. eine nicht vorhandene Konfiguration als "persistiere einfach alles!(!!)[!!!!]" zu interpretieren, nur weil es neue Anwender gibt, die nicht verstehen, dass eine Persistence zunächst eingerichtet werden muss.

Das ist ausnahmsweise mal ein Schih, der mir nicht passt.

Sorry für den Rant, hilft hier nicht, musste aber gerade mal raus...
Mein Tipp: Mach einen Issue dazu auf, es ist ein Fehlverhalten von openHAB (welches sehr gut erklärbar ist, mit shitty Entscheidungen der Entwickler beim Übergang auf OH3)

OK, dann suche ich mal ein passendes Unterforum. => Reported here => openHAB Community

[udo1toni]

Das ist ausnahmsweise mal ein Schuh, der mir nicht passt.

Das Ding ist halt, es ist eine Abkehr von der früheren Regel, dass nichts installiert wird, was der Anwender nicht explizit ausgewählt hat.
Die DSL z.B. ist Teil von Core, da gibt es nichts zu installieren, also ist sie automatisch dabei.
Früher(tm), also bei OH2, gab es die verschiedenen Voreinstellungen (kannst Du Dich bestimmt auch noch dran erinnern, expert, basic usw.), wo dann halt bestimmte Module als Vorauswahl installiert wurden, ABER diese wurden dann auch alle entsprechend angezeigt.
Bei der Persistence wurde aber mit OH3 einfach rrd4j installiert, ohne es als installiertes Modul anzuzeigen. Weiter wurde es als Default gewählt, ohne dass dies in den Einstellungen ersichtlich gewesen wäre. Immerhin wird jetzt zumindest angezeigt, dass rrd4j installiert ist.
Ob man es deinstallieren kann, habe nicht ausprobiert, ich nutze es ja auch selbst, aber es ist halt nicht sauber, genau wie die Sache mit der rrd4j.persist - sicher unter OH3 aus der Not geboren, dass es noch keine Möglichkeit gab, die Konfiguration über die UI zu erledigen. Wobei selbst der Zustand jetzt noch weit davon entfernt ist, dass man das als userfriendly bezeichnen könnte, aber zumindest kann der Anwender über die UI zugreifen.