Die Variante von @liv-in-sky funktioniert nun einige Tage stabil. Danke fürs Helfen! Auch an dich @TT-Tom .

@oliverio
Da der RAM nie wirklich voll war, hatte ich den Fokus tatsächlich auf den IOPS. Mit dem gerade eben verbauten Riegel ist es nun deutlich schneller. Ich sehe immer noch teils 20% I/O wait auf der CPU, ist aber aus Nutzersicht verschmerzbar. Schneller geht bekanntlich immer.

@oliverio

Was mir im Gegensatz zur Influx 1 bei der Influx 2 auffällt: Verdoppelung der IOPS.
Und das ist vmtl. genau das Problem aus meiner Sicht: Die Seagate Ironwolfs, welche verbaut sind, haben 292 IOPS im Maximum angegeben. Das korreliert nicht so wirklich mit 500 bzw 1000 IOPS gem. Spec der Influx.

@oliverio Ja, ist wirklich knapp bemessen von Synology...da haben sie wieder gespart. Der Speicher ist zu 75% ausgelastet, sieht eher gut aus auch während der Zugriffe. Aber sobald die 16GB Erweiterung da sind, kann ich sagen, ob es wirklich nicht am Speicher liegt.

Danke schonmal für den Hinweis.

Hallo zusammen,

folgende Herausforderung:
Bislang habe ich meine influxdb auf dem Raspi betrieben. Ohne externen Speicher, alles lief auf der SD-Karte und es gab keinerlei Probleme.
Nun habe ich mir vor einigen Monaten eine neue Synology NAS angeschafft, es handelt sich um die 224+.
RAM ist wie gekauft = 2GB, und 2*2TB HDD sind verbaut.

Ich habe daraufhin die influxdb vom Raspi auf die NAS in einen Container umgezogen, eigentlich um die Sicherung einfacher zu gestalten, da die NAS sowieso immer über Nacht in die (deutsche) Cloud gesichert wird.

Nun ist mir aufgefallen, dass seitdem die Zugriffszeiten stark verzögert sind und häufiger ins Timeout laufen.
Nach längerer Suche scheinen die HDD's das Bottleneck zu sein, Stichwort IOPS. Dies bestätigte sich in der Tat, wenn ich live den Ressourcenmonitor beobachtete, während ich wahlweise über Lovelace oder Grafana die Datenbank bemüht habe.

Anstelle nun "einfach" meine HDDs auf SSDs umzubauen, was ich ungerne möchte (Kosten/Zeitmangel) stellt sich mir die Frage, ob ich die gemounteten Ordner des influxdb Containers nicht auf eine kleine externe SSD am USB-Port der NAS betreiben könnte.

Aber: Ich suche seit einiger Zeit nach verlässlichen Informationen, ob nicht doch die HDDs diesen Plan wieder durchkreuzen (Zwischenspeicherung, etc. und somit Ausbremsung auf die IOPS der HDD anstelle direkte Nutzung der IOPS-Möglichkeiten der externen SSD).

Falls hier jemand zuverlässige Informationen hat, wäre ich sehr dankbar.
Ein Hinweis noch: Der Arbeitsspeicher selber läuft nicht voll. Und selbst wenn: Habe eh gerade 16GB RAM bestellt, dann gäbe es dort so oder so kein Bottleneck (mehr).

Danke und VG

@bakerman23 Steht doch praktisch in der Readme. Etwas, das MQTT-fähig ist. Also auch iobroker mit mqtt-Adapter

@bakerman23 Tut i.d.R. auch nicht not, schließlich optimiert man nicht täglich und kann das an der Kiste dann selbst einstellen. Aber zum Verständnis hilft es ungemein.

Mittlerweile habe ich TCP aktiviert und den Port freigegeben, das fehlte noch.

In Tasmota sehe ich, dass die Verbindung erlaubt zu sein scheint:

06:36:20.429 TCP: Allowed through filter
06:38:38.732 TCP: Got connection from 192.168.178.57
06:38:38.734 TCP: Allowed through filter
06:39:28.889 TCP: Got connection from 192.168.178.57
06:39:28.890 TCP: Allowed through filter
06:40:19.492 TCP: Got connection from 192.168.178.57
06:40:19.493 TCP: Allowed through filter

Allerdings wirft iobroker weiter Errors, womit ich nach aktuellem Stand nichts anfangen kann und auf Tips hoffe:

zigbee.0 2024-10-03 07:38:38.866	info	starting. Version 1.10.3 in /opt/iobroker/node_modules/iobroker.zigbee, node: v18.17.1, js-controller: 6.0.11
zigbee.0 2024-10-03 07:38:39.021	info	Starting Zigbee npm ...
zigbee.0 2024-10-03 07:38:39.541	info	Installed Version: iobroker.zigbee@1.10.3
zigbee.0 2024-10-03 07:38:49.983	error	Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
zigbee.0 2024-10-03 07:38:49.984	error	unhandled promise rejection: Failure to connect
zigbee.0 2024-10-03 07:38:50.080	error	Error: Failure to connect at SerialDriver.resetForReconnect (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:347:19) at SerialDriver.emit (node:events:514:28) at SerialDriver.emit (node:domain:489:12) at /opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:348:22 at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:35:20) at Socket.<anonymous> (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:154:17)
zigbee.0 2024-10-03 07:38:50.081	error	Failure to connect
zigbee.0 2024-10-03 07:38:50.120	info	cleaned everything up...
zigbee.0 2024-10-03 07:38:50.123	info	Zigbee: disabling joining new devices.
zigbee.0 2024-10-03 07:38:50.168	warn	Failed to stop zigbee during startup
zigbee.0 2024-10-03 07:38:50.169	info	terminating
zigbee.0 2024-10-03 07:38:50.171	warn	Terminated (UNCAUGHT_EXCEPTION): Without reason
zigbee.0 2024-10-03 07:38:50.622	info	terminating

Hi zusammen,

bin bisweilen stiller Mitleser mit der Hoffnung, dass es eine Lösung der revoked Token geben wird.

Aber als Hinweis für alle, die ihre Daikin WP so wie ich etwas besser verstehen möchten:
https://raomin.github.io/ESPAltherma/
Die Bastelei hat mir den A*** gerettet, was die Optimierung der WP angeht. Das ewige Takten, was ich eigentlich nur durch "neben der WP stehen" mitbekommen hatte, konnte ich visualisieren und dann entsprechend mit Änderungen von Parametern reagieren. Am Gerät versteht sich.

Hi zusammen,

altes Topic, aber ich hoffe es liest noch wer meinen Request und kann helfen.

Was wurde erledigt:

• Sonoff Zigbee Bridge Pro mit Tasmota geflasht und eingerichtet
• Zigbee Adapter installiert und entsprechend der "alten" Anleitung konfiguriert, siehe Screenshot
  

Frage meinerseits: Port 8888 - Ich sehe über AngryIP keine Freigabe des Ports (Dort steht n/a). Habe ich was in Tasmota noch nicht konfiguriert? MQTT sowie HTTP API sind enabled (letzteres dürfte auf Port 80 laufen, ging aber probehalber total schief...)

Logfile vom Adapter, habe kurz auf Debug gestellt auch wenn dort keine aus meiner Sicht weiteren relevanten Infos drin sind:

zigbee.0 2024-10-02 19:48:06.383	debug	Plugin sentry Initialize Plugin (enabled=true)
zigbee.0 2024-10-02 19:48:07.127	info	starting. Version 1.10.3 in /opt/iobroker/node_modules/iobroker.zigbee, node: v18.17.1, js-controller: 6.0.11
zigbee.0 2024-10-02 19:48:07.184	debug	Using zigbee-herdsman with settings: {"network":{"panID":9876,"channelList":[11],"networkKey":[1,3,5,7,9,11,13,15,0,2,4,6,8,10,12,13],"extenedPanID":[239,205,171,137,103,69,35,1]},"databasePath":"/opt/iobroker/iobroker-data/zigbee_0/shepherd.db","backupPath":"/opt/iobroker/iobroker-data/zigbee_0/nvbackup.json","serialPort":{"baudRate":115200,"rtscts":false,"path":"tcp://192.168.178.110:8888","adapter":"ezsp"},"adapter":{"forceStartWithInconsistentAdapterConfiguration":false},"legacy":false}
zigbee.0 2024-10-02 19:48:07.299	info	delete old Backup files. keep only last 10
zigbee.0 2024-10-02 19:48:07.303	info	Starting Zigbee npm ...
zigbee.0 2024-10-02 19:48:07.353	debug	Backup /opt/iobroker/iobroker-data/zigbee_0/backup_2024_10_02-19_48_07.tar.gz success
zigbee.0 2024-10-02 19:48:07.361	debug	Starting zigbee-herdsman...
zigbee.0 2024-10-02 19:48:07.788	info	Installed Version: iobroker.zigbee@1.10.3
zigbee.0 2024-10-02 19:48:39.025	error	Starting zigbee-herdsman problem : "Failure to connect"
zigbee.0 2024-10-02 19:48:39.026	error	Failed to start Zigbee
zigbee.0 2024-10-02 19:48:39.027	error	Error herdsman start
'''

Danke im Voraus fürs Feedback, worauf ich noch achten sollte um die Bridge koppeln zu können!

@garfonso sagte in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

@basti-liciouz
das steht im Leitfaden?

Wenn du die Karten von github lädst, dann am besten rechts in der Spalte nach "releases" gucken, da das letzte nehmen. Da sollte eine gebaute .js Datei verlinkt sein. -> das ist die richtige. Und dann hast du auch eine Version (die schreibe ich immer einfach in den Dateinamen beim runterladen) und kannst gucken, ob die Karte noch aktuell ist.

Wenn das so nicht geht:
Gucken, ob es eine einzelne js-Datei gibt, dann die nehmen.

Es gibt ein paar wenige Karten, die die card-tools (oder so) brauchen. Die kannst du noch selber installieren.
Eine Karte hatte mal ganz viele Bilder gebraucht, die kann man mittlerweile auch in Ordner schieben. Würde ich aber nicht empfehlen...

Grundsätzlich git: Wenn da python-Dateien gebraucht werden, wird es vermutlich nicht (oder zumindest ein Teil nicht) gehen.

Und eine Karte mit typescript usw. würde ich an deiner Stelle nicht bauen, außer du kennst dich gut damit aus.

Ja, steht dort tatsächlich drin. Ist aber vmtl. eher ein Wink an den entsprechenden Entwickler, die js zu kompilieren. So interpretiere ich es jetzt nach deinem Feedback.
Danke für den Hinweis mit den Releases!