Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[apollon77]

Was meinst Du genau damit?

[Issi]

@apollon77 sagte in Adapter SQL - Einstellungen:

Was meinst Du genau damit?

wenn du damit mich meinst hab die selben einstelungen bei History-Adapter probirt und dan Storage Vorhaltezeit gewechselt während der laufzeit und er hat nicht angefangen zu logen so wie der SQL adapter

[paul53]

@apollon77 sagte am 13.4.2017:

Wenn innerhalb der Entprellzeit ein neuer Wert kommt, gilt der letzte Wert als "Nicht stabil" und die Entprellzeit wird für den neuen Wert neugestartet.

Der Neustart bei jeder Änderung erfolgt im History-Adapter, nicht aber im SQL-Adapter. Im SQL-Adapter läuft der Timer / Zähler weiter und gibt nach Zeitablauf wieder frei.

[apollon77]

ok. AUch eine wichtige Info. Also es geht alles korrekt bei history, aber sql nicht

[paul53]

@apollon77 Schau Dir mal die Änderung vom 10.Oktober 2018 an:

        if (timeoutTriggered) sqlDPs[_id].timeout = null;

[apollon77]

Das ist egal. wenn ein Timeout gesetzt ist dann läuft der auch wenn man da "null" setzt. Da geht es nur um korrekte Werte.

Meine Vermutung geht eher dahin das bei einem Object change die Werte ncht sauber korrekt eu initsialisiert werden und damit debounce vllt gar nicht gesetzt ist oder so

[paul53]

@apollon77 sagte:

wenn ein Timeout gesetzt ist dann läuft der auch wenn man da "null" setzt.

Ja, aber clearTimeout() wird vor setTimeout() nicht mehr ausgeführt.

            if (sqlDPs[id].timeout) clearTimeout(sqlDPs[id].timeout);

Wann ist diese Bedingung erfüllt ?

if (_settings) {

[apollon77]

@paul53 zu 1.) ja, würde maximal dazu führen das zwei Timer laufen. Daher die obige Änderung weil sonst fälschlicherweise Timer vergessen wurden weil immer auf "null" gesetzt wurde auch wenn es direkt aufgerufen wurde.

zu 2.) Sobald das "eine Wert" hat (also !== null && !== undefined && !==false) .. in dem Fall ist es dann ein Objekt

[paul53]

@apollon77 sagte:

zu 2.)

Das ist mir klar, aber was ist der Inhalt von ?

    var _settings = sqlDPs[_id][adapter.namespace];

[apollon77]

Das sind die Datenpunkt Spezifischen Einstellungen der sql Instanz. also das im Objekt unter common.custom["sql.0"]

[dtp]

Vielleicht darf ich mich hier mal ranhängen, obwohl ich ein etwas anderes Problem mit dem SQL-Adapter habe.

Ich beschreibe mit dem Adapter eine mariaDB-10-Datenbank auf meiner DiskStation. Kürzlich habe ich nun wegen Umstellung auf einen anderen Docker-Container (über Portainer mit MACVLAN) die IP-Adresse meines ioBroker ändern müssen. Die IP der mariaDB-10-Datenbank blieb gleich. Mir wird auch ein OK im SQL-Adapter angezeigt, wenn ich die Verbindung zur Datenbank überprüfe. Mein Problem ist aber, dass seit der Umstellung keine Datenpunkte mehr geloggt werden. Einmalig nach dem Neustart wird zwar ein neuer Wert geschrieben, aber das war's dann auch. Danach passiert nichts mehr. Nun muss ich wohl die komplette ioBroker-Datenbank unter phpMyAdmin löschen und neu anlegen.

Ist das Verhalten bekannt? Handelt es sich ggf. um einen Bug?

[apollon77]

Also wenn beim test ok kommt hat er Zugriff; ebenso wenn er einen Wert schreibt. Von daher sollte alles passen und es ist kein Bug bekannt der soetwas allein verursachen würde.
Im Log irgendwas hilfreiches? Debug Log? Das sagt an sich auch einiges ob und wann und warum ggf nicht etwas geloggt wird.

[dtp]

@apollon77: Das Problem scheint nicht der SQL-Adapter zu sein, sondern es scheint an den hm-rpc-Instanzen zu liegen, die ihre Zustände nicht aktualisieren. Hat sich also vorerst erledigt. Danke trotzdem für die schnelle Reaktion.

Gruß,

Thorsten

[apollon77]

Dann schau mal da da die "Callback Adresse" im Adapter korrekt eingestellt und der Port durchgeschleift wird!