[GELÖST] Wieder mal der Duty Cycle viel zu hoch

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Benutzeravatar
Wortmann30
Beiträge: 1300
Registriert: 21.03.2014, 21:39
Hat sich bedankt: 4 Mal
Danksagung erhalten: 10 Mal

[GELÖST] Wieder mal der Duty Cycle viel zu hoch

Beitrag von Wortmann30 » 18.05.2020, 13:40

Hallo zusammen,

die die Überschrift schon beschreibt habe ich Probleme mit dem Duty Cycle.

Mein System ist so aufgebaut, ich habe ca 160 Geräte HM Funk keine IP Geräte und ca 40 Geräte HMW auch keine IP Geräte.
Da die Wege zwischen den Geräten teilweise hoch sind, habe ich zwei Gateways und eben den RS485 Gateway.
Mein Rasi läuft derzeit mit 3.51.6.20200420 auf einem Pi2.

Gestern nachmittag hat es angefangen das diverse Geräte die über Funk betrieben werden und durch die Zentrale Verknüpft nicht mehr reagierten.
Eine Konkrete Regel des nicht reagierens war nicht festzustellen.
Beim untersuchen des Problems viel mir auf, dass ich ab diesem Zeitpunkt immer um die 40-50 Servicemeldungen hatte (also aktuelle nicht die die man bestätigen muss). Weiter war der Duty Cycle des Gateway im OG konstant um die 70-99% und die Alarmmeldung kommt immer.
Der DC der Zentrale und der Gatways im UG waren normal zwischen 5-20%.
Diese Situation hält nun seit gestern an.

Was ich getan habe ist folgendes:
ich habe zu beginn immer 50% der Geräte die auf dem OG Gateway verbunden sind auf die Zentrale und zurück gewechselt und den DC beobachtet bis das Problem mit gewandert ist. Es hat sich herausgestellt wenn ich die Fernbedienung HM-RC-19 wechselte wechselte das Problem mit. Zum Verifizieren wurde diese dann auch in den Keller verfachtet und auf den UG Gateway gehängt und das Problem wanderte mit.
Super der Übeltäter schien gefunden zu sein also Batterie raus und beobachten. Aber leider ergab sich keine Verbesserung des Problems.

Dann hab euch vermutet das das Programm das die Servicemeldungen ins Dysplay der HM-RC-19 sendet das Problem macht, und dieses deaktiviert, auch half leider nicht.

Ich habe mir auch angesehen was auf dem asksin-analyzer habe und festgestellt das die Paket Mengen der Geräte eigentlich ganz gut aussehen. Was mir aber aufgefallen ist, ist das ca 3/4 aller Signale von der Zentrale ausgehen. Ich gehe mal davon aus das Zentrale in einem Fall Signale alle von der Zentrale wie auch den Gateways ausgehen und da nicht unterscheiden wird.

Nun bin ich leider irgenwie immer noch nicht weiter die Geräte reagieren nicht und die Anzahl Servicemeldungen bleibt gleich, wie auch der DC hoch.
Spreche ich die Geräte direkt an reagieren sie immer noch nicht, auch eine lokale Betätigung schafft keine Abhilfe...

Ich bin echt am ende meines Lateins und hoffe auf einen Zündenden Input von Euch...
Grüsse


To be continued...

scorpionking
Beiträge: 323
Registriert: 14.02.2016, 12:32
System: Alternative CCU (RaspberryMatic etc.)
Hat sich bedankt: 14 Mal
Danksagung erhalten: 28 Mal

Re: Wieder mal der Cuty Cycle viel zu hoch

Beitrag von scorpionking » 18.05.2020, 17:57

Ich würde testweise erst mal alle Programme deaktivieren (auch die versteckten) und dann nach 1 Stunde schauen, ob der DC sinkt.
Wenn ja, ist es eines deiner Programme.

Ansonsten: Gibt's irgendwelche Fremdanbindungen (Redmatic, ioBroker, usw., oder auch Apps auf Mobilgeräten, selbstgestrickte Sachen)? Wenn ja, auch die temporär deaktieren.

Benutzeravatar
Wortmann30
Beiträge: 1300
Registriert: 21.03.2014, 21:39
Hat sich bedankt: 4 Mal
Danksagung erhalten: 10 Mal

Re: Wieder mal der Cuty Cycle viel zu hoch

Beitrag von Wortmann30 » 19.05.2020, 11:56

Hallo

danke für den Tipp, so den DC habe ich jetzt im Griff, aber nun habe ich immer noch um die um die 40 Kommunikations Störungen.

Leider lässt sich dieses nicht mit einfache betätigen am Gerät oder gar Stromlos machen lösen...

Was ich bisher noch gescheut habe ist jedes einzelne neu anzulernen, das ist alleine schon wegen der Erreichbarkeit der Geräte (Wettersation auf dem Carport, ...) schwierig...
Auch Def config ist so ne ding da müsste ja auch jedes gerät einzeln Angepackt werden...

Hat das jemand noch ne andere Idee?

Ein weiterer Gedanke ist das ich versuche zurück auf eine Alte Version der RM zu gehen mit dem entsprechenden Backup. Aber ich befürchte das die Geräte dann auch Kommunikationsstörungen haben...
Grüsse


To be continued...

jp112sdl
Beiträge: 5105
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 189 Mal
Danksagung erhalten: 402 Mal
Kontaktdaten:

Re: Wieder mal der Cuty Cycle viel zu hoch

Beitrag von jp112sdl » 19.05.2020, 12:20

Wortmann30 hat geschrieben:
19.05.2020, 11:56
aber nun habe ich immer noch um die um die 40 Kommunikations Störungen.
Was sagt denn der Rausch-Pegel im AskSinAnalyzer?

VG,
Jérôme
☕️

Benutzeravatar
Black
Beiträge: 2786
Registriert: 12.09.2015, 22:31
System: Alternative CCU (RaspberryMatic etc.)
Wohnort: Wegberg
Hat sich bedankt: 35 Mal
Danksagung erhalten: 172 Mal
Kontaktdaten:

Re: Wieder mal der Cuty Cycle viel zu hoch

Beitrag von Black » 19.05.2020, 12:21

defconfig müsste ja auch erreichbar sein das Gerät...

das klingt als hättest du im OG bei dir irgendwo einen BI, der dir da das 868 MHz zubrabbelt. so ein Teil findest du nicht mit dem Asksin analyser, weil ein BI ja nicht BidcosRF oder HMIp telegrammel quasseln muss, sondern auch einfach sinnfreien müll auf dem frequenzband senden kann.

Black

(batterien aus den zugänglichen geräten rausnehmen, auch schalt und rollandenaktoren mal stromlos machen bzw L abklemmen und dann mal gucken
Die Wahrheit ist ein Chor aus Wind
Meine Seite, ok noch bisschen im Aufbau

RaspberryMatic 3.51.6.20200420 mit Groundplane Antennenmod
jede Menge Sensoren und Aktoren, Logamatic 2107 Gateway zum Buderus Kessel
ioBroker unter ProxMox auf NUC als Hauptsteuersystem und Visualisierung
Script Time Scheduler V1.3
Howto - AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 3.11.04 Scripteditor und Objektinspektor

technical constribution against annoying advertising

jp112sdl
Beiträge: 5105
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 189 Mal
Danksagung erhalten: 402 Mal
Kontaktdaten:

Re: Wieder mal der Cuty Cycle viel zu hoch

Beitrag von jp112sdl » 19.05.2020, 12:25

Black hat geschrieben:
19.05.2020, 12:21
so ein Teil findest du nicht mit dem Asksin analyser, weil ein BI ja nicht BidcosRF oder HMIp telegrammel quasseln muss, sondern auch einfach sinnfreien müll auf dem frequenzband senden kann.
Aha... gut nur, dass der AskSinAnalyzer seit Monaten schon den RSSI Noise-Pegel erfasst.
Völlig unabhängig irgendwelcher Telegramme.
Oh man.
Bild

VG,
Jérôme
☕️

Xel66
Beiträge: 6922
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg
Hat sich bedankt: 32 Mal
Danksagung erhalten: 206 Mal

Re: Wieder mal der Cuty Cycle viel zu hoch

Beitrag von Xel66 » 19.05.2020, 12:26

Wortmann30 hat geschrieben:
19.05.2020, 11:56
Leider lässt sich dieses nicht mit einfache betätigen am Gerät oder gar Stromlos machen lösen...
Du musst halt einfach nur die Geräte ein mal zwingen, ihren aktuellen Zustand an die CCU zu übermitteln. Sonst bleibt der Zustand bei Geräten ohne zyklische Statusmeldung "ewig" bestehen, bis sie von der CCU angesprochen wurden.
Wortmann30 hat geschrieben:
19.05.2020, 11:56
Aber ich befürchte das die Geräte dann auch Kommunikationsstörungen haben...
Davon ist auszugehen, denn an dem grundsätzlichen Zustand ändert sich ja nichts. Diese aktive Abfrage ist ja auch der Grund, warum der Duty Cycle beim Systemstart meistens etwas hochgeht, denn nur da wird er aktiv durch die CCU eingeholt. Danach nicht mehr. Und eben auch nur bei Aktoren, die das unterstützen (Netzbetrieb und Batterieaktoren wie Thermostate). Auch werden durch die Abfrage auch manche Programme getriggert, die den Status von solchen Aktoren als Auslöser haben. Als Folge kann dann der Duty Cycle ebenfalls steigen.

Türkontakte haben auch nach einem Systemstart den Zustand "geschlossen". Das bleibt dann auch so bis zur nächsten zyklischen Statusmeldung oder bis zum nächsten Ereignis. Bei den klassischen Magnetkontakten sind das 24 Stunden, bei den optischen eine Stunde. Bei IP habe ich das noch nicht verfolgt. Der Grund dafür ist einfach, dass das System auf Batteriesparsamkeit ausgelegt ist, was eben auch manche Nachteile mit sich bringt. Einer ist eben die Nichtabfragbarkeit solcher Batteriesensoren.

Darum ist es im Grunde auch keine gute Idee, Statusmeldungen zu unterdrücken oder deren Zyklus zu verlängern. Diese Meldungen gehen sowieso nur als Broadcast raus. Aber des Anwenders Wunsch ist sein Himmelreich. Er muss dann mit den daraus resultierenden Folgen leben, kann aber häufig das Verhalten des Systems nicht auf sein Tun zurückführen. Er ist eben nur den "falschen" Ratschlägen anderer "Optimierer" gefolgt, die solche Einschränkungen häufig nicht oder nicht ausdrücklich in diesen Anleitungen kommunizieren. Die Folge sind eben lange anstehende Kommunikationsstörungen.

Wenn man nicht ständig neu bootet, ist das auch nicht wirklich ein Problem. Die Grundauslegung ist nun mal der Dauerbetrieb und nicht der häufige Neustart. Und im Dauerbetrieb hat man bei Beachtung einiger Grundlagen und Effekte kaum Kommunikationsstörungen die durch das System selbst verursacht sind und auch kein Problem mit den zyklischen Statusmeldungen. Reichweitenprobleme und Störungen von anderen Systemen (z.B. Wetterstationen) sowie durch Anwender verursachte Programmierfehler wie gleichzeitige Ansteuerung mehrerer Geräte sind mal außen vorgelassen. Der Funkkanal ist nur mal eine eingeschränkt vorhandene Ressource, die sich die Geräte untereinander, aber auch mit anderen Systemen (z.B. Wetterstationen) teilen müssen. Und damit diese optimal genutzt wird, hilft eben nur die zeitliche Entzerrung.

Gruß Xel66
---------------------------------------------------------------------------------
358 Kanäle in 103 Geräten und 114 CUxD-Kanäle in 24 CUxD-Geräten:
253 Programme, 218 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version 3.45.7.20190622
Testsystem: CCU3 3.49.17
---------------------------------------------------------------------------------

Benutzeravatar
Wortmann30
Beiträge: 1300
Registriert: 21.03.2014, 21:39
Hat sich bedankt: 4 Mal
Danksagung erhalten: 10 Mal

Re: Wieder mal der Cuty Cycle viel zu hoch

Beitrag von Wortmann30 » 19.05.2020, 12:57

Hallo zusammen

erst mal danke für die Antworten.

@Black,

den BI habe ich ja schon identifiziert durch hin und her schalten der Komponenten von Zentrale auf Gateway. Die musste auch ohne DVB-T Stick gehen den ich in solchen fällen immer wieder geren hervor ziehe, aberleider lief der bis heute nicht mehr da ich auf WIN10 umgestiegen bin, das ist aber eine andere Sache.

Mein DVB-T Stick geht seit heute wieder und ich werde dass mit dem BI verifizieren.

Der BI ist eine HM-RC-19...

@jp112sdl

Ja das habe ich ganz vergessen das der AskSinAnalyzer das ja auch bietet... kann ich davon ausgehen das -110dBm ein guter wünschenswerter Wert ist oder wo liegt die Grenze?

@Xel66

Ja das was du sagst ist mir alles klar. Das der DC bei System start höher ist und das Nur bestimmte geräte auch durch den Burst geweckt werden um den Status anzugeben.
Das ist ja auch nicht das Problem mehr.

Zb. Fenster Kontakt der wird derzeit nicht als Kommunikationsstörung angezeigt, da die Zentrale noch keine 24 STD online ist. Das ist richtig aber der wird nach 24 Std kommen. Weil er jetzt schon wenn ich das Fenster öffne orange leuchtet um den Status zu senden und dann irgendwann Rot kommt für Kommunikation fehl geschlagen.
Ein Heizungsthermostat wird ja durch eine Burst geweckt um den Status zu erfahren, die Kommunikation schlägt eben fehl und daher bekomme ich dies sofort als Kommunikationsstörung Meldung.
Also mein Schluss daraus ist das die Geräte nicht mehr mit der Zentrale kommunizieren, vielleicht liegt es daran das die Zentrale in der Software einen Defekt aufweist, dies habe ich aber gestern durch eine komplette Neuinstallation mit einem alten Backup wiederlegt.
Ich befürchte das so ziemlich alle Geräte irgendwie beim Auftreten des Problems eine Information gesendet bekommen haben die nicht gut war und dadurch die Kommunikation gestört wird...

Wie auch immer suche ich nach ner Möglichkeit das alles mit den Kommunikationsstörungen zu beheben ohne zu jedem Gerät "klettern" zu müssen, denn teilweise sind die echt nicht erreichbar verbaut da es keine andere Möglichkeit gab und ca. 160 Stück so zu behandeln will ich eben auch nicht.

Ich hoffe ich habe mich verständlich ausgedrückt.

Aber noch was ganz anderes, besteht die Möglichkeit oder besser gesagt kann es sein das durch ein Defektes Funkmodul das alles hervorgerufen wird? Also ich meine wenn eines der 3 eingesetzten (Zentrale Pi2 mit RPI-RF-MOD und 2x Gateway Pi2 mit jehweils HM-MOD-RPI-PCB) einen schuss hat?
Grüsse


To be continued...

jp112sdl
Beiträge: 5105
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 189 Mal
Danksagung erhalten: 402 Mal
Kontaktdaten:

Re: Wieder mal der Cuty Cycle viel zu hoch

Beitrag von jp112sdl » 19.05.2020, 12:59

Wortmann30 hat geschrieben:
19.05.2020, 12:57
kann ich davon ausgehen das -110dBm ein guter wünschenswerter Wert ist
Ja, das ist ein guter Wert, zumindest für den Standort, an dem sich der Analyzer befindet.

Du könntest mit diesem mal durch die Wohnung gehen und schauen, ob der Wert so bleibt.
Zumindest unter ca. -100dBm sollte er schon sein.

VG,
Jérôme
☕️

Benutzeravatar
Black
Beiträge: 2786
Registriert: 12.09.2015, 22:31
System: Alternative CCU (RaspberryMatic etc.)
Wohnort: Wegberg
Hat sich bedankt: 35 Mal
Danksagung erhalten: 172 Mal
Kontaktdaten:

Re: Wieder mal der Cuty Cycle viel zu hoch

Beitrag von Black » 19.05.2020, 13:04

jp112sdl hat geschrieben:
19.05.2020, 12:25
Aha... gut nur, dass der AskSinAnalyzer seit Monaten schon den RSSI Noise-Pegel erfasst.
Völlig unabhängig irgendwelcher Telegramme.
Oh man.
Dass man als Entwickler die Möglichkeiten um einiges besser kennt als ein Anwender, der das nur ab und an nutzt ist klar. Habe ich selber bei meinen projekten auch.
von daher finde ich dein "Aha (...) Oh man" ein wenig [zensur]

Ein Hinweis auf die technische Möglichkeit des Analysers wäre da angebrachter.

jm2c, Black
Die Wahrheit ist ein Chor aus Wind
Meine Seite, ok noch bisschen im Aufbau

RaspberryMatic 3.51.6.20200420 mit Groundplane Antennenmod
jede Menge Sensoren und Aktoren, Logamatic 2107 Gateway zum Buderus Kessel
ioBroker unter ProxMox auf NUC als Hauptsteuersystem und Visualisierung
Script Time Scheduler V1.3
Howto - AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 3.11.04 Scripteditor und Objektinspektor

technical constribution against annoying advertising

Antworten

Zurück zu „RaspberryMatic“