Community Forum

nograx

OliverIO

@Leonie sagte:

An der Stelle mag ich schonmal sagen, das eine DynDNS-Adresse bspw. von MyFritz! schon ausreichend ist, damit der BotFather zu Frieden ist.

wer einen port nach außen öffnet, sollte unbedingt einen
reverse proxy einsetzen um die Angriffsfläche zu verkleinern.
Weiterhin das noch mit fail2ban absichern, was aber ein wenig Beobachtung und Konfiguration erfordert

beides ist als dockercontainer verfügbar.
einen container mit dem reverse proxy ist sehr einfach
durch ein paar zusätzliche Anweisungen im docker compose welcher dann im internet auf anfragen horchen soll.
https://hub.docker.com/r/jwilder/nginx-proxy
https://hub.docker.com/r/linuxserver/fail2ban

kleine werbung in eigener Sache: Wer fail2ban mit einer webgui überwachen möchte kann sich diesen Container anschauen, leider ist die kommandozeile von fail2ban etwas grausam:
https://hub.docker.com/r/oweitman/fail2bancontrol
und zur Überwachung im iobroker:
https://github.com/oweitman/ioBroker.fail2bancontrol

DasBo1975

Nicht, dass ihr denkt, bei PoolControl geht es nicht weiter. 😉

Aktuell läuft der Adapter bewusst weiter im Latest-Repository, weil ich die laufende Poolsaison noch komplett als Testphase nutzen möchte.

Mein nächstes größeres Ziel steht aber schon fest: Wenn die Saison durch ist und alles weiterhin sauber läuft, möchte ich über die Wintermonate die Aufnahme von PoolControl ins Stable-Repository von ioBroker vorbereiten und anschließend beantragen.

Bis dahin bleibt Latest weiterhin die Teststrecke für die laufende Saison und natürlich auch für alles, was noch auffällt oder dazukommt.

Es geht also weiter – nur im Moment ganz bewusst ohne unnötige Hektik. 🙂

Leonie

@manne01 sagte:

Meinen Telegram Account zu verbinden - es kommt "Bot domain invalid" und meine "lokale" Domain bei Telegram mit /setdomain zu verknüpfen macht doch irgendwie keinen Sinn? Zur Domainregistrierung finde ich kaum Infos.

Ich ziehe das nochmal nach.
Leider habe ich selbst keinen Einfluss auf das was Telegram verlangt. Hannah nutzt ein "Login with Telegram" in der WebUI für die Verknüpfung. Dafür benötigt der BotFather eine Domain, die Domain unter der die WebUI erreichbar ist.
Leider funktionieren da keine IP-Adressen und keine lokalen Domains. Telegram erfordert eine öffentliche überprüfbare Domain. Nicht falsch verstehen, die WebUI muss nur eine öffentliche Domain nutzen, nicht aus der Öffentlichkeit erreichbar sein.
Ja, ist nicht ideal, aber den Ablauf gibt leider Telegram vor.
Ich selbst habe glücklicherweise eine eigene Domain. Unter der kann ich meine WebUI aufrufen und Telegram ist glücklich. Damit ich die aber aufrufen kann, muss ich zu Hause sein. Aus dem Internet geht es nicht.
An der Stelle mag ich schonmal sagen, das eine DynDNS-Adresse bspw. von MyFritz! schon ausreichend ist, damit der BotFather zu Frieden ist.

Liebe Grüße
Leonie

Leonie

Ihr Verrückten :D

Ich habe nun die letzten Stunden damit verbracht Container Images zu bauen. Habe die Services dafür verändert, meine Pipelines überarbeitet, aber hier ist nun das Composefile mit allem drin:

services:
 hannah-core:
   image: quay.io/m1kad0/hannah-core:latest
   container_name: hannah-core
   restart: unless-stopped
   pull_policy: always
   depends_on:
     mysql-db:
       condition: service_healthy
       required: false
     mosquitto:
       condition: service_healthy
       required: false
   ports:
     - "50051:50051"
   networks:
     - hannah_network
   volumes:
     - core_activity_audio:/app/activity_audio
     - core_audio_dumps:/app/audio_dumps
     - core_data:/app/data
     - ./core-config.yaml:/etc/hannah/config.yaml:ro

 hannah-webui:
   image: quay.io/m1kad0/hannah-webui:latest
   container_name: hannah-webui
   restart: unless-stopped
   pull_policy: always
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   ports:
     - "5000:5000"
   environment:
     HANNAH_WEBUI_SECRET_KEY: "SGVsbG8gV29ybGQhIFRoaXMgaXMgYSByYW5kb20gMTI4LWNoYXJhY3RlciBCYXNlNjQgc3RyaW5nIGNyZWF0ZWQgZm9yIHRlc3RpbmcgcHVycG9zZXMubmNlMXkyMw=="
     HANNAH_WEBUI_GRPC_HOST: "hannah-core"
     HANNAH_WEBUI_GRPC_PORT: "50051"

 hannah-telegram:
   image: quay.io/m1kad0/hannah-telegram:latest
   container_name: hannah-telegram
   restart: unless-stopped
   pull_policy: always
   profiles: ["full", "integrations", "telegram"]
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   volumes:
     - ./telegram-config.yaml:/etc/hannah-telegram/config.yaml:ro

 hannah-proxy:
   image: quay.io/m1kad0/hannah-proxy:latest
   container_name: hannah-proxy
   restart: unless-stopped
   pull_policy: always
   profiles: ["full", "with-proxy"]
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   volumes:
     - ./proxy-config.yaml:/etc/hannah-proxy/config.yaml:ro

 hannah-voiceid:
   image: quay.io/m1kad0/hannah-voiceid:latest-cpu
   container_name: hannah-voiceid
   restart: unless-stopped
   pull_policy: always
   profiles: ["full", "with-voiceid"]
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   volumes:
     - ./voiceid-config.yaml:/etc/hannah-voiceid/config.yaml:ro
     - hannah_mem:/mnt/hannah_mem

 hannah-timer:
   image: quay.io/m1kad0/hannah-timer:latest
   container_name: hannah-timer
   restart: unless-stopped
   pull_policy: always
   profiles: ["full", "with-timer"]
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   environment:
     HANNAH_TIMER_HANNAH_ADDRESS: "hannah-core:50051"
     HANNAH_TIMER_LOG_LEVEL: "info"
   volumes:
     - timer_data:/app/data

 mysql-db:
   image: mysql:8.0
   container_name: hannah-db
   profiles: ["full", "with-db"]
   environment:
     MYSQL_ROOT_PASSWORD: secretpassword
     MYSQL_DATABASE: hannah_db
     MYSQL_USER: hannah_user
     MYSQL_PASSWORD: hannah_pass
   networks:
     - hannah_network
   volumes:
     - mysql_data:/var/lib/mysql
   healthcheck:
     test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-psecretpassword"]
     interval: 5s
     timeout: 5s
     retries: 5

 mosquitto:
   image: eclipse-mosquitto:2
   container_name: hannah-mosquitto
   profiles: ["full","with-mqtt"]
   restart: unless-stopped
   networks:
     - hannah_network
   ports:
     - "1883:1883"
     - "9001:9001"
   volumes:
     - mosquitto_data:/mosquitto/data
     - mosquitto_log:/mosquitto/log
     - ./mosquitto.conf:/mosquitto/config/mosquitto.conf:ro
   healthcheck:
     test: ["CMD-SHELL", "nc -z localhost 1883 || exit 1"]
     interval: 5s
     timeout: 3s
     retries: 5

volumes:
 core_data:
 core_activity_audio:
 core_audio_dumps:
 timer_data:
 mysql_data:
 mosquitto_data:
 mosquitto_log:
 hannah_mem:

networks:
 hannah_network:
   driver: bridge

Gestartet werden kann der ganze Stack bspw. so: docker compose --profile full up -d
Am Besten tauscht ihr dann auch entsprechende Secrets aus, alles in dem File ist von meiner Seite aus Demo, aber voll getestet.

Für VoiceID habe ich eine cpu-only Version bereitgestellt. Eine Version mit GPU-Unterstützung kann ich aktuell nicht bauen, zumindest nicht automatisiert.

Mitgestartet wird auch ein MySQL-Server, der für den Activity Log genutzt wird. Warum ein MySQL-Server? Weil Hannah bei mir komplett auf einem Raspberry Pi läuft und ich mit der Datenbank für den Activty Log, die naturgemäß eine Menge Schreiboperationen aufweisen kann, die SD-Karte nicht belasten will.
Außerdem wird ein Mosquitto, als MQTT-Broker gestartet. Ich denke der ein oder andere von euch wird bereits einen Broker einsetzen, für alle anderen, ist hier die Vorlage.

Ich habe euch auch gleich einen Service dazu gepackt, den ich noch nicht vorgestelt habe: hannah-timer. Das ist ein Timerbackend für Core. Der hält alle Timer die Core stellen mag persistent. Egal ob man Wecker stellt, ob man sich an irgendwas erinnern lassen möchte oder einfach nur einer Eieruhr stellt, dieser Service sorgt für die Integrität.
Warum ein eigener Service? In der Entwicklung hat sich gezeigt das Core bei mir öfter neustarten muss, auch bspw. aufgrund von Updates. Timer ist so stabil, das er bereits seit Monaten bei mir ohne Downtime laufen kann. Außerdem kann so die ganze Timer-Logik aus dem Core draußen bleiben. Timer informiert Core aktiv, wenn ein Timer abgelaufen ist und stellt ihm wieder die Informationen bereit, die Core braucht um Aktionen zu ergreifen.

Eventuell bekommen in Zukunft noch weitere Services Unterstützung fürs Environment. Ich verstehe schon, das es sich doof anfühlt bspw. für den Proxy eine Configdatei mit 6 Zeilen zu schreiben, während timer bspw. Environment-Variablen hat. Faktisch unterstützen die meisten Services es nicht, da sind dann Configs notwendig.

Und natürlich werden die Images jetzt nicht bei mir gehostet, das heißt, die sollten zu jeder Zeit abrufbar sein :D

Liebe Grüße
Leonie

OliverIO

@Homoran

Evtl doch mal an eine Datenbank denken
https://github.com/ioBroker/ioBroker.history/blob/master/docs/de/README.md#history-daten-in-sql-oder-influxdb-übernehmen

Eine Datenbank geht etwas sorgsamer mit System Ressourcen um.
Der history Adapter hat ja für jeden Datenpunkt ein Verzeichnis.
Darin ist für jeden Tag eine Datei.
Bei jedem Mal einen Wert historisieren bedeutet das Datei öffnen, lesen, Daten anpassen, schreiben.
Das selbenpassiert parallel mit der states.jsonl für den aktuellen Wert.

Eine Datenbank lebt mit den gerade Interessanten hauptsächlich im Speicher. Schreiben findet dann einnwenigbzeitverzögert dann optimiert nicht pro Wert sondern gesammelt statt.

Redis geht leider nur als Ersatz für die aktuellen Daten, aber nicht für die history

krobi

danke an alle die ein gewisses Niveau einhalten und Fehler nachvollziehbar Melden. Wenn euch etwas auffallen solltet bitte immer nur zu - am besten ein Github Issue mit nachvollziehbaren Infos.

ps: Niemand wird gezwungen diesen Adapter zu nutzen oder zu testen, wer dies macht macht das freiwillig in der Absicht mir zu helfen. Danke

arteck

@krobi lol .. sei mir nicht böse aber ist schon lustig sich mit jemaden zu unterhalten der keine ahung von programmieren hat...

aber gut..ich habe ein zabbix bei mir laufen der sowas live per telegram meldet

Problem proxmox : ‼️ Proxmox: LXC [master/usv-serverschrank (lxc/103)] high memory usage (over 90% use)
Problem started at 18:41:49 on 2026.08.28
Problem name: ‼️ Proxmox: LXC [master/usv-serverschrank (lxc/103)] high memory usage (over 90% use)
Host: proxmox
Severity: Average
Operational data: Current use: 1.99 GB of 2 GB
Original problem ID: 11768523

Problem usv-serverschrank: 📕 Linux: Load average is too high (per CPU load over 2.5 for 5m)
Problem started at 18:47:21 on 2026.08.28
Problem name: 📕 Linux: Load average is too high (per CPU load over 2.5 for 5m)
Host: usv-serverschrank
Severity: Average
Operational data: Load averages(1m 5m 15m): (18.10498 14.842773 8.611328), # of CPUs: 2
Original problem ID: 11768563

ich habe die GIT Version des Adapter installiert .. also die 0.9.0 (hier funktioniert die offline meldung)

der rest ist irrelevant (aber ich bin auf beta)...

dein Befehl ist schön (generiert) aber du glaubst wohl nicht dass ich das live verfolge bzw das problem direkt aufkommt.

ich hab die kiste neu gestartet.. ich beobachte mal..

p.s: gruss an Klaus

krobi

@arteck hallo, das ist ein schwerwiegendes Thema in meinen Augen.

Wie hast du das festgestellt? Welche Adapter-Version hast du installiert? Du als Developer weißt ja, wie wichtig es ist, klare Informationen zu haben:

Welche Admin-Version hast du installiert?
Welche js-controller-Version hast du installiert?

Was sagt folgender Befehl dazu?

watch -n 1 'ps aux | grep "io.nut2.0" | grep -v grep | awk "{print \"CPU: \" $3 \"% | RAM: \" $6/1024 \" MB\"}"'

Ich habe das selbst natürlich direkt versucht nachzustellen, aber mein ioBroker inkl. CPU-Auslastung lässt das absolut kalt.

OliverIO

@Homoran

Auch mal ins syslog schauen

Dann
Ist zwar etwas weiter hergeholt und um die Suche in einem Adapter nicht zu aufwändig werden zu lassen:
Du hast jetzt 2 Adapter abgeschaltet.
Nicht das es nur an einem liegt, sondern durch die gesamtlast.

Auch eine Idee
Wenn der history Adapter viele datenpunkte pflegen muss, hat er viele dateihandles gleichzeitig offen. Wird ja alles in einzelnen Dateien gepflegt. Auch da gibt es Obergrenzen.

Noch eine Idee
Auch der interne Bus des Systems mit dem ram CPU ssd miteinander kommuniziert hat Grenzen. Da weiß ich aber nicht wie man da nachschaut. Ist aber eher am Ende der Wahrscheinlichkeiten

Daher mal das syslog um den Absturz herum untersuchen

Community Forum

Developer

Beiträge

Mitgliederliste