@crunchip
den Thread hatte ich nicht gefunden, danke für den Hinweis.
Den werde ich dann weiterverfolgen und hoffe auf eine Lösung durch den Entwickler.

Nach Update von 5.2.0 auf die aktuelle Version 6.1.2 kommt diese Meldung:

Cannot update connection info: TypeError: Cannot read properties of undefined (reading 'stream')

Nach Downgrade auf die Version 6.1.1 kommt diese Meldung:

Cannot update connection info: Error: The id "info.clients." is invalid. Ids are not allowed to end in "."

Nach Downgrade auf die Version 6.0.2 läuft es wieder fehlerfrei.

Getestet wurde das mit diesem Skript (ähnliche sind seit Jahren fehlerfrei gelaufen):

#!/usr/bin/env python
import paho.mqtt.client as mqtt

client = mqtt.Client()
client.connect("10.10.10.88", 1883, 60)

client.publish("test/Temperatur", "21 °C")
client.publish("test/Luftfeuchte", "70%")
client.publish("test/Windstaerke", "7 bf")
client.publish("test/Windrichtung", "NW")
client.publish("test/Wetter", "stuermisch")
client.publish("test/Bewoelkung", "sonnig")
client.disconnect()

Am Skript und der Konfiguration der Instanz gab es keine Änderungen. Eine Recherche brachte keine Ergebnisse zu den Meldungen.

Das Problem tritt bei einer Installation auf einem Raspberry Pi 5 als auch in einer VM in proxmox auf.

Die Einstellungen der Instanz:

iob_diag.txt

Muss in der neuen Version was anders konfiguriert werden?
Hat jemand eine Idee, warum das jetzt auf Fehler läuft?

@fritz-0
Aus Zeitgründen werde ich auf weitere Tests verzichten, außerdem bin ich mit einer eigenen Lösung mittels javascript unabhängiger und die Einrichtung/Erweiterung neuer Datenpunkte ist für mich einfacher.

Daher ist das Thema für mich beendet.

@homoran
das mit den Nachkomastellen ist nun mal so, kann ich mit leben.

Ich werde jetzt versch. Konfigurationen testen und schauen, ob da eine für mich passend ist.
Sollte das nicht der Fall sein werde ich eine Datenübernahme (alle 60s/300s) auf einen Datenpunkt unter 0_Userdata durchführen.

Damit ist die Sache hier im Forum erstmal für mich beendet, ich werde das Ergebnis dann hier nochmal schreiben.

Ich danke Euch für die Anregungen und Hinweise, die mir mehr Verständnis für iobroker gebracht haben.

@homoran

es geht nicht um die Nachkommastellen an sich, sondern, dass jede Änderung an der zwriten Nachkommastelle ein logging auslöst.

Die Daten kommen von einem shelly. Auf der Konfigurationsseite vom shelly wird der Wert ohne Nachkommastellen angezeigt, aber ich kann nicht einstellen, das ein Wert ohne Nachkommastellen per MQTT gesendet werden soll. Die "Genauigkeit" des Wertes wird nicht benötigt, kann ich aber nicht abstellen.

In der Doku zum SQL-Adapter (V 3.0.1) zu den Einstellungen auf der Seite der Verbindung zur DB habe ich das gefunden:

Round real to: Number of digits after the comma.

Ich verwende die aktuelle Adapter Version 3.0.1 und da finde ich diese Konfigurationsmöglichkeit nicht. Auf einem alten iobroker-System läuft noch die Version 1.9.5 (ein Update lohnt sich nicht, das System wird abgelöst), und da gibt es diesen Punkt noch.

Weisst Du was darüber? Aber vermutlich würde das auch nicht helfen zu Deiner Aussage wegen der Nachkommastellen

@dr-bakterius sagte in <gelöst> SQL-Adapter benutzt Blockzeit nicht:

Dann hake mal 'Nur Änderungen aufzeichnen' an.

Das hatte ich vorher aktiviert, aber inzwischen habe ich verschiedene Konfigurationen versucht, das ich da langsam durcheinander komme ...

@homoran sagte in <gelöst> SQL-Adapter benutzt Blockzeit nicht:
obige Aussage auch als Antwort auf Deine Anmerkung

das ist ja jetzt nicht mehr was du bisher hattest!

@homoran sagte in <gelöst> SQL-Adapter benutzt Blockzeit nicht:

Die Frage ist auch ob du alle Werte auf 10mW genau loggen willst.

das muss ich nicht, ich habe nur keinen Punkt gefunden, wo ich das für die Protokollierung "aufrunden" kann, ich habe nur das dazu gesehen:

Runden Sie bei der Abfrage die Zahlen auf

aber das greift ja nicht beim protokollieren....
Wie lässt sich das mit den Nachkommastellen abstellen?

Wäre es nicht evtl. sinnvoll, hier einen Wert einzustellen?

Das würde die Anzahl der zu protokollierenden Sätze doch auch reduzieren, oder?

Ich werde jetzt mal strukturierter vorgehen und verschiedene Konfigurationen probieren und genauer protokollieren, welche Konfiguration welche Daten protokolliert. Da wäre es hilfreich, wenn ich einen Hinweis bekommen würde, wie sich Nachkommastellen verhindern lassen.

@homoran

Dementsprechend trägst du bei dem Menüpunkt den passenden Wert ein.

Bei welchem Menüpunkt? Hast Du da mal ein Beispiel für mich?

Aktuell habe ich das jetzt so konfiguriert:

In den Verlaufsdaten seht das jetzt so aus:

Und in der Datenbank so:

+---------------------+-------+
| TimeStamp           | val   |
+---------------------+-------+
| 14.09.2024 08:17:04 | 19.11 |
| 14.09.2024 08:15:55 | 20.84 |
| 14.09.2024 08:14:51 | 18.76 |
| 14.09.2024 08:13:45 | 20.49 |
| 14.09.2024 08:12:40 |  18.7 |
| 14.09.2024 08:11:35 | 18.32 |
| 14.09.2024 08:10:32 | 19.35 |
| 14.09.2024 08:09:30 |  18.3 |
| 14.09.2024 08:08:26 | 17.98 |
| 14.09.2024 08:07:25 | 18.69 |
+---------------------+-------+

Ich werde das jetzt erstmal so laufen lassen, wenn mir das (z. B. im Chart) nicht gefällt werde ich auf meine Lösung per javascipt zurückgreifen. Ich werde mir auch überlegen, ob der 60s Intervall wirklich notwendig ist, evtl. gehe ich auf 5 Minuten.

@homoran
wie kann ich das abstellen?

@homoran

Dazu die Einträge in der Datenbank:

| 13.09.2024 13:39:49 | 139.74 |
| 13.09.2024 13:39:35 | 282.99 |
| 13.09.2024 13:38:35 | 282.99 |
| 13.09.2024 13:38:35 | 301.15 |
| 13.09.2024 13:37:35 | 301.15 |
| 13.09.2024 13:37:35 | 298.33 |
| 13.09.2024 13:36:35 | 298.33 |
| 13.09.2024 13:36:35 | 299.15 |
| 13.09.2024 13:35:35 | 299.15 |
| 13.09.2024 13:34:54 | 297.62 |
| 13.09.2024 13:33:54 | 297.62 |
| 13.09.2024 13:33:45 | 238.71 |
| 13.09.2024 13:32:45 | 238.71 |
| 13.09.2024 13:32:42 | 272.59 |
| 13.09.2024 13:31:42 | 272.59 |
| 13.09.2024 13:31:35 | 286.09 |
| 13.09.2024 13:30:35 | 286.09 |
| 13.09.2024 13:30:10 | 281.71 |
| 13.09.2024 13:29:10 | 281.71 |
| 13.09.2024 13:29:05 | 171.23 |
| 13.09.2024 13:28:05 | 171.23 |
| 13.09.2024 13:28:05 | 309.13 |
| 13.09.2024 13:27:05 | 309.13 |
| 13.09.2024 13:27:05 |  309.3 |
| 13.09.2024 13:26:05 |  309.3 |
| 13.09.2024 13:26:05 |  308.7 |
| 13.09.2024 13:25:05 |  308.7 |
| 13.09.2024 13:25:05 | 320.16 |
| 13.09.2024 13:24:05 | 320.16 |
| 13.09.2024 13:24:05 | 320.63 |
| 13.09.2024 13:23:05 | 320.63 |
| 13.09.2024 13:23:05 | 250.64 |

Das sieht so aus, dass die Werte der Verlaufsdaten identisch in die DB laufen, unabhängig von der Quelle. Wenn der Wert gleich ist wird nur ein Wert pro Minute protokolliert, bei Änderungen werden ggf. ein weiterer Werte protokolliert, was ich geshen habe aber kein zweiter geändert Wert inenrhalb von 60s, d.h. das mit der Blockzeit scheint zu funktionieren.

@homoran said in <gelöst> SQL-Adapter benutzt Blockzeit nicht:

Auch hier wäre die Liste aus der Konfiguration für SQL im Datenpunkt interessant

Die Speicherung von Werten alle 60s ist historisch bedingt. Seit mehreren Jahren lese ich alle 60s Daten der PV-Anlage und Heizung (bisher über einen Mix von Shellskripten und python-Skripten) aus, dafür habe ich zahlreiche Auswerteprogramme. Das auslesen und auswerten stelle ich gerade auf iobroker um, da möchte ich grundsätzlich nichts an dem Intervall ändern (auch wenn ich weniger protokollieren könnte).

Auf Deine Frage:

Auch hier wäre die Liste aus der Konfiguration für SQL im Datenpunkt interessant

würde ich Dir gerne antworten, wenn ich wüßte was genau ich Dir an Infos geben soll.
Soll die Liste ein Auszug zum Datenpunkt aus der DB sein? Passend zum Datenpunkt aus der Konfiguration vom SQL-Adapter? Oder meinst Du damit was ganz anderes?