Jetzt habe ich noch folgende Meldungen im Logfile:

ebus.0 2025-01-22 14:44:36.239 warn sent read -f -c sc D2Temp, received ERR: invalid position in decode for {"active":true,"circuit":"sc","name":"D2Temp","parameter":""} please check ebusd logs for details!
ebus.0 2025-01-22 14:44:35.471 warn sent read -f -c sc D1Temp, received ERR: invalid position in decode for {"active":true,"circuit":"sc","name":"D1Temp","parameter":""} please check ebusd logs for details!

2025-01-22 14:44:34.653 [bus info] send message: 31ecb509030d0200

2025-01-22 14:44:34.760 [bus error] send to ec: ERR: wrong symbol received, retry

2025-01-22 14:44:35.470 [update info] sent MS cmd: 31ecb509030d0200 / 00

2025-01-22 14:44:35.471 [update error] unable to parse read sc D1Temp from 31ecb509030d0200 / 00: ERR: invalid position

2025-01-22 14:44:35.471 [main error] read sc D1Temp: decode ERR: invalid position

2025-01-22 14:44:35.472 [bus info] send message: 31ecb509030d0800

2025-01-22 14:44:36.237 [update info] sent MS cmd: 31ecb509030d0800 / 00
2025-01-22 14:44:36.237 [update error] unable to parse read sc D2Temp from 31ecb509030d0800 / 00: ERR: invalid position

2025-01-22 14:44:36.238 [main error] read sc D2Temp: decode ERR: invalid position

2025-01-22 14:44:36.239 [network info] [00053] connection closed

Hat jemand einen Tipp für mich ?

@marc-berg
Danke für deinen Tipp.
DAS hat geholfen.

Ich bin wie folgt vorgegangen:

Die Instanz ebus.0 habe ich im iobroker gestoppt.
Den Dienst ebusd habe ich mit "sudo service ebusd stop" auf den Betriebssystemconsole beendet.
Nun habe ich in den Objekten des iobrokers die nicht gewünschten Datenpunkte entfernt.
Dann den Dienst ebusd mit "sudo service ebusd start" auf den Betriebssystemconsole gestartet.
Anschließend die Instanz ebus.0 im iobroker wieder gestartet.

Auch nach einiger Wartezeit (ca. 2 Stunden) wurden die o.g. Objekte nicht mehr im Protokoll angezeigt.

@leonundjulie
Das Verhalten ist bei meiner Installation genau so.
Ich habe den Entwickler des Adapters auf Github gefragt:
https://github.com/rg-engineering/ioBroker.ebus/issues/391

Ich bin auf die Antwort gespannt.

AndreasW63 created this issue in rg-engineering/ioBroker.ebus

open warn no update since #391

Hallo leonundjulie,

ist der Wert "signofile" in deiner ebus Instanz eingetragen?

Bei meiner Installation ist es so, das im Logfile nur Werte "angemerkt" werden, die mal eingetragen waren aber mittlerweile entfernt wurden !!!!

Gruß Andreas

Hallo leonundjulie,

danke für deine Antworten.

Wenn ich es richtig sehe, wird der eine Port zum Lesen der Daten verwendet:
"HTTP Port zum Lesen von Daten" = 8889
"TCP (Telnet) Port Schreiben von Daten" = 8888

Grundsätzlich kann ich die erforderlichen Datenpunkte auslesen.

Ich habe das Problem, das bei entfernte Datenpunkten der Hinweis im Protokoll
des iobroker steht, das die Aktualisierung schon einige Tage her ist.
Diese Datenpunkte sind in der Instanz des Adapters NICHT eingetragen.

Gruß Andreas

Hallo,

ich setzte den ebus Adapter in der Version 3.38 auf meinem iobroker ein.

Mir fällt auf, das folgende Datenpunkte mit einer Warnmeldung im Protokoll stehen.
ebus.0 2025-01-19 12:27:30.399 warn no update since 17.1.2025, 20:48:16 v32.messages.HeatRecovery.lastup
ebus.0 2025-01-19 12:27:30.377 warn no update since 17.1.2025, 20:48:15 v32.messages.FrostProtectionElement.lastup
ebus.0 2025-01-19 12:27:30.203 warn no update since 17.1.2025, 20:50:02 v32.messages.BypassMaxDiffTemp.lastup
ebus.0 2025-01-19 12:27:27.161 warn no update since 16.1.2025, 09:52:16 700.messages.HwcStorageTempTop.lastup
ebus.0 2025-01-19 12:27:27.131 warn no update since 16.1.2025, 17:53:20 700.messages.HwcStorageTempBottom.lastup
ebus.0 2025-01-19 12:27:27.070 warn no update since 16.1.2025, 09:52:17 700.messages.HcStorageTempTop.lastup
ebus.0 2025-01-19 12:27:27.039 warn no update since 16.1.2025, 09:52:17 700.messages.HcStorageTempBottom.lastup
ebus.0 2025-01-19 12:27:26.626 warn no update since 18.1.2025, 20:03:46 700.messages.AdaptHeatCurve.lastup

Diese Datenpunkte hatte ich zum Testen mal konfiguriert, aber wieder entfernt.
Ich habe in der Instanz ebus.0 die Konfiguration gespeichert, den Adapter deinstalliert, geprüft ob alle Objekte entfernt wurden
und anschließend den Adapter erneut installiert.
Zunächst habe ich die Konfiguration wieder importiert, jedoch blieben die Warnmeldungen im Protokoll erhalten.
Daher den Adapter noch mal deinstalliert und von Hand neu konfiguriert.
Das macht es leider auch nicht besser.
Die Warnmeldungen der entfernten Datenpunkte bleiben erhalten.

Hat hier jemand eine Idee?

Gruß aus dem sonnigen OWL
Andreas

@plchome-0
danke für deine Antwort.

Ich nutze die Version v0.1.5 und verwende
den Datenpunkt intex.0.localtcp.control.Heat zum Steuern der Heizung

@homoran

danke für den Hinweis.
Ich werde das weiterverfolgen

Wenn PV-Überschuss vorhanden ist, wird die Heizung unseres Intex Pools eingeschaltet, aber nach ca. 15 Sekunden wieder abgeschaltet.
Hier ein Auszug aus dem Protokoll des Datenpunktes der geschaltet wird.

Hat jemand eine Erklärung dazu?

@paul53
Hallo,

ich kriege das Blockly nicht sauber zum Laufen....

Wenn Überschuß vorhanden ist, wird die Heizung unseres Intex Pools eingeschaltet, aber nach ca. 15 Sekunden wieder abgeschaltet.
Hier ein Auszug aus dem Protokoll des Datenpunktes der geschaltet wird.

Hat jemand eine Erklärung dazu?