Weiter zum Inhalt
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Hell
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dunkel
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Skripten / Logik
  4. JavaScript
  5. ioBroker Prozess- & Gesundheitsmonitor + Grafana + HTML

NEWS

  • Neuer ioBroker-Blog online: Monatsrückblick März/April 2026
    BluefoxB
    Bluefox
    8
    1
    750

  • Verwendung von KI bitte immer deutlich kennzeichnen
    HomoranH
    Homoran
    10
    1
    573

  • Monatsrückblick Januar/Februar 2026 ist online!
    BluefoxB
    Bluefox
    18
    1
    1.1k

ioBroker Prozess- & Gesundheitsmonitor + Grafana + HTML

Geplant Angeheftet Gesperrt Verschoben JavaScript
javascriptmonitoring
78 Beiträge 8 Kommentatoren 2.1k Aufrufe 13 Beobachtet
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • R rallef

    ok funktioniert jetzt super. Allerdings geht mein Synology NAS jetzt in die Knie. Mein iobroker belegt mehr als 44% RAM und es werden jede menge Warnings und errors in die influxdb geschrieben. schaukelt sich also hoch. da muss ich noch was optimieren

    crunchipC Abwesend
    crunchipC Abwesend
    crunchip
    Forum Testing Most Active Developer
    schrieb am zuletzt editiert von
    #66

    @rallef sagte:

    ede menge Warnings und errors in die influxdb geschrieben

    die da wären?

    @rallef sagte:

    muss ich noch was optimieren

    sollte eigentlich von haus aus so passen, mit den vorgegebenen Werten

    umgestiegen von Proxmox auf Unraid

    1 Antwort Letzte Antwort
    0
    • crunchipC crunchip

      @sigi234 sagte:

      eine E-Mail Benarichtigung einbauen

      Lässt sich sicherlich machen, wenn ich heut abend dazu komme

      @sigi234 ist drin, siehe ersten Beitrag

      sigi234S Online
      sigi234S Online
      sigi234
      Forum Testing Most Active
      schrieb am zuletzt editiert von
      #67

      @crunchip sagte:

      @sigi234 ist drin, siehe ersten Beitrag

      DANKE! 👍

      Bitte benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
      Immer Daten sichern!

      1 Antwort Letzte Antwort
      0
      • R Offline
        R Offline
        rallef
        schrieb am zuletzt editiert von
        #68

        habe jetzt 350 warnings /h in der influxdb.0 und ich sehe das die instanz neugestartet wird. Mein Host Ram ist auch zeitweise kritisch nur 13% und mein iobroker Ram belegt mehr als 54% zeitweise
        hab eine synology Nas DS918+ mit 12 GB ram

        crunchipC 1 Antwort Letzte Antwort
        0
        • R Offline
          R Offline
          rallef
          schrieb am zuletzt editiert von
          #69

          werde die mal auf 16GB aufrüsten

          1 Antwort Letzte Antwort
          0
          • R rallef

            habe jetzt 350 warnings /h in der influxdb.0 und ich sehe das die instanz neugestartet wird. Mein Host Ram ist auch zeitweise kritisch nur 13% und mein iobroker Ram belegt mehr als 54% zeitweise
            hab eine synology Nas DS918+ mit 12 GB ram

            crunchipC Abwesend
            crunchipC Abwesend
            crunchip
            Forum Testing Most Active Developer
            schrieb am zuletzt editiert von
            #70

            @rallef das der RAM oder die CPU mal schwankt ist normal, meine Frage lag eher darin:
            Hattest du diese Probleme schon vorher oder wolltest du mir mitteilen, erst seit Scriptinstallation

            umgestiegen von Proxmox auf Unraid

            1 Antwort Letzte Antwort
            0
            • R Offline
              R Offline
              rallef
              schrieb am zuletzt editiert von
              #71

              kann ich nicht sagen, aber es werden ja viele Änderungen in die influxdb geschrieben seitdem ich das Skript gestartetd habe

              1 Antwort Letzte Antwort
              0
              • R Offline
                R Offline
                rallef
                schrieb am zuletzt editiert von
                #72

                hab halt viele Warnungen die in der influxdb geschrieben werden
                ich werde die mal posten

                1 Antwort Letzte Antwort
                0
                • crunchipC crunchip

                  ioBroker Prozess-Monitor — Langzeit-Gesundheitsmonitoring

                  Ich stelle hier mein Script für ein erweitertes Prozess- und Gesundheitsmonitoring von ioBroker vor, inklusive passendem Grafana-Dashboard für InfluxDB v1. (InfluxQL )
                  InfluxDB v2 ist grundsätzlich vorgesehen, aktuell aber noch nicht als separates Dashboard-Paket enthalten.
                  Habe das Grafana json (flux) im Beitrag unten ergänzt, jedoch ungetestet

                  Das Script nutzt Standard-States wie system.adapter.* und system.host.* und benötigt keinen zusätzlichen eigenen Adapter.
                  Für Log-Tracking und die Erkennung degradierter Adapter wird onLog des JavaScript-Adapters benötigt.

                  Enthalten sind unter anderem:

                  • CPU-/RAM-Monitoring aller laufenden Adapter
                  • Restart-Tracking für Flaky-Adapter und Cron-Restarts
                  • Memory-Leak- und Deadlock-Erkennung
                  • Log-Error-/Warn-Tracking und Degraded-Adapter-Bewertung
                  • Host-, Disk- und Health-Score-Monitoring
                  • Optionale Telegram-Alarme und REST-Auswertung
                  • Übersicht über deaktivierte Adapter

                  Getestet auf Raspberry Pi, VM, LXC, Docker und Unraid; produktiv läuft es aktuell auf Docker/Unraid.
                  Ziel ist die Früherkennung schleichender Probleme in produktiven ioBroker-Systemen.

                  Wichtig:
                  Nach dem Import des Dashboards bitte zuerst DSINFLUXDB, DSINFINITY und iobrokerurl prüfen bzw. auswählen.
                  Erst danach liefern alle Panels und REST-basierten Tabellen zuverlässig Daten.

                  Im Beitrag:

                  1. Script
                  2. Grafana-Dashboard InfluxDB v1 ( InfluxQL )
                  3. Grafana-Dashboard InfluxDB v2 (flux)
                  4. Die für InfluxDB benötigten Datenpunkte; weitere Tabellen und Zusatzdaten kommen per Infinity direkt über die REST-API
                    92378b3e-1ebf-4697-9f4d-79b7d4a03095-image.png
                  5. Variablen anlegen siehe https://forum.iobroker.net/post/1330170
                  6. Für dein Dashboard und die Ressourcen ist entscheidend, wie du die Datenpunkt‑spezifischen Influx‑Einstellungen je Typ setzt – nicht global alles gleich.

                  Grundprinzip je Datenpunkttyp

                  • Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse):
                  • Nur Änderungen aufzeichnen: an
                  • Entprellzeit: 300–1000 ms
                  • Blockzeit: 0
                  • „Trotzdem gleiche Werte aufzeichnen“: 600–3600 s (je nach gewünschter History‑Auflösung)
                  • Minimale Differenz: 0 (bei Booleans/Zahlen mit kleinem Bereich)
                  • Ergebnis: sehr wenige Punkte, aber alle Zustandswechsel sauber im Grafana‑Dashboard.

                  Kontinuierliche Messwerte mit Trend (CPU‑Last, RAM‑MB, Host‑Disk‑FreeMB, Health‑Score):

                  • Nur Änderungen aufzeichnen: an
                  • Entprellzeit: 500 ms wie im Screenshot ist ok
                  • „Trotzdem gleiche Werte“: auf deinen Script‑Zyklus bzw. Host‑Intervalle ausrichten, z. B. 180–300 s, damit Influx wenigstens alle paar Minuten einen Punkt bekommt, selbst wenn sich nichts ändert.
                  • Minimale Differenz: z. B. 1 % bei CPU‑Werten, 5–10 MB bei RAM, 1 Punkt beim Health‑Score.
                  • Ignoriere 0/Nullwerte: an, falls der DP beim Start kurz 0/NULL ist und das im Dashboard nicht stören soll.

                  Pulse‑Werte für Events (RestartEventPulse, FlakyEventPulse, Deadlock‑Alarm‑Pulse etc.):

                  • Nur Änderungen: an
                  • Trotzdem gleiche Werte: 0 s (nicht nötig, der Pulse ist ein kurzer Wechsel 0→1→0)
                  • Entprellzeit: klein (100–200 ms), damit jeder Pulse als eigener Punkt landet.
                  • 0/Null ignorieren: aus, sonst siehst du nur die 1, aber keinen „Rückfall“ im Graphen.
                  Bereich Datenpunkte
                  Grundprinzip / langsam ändernde Zustände SystemHealthScore, DisabledAdaptersCount, ConnectionIssuesCount, DeadlockAdapters, DisconnectedCount, FlakyAdaptersCount, CronRestartCount, MemoryLeakCount, LogErrorCount, LogErrors1hTotal, LogWarns1hTotal, CriticalAdaptersCount, WarningAdaptersCount, CPUAlarmCounter, RAMAlarmCounter, RestartCount24h
                  Kontinuierliche Messwerte ioBrokerCPUGesamt, ioBrokerRAMGesamt, HostCPULoad, HostCPUOther, HostRAMFreeMB, HostRAMAvailMB, HostRAMUsedMB, HostRAMTotalMB, HostRAMUsedPercent, HostLoadAvg, HostUptimeDays, HostEventLoopLag, DiskFreeMB, DiskUsedPct
                  Puls-Werte RestartEventPulse, FlakyEventPulse

                  Feedback, Tests in anderen Umgebungen und Verbesserungsvorschläge willkommen! 🚀

                  🔥 NEU: Prozess-Monitor

                  // CHANGELOG v4.6.7 (04.05.2026)
                  // ============================================================
                  // ✅ E-Mail-Benachrichtigung (email-Adapter): parallel zu Telegram/Pushover,
                  // gleicher Cooldown, gleiche Alarmtyp-Schalter (EMAIL*ALERT)

                  Changelog_old


                  CHANGELOG v4.6.6 (20.04.2026) RAM-Prozent mit Docker-tauglicher Bezugsgröße (Cgroup / manuell).


                  ✅ RAMPERCENTBASIS / RAMPERCENTMANUALMB: gemeinsamer Nenner für alle RAM-%-Werte (ioBroker-Gesamt + Host „frei“) → Prozent im Container bezieht sich auf Cgroup-Limit oder festen Wert, nicht blind auf Host-totalmem
                  ✅ readCgroupMemoryLimitBytes(): liest memory.max (v2) bzw. memory.limit_in_bytes (v1) → passendes Limit unter Linux/Docker, wenn gesetzt
                  ✅ Modi cgroup_or_host / host / cgroup / manual: steuerbar, wann Cgroup, Hardware oder manuelle MB greifen → klare Experten- vs. Standard-Logik
                  ✅ formatRAMAlertMessage(): wenn Prozent aktiv, aber keine Bezugsgröße ermittelbar → Text nennt MB-Fallback und Hinweis zu RAMPERCENT* → Telegram passt zur echten Alarmlogik

                  CHANGELOG v4.6.5 (20.04.2026) RAM-Schwellen wahlweise in Prozent oder MB (Einsteiger / Experte).


                  ✅ IOBROKERRAMTHRESHOLDMODE percent | mb: ioBroker-Gesamt-RAM → entweder RAMWARNINGPCT / RAMCRITICALPCT oder RAMWARNING / RAMCRITICAL (MB)
                  ✅ HOSTRAMTHRESHOLDMODE percent | mb: freier Host-RAM → entweder HOSTRAMFREEPCT oder HOSTRAMFREEMB → beide Bereiche unabhängig umschaltbar
                  ✅ resolveIoBrokerRamAlarmLevels() + Dashboard-Kachel: Farbe/Limit-Text folgen dem Modus → konsistent zu checkAlarm und HTML-DashboardHTML
                  ✅ Host-RAM-Alarm & Host-Kachel: Prozent nutzt dieselbe Bezugsgröße wie ioBroker-% (ab v4.6.6 inkl. Cgroup/Manual) → einheitliche Semantik
                  Hinweis: Script neu starten. Grafana ändert sich nicht von selbst (keine Dashboard-Datei im Skript); nur Schwellzeitpunkte können sich bei Umstellung auf Prozent verschieben — fest eingetragene MB-Linien in Panels ggf. anpassen. Wer nur klassisch MB will: IOBROKERRAMTHRESHOLDMODE: 'mb' und HOSTRAMTHRESHOLDMODE: 'mb' setzen.

                  CHANGELOG v4.6.4 (17.04.2026) HTML-Dashboard für VIS / Jarvis / iQontrol (ohne Grafana).


                  ✅ Optionales Dashboard: DASHBOARDHTMLENABLED (Standard: true) → State …Prozesse.DashboardHTML mit role: 'html'
                  ✅ Eigener Rhythmus: DASHBOARDHTMLINTERVAL in Minuten (Standard: 10, 0 = kein Schedule) → weniger Last als beim Haupt-Monitoring
                  ✅ Kein History-Müll: Beim Anlegen des States sind InfluxDB / history / sql für genau diesen State per custom deaktiviert → nur dieser eine State, Rest unverändert
                  ✅ Dirty-Check: HTML wird nur geschrieben, wenn sich der Inhalt geändert hat → weniger DB-Schreibvorgänge
                  ✅ Sparklines: RAM-Verlauf aus memoryHistoryCache mit Downsampling (max. 20 Punkte) → kompakt für Raspberry & Co.
                  Hinweis: In VIS z. B. Widget „String (unescaped)“ auf DashboardHTML legen. Bei abweichenden Adapter-Instanzen (influxdb.2 etc.) custom im Script anpassen.

                  CHANGELOG v4.6.3 (17.04.2026) Performance, Bugfixes, Stabilität.


                  ✅ formatCPUAlertMessage() ergänzt → war nicht definiert, sonst ReferenceError beim CPU-Kritisch-Alarm
                  ✅ Stats-Zyklus-Cache: getProcessStats() pro Adapter nur noch einmal pro Zyklus statt mehrfach → deutlich weniger getState()-Aufrufe
                  ✅ $()-Selector: aliveSelector einmal pro updateMonitoring() und an getDisabledAdapters() übergeben
                  ✅ Log-History: Obergrenze pro Adapter und Severity (errors / warns) → Schutz vor RAM-Wachstum bei Dauerfehlern
                  ✅ Memory-History: harte Obergrenze der gespeicherten Punkte pro Adapter
                  ✅ Schedule-Fix: cleanupAllLogErrors von */60 * * * auf 5 Felder */60 * * * * → Cleanup lief vorher nicht
                  ✅ purgeOrphanAdapterPersistentData() nur noch stündlich statt bei jedem Monitoring-Zyklus
                  ✅ Pulse-States: setStateDelayed(…, clearRunning=true) statt setTimeout für Restart-/Flaky-Pulse → weniger Überschneidungen
                  Hinweis: Script neu starten. Bei bereits existierendem DashboardHTML ohne custom ggf. History in der Admin-UI prüfen (siehe v4.6.4).

                  CHANGELOG v4.6.2 (14.04.2026) Pushover als zweiter Benachrichtigungskanal neben Telegram.


                  ✅ Pushover-Unterstützung: Neuer Konfig-Block mit PUSHOVERENABLE, PUSHOVERINSTANCE, PUSHOVERDEVICE, PUSHOVERTITLE und PUSHOVERPRIORITY (-2 bis 1) → komplett optional, per Default deaktiviert
                  ✅ Granulare Schalter: Jeder Alarmtyp hat einen eigenen Pushover-Schalter (PUSHOVERALERT) → analog zu den bestehenden TELEGRAMALERT-Flags
                  ✅ Gemeinsamer Cooldown: sendAlert() löst Telegram und Pushover gleichzeitig aus → ein Timer pro Alarmtyp verhindert Alarmflut auf beiden Kanälen
                  ✅ Keine Änderung für bestehende Nutzer: Telegram-Konfiguration bleibt unverändert

                  Hinweis: PUSHOVERENABLE: true setzen, PUSHOVERINSTANCE anpassen, Script neu starten. ioBroker Pushover-Adapter muss installiert und konfiguriert sein.

                  CHANGELOG v4.6.1 (13.04.2026) Minütliche Controller-Warnungen nach Adapter-Deinstallation behoben.


                  ✅ existsObject() vor getObject(): Fehlende system.adapter.*-Objekte werden übersprungen → keine minütlichen „Object … does not exist“-Warnungen mehr
                  ✅ History-Bereinigung: Uptime-, Log- und Memory-Einträge deinstallierter Instanzen werden beim Monitoring-Lauf automatisch entfernt

                  Hinweis: Aktueller ioBroker.javascript-Adapter mit existsObject() empfohlen. Script neu starten.

                  CHANGELOG v4.6.0 (20.03.2026) Konfigurationsbereich vollständig neu strukturiert.


                  ✅ Neue Konfig-Struktur: Benutzerwerte, Schwellwerte und Expertenwerte klar getrennt
                  ✅ Benutzer-Checkliste ergänzt: Schneller erkennbar, welche Werte angepasst werden sollen
                  ✅ Einheitliche Kommentare und Abschnittsüberschriften → forumtauglicher, übersichtlicher, leichter wartbar
                  ✅ Kein funktionaler Eingriff: Bestehende States, Prüfungen und Features bleiben vollständig erhalten
                  ✅ Neu: Deaktivierte Adapter: DisabledAdaptersCount und DisabledAdapters werden erfasst und als State geschrieben

                  Script
                  iobroker-prozessmonitor_v4.6.7

                  Das Dashboard (InfluxQL )
                  dashboard-4.6.0-Final

                  NEU 30.03.2026
                  Das Dashboard (Flux)
                  dashboard-4.6.0_flux

                  6f1fa838-d2ed-4bcc-979c-106f6c6d64b3-image.png
                  a993a827-5211-429f-8da5-439af66494c5-image.png
                  21551d26-8e42-4686-be68-3fd5b1bdba9d-image.png
                  b146f87b-c57e-4ca7-b972-5c8df09c06c3-image.jpeg

                  Offene Tuning-Punkte

                  • Flaky: aktuell 3 Restarts in 24h — sinnvoller Grenzwert, wenn geplante Cron-Restarts toleriert werden?
                  • Errors: aktuell 3/h Warnung und 20/h kritisch — passen diese Werte in anderen Umgebungen?
                  • Worst/Best Performer: Gewichtung des Health Scores noch offen für Feintuning.
                  • Degraded Adapter: aktuell kritische Error-Rate ab 10/h plus CPU > 12 und/oder Event Loop Lag > 100 ms — praxistauglich?
                  • Event Loop Lag: aktuell 500 ms kritisch als allgemeiner Schwellwert — vermutlich hardwareabhängig?
                  • Memory Leak: aktuell ab (R^2 > 0.65) und Wachstum > 15 MB/h — Erfahrungswerte willkommen.
                  • Deadlock: aktuell alive=true und connected=false — eventuell noch erweiterbar.
                  crunchipC Abwesend
                  crunchipC Abwesend
                  crunchip
                  Forum Testing Most Active Developer
                  schrieb am zuletzt editiert von crunchip
                  #73

                  crunchip sagte:

                  Grundprinzip je Datenpunkttyp

                  Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse):
                  Nur Änderungen aufzeichnen: an
                  Entprellzeit: 300–1000 ms
                  Blockzeit: 0
                  „Trotzdem gleiche Werte aufzeichnen“: 600–3600 s (je nach gewünschter History‑Auflösung)
                  Minimale Differenz: 0 (bei Booleans/Zahlen mit kleinem Bereich)
                  Ergebnis: sehr wenige Punkte, aber alle Zustandswechsel sauber im Grafana‑Dashboard.
                  Kontinuierliche Messwerte mit Trend (CPU‑Last, RAM‑MB, Host‑Disk‑FreeMB, Health‑Score):

                  Nur Änderungen aufzeichnen: an
                  Entprellzeit: 500 ms wie im Screenshot ist ok
                  „Trotzdem gleiche Werte“: auf deinen Script‑Zyklus bzw. Host‑Intervalle ausrichten, z. B. 180–300 s, damit Influx wenigstens alle paar Minuten einen Punkt bekommt, selbst wenn sich nichts ändert.
                  Minimale Differenz: z. B. 1 % bei CPU‑Werten, 5–10 MB bei RAM, 1 Punkt beim Health‑Score.
                  Ignoriere 0/Nullwerte: an, falls der DP beim Start kurz 0/NULL ist und das im Dashboard nicht stören soll.
                  Pulse‑Werte für Events (RestartEventPulse, FlakyEventPulse, Deadlock‑Alarm‑Pulse etc.):

                  Nur Änderungen: an
                  Trotzdem gleiche Werte: 0 s (nicht nötig, der Pulse ist ein kurzer Wechsel 0→1→0)
                  Entprellzeit: klein (100–200 ms), damit jeder Pulse als eigener Punkt landet.
                  0/Null ignorieren: aus, sonst siehst du nur die 1, aber keinen „Rückfall“ im Graphen.

                  @rallef hast du aber schon beachtet? und auch Punkt4 im ersten Beitrag?

                  umgestiegen von Proxmox auf Unraid

                  1 Antwort Letzte Antwort
                  0
                  • R Offline
                    R Offline
                    rallef
                    schrieb am zuletzt editiert von
                    #74

                    muss ich nachschauen

                    dp.jpg

                    1 Antwort Letzte Antwort
                    0
                    • R Offline
                      R Offline
                      rallef
                      schrieb am zuletzt editiert von
                      #75

                      muss ich das für alle datenpunkte unter prozesse ändern ?

                      1 Antwort Letzte Antwort
                      0
                      • R Offline
                        R Offline
                        rallef
                        schrieb am zuletzt editiert von
                        #76

                        ok aber was ist was
                        Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse): welche dp's sind das?

                        crunchipC 1 Antwort Letzte Antwort
                        0
                        • R Offline
                          R Offline
                          rallef
                          schrieb am zuletzt editiert von
                          #77

                          super vielen dank das habe ich noch nie berücksichtigt bei den anderen Datenpunkten meiner anderen Anwendungen. Vielleicht habe ich das problem schon vorher gehabt. aber das die Influxdb Instanz mehrmals täglich sich restartet ist neu. Werde alle Datenpunkte unter Prozesse heute abend mir anschauen und ggfls ändern. Hoffe das reicht dann damit Influxdb nicht mehr sich restartet

                          1 Antwort Letzte Antwort
                          0
                          • R rallef

                            ok aber was ist was
                            Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse): welche dp's sind das?

                            crunchipC Abwesend
                            crunchipC Abwesend
                            crunchip
                            Forum Testing Most Active Developer
                            schrieb zuletzt editiert von
                            #78

                            @rallef sagte:

                            ok aber was ist was

                            ich habs oben im ersten Beitrag ergänzt

                            umgestiegen von Proxmox auf Unraid

                            1 Antwort Letzte Antwort
                            0

                            Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.

                            Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.

                            Mit deinem Input könnte dieser Beitrag noch besser werden 💗

                            Registrieren Anmelden
                            Antworten
                            • In einem neuen Thema antworten
                            Anmelden zum Antworten
                            • Älteste zuerst
                            • Neuste zuerst
                            • Meiste Stimmen


                            Support us

                            ioBroker
                            Community Adapters
                            Donate

                            607

                            Online

                            32.8k

                            Benutzer

                            82.9k

                            Themen

                            1.3m

                            Beiträge
                            Community
                            Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                            ioBroker Community 2014-2025
                            logo
                            • Anmelden

                            • Du hast noch kein Konto? Registrieren

                            • Anmelden oder registrieren, um zu suchen
                            • Erster Beitrag
                              Letzter Beitrag
                            0
                            • Home
                            • Aktuell
                            • Tags
                            • Ungelesen 0
                            • Kategorien
                            • Unreplied
                            • Beliebt
                            • GitHub
                            • Docu
                            • Hilfe