SQL-Adapter speichert keine Werte von Alias-Datenpunkten
-
Da ich mit Lovelace experimentiere, habe ich mir den Alias-Adapter installiert, da der dort manchmal hilfreich ist. Die Idee, mir einen Datenpunkt zu spiegeln, um bei Bedarf auch das Gerät dahinter tauschen zu können, ohne eine neue Zeitreihe beginnen zu müssen, finde ich auch sehr praktisch.
Allerdings funktioniert das nicht so, wie gedacht. Ich habe für ein Raumthermostat ein Alias mit mehreren Datenpunkten erstellt, die von Datenpunkten des Thermostats und von einem Skript gespeist werden. Die Werte werden auch übernommen, soweit sieht das gut aus:
Wenn ich nun neben dem Objekt das Zahnrad anklicke, kann ich sie dort auch für den SQL-Adapter aktivieren:
Bei allen "normalen" Objekten klappt das auch seit jeher problemlos, die Daten werden schön in die MySQL geschrieben. Nur bei meinen neuen Alias-Objekten passiert leider nichts. Außer einem initialen "null" zu dem Zeitpunkt, als ich SQL aktiviert habe, schreibt er nichts in die DB:
Woran kann das liegen?
-
@bfit sagte in SQL-Adapter speichert keine Werte von Alias-Datenpunkten:
Außer einem initialen "null"
wieso denn null?
passt der Datentyp? -
@homoran Keine Ahnung, wieso "null". Das Alias ist wie folgt definiert – also als "number":
{ "type": "state", "common": { "name": "Temperatur", "role": "value.temperature", "type": "number", "unit": "°C", "read": true, "write": true, "alias": { "id": "bshb.0.roomClimateControl_hz_9.TemperatureLevel.temperature" }, "custom": { "lovelace.0": { "enabled": true, "entity": "sensor", "name": "raum_technik_temperature", "attr_mode": "box", "attr_unit_of_measurement": "°C", "attr_device_class": "temperature" }, "sql.0": { "enabled": true, "storageType": "", "counter": false, "aliasId": "", "debounceTime": 0, "blockTime": 0, "changesOnly": false, "changesRelogInterval": 0, "changesMinDelta": 0, "ignoreBelowNumber": "", "disableSkippedValueLogging": false, "retention": 0, "customRetentionDuration": 365, "maxLength": 0, "enableDebugLogs": false, "debounce": 1000 } } }, "_id": "alias.0.raum.technik.temperature", "native": {}, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" }, "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1701293808998 } -
@bfit sagte in SQL-Adapter speichert keine Werte von Alias-Datenpunkten:
"sql.0": {
storageType": "", -
@homoran Hm, ok. Was sollte da drin stehen? Ich hab gerade mal stichprobenartig nachgeprüft: Bei allen anderen "normalen" Datenpunkten, die der SQL-Adapter erfolgreich wegschreibt, ist der storageType auch leer
-
Bei mir sind die auch leer, vermutlich wenn der Typ auf Automatisch steht.
Schau doch mal, ob der Datenpunkt in der Datenbank aufgeführt ist.
Es gibt eine Tabelle "datapoints" da müsste er drinnen stehen.
Hatte was ähnliches mal, als ich Daten per Skript in die DB schreiben wollte.
-
@david-g Ja, die Datenpunkte gibt es in der MySQL-DB:
In der Tabelle ts_numbers zeigt sich allerdings das selbe Bild, wie im ioBroker: Nur eine Handvoll null-Werte:
Ich habe mittlerweile noch ein weiteres Alias (Zirkulationspumpe.Power) angelegt und dabei auch explizit darauf geachtet, dass von vornherein alle Types richtig gesetzt sind. Das holt sich die Werte aus einem Shelly-Messgerät. Auch dort gibt es einen ominösen null-Wert, allerdings auch einen richtigen:
Dabei ist mir etwas kurioses aufgefallen: Solange ich den Reiter "Verlaufsdaten" offen habe, tauchen dort auch neue Zeilen mit Werten auf (siehe nächster Screenshot oberste Zeile). Sie sind allerdings wieder verschwunden, sobald ich auf einen anderen Reiter gehe und zurück. Auch in der MySQL-DB landen sie nicht:
-
@bfit sagte in SQL-Adapter speichert keine Werte von Alias-Datenpunkten:
Das Alias ist wie folgt definiert – also als "number":
das heisst aber nicht, dass der Wert der da hinein geschrieben wird auch vom selben Typ ist.
-
@homoran Ich steh gerade auf dem Schauch – worauf willst du hinaus?
Mein neues Alias "Zirkulationspumpe.Power" hat folgende Objektdaten:
{ "type": "state", "common": { "name": "Power", "role": "value.power", "type": "number", "unit": "W", "read": true, "write": false, "alias": { "id": "shelly.0.shellyplusplugs#d4d4daf51a80#1.Relay0.Power" }, "custom": { "lovelace.0": { "enabled": true, "entity": "sensor", "name": "Zirkulationspumpe_Power", "attr_unit_of_measurement": "W", "attr_device_class": "power" }, "sql.0": { "enabled": true, "storageType": "", "counter": false, "aliasId": "", "debounceTime": 0, "blockTime": 0, "changesOnly": true, "changesRelogInterval": 0, "changesMinDelta": 0, "ignoreBelowNumber": "", "disableSkippedValueLogging": false, "retention": 1209600, "customRetentionDuration": 365, "maxLength": 0, "enableDebugLogs": false, "debounce": 1000 } } }, "_id": "alias.0.Zirkulationspumpe.Power", "native": {}, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" }, "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1701438899399 }Und das Objekt des Originalgerätes (Shelly Plus Plug S) sieht folgendermaßen aus (hier kann ich die Objektdaten so nicht öffnen, da das Objekt vom Shelly-Adapter erstellt wird):
Die sind doch beides "Number", oder? Bei diesem Alias hat er ja sogar (siehe oben) schon einmal einen Zahlenwert in die Datenbank geschrieben – nur leider seitdem keinen weiteren, obwohl er sich mehrfach geändert hat.
-
Ich glaube, ich komme langsam dahinter: Wenn bisher der Wert des "Original"-Objekts per SQL-Adapter protokolliert wurde, und künftig nur noch der Wert des Alias-Objekts, dann braucht der SQL-Adapter einen Neustart. Die ersten Alias-Werte bekomme ich mittlerweile protokolliert. Ich beobachte weiter.
-
@bfit sagte in SQL-Adapter speichert keine Werte von Alias-Datenpunkten:
Die sind doch beides "Number", oder?
wie gesagt, den Typ den du dem Datenpunkt gibst muss nicht der Typ sein, der dort hineingeschrieben wird.
So kann ein "Zahlenwert" per MQTT trotzdem als String kommen. Oder per Skript das selbe.Dies wird allerdings seit einiger Zeit im Log angemeckert.
-
@bfit Ich hatte eben das gleiche Problem. Ich hatte aber am originalen Datenpunkt kein Logging an. Ich musste aber auch erst den SQL-Adapter neu starten, damit er loggt.
