DutyCycle zeitweise auf 100%

[Josh]

Hallo zusammen!

Alle paar Tage ist mein DutyCycle auf 100% und löst somit eine Alarmmeldung aus. Meistens passiert das nachts, wenn alle schlafen. Es tippt also keiner endlos auf irgendeinem Schalter herum. Die Batteriespannung der Geräte liegt zwischen 2.3V und 2.5V.

Ich habe dazu mal einen Screenshot angehängt.

Wie gehe ich vor, um das Problem zu erkennen und zu beheben? Welche Infos benötigt ihr noch?

Firmware und Zusatzsoftware ist auf neustem Stand.

Gruß Josh

EDIT: Das Problem tritt seit der vorletzten Firmware von 12.2018 auf. In der Zeit habe ich allerdings ein paar Update auf Geräten durchgeführt und eine HmIP-BSL hinzugefügt. Es muss also nicht zwangsweise an der Firmware liegen.

EDIT2: Ich habe das hier hin und wieder in den Logs stehen:

Code: Alles auswählen

Jan 29 01:17:35 org.apache.http.impl.client.DefaultHttpClient INFO  [vert.x-worker-thread-0] I/O exception (java.net.SocketException) caught when processing request to {}->http://127.0.0.1:39292: Broken pipe (Write failed) 
Jan 29 01:17:35 org.apache.http.impl.client.DefaultHttpClient INFO  [vert.x-worker-thread-0] Retrying request to {}->http://127.0.0.1:39292 
Jan 29 01:20:04 org.apache.http.impl.client.DefaultHttpClient INFO  [vert.x-worker-thread-2] I/O exception (java.net.SocketException) caught when processing request to {}->http://127.0.0.1:39292: Broken pipe (Write failed) 
Jan 29 01:20:04 org.apache.http.impl.client.DefaultHttpClient INFO  [vert.x-worker-thread-2] Retrying request to {}->http://127.0.0.1:39292 

Was bedeutet das?

Code: Alles auswählen

Jan 29 01:00:00 raspberrymatic user.info dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 80%
Jan 29 01:03:00 raspberrymatic user.info dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 92%
Jan 29 01:06:00 raspberrymatic user.info dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 96%
Jan 29 01:09:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:12:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:15:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:18:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:21:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 98%
Jan 29 01:24:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:27:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:30:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:33:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:36:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 98%
Jan 29 01:39:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:42:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%
Jan 29 01:45:00 raspberrymatic user.err dutycycle: DutyCycle-OEQ0306741 / CCU2 / FW: 2.8.6 / DC: 99%

[Xel66]

Ich würde schauen, welche Programme bei Dir 00:30 Uhr auf dem Trigger haben, bzw. Timer beinhalten, die um diese Uhrzeit auslaufen.

Gruß Xel66

[Josh]

Ich habe nur 4 Programme drin. Diese hatte ich beim vorletzten Auftreten des Problems deaktiviert. Jetzt sind nur noch Direktverknüpfungen aktiv. Daran kann es also nicht liegen.

[Xel66]

Dann dürfte es Deiner externen Anbindungensein. Ich sehe da mindestens drei potenzielle Quellen in Seiner Signatur.

Gruß Xel66

[Josh]

hmmm....?

Ich sehe nur eine Möglichkeit. Die Anbindung an Pimatic.

Das Raspberrymatic ist per RedMatic per MQTT an die Diskstation angebunden. Pimatic holt sich dann die Daten über den Mosquitto-Server.

Wo gibt's denn noch weitere Möglichkeiten?

Heute morgen ist übrigens zwischen 6 und 7 Uhr der DC von ~20% auf 80% sprunghaft angestiegen. Es ist immer eine andere Uhrzeit...

[Hypnos]

Kommt darauf an, was du in RedMatic oder in PiMatic machst oder was noch alles an MQTT hängt.

Wenn du in RedMatic nur die MQTT Nodes hast, würde ich mir an deiner Stelle mal ansehen was da auf dem MQTT Broker los ist. Dazu kannst du einen MQTT client deiner Wahl nehmen und sich einfach mal auf alle Topics Subscriben um sich das anzusehen.

[Josh]

Ich nutze Redmatic zur Zeit nur als MQTT-Schnittstelle zwischen Raspberrymatic und Pimatic. Im Pimatic sind natürlich viele andere Komponenten wie z.B. SonOff mit Tasmota, FritzDECT, 1Wire-Sensoren, 433MHz-Transmitter angebunden. Dort sind auch einige Programme aktiv, die mit Raspberrymatic interagieren. Vielleicht deaktiviere ich diese mal temporär. Allerdings sind die Programme schon alt. Früher trat das Problem schließlich nicht auf.

Als MQTT-Client habe ich mir auf der Diskstation mqtt-admin auf der Webstation installiert. Wenn ich dort nachschaue, fällt mir nichts besonders auf. Leider kann ich während des Fehlers nicht schauen, da nicht vorauszusehen ist, wann er auftritt. Bei Gelegenheit werde ich, wie Du vorgeschlagen hast, auf allen Topics subscriben und anschauen, ob was auffällig ist.

Ich könnte auch mal die MQTT-Schnittstelle deaktivieren und schauen, ob der Fehler ausbleibt.

Wie im Anhang zu sehen ist, gibt es immer mal wieder Ausschläge gegen 100%.

[Xel66]

Früher trat das Problem schließlich nicht auf.

Putziges Argument. Vielleicht sind aber genau jetzt die Gegebenheiten so, dass ein Programm Amok laufen kann. Beispiel: Du hast ein Programm, welches die Außentemperatur auswertet und in Abhängigkeit davon irgendwelche Aktionen auslöst. Im größten Teil des Jahres sind die Temperaturen viel höher und der fehlerhafte Zweig kommt nie zum Einsatz. Jetzt aber, da die Temperaturen geringer sind, tritt genau der Fall ein. Das Programm war in diesem Falle schon immer fehlerhaft, aber eben ohne Auswirkungen. Insofern ist die Aussage, dass das Problem "früher" nicht auftrat, absolut nicht belastbar. Aber ist nur ein Beispiel. Kann auch was ganz anderes sein.

Ich könnte auch mal die MQTT-Schnittstelle deaktivieren und schauen, ob der Fehler ausbleibt.

Diese Maßnahme würde ich auch als zielführend erachten.

Gruß Xel66

[Josh]

Das Problem hat sich in Luft aufgelöst. Ich habe drei Dinge "gleichzeitig" verändert:

1) FW-Updates auf einigen Schalter durchgeführt
2) Batterie in einem Raumtemperaturfühler ersetzt
3) Eine Antenne mit +7dB eingesetzt (die alte hatte +2-3dB)

Woran es gelegen hat, kann ich nicht mit Bestimmtheit sagen. Aber ich habe es schwer daruf stehen, dass die neuen Batterien in einem Sensor den Erfolg gebracht haben. Die Batterie des Sensors hatte zum Zeitpunkt des ersten Auftretens 2,3V. Kurze Zeit später waren es 2.1V und das wurde in der Zentrale signalisiert. Die 2.2V hat er "übersprungen".

Die neue Antenne wirkt aber bestimmt auch nicht negativ.

Kann jemand meine Meinung bestätigen?

Gruß Josh

[Familienvater]

Hi,

wenn ich Antenne mit +7db lese, dann kann die durchaus auch den Empfang verschlechtern...
Warum? Weil der Antennengewinn immer von einer Richtwirkung kommt, die alte Antenne mit nur 2db hat vielleicht eine "kugelförmige" Empfangscharakteristik, die gut ist, wenn z.B. die CCU zentral im Keller oder EG steht, damit werden wegen der "Kugel" auch Geräte direkt über oder unter der Antenne empfangen, +7db klingt eher nach "langer" Stabantenne, die hat eher eine Empfangs-/Sendecharakteristik wie ein Leuchtturm, direkt darüber und darunter ist eher schlechter Emfang, dafür in der Ebene der Antenne ist er halt besser, soetwas passt aber eher zu jemand, der einen Bugalow bewohnt, und kein OG und keinen Keller hat. Durch Reflexion werden auch Geräte darüber oder darunter empfangen, aber nicht "direkt".

Und dann muss einfach ganz klar sagen, das fast alles, was bei Amazon und Co als 868-Mhz Antenne verkauft wird, auf dem Vector-Impedanz-Analyser eher nach nicht so wirklich geeignet für 868 Mhz aussieht (den Funkwellen ist es egal, ob da 868 MHz auf der Antenne draufsteht, der Aufdruck von UKW oder LTE auf die Antenne kostet das gleiche Geld), mit das brauchbarste von der Anpassung war eine Stummelantenne, die "nur" 2,15db verspricht.

Die in meinen Augen "beste" Allround-Antenne ist immer noch die Aurel 868MHz-Groundplane, die zeigt auch im Vector-Impedanz-Analyser, das die wirklich für die Frequenz passt.

Der Familienvater