Ik wilde nog eventjes apart van
mijn post hierboven een aanvulling en suggesties geven voor het ontwijken van resonantie snelheden. Maar voordat ik begin wil ik wel even highlighten dat Heatbooster in z'n huidige staat ook een goed product is. Ik wil vooral het feit dat @
Bazz0847 op Tweakers actief is gebruiken om mee te helpen denken over hoe heatbooster zo goed mogelijk te laten werken.
Ik identificeer de volgende issues bij ons:
1. Pendelen
In mijn geval geven de ranges tussen de 22%-32% en 54%-64% geven resonantie. De optie met vaste snelheden lossen dit deels op, al horen we af en toe steeds kort fluiten achter elkaar als de fan snelheid die uitgerekend is gebaseerd op de curve rond de 30% blijft hangen en er steeds even onder of boven komt. Dan pendelt de fansnelheid heen en weer over een resonantie snelheid.
2. Granularity
De vaste snelheden zijn wel in de juiste richting, maar ik vind het is wel wat jammer om die hoge nauwkeurigheid die de fan curve instellingen bieden te moeten opgeven om twee kleine ranges te vermijden. De Tweaker in mij werd juist heel blij van de nauwkeurige controle. De huidige oplossing is dus limiterend in de zin dat je nauwkeurige regeling ook kwijtraakt op fansnelheden waar geen resonantie zou optreden. In mijn geval 1%-22%, 32%-54%, 64%-100%
3. Maximale snelheid
Onze warmtepomp verwarmt ook SWW via een driewegklep waardoor er af en toe even niet verwarmd wordt. het SWW wordt tot een veel hogere temperatuur verwarmd dan het CV water. Het lijkt er op dat wanneer de driewegklep weer naar verwarmen switched er een kleine hoeveelheid heet water de CV leidingen in wordt gepompt waardoor de Heatbooster fans naar het hoogste niveau springen. Wanneer de boost mode nog automatisch aanstaat kan dit 100% zijn. Dit geeft best heel veel lawaai plotseling en veroorzaakte wat verwarring bij mijn partner die dacht dat er iets aan de hand was met de warmtepomp.
Waar Shmax geschikt is om de fansnelheid te limiteren, is de boost mode dat niet aangezien deze geen eigen Ts2 heeft. Er is dus geen manier op het moment om te voorkomen dat de fans sneller draaien dan bijvoorbeeld 60% tijdens de automatische boost modus.
Hoe belangrijk zijn deze issues?
Van de bovenstaande potentiële issues verwacht ik dat issue 1 de enige is die zal worden ervaren door een bredere groep gebruikers. Issue 2 zal enige invloed hebben op de efficiëntie van systemen die vaste snelheden gebruiken, maar waarschijnlijk vrij weinig. Issue 3 is vrij relevant voor mensen die een efficiënte en kostenefficiënte set-up hebben met een SWW vat. In Engeland zijn dit er veel, maar in Nederland komt dit denk ik minder voor. Toch zou ik het iets meer relevantie geven omdat het wel een duurzame set-up is die vooral zou moeten worden aangemoedigd en dus het liefst ook goed wordt ondersteund.
Oplossing
Er rekening mee houdende dat @
Bazz0847 geen verzameling aan random features wil toevoegen, wat ik helemaal begrijp, zat ik na te denken over één oplossing die de bovenstaande oplossing moet kunnen bieden.
De issues kunnen worden samengevat als snelheden gebaseerd op een geoptimaliseerde regelcurve die problemen geven welke niet kunnen worden voorkomen zonder de regelcurve zelf te herconfigureren met minder optimale parameters.
Een oplossing voor dit probleem zou specifieke snelheden (en ranges aan snelheden) kunnen voorkomen zonder dat de regelcurve hiervoor minder optimaal wordt.
Het is logisch om het snelheidspercentage na de berekening van de regelcurve te pakken en deze aan te passen wanneer het binnen bepaalde ranges valt. Vergelijkbaar met de huidige vaste snelheden implementatie, met als verschil dat de ranges aan te passen moeten zijn en dat de snelheid die hier in plaats van wordt gebruikt minder belangrijk is.
Ik zat te denken, is de "print specifieke pagina's" notatie. Die is makkelijk te begrijpen en bekend bij end-users, en makkelijk te parsen. De percentages die niet toegestaan zijn zouden er dan als volgt uitzien: 22-32, 54-64, 70-100. 70-100 betekent effectief dat de fans nooit sneller draaien dan 70% De optie zou dan kunnen zijn: "de volgende standen zijn niet toegestaan". Dit zou geavanceerde gebruikers gelijkt een manier geven om de fansnelheid te limiteren tot een bepaald percentage. Om pendelen te voorkomen zijn er meerdere opties, maar het makkelijkste is waarschijnlijk om een bepaalde factor te kiezen die de threshold vormt.
Als deze factor 0.2 zou zijn en de range die ontweken moet worden is tussen 40% en 50%, dan is de range 10 procentpunten. met 0.2 * 10 procentpunten = 2 procentpunten. Dus als de doelsnelheid stijgt en boven de 40% komt blijft de daadwerkelijke snelheid 40%. Pas als de doelsnelheid 50% - 2 procentpunten = 48% wordt stijgt de daadwerkelijke snelheid naar 50%. Door niet het middenpunt tussen 40% en 50% te kiezen wordt pendelen voorkomen.
Het aanpassen van de interface is ook een mogelijkheid en kan breaking changes voorkomen. Ik kan me hierbij het volgende voorstellen:
Ter vergelijking, hier is de huidige interface:
De optionele snelheid aan de rechterkant kan ook worden weggelaten, maar op deze manier zouden de waarden van de huidige interface zouden kunnen worden overgezet in de nieuwe interface na een update zodat de gebruikers die de vaste snelheden al hebben aanstaan geen hinder ondervinden van de update.