:fill(white):strip_exif()/i/2004297244.jpeg?f=thumbmini)
:strip_icc():strip_exif()/u/252842/crop5c3460b3a1c08_cropped.jpeg?f=community)
Gisteren had ik net 7.0 RC2 geïnstalleerd 
. Vandaag upgrade naar 7.0. Beide keren zonder problemen 
.
. Vandaag upgrade naar 7.0. Beide keren zonder problemen .
:strip_exif()/u/206557/captain-obvious.gif?f=community)
/u/72062/logov2_resize.png?f=community)
/u/42458/icon.png?f=community){kind=icon}
Hoe draait 7.0 bij iedereen die heeft geupdate?
* MisteRMeesteR draait nog op 6.12.11 en wil eigk wachten op 7.0.1 oid
* MisteRMeesteR draait nog op 6.12.11 en wil eigk wachten op 7.0.1 oid
[ Voor 15% gewijzigd door MisteRMeesteR op 16-01-2025 19:38 ]
www.google.nl
Ik wacht eigenlijk altijd bij Unraid tot de eerste bugfixes zijn gedaan. Wacht wel tot 7.0.x of 7.x. Binnenkort maar eerst eens updaten naar de laatste 6.12 x versie.:
Hoe draait 7.0 bij iedereen die heeft geupdate?
* MisteRMeesteR draait nog op 6.12.11 en wil eigk wachten op 7.0.1 oid
/u/375324/crop5d95a2d427d1d_cropped.png?f=community)
Ik heb nog geen problemen ervaren. Dag van release al geupdatet:
Hoe draait 7.0 bij iedereen die heeft geupdate?
* MisteRMeesteR draait nog op 6.12.11 en wil eigk wachten op 7.0.1 oid
Share and Enjoy!
:strip_icc():strip_exif()/u/150113/q3icon.jpg?f=community)
:no_upscale():strip_icc():strip_exif()/f/image/Pc57QJvTKoDK6Ytz58iVfq1a.jpg?f=user_large)
Iemand enig idee?
Is kort na de 7.0 update begonnen maar vermoed niet dat het gerelateerd is.
De installatie/config heb ik al op een andere usb stick omgezet maar blijf het dus nog krijgen.
Server draait maar loopt vast en bij reboot krijg ik dit dus.
Iemand al gelijkaardig meegemaakt?
Edit: gloednieuwe usb stick, andere usb poorten ook al geprobeerd.
[ Voor 6% gewijzigd door masauri op 30-01-2025 19:53 ]
/u/417466/crop6894bbdbb0a04_cropped.png?f=community)
Weet je zeker dat je systeem van de Unraid flash wil booten? Heb zelf weleens gehad dat er op het moederbord nog een SD kaartje zat welke als first boot device stond ingesteld. Kun je booten via het boot-menu en daar de 100% juiste USB flash selecteren?:
[Afbeelding]
Iemand enig idee?
Is kort na de 7.0 update begonnen maar vermoed niet dat het gerelateerd is.
De installatie/config heb ik al op een andere usb stick omgezet maar blijf het dus nog krijgen.
Server draait maar loopt vast en bij reboot krijg ik dit dus.
Iemand al gelijkaardig meegemaakt?
Edit: gloednieuwe usb stick, andere usb poorten ook al geprobeerd.
www.google.nl
:strip_exif()/u/21351/crop5a7ff7629b631_cropped.gif?f=community)
/u/305672/TLM.png?f=community)
@masauri , lijkt erop dat je USB stick geen GUID meer heeft als ik het scherm zo zie?
Zelf nog niet bijgewerkt naar 7.0.0 want verbouwingen aan het doen en NAS staat bij mijn ouders en niet meteen een netwerk aansluiting waar deze nu staat. Als de server terug op zijn plaats staat zullen de bugs er vast en zeker wel uit zijn, hoewel heb zelf nog nooit problemen gehad met updates, hout vasthouden
Ben zelf nog altijd aan het spelen met idee om een nieuwe server te bouwen, dit keer in een rack mount case met een Intel Core i5-13500 op een Z690 mobo. Een LSI 9300-16i heb ik reeds liggen en getest gehad in de huidige server om te zien of deze werkte, wat het geval was. Die HBA wordt wel serieus warm op de heatsink dus gaan we een fan shroud erop monteren + Noctua fan om het zaakje koel te houden.
Alleen de server case is nog een vraagstuk, eventueel een Inter-Tech 4U-4724 (24 bays) maar de afwerking van deze is minder dan bijvoorbeeld de Silverstone RM43-320-RS (20 bays) die wel €250 duurder is dan de Inter-Tech. De Silverstone is wel een stuk beter afgewerkt (minder scherpe randen) en waar de rack rails ook reeds bij zijn, niet dat dit de grote kost is.
Maar een ander voordeel, lijkt me toch want nog geen ervaring met rack mount cases, van de Silverstone is dat er per rij van schijven een backplane is, dus 5 in totaal voor de 20 bays. Terwijl er bij de Inter-Tech maar 2 backplanes zijn, dus als er eentje uitvalt ben je meteen 12 schijven kwijt en moet je maar zien aan een nieuwe backplane te komen.
Zijn er mensen die gebruik maken van een rack mount case, zo ja welke hebben jullie en wat zijn de ervaringen hiermee?
Zelf nog niet bijgewerkt naar 7.0.0 want verbouwingen aan het doen en NAS staat bij mijn ouders en niet meteen een netwerk aansluiting waar deze nu staat. Als de server terug op zijn plaats staat zullen de bugs er vast en zeker wel uit zijn, hoewel heb zelf nog nooit problemen gehad met updates, hout vasthouden
Ben zelf nog altijd aan het spelen met idee om een nieuwe server te bouwen, dit keer in een rack mount case met een Intel Core i5-13500 op een Z690 mobo. Een LSI 9300-16i heb ik reeds liggen en getest gehad in de huidige server om te zien of deze werkte, wat het geval was. Die HBA wordt wel serieus warm op de heatsink dus gaan we een fan shroud erop monteren + Noctua fan om het zaakje koel te houden.
Alleen de server case is nog een vraagstuk, eventueel een Inter-Tech 4U-4724 (24 bays) maar de afwerking van deze is minder dan bijvoorbeeld de Silverstone RM43-320-RS (20 bays) die wel €250 duurder is dan de Inter-Tech. De Silverstone is wel een stuk beter afgewerkt (minder scherpe randen) en waar de rack rails ook reeds bij zijn, niet dat dit de grote kost is.
Maar een ander voordeel, lijkt me toch want nog geen ervaring met rack mount cases, van de Silverstone is dat er per rij van schijven een backplane is, dus 5 in totaal voor de 20 bays. Terwijl er bij de Inter-Tech maar 2 backplanes zijn, dus als er eentje uitvalt ben je meteen 12 schijven kwijt en moet je maar zien aan een nieuwe backplane te komen.
Zijn er mensen die gebruik maken van een rack mount case, zo ja welke hebben jullie en wat zijn de ervaringen hiermee?
:strip_icc():strip_exif()/u/140051/BSOD.jpg?f=community)
Syslog laten opslaan op een cache disk (of array) om te zien of een je aanwijzing kan vinden. Nooit laten opslaan op je usb-stick. Daardoor degradeert je USB te snel.:
[...]
ik heb een monitor aangesloten , maar die laat gewoon een bevroren beeld zien...
Op de monitor je syslog openen. dan kan je op de monitor de laatste meldingen zien.:
[...]
ik heb een monitor aangesloten , maar die laat gewoon een bevroren beeld zien...
code:
1
| tail -f /var/log/syslog |
:strip_exif()/u/101588/the_lemmings_masacre_2_by_wormthingy.gif?f=community)
Redelijk recent ben ik overgestapt van Unraid 6 naar 7.0 en eigenlijk direct door naar 7.1, maar ik ben er eigenlijk niet heel erg blij mee 
. Waar Unraid 6 voor mij altijd enorm stabiel was, loop ik nu toch tegen kleine problemen aan die relatief veel tijd kosten.
De afgelopen week was af en toe mijn server onbereikbaar en dat werd ook steeds erger. Gisterochtend ben ik daar eens in gedoken en kwam ik tegen dat kswapd0 enorm veel CPU vrat. Maar ik heb helemaal geen swap geconfigureerd
. Echter ging het systeem swappen bij 16GB of 50% geheugengebruik. De andere 16GB was beschikbaar volgens top en free, maar blijkbaar niet te gebruiken? Een reboot loste dit probleem uiteindelijk op en ik kan u ook weer gewoon mijn 32GB gebruiken 
. Het enige vermoeden wat ik heb is dat de iGPU een sloot geheugen heeft geclaimed, want ook /dev/shm was zo goed als leeg. Dit was niet de eerste keer dat ik dit zag.
Na de reboot om bovenstaand probleem op te lossen kreeg ik ook Host Access to Custom Networks in Docker met geen mogelijkheid meer aan de praat. Normaal moest ik sowieso na een reboot het vinkje een keer omzetten om dit te laten werken, maar ook dat werkte nu niet.
Ik kwam verschillende posts op het Unraid forum tegen met vergelijkbare issues sinds 7.1(.2). Maar helaas zonder oplossing. Uiteindelijk heb ik hiervoor de Docker service gestopt en handmatig maar het shim netwerk aangemaakt:
Normaal gebruikte ik de ipvlan driver, maar die moest ik ook inwisselen voor macvlan om het weer te laten werken.
Niet het einde van de wereld, maar vooral vervelend omdat de oorzaak niet echt duidelijk is.
. Waar Unraid 6 voor mij altijd enorm stabiel was, loop ik nu toch tegen kleine problemen aan die relatief veel tijd kosten.De afgelopen week was af en toe mijn server onbereikbaar en dat werd ook steeds erger. Gisterochtend ben ik daar eens in gedoken en kwam ik tegen dat kswapd0 enorm veel CPU vrat. Maar ik heb helemaal geen swap geconfigureerd
. Echter ging het systeem swappen bij 16GB of 50% geheugengebruik. De andere 16GB was beschikbaar volgens top en free, maar blijkbaar niet te gebruiken? Een reboot loste dit probleem uiteindelijk op en ik kan u ook weer gewoon mijn 32GB gebruiken . Het enige vermoeden wat ik heb is dat de iGPU een sloot geheugen heeft geclaimed, want ook /dev/shm was zo goed als leeg. Dit was niet de eerste keer dat ik dit zag.Na de reboot om bovenstaand probleem op te lossen kreeg ik ook Host Access to Custom Networks in Docker met geen mogelijkheid meer aan de praat
. Normaal moest ik sowieso na een reboot het vinkje een keer omzetten om dit te laten werken, maar ook dat werkte nu niet.Ik kwam verschillende posts op het Unraid forum tegen met vergelijkbare issues sinds 7.1(.2). Maar helaas zonder oplossing. Uiteindelijk heb ik hiervoor de Docker service gestopt en handmatig maar het shim netwerk aangemaakt:
ip link add shim-br0 link br0 type macvlan mode bridge ip link set shim-br0 up
Normaal gebruikte ik de ipvlan driver, maar die moest ik ook inwisselen voor macvlan om het weer te laten werken.
Niet het einde van de wereld, maar vooral vervelend omdat de oorzaak niet echt duidelijk is.
Een SSD is een SSD.
. Ik ken helaas genoeg mensen die parity als backup zien en dan teleurgesteld / verdrietig / verontwaardigd zijn als het bijvoorbeeld bij een rebuild misgaat. Vandaar dat ik zoiets altijd scherp stel 
.
Nu sla ik toch wel even steil achterover.
Ik heb de voorbije dagen redelijk wat Docker containers aangemaakt.
Toen ik wou inloggen via ssh en geen connectie kreeg heb ik de server herstart.
Nu zijn al deze containers verdwenen tussen 2 weken en nu.
Ik heb wel nog alle datamappen staan in de appdata folder maar ze staan niet in het overzicht?
Heeft iemand een idee waar ik moet beginnen zoeken naar de oorzaak?
Nu is er wel immens veel werk verloren.
Ik heb de voorbije dagen redelijk wat Docker containers aangemaakt.
Toen ik wou inloggen via ssh en geen connectie kreeg heb ik de server herstart.
Nu zijn al deze containers verdwenen tussen 2 weken en nu.
Ik heb wel nog alle datamappen staan in de appdata folder maar ze staan niet in het overzicht?
Heeft iemand een idee waar ik moet beginnen zoeken naar de oorzaak?
Nu is er wel immens veel werk verloren.
Adem in, adem uit:
Nu sla ik toch wel even steil achterover.
Ik heb de voorbije dagen redelijk wat Docker containers aangemaakt.
Toen ik wou inloggen via ssh en geen connectie kreeg heb ik de server herstart.
Nu zijn al deze containers verdwenen tussen 2 weken en nu.
Ik heb wel nog alle datamappen staan in de appdata folder maar ze staan niet in het overzicht?
Heeft iemand een idee waar ik moet beginnen zoeken naar de oorzaak?
Nu is er wel immens veel werk verloren.
Als je een nieuwe container wilt maken, kan je uit de template lijst verschillende dockers selecteren.
Wanneer je deze aanklikt dan komen alle oude instellingen terug en hoef je enkel nog op "apply" te klikken.
De waarom vraag kan ik niet beantwoorden maar je bent binnen no-time weer "online".
Bedankt voor de tip.:
[...]
Adem in, adem uit
Als je een nieuwe container wilt maken, kan je uit de template lijst verschillende dockers selecteren.
Wanneer je deze aanklikt dan komen alle oude instellingen terug en hoef je enkel nog op "apply" te klikken.
De waarom vraag kan ik niet beantwoorden maar je bent binnen no-time weer "online".
Ik zie echter wel dat instellingen die ik gemaakt heb ongedaan zijn gemaakt.
Er zijn zelfs containers terug gekomen die ik verwijderd had.
Het is alsof er een snapshot genomen is waar hij na de reboot terug is gegaan.
Edit:
Met behulp van Chatgpt even in de logs gedoken. Daaruit blijkt dat alle wijzigingen sinds vorige maand niet naar de flashdrive zijn weggeschreven en dus alles verloren is gegaan na de reboot.
Worden normaal alle wijzigingen weggeschreven naar de flashdrive wanneer men afsluit of herstart of gebeurd dit tussentijds ook?
[ Voor 19% gewijzigd door Asterion op 11-07-2025 20:46 ]
Ik vind de Appdata backup echt de meest onzinnige plugin die er bestaat. Welke aardappel verzint het om de Docker service daarvoor te stoppen ? Ik snap best dat dat het veiligste is, maar regel dan als je bezig bent je backups gewoon correct in.
Ik gebruik nu al enkele jaren Kopia voor mijn backups. Dat is een deduplicerende backup tool. Ook als container te installeren via de apps store. De initiële opzet is niet bijster complex, maar wel even iets waar je op moet letten. Daarna heb je eigenlijk geen omkijken meer naar.
Mijn appdata en flash drive worden elke 4 / 6 uur gebackupt naar een externe disk:
/f/image/9fzF903yM0EClus1iGWhJ1UM.png?f=fotoalbum_large)
Deze backup schrijf ik daarna ook weg naar twee remote locaties.
Met mijn retentie policy heb ik eveneens genoeg mogelijkheden om bij problemen nog zaken te restoren:
/f/image/PZ3YBD4QOeWP2bVEdAY83C2R.png?f=fotoalbum_large)
En de backup is via de webinterface benaderbaar en browsebaar:
:strip_exif()/f/image/oThuxZLHMEBaOdE00pVGpHHT.png?f=user_large)
Omdat Kopia comprimerend én deduplicerend werkt is mijn backup 'maar' 440GB. Terwijl 1 snapshot al 530GB zou moeten zijn.
Bovenstaand heeft natuurlijk geen zin als de configuratie niet wordt weggeschreven
.
@Asterion Veel werk verloren valt ook wel weer mee. Daarnaast, als het zo belangrijk was, had je wellicht ook de tijd moeten nemen om het te documenteren.
? Ik snap best dat dat het veiligste is, maar regel dan als je bezig bent je backups gewoon correct in.Ik gebruik nu al enkele jaren Kopia voor mijn backups. Dat is een deduplicerende backup tool. Ook als container te installeren via de apps store. De initiële opzet is niet bijster complex, maar wel even iets waar je op moet letten. Daarna heb je eigenlijk geen omkijken meer naar.
Mijn appdata en flash drive worden elke 4 / 6 uur gebackupt naar een externe disk:
:strip_exif()/f/image/9fzF903yM0EClus1iGWhJ1UM.png?f=user_large)
Deze backup schrijf ik daarna ook weg naar twee remote locaties.
Met mijn retentie policy heb ik eveneens genoeg mogelijkheden om bij problemen nog zaken te restoren:
:strip_exif()/f/image/PZ3YBD4QOeWP2bVEdAY83C2R.png?f=user_large)
En de backup is via de webinterface benaderbaar en browsebaar:
Omdat Kopia comprimerend én deduplicerend werkt is mijn backup 'maar' 440GB. Terwijl 1 snapshot al 530GB zou moeten zijn.
Bovenstaand heeft natuurlijk geen zin als de configuratie niet wordt weggeschreven
.@Asterion Veel werk verloren valt ook wel weer mee. Daarnaast, als het zo belangrijk was, had je wellicht ook de tijd moeten nemen om het te documenteren
.
Sinds Unraid 7 heb ik eigenlijk een beetje een gek probleem. Ik ben niet 100% zeker of het door Unraid 7 komt, maar het is wel toevallig dat het sinds toen is gaan spelen. Af en toe is mijn server niet meer bereikbaar. Of eigenlijk heel traag. Het komt vast door een proces die helemaal uit de klauwen loopt, maar als ik mijn Beszel monitoring ga bekijken zie ik niets geks:
/f/image/uyv96D7KghULQc7eO8r6FI76.png?f=fotoalbum_large)
Wat ik wel zie op zo'n moment is dat kswapd0 en kcompactd0 nagenoeg alle CPU cycles opsnoepen. Als ik een of meerdere containers stop (bijv. Plex of Paperless-ngx) dan normaliseert het weer. Een reboot lost het sowieso op.
Ik heb geen swap ingesteld en volgens free of top heb ik op zo'n moment ook voldoende geheugen:
Als ik echter een stress test draai dan gaat dit ook goed:
En doe ik hetzelfde met 'teveel' geheugen krijg ik ook netjes een fail:
Gek genoeg is daarna de buff/cache wel een heel stuk leger, maar volgens mij betekend dat niets.
Het enige echte aanknopingspunt of iets wat echt heel vreemd is, is dat mijn Caddy setup met caddy-docker-proxy compleet stopt met werken. Het is dus net of Docker API / Socket niet meer bereikbaar is. Maar ik zie daar verder niets geks terug. Ook niet in de Unraid logging.
Vergelijkbare problemen heb ik ook gevonden op het Unraid forum, maar zonder resultaat. Ik vind het wel jammer want Unraid 6 was enorm stabiel.
:strip_exif()/f/image/uyv96D7KghULQc7eO8r6FI76.png?f=user_large)
Wat ik wel zie op zo'n moment is dat kswapd0 en kcompactd0 nagenoeg alle CPU cycles opsnoepen. Als ik een of meerdere containers stop (bijv. Plex of Paperless-ngx) dan normaliseert het weer. Een reboot lost het sowieso op.
Ik heb geen swap ingesteld en volgens free of top heb ik op zo'n moment ook voldoende geheugen:
root@LeeTower:~# free -h
total used free shared buff/cache available
Mem: 31Gi 17Gi 2.6Gi 4.1Gi 15Gi 13Gi
Swap: 0B 0B 0B
Als ik echter een stress test draai dan gaat dit ook goed:
root@LeeTower:~# docker run -ti --rm polinux/stress stress --cpu 1 --io 1 --vm 4 --vm-bytes 4G --timeout 10s stress: info: [1] dispatching hogs: 1 cpu, 1 io, 4 vm, 0 hdd stress: info: [1] successful run completed in 10s
En doe ik hetzelfde met 'teveel' geheugen krijg ik ook netjes een fail:
root@LeeTower:~# docker run -ti --rm polinux/stress stress --cpu 1 --io 1 --vm 8 --vm-bytes 4G -- timeout 10s stress: info: [1] dispatching hogs: 1 cpu, 1 io, 8 vm, 0 hdd stress: FAIL: [1] (415) <-- worker 11 got signal 9 stress: WARN: [1] (417) now reaping child worker processes stress: FAIL: [1] (451) failed run completed in 3s
Gek genoeg is daarna de buff/cache wel een heel stuk leger, maar volgens mij betekend dat niets.
root@LeeTower:~# free -h
total used free shared buff/cache available
Mem: 31Gi 14Gi 15Gi 4.1Gi 5.6Gi 16Gi
Swap: 0B 0B 0B
Het enige echte aanknopingspunt of iets wat echt heel vreemd is, is dat mijn Caddy setup met caddy-docker-proxy compleet stopt met werken. Het is dus net of Docker API / Socket niet meer bereikbaar is
. Maar ik zie daar verder niets geks terug. Ook niet in de Unraid logging.Vergelijkbare problemen heb ik ook gevonden op het Unraid forum, maar zonder resultaat. Ik vind het wel jammer want Unraid 6 was enorm stabiel.
@canonball Ik moest googlen wat Krusader is 
. Dus nee, die gebruik ik niet .
Ik gebruikte eerder ook veelvuldig /dev/shm maar daar ben ik ook maar mee gestopt om dit probleem te tacklen. Dat hielp overigens wel, maar uiteindelijk komt het toch terug.
Ik heb het vermoeden dat er iets misgaat in de berekening van het beschikbare geheugen. Het swappen gebeurt als ik circa 50% van het beschikbare geheugen daadwerkelijk in gebruik heb. Als ik de Beszel stats mag geloven ligt het ook niet aan de Docker containers, want daar veranderd niets, of weinig.
/f/image/41Ye9OIyoyfygNS71GldtzD9.png?f=fotoalbum_large)
Wat ik voornamelijk zo gek vind is dat de OOM killer niet getriggerd wordt, maar dat het systeem wel als een malloot gaat swappen. Bij Debian / Ubuntu systemen gaat dat in mijn ervaring toch aardig hand in hand.
Overigens post een user hier ongeveer hetzelfde en als ik dus de sysctl commando's overneem, kalmeert het systeem direct. Super vaag
. Dus nee, die gebruik ik niet .Ik gebruikte eerder ook veelvuldig /dev/shm maar daar ben ik ook maar mee gestopt om dit probleem te tacklen. Dat hielp overigens wel, maar uiteindelijk komt het toch terug.
Ik heb het vermoeden dat er iets misgaat in de berekening van het beschikbare geheugen. Het swappen gebeurt als ik circa 50% van het beschikbare geheugen daadwerkelijk in gebruik heb. Als ik de Beszel stats mag geloven ligt het ook niet aan de Docker containers, want daar veranderd niets, of weinig.
:strip_exif()/f/image/41Ye9OIyoyfygNS71GldtzD9.png?f=user_large)
Wat ik voornamelijk zo gek vind is dat de OOM killer niet getriggerd wordt, maar dat het systeem wel als een malloot gaat swappen. Bij Debian / Ubuntu systemen gaat dat in mijn ervaring toch aardig hand in hand.
Overigens post een user hier ongeveer hetzelfde en als ik dus de sysctl commando's overneem, kalmeert het systeem direct. Super vaag
:strip_icc():strip_exif()/u/157138/MonsterPrincess-SS.jpg?f=community)
@ErikRedbeard Goede gedachte, maar die vlieger gaat bij mij niet op. Ik heb door middel van taskset de Unraid processen op andere (E-)cores draaien . Tegelijkertijd is het ook niet één core die belast wordt. Ik kijk uiteraard niet alleen in Beszel, maar dat snap jij natuurlijk wel. kswapd0 en kcompactd0 pakken ergens tussen de 4 en 8 cores met een belasting van rond de 80-120 . Dat heurt niet zo. De Unraid processen komen niet eens voor in de top (pun intended).
De hoge IOPS gedachte is eveneens een goede poging die snel strandt. De meeste van mijn processen draaien langs shfs heen omdat deze inderdaad niet erg geoptimaliseerd is. Ook niet verwonderlijk aangezien het volgens mij door middel van FUSE gaat.
Het systeem vermoed ergens uit geheugen te zijn of de behoefte krijgen om geheugen te compacten. Maar dat raakt kant noch wal omdat ik - bijvoorbeeld vorige week - nog zo'n 30-50% geheugen vrij heb, al dan niet in shared/buffers. De kernel is het hier blijkbaar ook mee eens aangezien er eveneens geen oom-killer getriggerd wordt. Dan moet er iets gaar zijn. Of dat dan een Unraid proces is, een configuratie of mijn hardware, dat weet ik niet. Maar het klopt niet.
Sinds ik vorige week het compacten en swappiness heb uitgezet met ...
... draait het systeem alweer een week (zonder reboot) als een zonnetje.
/f/image/rNBU8IwWUSNVUJ8oISMoalOo.png?f=fotoalbum_large)
Toen ik echter als test de bovenstaande sysctl instellingen terugzette op de oorspronkelijke waardes ging het weer mis. Maar in ieder geval werkt het nu.
. Tegelijkertijd is het ook niet één core die belast wordt. Ik kijk uiteraard niet alleen in Beszel, maar dat snap jij natuurlijk wel. kswapd0 en kcompactd0 pakken ergens tussen de 4 en 8 cores met een belasting van rond de 80-120 . Dat heurt niet zo. De Unraid processen komen niet eens voor in de top (pun intended).De hoge IOPS gedachte is eveneens een goede poging die snel strandt. De meeste van mijn processen draaien langs shfs heen omdat deze inderdaad niet erg geoptimaliseerd is. Ook niet verwonderlijk aangezien het volgens mij door middel van FUSE gaat.
Het systeem vermoed ergens uit geheugen te zijn of de behoefte krijgen om geheugen te compacten. Maar dat raakt kant noch wal omdat ik - bijvoorbeeld vorige week - nog zo'n 30-50% geheugen vrij heb, al dan niet in shared/buffers. De kernel is het hier blijkbaar ook mee eens aangezien er eveneens geen oom-killer getriggerd wordt. Dan moet er iets gaar zijn. Of dat dan een Unraid proces is, een configuratie of mijn hardware, dat weet ik niet. Maar het klopt niet.
Sinds ik vorige week het compacten en swappiness heb uitgezet met ...
sysctl -w vm.swappiness=0 sysctl -w vm.compaction_proactiveness=0 sysctl -w vm.extfrag_threshold=1000
... draait het systeem alweer een week (zonder reboot) als een zonnetje.
:strip_exif()/f/image/rNBU8IwWUSNVUJ8oISMoalOo.png?f=user_large)
Toen ik echter als test de bovenstaande sysctl instellingen terugzette op de oorspronkelijke waardes ging het weer mis. Maar in ieder geval werkt het nu.
Geen probleem
. Dat overkomt me wel vaker .Voor read-only taken of grote bulk acties gebruik ik het wel, maar daar is het ook voor bedoeld. Alle Docker (app)data staat op SSD en wordt direct benaderd ipv shfs. Behalve als het echt niet anders kan.
Er gebeurt wel iets vreemds overigens met loads met hoge iops. Wanneer het systeem dus problemen heeft met swap/compact en ik een load start met veel iops wordt het systeem eveneens onmogelijk traag. Bijvoorbeeld ncdu. Ook wanneer dit via een directe mount gaat (bijv. /mnt/system). Vooralsnog heb ik dit eveneens onder geheugen tekort geschaard, maar misschien is dat ook niet de gehele waarheid. Dit is wederom niet meer voorgekomen.
:strip_icc():strip_exif()/u/228018/crop5ee8807bd52c7_cropped.jpeg?f=community)
/u/310759/crop5a8fa260a4c33_cropped.png?f=community)
Toen ik net met unRAID begon werden SSD's nog iets minder stevig gebakken en was ik binnen een jaar door 70% van de durability van m'n cache SSD heen gevreten grotendeels door downloads.
Maar goed, dat is inmiddels ook alweer een jaar of 7-8 geleden met een vrij kleine SSD. Op moderne SSD's is het wat minder relevant. Desalniettemin probeer ik dat soort intensieve schrijfacties op m'n cache te voorkomen.
Yes, je kan de 3e schijf toevoegen als 2e pool, en 'gewoon' de mover zaken tussen de array/pool1/pool2 laten schuiven.
[ Voor 6% gewijzigd door D4NG3R op 31-07-2025 13:38 ]
Komt d'r in, dan kö-j d’r oet kieken
Was dit niet door een bug in Unraid als er btrfs werd gebruikt voor de cache? Kan het verkeerd voorhebben. Nu mijn cache gebruikt reeds een tijd zfs.:
[...]
Toen ik net met unRAID begon werden SSD's nog iets minder stevig gebakken en was ik binnen een jaar door 70% van de durability van m'n cache SSD heen gevreten grotendeels door downloads.
[...]
Ben zelf ook reeds een tijd aan het denken om een nieuwe Unraid server op te zetten, niet dat de originele niet meer voldoet maar de HDD's koel houden in de Node 804 case is toch een dingetje.
Zit zelf te tobben om of wel een rack mount server te bouwen en in de berging te plaatsen daar heeft die ademruimte genoeg en dan heb 'k ook geen last van het eventuele geluid. Of een off-shelf NAS zoals de Aoostar WTR MAX of de Ugreen NASync DXP8800 Plus. Wel flink aan de prijs die laatste, voor wat meer kan ik zeker de zelfbouw route nemen.
Mijn droom case momenteel is de 45HomeLab HL15 2.0 maar ja die kost ook een aardige duit om maar niet te spreken over shipping en invoerrechten.
Ik heb oprecht geen idee, destijds (2017-18) had ik een oude 128GB MX100 als cache in m'n servertje zitten, beestje was in een kleine 13 maanden van 7% lifetime used naar 71% gevlogen.
Zal op een moderne (en vooral; grotere) SSD absoluut niet zo hard gaan, desalniettemin slinger ik downloads nog altijd eerst lekker naar een losse SSD waar ik weinig om geef voordat ze elders in hun geheel worden weggeschreven.
Komt d'r in, dan kö-j d’r oet kieken
Mijn primaire 1TB Samsung SSD heb ik volgens mij met de bouw van mijn Unraid machine in de zomer van 2023 in gebruik genomen. Daarvan zegt SMART nu dat deze 20% verbruikt is met 133TB geschreven. Maar ik doe 'alles' met deze disk. Alle appdata, Docker containers, Linux ISO's downloaden, etc. Met een lineaire aftakeling (en dat is niet zo) zou deze disk dus nog bijna 8 jaar mee moeten kunnen. Ik geloof dat wel, maar vind het zeker niet onredelijk.
De 1TB Crucial P1 die ernaast zit is een jaartje ouder, maar heeft 'maar' 30TB bytes written en daardoor nog 98% levensduur. Die zal ik dus sowieso niet snel verslijten.
Opslag blijft voor mij een gebruiksproduct. Heb ik ook een mooi excuus om te upgraden.
De 1TB Crucial P1 die ernaast zit is een jaartje ouder, maar heeft 'maar' 30TB bytes written en daardoor nog 98% levensduur. Die zal ik dus sowieso niet snel verslijten.
Opslag blijft voor mij een gebruiksproduct. Heb ik ook een mooi excuus om te upgraden
.
:strip_icc():strip_exif()/u/66496/purple-tentacle_small.jpg?f=community)
Ik trek zelf wekelijks een backup van m'n containers, dus in het ergste geval kan ik de boel wel reverten. Maar heel eerlijk is dat nog nooit nodig geweest, er zijn wel een aantal containers welke ik handmatig even een versie terug heb gezet. (en een enkele container blijft daar ook op)
Ik klik af en toe op update all containers, wil wel graag weten wanneer het nu precies fout is gegaan i.p.v. eerst te moeten zoeken of er niet toevallig een update is geweest.
Ik klik af en toe op update all containers, wil wel graag weten wanneer het nu precies fout is gegaan i.p.v. eerst te moeten zoeken of er niet toevallig een update is geweest.
Komt d'r in, dan kö-j d’r oet kieken
Dat laatste lijkt mij ook het grootste struikelblok. Ik laat elke nacht een appdata backup maken en er worden er slechts 3 bewaard. In het slechtste geval kom je er later achter dat een container kapot is gegaan en heb je geen goede backup meer. Ik denk dat jouw oplossing een goede is.:
Ik trek zelf wekelijks een backup van m'n containers, dus in het ergste geval kan ik de boel wel reverten. Maar heel eerlijk is dat nog nooit nodig geweest, er zijn wel een aantal containers welke ik handmatig even een versie terug heb gezet. (en een enkele container blijft daar ook op)
Ik klik af en toe op update all containers, wil wel graag weten wanneer het nu precies fout is gegaan i.p.v. eerst te moeten zoeken of er niet toevallig een update is geweest.
Dat is ook een beetje mijn gedachte. Het is heel prettig als alles gewoon blijft werken, maar het blijft hobby. Hoe lang bewaar je jouw backups? Wat is jouw instelling?
Goed om te horen. Ik neig er toch ook sterk naar om het maar gewoon te proberen met een goede backupstrategie. Het probleem is dat ik niet alle containers dagelijks gebruik, dus als er 1 kapot gaat kan het zijn dat ik daar pas veel later achter kom.
Ik beheer mijn Docker containers buiten Unraid om met Docker Compose. Updates doe ik met automatisch met Renovate en Forgejo Actions. Daar heb ik een hele tijd geleden alweer iets over geschreven in het Docker topic.
Dit zorgt ervoor dat ik precies kan zien wat wanneer gewijzigd is, en dus eventueel ook kan ingrijpen. Deze automatische updates gebeuren alleen overdag. Eveneens heb ik sommige updates zo ingesteld dat deze goedkeuring vereisen. Bijvoorbeeld bij Home Assistant en Zigbee2MQTT. Ik heb namelijk geen zin in onverwachte verrassingen.
Docker Compose (en Docker Swarm) installeer en configureer ik overigens met Ansible in plaats van de kant-en-klare Docker Compose uit de Apps store. Dit is niets meer dan de GitHub release uitpakken in /usr/local/lib/docker/cli-plugins/ en de juiste 0755 permissie meegeven. Deze houdt ik eveneens up to date met Renovate.
Backups maak ik met een Kopia container. Na de opzet heb ik hier geen omkijken meer naar en mijn appdata backups blijven tot één jaar bewaard. Door de deduplication neemt dit ook niet bijster veel ruimte in. Database snapshots maak ik live met de Postgres of MariaDB/MySQL tooling. Dit is ook niets meer dan een oneliner:
De database data / WALs houdt ik buiten de backup omdat deze waarschijnlijk toch niet (correct) te restoren zijn.
Denk er overigens aan dat backups alleen nuttig zijn als je ook regelmatig de restore test. Een backup zonder restore (test) is geen backup, maar waardeloze bytes.
Dit zorgt ervoor dat ik precies kan zien wat wanneer gewijzigd is, en dus eventueel ook kan ingrijpen. Deze automatische updates gebeuren alleen overdag. Eveneens heb ik sommige updates zo ingesteld dat deze goedkeuring vereisen. Bijvoorbeeld bij Home Assistant en Zigbee2MQTT. Ik heb namelijk geen zin in onverwachte verrassingen.
Docker Compose (en Docker Swarm) installeer en configureer ik overigens met Ansible in plaats van de kant-en-klare Docker Compose uit de Apps store. Dit is niets meer dan de GitHub release uitpakken in /usr/local/lib/docker/cli-plugins/ en de juiste 0755 permissie meegeven. Deze houdt ik eveneens up to date met Renovate.
Backups maak ik met een Kopia container. Na de opzet heb ik hier geen omkijken meer naar en mijn appdata backups blijven tot één jaar bewaard. Door de deduplication neemt dit ook niet bijster veel ruimte in. Database snapshots maak ik live met de Postgres of MariaDB/MySQL tooling. Dit is ook niets meer dan een oneliner:
# PostgreSQL docker exec -i immich-database /bin/bash -c 'PGPASSWORD=$POSTGRES_PASSWORD pg_dumpall --username=$POSTGRES_USER' > /mnt/applications/appdata/immich/database.sql # MariaDB / MySQL docker exec -i home-assistant-database sh -c 'mariadb-dump --all-databases > /var/lib/mysql/dump.sql'
De database data / WALs houdt ik buiten de backup omdat deze waarschijnlijk toch niet (correct) te restoren zijn.
Denk er overigens aan dat backups alleen nuttig zijn als je ook regelmatig de restore test
. Een backup zonder restore (test) is geen backup, maar waardeloze bytes.
Wow.. Haha bedankt! Gemini had het ook al over het nut van een restore test. Ik ga ernaar kijken.:
Ik beheer mijn Docker containers buiten Unraid om met Docker Compose. Updates doe ik met automatisch met Renovate en Forgejo Actions. Daar heb ik een hele tijd geleden alweer iets over geschreven in het Docker topic.
Dit zorgt ervoor dat ik precies kan zien wat wanneer gewijzigd is, en dus eventueel ook kan ingrijpen. Deze automatische updates gebeuren alleen overdag. Eveneens heb ik sommige updates zo ingesteld dat deze goedkeuring vereisen. Bijvoorbeeld bij Home Assistant en Zigbee2MQTT. Ik heb namelijk geen zin in onverwachte verrassingen.
Docker Compose (en Docker Swarm) installeer en configureer ik overigens met Ansible in plaats van de kant-en-klare Docker Compose uit de Apps store. Dit is niets meer dan de GitHub release uitpakken in /usr/local/lib/docker/cli-plugins/ en de juiste 0755 permissie meegeven. Deze houdt ik eveneens up to date met Renovate.
Backups maak ik met een Kopia container. Na de opzet heb ik hier geen omkijken meer naar en mijn appdata backups blijven tot één jaar bewaard. Door de deduplication neemt dit ook niet bijster veel ruimte in. Database snapshots maak ik live met de Postgres of MariaDB/MySQL tooling. Dit is ook niets meer dan een oneliner:
# PostgreSQL docker exec -i immich-database /bin/bash -c 'PGPASSWORD=$POSTGRES_PASSWORD pg_dumpall --username=$POSTGRES_USER' > /mnt/applications/appdata/immich/database.sql # MariaDB / MySQL docker exec -i home-assistant-database sh -c 'mariadb-dump --all-databases > /var/lib/mysql/dump.sql'
De database data / WALs houdt ik buiten de backup omdat deze waarschijnlijk toch niet (correct) te restoren zijn.
Denk er overigens aan dat backups alleen nuttig zijn als je ook regelmatig de restore test
Ondanks dat ik beter weet, moet ik zeggen dat ik eigenlijk nooit echt geplande restore tests doen. Wel ongeplande, als ik iets kapot gemaakt heb
Share and Enjoy!
Nadat ik relatief recent naar Unifi ben overgestapt heb ik vandaag eindelijk de moeite genomen om ook VLANs in te regelen op mijn Unraid machine. Ik zag hier een beetje tegen op door de enorm moeizame ervaring van een kennis van me, maar die zorgen waren uiteindelijk onterecht.
In Unifi heb ik allereerst een VLAN aangemaakt met ID 40:
/f/image/t3YYmvCAK4biL1ULAIMIjhLf.png?f=fotoalbum_large)
Ik heb daarna dat VLAN toegevoegd met dezelfde instellingen in Unraid's Network Settings:
/f/image/FO68ZhVoFZLACBVgoqo0wAqx.png?f=fotoalbum_large)
EDIT Ik had hier eerder staan dat IPv4 Address Assignment op None moest staan, maar dat klopt niet. Dit moet Automatic zijn. De None optie werkt maar maakt geen bridge of shims aan waardoor container <> container communicatie niet werkt. De Static optie is ook mogelijk, maar ik houd het liever dynamisch.
En vervolgens ook toegewezen in Docker Settings:
/f/image/sObIAgXP3QkWa3a6EO3rOGbs.png?f=fotoalbum_large)
Dat was het eigenlijk.
Na het aanpassen van het netwerk in de Compose definitie, werkte dit out of the box.
In Unifi heb ik allereerst een VLAN aangemaakt met ID 40:
:strip_exif()/f/image/t3YYmvCAK4biL1ULAIMIjhLf.png?f=user_large)
Ik heb daarna dat VLAN toegevoegd met dezelfde instellingen in Unraid's Network Settings:
:strip_exif()/f/image/FO68ZhVoFZLACBVgoqo0wAqx.png?f=user_large)
EDIT Ik had hier eerder staan dat IPv4 Address Assignment op None moest staan, maar dat klopt niet. Dit moet Automatic zijn. De None optie werkt maar maakt geen bridge of shims aan waardoor container <> container communicatie niet werkt. De Static optie is ook mogelijk, maar ik houd het liever dynamisch.
En vervolgens ook toegewezen in Docker Settings:
:strip_exif()/f/image/sObIAgXP3QkWa3a6EO3rOGbs.png?f=user_large)
Dat was het eigenlijk
.Na het aanpassen van het netwerk in de Compose definitie, werkte dit out of the box.
[ Voor 14% gewijzigd door alex3305 op 04-08-2025 16:24 ]
En dat ging goed?:
[...]
Ondanks dat ik beter weet, moet ik zeggen dat ik eigenlijk nooit echt geplande restore tests doen. Wel ongeplande, als ik iets kapot gemaakt heb
@masauri Zo uit het niets, of na gewijzigde instellingen of iets van een update?
( Waarom trouwens een van Binhexes z'n VPN containers draaien met Privoxy, zonder dat het VPN aspect actief is? )
( Waarom trouwens een van Binhexes z'n VPN containers draaien met Privoxy, zonder dat het VPN aspect actief is?
)
Komt d'r in, dan kö-j d’r oet kieken
zo uit t niets idd...:
@masauri Zo uit het niets, of na gewijzigde instellingen of iets van een update?
( Waarom trouwens een van Binhexes z'n VPN containers draaien met Privoxy, zonder dat het VPN aspect actief is?
ik heb indertijd de migratie door ed van spaceinvaders laten uitvoeren dus het heeft allemaal perfect gewerkt... tot nu dus...
Het meeste is ondertussen wel gezegd. Ik doe het updaten zoveel mogelijk automatisch ik heb alleen een 'vertraging' van een paar dagen toegevoegd. Daarvoor gebruik ik de plugin 'Auto Update Applications' dit werkt zowel voor plugins als voor docker. Hij wacht nu alleen (in mijn geval) 3 dagen voordat de nieuwe versie geupdate wordt. Dus als er iets mis is met een nieuwe release dan is er tegen de tijd dat het bij mij fout gaat (hopelijk) een nieuwe versie
@tomdh76 Schijven hebben altijd wat overhead afhankelijk van het bestandssysteem. Dit is altijd al zo geweest . Alleen lijkt dit met de grote disks ineens enorm veel.
. Alleen lijkt dit met de grote disks ineens enorm veel.
Ik ben zelf bezig met het toevoegen van twee nieuwe servers. 1 voor interne backup en 1 voor het high available maken van Pi-Hole en Home Assistant (vooral om ervoor te zorgen dat 'het huis het blijft doen' ). Ik wil ze eigenlijk beide truenas laten draaien om op die manier ook dat wat te leren kennen.
). Ik wil ze eigenlijk beide truenas laten draaien om op die manier ook dat wat te leren kennen.- De backup server is/wordt redelijk straight forward. Elke nacht wordt die door WoL aangezet om vervolgens intern een backup te draaien en deze backup ook meteen naar de cloud door te zetten. Deze server wordt dus mijn 2 en 1 van de 3, 2, 1 methode.
- De HA server heb ik nog niet helemaal helder, hoe ik dat voor elkaar moet krijgen. Hoe ga ik de twee instances van Pi-Hole en Home Assistant in sync houden? Hoe kun je het best de failover regelen? Doorgeven van de zigbee controller aan twee systemen?
Je kan voor Home Assistant in ieder geval een MySQL backend gebruiken, die kan je prima laten repliceren. Maar met Home Assistant is er veel meer ellende als je met dingen als Zigbee & ZWave aan de gang wilt. Ik zou het vooral als VM draaien en die laten repliceren zodat je die snel kan booten als t echt mis is ..:
Ik ben zelf bezig met het toevoegen van twee nieuwe servers. 1 voor interne backup en 1 voor het high available maken van Pi-Hole en Home Assistant (vooral om ervoor te zorgen dat 'het huis het blijft doen'Het lijkt erop alsof hetgeen ik wil niet kan en ik zou eigenlijk over moeten stappen op iets als proxmox. Zijn er mensen hier die dit al werkend hebben en wat insight kunnen delen?
- De backup server is/wordt redelijk straight forward. Elke nacht wordt die door WoL aangezet om vervolgens intern een backup te draaien en deze backup ook meteen naar de cloud door te zetten. Deze server wordt dus mijn 2 en 1 van de 3, 2, 1 methode.
- De HA server heb ik nog niet helemaal helder, hoe ik dat voor elkaar moet krijgen. Hoe ga ik de twee instances van Pi-Hole en Home Assistant in sync houden? Hoe kun je het best de failover regelen? Doorgeven van de zigbee controller aan twee systemen?
Owner of DBIT Consultancy | DJ BassBrewer
@Flans Beter laat dan nooit, maar ik draai wat diensten, o.a. AdGuard Home HA. Ik heb een primaire instantie op mijn primaire server draaien (duh ), maar tegelijkertijd draait mijn oude NUC ook nog met een secundaire instantie.
Home Assistant HA is met o.a. hardware koppelingen nogal lastig. Er zijn wel custom components die meerdere Home Assistant instanties kunnen syncen, maar dat was geloof ik niet bijster stabiel. Althans, er kwamen nogal eens wat breaking changes.
In mijn setup heb ik 1 instantie van Home Assistant op mijn primaire machine draaien, maar de hardware koppelingen draaien op mijn secundaire machine. Dat is een geluk bij een ongeluk, omdat er een bug in de Intel chipset zit van mijn primaire machine. Door deze bug gebruikt elk full speed USB apparaat zoals een Zigbee dongle, meteen 5W en gaat de processor niet meer naar de lagere C-states. Mijn Zigbee en Z-Wave netwerken blijven hierdoor dus door werken zonder Home Assistant.
), maar tegelijkertijd draait mijn oude NUC ook nog met een secundaire instantie.Home Assistant HA is met o.a. hardware koppelingen nogal lastig. Er zijn wel custom components die meerdere Home Assistant instanties kunnen syncen, maar dat was geloof ik niet bijster stabiel. Althans, er kwamen nogal eens wat breaking changes.
In mijn setup heb ik 1 instantie van Home Assistant op mijn primaire machine draaien, maar de hardware koppelingen draaien op mijn secundaire machine. Dat is een geluk bij een ongeluk, omdat er een bug in de Intel chipset zit van mijn primaire machine. Door deze bug gebruikt elk full speed USB apparaat zoals een Zigbee dongle, meteen 5W en gaat de processor niet meer naar de lagere C-states. Mijn Zigbee en Z-Wave netwerken blijven hierdoor dus door werken zonder Home Assistant.
Sinds een paar weken kon ik - ogenschijnlijk - na een Windows update ineens niet meer bij de Samba shares van mijn Unraid machine komen. Het is stom toeval dat dat ook de enige SMB shares zijn die in mijn netwerk hangen. Ik had al van alles geprobeerd om dit te verhelpen. Van netwerk profielen tot group policies en firewalls. Maar niets leek het op te lossen.
In een soort van wanhoopspoging heb ik daarom maar de Samba service op Unraid herstart:
Waarna het direct weer werkte
.
Geen idee wat er precies mis is gegaan, maar niet alle problemen liggen blijkbaar bij Windows Updates.
In een soort van wanhoopspoging heb ik daarom maar de Samba service op Unraid herstart:
/usr/local/etc/rc.d/rc.samba restart
Waarna het direct weer werkte
.Geen idee wat er precies mis is gegaan, maar niet alle problemen liggen blijkbaar bij Windows Updates
.
Mag ik vragen hoe jij de twee instanties van HA hebt opgezet en in sync houdt? Na wat ik las was dit vrij ingewikkeld en leek mij alleen maar meer werk qua onderhoud. Hoe sync jij bijvoorbeeld de database? Ik heb zelf Unraid draaien krachtig systeem (I7 12600K, Kontron moederbord), maar ik ben met HA overgestapt naar een kleine intel QOTOM pc i5.:
@Flans Beter laat dan nooit, maar ik draai wat diensten, o.a. AdGuard Home HA. Ik heb een primaire instantie op mijn primaire server draaien (duh
Home Assistant HA is met o.a. hardware koppelingen nogal lastig. Er zijn wel custom components die meerdere Home Assistant instanties kunnen syncen, maar dat was geloof ik niet bijster stabiel. Althans, er kwamen nogal eens wat breaking changes.
In mijn setup heb ik 1 instantie van Home Assistant op mijn primaire machine draaien, maar de hardware koppelingen draaien op mijn secundaire machine. Dat is een geluk bij een ongeluk, omdat er een bug in de Intel chipset zit van mijn primaire machine. Door deze bug gebruikt elk full speed USB apparaat zoals een Zigbee dongle, meteen 5W en gaat de processor niet meer naar de lagere C-states. Mijn Zigbee en Z-Wave netwerken blijven hierdoor dus door werken zonder Home Assistant.
Ik heb geen last van directe hardware koppelingen omdat ik de volgende ZigBee adapter heb: https://smartlight.me/sma...r1-multiradio-coordinator.
Misschien had ik het niet helemaal duidelijk verwoord, maar ik heb dus maar één instantie van Home Assistant draaien en dat dus op mijn primaire machine. Op mijn secundaire machine staat dan Zigbee2MQTT en Z-WaveJS. En daar zitten dan ook de desbetreffende adapters op aangesloten. Ik heb er de tijd en energie niet voor over om twee HA instanties draaiend te houden
.Maar goed, omdat Zigbee2MQTT en Z-WaveJS dus apart draaien, kan ik dus bijvoorbeeld ook automations daar koppelen in plaats van in Home Assistant. Bijvoorbeeld met clusters. Dat verminderd de eventuele afhankelijkheid. Alleen is dat hier off-topic
.