wichtiges UPDATE für controller 7.2.2 im stable

[Kusselin]

@mcm1957 sagte:

@Kusselin sagte:

Könnt Ihr Experts da was erkennen, ob da was zu oft abgerufen wird??

In welchem Script liest du daten vom Shelly?

im ersten Script hier:

const SHELLY_PREFIX = 'shelly.1.shellypro3em#34987a467c54#1';
// Beispiel: 'shelly.0.shellypro3em-aabbccddeeff'

[mcm1957]

@Kusselin sagte:

@mcm1957 sagte:

@Kusselin sagte:

Könnt Ihr Experts da was erkennen, ob da was zu oft abgerufen wird??

In welchem Script liest du daten vom Shelly?

im ersten Script hier:

const SHELLY_PREFIX = 'shelly.1.shellypro3em#34987a467c54#1';
// Beispiel: 'shelly.0.shellypro3em-aabbccddeeff'

Ja grad gesehen. Da liest du eh vom Adapter und nicht vom Shelly direkt.

[Homoran]

@Kusselin sagte:

Das ist aber nicht schlimm

Aber wenn du dir die Timestams ansiehst, sind da nur 3 sekunden zwischen den Abrufen.

[Kusselin]

@mcm1957 sagte:

@Kusselin sagte:

@mcm1957 sagte:

@Kusselin sagte:

Könnt Ihr Experts da was erkennen, ob da was zu oft abgerufen wird??

In welchem Script liest du daten vom Shelly?

im ersten Script hier:

const SHELLY_PREFIX = 'shelly.1.shellypro3em#34987a467c54#1';
// Beispiel: 'shelly.0.shellypro3em-aabbccddeeff'

Ja grad gesehen. Da liest du eh vom Adapter und nicht vom Shelly direkt.

Genau..soviel erkenne ich auch...aber das ist doch o.k. - das was da der shelly support schreibt das ich direkt vom shelly 3em pro abrufe ist doch dann faslch....ich rufe lt. script vom shelly.1 adapter ab...richtig?

@Homoran sagte:

@Kusselin sagte:

Das ist aber nicht schlimm

Aber wenn du dir die Timestams ansiehst, sind da nur 3 sekunden zwischen den Abrufen.

kann ich das ändern irgendwie ? also in den Objekten oder so?

[mcm1957]

Der Shelly sendet praktisch im Sekundenabstand neue Daten. Das ist an sich normal und ok. Das kann ihn nicht überlasten, da diese Funktion vom Shelly aus geht.
Die Skripts sehen für mich - in Bezug auf Shelly - unkritisch aus. Dass da bei jeder Änderung der Shelly Werte einige lokale Werte neu berechnet werden sollte nur den ioBroker host belasten.

Ev. sieht man in einem vollständigen Log der Shelly Instanz /= Log ab starten der Instanz bis zum unerwarteten Restart des Shellies) mit level DEBUG mehr.

[Negalein]

@Kusselin sagte:

sorry @mcm1957 das kann ich nicht....also so drinn im thema bin ich da leider nicht.

dann sag das der KI.
Erklär ihr alles GENAU wie du es braucht.

[Kusselin]

Hier die letzte Nachricht vom Shelly Support:

die von Ihnen zitierte allgemeine Aussage des Adapter-Entwicklers ändert nichts an den im konkreten Fall vorliegenden Diagnosedaten.

In den übermittelten Protokollen ist eindeutig erkennbar, dass der Shelly in sehr kurzen Abständen eingehende MQTT-Nachrichten aus Ihrem Netzwerk erhält. Der Adapter-Entwickler kennt weder Ihre vollständige ioBroker-Konfiguration noch Ihre Skripte, Instanzen, MQTT-Topics oder die konkreten Logdaten dieses Gerätes. Eine pauschale Aussage zum üblichen Verhalten des Adapters kann daher die tatsächlich protokollierte Kommunikation in Ihrer Installation nicht widerlegen.

Ob diese Nachrichten durch den Adapter selbst, ein Skript, eine weitere Instanz, eine fehlerhafte Konfiguration oder ein anderes System erzeugt werden, können wir nicht beurteilen. Dies muss innerhalb Ihres Drittanbietersystems beziehungsweise anhand der Broker- und ioBroker-Protokolle geprüft werden.

Der Shelly wird durch diese ungewöhnlich hohe Anzahl eingehender MQTT-Nachrichten, teilweise in Abständen im Millisekundenbereich, erheblich belastet. In den Protokollen wird dabei sogar eine überlaufende Warteschlange gemeldet. Dies führt dazu, dass das Gerät zeitweise nicht mehr reagiert und abstürzt. Ein Gerätefehler lässt sich aus den vorliegenden Diagnosedaten hingegen nicht ableiten.

Bitte prüfen Sie daher in Ihrem MQTT-Broker beziehungsweise in ioBroker:

    welche Clients Nachrichten an die Topics des Shelly senden,
    welche Skripte oder Automationen diese Nachrichten auslösen,
    ob mehrere Adapter oder Instanzen gleichzeitig auf dasselbe Gerät zugreifen,
    welche Polling (Abfrage) Intervalle konfiguriert sind
    und ob sich die Nachrichtenrate nach dem Deaktivieren der MQTT-Integration normalisiert.

Da die Ursache nach aktuellem Stand außerhalb des Shelly-Gerätes liegt und innerhalb des verwendeten Drittanbietersystems geprüft werden muss, werden wir den Vorgang an dieser Stelle schließen.

[Kusselin]

@homoran : Wie kann ich in dem Script das "Timestamp" ändern?

[Negalein]

@Kusselin sagte:

Timestamp

welchen Timestamp? Bzw., was verstehst du unter Timestamp?

[Kusselin]

Ha das kommt weiter oben von @homoran

[Negalein]

@Kusselin sagte:

Ha das kommt weiter oben von

Timestamps sind Zeitstempel, wann zB der DP beschrieben wurde.

[mcm1957]

@Kusselin sagte:

Hier die letzte Nachricht vom Shelly Support:

die von Ihnen zitierte allgemeine Aussage des Adapter-Entwicklers ändert nichts an den im konkreten Fall vorliegenden Diagnosedaten.

In den übermittelten Protokollen ist eindeutig erkennbar, dass der Shelly in sehr kurzen Abständen eingehende MQTT-Nachrichten aus Ihrem Netzwerk erhält. Der Adapter-Entwickler kennt weder Ihre vollständige ioBroker-Konfiguration noch Ihre Skripte, Instanzen, MQTT-Topics oder die konkreten Logdaten dieses Gerätes. Eine pauschale Aussage zum üblichen Verhalten des Adapters kann daher die tatsächlich protokollierte Kommunikation in Ihrer Installation nicht widerlegen.

Ob diese Nachrichten durch den Adapter selbst, ein Skript, eine weitere Instanz, eine fehlerhafte Konfiguration oder ein anderes System erzeugt werden, können wir nicht beurteilen. Dies muss innerhalb Ihres Drittanbietersystems beziehungsweise anhand der Broker- und ioBroker-Protokolle geprüft werden.

Der Shelly wird durch diese ungewöhnlich hohe Anzahl eingehender MQTT-Nachrichten, teilweise in Abständen im Millisekundenbereich, erheblich belastet. In den Protokollen wird dabei sogar eine überlaufende Warteschlange gemeldet. Dies führt dazu, dass das Gerät zeitweise nicht mehr reagiert und abstürzt. Ein Gerätefehler lässt sich aus den vorliegenden Diagnosedaten hingegen nicht ableiten.

Bitte prüfen Sie daher in Ihrem MQTT-Broker beziehungsweise in ioBroker:

    welche Clients Nachrichten an die Topics des Shelly senden,
    welche Skripte oder Automationen diese Nachrichten auslösen,
    ob mehrere Adapter oder Instanzen gleichzeitig auf dasselbe Gerät zugreifen,
    welche Polling (Abfrage) Intervalle konfiguriert sind
    und ob sich die Nachrichtenrate nach dem Deaktivieren der MQTT-Integration normalisiert.

Da die Ursache nach aktuellem Stand außerhalb des Shelly-Gerätes liegt und innerhalb des verwendeten Drittanbietersystems geprüft werden muss, werden wir den Vorgang an dieser Stelle schließen.

Um das Rätselraten zu minimieren bitte

- stell uns die Protokolle zur Verfügung auf Grund derer der Shelly SSupport zu seiner Aussage kommt.
- stell wie schon früher angefragt ein vollständiges Logfile des Shelly Adapters mit level DEBUG zur Verfügung (vollständig = vom Start des Adapter bis zum Auftreten des Problems)

Vielleicht sieht man dann mehr...

Welche der Schritte die der Shelly Support empfohlen hat:

Bitte prüfen Sie daher in Ihrem MQTT-Broker beziehungsweise in ioBroker:

welche Clients Nachrichten an die Topics des Shelly senden,
welche Skripte oder Automationen diese Nachrichten auslösen,
ob mehrere Adapter oder Instanzen gleichzeitig auf dasselbe Gerät zugreifen,
welche Polling (Abfrage) Intervalle konfiguriert sind
und ob sich die Nachrichtenrate nach dem Deaktivieren der MQTT-Integration normalisiert.

hast du schon mit welchem Ergebnis durchgeführt?