Itho Daalderop - open source wifi control add-on module

[cablegunmaster]

-Miura- schreef op zaterdag 5 september 2026 @ 07:35:
[...]

Dat is wel mogelijk. Je moet alleen een Virtual Remote gebruiken die dat ondersteunt. Ik heb de RFT CO2 gebruikt hiervoor. Werkt prima!

ik vond hem duur, ik zat eerder naar een SCD40 te kijken en een ESP32 (of iets wat minder energy slurpt) eraan te koppelen alleen dan is hij wat minder duurzaam omdat geen behuizing, maar dan moet ik iets bedenken om dit goed te bedekken.

Blijkbaar is alles goedkoop om hem te maken maar is de sensor een beetje duur (vergeleken met andere sensoren).
https://learn.adafruit.com/adafruit-scd-40-and-scd-41

Prijzen die ik ongv tegenkwam waren 160 voor zelfbouw inelkaar gezet door derde en verkoop en 180 als kit. Ik denk erover na om er zelf 1 te maken en deze te programmeren, zo moeilijk kan dit niet zijn. Het enige waar ik mee zit is het permanente gedeelte van een behuizing maken. (realistischere kosten 40-50 euro) maar wel zelf alles bouwen en enige overhead is invoerbelasting. dit is niet realistisch voor een product om te verkopen besef ik mij, maar wel voor eigenbouw.

Terug ontopic;
Want ik heb het idee als ik eenmaal een sensor heb dat ik deze kan toevoegen aan het systeem en de sensor kan toevoegen in HA aan de Itho Daalderop?

[ Voor 32% gewijzigd door cablegunmaster op 05-09-2026 13:42 ]

[Bingo the Clown]

Sinds oktober 2023 blije bezitter van de HRU 300 set. Ingesteld en via homebridge als fan toegevoegd aan mijn Apple homekit setup (status updates via MQTT). Kort geleden na een power outage was de homebridge sd kaart in de Raspberry Pi corrupt geworden. Toen dacht ik waarom doet het ithowifi bordje niet gewoon matter over wifi, sinds het voor de HRU300 eigenlijk alleen een beetje status uitleest en RF commando's verstuurd. Een weekendje en wat tokens later:

https://github.com/Cage78/itho-matter-fan,

de HRU300 wordt als matter fan plus wat temp sensors en de "summer boost" setting aan apple homekit gepresenteerd. Via de USB connector op dit bordje kan je het gewoon flashen. Bouwen is denk ik redelijk simpel dankzij alle AI documentatie

[TweakM]

Bingo the Clown schreef op zondag 6 september 2026 @ 15:02:
(…) Toen dacht ik waarom doet het ithowifi bordje niet gewoon matter over wifi, sinds het voor de HRU300 eigenlijk alleen een beetje status uitleest en RF commando's verstuurd. (…)

Wat een goed idee! Nu heeft niet iedereen een HRU300 en zijn er nog wat features die zouden kunnen worden toegevoegd (bijv. traploze fan instelling). @arjenhiemstra Is dit iets dat je zou willen overwegen om aan de bestaande firmware toe te voegen?

[PaulUitWijchen]

RemySoeters: Je vroeg om een C02 sensors: Ik heb een SCD30 aan een ESP32 hangen, samen met SDS011 voor de deeltjes en een DHT voor de temperatuur en vochtigheid. Verder heb ik in de koelkast een BT temp sensor zitten die praat met dezelfde EPS32. Die stuurt alles via WiFi naar HA. Werkt al een paar jaar probleemloos. Ook een paar ledjes rood, geel en groen die oplichten bij een bepaalde lucht kwaliteit. Ik moet er nog een keer een mooi kastje voor printen.

[arjenhiemstra]

TweakM schreef op zondag 6 september 2026 @ 22:39:
[...]

Wat een goed idee! Nu heeft niet iedereen een HRU300 en zijn er nog wat features die zouden kunnen worden toegevoegd (bijv. traploze fan instelling). @arjenhiemstra Is dit iets dat je zou willen overwegen om aan de bestaande firmware toe te voegen?

Toevoegen gaat het niet worden denk ik. Ik begeep van @Bingo the Clown dat de matter firmware te groot is om te passen in de huidige partitie setup. Met de huidige setup is het flash geheugen in twee stukken opgeknipt waarbij in elk stuk de hele firmware staat, hierdoor is het bijna onmogelijk om met een firmware update je device te bricken.
Nu maakt dat voor de non-cve versie iets minder uit want die zou via USB nog te flashen zijn (feitelijk wat @Bingo the Clown ook heeft gedaan met zijn device) maar voor de cve variant is dat niet zo makkelijk.

[arjenhiemstra]

cablegunmaster schreef op zaterdag 5 september 2026 @ 12:00:
[...]

ik vond hem duur, ik zat eerder naar een SCD40 te kijken en een ESP32 (of iets wat minder energy slurpt) eraan te koppelen alleen dan is hij wat minder duurzaam omdat geen behuizing, maar dan moet ik iets bedenken om dit goed te bedekken.

Blijkbaar is alles goedkoop om hem te maken maar is de sensor een beetje duur (vergeleken met andere sensoren).
https://learn.adafruit.com/adafruit-scd-40-and-scd-41

Prijzen die ik ongv tegenkwam waren 160 voor zelfbouw inelkaar gezet door derde en verkoop en 180 als kit. Ik denk erover na om er zelf 1 te maken en deze te programmeren, zo moeilijk kan dit niet zijn. Het enige waar ik mee zit is het permanente gedeelte van een behuizing maken. (realistischere kosten 40-50 euro) maar wel zelf alles bouwen en enige overhead is invoerbelasting. dit is niet realistisch voor een product om te verkopen besef ik mij, maar wel voor eigenbouw.

Terug ontopic;
Want ik heb het idee als ik eenmaal een sensor heb dat ik deze kan toevoegen aan het systeem en de sensor kan toevoegen in HA aan de Itho Daalderop?

Ik heb een paar Alpstuga CO2 sensoren van Ikea, nog geen 30 euro en er zit een prima CO2 sensor in. Dat is ongeveer de groothandelsprijs voor alleen de losse sensor....

[ Voor 8% gewijzigd door arjenhiemstra op 07-09-2026 22:30 ]

[TweakM]

Jammer, inderdaad is de fallback tegen bricken ook waardevol. Misschien ooit als er een nieuw ontwerp komt met wat meer geheugen (al zal dat met de huidige prijzen nog wel even duren )

[sciurius]

In RockBox hadden we destijds de truuk om de firmware compressed op te slaan, en een initiële bootloader die dat uncompresste naar het geheugen. Daardoor konden we in het flash memory twee complete versies van de firmware kwijt met het oog op fallback. Omdat de compressiefactor groter dan 2 was, konden we dus ook grotere firmwares flashen.

[karazz]

arjenhiemstra schreef op maandag 7 september 2026 @ 22:26:
[...]

Ik heb een paar Alpstuga CO2 sensoren van Ikea, nog geen 30 euro en er zit een prima CO2 sensor in. Dat is ongeveer de groothandelsprijs voor alleen de losse sensor....

Dat prima dacht ik ook, totdat ik er 2 naast elkaar had staan. Vervolgens kwam ik dit artikel tegen en nou twijfel ik nog meer aan de betrouwbaarheid van de Alpstuga.

Foto uit artikel:

[Lawrentz]

karazz schreef op dinsdag 8 september 2026 @ 09:31:
[...]


Dat prima dacht ik ook, totdat ik er 2 naast elkaar had staan. Vervolgens kwam ik dit artikel tegen en nou twijfel ik nog meer aan de betrouwbaarheid van de Alpstuga.

Foto uit artikel:
[Afbeelding]

De CO2-sensor in de Sensirion SEN63C is gebaseerd op een halfgeleider en niet op een dual beam NDIR.
Een CO2-sensor gebaseerd op een halfgeleider is per definitie onnauwkeurig en onbetrouwbaar.
Dit baseer ik op een bronnenonderzoek dat ik een paar jaar geleden heb mogen uitvoeren.

[RemySoeters]

karazz schreef op dinsdag 8 september 2026 @ 09:31:
[...]


Dat prima dacht ik ook, totdat ik er 2 naast elkaar had staan. Vervolgens kwam ik dit artikel tegen en nou twijfel ik nog meer aan de betrouwbaarheid van de Alpstuga.

Foto uit artikel:
[Afbeelding]

Ik ben blij dat mijn weegschaal minder variatie in meetdata oplevert.

[Bingo the Clown]

arjenhiemstra schreef op maandag 7 september 2026 @ 22:25:
[...]


Toevoegen gaat het niet worden denk ik. Ik begeep van @Bingo the Clown dat de matter firmware te groot is om te passen in de huidige partitie setup. Met de huidige setup is het flash geheugen in twee stukken opgeknipt waarbij in elk stuk de hele firmware staat, hierdoor is het bijna onmogelijk om met een firmware update je device te bricken.
Nu maakt dat voor de non-cve versie iets minder uit want die zou via USB nog te flashen zijn (feitelijk wat @Bingo the Clown ook heeft gedaan met zijn device) maar voor de cve variant is dat niet zo makkelijk.

Toevoegen werd idd te krap. Ik heb nu alles opnieuw gepartitioneerd, ook twee partities voor OTA. En dat past makkelijk (dus alleen de Matter code + geleende code voor het aansturen van de RF via SPI + uitlezen van status via I2C)

[arjenhiemstra]

RemySoeters schreef op dinsdag 8 september 2026 @ 11:54:
[...]


Ik ben blij dat mijn weegschaal minder variatie in meetdata oplevert.

mwah, ik noem dat plausible deniability

[arjenhiemstra]

Lawrentz schreef op dinsdag 8 september 2026 @ 11:16:
[...]

De CO2-sensor in de Sensirion SEN63C is gebaseerd op een halfgeleider en niet op een dual beam NDIR.
Een CO2-sensor gebaseerd op een halfgeleider is per definitie onnauwkeurig en onbetrouwbaar.
Dit baseer ik op een bronnenonderzoek dat ik een paar jaar geleden heb mogen uitvoeren.

Wist ik niet, interessant!

[arjenhiemstra]

Bingo the Clown schreef op dinsdag 8 september 2026 @ 16:29:
[...]

Toevoegen werd idd te krap. Ik heb nu alles opnieuw gepartitioneerd, ook twee partities voor OTA. En dat past makkelijk (dus alleen de Matter code + geleende code voor het aansturen van de RF via SPI + uitlezen van status via I2C)

Nice! Als je dezelfde partitie indeling aangehouden hebt als de ithowifi firmware dat zou switchen tussen beide via OTA kunnen. Dus simpel nieuwe firmware via de web interface van de add-on en ook weer terug (afhankelijk van hoe je het ingebouwd hebt) indien nodig

[arjenhiemstra]

sciurius schreef op dinsdag 8 september 2026 @ 08:41:
In RockBox hadden we destijds de truuk om de firmware compressed op te slaan, en een initiële bootloader die dat uncompresste naar het geheugen. Daardoor konden we in het flash memory twee complete versies van de firmware kwijt met het oog op fallback. Omdat de compressiefactor groter dan 2 was, konden we dus ook grotere firmwares flashen.

Was dat ook met de ESP32?

[sciurius]

EPS32?

Nee, dat was lang voor die tijd. Aanvankelijk proprietary chips, maar later ook ports naar iPod en ARM processors.

Tot mijn verrassing is het project nog steeds levend: Wikipedia: Rockbox.

[Ruimzicht]

Ik dacht een eenvoudige casus te hebben maar mijn kennis schiet helaas tekort. Ik heb een CVE-S PAK (met vochtsensor) en een fysieke remote (RFT Remote AUTO (536-0150)). Met de remote schakel ik de box 's avonds naar "low" en 's morgens vóór het douchen weer naar "auto" - ik vond hem 'snachts te luid.

Omdat ik HA met MQTT draai de addon besteld om de box in HA te zetten en mijn vaste schakeling te automatiseren. Fysieke installatie ging probleemloos, add-on meldde zich via MQTT in HA en de vinkjes die ik in de webinterface aanzet zie ik keurig in HA:



Ik heb de koppeling van de fysieke remote aan de box niet gewijzigd, dus zoals ik het begrijp stuurt die rechtstreeks de box aan en niet de add-on. In de webinterface wel de het virtual remote vinkje aangezet maar ik weet niet of dat wel een goed idee is.

Probleem: de box reageert nu helemaal niet op HA opdrachten; wél op de fysieke remote. Ik heb gezocht in dit topic en de wiki en vind veel vergelijkbare issues maar niet in combinatie met mijn box. Wil graag van alles proberen maar loop vast. Kan iemand mij helpen met de juiste vervolgstap(pen)?

[jjust]

Ik heb al best een oude CVE ECO-fan 2 met een RF ontvanger. Werken mijn afstandsbedieningen ook met deze add-on module? Op de print van de afstandsbedieningen staat HCCP2013 en CP5 94V-01 1 09.

Op de webshop staat een afbeelding van ondersteunde afstandsbedieningen maar daar kan je niet op inzoomen waardoor het niet te lezen is.

[arjenhiemstra]

Ruimzicht schreef op vrijdag 18 september 2026 @ 11:57:
Ik dacht een eenvoudige casus te hebben maar mijn kennis schiet helaas tekort. Ik heb een CVE-S PAK (met vochtsensor) en een fysieke remote (RFT Remote AUTO (536-0150)). Met de remote schakel ik de box 's avonds naar "low" en 's morgens vóór het douchen weer naar "auto" - ik vond hem 'snachts te luid.

Omdat ik HA met MQTT draai de addon besteld om de box in HA te zetten en mijn vaste schakeling te automatiseren. Fysieke installatie ging probleemloos, add-on meldde zich via MQTT in HA en de vinkjes die ik in de webinterface aanzet zie ik keurig in HA:

[Afbeelding]

Ik heb de koppeling van de fysieke remote aan de box niet gewijzigd, dus zoals ik het begrijp stuurt die rechtstreeks de box aan en niet de add-on. In de webinterface wel de het virtual remote vinkje aangezet maar ik weet niet of dat wel een goed idee is.

Probleem: de box reageert nu helemaal niet op HA opdrachten; wél op de fysieke remote. Ik heb gezocht in dit topic en de wiki en vind veel vergelijkbare issues maar niet in combinatie met mijn box. Wil graag van alles proberen maar loop vast. Kan iemand mij helpen met de juiste vervolgstap(pen)?

Ik zou een virtual remote aanmelden bij je itho. Als dat is gelukt (check via de virtual remotes pagina, klik op de blauwe knopjes en kijk of je fan reageert)
Daarna zet je de optie "Force medium/auto mode" aan. Hiermee zorg je in ieder geval dat als je andere remote de van uit de auto stand heeft gehaald dat een commado vanaf de add-on nog steeds werkt.
Daarna:
Als je naar de web interface van de add-on gaat zie je als het goed is een slider, werkt het bedienen van de Itho mbv deze slider?

[arjenhiemstra]

jjust schreef op vrijdag 18 september 2026 @ 12:55:
Ik heb al best een oude CVE ECO-fan 2 met een RF ontvanger. Werken mijn afstandsbedieningen ook met deze add-on module? Op de print van de afstandsbedieningen staat HCCP2013 en CP5 94V-01 1 09.

Op de webshop staat een afbeelding van ondersteunde afstandsbedieningen maar daar kan je niet op inzoomen waardoor het niet te lezen is.

Ik heb de afbeelding vervangen door 1 met hogere resolutie. Geen diee waarom die er niet meer was. Als je nu klikt op de afbeelding opent deze de hoge resolutie variant in een nieuwe tab.

[jjust]

Dank. Het lijkt een voorloper te zijn van de 536-0124. Is er wat te zeggen over de succeskans dat die afstandbediening het doet? Of is het gewoon een kwestie van de gok wagen?

[arjenhiemstra]

jjust schreef op vrijdag 18 september 2026 @ 14:01:
Dank. Het lijkt een voorloper te zijn van de 536-0124. Is er wat te zeggen over de succeskans dat die afstandbediening het doet? Of is het gewoon een kwestie van de gok wagen?

Moeilijk te zeggen, er zijn oudere remotes die werken maar ook die niet werken. Ik heb zelf geen ouder model beschikbaar dus ik weet ook zo niet of er aan de binnenkant van de remote iets onderscheidends te zien is.
Je itho heeft wel de 2x4 pins header op de printplaat?

[jjust]

Ja hij heeft wel die 2x4 pins. Nu zit er een RF-bordje op.



Hieronder een foto van de afstandsbediening en de printplaat.

[arjenhiemstra]

jjust schreef op vrijdag 18 september 2026 @ 16:40:
Ja hij heeft wel die 2x4 pins. Nu zit er een RF-bordje op.

[Afbeelding]

Hieronder een foto van de afstandsbediening en de printplaat.

[Afbeelding]

[Afbeelding]

Ah, ik gok dat de aanduiding RFT op de afstandsbediening een goede hint is dat het wel werkt. De add-on komt dan in de plaats van het RF bordje, de bestaande afstandbediening koppel je dan aan de add-on.

[Died]

Hoi @arjenhiemstra,

Ik probeer de ventilatiestand in Homebridge te synchroniseren via het MQTT-topic itho/rfstatus/Badkamer/31DA, met name het veld FanInfo. De status komt binnen, maar onregelmatig: vaak na ongeveer 30 seconden, soms pas na een minuut of langer.

Mijn configuratie:

• Itho HRU 250-300, hardwareversie 11, Itho-firmwareversie 10.
• Wifi-add-on met CC1101, firmware 3.2.0.
• RF standalone ingeschakeld.
• Itho status update frequency: 15 seconden.
• Remote index 1: RFT CO2, functie Send, bidirectional: true.
• Remote-ID: DF:FB:53, destination-ID: 49:5D:50.
• RF-statusbron 49:5D:50 wordt gemonitord onder de naam Badkamer.

Laag, midden en hoog bedienen via deze RFT CO2-remote werkt. De automatische statusaanvragen worden volgens het systeemlog ook netjes elke 15 seconden uitgevoerd:

code:

20:47:12 I: SYS: sent RF 31DA+31D9 status request via remote idx:1, dest:49,5D,50
20:47:27 I: SYS: sent RF 31DA+31D9 status request via remote idx:1, dest:49,5D,50
20:47:42 I: SYS: sent RF 31DA+31D9 status request via remote idx:1, dest:49,5D,50
20:47:57 I: SYS: sent RF 31DA+31D9 status request via remote idx:1, dest:49,5D,50

De ontvangen 31DA-berichten volgen dat interval echter niet. Bijvoorbeeld om 20:48:13, 20:48:48 en 20:49:25. Ze hebben dit formaat:

code:

H:18 _I P0:-- P1:-- 49,5D,50 --,--,-- 49,5D,50 31DA 1D:00,F0,00,7F,FF,EF,EF,09,B9,07,08,08,A4,07,08,20,00,C8,42,78,FF,00,00,EF,EF,7F,FF,7F,FF (cmd:itho31da)

Ook handmatig Request 31DA status op de Debug-pagina, met remote index 1, geeft een verzendmelding maar geen duidelijk herkenbaar direct antwoord. Nieuwe RF-gegevens verschijnen uiteindelijk wel in zowel /api/v2/rfstatus als MQTT.

Is actieve 31DA/31D9-polling via een geëmuleerde RFT CO2-remote ondersteund op deze HRU 250-300? Kan het zijn dat ik alleen spontane statusuitzendingen ontvang en de gerichte aanvragen niet worden beantwoord? Of ontbreekt er nog een instelling?

Ik kan aanvullende logs of configuratiegegevens delen. Alvast bedankt!

[Dquartz]

Lawrentz schreef op dinsdag 8 september 2026 @ 11:16:
[...]

De CO2-sensor in de Sensirion SEN63C is gebaseerd op een halfgeleider en niet op een dual beam NDIR.
Een CO2-sensor gebaseerd op een halfgeleider is per definitie onnauwkeurig en onbetrouwbaar.
Dit baseer ik op een bronnenonderzoek dat ik een paar jaar geleden heb mogen uitvoeren.

@karazz @RemySoeters @arjenhiemstra Die van mij werken best wel goed. Ik heb gelezen dat ze zichzelf kalibreren aan de hand van schone lucht en je moet minimaal 12 uur wachten in eerste instantie. Dus zolang je overdag ook voldoende ventileert gaat het denk ik wel goed. Zie datasheet:

[Lawrentz]

Dquartz schreef op woensdag 23 september 2026 @ 20:13:
[...]

@karazz @RemySoeters @arjenhiemstra Die van mij werken best wel goed. Ik heb gelezen dat ze zichzelf kalibreren aan de hand van schone lucht en je moet minimaal 12 uur wachten in eerste instantie. Dus zolang je overdag ook voldoende ventileert gaat het denk ik wel goed. Zie datasheet:

[Afbeelding]

Waarop baseer je dat die van jou best wel goed werken?
Ik ben wel benieuwd.

[Dquartz]

Een tijdje geleden heb ik er een Honeywell BW solo CO2 meter naast gehad. Ik zag wel een verschil dat overeen kwam met die 100ppm uit de tabel, voor wat ik er nog van weet gaf de Alpstuga altijd net wat hoger aan, maar pin me er niet op vast.

De honeywell ligt nu alweer een tijdje op mijn werk. Voor nu was mijn reactie dus wat meer gebaseerd op hoe ik zie dat de CO2 oploopt als ik in een ruimte ben met 1, 2 of meer personen en wat ik zie als ik bijvoorbeeld een raam open of dicht heb staan.

Wel interessant om de honeywell er weer eens naast te houden.😉

[Lawrentz]

Dquartz schreef op woensdag 23 september 2026 @ 22:49:
Een tijdje geleden heb ik er een Honeywell BW solo CO2 meter naast gehad. Ik zag wel een verschil dat overeen kwam met die 100ppm uit de tabel, voor wat ik er nog van weet gaf de Alpstuga altijd net wat hoger aan, maar pin me er niet op vast.

De honeywell ligt nu alweer een tijdje op mijn werk. Voor nu was mijn reactie dus wat meer gebaseerd op hoe ik zie dat de CO2 oploopt als ik in een ruimte ben met 1, 2 of meer personen en wat ik zie als ik bijvoorbeeld een raam open of dicht heb staan.

Wel interessant om de honeywell er weer eens naast te houden.😉

Als ik het goed interpreteer dan heeft de Honeywell BW solo CO2 een meetbereik van 0 tot 50.000 ppm met een resolutie van 100 ppm.
Dan betreft dit een CO2 meter bedoeld voor specifieke industriële doeleinden en niet geschikt als referentie voor CO2 meters voor huis, tuin en keukendoeleinden met een veel kleiner meetbereik tot meestal 2.000 ppm en lagere resolutie van meestal 1 ppm.
Maar goed, ik denk dat we teveel off topic gaan.

[ViezeVis]

Ik krijg de laatste tijd ineens willekeurig de foutmelding:
" i2c bus stuck - please power cycle the Itho unit"

Is dit iets van de laatste tijd o.i.d.? Ik draai op firmware 3.2.0.

[arjenhiemstra]

ViezeVis schreef op zaterdag 26 september 2026 @ 17:04:
Ik krijg de laatste tijd ineens willekeurig de foutmelding:
" i2c bus stuck - please power cycle the Itho unit"

Is dit iets van de laatste tijd o.i.d.? Ik draai op firmware 3.2.0.

Heb je misschien iets van i2c logging of debugging aan staan?

[ViezeVis]

arjenhiemstra schreef op zaterdag 26 september 2026 @ 17:07:
[...]


Heb je misschien iets van i2c logging of debugging aan staan?

Ik heb dat een paar weken geleden ook al eens gecheckt maar volgens mij niet. Hoe kan ik dat zien? Ik heb voor de vorm onder 'debug' en dan 'I2C extra debug functionality' op 'Debug off' geklikt. Onder syslog is de log-level info.

[jiquera]

Ik heb de non-cve wifi module net aangesloten maar hij weigert met het wifi netwerk te verbinden tenzij ik het wifi netwerk internet toegang geef... is dat normaal?

Weet iemand hoe er bepaald wordt of de verbinding goed genoeg is? ik verwachtte eigenlijk geen verkeer buiten het lokale netwerk via mqtt

[ Voor 29% gewijzigd door jiquera op 28-09-2026 19:43 ]

[arjenhiemstra]

jiquera schreef op maandag 28 september 2026 @ 19:29:
Ik heb de non-cve wifi module net aangesloten maar hij weigert met het wifi netwerk te verbinden tenzij ik het wifi netwerk internet toegang geef... is dat normaal?

Weet iemand hoe er bepaald wordt of de verbinding goed genoeg is? ik verwachtte eigenlijk geen verkeer buiten het lokale netwerk via mqtt

Het enige buiten eigen netwerk verkeer wat nu in de firmware zit is een check bij GitHub voor een versie check. Ik zal bij een volgende versie dit optioneel maken.
Voor een verbinding met je wifi netwerk is sowieso geen internet verbinding nodig.

[jiquera]

hm raar... ik block al het verkeer buiten mijn lokale 10.0.0.0\8 net en zonder die blokkade werkt t prima. Ik zie dat een NTP server ingesteld kan worden in de settings... wordt dat misschien nog gebruikt tijdens de verbinding?

Found it, mijn block was iets te rigoureus en blockte ook DHCP broadcast packets, geen idee waarom mijn laptop en telefoon er geen moeite mee hadden maar t werkt iig weer

[ Voor 28% gewijzigd door jiquera op 28-09-2026 21:31 ]

[DonB.]

Ik heb een wat oudere Itho CVE die ik graag via Homey Pro wil aansturen.

Na het openen van de unit blijkt deze voorzien van een E.RF-I module, onderdeelnummer 11003170. De hoofdprint heeft 9 contacten op één rij en dus niet de 2×4-pins aansluiting die nodig. De IthoWiFi zou dus niet elektrisch/I²C met de CVE verbonden worden, maar als extra RF-afstandsbediening functioneren. Vervolgens wil ik hem via de REST API vanuit Homey Pro bedienen.

Heeft iemand deze combinatie werkend met deze oudere CVE/E.RF-I 11003170?

Concreet zou ik graag willen weten of:

• de non-CVE + CC1101 als RF-standalone met deze E.RF-I kan pairen;
• laag, midden, hoog en timer/boost via RF werken;
• de bestaande originele RFT-afstandsbediening daarnaast gewoon bruikbaar blijft.

Ik heb foto's van zowel de hoofdprint als de E.RF-I-print beschikbaar.

Alvast bedankt! is voor de normale IthoWiFi CVE add-on.

De CVE wordt momenteel probleemloos bediend met de originele draadloze Itho RFT-afstandsbediening.

Mijn idee is daarom om een IthoWiFi non-CVE module + CC1101 standalone te gebruiken en de CVE volledig via RF aan te sturen

[arjenhiemstra]

DonB. schreef op vrijdag 2 oktober 2026 @ 11:32:
Ik heb een wat oudere Itho CVE die ik graag via Homey Pro wil aansturen.

Na het openen van de unit blijkt deze voorzien van een E.RF-I module, onderdeelnummer 11003170. De hoofdprint heeft 9 contacten op één rij en dus niet de 2×4-pins aansluiting die nodig. De IthoWiFi zou dus niet elektrisch/I²C met de CVE verbonden worden, maar als extra RF-afstandsbediening functioneren. Vervolgens wil ik hem via de REST API vanuit Homey Pro bedienen.

Heeft iemand deze combinatie werkend met deze oudere CVE/E.RF-I 11003170?

Concreet zou ik graag willen weten of:

• de non-CVE + CC1101 als RF-standalone met deze E.RF-I kan pairen;
• laag, midden, hoog en timer/boost via RF werken;
• de bestaande originele RFT-afstandsbediening daarnaast gewoon bruikbaar blijft.

Ik heb foto's van zowel de hoofdprint als de E.RF-I-print beschikbaar.

Alvast bedankt! is voor de normale IthoWiFi CVE add-on.

De CVE wordt momenteel probleemloos bediend met de originele draadloze Itho RFT-afstandsbediening.

Mijn idee is daarom om een IthoWiFi non-CVE module + CC1101 standalone te gebruiken en de CVE volledig via RF aan te sturen

Dat gaat helaas niet werken omdat de 9-pin rf variant een ander rf protocol gebruikt

[Ijzerenhein]

Ik heb een vraag,

ik heb een non-CVE add-on gekoppeld aan mijn HRU 350, omdat ik geen programmeer ervaring heb gebruik ik een Homey Pro (2026) met de app Itho Daalderop van MonkeySoft. Ik las in de installatie pdf dat ik de afstandsbediening en sensoren kan koppelen aan de add-on of aan de Itho kan laten. Zijn er voordelen aan het koppelen op de add-on zoals extra informatie of instellingen?

Heeft iemand info?

Groeten Ruud

[Primal]

Hoi @arjenhiemstra , ik heb het topic sinds de toevoeging van de CO2 sensoren doorgenomen, maar misschien heb ik toch ergens overheen gekeken.

• Ik heb een Itho HRU 350 ECO (firmware hw version: 10, fw version: 4)
• Wifi add-on met CC1101 RF ingeschakeld (firmware 3.2.0)
• Fysieke CO2 sensoren van Itho zelf
• Home Assistant OS 18.3, Core 2026.10.2)

Ik gebruik de add-on al sinds versie 2.8 zonder problemen, toen nog wel zonder de CO2 integratie dus. Nu wil ik de CO2 aansturing via HA laten lopen en niet door Itho zelf. Dus ik heb alle gepaired sensoren van de HRU losgekoppeld, maar nog niet aan de add-on gekoppeld. Vervolgens heb ik de add-on met de HRU gejoind als RFT-AUTO, want joinen als RFT-CO2 werkt niet. Als ik join als RFT-AUTO reageert ie op de controls om de fanspeed aan te passen, behalve de control 'request fanspeed'. Wanneer ik op 'auto' klik komt ie niet in de auto modus terecht, maar de medium modus. Als ik het model van de virtual remote verander naar RFT-CO2 werken de controls niet (zowel HA als add-on page), ook niet na een herstart.

Ik zit geloof ik een beetje vast en moet eerlijk zeggen dat ik op dit moment ook even niet meer weet wat ik aan het doen ben. Heb je wat tips?

[pollekeb]

Beste Tweakers,

Ik wil mijn oude Daalderop Itho evo 266 vervangen voor een nieuwe Itho Daalderop Optima Inside MV-Unit 468 RV- en CO2-Sensor Inside.Ook wil deze in mijn Homey pro 2026 intregeren en heb ik een Itho CVE WiFi add-on nodig van NRG watch.

Nu is mijn vraag is het slim om de uitgebreide optima inside te kopen? Ik heb 2 Ikea ALPSTUGALuchtkwaliteitsensors.Of mischien gewoon de afzuiging zijn werk laten doen?

Of kan ik wanneer de Ikea sensor toch slechte luchtkwaliteit meet deze overrulen?


Paul

[Lawrentz]

pollekeb schreef op zondag 18 oktober 2026 @ 19:27:
Beste Tweakers,

Ik wil mijn oude Daalderop Itho evo 266 vervangen voor een nieuwe Itho Daalderop Optima Inside MV-Unit 468 RV- en CO2-Sensor Inside.Ook wil deze in mijn Homey pro 2026 intregeren en heb ik een Itho CVE WiFi add-on nodig van NRG watch.

Nu is mijn vraag is het slim om de uitgebreide optima inside te kopen? Ik heb 2 Ikea ALPSTUGALuchtkwaliteitsensors.Of mischien gewoon de afzuiging zijn werk laten doen?

Of kan ik wanneer de Ikea sensor toch slechte luchtkwaliteit meet deze overrulen?


Paul

Neem gewoon de Optima Inside.
De Ikea Alpsuga is rommel voor CO2-metingen.
Ik ga niet opnieuw uitleggen waarom, want daar is al genoeg over geschreven.

[arjenhiemstra]

pollekeb schreef op zondag 18 oktober 2026 @ 19:27:
Beste Tweakers,

Ik wil mijn oude Daalderop Itho evo 266 vervangen voor een nieuwe Itho Daalderop Optima Inside MV-Unit 468 RV- en CO2-Sensor Inside.Ook wil deze in mijn Homey pro 2026 intregeren en heb ik een Itho CVE WiFi add-on nodig van NRG watch.

Nu is mijn vraag is het slim om de uitgebreide optima inside te kopen? Ik heb 2 Ikea ALPSTUGALuchtkwaliteitsensors.Of mischien gewoon de afzuiging zijn werk laten doen?

Of kan ik wanneer de Ikea sensor toch slechte luchtkwaliteit meet deze overrulen?


Paul

Ik zou zeggen dat het sterk situatie afhankelijk is.
Als je 1 punt hebt waarop de Itho afzuigt dan is de CO2 meting heel betrouwbaar, meestal gaat het om menglucht en is de meting erg onbetrouwbaar.
De sensor van alpstuga heeft duidelijke beperkingen maar gezien bovenstaand is de meting vanuit de Itho niet per definitie beter.
Voor het bedrag dat je extra betaald voor de Optima inside heb je hele goede kwaliteit andere CO2 sensoren waarbij je wel controle hebt over het effect op je ventilatie en niet beperkt wordt door de settings in de Itho firmware. Als je een goede Itho sensor wilt, de RFT-CO2 zou dan mijn keuze zijn.
Maargoed, hierbij preek ik deels voor eigen parochie natuurlijk.

[arjenhiemstra]

Primal schreef op zondag 18 oktober 2026 @ 12:44:
Hoi @arjenhiemstra , ik heb het topic sinds de toevoeging van de CO2 sensoren doorgenomen, maar misschien heb ik toch ergens overheen gekeken.

• Ik heb een Itho HRU 350 ECO (firmware hw version: 10, fw version: 4)
• Wifi add-on met CC1101 RF ingeschakeld (firmware 3.2.0)
• Fysieke CO2 sensoren van Itho zelf
• Home Assistant OS 18.3, Core 2026.10.2)

Ik gebruik de add-on al sinds versie 2.8 zonder problemen, toen nog wel zonder de CO2 integratie dus. Nu wil ik de CO2 aansturing via HA laten lopen en niet door Itho zelf. Dus ik heb alle gepaired sensoren van de HRU losgekoppeld, maar nog niet aan de add-on gekoppeld. Vervolgens heb ik de add-on met de HRU gejoind als RFT-AUTO, want joinen als RFT-CO2 werkt niet. Als ik join als RFT-AUTO reageert ie op de controls om de fanspeed aan te passen, behalve de control 'request fanspeed'. Wanneer ik op 'auto' klik komt ie niet in de auto modus terecht, maar de medium modus. Als ik het model van de virtual remote verander naar RFT-CO2 werken de controls niet (zowel HA als add-on page), ook niet na een herstart.

Ik zit geloof ik een beetje vast en moet eerlijk zeggen dat ik op dit moment ook even niet meer weet wat ik aan het doen ben. Heb je wat tips?

Probeer eventueel de laatste beta, er zitten nogal wat verbeteringen rondom de RFT-CO2 emulate in de laatste versies.

Wat sowieso nooit zal werken is een remote joinen en daarna het type veranderen (bijv, van RFT-Auto naar RFT-CO2). De join moet slagen voor het ingestelde type remote, anders werkt het niet of niet betrouwbaar, zeker niet met een bi-directionele remote zoals de RFT-CO2.
Het zou goed samen moeten werken met de HRU 350. Wellicht eens een heel ander ID instellen voordat je op join klikt?

Wat betreft de "behalve de control 'request fanspeed'"; dat is info direct uit de Itho firmware, ik weet helaas niet wanneer deze wel of niet veranderd qua waarde.

[pollekeb]

arjenhiemstra schreef op zondag 18 oktober 2026 @ 21:53:
[...]


Ik zou zeggen dat het sterk situatie afhankelijk is.
Als je 1 punt hebt waarop de Itho afzuigt dan is de CO2 meting heel betrouwbaar, meestal gaat het om menglucht en is de meting erg onbetrouwbaar.
De sensor van alpstuga heeft duidelijke beperkingen maar gezien bovenstaand is de meting vanuit de Itho niet per definitie beter.
Voor het bedrag dat je extra betaald voor de Optima inside heb je hele goede kwaliteit andere CO2 sensoren waarbij je wel controle hebt over het effect op je ventilatie en niet beperkt wordt door de settings in de Itho firmware. Als je een goede Itho sensor wilt, de RFT-CO2 zou dan mijn keuze zijn.
Maargoed, hierbij preek ik deels voor eigen parochie natuurlijk.

Welke afzuigunit zouden jullie adviseren wanneer ik toch de Itho CVE WiFi add-on ga inbouwen en meerdere co2 sensoren ga gebruiken.Ik merk nl dat de co2 waarden in mijn huiskamer best snel richting de 1000 gaat. Ik geloofde dit eerst niet maar beide naast elkaar geven dezelfde waarden aan. na goed ventileren zak deze dan weer rond de 450.

[arjenhiemstra]

pollekeb schreef op zondag 18 oktober 2026 @ 22:17:
[...]

Welke afzuigunit zouden jullie adviseren wanneer ik toch de Itho CVE WiFi add-on ga inbouwen en meerdere co2 sensoren ga gebruiken.Ik merk nl dat de co2 waarden in mijn huiskamer best snel richting de 1000 gaat. Ik geloofde dit eerst niet maar beide naast elkaar geven dezelfde waarden aan. na goed ventileren zak deze dan weer rond de 450.

Er zijn eigenlijk maar 4 opties qua CVE;
standaard / high performance
optima inside / niet optima inside

Of het verschil tussen standaard / high performance de print en motor en/of firmware is weet ik niet. Ik weet wel dat high performance of niet een setting is in de firmware maar ik heb de twee varianten nog niet kunnen vergelijken.
Verder zijn alle CVE-S uitvoeringen gelijk op de aanwezigheid van een CO2 sensor na dus

Ik ben geen expert op het vlak van CO2 sensoren maar ik lees goede verhalen over de metingen van de Switchbot Meter Pro die te verbinden is met wifi en matter ondersteund.

[Primal]

arjenhiemstra schreef op zondag 18 oktober 2026 @ 22:00:
[...]


Probeer eventueel de laatste beta, er zitten nogal wat verbeteringen rondom de RFT-CO2 emulate in de laatste versies.

Wat sowieso nooit zal werken is een remote joinen en daarna het type veranderen (bijv, van RFT-Auto naar RFT-CO2). De join moet slagen voor het ingestelde type remote, anders werkt het niet of niet betrouwbaar, zeker niet met een bi-directionele remote zoals de RFT-CO2.
Het zou goed samen moeten werken met de HRU 350. Wellicht eens een heel ander ID instellen voordat je op join klikt?

Wat betreft de "behalve de control 'request fanspeed'"; dat is info direct uit de Itho firmware, ik weet helaas niet wanneer deze wel of niet veranderd qua waarde.

Ik heb andere ID's geprobeerd, de firmware nog eens geflashed (3.2.0) en een factory reset, maar dat heeft het probleem niet opgelost. De enige RFT die ik als virtuele remote kan joinen is RFT-AUTO. Wanneer ik een fysieke CO2 sensor join met de HRU lukt dat direct, dus er lijkt iets niet goed te gaan op de add-on. De logs helpen me ook niet direct verder, maar dan kan ook goed aan gebrek aan kennis liggen. Ik ga morgen de laatste beta eens flashen en kijken of het daarmee wel lukt.

[arjenhiemstra]

Primal schreef op maandag 19 oktober 2026 @ 21:12:
[...]

Ik heb andere ID's geprobeerd, de firmware nog eens geflashed (3.2.0) en een factory reset, maar dat heeft het probleem niet opgelost. De enige RFT die ik als virtuele remote kan joinen is RFT-AUTO. Wanneer ik een fysieke CO2 sensor join met de HRU lukt dat direct, dus er lijkt iets niet goed te gaan op de add-on. De logs helpen me ook niet direct verder, maar dan kan ook goed aan gebrek aan kennis liggen. Ik ga morgen de laatste beta eens flashen en kijken of het daarmee wel lukt.

Sorry, ik heb over virtual remote heen gelezen. De RFT CO2 is een bidirectionele remote. Dat werkt vooralsnog enkel via RF. Onder menu RF devices kun je een remote configureren en joinen aan je HRU.
Excuus voor de verwarring!

[Primal]

arjenhiemstra schreef op maandag 19 oktober 2026 @ 21:20:
[...]


Sorry, ik heb over virtual remote heen gelezen. De RFT CO2 is een bidirectionele remote. Dat werkt vooralsnog enkel via RF. Onder menu RF devices kun je een remote configureren en joinen aan je HRU.
Excuus voor de verwarring!

Aah ok! Dan werkt het dus wel zoals verwacht. Fijn, dan kan ik weer verder. Thanks!

[Primal]

.

[ Voor 109% gewijzigd door Primal op 20-10-2026 18:51 ]

[Casio fx-100]

Ik zoek een nieuwe ventilatiebox en er gaat een wereld voor me open wat er allemaal mogelijk is.

Heeft iemand ervaring met een sensor (tvoc/voc) op wc die reageerd op nare geurtjes?
Bijvoorbeeld TVOC Air Quality Monitor of Eve Room.

[wouterhil1]

Sinds enkele weken ben ik een tevreden gebruiker van de Itho Wifi add-on. Ik gebruik deze i.c.m. mijn Itho HRU300 DZ met Co2-sensoren en zonekleppen. Helaas loop ik er net als anderen hier tegenaan dat de Co2- sturing van Itho te wensen overlaat. Pas bij een PPM van 1200 gaat de WTW optoeren waarbij gerust hogere PPM-waardes worden gezien. Het aanpassen van de PPMGoodQuality naar 600 en PPMPoorQuality naar 800 maakt hierbij geen merkbaar verschil.

Omdat ik de Co2-waardes graag lager houdt (rond 800ppm) heb ik nu zelf Co2-sturing ingesteld via Home Assistant waarbij ik per zone wissel tussen Low, Medium en High bij verschillende PPM-waardes. Ik lees de fysieke RFT-Co2-sensoren via Monitoring Only uit en gebruik deze PPM-waarde om via twee virtuele RFT-Co2-afstandsbedieningen vanaf de add-on de WTW aan te sturen. De fysieke RFT-Co2 zijn ook nog gekoppeld aan de WTW (omnidirectioneel).
Dit schakelen via Home Assistant werkt op zich wel maar heeft veel schakelen in toerental tot gevolg wat denk ik niet heel energiezuinig is en ook niet zozeer goed voor de WTW. Ter illustratie. Om de PPM op 800 te houden draait de WTW 2 minuten op Medium-->PPM zakt onder 800, vervolgens 2 minuten op Low (PPM stijgt weer boven 800) enzovoorts. Dat moet beter kunnen. Eigenlijk zoals de Itho het zelf regelt op Co2-waarde maar dan met lagere PPM-grenzen.

Is er iemand die het Duozone-systeem volledig naar wens heeft draaien, waarbij gestuurd wordt op een lage PPM-waarde en die mij zou kunnen uitleggen hoe hij dit geregeld heeft?

Tot slot doorgrond ik de werking van de Duozone-kleppen nog niet. Ik heb veel verschillende instellingen geprobeerd wordt wat betreft M3/h instellingen in de HMI voor de Dag/Nacht/Return met daarbij verschillende instellingen voor het toerental, maar ik blijf tegen wat onbegrijpelijke dingen aanlopen. Zoals:

-Beide zones op Low: Kleppen naar beide zones staan ongeveer 40% open.
-Zone Slaap Medium en Zone Woon Low. Klep naar Slaap gaat verder open, toerental stijgt iets en klep naar Woon gaat vrijwel dicht. Dit geldt andersom ook (Slaap Low en Wonen Medium) en geldt eigenlijk voor alle instellingen dat de zone die een hogere stand heeft, de klep verder open heeft staan dan de zone met de lagere stand. Dat is prima.
-Beide zones op Medium of High: Zelfde gedrag als bij Low. Kleppen naar beide zones staan ongeveer 40% open, dus evenredig verdeeld. WTW draait meer toeren, tot aan maximum toerental (1900RPM) om het gewenste debiet te leveren.
Wat mij verbaasd: Bij gelijke ventilatievraag in beide zones zou je verwachten (zeker op medium en high) dat de kleppen naar beide zones geheel openstaan. Het levert toch flink weerstand op als je 300M3/h door het kanalenstelsel moet blazen, maar eerst tegen twee kleppen aan blaast die maar 40% open staan.

Is er iemand die het gedrag van de kleppen begrijpt en dit helemaal naar wens heeft draaien?

[ Voor 5% gewijzigd door wouterhil1 op 26-10-2026 14:20 ]

[Primal]

wouterhil1 schreef op maandag 26 oktober 2026 @ 14:08:
Sinds enkele weken ben ik een tevreden gebruiker van de Itho Wifi add-on. Ik gebruik deze i.c.m. mijn Itho HRU300 DZ met Co2-sensoren en zonekleppen. Helaas loop ik er net als anderen hier tegenaan dat de Co2- sturing van Itho te wensen overlaat. Pas bij een PPM van 1200 gaat de WTW optoeren waarbij gerust hogere PPM-waardes worden gezien. Het aanpassen van de PPMGoodQuality naar 600 en PPMPoorQuality naar 800 maakt hierbij geen merkbaar verschil.

Omdat ik de Co2-waardes graag lager houdt (rond 800ppm) heb ik nu zelf Co2-sturing ingesteld via Home Assistant waarbij ik per zone wissel tussen Low, Medium en High bij verschillende PPM-waardes. Ik lees de fysieke RFT-Co2-sensoren via Monitoring Only uit en gebruik deze PPM-waarde om via twee virtuele RFT-Co2-afstandsbedieningen vanaf de add-on de WTW aan te sturen. De fysieke RFT-Co2 zijn ook nog gekoppeld aan de WTW (omnidirectioneel).
Dit schakelen via Home Assistant werkt op zich wel maar heeft veel schakelen in toerental tot gevolg wat denk ik niet heel energiezuinig is en ook niet zozeer goed voor de WTW. Ter illustratie. Om de PPM op 800 te houden draait de WTW 2 minuten op Medium-->PPM zakt onder 800, vervolgens 2 minuten op Low (PPM stijgt weer boven 800) enzovoorts. Dat moet beter kunnen. Eigenlijk zoals de Itho het zelf regelt op Co2-waarde maar dan met lagere PPM-grenzen.

Is er iemand die het Duozone-systeem volledig naar wens heeft draaien, waarbij gestuurd wordt op een lage PPM-waarde en die mij zou kunnen uitleggen hoe hij dit geregeld heeft?

Tot slot doorgrond ik de werking van de Duozone-kleppen nog niet. Ik heb veel verschillende instellingen geprobeerd wordt wat betreft M3/h instellingen in de HMI voor de Dag/Nacht/Return met daarbij verschillende instellingen voor het toerental, maar ik blijf tegen wat onbegrijpelijke dingen aanlopen. Zoals:

-Beide zones op Low: Kleppen naar beide zones staan ongeveer 40% open.
-Zone Slaap Medium en Zone Woon Low. Klep naar Slaap gaat verder open, toerental stijgt iets en klep naar Woon gaat vrijwel dicht. Dit geldt andersom ook (Slaap Low en Wonen Medium) en geldt eigenlijk voor alle instellingen dat de zone die een hogere stand heeft, de klep verder open heeft staan dan de zone met de lagere stand. Dat is prima.
-Beide zones op Medium of High: Zelfde gedrag als bij Low. Kleppen naar beide zones staan ongeveer 40% open, dus evenredig verdeeld. WTW draait meer toeren, tot aan maximum toerental (1900RPM) om het gewenste debiet te leveren.
Wat mij verbaasd: Bij gelijke ventilatievraag in beide zones zou je verwachten (zeker op medium en high) dat de kleppen naar beide zones geheel openstaan. Het levert toch flink weerstand op als je 300M3/h door het kanalenstelsel moet blazen, maar eerst tegen twee kleppen aan blaast die maar 40% open staan.

Is er iemand die het gedrag van de kleppen begrijpt en dit helemaal naar wens heeft draaien?

Ik heb een HRU 350 ECO en gebruik de CO2 sensoren van Itho (hoewel niet tevreden over de stabiliteit). Voor mij was de gebrekkige aansturing op co2 vlak de reden om met de Wifi add-on aan de slag te gaan. Ik heb ook een luchtvochtigheidssensor in de badkamer. Ik heb alle sensoren losgekoppeld van de HRU en rechtstreeks gepaird met de add-on. Via ChatGPT heb ik een automation voor home assistant laten creëren. Deze past het toerental van de HRU traploos aan op basis van:

1. Co2
2. Luchtvochtigheid
3. Automatische (nacht) stand
4. Handmatige inzet (low, med, high, timers)

Ben er zeer tevreden mee. Het script is te configureren met drempelwaarden, hoe snel de opbouw/afbouw van toeren moet gebeuren etc. Het script werkt ook met prioriteiten, in respectievelijke volgorde: handmatige inzet, luchtvochtigheid, CO2. De laatste 2 werken in de auto (nacht) stand. Mocht je interesse hebben, dan kan ik het delen.

[karazz]

Primal schreef op maandag 26 oktober 2026 @ 14:30:
[...]

Ik heb een HRU 350 ECO en gebruik de CO2 sensoren van Itho (hoewel niet tevreden over de stabiliteit). Voor mij was de gebrekkige aansturing op co2 vlak de reden om met de Wifi add-on aan de slag te gaan. Ik heb ook een luchtvochtigheidssensor in de badkamer. Ik heb alle sensoren losgekoppeld van de HRU en rechtstreeks gepaird met de add-on. Via ChatGPT heb ik een automation voor home assistant laten creëren. Deze past het toerental van de HRU traploos aan op basis van:

1. Co2
2. Luchtvochtigheid
3. Automatische (nacht) stand
4. Handmatige inzet (low, med, high, timers)

Ben er zeer tevreden mee. Het script is te configureren met drempelwaarden, hoe snel de opbouw/afbouw van toeren moet gebeuren etc. Mocht je interesse hebben, dan kan ik het delen.

Ik heb precies zo'n project op mijn lijstje staan (maar dan ikea sensoren ipv itho sensoren), de wifi module ligt al klaar. Ik zou dan ook graag je script willen bekijken!

[wouterhil1]

Primal schreef op maandag 26 oktober 2026 @ 14:30:
[...]

Ik heb een HRU 350 ECO en gebruik de CO2 sensoren van Itho (hoewel niet tevreden over de stabiliteit). Voor mij was de gebrekkige aansturing op co2 vlak de reden om met de Wifi add-on aan de slag te gaan. Ik heb ook een luchtvochtigheidssensor in de badkamer. Ik heb alle sensoren losgekoppeld van de HRU en rechtstreeks gepaird met de add-on. Via ChatGPT heb ik een automation voor home assistant laten creëren. Deze past het toerental van de HRU traploos aan op basis van:

1. Co2
2. Luchtvochtigheid
3. Automatische (nacht) stand
4. Handmatige inzet (low, med, high, timers)

Ben er zeer tevreden mee. Het script is te configureren met drempelwaarden, hoe snel de opbouw/afbouw van toeren moet gebeuren etc. Het script werkt ook met prioriteiten, in respectievelijke volgorde: handmatige inzet, luchtvochtigheid, CO2. De laatste 2 werken in de auto (nacht) stand. Mocht je interesse hebben, dan kan ik het delen.

Dank voor je reactie. Ik zou het script graag ontvangen. Ik zal het dan nog moeten aanpassen om te laten werken met zonering, maar het idee kan ik goed gebruiken als input. De HRU300 werkt niet met Virtual Remotes. Gebruik jij die nu wel? Ik kan dus alleen de specifieke demand sliders gebruiken van de virtuele Rft-Co2.


Meer reacties (specifiek HRU300 met Duozone) blijven welkom 😊

[Primal]

wouterhil1 schreef op maandag 26 oktober 2026 @ 19:08:
[...]

Dank voor je reactie. Ik zou het script graag ontvangen. Ik zal het dan nog moeten aanpassen om te laten werken met zonering, maar het idee kan ik goed gebruiken als input. De HRU300 werkt niet met Virtual Remotes. Gebruik jij die nu wel? Ik kan dus alleen de specifieke demand sliders gebruiken van de virtuele Rft-Co2.


Meer reacties (specifiek HRU300 met Duozone) blijven welkom 😊

Ik heb een RFT CO2 als RF remote geconfigureerd in de add-on. Deze ontvangt de commando's vanuit de automation, vertaalt ze (neem ik aan) en stuurt de HRU aan. Ik heb overigens een HRU 350 zonder zonering.

[Primal]

@wouterhil1 @karazz (of anderen) hierbij de automation om Home Assistant een Itho WTW vraag-gestuurd (CO2/luchtvochtigheid) te laten beheren. Uitvoerig te customizen m.b.v. uiteenlopende parameters en daarmee presteert het significant beter dan de, in mijn ogen, brakke aansturing van Itho (vooral op gebied van CO2).

Full disclaimer:

• De automation is volledig gegenereerd via de 'Work' mode in ChatGPT
  • Ik heb géén code reviews gedaan
  • Ik heb geen idee of het efficiënter/beter kan. Voel je vrij het script naar hartenlust aan te passen
• De automation draait bij mij nu precies een week volledig probleemloos en ben er superblij mee!! Er gaat wel wat tijd zitten in het beter afstellen van de parameters, dat zul je door de tijd verder moeten optimaliseren
• De automation bied ik aan 'as is', dus zónder support of verantwoording, omdat het nooit mijn doel was er een gedeeld project van te maken

Automation: https://github.com/omegasupreme3/itho_daalderop_humidity_co2_auto_control/tree/main .

[karazz]

Primal schreef op maandag 26 oktober 2026 @ 22:53:
@wouterhil1 @karazz (of anderen) hierbij de automation om Home Assistant een Itho WTW vraag-gestuurd (CO2/luchtvochtigheid) te laten beheren. Uitvoerig te customizen m.b.v. uiteenlopende parameters en daarmee presteert het significant beter dan de, in mijn ogen, brakke aansturing van Itho (vooral op gebied van CO2).

Full disclaimer:

• De automation is volledig gegenereerd via de 'Work' mode in ChatGPT
  • Ik heb géén code reviews gedaan
  • Ik heb geen idee of het efficiënter/beter kan. Voel je vrij het script naar hartenlust aan te passen
• De automation draait bij mij nu precies een week volledig probleemloos en ben er superblij mee!! Er gaat wel wat tijd zitten in het beter afstellen van de parameters, dat zul je door de tijd verder moeten optimaliseren
• De automation bied ik aan 'as is', dus zónder support of verantwoording, omdat het nooit mijn doel was er een gedeeld project van te maken

Automation: https://github.com/omegasupreme3/itho_daalderop_humidity_co2_auto_control/tree/main .

Top! Dankjewel. Dit kan mooi dienen als basis voor mijn project, het scheelt dat ik niet op 0 hoef te beginnen.

(en ik zal je niet lastig vallen met vragen over de inhoud van het script )

[Corn]

Zojuist board geinstalleerd, na fantastisch snelle levering! Besturing via Home Assistant en MQTT werkt perfect, ook afstandsbediening pairde vlot. Ik loop echter tegen het volgende aan: Met de add-on print geinstalleerd produceert de fan een soort van 'ratelend' geluid. Dit geluid is met name heel duidelijk met lage toerentallen. Als ik de print loshaal is het geluid nog steeds wel ergens aanwezig, maar véél minder duidelijk.

Als de fan niet tijdelijk niet powered is, bijvoorbeeld bij het wisselen van hoog naar laag toerental, is het geluid tijdelijk even weg. Daarna komt het weer keihard terug.

Iemand ideeen? Slecht driver-board?

In het filmpje hoor je de fan downspoolen van 50%, en nadat ie op z'n target RPM is begint het geratel. Zodra ik het board lostrek is het aanzienlijk minder.

(Ja, ik snap dat het een suboptimale strategie is om het bord onder spanning los te trekken, maar dit even om duidelijk te maken dat het echt significant scheelt in het lawaai)

Verdere troubleshooting:
- 400v/63µ elco vervangen (geen effect)
- Extra 330µF elco op de 16v-rail (geen effect)
- Extra elco's bij de 78M05 die de ATMega/ATiny combo op het driver board powered (geen effect)
- Extra bypass caps bij de FET-drivers geplaatst (geen effect)
- Het geluid is ook een paar seconden minder duidelijk aanwezig als de add-on een soft-reboot krijgt

Op dit moment is de enige theorie die bij mij blijft staan dat er op een of andere manier jitter ontstaat op de motordriver, waardoor de herrie ontstaat, maar hoe is mij een raadsel...

[ Voor 24% gewijzigd door Corn op 27-10-2026 17:14 ]

[arjenhiemstra]

Corn schreef op dinsdag 27 oktober 2026 @ 16:13:
Zojuist board geinstalleerd, na fantastisch snelle levering! Besturing via Home Assistant en MQTT werkt perfect, ook afstandsbediening pairde vlot. Ik loop echter tegen het volgende aan: Met de add-on print geinstalleerd produceert de fan een soort van 'ratelend' geluid. Dit geluid is met name heel duidelijk met lage toerentallen. Als ik de print loshaal is het geluid nog steeds wel ergens aanwezig, maar véél minder duidelijk.

Als de fan niet tijdelijk niet powered is, bijvoorbeeld bij het wisselen van hoog naar laag toerental, is het geluid tijdelijk even weg. Daarna komt het weer keihard terug.

Iemand ideeen? Slecht driver-board?

In het filmpje hoor je de fan downspoolen van 50%, en nadat ie op z'n target RPM is begint het geratel. Zodra ik het board lostrek is het aanzienlijk minder.

[YouTube: Itho CVE]
(Ja, ik snap dat het een suboptimale strategie is om het bord onder spanning los te trekken, maar dit even om duidelijk te maken dat het echt significant scheelt in het lawaai)

Verdere troubleshooting:
- 400v/63µ elco vervangen (geen effect)
- Extra 330µF elco op de 16v-rail (geen effect)
- Extra elco's bij de 78M05 die de ATMega/ATiny combo op het driver board powered (geen effect)
- Extra bypass caps bij de FET-drivers geplaatst (geen effect)
- Het geluid is ook een paar seconden minder duidelijk aanwezig als de add-on een soft-reboot krijgt

Op dit moment is de enige theorie die bij mij blijft staan dat er op een of andere manier jitter ontstaat op de motordriver, waardoor de herrie ontstaat, maar hoe is mij een raadsel...

Bruute test - do never try this at home - maar wel effectief...

Ik heb dezelfde CVE versie hier staan en herken het soort geluid wel maar ik moet echt heel goed luisteren om het verschil tussen met en zonder add-on te horen.
Ik dacht eerlijk gezegd dat het simpelweg met een ander toerental te maken had maar deze test toont denk ik wel effectief aan dat er een wisselwerking is tussen add-on en Itho motor driver.

Enige wat ik kan bedenken dat er een oscillatie onstaat tussen de driver frequentie van de dc-dc converter op de add-on en misschien een hele specifieke/toevallige samenkomst van onderdelen in het motor driver deel van de Itho? Ik kan eens kijken of ik een dc-dc converter kan vinden met een andere frequentie, dat zou dan verschil moeten maken als de theorie klopt.

[arjenhiemstra]

Corn schreef op dinsdag 27 oktober 2026 @ 16:13:
Zojuist board geinstalleerd, na fantastisch snelle levering! Besturing via Home Assistant en MQTT werkt perfect, ook afstandsbediening pairde vlot. Ik loop echter tegen het volgende aan: Met de add-on print geinstalleerd produceert de fan een soort van 'ratelend' geluid. Dit geluid is met name heel duidelijk met lage toerentallen. Als ik de print loshaal is het geluid nog steeds wel ergens aanwezig, maar véél minder duidelijk.

Als de fan niet tijdelijk niet powered is, bijvoorbeeld bij het wisselen van hoog naar laag toerental, is het geluid tijdelijk even weg. Daarna komt het weer keihard terug.

Iemand ideeen? Slecht driver-board?

In het filmpje hoor je de fan downspoolen van 50%, en nadat ie op z'n target RPM is begint het geratel. Zodra ik het board lostrek is het aanzienlijk minder.

[YouTube: Itho CVE]
(Ja, ik snap dat het een suboptimale strategie is om het bord onder spanning los te trekken, maar dit even om duidelijk te maken dat het echt significant scheelt in het lawaai)

Verdere troubleshooting:
- 400v/63µ elco vervangen (geen effect)
- Extra 330µF elco op de 16v-rail (geen effect)
- Extra elco's bij de 78M05 die de ATMega/ATiny combo op het driver board powered (geen effect)
- Extra bypass caps bij de FET-drivers geplaatst (geen effect)
- Het geluid is ook een paar seconden minder duidelijk aanwezig als de add-on een soft-reboot krijgt

Op dit moment is de enige theorie die bij mij blijft staan dat er op een of andere manier jitter ontstaat op de motordriver, waardoor de herrie ontstaat, maar hoe is mij een raadsel...

Ik heb 2 dc-dc converter varianten besteld die een swithing freq. hebben van 800 KHz en 1 MHz ipv de +- 550 KHz die er nu op zit.
Gezen je skills op het gebied van solderen; zal ik ze naar je opsturen zodra ik ze binnen heb zodat je kan testen of het verschil maakt?

[Corn]

Graag! Bedankt, ben benieuwd!

[Ortep]

Ik ben al een paar jaar een unit. Eigenlijk was het set en forget. Maar een paar weken geleden kreeg ik wat problemen met een automatisering die ik maakte.

Bij goed zoeken kwam ik er achter dat ik twee entities heb.
De ene heet Fan, de andere fan.
fan wijst naar nrg_itho_3c4c_fan en Fan naar zolder_cve_silent_fan. Ze doen alle twee hun werk.
Alle oude automatiseringen waren aangemaakt met fan. Nieuwere met Fan. Die werken prima. Maar mixen geeft gemixte resultaten.
Ik heb nu alles over gezet zolder_cve_silent_fan. Gewoon omdat het netter is.

Ik raak alleen de fan/nrg_itho_3c4c_fan niet kwijt. Ik kan hem niet deleten. Weet iemand hoe dat moet?

[ Voor 7% gewijzigd door Ortep op 30-10-2026 16:57 ]

[arjenhiemstra]

Ortep schreef op vrijdag 30 oktober 2026 @ 16:55:
Ik ben al een paar jaar een unit. Eigenlijk was het set en forget. Maar een paar weken geleden kreeg ik wat problemen met een automatisering die ik maakte.

Bij goed zoeken kwam ik er achter dat ik twee entities heb.
De ene heet Fan, de andere fan.
fan wijst naar nrg_itho_3c4c_fan en Fan naar zolder_cve_silent_fan. Ze doen alle twee hun werk.
Alle oude automatiseringen waren aangemaakt met fan. Nieuwere met Fan. Die werken prima. Maar mixen geeft gemixte resultaten.
Ik heb nu alles over gezet zolder_cve_silent_fan. Gewoon omdat het netter is.

Ik raak alleen de fan/nrg_itho_3c4c_fan niet kwijt. Ik kan hem niet deleten. Weet iemand hoe dat moet?

Gebruik je de home assistant plugin?

[Ortep]

arjenhiemstra schreef op vrijdag 30 oktober 2026 @ 17:39:
Gebruik je de home assistant plugin?

Welke plugin bedoel je? Ik heb er eerlijk gezegd al in geen jaren naar gekeken. Ik kreeg jouw module, ik bracht hem online en dat was het. Maar dat was denk ik 5 jaar geleden. Ik had alleen een keer een problem toen ik een nieuw server ging inrichten. Ik was vergeten dat er een password was.

[arjenhiemstra]

Ortep schreef op vrijdag 30 oktober 2026 @ 20:26:
[...]


Welke plugin bedoel je? Ik heb er eerlijk gezegd al in geen jaren naar gekeken. Ik kreeg jouw module, ik bracht hem online en dat was het. Maar dat was denk ik 5 jaar geleden. Ik had alleen een keer een problem toen ik een nieuw server ging inrichten. Ik was vergeten dat er een password was.

Never mind, de plugin waar ik benieuwd naar was is er pas sinds dit jaar dus dat zal het niet zijn.

Om oude devices weg te gooien:
Ga in home assistant naar settings -> devices and services -> Entities
dan zie je een lijst met devices, als je in het zoekveld "itho" typt zie je alle itho entities die home assistant kent. Je kunt in de kolom "Integration" zien waar je entities mee aangemaakt zijn (bijv. MQTT)
Als je vervolgens op 1 van de entities klikt open die, in het scherm dat opent klik je op de 3 puntjes rechts bovenin en daarna op "Device info"
Het device opent dan met alle entities die erbij horen. In het blok "Device info" kun je op de 3 puntjes recht onderin klikken en vervolgens op "Delete" om de entities weg te gooien.

[Ortep]

arjenhiemstra schreef op vrijdag 30 oktober 2026 @ 22:14:
[...]

Het device opent dan met alle entities die erbij horen. In het blok "Device info" kun je op de 3 puntjes recht onderin klikken en vervolgens op "Delete" om de entities weg te gooien.

Die route heb ik gevolgd voor fan en voor Fan, maar dan kom ik op dezelfde plaats uit.


En dan lijkt het alsof ik het hele device weggooi. En niet de alleen 'fan'

[arjenhiemstra]

Ortep schreef op zaterdag 31 oktober 2026 @ 08:52:
[...]


Die route heb ik gevolgd voor fan en voor Fan, maar dan kom ik op dezelfde plaats uit.
[Afbeelding]

En dan lijkt het alsof ik het hele device weggooi. En niet de alleen 'fan'

Klopt maar als het goed is wordt dmv mqtt auto discovery het apparaat daarna weer aangemaakt. Zo niet dan zou een herstart van de add-on voldoende moeten zijn.

[n00bCoder]

Ik heb en itho demandflow en de wifi module geïnstalleerd. ik vraag me af hoe die wifi module de fan speed van besturen, er loopt helemaal geen kabel oid vanaf de demandflow naar de ventilatieunit…

En waar vind ik ergens in de ui of ik ook de kleppen per kamer kan bedienen?

[Ortep]

arjenhiemstra schreef op zaterdag 31 oktober 2026 @ 10:37:
[...]


Klopt maar als het goed is wordt dmv mqtt auto discovery het apparaat daarna weer aangemaakt. Zo niet dan zou een herstart van de add-on voldoende moeten zijn.

Dat ga ik na het weekend proberen. Nu is het even wat te druk

[__Peter__]

n00bCoder schreef op zaterdag 31 oktober 2026 @ 10:51:
Ik heb en itho demandflow en de wifi module geïnstalleerd. ik vraag me af hoe die wifi module de fan speed van besturen, er loopt helemaal geen kabel oid vanaf de demandflow naar de ventilatieunit…

En waar vind ik ergens in de ui of ik ook de kleppen per kamer kan bedienen?


[Afbeelding]

Volgens mij heeft de Itho controller een draadloze verbinding met de fan. Het is mij nooit gelukt om de fan of the kleppen te sturen en het gedrag van de controller was niet te begrijpen. Toch een beetje reclame maken voor mijn alternatief: Open source vraag gestuurd ventilatie systeem

[Ortep]

arjenhiemstra schreef op zaterdag 31 oktober 2026 @ 10:37:
[...]


Klopt maar als het goed is wordt dmv mqtt auto discovery het apparaat daarna weer aangemaakt. Zo niet dan zou een herstart van de add-on voldoende moeten zijn.

Ik heb hem verwijderd, maar hij komt niet terug via MQTT. Ook niet na een reboot van HA. Ik zie hem wel. Maar dat komt omdat mijn Fritzbox hem ziet via het ip address

Aanvulling:

Ik heb de Itho van de stroom afgehaald en weer aangezet. Hij is weer zichtbaar

[ Voor 9% gewijzigd door Ortep op 03-11-2026 10:49 ]

[Markkolk]

Ik heb het volgende,

Ik heb de Wifi Add-on geïnstalleerd en de wizard doorlopen.
In de web interface (wifi controller) zie ik alle waarden en deze veranderen als ik via de afstandsbediening (RF) het toerental verhoog of verlaag.

Echter in Homey zie ik enkel de waarde van de buiten temperatuur. alle andere waarde staan wel vermeld maar er wordt geen waarde bij gepresenteerd.

Teven kan ik geen virtual remote aanmaken, doordat deze niet aanwezig zou zijn.

het betreft een WTW type
HRU-3 BVFT-H-005
Artikelnr 545-4221

Wat kan er aan de hand zijn?

[jiquera]

Hoi ik heb recent de wifi add-on aan een DemandFlow systeem gehangen en aan home assistant gekoppeld en hoewel het een soort van werkt heb ik een paar vragen:

#1 Ik heb de koppeling nu via Arjens integratie ding gemaakt, maar ik zie de add on ook MQTT ondersteund... heeft het een een voor of nadeel ten opzichte van het ander?

#2 Ik heb een virtual remote van het type DF/QF maar ik krijg regelmatig de volgende error in de log: "SYS: rfdemand failed - remote 0 is not RFT CO2 or RFT RV type" Ik begrijp niet waarom hij hier over klaagt... iemand die hier meer verstand van heeft? Dit wordt getriggered door het gebruik van de fan demand slider in HA. Dus is een gevolg van issue #3

#3 In home assistant worden de controls weergegeven zoals hieronder, maar de opties "medium", "auto", "auto night", "fan demand" zitten niet op mijn RFT remote en lijken ook geen effect te hebben. Is het de bedoeling dat ze in HA verschijnen of heb ik iets verkeerd ingesteld?



#4 ook zie ik een toggle verschijnen die remote0 aan en uit kan zetten... wat doet dit?




#5 Ik heb een automation gemaakt die 's avonds de ventilatie op "low" zet om de hoeveelheid lawaai in huis te verminderen en 's ochtends weer op "high". De action is een "press low" dus ik verwacht in de log van het device eigenlijk dat er heel weinig gebeurd snachts... maar de activity log van de nacht staat vol met dit:



Het lijken me status updates? maar ze triggeren om de 4 uur ofzoiets, en t merendeel is unavailable, maar als ze er niet zijn... waarom worden ze dan geupdate?

#6 ik zie ook een "last command" veld maar het is me niet helemaal duidelijk wat dat betekent:

- het laaste commando verstuurd van de addon naar de DF/QF
- het laatste commando ontvangen door de addon via de main page GUI
- het laatste commando ontvangen door de addon voor virtual remote0
- het laatste commando ontvangen door de gemonitorde fysieke remote
- of een combinatie van all of the above?

#7 er is een rariteit in de status veldjes die gerapporteerd worden voor de huidige mode als een specifieke mode is geselecteerd dan is het bij behorende veldje 1 en anders 0. Behalve bij "eco comfort" daar is het andersom... is dit iets geks van itho of van de add on?


Ben nogal nieuw met Home Assistant dus dat helpt niet echt met debuggen hier... t probleem is vooral dat ik de logging dus niet helemaal geinterpreteerd krijg waardoor ik ook niet weet of er nou een probleem is of niet.

[ Voor 21% gewijzigd door jiquera op 07-11-2026 11:25 ]

[arjenhiemstra]

jiquera schreef op zaterdag 7 november 2026 @ 11:02:
Hoi ik heb recent de wifi add-on aan een DemandFlow systeem gehangen en aan home assistant gekoppeld en hoewel het een soort van werkt heb ik een paar vragen:

#1 Ik heb de koppeling nu via Arjens integratie ding gemaakt, maar ik zie de add on ook MQTT ondersteund... heeft het een een voor of nadeel ten opzichte van het ander?

#2 Ik heb een virtual remote van het type DF/QF maar ik krijg regelmatig de volgende error in de log: "SYS: rfdemand failed - remote 0 is not RFT CO2 or RFT RV type" Ik begrijp niet waarom hij hier over klaagt... iemand die hier meer verstand van heeft? Dit wordt getriggered door het gebruik van de fan demand slider in HA. Dus is een gevolg van issue #3

#3 In home assistant worden de controls weergegeven zoals hieronder, maar de opties "medium", "auto", "auto night", "fan demand" zitten niet op mijn RFT remote en lijken ook geen effect te hebben. Is het de bedoeling dat ze in HA verschijnen of heb ik iets verkeerd ingesteld?

[Afbeelding]

#4 ook zie ik een toggle verschijnen die remote0 aan en uit kan zetten... wat doet dit?

[Afbeelding]


#5 Ik heb een automation gemaakt die 's avonds de ventilatie op "low" zet om de hoeveelheid lawaai in huis te verminderen en 's ochtends weer op "high". De action is een "press low" dus ik verwacht in de log van het device eigenlijk dat er heel weinig gebeurd snachts... maar de activity log van de nacht staat vol met dit:

[Afbeelding]

Het lijken me status updates? maar ze triggeren om de 4 uur ofzoiets, en t merendeel is unavailable, maar als ze er niet zijn... waarom worden ze dan geupdate?

#6 ik zie ook een "last command" veld maar het is me niet helemaal duidelijk wat dat betekent:

- het laaste commando verstuurd van de addon naar de DF/QF
- het laatste commando ontvangen door de addon via de main page GUI
- het laatste commando ontvangen door de addon voor virtual remote0
- het laatste commando ontvangen door de gemonitorde fysieke remote
- of een combinatie van all of the above?

#7 er is een rariteit in de status veldjes die gerapporteerd worden voor de huidige mode als een specifieke mode is geselecteerd dan is het bij behorende veldje 1 en anders 0. Behalve bij "eco comfort" daar is het andersom... is dit iets geks van itho of van de add on?


Ben nogal nieuw met Home Assistant dus dat helpt niet echt met debuggen hier... t probleem is vooral dat ik de logging dus niet helemaal geinterpreteerd krijg waardoor ik ook niet weet of er nou een probleem is of niet.

Goede vragen, een deel daarvan lijken bugs aan mijn kant.

1. De integratie haalt de gegevens elke 10 seconden op via de API van de add-on en heeft wat extra's: een fan per remote, Spider thermostaten en een melding bij een firmware update. Met MQTT stuurt de add-on wijzigingen zelf naar een broker en meldt hij zijn entities zelf aan bij HA. Allebei prima, maar gebruik er één, anders krijg je alles dubbel.
2. Bug in de integratie. Een DemandFlow bedien je via een DF/QF remote en die kent alleen low, high, de timers en cook. Medium, auto, auto night en de fan demand slider horen er niet te staan en doen ook niets. De slider probeert een RF demand naar RF remote 0 te sturen, vandaar die foutmelding. In de volgende versie van de integratie verdwijnen ze, tot die tijd kun je ze in HA uitschakelen.
3. Zelfde oorzaak als 2.
4. Dat is de fan van virtual remote 0. Uit stuurt low (een DF/QF remote heeft geen away), aan stuurt high. Het is dus geen echte aan/uit, en de status is het laatst verstuurde commando, niet wat de unit doet.
5. Dat zijn geen nieuwe commando's. Om 3:13:10 worden alle entities "unavailable" en 10 seconden later zijn ze terug. Bij een knop is de status het moment dat hij voor het laatst is ingedrukt, daarom zie je die tijden opnieuw. 10 seconden is precies één keer ophalen door de integratie, dus vermoedelijk is één verzoek aan de add-on mislukt. Kun je de log van de add-on rond die tijden posten (staat er een herstart in?) en in de log van HA zoeken op Error fetching itho_wifi data?
6. Er zijn er twee. Last command van de add-on is het laatste commando dat de add-on heeft verwerkt, ongeacht de bron: webinterface, API, MQTT, HA of een ontvangen RF remote. De bron staat als attribuut bij die sensor. Bij de fan per remote is het het laatste commando dat via die remote is verstuurd. Daar zit nog een bug: een commando dat de DF/QF remote niet kent, bijvoorbeeld medium, werd toch als laatste commando getoond. Dat wordt in de volgende firmware opgelost.
7. Dat veld komt rechtstreeks van de Itho. Volgens mij is het niet "deze modus staat aan" zoals de andere velden, maar geeft het aan of de unit in eco of comfort staat. Welke waarde wat betekent weet ik niet zeker. Vergelijk het eens met de instelling Eco - Comfort mode van je unit.

[arjenhiemstra]

Oudere Itho units (9 pin interface) via RF bedienen: testers gezocht

Sommige oudere Itho units zoals de CVE ECO 2 gebruiken een ouder RF protocol dan de huidige RFT remotes. Oa. de CVE ECO 2 maar ook sommige HRU's met de 9-pins aansluiting ondersteunen de add-on op dit moment niet via I2C of RF.
Ik heb het oude protocol nu kunnen reverse engineeren via RF.

Op mijn eigen CVE ECO 2 werkt nu:

• joinen en leaven
• low, medium en high
• timer 1, 2 en 3

Hoe werkt het

• In de testfirmware staat onder RF devices een nieuw remote type RF (old protocol).
• Zo'n remote heeft een eigen ID, dit werkt naast eventuele bestaande remotes.
• Beperking; de Itho stuurt niets terug. De add-on weet dus alleen welk commando hij als laatste heeft verstuurd, bijv. niet hoe snel de ventilator draait (wat met nieuwere Itho's wel mogelijk is).

Wie zoek ik
Een paar mensen met zo'n oudere unit die dit willen testen. Dit werkt alleen met een non-cve module met CC1101 RF module.

Reageer hier of stuur me een DM met:

1. het type unit (typeplaatje)
2. de remote die je gebruikt

Dan stuur ik je de testfirmware met instructies. Mocht je nog geen add-on hebben en twijfelen of deze functie interessant voor je is; je mag de module kosteloos retourneren.

[jiquera]

arjenhiemstra schreef op zondag 8 november 2026 @ 02:28:
[...]

Goede vragen, een deel daarvan lijken bugs aan mijn kant.

1. De integratie haalt de gegevens elke 10 seconden op via de API van de add-on en heeft wat extra's: een fan per remote, Spider thermostaten en een melding bij een firmware update. Met MQTT stuurt de add-on wijzigingen zelf naar een broker en meldt hij zijn entities zelf aan bij HA. Allebei prima, maar gebruik er één, anders krijg je alles dubbel.
2. Bug in de integratie. Een DemandFlow bedien je via een DF/QF remote en die kent alleen low, high, de timers en cook. Medium, auto, auto night en de fan demand slider horen er niet te staan en doen ook niets. De slider probeert een RF demand naar RF remote 0 te sturen, vandaar die foutmelding. In de volgende versie van de integratie verdwijnen ze, tot die tijd kun je ze in HA uitschakelen.
3. Zelfde oorzaak als 2.
4. Dat is de fan van virtual remote 0. Uit stuurt low (een DF/QF remote heeft geen away), aan stuurt high. Het is dus geen echte aan/uit, en de status is het laatst verstuurde commando, niet wat de unit doet.
5. Dat zijn geen nieuwe commando's. Om 3:13:10 worden alle entities "unavailable" en 10 seconden later zijn ze terug. Bij een knop is de status het moment dat hij voor het laatst is ingedrukt, daarom zie je die tijden opnieuw. 10 seconden is precies één keer ophalen door de integratie, dus vermoedelijk is één verzoek aan de add-on mislukt. Kun je de log van de add-on rond die tijden posten (staat er een herstart in?) en in de log van HA zoeken op Error fetching itho_wifi data?
6. Er zijn er twee. Last command van de add-on is het laatste commando dat de add-on heeft verwerkt, ongeacht de bron: webinterface, API, MQTT, HA of een ontvangen RF remote. De bron staat als attribuut bij die sensor. Bij de fan per remote is het het laatste commando dat via die remote is verstuurd. Daar zit nog een bug: een commando dat de DF/QF remote niet kent, bijvoorbeeld medium, werd toch als laatste commando getoond. Dat wordt in de volgende firmware opgelost.
7. Dat veld komt rechtstreeks van de Itho. Volgens mij is het niet "deze modus staat aan" zoals de andere velden, maar geeft het aan of de unit in eco of comfort staat. Welke waarde wat betekent weet ik niet zeker. Vergelijk het eens met de instelling Eco - Comfort mode van je unit.

Ten eerste mijn waardering voor je snelle en volledige reacties hier in het topic, echt super!

1. helder
2. helder
3. helder
4. wat bedoel je hier met "fan" ze sturen allemaal de zelfde unit aan, dus er zijn niet echt meer "fans" toch? Ik neem aan dat dit gewoon de status is van de laatste commandos van die specifieke virtual remote.
5. In de ithoWifi log staat niks opvallends (wat gefaalde update checks want geen internet, en wat commandos die dus geen DF/QF commandos zijn).
   In de HA log zie ik 2 soorten errors:
   2026-11-08 09:17:40.694+01:00 ERROR (MainThread) [custom_components.itho_wifi.coordinator] Error fetching itho_wifi_status data: Connection error: Timeout connecting to <censored domain>
   
   De eerste zal een netwerk error zijn aan mijn kant, de wifi moet door 2 verdiepingen heen, het is voor nu even wat het is...
   
   2026-11-08 10:08:47.493+01:00 WARNING (MainThread) [custom_components.itho_wifi] IthoWiFi setup: use_rf_commands=False rf_standalone=False itho_devtype='DemandFlow' itho_rf_standalone=0 itho_control_interface=0 deviceinfo={'itho_devtype': 'DemandFlow', 'itho_mfr': 0, 'itho_deviceid': 11, 'itho_hwversion': 38, 'itho_fwversion': 20, 'add-on_hwid': '58:2A:BD:B8:04:64', 'add-on_fwversion': '3.2.0', 'ota_progress': -1, 'itho_rf_standalone': 0, 'itho_control_interface': 0, 'add-on_fwupdate_available': 'false', 'add-on_latest_fw': '', 'add-on_latest_beta_fw': '', 'add-on_update_channel': 'stable', 'add-on_latest_for_channel': '3.2.0'}
   
   Deze warning zie ik ook vaak (op andere tijden dan de eerste) maar dit zegt me niks... ik gok dat t eigenlijk ook een connection error ding is.
6. Na een beetje testen lijkt dit exclusief de gemonitorde remotes? (die dus eigenlijk geen actie op de add on vereisen?) klopt dat?
7. helder
8. Gegeven de matige verbinding, is er een manier om de sensoren hun vorige waarden te laten behouden bij connection failure om de log per sensor een beetje schoon te houden? Ik zie dat ik per sensor handmatig een nieuwe trigger sensor kan maken maar is er een algemene manier omdat te doen die niet 40 handmatige sensors betekent?
   

[arjenhiemstra]

jiquera schreef op zondag 8 november 2026 @ 10:53:
[...]

Ten eerste mijn waardering voor je snelle en volledige reacties hier in het topic, echt super!

1. helder
2. helder
3. helder
4. wat bedoel je hier met "fan" ze sturen allemaal de zelfde unit aan, dus er zijn niet echt meer "fans" toch? Ik neem aan dat dit gewoon de status is van de laatste commandos van die specifieke virtual remote.
5. In de ithoWifi log staat niks opvallends (wat gefaalde update checks want geen internet, en wat commandos die dus geen DF/QF commandos zijn).
   In de HA log zie ik 2 soorten errors:
   2026-11-08 09:17:40.694+01:00 ERROR (MainThread) [custom_components.itho_wifi.coordinator] Error fetching itho_wifi_status data: Connection error: Timeout connecting to <censored domain>
   
   De eerste zal een netwerk error zijn aan mijn kant, de wifi moet door 2 verdiepingen heen, het is voor nu even wat het is...
   
   2026-11-08 10:08:47.493+01:00 WARNING (MainThread) [custom_components.itho_wifi] IthoWiFi setup: use_rf_commands=False rf_standalone=False itho_devtype='DemandFlow' itho_rf_standalone=0 itho_control_interface=0 deviceinfo={'itho_devtype': 'DemandFlow', 'itho_mfr': 0, 'itho_deviceid': 11, 'itho_hwversion': 38, 'itho_fwversion': 20, 'add-on_hwid': '58:2A:BD:B8:04:64', 'add-on_fwversion': '3.2.0', 'ota_progress': -1, 'itho_rf_standalone': 0, 'itho_control_interface': 0, 'add-on_fwupdate_available': 'false', 'add-on_latest_fw': '', 'add-on_latest_beta_fw': '', 'add-on_update_channel': 'stable', 'add-on_latest_for_channel': '3.2.0'}
   
   Deze warning zie ik ook vaak (op andere tijden dan de eerste) maar dit zegt me niks... ik gok dat t eigenlijk ook een connection error ding is.
6. Na een beetje testen lijkt dit exclusief de gemonitorde remotes? (die dus eigenlijk geen actie op de add on vereisen?) klopt dat?
7. helder
8. Gegeven de matige verbinding, is er een manier om de sensoren hun vorige waarden te laten behouden bij connection failure om de log per sensor een beetje schoon te houden? Ik zie dat ik per sensor handmatig een nieuwe trigger sensor kan maken maar is er een algemene manier omdat te doen die niet 40 handmatige sensors betekent?
   

4. Klopt. "Fan" is hier het type entity in HA, niet een extra ventilator. Elke remote krijgt een eigen fan entity. Bij een virtual remote is dat altijd de unit waar de add-on aan zit. Een RF remote kan ook een ander apparaat aansturen, bijvoorbeeld een HRU via RF terwijl de add-on via I2C aan een WPU zit. De status is het laatste commando via die remote.

5. De eerste is inderdaad de verbinding, de integratie wacht maximaal 10 seconden op een antwoord van de add-on.
De warning is onschuldig. Dat is een regel voor diagnose die er nog in zat. Hij komt elke keer dat de integratie start: bij een herstart van HA, bij een reload, en als het eerste ophalen bij het starten mislukt en HA het later opnieuw probeert. Met jouw wifi is dat laatste waarschijnlijk. In de volgende versie verdwijnt hij uit de log.

6. Niet helemaal. Bij een gemonitorde remote komt het laatste commando uit wat de add-on via RF ontvangt, daar hoeft de add-on inderdaad niets voor te doen. Bij een virtual remote is het het laatste commando dat de add-on via die remote heeft verstuurd. De bug die ik noemde zit alleen in dat tweede geval. Of bedoel je met "dit" iets anders?

Vorige waarden behouden
Een algemene instelling daarvoor heeft HA niet. Een integratie zet bij een mislukte update standaard alle entities op unavailable. Dat kan ik in de integratie aanpassen: een paar mislukte keren achter elkaar negeren en de vorige waarden laten staan, en pas daarna unavailable. Dat neem ik mee in de volgende versie, dan heb je die 40 template sensors niet nodig.

[jiquera]

4. helder
5. helder
6. Ik bedoel t veld/sensor/(ik heb t jargon nog niet helemaal down) 'last command' van de add on. Update die ook als een gemonitorde remote iets stuurt, of alleen als de add-on ook echt een commando moet afhandelen e.g. bij een virtual remote / via de GUI / of een aangemelde remote bij de add on? Uit je verwoording lijkt t eerste geval maar uit mijn tests t tweede. In mijn geval heb ik mijn remote dus niet afgemeld bij de DF unit, dus die handelt t af, en de add on observeert alleen het verkeer.

Vorige waarden behouden: dat zou zeker fijn zijn om wat fault-tolerantie in het verkeer toe te kunnen staan. Nu wordt ik wel nieuwsgierig wanneer de volgende versie uitkomt, al enig idee?

Bij ons komt de HR kap ventilatie uit in een kast (was al zo toen we t huis kochten), ik heb die dus losgekoppeld maar wil het knopje op de remote eigenlijk gebruiken om via HA een uur lang de keuken ventilatie aan te zetten (timer maar dan na 1 uur uit). Daarvoor moet ik enigszins betrouwbaar weten of er in de tussen tijd niet nog een ander commando is gestuurd ongeacht de bron.

[arjenhiemstra]

jiquera schreef op zondag 8 november 2026 @ 19:30:
4. helder
5. helder
6. Ik bedoel t veld/sensor/(ik heb t jargon nog niet helemaal down) 'last command' van de add on. Update die ook als een gemonitorde remote iets stuurt, of alleen als de add-on ook echt een commando moet afhandelen e.g. bij een virtual remote / via de GUI / of een aangemelde remote bij de add on? Uit je verwoording lijkt t eerste geval maar uit mijn tests t tweede. In mijn geval heb ik mijn remote dus niet afgemeld bij de DF unit, dus die handelt t af, en de add on observeert alleen het verkeer.

Vorige waarden behouden: dat zou zeker fijn zijn om wat fault-tolerantie in het verkeer toe te kunnen staan. Nu wordt ik wel nieuwsgierig wanneer de volgende versie uitkomt, al enig idee?

Bij ons komt de HR kap ventilatie uit in een kast (was al zo toen we t huis kochten), ik heb die dus losgekoppeld maar wil het knopje op de remote eigenlijk gebruiken om via HA een uur lang de keuken ventilatie aan te zetten (timer maar dan na 1 uur uit). Daarvoor moet ik enigszins betrouwbaar weten of er in de tussen tijd niet nog een ander commando is gestuurd ongeacht de bron.

6. Je test klopt, ik had het verkeerd verwoord. Last command van de add-on verandert alleen als de add-on zelf een commando afhandelt: een virtual remote, de webinterface, de API, MQTT, HA, of een RF remote die als receive bij de add-on is aangemeld. Een gemonitorde remote wordt alleen afgeluisterd, die commando's voert de add-on niet uit en die komen daar dus niet in.
Wat de add-on van een gemonitorde remote hoort, staat wel bij die remote zelf: het laatste commando en het tijdstip daarvan. In de integratie zijn dat de sensoren per remote. Die zet je aan in de opties van de integratie door de remote te selecteren.

Volgende versie
Van de integratie is 0.8.1 al uit, met het behouden van de vorige waarden. Update via HACS. De fix voor het laatste commando per virtual remote zit in de firmware, de volgende beta zal ergens de komende dagen uitkomen

[jiquera]

nice, goede productie lijn heb je daar ;-)

[edvanleeuwen]

Ik probeer de ventilatie met HA 's avonds laag te zetten en 's morgen op auto. Dat laatste lukt me nog niet en ik heb het forum al afgestruind of dat ergens besproken wordt. Daaruit heb ik gehaald dat de medium-instelling met Force auto het zou moeten doen. Maar die reageert niet.

Iemand nog een suggestie? Of kan dat gewoon niet?

CVE Silent, NRG-versie 3.2.0, Itho WIFI 2.5.9.