Persistenz für boolesche Werte mit OpenHAB

[Jesco]

Hallo,

ich habe erstmalig OpenHAB eingerichtet und dabei auch Persistenz unter Verwendung von JDBC/MariaDB eingerichtet.
(OpenHAB 3.0.1, JDBC Persistence MariaDB 3.0.1, MariaDB 10.3.27).
Mir ist dabei aufgefallen, dass binäre Werte (z.B. der Betriebszustand der Heizungspumpe) in der Datenbank als Typ 'VARCHAR' mit den Werten OPEN/CLOSED abgespeichert wird.
Das scheint mir nicht sehr effizient. Gibt es eine Möglichkeit das System so zu konfigurieren, dass die Daten als Boolean-Typ gespeichert werden?
Außerdem sind die Werte irreführend, ON/OFF wäre sinnvoller. In der Items-Datei lässt sich zwar ein Mapping einrichten, das hat aber keine Auswirkungen auf die Persistierung.

Danke und Gruß
Jesco

knx.things:

Code: Alles auswählen

Bridge knx:ip:bridge "KNX-IP-Interface" [
  < ... >
] {
    Thing device haustechnik [ ] {
        Type contact:  Pumpe_Heizkreis   "Status Heizkreispumpe"   [ ga="1.009:<7/482" ]
    }
}

knx.items:

Code: Alles auswählen

Contact Pumpe_Heizkreis  "Schaltzustand Heizkreispumpe [MAP(boolean_ein.map):%s]"  <pump> (gHaustechnik)   { channel="knx:device:bridge:haustechnik:Pumpe_Heizkreis" }

boolean_ein.map:

Code: Alles auswählen

CLOSED=aus
OPEN=ein
-=undefiniert
NULL=undefiniert

jdbc.persist:

Code: Alles auswählen

Strategies {
    default = everyChange
}
Items {
    gHaustechnik*: strategy = everyUpdate
}

[udo1toni]

Ein Contact hat nunmal den Zustand OPEN oder CLOSED. Wenn Du das Type Switch verwendest, hast Du ON und OFF als Zustände.

Hint: Die meisten Anwender denken, der Unterschied zwischen Contact und Switch bestünde darin, dass für Contact keine Schaltfläche in der Sitemap gezeichnet wird. das ist aber nur die halbe Wahrheit.

Contact bietet keine Commands, man kann also ein Contact Item nicht per sendCommand nutzen.
Switch wird Default als Schalter gerendert, man kann aber ohne weiteres ein Switch Item mittels Text Widget ohne Schaltfläche rendern lassen.

Man sollte nicht der Idee verfallen, dass Contact das "richtige" Format sei, nur weil man einen ReadOnly Zustand darstellen möchte.

[Jesco]

Danke für die Rückmeldung. Ein Wechsel auf Typ "Contact" bringt damit also schon mal eine Verbesserung. Gibt es zusätzlich auch die Möglichkeit, in der Datenbank direkt Binärwerte abzuspeichern?

[udo1toni]

Ein Wechsel auf den Typ Switch bringt Besserung

Die Datenbank speichert als varchar, weil weder ON/OFF noch OPEN/CLOSED die einzig möglichen Werte sind. Für beide Itemarten Switch und Contact (sowie alle anderen Itemarten) stehen mindestens noch die beiden Status NULL und UNDEV zur Verfügung.

[Jesco]

OK, danke für die nützlichen Informationen!

Ich habe noch eine weitergehende Frage:
Durch den Persistenz-Dienst werden in der Datenbank zum einen eine Tabelle 'items' angelegt (mit den Spalten 'ItemId' und 'itemname') und weiterhin pro Item eine Tabelle mit dem Namensschema 'item0001', 'item0002'.
Der Präfix 'item' wird wohl aufgrund der entsprechenden Konfiguration in meiner Konfigurationsdatei jdbc.cfg (s.u.) vergeben. Die Nummerierung ist offenbar konsekutiv in der Reihenfolge, in der zum ersten Mal ein Wert dieses Items in der Datenbank gespeichert werden soll.

Lässt sich dieses Datenbankschema konfigurieren? Z.B. so dass die Tabellen für die Items entsprechend dem Namen des Items benannt werden?

Aktuell sind nämlich itemname und Tabellenname nur recht lose über die 'ItemId' verknüpft und der Tabellenname muss durch String-Operationen aus der 'ItemId' konstruiert werden. Oder gibt es SQL-Operationen, die einem diese Arbeit abnehmen?

jdbc.cfg:

Code: Alles auswählen

url=jdbc:mysql://localhost:3306/OpenHAB?useSSL=false
user=openhab
password= ...
tableNamePrefix=item
tableIdDigitCount=0

[udo1toni]

Mit openHAB3 solltest Du die Datenbank über die UI konfigurieren können. Das sind letztlich die gleichen Einträge wie in der jdbc.cfg, nut in der UI integriert. Es gibt einen Eintrag Tablename Realname Generation, in der jdbc.cfg heißt der entsprechende Eintrag tableUseRealItemNames, wenn der Eintrag auf true steht, verwendet jdbc die echten Itemnamen statt dem Umweg über die Namenstabelle.

In dem Zusammenhang ist es hilfreich, zu wissen, dass die erste Generation für MySQL-Zugriff (und die die anderen unterstützten SQL-Datenbanken) genau dieses Tabellenformat verwendet haben, die Variante itemxxxx mit Übersetzungstabelle stellt also einen kompatiblen Zugriff dar. Ehe man die Tabellennamen umstellt, sollte man sich aber über die Konsequenzen im Klaren sein. Manch einer erstellt überaus lange Itemnamen, das führt dann natürlich zu überaus langen Tebellennamen. Je nach Konfiguration der dahinter laufenden Engine kann das zu Problemen führen.

[Jesco]

Super, vielen Dank für diese Information! Ich werde meine Datenbank entsprechend umstellen und mich bei der Länge der Itemnamen zurückhalten.