[GELÖST] Wieder mal der Duty Cycle viel zu hoch
Moderatoren: jmaus, Co-Administratoren
- Wortmann30
- Beiträge: 1353
- Registriert: 21.03.2014, 21:39
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 7 Mal
- Danksagung erhalten: 11 Mal
[GELÖST] Wieder mal der Duty Cycle viel zu hoch
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...
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...
To be continued...
-
- Beiträge: 1165
- Registriert: 14.02.2016, 12:32
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Heidenheim
- Hat sich bedankt: 57 Mal
- Danksagung erhalten: 225 Mal
Re: Wieder mal der Cuty Cycle viel zu hoch
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.
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.
- Wortmann30
- Beiträge: 1353
- Registriert: 21.03.2014, 21:39
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 7 Mal
- Danksagung erhalten: 11 Mal
Re: Wieder mal der Cuty Cycle viel zu hoch
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...
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...
To be continued...
-
- Beiträge: 12085
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 847 Mal
- Danksagung erhalten: 2139 Mal
- Kontaktdaten:
Re: Wieder mal der Cuty Cycle viel zu hoch
Was sagt denn der Rausch-Pegel im AskSinAnalyzer?Wortmann30 hat geschrieben: ↑19.05.2020, 11:56aber nun habe ich immer noch um die um die 40 Kommunikations Störungen.
- Black
- Beiträge: 5463
- Registriert: 12.09.2015, 22:31
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Wegberg
- Hat sich bedankt: 418 Mal
- Danksagung erhalten: 1069 Mal
- Kontaktdaten:
Re: Wieder mal der Cuty Cycle viel zu hoch
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
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
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg
Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann
Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W
technical contribution against annoying advertising
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg
Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann
Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W
technical contribution against annoying advertising
-
- Beiträge: 12085
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 847 Mal
- Danksagung erhalten: 2139 Mal
- Kontaktdaten:
Re: Wieder mal der Cuty Cycle viel zu hoch
Aha... gut nur, dass der AskSinAnalyzer seit Monaten schon den RSSI Noise-Pegel erfasst.
Völlig unabhängig irgendwelcher Telegramme.
Oh man.
-
- Beiträge: 14085
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 580 Mal
- Danksagung erhalten: 1492 Mal
Re: Wieder mal der Cuty Cycle viel zu hoch
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:56Leider lässt sich dieses nicht mit einfache betätigen am Gerät oder gar Stromlos machen lösen...
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.Wortmann30 hat geschrieben: ↑19.05.2020, 11:56Aber ich befürchte das die Geräte dann auch Kommunikationsstörungen haben...
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
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
- Wortmann30
- Beiträge: 1353
- Registriert: 21.03.2014, 21:39
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 7 Mal
- Danksagung erhalten: 11 Mal
Re: Wieder mal der Cuty Cycle viel zu hoch
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?
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...
To be continued...
-
- Beiträge: 12085
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 847 Mal
- Danksagung erhalten: 2139 Mal
- Kontaktdaten:
Re: Wieder mal der Cuty Cycle viel zu hoch
Ja, das ist ein guter Wert, zumindest für den Standort, an dem sich der Analyzer befindet.Wortmann30 hat geschrieben: ↑19.05.2020, 12:57kann ich davon ausgehen das -110dBm ein guter wünschenswerter Wert ist
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.
- Black
- Beiträge: 5463
- Registriert: 12.09.2015, 22:31
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Wegberg
- Hat sich bedankt: 418 Mal
- Danksagung erhalten: 1069 Mal
- Kontaktdaten:
Re: Wieder mal der Cuty Cycle viel zu hoch
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
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg
Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann
Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W
technical contribution against annoying advertising
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg
Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann
Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W
technical contribution against annoying advertising