OpenQuatt: zelf je Quatt warmtepomp aansturen

[jj85]

babobo1977 schreef op woensdag 1 juli 2026 @ 09:25:
[...]

Ik heb ook een waveshare module. Haal de kabel uit de cic en steek de (rode) A kabel en de (blauwe) B kabel in de waveshare module. De groene kabel wordt niet gebruikt. Ik heb deze aan de kabel gebogen om contact te voorkomen.
Wat ik me nog afvraag is of ik eventueel met een 2e waveshare module de CIC weer van info kan voorzien?
In hoe is dat in te stellen?

Ja, in principe wel
Staat min of meer hier beschreven
https://github.com/jeroen...tree/main/docs/cic-bridge

(let op; deze config is niet gelijk aan de Waveshare, maar voor een https://shop.m5stack.com/products/atomic-rs485-base met https://shop.m5stack.com/...oms3-lite-esp32s3-dev-kit )

[pieke]

Mailtje van Quatt over aanpassing van de algemene voorwaarden. Ik ben te lui om te checken of dit er eerst ook al in stond, maar dit staat er nu onder redenen waarom de standaard garantie vervalt.



Volledige nieuwe voorwaarden: klik

[jj85]

pieke schreef op woensdag 1 juli 2026 @ 19:08:
Mailtje van Quatt over aanpassing van de algemene voorwaarden. Ik ben te lui om te checken of dit er eerst ook al in stond, maar dit staat er nu onder redenen waarom de standaard garantie vervalt.

[Afbeelding]

Volledige nieuwe voorwaarden: klik

Stond er altijd al in, ook dat je de warmtepomp en software niet mag reverse engineeren

[faberr]

babobo1977 schreef op woensdag 1 juli 2026 @ 09:25:
[...]

Ik heb ook een waveshare module. Haal de kabel uit de cic en steek de (rode) A kabel en de (blauwe) B kabel in de waveshare module. De groene kabel wordt niet gebruikt. Ik heb deze aan de kabel gebogen om contact te voorkomen.
Wat ik me nog afvraag is of ik eventueel met een 2e waveshare module de CIC weer van info kan voorzien?
In hoe is dat in te stellen?

Thanks, zodra ik hem binnen heb dan ga ik ermee aan de slag en zal m’n ervaringen delen.

[RickvdT]

leejoow schreef op maandag 29 juni 2026 @ 09:47:
[...]

2 Dallas DS18B20 kan hardware technisch sowieso op de hardware omdat het een bussysteem is. Alleen zoals ik elke keer aangeef: je zal wel je eigen firmware moeten maken dan

Extra relais zou inderdaad via een van de extra GPIO pinnen kunnen (moet je wel zorgen voor de juiste transistoren en zo, of een standaard module op 3.3V daarvoor gebruiken).
[...]

Top! Firmware moet geen probleem zijn. De hardware maakte ik mij meer zorgen om, maar na mij daar iets meer in verdiept te hebben moet dat vrij eenvoudig zijn. Zitten de pin headers standaard al vast op het boord? Met mijn soldeerkunsten zou dat eventueel nog de grootste uitdaging zijn

[leejoow]

Ik zit er aan te denken dat dat een optie in het bestelproces gaat worden, ik denk ook een iets anders deksel dan te leveren zodat de pinnen exposed zijn en gebruikt kunnen worden zonder de deksel er af te halen
Binnenkort weer eens even een in de tekensoftware klimmen

[sdh1981]

pieke schreef op woensdag 1 juli 2026 @ 19:08:
Mailtje van Quatt over aanpassing van de algemene voorwaarden. Ik ben te lui om te checken of dit er eerst ook al in stond, maar dit staat er nu onder redenen waarom de standaard garantie vervalt.

[Afbeelding]

Volledige nieuwe voorwaarden: klik

Daarboven heb je nog een wettelijke garantie die je het recht geeft om een aanpassing te doen aan het systeem. Het 1ste jaar moet Quatt bewijzen dat jij iets stuk hebt gemaakt door de modificatie, het 2de jaar ligt het in de handen van de gebruiker om aan te tonen dat je aanpassing niet de oorzaak is van een defecte Quatt.

[geerttttt]

Ik dacht een waveshare module gekocht te hebben, maar toen hij thuis was bezorgd viel me ineens op dat ik geen usb-c poort erop had zitten. Verkeerde module besteld... Kak!

[jj85]

m10tech schreef op zondag 28 juni 2026 @ 09:24:
[...]

Ik ben nog maar net begonnen met de analyse, maar volgens mij gebruiken we de ESPHOME modbus library. En die is conceptueel gewoon een loop die maximaal elke 16 ms mag draaien.

Dat is volstrekt niet voldoende om de 3.5T = 2ms van modus op 19200 baud te volgen volgens het boekje. MAAR, omdat we nu IDF hebben, is het gebruiken van de RS485 mode van de serial driver wel binnen handbereik (hoop ik).
Is duidelijk een diepte-investering, en is misschien niet nodig op een ESP-S3 en goede bekabeling.
Maar in mijn opstelling gaat modus helemaal van slag door het opstarten van de compressor, en bevriest de update van het dashboard. Dan hoort de ODU geen master meer en schakelt na 4 minuten af.
Dus afhankelijk van hoe snel de modbus recovert heb je een start-stop cyclus van 7 minuten, of hij draait verder.

Dat is 1 van de twee theorieën, de andere is dat de coil te koud wordt.
Of beide zijn waar.

Wordt vervolgd

Wel interessant.

Nu gebruik ik de modbus component in ESPHome en zet daar de flow_control_pin
Alternatief is deze in de UART-component te definiëren. Dan krijgt ESP-IDF zelf RS485 half-duplex control over RTS/DE. Maar eens proberen binnenkort.

[CPM]

Ik lees dingen over het aansluiten van een extra temperatuur sensor? Kan iemand mij kort uitleggen waarvoor je die dan zou gebruiken? En zou je zoiets ook bijv. via Bluetooth (of anders) kunnen realiseren?

[geerttttt]

Ik heb ondertussen openQuatt geïnstalleerd. Maar om een of andere reden krijgt hij geen data door van de CiC. Iemand een idee? De json feed is handmatig wel te lezen, dus alles lijkt toch goed ingesteld?



Misschien is mijn logging relevant?

code:

03-07-2026, 19:50:03 [I][app:117]: setup() finished successfully!
03-07-2026, 19:50:03 [W][component:382]: wifi set Warning flag: scanning for networks
03-07-2026, 19:50:03 [I][app:151]: ESPHome version 2026.6.2 compiled on 2026-07-01 13:30:01 +0000
03-07-2026, 19:50:03 [I][app:153]: Project openquatt.openquatt version v0.39.0
03-07-2026, 19:50:03 [I][app:158]: ESP32 Chip: ESP32-S3 rev0.2, 2 core(s)
03-07-2026, 19:50:03 [W][gpio.one_wire:085]:   Found no devices!
03-07-2026, 19:50:03 [I][supervisory:1341]: ControlMode transition: (unset) -> CM0 (no thermal demand)
03-07-2026, 19:50:04 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 52ms after last send
03-07-2026, 19:50:05 [I][wifi:1097]: Connecting to 'REDACTED (priority 0, attempt 1/2 in phase SCAN_CONNECTING)...
03-07-2026, 19:50:05 [W][component:513]: wifi_signal.sensor took a long time for an operation (62 ms), max is 50 ms
03-07-2026, 19:50:05 [W][wifi_esp32:811]: Disconnected ssid=REDACTED reason='Authentication Failed'
03-07-2026, 19:50:05 [W][wifi:1678]: Connecting to network failed (callback)
03-07-2026, 19:50:05 [I][wifi:1097]: Connecting to 'REDACTED) (priority 0, attempt 2/2 in phase SCAN_CONNECTING)...
03-07-2026, 19:50:06 [I][quatt:644]: Startup inhibit armed for 240s after reboot; compressors remain blocked.
03-07-2026, 19:50:06 [I][quatt.req:802]: Optimizer reason: inactive
03-07-2026, 19:50:06 [I][quatt.req:826]: Request reason: inactive_cm (mode=0 strategy=0 owner=0 topology=0 hp1=0 hp2=0)
03-07-2026, 19:50:06 [W][dallas.temp.sensor:030]:   Unable to select an address
03-07-2026, 19:50:07 [I][wifi:1575]: Connected
03-07-2026, 19:50:07 [W][component:405]: wifi cleared Warning flag
03-07-2026, 19:50:07 [I][quatt.boiler:165]: Boiler blocked: water supply temperature unavailable
03-07-2026, 19:50:11 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 53ms after last send
03-07-2026, 19:50:12 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:50:12 [I][openquatt.cic:184]: CIC fetch task stack high-watermark: 3744 B free
03-07-2026, 19:50:12 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:50:12 [W][component:513]: openquatt_cic took a long time for an operation (53 ms), max is 50 ms
03-07-2026, 19:50:13 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 43ms after last send
03-07-2026, 19:50:13 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:50:13 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 51ms after last send
03-07-2026, 19:50:18 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 46ms after last send
03-07-2026, 19:50:27 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:50:27 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:50:28 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:50:36 [W][modbus:063]: Stop waiting for response from 1 104ms after last send
03-07-2026, 19:50:40 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 48ms after last send
03-07-2026, 19:50:42 [W][component:513]: modbus took a long time for an operation (57 ms), max is 50 ms
03-07-2026, 19:50:42 [W][modbus:063]: Stop waiting for response from 2 122ms after last send
03-07-2026, 19:50:47 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 48ms after last send
03-07-2026, 19:50:52 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:50:52 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:50:53 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:51:02 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 49ms after last send
03-07-2026, 19:51:03 [I][safe_mode:142]: Boot seems successful; resetting boot loop counter
03-07-2026, 19:51:07 [W][component:513]: api took a long time for an operation (55 ms), max is 50 ms
03-07-2026, 19:51:09 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 51ms after last send
03-07-2026, 19:51:17 [I][quatt.cm100:083]: CM100 requested via dashboard (override=Auto task=0 active=0 pending=0)
03-07-2026, 19:51:18 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 59ms after last send
03-07-2026, 19:51:18 [I][quatt.cm100:299]: CM100 request pending while not in CM100; waiting
03-07-2026, 19:51:19 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 57ms after last send
03-07-2026, 19:51:20 [I][supervisory:1341]: ControlMode transition: CM0 -> CM100 (commissioning task active)
03-07-2026, 19:51:23 [I][quatt.cm100:302]: CM100 request accepted; entering neutral commissioning container
03-07-2026, 19:51:37 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:51:37 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:51:38 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:51:38 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 49ms after last send
03-07-2026, 19:51:40 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 56ms after last send
03-07-2026, 19:52:00 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 52ms after last send
03-07-2026, 19:52:08 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 49ms after last send
03-07-2026, 19:52:14 [I][quatt.cm100.hpcal:129]: HP water sensor calibration requested (min_mix=60s stable_window=60s max=300s flow_setpoint=normal spread<=0.35C drift<=0.20C/min max_offset=2.00C)
03-07-2026, 19:52:15 [I][quatt.cm100.hpcal:541]: status=MIXING phase=1 remaining=300s flow=nanL/h spread=nanC stable=0s/60s
03-07-2026, 19:52:17 [I][flow:449]: AUTO start(CM100-task): iPWM=400 (last_good=440 bank=normal fallback=440 commissioning=yes hold 20s, fixed iPWM)
03-07-2026, 19:52:17 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:17 [I][flow:774]: Flow mode changed: AUTO (failsafe) (cm=CM100 manual=0 failsafe=1 hold=4 pwm=850)
03-07-2026, 19:52:22 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:27 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:32 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:35 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 52ms after last send
03-07-2026, 19:52:37 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:42 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:47 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:52 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:57 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:02 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:53:02 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:53:02 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:03 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:53:07 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:09 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 45ms after last send
03-07-2026, 19:53:12 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:13 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 50ms after last send
03-07-2026, 19:53:16 [I][quatt.cm100.hpcal:541]: status=MEASURING phase=2 remaining=239s flow=nanL/h spread=nanC stable=0s/60s
03-07-2026, 19:53:17 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:22 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:27 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:32 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:37 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:39 [W][modbus:063]: Stop waiting for response from 2 104ms after last send
03-07-2026, 19:53:41 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 43ms after last send
03-07-2026, 19:53:42 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:47 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:52 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:55 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 50ms after last send
03-07-2026, 19:53:57 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:54:02 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:54:07 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:54:08 [I][quatt:657]: Startup inhibit cleared after reboot; compressors may resume.
03-07-2026, 19:54:10 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 45ms after last send
03-07-2026, 19:54:12 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:54:16 [W][component:513]: template.switch took a long time for an operation (64 ms), max is 50 ms
03-07-2026, 19:54:16 [W][modbus:063]: Stop waiting for response from 1 118ms after last send
03-07-2026, 19:54:16 [I][quatt.cm100.hpcal:541]: status=FAILED: no flow detected phase=0 remaining=0s flow=nanL/h spread=nanC stable=0s/60s
03-07-2026, 19:54:40 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 93ms after last send
03-07-2026, 19:55:06 [W][component:513]: template.binary_sensor took a long time for an operation (55 ms), max is 50 ms
03-07-2026, 19:55:07 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:55:07 [I][openquatt.cic:184]: CIC fetch task stack high-watermark: 3684 B free
03-07-2026, 19:55:07 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:55:08 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:55:48 [W][modbus:063]: Stop waiting for response from 2 110ms after last send
03-07-2026, 19:55:55 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 51ms after last send
03-07-2026, 19:56:06 [W][component:513]: openquatt_mqtt_publisher took a long time for an operation (62 ms), max is 50 ms
03-07-2026, 19:56:09 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 50ms after last send
03-07-2026, 19:56:11 [W][modbus:063]: Stop waiting for response from 2 142ms after last send
03-07-2026, 19:56:18 [W][modbus:063]: Stop waiting for response from 2 104ms after last send
03-07-2026, 19:56:36 [W][modbus:417]: Clearing buffer of 2 bytes - timeout after partial response 18ms after last send
03-07-2026, 19:56:36 [W][modbus:063]: Stop waiting for response from 1 105ms after last send
03-07-2026, 19:56:42 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 76ms after last send
03-07-2026, 19:56:47 [W][modbus:063]: Stop waiting for response from 1 114ms after last send
03-07-2026, 19:56:58 [W][component:513]: modbus took a long time for an operation (65 ms), max is 60 ms
03-07-2026, 19:56:58 [W][modbus:063]: Stop waiting for response from 1 129ms after last send
03-07-2026, 19:57:06 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 49ms after last send
03-07-2026, 19:57:10 [W][modbus:063]: Stop waiting for response from 1 106ms after last send
03-07-2026, 19:57:12 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:57:12 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:57:13 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:57:28 [W][modbus:063]: Stop waiting for response from 2 116ms after last send
03-07-2026, 19:58:00 [W][component:513]: openquatt_mqtt_publisher took a long time for an operation (81 ms), max is 70 ms
03-07-2026, 19:58:02 [W][component:513]: template.binary_sensor took a long time for an operation (62 ms), max is 50 ms
03-07-2026, 19:58:06 [W][modbus:063]: Stop waiting for response from 1 117ms after last send
03-07-2026, 19:58:20 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 46ms after last send
03-07-2026, 20:27:20 [0;33m[W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 44ms after last send[0m
03-07-2026, 20:27:27 [0;33m[W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 56ms after last send[0m

[ Voor 161% gewijzigd door geerttttt op 04-07-2026 08:26 ]

[jj85]

geerttttt schreef op vrijdag 3 juli 2026 @ 20:22:
Ik heb ondertussen openQuatt geïnstalleerd. Maar om een of andere reden krijgt hij geen data door van de CiC. Iemand een idee? De json feed is handmatig wel te lezen, dus alles lijkt toch goed ingesteld?[Afbeelding]

[Afbeelding]

Misschien is mijn logging relevant?

code:

03-07-2026, 19:50:03 [I][app:117]: setup() finished successfully!
03-07-2026, 19:50:03 [W][component:382]: wifi set Warning flag: scanning for networks
03-07-2026, 19:50:03 [I][app:151]: ESPHome version 2026.6.2 compiled on 2026-07-01 13:30:01 +0000
03-07-2026, 19:50:03 [I][app:153]: Project openquatt.openquatt version v0.39.0
03-07-2026, 19:50:03 [I][app:158]: ESP32 Chip: ESP32-S3 rev0.2, 2 core(s)
03-07-2026, 19:50:03 [W][gpio.one_wire:085]:   Found no devices!
03-07-2026, 19:50:03 [I][supervisory:1341]: ControlMode transition: (unset) -> CM0 (no thermal demand)
03-07-2026, 19:50:04 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 52ms after last send
03-07-2026, 19:50:05 [I][wifi:1097]: Connecting to 'REDACTED (priority 0, attempt 1/2 in phase SCAN_CONNECTING)...
03-07-2026, 19:50:05 [W][component:513]: wifi_signal.sensor took a long time for an operation (62 ms), max is 50 ms
03-07-2026, 19:50:05 [W][wifi_esp32:811]: Disconnected ssid=REDACTED reason='Authentication Failed'
03-07-2026, 19:50:05 [W][wifi:1678]: Connecting to network failed (callback)
03-07-2026, 19:50:05 [I][wifi:1097]: Connecting to 'REDACTED) (priority 0, attempt 2/2 in phase SCAN_CONNECTING)...
03-07-2026, 19:50:06 [I][quatt:644]: Startup inhibit armed for 240s after reboot; compressors remain blocked.
03-07-2026, 19:50:06 [I][quatt.req:802]: Optimizer reason: inactive
03-07-2026, 19:50:06 [I][quatt.req:826]: Request reason: inactive_cm (mode=0 strategy=0 owner=0 topology=0 hp1=0 hp2=0)
03-07-2026, 19:50:06 [W][dallas.temp.sensor:030]:   Unable to select an address
03-07-2026, 19:50:07 [I][wifi:1575]: Connected
03-07-2026, 19:50:07 [W][component:405]: wifi cleared Warning flag
03-07-2026, 19:50:07 [I][quatt.boiler:165]: Boiler blocked: water supply temperature unavailable
03-07-2026, 19:50:11 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 53ms after last send
03-07-2026, 19:50:12 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:50:12 [I][openquatt.cic:184]: CIC fetch task stack high-watermark: 3744 B free
03-07-2026, 19:50:12 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:50:12 [W][component:513]: openquatt_cic took a long time for an operation (53 ms), max is 50 ms
03-07-2026, 19:50:13 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 43ms after last send
03-07-2026, 19:50:13 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:50:13 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 51ms after last send
03-07-2026, 19:50:18 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 46ms after last send
03-07-2026, 19:50:27 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:50:27 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:50:28 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:50:36 [W][modbus:063]: Stop waiting for response from 1 104ms after last send
03-07-2026, 19:50:40 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 48ms after last send
03-07-2026, 19:50:42 [W][component:513]: modbus took a long time for an operation (57 ms), max is 50 ms
03-07-2026, 19:50:42 [W][modbus:063]: Stop waiting for response from 2 122ms after last send
03-07-2026, 19:50:47 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 48ms after last send
03-07-2026, 19:50:52 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:50:52 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:50:53 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:51:02 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 49ms after last send
03-07-2026, 19:51:03 [I][safe_mode:142]: Boot seems successful; resetting boot loop counter
03-07-2026, 19:51:07 [W][component:513]: api took a long time for an operation (55 ms), max is 50 ms
03-07-2026, 19:51:09 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 51ms after last send
03-07-2026, 19:51:17 [I][quatt.cm100:083]: CM100 requested via dashboard (override=Auto task=0 active=0 pending=0)
03-07-2026, 19:51:18 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 59ms after last send
03-07-2026, 19:51:18 [I][quatt.cm100:299]: CM100 request pending while not in CM100; waiting
03-07-2026, 19:51:19 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 57ms after last send
03-07-2026, 19:51:20 [I][supervisory:1341]: ControlMode transition: CM0 -> CM100 (commissioning task active)
03-07-2026, 19:51:23 [I][quatt.cm100:302]: CM100 request accepted; entering neutral commissioning container
03-07-2026, 19:51:37 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:51:37 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:51:38 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:51:38 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 49ms after last send
03-07-2026, 19:51:40 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 56ms after last send
03-07-2026, 19:52:00 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 52ms after last send
03-07-2026, 19:52:08 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 49ms after last send
03-07-2026, 19:52:14 [I][quatt.cm100.hpcal:129]: HP water sensor calibration requested (min_mix=60s stable_window=60s max=300s flow_setpoint=normal spread<=0.35C drift<=0.20C/min max_offset=2.00C)
03-07-2026, 19:52:15 [I][quatt.cm100.hpcal:541]: status=MIXING phase=1 remaining=300s flow=nanL/h spread=nanC stable=0s/60s
03-07-2026, 19:52:17 [I][flow:449]: AUTO start(CM100-task): iPWM=400 (last_good=440 bank=normal fallback=440 commissioning=yes hold 20s, fixed iPWM)
03-07-2026, 19:52:17 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:17 [I][flow:774]: Flow mode changed: AUTO (failsafe) (cm=CM100 manual=0 failsafe=1 hold=4 pwm=850)
03-07-2026, 19:52:22 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:27 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:32 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:35 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 52ms after last send
03-07-2026, 19:52:37 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:42 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:47 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:52 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:52:57 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:02 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:53:02 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:53:02 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:03 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:53:07 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:09 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 45ms after last send
03-07-2026, 19:53:12 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:13 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 50ms after last send
03-07-2026, 19:53:16 [I][quatt.cm100.hpcal:541]: status=MEASURING phase=2 remaining=239s flow=nanL/h spread=nanC stable=0s/60s
03-07-2026, 19:53:17 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:22 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:27 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:32 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:37 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:39 [W][modbus:063]: Stop waiting for response from 2 104ms after last send
03-07-2026, 19:53:41 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 43ms after last send
03-07-2026, 19:53:42 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:47 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:52 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:53:55 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 50ms after last send
03-07-2026, 19:53:57 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:54:02 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:54:07 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:54:08 [I][quatt:657]: Startup inhibit cleared after reboot; compressors may resume.
03-07-2026, 19:54:10 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 45ms after last send
03-07-2026, 19:54:12 [W][flow:487]: Flow PI failsafe engaged: sp=800.0 pv=nan -> forcing iPWM=850
03-07-2026, 19:54:16 [W][component:513]: template.switch took a long time for an operation (64 ms), max is 50 ms
03-07-2026, 19:54:16 [W][modbus:063]: Stop waiting for response from 1 118ms after last send
03-07-2026, 19:54:16 [I][quatt.cm100.hpcal:541]: status=FAILED: no flow detected phase=0 remaining=0s flow=nanL/h spread=nanC stable=0s/60s
03-07-2026, 19:54:40 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 93ms after last send
03-07-2026, 19:55:06 [W][component:513]: template.binary_sensor took a long time for an operation (55 ms), max is 50 ms
03-07-2026, 19:55:07 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:55:07 [I][openquatt.cic:184]: CIC fetch task stack high-watermark: 3684 B free
03-07-2026, 19:55:07 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:55:08 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:55:48 [W][modbus:063]: Stop waiting for response from 2 110ms after last send
03-07-2026, 19:55:55 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 51ms after last send
03-07-2026, 19:56:06 [W][component:513]: openquatt_mqtt_publisher took a long time for an operation (62 ms), max is 50 ms
03-07-2026, 19:56:09 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 50ms after last send
03-07-2026, 19:56:11 [W][modbus:063]: Stop waiting for response from 2 142ms after last send
03-07-2026, 19:56:18 [W][modbus:063]: Stop waiting for response from 2 104ms after last send
03-07-2026, 19:56:36 [W][modbus:417]: Clearing buffer of 2 bytes - timeout after partial response 18ms after last send
03-07-2026, 19:56:36 [W][modbus:063]: Stop waiting for response from 1 105ms after last send
03-07-2026, 19:56:42 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 76ms after last send
03-07-2026, 19:56:47 [W][modbus:063]: Stop waiting for response from 1 114ms after last send
03-07-2026, 19:56:58 [W][component:513]: modbus took a long time for an operation (65 ms), max is 60 ms
03-07-2026, 19:56:58 [W][modbus:063]: Stop waiting for response from 1 129ms after last send
03-07-2026, 19:57:06 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 49ms after last send
03-07-2026, 19:57:10 [W][modbus:063]: Stop waiting for response from 1 106ms after last send
03-07-2026, 19:57:12 [W][openquatt.cic:277][openquatt_cic]: CIC HTTP read failed
03-07-2026, 19:57:12 [E][component:389]: openquatt_cic set Error flag: unspecified
03-07-2026, 19:57:13 [E][component:414]: openquatt_cic cleared Error flag
03-07-2026, 19:57:28 [W][modbus:063]: Stop waiting for response from 2 116ms after last send
03-07-2026, 19:58:00 [W][component:513]: openquatt_mqtt_publisher took a long time for an operation (81 ms), max is 70 ms
03-07-2026, 19:58:02 [W][component:513]: template.binary_sensor took a long time for an operation (62 ms), max is 50 ms
03-07-2026, 19:58:06 [W][modbus:063]: Stop waiting for response from 1 117ms after last send
03-07-2026, 19:58:20 [W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 46ms after last send
03-07-2026, 20:27:20 [0;33m[W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 44ms after last send[0m
03-07-2026, 20:27:27 [0;33m[W][modbus:417]: Clearing buffer of 1 bytes - timeout after partial response 56ms after last send[0m

Apart... even hier ook weer getest en werkt zonder problemen.

Heb je de volledige url ingevoerd in OQ?
http://192.168.1.109:8080/beta/feed/data.json

Zitten beide apparaten op dezelfde wifi/vlan/subnet etc?

[geerttttt]

jj85 schreef op vrijdag 3 juli 2026 @ 21:34:
[...]

Apart... even hier ook weer getest en werkt zonder problemen.

Heb je de volledige url ingevoerd in OQ?
http://192.168.1.109:8080/beta/feed/data.json

Zitten beide apparaten op dezelfde wifi/vlan/subnet etc?

Ja dat allemaal wel. vreemd. Mijn CiC is zowel via wifi als ethernet verbonden, dus heb nu maar ff het ethernet ip geprobeerd. Nu werkt het wel. geen idee waarom. Home assistant is verbonden met quatt via het wifi ip en dat werkt al maanden prima... Nou ja ,het werkt nu.

[CPM]

@geerttttt wel even je CiC hostname/adres verwijderen.

[ Voor 8% gewijzigd door CPM op 03-07-2026 23:45 ]

[geerttttt]

Ok, leuk, hij werkt nu dus en ik zie dat hij momenteel de pomp aan heeft staan. Als het water boven de 20 graden komt gaat hij het koelen zie ik. Leuk! Maar hij moet nu het dauwpunt gokken. Ik zag ergens dat je home assistant sensoren eraan kunt koppelen. Ik heb een tado thermostaat in de kamer die gekoppeld is aan HA. Ik wil graag de luchtvochtigheid daarvan gebruiken voor een betrouwbare dauwpunt berekening. Hoe doe ik dat? Ik zie nergens iets om dat te koppelen...

[jj85]

@geerttttt https://jeroen85.github.io/OpenQuatt/dashboard/index.html

[geerttttt]

jj85 schreef op zaterdag 4 juli 2026 @ 11:58:
@geerttttt https://jeroen85.github.io/OpenQuatt/dashboard/index.html

Ja ik zat dat net te lezen idd. Ik vind het alleen wel vrij verwarrend. Waarom kun je dit niet gewoon in openQuatt instellen en wat heeft dat met een HA dashboard te maken...

[jj85]

geerttttt schreef op zaterdag 4 juli 2026 @ 12:50:
[...]

Ja ik zat dat net te lezen idd. Ik vind het alleen wel vrij verwarrend. Waarom kun je dit niet gewoon in openQuatt instellen en wat heeft dat met een HA dashboard te maken...

Hoe wil je die HA meting in OpenQuatt krijgen dan? Tips zijn welkom

[zeekoe]

geerttttt schreef op zaterdag 4 juli 2026 @ 12:50:
[...]

Ja ik zat dat net te lezen idd. Ik vind het alleen wel vrij verwarrend. Waarom kun je dit niet gewoon in openQuatt instellen en wat heeft dat met een HA dashboard te maken...

Houd er rekening mee dat OpenQuatt een (uit de hand gelopen?) hobbyproject is, en dat niet alles (al) kan. Het is open source, dus van alles is te bouwen. Als je terug leest, zijn er ideeën om gegevens van het KNMI erin te krijgen, maar dat is nog niet gedaan.

[Ferdinand Oeinck]

jj85 schreef op zaterdag 4 juli 2026 @ 13:04:
[...]

Hoe wil je die HA meting in OpenQuatt krijgen dan? Tips zijn welkom

Post Rest API implementeren

[jj85]

Ferdinand Oeinck schreef op zaterdag 4 juli 2026 @ 16:19:
[...]

Post Rest API implementeren

Wat is het voordeel tov de standaard esphome/HA API?

[Ferdinand Oeinck]

jj85 schreef op zaterdag 4 juli 2026 @ 16:35:
[...]

Wat is het voordeel tov de standaard esphome/HA API?

Of deze: https://esphome.io/components/sensor/homeassistant/

[jj85]

Ferdinand Oeinck schreef op zaterdag 4 juli 2026 @ 17:20:
[...]

Of deze: https://esphome.io/components/sensor/homeassistant/

Dat is precies de route die gevolgd wordt

[jj85]

@geerttttt @Ferdinand Oeinck zo werkt het nu

[onlinaius]

jj85 schreef op zaterdag 4 juli 2026 @ 18:44:
@geerttttt @Ferdinand Oeinck zo werkt het nu

[Afbeelding]

Ik kan niet wachten om het te gaan proberen! (maar doe dat toch maar even, op de hardware van @leejoow )

[jj85]

Voor de gebruikers zonder HA; er komt tzt ook een optie bij om via MQTT een dauwpunt (en straks nog wel wat meer sensoren, ik denk aan thermostaat setpoint en kamertemperatuur) te publiceren naar OpenQuatt.
Bijv nuttig voor Homey gebruikers :-)





Edit: nu te testen via dev-kanaal (OTA update)

[ Voor 5% gewijzigd door jj85 op 05-07-2026 20:48 ]

[geerttttt]

Zou het bijna jammer vinden dat het nu geen 28+ graden is... Ben benieuwd hoe goed het koelen werkt. Wel bijzonder dat de dauwpunt ondergrens bij mij nu 12.6 graden is. Dat is toch vrij laag!

[m10tech]

Ook nu kun je koelen natuurlijk, maar ik vrees dat je huisgenoten hebt die het daar niet mee eens zijn.

In mijn opstelling heb ik een staande ventilator in het midden van de kamer met vloerverwarming gelegd zodat die koelte oppikte en naar boven blies. Dat is natuurlijk behelpen, maar met nietsdoen krijg je eigenlijk alleen maar koude voeten.

Boven had ik twee radiatoren met fans, die ik aan heb gezet. Alle andere radiatoren heb ik dichtgedraaid.

Over dat dauwpunt: hoeveel luchtvochtigheid heb je dan? En hoe warm is het op het meetpunt?

[jj85]

geerttttt schreef op zondag 5 juli 2026 @ 17:56:
Zou het bijna jammer vinden dat het nu geen 28+ graden is... Ben benieuwd hoe goed het koelen werkt. Wel bijzonder dat de dauwpunt ondergrens bij mij nu 12.6 graden is. Dat is toch vrij laag!

Hoe is die 12,6 bepaald? Is idd wel aan de lage kant wellicht

[geerttttt]

jj85 schreef op zondag 5 juli 2026 @ 18:22:
[...]

Hoe is die 12,6 bepaald? Is idd wel aan de lage kant wellicht

21,7 graden met 49% luchtvochtigheid. gemeten vanaf mijn tado thermostaat in de woonkamer.

[m10tech]

Dat klopt wel ongeveer, maar wel speciaal dat het zo 'droog' is bij jou.
Hier heb ik 66%

[geerttttt]

m10tech schreef op zondag 5 juli 2026 @ 18:37:
Dat klopt wel ongeveer, maar wel speciaal dat het zo 'droog' is bij jou.
Hier heb ik 66%

Ik heb ook een split unit airco, die draait op laag vermogen in deze weken eigenlijk 24/7. Vandaar denk ik dan.

[m10tech]

Wat natuurlijk de vraag opwerpt waarom je dan nog via OpenQuatt wil koelen.
Nieuwsgierigheid is natuurlijk een goed antwoord ;-)

[geerttttt]

m10tech schreef op zondag 5 juli 2026 @ 18:45:
Wat natuurlijk de vraag opwerpt waarom je dan nog via OpenQuatt wil koelen.
Nieuwsgierigheid is natuurlijk een goed antwoord ;-)

Mijn airco hangt in de hal. Dus het is niet super hard nodig, toch is het in de hal en boven een stuk koeler dan beneden. Mijn hele benedenverdieping is tegels met vloerverwarming, dus de systemen zouden elkaar goed kunnen aanvullen.

Vraag me ook af welk systeem efficiënter is. Mijn airco verbruikt op maximale stand 1500-1600 watt.

En daarnaast idd nieuwsgierigheid haha

[ Voor 3% gewijzigd door geerttttt op 05-07-2026 19:01 ]

[timmert26]

jj85 schreef op zondag 5 juli 2026 @ 16:27:
Voor de gebruikers zonder HA; er komt tzt ook een optie bij om via MQTT een dauwpunt (en straks nog wel wat meer sensoren, ik denk aan thermostaat setpoint en kamertemperatuur) te publiceren naar OpenQuatt.
Bijv nuttig voor Homey gebruikers :-)

[Afbeelding]

[Afbeelding]

Edit: nu te testen via dev-kanaal (OTA update)

Kun je die dauwpunt waardes ook uit een TADO halen? Die hebben zowel temperatuur- als luchtvochtigheidssensoren. Of moeten ze echt buiten hangen?

[jj85]

timmert26 schreef op maandag 6 juli 2026 @ 07:36:
[...]

Kun je die dauwpunt waardes ook uit een TADO halen? Die hebben zowel temperatuur- als luchtvochtigheidssensoren. Of moeten ze echt buiten hangen?

Gaat juist om dauwpunt binnen

[timmert26]

jj85 schreef op maandag 6 juli 2026 @ 08:02:
[...]

Gaat juist om dauwpunt binnen

80% van de gebruikers zal vast een TADO/honeywell T6 gebruiken (die laatste wordt immers door Quatt aangeraden). Deze voed in ieder geval de temperatuur naar de ketel, geeft die ook de luchtvochtigheidwaardes door? Als je die buiten HA zou kunnen binnenhalen in openquatt heb je de grootste doelgroep denk ik al gedekt.

[Trackerfire]

timmert26 schreef op maandag 6 juli 2026 @ 08:07:
[...]

80% van de gebruikers zal vast een TADO/honeywell T6 gebruiken (die laatste wordt immers door Quatt aangeraden). Deze voed in ieder geval de temperatuur naar de ketel, geeft die ook de luchtvochtigheidwaardes door? Als je die buiten HA zou kunnen binnenhalen in openquatt heb je de grootste doelgroep denk ik al gedekt.

100%, maar niet heel veel kans dat die mee wordt gestuurd (denk ik). Misschien ook wel een van de redenen waarom de koeling (nog) niet standaard aan gaat/mag/kan bij Quatt.

[jj85]

Trackerfire schreef op maandag 6 juli 2026 @ 08:28:
[...]

100%, maar niet heel veel kans dat die mee wordt gestuurd (denk ik). Misschien ook wel een van de redenen waarom de koeling (nog) niet standaard aan gaat/mag/kan bij Quatt.

Ik vermoed dat de Quatt strategie gaat zijn als ze ooit vloerkoeling gaan activeren: gebruikers voorzien van een temp/hum (of dauwpunt) meting via Thread.

[jj85]

timmert26 schreef op maandag 6 juli 2026 @ 08:07:
[...]

80% van de gebruikers zal vast een TADO/honeywell T6 gebruiken (die laatste wordt immers door Quatt aangeraden). Deze voed in ieder geval de temperatuur naar de ketel, geeft die ook de luchtvochtigheidwaardes door? Als je die buiten HA zou kunnen binnenhalen in openquatt heb je de grootste doelgroep denk ik al gedekt.

T6 geeft enkel temp door. Van Tado weet ik het niet. Ik denk dat dauwpunt / humidity ook niet in de OpenTherm standaard zit trouwens...
Was anders ideaal geweest natuurlijk.

Vergeet echter niet dat het zinvol kan zijn om dauwpunt in meerdere ruimte te meten.
Woonkamer kan prima een dauwpunt van bijv 18grC hebben, terwijl een zolder bijv op 21grC zit. Als je dan 19grC water door je leiding drukt, dan kan je alsnog condensatie krijgen op zolder.

[timmert26]

jj85 schreef op maandag 6 juli 2026 @ 09:10:
[...]
T6 geeft enkel temp door. Van Tado weet ik het niet. Ik denk dat dauwpunt / humidity ook niet in de OpenTherm standaard zit trouwens...
Was anders ideaal geweest natuurlijk.

Vergeet echter niet dat het zinvol kan zijn om dauwpunt in meerdere ruimte te meten.
Woonkamer kan prima een dauwpunt van bijv 18grC hebben, terwijl een zolder bijv op 21grC zit. Als je dan 19grC water door je leiding drukt, dan kan je alsnog condensatie krijgen op zolder.

Daarom zouden juist slimme-radiator knoppen ideaal zijn als sensoren. Dan heb je per ruimte de temperatuur + humidity. Allicht iets om ooit te overwegen :-). Anders daarvoor ooit maar HA in elkaar flansen

[HGBMason]

Afhankelijk van instellingen geeft Tado (in elk geval Tado X) de vochtigheidsgraad weer per radiatorthermostaat of per ruimte.

[jj85]

@timmert26 @HGBMason Enig idee hoe je die info uit de Tado in OpenQuatt kunt krijgen?

[RickvdT]

Tado V3+ kan als HomeKit device lokaal data beschikbaar stellen. Hier is al best veel voor beschikbaar. Bijv. AmpScm/TadoLocal: Tado Local - Manage TADO devices locally

Tado X als het goed is via Matter over Thread. Dat wordt al ingewikkelder

[timmert26]

jj85 schreef op maandag 6 juli 2026 @ 10:29:
@timmert26 @HGBMason Enig idee hoe je die info uit de Tado in OpenQuatt kunt krijgen?

TADO heeft een REST API die met de gratis versie 100 verzoeken per dag toestaat.
How do I authenticate to access the REST API? | Help Center for tado° V3+ and earlier devices

[joosie]

Met de beta versie die sinds gisteravond beschikbaar is kun je het dauwpunt via MQTT publiceren. Ik heb het via Homey gedaan met de waardes van mijn Tado Thermostaat, voor degenen die op zoek zijn, hierbij mijn flow en code:

const device = await Homey.devices.getDevice({ id: 'ID_VAN_JE_THERMOSTAAT' });
const T = device.capabilitiesObj.measure_temperature.value;
const RH = device.capabilitiesObj.measure_humidity.value;
const a = 17.625, b = 243.04;
const alpha = Math.log(RH / 100) + (a * T) / (b + T);
const dewpoint = (b * alpha) / (a - alpha);
return Math.round(dewpoint * 10) / 10;

[jj85]

joosie schreef op maandag 6 juli 2026 @ 11:25:
Met de beta versie die sinds gisteravond beschikbaar is kun je het dauwpunt via MQTT publiceren. Ik heb het via Homey gedaan met de waardes van mijn Tado Thermostaat, voor degenen die op zoek zijn, hierbij mijn flow en code:

[Afbeelding]

const device = await Homey.devices.getDevice({ id: 'ID_VAN_JE_THERMOSTAAT' });
const T = device.capabilitiesObj.measure_temperature.value;
const RH = device.capabilitiesObj.measure_humidity.value;
const a = 17.625, b = 243.04;
const alpha = Math.log(RH / 100) + (a * T) / (b + T);
const dewpoint = (b * alpha) / (a - alpha);
return Math.round(dewpoint * 10) / 10;

Cool! (pun intended )
Bij meerdere dauwpunten is het overigens wijs om de hoogste waarde dan door te sturen aan OpenQuatt

[jj85]

jj85 schreef op zondag 5 juli 2026 @ 16:27:
Voor de gebruikers zonder HA; er komt tzt ook een optie bij om via MQTT een dauwpunt (en straks nog wel wat meer sensoren, ik denk aan thermostaat setpoint en kamertemperatuur) te publiceren naar OpenQuatt.
Bijv nuttig voor Homey gebruikers :-)

[Afbeelding]

[Afbeelding]

Edit: nu te testen via dev-kanaal (OTA update)

De keuze wordt reuze

[HGBMason]

jj85 schreef op maandag 6 juli 2026 @ 10:29:
@timmert26 @HGBMason Enig idee hoe je die info uit de Tado in OpenQuatt kunt krijgen?

Voor Tado X is er de integratie via Matter of de Tado Hijack via Hacs in HA om de gegervens uit te lezen.

[geerttttt]

jj85 schreef op maandag 6 juli 2026 @ 08:43:
[...]

Ik vermoed dat de Quatt strategie gaat zijn als ze ooit vloerkoeling gaan activeren: gebruikers voorzien van een temp/hum (of dauwpunt) meting via Thread.

Ik denk dat Quatt gewoon 18 graden als minimum instelt en niet lager wil dan dat. Evt kunnen ze nog de binnentemp gebruiken voor een beetje een schatting, maar ze zullen denk ik heel voorzichtig zijn, deels omdat ze dus niet exact het dauwpunt kunnen berekenen, en deels omdat ze liever de Chill verkopen.

Nu zegt een consument "Kies ik Quatt met een Chill? Of een andere warmtepomp die vloerkoeling aan kan? Vloerkoeling is goedkoper, Quatt Chill is wat effectiever...".
Straks is de logische keuze "Eerst maar eens vloerkoeling proberen, Quatt Chill kan ik dan altijd nog kopen als uitbreiding". Dus is het voor Quatt ook helemaal niet erg als vloerkoeling maar beperkt effect heeft.

[faberr]

jj85 schreef op vrijdag 29 mei 2026 @ 17:12:
@marsman
Bij de CiC haal je de drie draden los die hieronder aangegeven staan (in mijn foto is GND (groen) niet aangesloten). Kijk even welke kleur draad hier onder A en B is aangesloten. Als het goed is Rood op A en Blauw op B.
[Afbeelding]

Steek de draden vervolgens in de Waveshare
Rood op A en Blauw op B.
[Afbeelding]

Dat zou het moeten zijn

Misschien domme vraag maar wat zit hier dan op de relay? Welke draadjes zijn dat. 😅

[jj85]

faberr schreef op maandag 6 juli 2026 @ 20:47:
[...]

Misschien domme vraag maar wat zit hier dan op de relay? Welke draadjes zijn dat. 😅

M'n doorstroomverwarmer (of je aan/uit ketel)

[faberr]

Ah, die heb ik niet. Inmiddels wel alle stappen doorlopen en het systeem is nu actief aan het koelen. De komende dagen ga ik kijken wat het brengt en ik houd het dauwpunt nauwlettend in de gaten. Mocht de aanvoer te koud staan, dan verwacht ik de eerste condens bij de verdeler en de eerste stukken aanvoerleiding, dus daar let ik als eerste op.

Verder een compliment: de installatie was erg makkelijk en het systeem is prettig stap voor stap te doorlopen. Ziet er allemaal echt netjes uit!

[geerttttt]

Ok, ik heb een extra reden bedacht waarom extra koelen met een WP voor mij slim is, ik heb een dynamisch contract. Mijn stroom is niet veel waard overdag... Dus overdag ga ik mooi extra koelen.

Goed, dat test ik nu dus, het is toch immers 25-26 graden buiten. Maar ik zie nu de hele dag al dit gedrag:


Voor mijn gevoel is dit vreemd en niet effectief. Dit zijn mijn koelgegevens:

code:

Kamertemperatuur: 21.76 °C
Kamer setpoint: 5.00 °C
Aanvoertemperatuur :18.09 °C
Koeldoel: 18.0 °C
Veilige aanvoergrens: 14.08 °C
Dauwpunt :12.08 °C

Kan iemand dit verklaren? Of doe ik iets fout?

[jj85]

@geerttttt zet iig de min watertemp omlaag, die staat nu denk ik op 18grC. Dan stopt hij met koelen zodra hij die 18grC bereikt heeft. Terwijl je eigenlijk tot 12 door zou kunnen.
Je zou ook nog de Dauwpunt veiligheidsmarge kunnen verlagen, die heb je nu op 2 staan, kan ook naar 1, 0,5 of zelfs 0 misschien.

[jj85]

btw, er is ook een Discord kanaaltje. https://discord.gg/tXza4xd25k
Werkt soms net wat makkelijker voor dit soort zaken (en houdt dit topic wat 'schoner')

[geerttttt]

jj85 schreef op maandag 6 juli 2026 @ 22:13:
btw, er is ook een Discord kanaaltje. https://discord.gg/tXza4xd25k
Werkt soms net wat makkelijker voor dit soort zaken (en houdt dit topic wat 'schoner')

Ah ik zal daar ook heen gaan. Heb nu in ieder geval het koeldoel verlaagd, dat helpt inderdaad. Maar ik bedenk me nu net ook waarom het bij mij zo snel wisselt qua watertemperatuur... Ik heb een pompschakelaar die pas de vloerverwarming pomp activeert bij temperaturen rond 28+ graden ofzo.

Dus het water wordt nu neem ik aan slechts rondgepompt door mijn radiatoren (die wellicht ook dicht staan omdat het thermostaatknoppen zijn) en wat buizen... Daar zal ik wat op moeten bedenken dan.

[jj85]

jj85 schreef op maandag 6 juli 2026 @ 22:10:
@geerttttt zet iig de min watertemp omlaag, die staat nu denk ik op 18grC. Dan stopt hij met koelen zodra hij die 18grC bereikt heeft. Terwijl je eigenlijk tot 12 door zou kunnen.
Je zou ook nog de Dauwpunt veiligheidsmarge kunnen verlagen, die heb je nu op 2 staan, kan ook naar 1, 0,5 of zelfs 0 misschien.
[Afbeelding]

Ik heb de defaultwaarden hiervoor ook wat verlaagd, anders gaan we deze vraag waarschijnlijk heel vaak krijgen

[onlinaius]

geerttttt schreef op dinsdag 7 juli 2026 @ 08:56:
[...]

Ah ik zal daar ook heen gaan. Heb nu in ieder geval het koeldoel verlaagd, dat helpt inderdaad. Maar ik bedenk me nu net ook waarom het bij mij zo snel wisselt qua watertemperatuur... Ik heb een pompschakelaar die pas de vloerverwarming pomp activeert bij temperaturen rond 28+ graden ofzo.

Dus het water wordt nu neem ik aan slechts rondgepompt door mijn radiatoren (die wellicht ook dicht staan omdat het thermostaatknoppen zijn) en wat buizen... Daar zal ik wat op moeten bedenken dan.

Wat zie je voor flow? Verandert deze als je bijv 1 radiator dicht draait?

Ik zie namelijk bij mijzelf dat een VVW pomp wel invloed heeft op de flow, maar ook weer niet zo heel erg veel. Het zal mij verbazen als zonder de pomp er helemaal niets door de VVW heen gaat.

[geerttttt]

onlinaius schreef op dinsdag 7 juli 2026 @ 14:06:
[...]

Wat zie je voor flow? Verandert deze als je bijv 1 radiator dicht draait?

Ik zie namelijk bij mijzelf dat een VVW pomp wel invloed heeft op de flow, maar ook weer niet zo heel erg veel. Het zal mij verbazen als zonder de pomp er helemaal niets door de VVW heen gaat.

De flow is bij mij eigenlijk altijd erg stabiel rond de 800

[onlinaius]

geerttttt schreef op dinsdag 7 juli 2026 @ 14:31:
[...]

De flow is bij mij eigenlijk altijd erg stabiel rond de 800

Afhankelijk van hoeveel radiatoren er open staan zou het me niet verbazen als daarvan nog een aanzienlijk deel door de VVW gaat, ook als de pomp uitstaat.

Heb je een infrarood thermometer? Dan zou je eens kunnen kijken wat de temperatuur van de uitgaande en inkomende buizen zijn terwijl je aan het koelen bent, en terwijl de pomp uitstaat. Als retour dezelfde temp heeft als inkomend is er geen flow, is retour warmer dan gaat er dus water door de VVW.

[jj85]

Korte waarschuwing voor wie met koelbedrijf test: ik zou voorzichtig zijn met het verlagen van de minimale compressorfrequentie onder de standaardwaarde.
Ik heb mijn Quatt v1.5 met R32 in koelstand gelogd. Bij lage frequenties, vooral rond 26-30 Hz, bleef de suction superheat langdurig erg laag: vaak rond 0-0,5 K en veel tijd onder 2 K. Dat betekent weinig marge dat het koudemiddel volledig verdampt is voordat het terug richting compressor gaat.
Dat is niet meteen een acute storing, maar langdurig natte zuigretour kan op termijn ongunstig zijn voor compressor en smering. Mijn advies: zet level 1 in koelbedrijf niet zomaar lager naar 20-23 Hz zonder superheat-monitoring. De standaard 30 Hz lijkt al aan de natte kant; lager kan het risico vergroten.

[harv]

jj85 schreef op dinsdag 7 juli 2026 @ 17:36:
Korte waarschuwing voor wie met koelbedrijf test: ik zou voorzichtig zijn met het verlagen van de minimale compressorfrequentie onder de standaardwaarde.
Ik heb mijn Quatt v1.5 met R32 in koelstand gelogd. Bij lage frequenties, vooral rond 26-30 Hz, bleef de suction superheat langdurig erg laag: vaak rond 0-0,5 K en veel tijd onder 2 K. Dat betekent weinig marge dat het koudemiddel volledig verdampt is voordat het terug richting compressor gaat.
Dat is niet meteen een acute storing, maar langdurig natte zuigretour kan op termijn ongunstig zijn voor compressor en smering. Mijn advies: zet level 1 in koelbedrijf niet zomaar lager naar 20-23 Hz zonder superheat-monitoring. De standaard 30 Hz lijkt al aan de natte kant; lager kan het risico vergroten.

@jj85

Ik heb geen huis voor chill, koeling, huisbatterij enz. Ik hou het bij de eerste opzet van Quatt; verwarmen met 1 of twee quatts, in mijn geval 2 x versie 1.5. Sinds er steeds meer vergezichten ontstaan, begin ik de boot bij Quatt een beetje te missen. Steeds meer updates, steeds meer correctie updates, steeds meer problemen met technische installatie, lijkt het vanuit Quatt.

En dat begint een heel klein beetje nu ook Open Quatt te raken. Eigenlijk wil je alles wat Quatt in de markt gooit verbeteren, de problemen van Quatt oplossen. En dat lukt ook niet altijd, niet altijd lukt het direct in te springen op elke wijziging/vernieuwing/correctie die Quatt invoert. Zeker ook omdat Quatt zeer gesloten is, terwijl het ook maar een start-up is.

Zorg dus vooral dat Open Quatt erboven staat, ken je grenzen, zorg dat wat Open Quatt aanbiedt altijd werkt en geen schade kan veroorzaken.

En dus ook complimenten, dat je verkeerde verbeteringen gewoon aangeeft hier bij Tweakers, en niet zoals bij Quatt er de volgende update overheen gooit.

Ik ben blij dat Open Quatt aanbiedt alle mogelijkheden in- en uit te schakelen, en zo te kunnen voorkomen dat verkeerde software je installatie negatief beinvloedt. Ik ben benieuwd wanneer de "definitieve"?? versie van Open Quatt het licht ziet, om dat te gaan proberen! Succes!!

[m10tech]

De waarschuwing bij het veranderen van compressorfrequenties is anders duidelijk zat...
"Gebruik dit alleen voor gecontroleerde tests."

[jj85]

harv schreef op dinsdag 7 juli 2026 @ 18:08:
[...]


Zorg dus vooral dat Open Quatt erboven staat, ken je grenzen, zorg dat wat Open Quatt aanbiedt altijd werkt en geen schade kan veroorzaken.

Dat kan ik niet garanderen.

En dus ook complimenten, dat je verkeerde verbeteringen gewoon aangeeft hier bij Tweakers, en niet zoals bij Quatt er de volgende update overheen gooit.

Ik zie het zelf niet als verkeerde verbetering ;-)
Enkel de waarschuwing; ga niet te laag met je frequentie, daarvan zijn de gevolgen momenteel niet volledig helder.
De mogelijkheid om zelf frequenties toe te kennen blijft wel prettig.
Nu ga ik koelen op 30, 32, 34, 36, 38 Hz etc ipv 30, 36, 42, 47 Hz etc. Dat geeft een veel rustiger beeld.

Ik ben blij dat Open Quatt aanbiedt alle mogelijkheden in- en uit te schakelen, en zo te kunnen voorkomen dat verkeerde software je installatie negatief beinvloedt. Ik ben benieuwd wanneer de "definitieve"?? versie van Open Quatt het licht ziet, om dat te gaan proberen! Succes!!

Er zal wellicht nooit een echt definitieve versie zijn Het blijft nog wel even doorpruttelen.

[TalkingCarrot]

Mooi om alle ontwikkelingen te zien! Ik heb me ook al aangemeld voor interesse voor de te ontwikkelen boards.

Hebben we enig verwachting wanneer de eerste batch af is? Anders bestel ik alvast een Waveshare voor de time being, maar helaas heeft deze ook een paar weken levertijd.

Anyway, keep up the good work! Echt tof om hier straks mee aan de slag te gaan.

[leejoow]

Deze week verwacht ik de prototypes die we besteld hebben waarin een tweetal problemen van het eerste bord zijn opgelost. Als deze goed werken dan verwacht ik dat we kunnen bestellen. Qua hardware heb ik er in elk geval een goed gevoel over!

[timmert26]

leejoow schreef op woensdag 8 juli 2026 @ 07:14:
Deze week verwacht ik de prototypes die we besteld hebben waarin een tweetal problemen van het eerste bord zijn opgelost. Als deze goed werken dan verwacht ik dat we kunnen bestellen. Qua hardware heb ik er in elk geval een goed gevoel over!

Als dit straks klaar is, is dat toch eigenlijk een tweakers artikel waardig. Het feit dat je volledig de software en hardware van, in dit geval een warmtepomp, zelf ontwikkeld vanuit een communicty perspectief. Alles tot in den treure hebt moeten uitzoeken met weinig tot geen support en alles zo goed voor elkaar hebt gekregen, dat is uiteindelijk waar tweakers (ooit) om draaide!

Misschien staat er wel een redacteur ergens in de startblokken als jullie straks zover zijn

[jj85]

Sneak peak: OpenQuatt Beslislog

Poging om inzichtelijk te maken waarom OpenQuatt bepaalde keuzes maakt.

• Waarom gaat vorstbescherming aan.
• Waarom gaat een duo-setup van HP1+HP2 draaien of enkel HP1
• Waarom schakelt de CV bij
• Waarom stopt het koelen (dauwpuntbewaking etc)
• etc etc

Edit; wat later vandaag even koelen aangezet.

Binnenkort op het dev-kanaal beschikbaar

[ Voor 25% gewijzigd door jj85 op 09-07-2026 20:57 ]

[MrPunchinello]

Iemand al bezig/ervaring met het koelen via een Quatt warmtepomp? Ben zelf nog niet in de open Quatt materie gedoken maar valt me tegen dat Quatt zelf dit niet toelaat.

[jj85]

MrPunchinello schreef op donderdag 9 juli 2026 @ 18:08:
Iemand al bezig/ervaring met het koelen via een Quatt warmtepomp? Ben zelf nog niet in de open Quatt materie gedoken maar valt me tegen dat Quatt zelf dit niet toelaat.

Ja, lees dit topic zou ik zeggen. Zoek desnoods even op koelen

[MrPunchinello]

jj85 schreef op donderdag 9 juli 2026 @ 18:31:
[...]

Ja, lees dit topic zou ik zeggen. Zoek desnoods even op koelen

Ja inmiddels aardig door het topic heen aan het lezen maar holy moly ik heb nog een lange weg te gaan.

[AliExpres]

MrPunchinello schreef op donderdag 9 juli 2026 @ 18:08:
Iemand al bezig/ervaring met het koelen via een Quatt warmtepomp? Ben zelf nog niet in de open Quatt materie gedoken maar valt me tegen dat Quatt zelf dit niet toelaat.

Quatt heeft bij de lancering jaren geleden al aangekondigd dat koelen met de Quatt warmtepomp mogelijk zal zijn.

Meer recent na heel veel aandringen heeft Quatt toegezegd dat koelen voor alle gebruikers zal worden toegevoegd, nadat Quatt product ontwikkelaars met de huidige Quatt uitbreidingen zoals Chill, Heatcharger etc gereed zijn.

Met het OpenQuatt project werd snel duidelijk dat de Quatt buitenunit laten koelen ipv verwarmen een eenvoudige handeling in de aansturing vraagt. De correcte aansturing voor koelen zodat de warmtepomp met de juiste temperatuur en compressorkracht koelt vraagt meer aandacht.

OpenQuatt is een open source project door en voor Quatt gebruikers.

Doe mee met OpenQuatt en laat jouw Quatt warmtepomp deze zomer jouw huis koelen!

[ Voor 3% gewijzigd door AliExpres op 10-07-2026 13:46 ]

[memorynl]

jj85 schreef op dinsdag 7 juli 2026 @ 17:36:
Korte waarschuwing voor wie met koelbedrijf test: ik zou voorzichtig zijn met het verlagen van de minimale compressorfrequentie onder de standaardwaarde.
Ik heb mijn Quatt v1.5 met R32 in koelstand gelogd. Bij lage frequenties, vooral rond 26-30 Hz, bleef de suction superheat langdurig erg laag: vaak rond 0-0,5 K en veel tijd onder 2 K. Dat betekent weinig marge dat het koudemiddel volledig verdampt is voordat het terug richting compressor gaat.
Dat is niet meteen een acute storing, maar langdurig natte zuigretour kan op termijn ongunstig zijn voor compressor en smering. Mijn advies: zet level 1 in koelbedrijf niet zomaar lager naar 20-23 Hz zonder superheat-monitoring. De standaard 30 Hz lijkt al aan de natte kant; lager kan het risico vergroten.

De bovenstaande waarschuwing van @jj85 heeft mij aan het denken gezet (en voorlopig het koelen even uitgezet ). Ik deel graag een aantal dingen met jullie, met de intentie om samen verder te komen, zodat we straks weten onder welke voorwaarden 'veilig' koelen mogelijk is.
Want hoewel ik wat dingen geleerd heb (ja, met Claude-hulp, maar ik neem zeker niet zomaar alles aan), mis ik de intuïtie die een expert op dit gebied heeft. Dus alle discussie is welkom.

Als eerste gaan we kijken naar die superheat. Dat is voor de compressor relevant, want er moet R32 (in mijn V1 in elk geval) in GASVORM doorheen. Als de R32 vloeibaar is gaat de compressor sneller slijten of simpelweg stuk, daar is het ding niet voor gemaakt. Het is dus belangrijk dat de R32 in gasvorm blijft, ofwel het moet heter zijn dan het kookpunt/condensatiepunt (want anders wordt het vloeibaar). Hoeveel heter het gas is, noemen we "superheat", en blijkbaar is het gezond om daar wat marge in te hebben, ergens tussen de 5-10 graden (Kelvin of Celsius maakt niet uit, het gaat om de delta).

Maar dat doet onze (althans mijn V1) Quatt niet zomaar:
Gisteren heb ik een cooling-run gedaan op 30 Hz, in dit plaatje zie je over een half uur tijd de "superheat" (het verschil tussen die twee dus). Na het opstarten (1:08) zie je een flinke marge, maar daarna neemt de superheat langzaam af naar een graadje of een half . Dat lijkt geen lekkere marge.


Maar toch interessant, dacht ik, waarom start hij dan wel lekker? En hij wordt ook niet negatief, hoe dan? Lijkt wel alsof de Quatt dit expres doet, nietwaar? En hoe doet de Quatt dat dan als er een Chill aan hangt? De ODU is dan exact hetzelfde.

Na wat graven kom ik er dan achter dat "moderne" EEV-pompen (Electronic Expansion Valve) inderdaad zouden moeten kunnen werken met een veel lagere superheat. Er is namelijk ook een hogere efficiency mogelijk door strak te sturen op een lage superheat. (In het kort: R32-vloeistof "koken" is efficiëntere energieoverdracht dan R32-gas verder verhitten, en minder superheat = minder "verder verhitten" en "meer koken"). En dat doet o.a. de EEV.
Daar hoort dan ook een ander veiligheidsmechanisme bij; door te kijken naar (plotselinge afwijkingen in) de "discharge temperature" (de output-kant van de compressor) kan de EEV-controller dit blijkbaar zo strak sturen als hij doet. En volgens Claude was de 46 graden discharge temp die ik gisteren stabiel had "healthy".

Onder de streep ben ik iets hoopvoller geworden t.a.v. de geobserveerde lage superheat values. Maar nog wel werk aan de winkel voordat ik "veilig" durf te koelen. Dus het eerdere advies is nog steeds van kracht!

Op dit punt ben ik gestopt. Ik heb nog geen literatuur bekeken hierover, en nog niet veel verder gedoken in wat dan "healthy" is.
Tevens heb ik geen Chill, dus als iemand die heeft zou ik heel benieuwd zijn wat die doet tijdens koelen (compressor-frequentie, superheat values, discharge temperature, etc).

Nog een paar simpele observaties ter referentie:

• de gemeten pressure waarden zijn in gauge-bar
• de door de UDO-gerapporteerde "evaporating temperature" is nauwkeurig
• de namen van de sensoren in HA zijn gebaseerd op verwarmings-modus. In cooling-mode kloppen evaporator_pressure en condenser_pressure wel, maar evaporator_coil_temperature meet dan de temp van de "condensing" en inner_coil_temperature meet de temp van "evaporating". (Het duurde even voordat we de klik gemaakt hadden hier ).

[jj85]

@memorynl Dank voor je analyse. Het zit mij ook niet helemaal lekker... ook op die 30Hz niet

Nu ook op 0 of soms er iets onder..

[jj85]

@memorynl Wat aanvullend onderzoek
Ik heb dit inmiddels verder uitgezocht aan de hand van het Modbus-protocol en de historydata. De drukregisters van de Quatt gedragen zich als barg, niet als bara. De schaal 0–600 betekent daarbij 0–60,0 bar.

Dat is ook te controleren met de door de Quatt berekende verdampingstemperatuur. Bij 12,2 barg is de absolute druk ongeveer 13,21 bara. Voor R32 hoort daar een verzadigingstemperatuur van circa 16,1 °C bij. Dat komt redelijk overeen met de 16,7 °C die de Quatt zelf rapporteert. Wanneer 12,2 bar als absolute druk wordt geïnterpreteerd, zou de verzadigingstemperatuur slechts ongeveer 13,3 °C zijn; dat past duidelijk niet bij de overige waarden.

Op het betreffende moment was de gasretourtemperatuur 16,63 °C. De onafhankelijk berekende superheat is daarmee ongeveer:

16,63−16,09=0,54K

De Quatt zelf toont ongeveer −0,1 K, omdat hij de gasretourtemperatuur aftrekt van zijn intern berekende verdampingstemperatuur van 16,72 °C. Praktisch zou ik daarom niet zeggen dat de superheat exact negatief is, maar dat hij ergens rond 0–1 K ligt. Dat is nog steeds erg laag.

Het verschil van circa 0,6 K tussen de Quatt-berekening en de onafhankelijke R32-berekening lijkt structureel uit de interne druk-temperatuurconversie in de buitenunit te komen.

Met andere woorden: superheat berekend met de Quatt-ODU temp-waarden lijken wat te conservatief te zijn t.o.v. R32 diagrammen.




Als je naar EEV data kijkt, dan is die ook nog niet uitgeregeld. Het systeem lijkt idd bewust op een hele lage superheat te sturen...

[ Voor 13% gewijzigd door jj85 op 11-07-2026 17:26 ]

[TeslaNerd]

De druk wordt mogelijk niet met een druksensor gemeten maar afgeleid van de temperatuur

Oeps, het is net andersom:

De warmtepomp gebruikt de gemeten druk om de verzadigingstemperatuur (het kookpunt/condensatiepunt) van het koudemiddel te berekenen via een ingebouwde koudemiddeltabel. De computer doet dus het omgekeerde: hij meet de druk en berekent daaruit de theoretische temperatuur.

[ Voor 70% gewijzigd door TeslaNerd op 11-07-2026 18:23 ]

[m10tech]

Ik wilde net laten zien dat er druksensoren zijn aangesloten in de ODU...
Goed dat ik even refresh deed...

[ Voor 60% gewijzigd door m10tech op 11-07-2026 18:31 ]

[TeslaNerd]

m10tech schreef op zaterdag 11 juli 2026 @ 18:28:
Ik wilde net laten zien dat er druksensoren zijn aangesloten in de ODU...
Goed dat ik even refresh deed...

[Afbeelding]

Ik zie dat in het mooie systeemplaatje van OpenQuatt niet alle temperaturen worden weergegeven

[m10tech]

Overigens een verzoek tot een aanvulling op OpenQuatt:
Het is niet altijd zo dat er goede metingen worden ontvangen op de modbus, en daarna kan de wifi ook even haperen.
Het zou fijn zijn als er een soort 'hamsterwiel' is dat aangeeft dat info nog ververst, of dat we naar een bevroren status kijken.
Tevens lijkt het patroon van de huidige CiC te zijn overgenomen door meerdere modbus read commands te sturen, terwijl één grote read ook jarenlang goed werkte.

@jj85 kijk maar of je dit er ooit infietst. Bij voorbaat dank!

[jj85]

m10tech schreef op zaterdag 11 juli 2026 @ 18:54:
Overigens een verzoek tot een aanvulling op OpenQuatt:
Het is niet altijd zo dat er goede metingen worden ontvangen op de modbus, en daarna kan de wifi ook even haperen.
Het zou fijn zijn als er een soort 'hamsterwiel' is dat aangeeft dat info nog ververst, of dat we naar een bevroren status kijken.
Tevens lijkt het patroon van de huidige CiC te zijn overgenomen door meerdere modbus read commands te sturen, terwijl één grote read ook jarenlang goed werkte.

@jj85 kijk maar of je dit er ooit infietst. Bij voorbaat dank!

Ik herken dit eerlijk gezegd niet. Andere gebruikers die ook last hebben van stotterende wifi en bevroren metingen?

1 grote read is wellicht zinvol.

Gaf eerder problemen in combi met OT en webserver (maar wellicht dat het nu beter uitpakt)

Waar zie je die hamsters voor je ?

[jj85]

jj85 schreef op zaterdag 11 juli 2026 @ 17:05:
@memorynl Wat aanvullend onderzoek
Ik heb dit inmiddels verder uitgezocht aan de hand van het Modbus-protocol en de historydata. De drukregisters van de Quatt gedragen zich als barg, niet als bara. De schaal 0–600 betekent daarbij 0–60,0 bar.

Dat is ook te controleren met de door de Quatt berekende verdampingstemperatuur. Bij 12,2 barg is de absolute druk ongeveer 13,21 bara. Voor R32 hoort daar een verzadigingstemperatuur van circa 16,1 °C bij. Dat komt redelijk overeen met de 16,7 °C die de Quatt zelf rapporteert. Wanneer 12,2 bar als absolute druk wordt geïnterpreteerd, zou de verzadigingstemperatuur slechts ongeveer 13,3 °C zijn; dat past duidelijk niet bij de overige waarden.

Op het betreffende moment was de gasretourtemperatuur 16,63 °C. De onafhankelijk berekende superheat is daarmee ongeveer:

16,63−16,09=0,54K

De Quatt zelf toont ongeveer −0,1 K, omdat hij de gasretourtemperatuur aftrekt van zijn intern berekende verdampingstemperatuur van 16,72 °C. Praktisch zou ik daarom niet zeggen dat de superheat exact negatief is, maar dat hij ergens rond 0–1 K ligt. Dat is nog steeds erg laag.

Het verschil van circa 0,6 K tussen de Quatt-berekening en de onafhankelijke R32-berekening lijkt structureel uit de interne druk-temperatuurconversie in de buitenunit te komen.

Met andere woorden: superheat berekend met de Quatt-ODU temp-waarden lijken wat te conservatief te zijn t.o.v. R32 diagrammen.

[Afbeelding]


Als je naar EEV data kijkt, dan is die ook nog niet uitgeregeld. Het systeem lijkt idd bewust op een hele lage superheat te sturen...

Zelf een sensor gemaakt om op basis van de R32 properties een verdampingstemperatuur te bepalen (vanuit de zuigdruk).
De berekende superheat (onderste waarde) is een stukje gunstiger dan die ik krijg door de ODU-waarden te gebruiken. Voel me er nu iets prettiger bij




Template sensor

YAML:

template:
  - sensor:

      # ============================================================
      # HP1 — onafhankelijke R32-verzadigingstemperatuur
      # ============================================================
      - name: "OpenQuatt HP1 R32 evaporating temperature"
        default_entity_id: sensor.openquatt_hp1_r32_evaporating_temperature
        unique_id: openquatt_hp1_r32_evaporating_temperature
        icon: mdi:thermometer-lines
        device_class: temperature
        state_class: measurement
        unit_of_measurement: "°C"

        availability: >
          {% set p = states('sensor.openquatt_hp1_evaporator_pressure') %}
          {{ is_number(p) and 0.5 < (p | float) < 54 }}

        state: >
          {% set p_gauge = states(
               'sensor.openquatt_hp1_evaporator_pressure'
             ) | float %}

          {# Quatt rapporteert barg; omrekenen naar bara #}
          {% set p_absolute = p_gauge + 1.01325 %}

          {# R32 Tsat-fit, invoer: absolute druk in bar #}
          {% set x = log(p_absolute) %}
          {% set y = -0.0105466122305 %}
          {% set y = y * x + 0.118156099581 %}
          {% set y = y * x - 0.503158364915 %}
          {% set y = y * x + 1.36061590071 %}
          {% set y = y * x + 0.63126215419 %}
          {% set y = y * x + 20.3256147704 %}
          {% set y = y * x - 52.0666670537 %}

          {{ y | round(2) }}


      # ============================================================
      # HP1 — onafhankelijk berekende superheat
      # ============================================================
      - name: "OpenQuatt HP1 R32 superheat"
        default_entity_id: sensor.openquatt_hp1_r32_superheat
        unique_id: openquatt_hp1_r32_superheat
        icon: mdi:thermometer-chevron-up
        state_class: measurement
        unit_of_measurement: "K"

        availability: >
          {{
            is_number(states(
              'sensor.openquatt_hp1_gas_return_temperature'
            ))
            and
            is_number(states(
              'sensor.openquatt_hp1_r32_evaporating_temperature'
            ))
          }}

        state: >
          {% set gas_return = states(
               'sensor.openquatt_hp1_gas_return_temperature'
             ) | float %}
          {% set evaporation = states(
               'sensor.openquatt_hp1_r32_evaporating_temperature'
             ) | float %}

          {{ (gas_return - evaporation) | round(2) }}

[m10tech]

jj85 schreef op zaterdag 11 juli 2026 @ 19:39:
[...]

Waar zie je die hamsters voor je ?

Bij hamsterwiel stel ik me voor dat er een 60° rotatie is van een streep, elke keer als er een meting binnenkomt. Als die dan stilstaat weet je dat er iets hapert. En als het blijft bewegen geeft het een mooi dopamineshotje ;-)

[ Voor 25% gewijzigd door m10tech op 11-07-2026 22:06 ]

[TeslaNerd]

m10tech schreef op zaterdag 11 juli 2026 @ 22:05:
[...]

Bij hamsterwiel stel ik me voor dat er een 60° rotatie is van een streep, elke keer als er een meting binnenkomt. Als die dan stilstaat weet je dat er iets hapert. En als het blijft bewegen geeft het een mooi dopamineshotje ;-)

/|\-/|\-/|\-/|\-/|\-/|\-

[jj85]

m10tech schreef op zaterdag 11 juli 2026 @ 22:05:
[...]

Bij hamsterwiel stel ik me voor dat er een 60° rotatie is van een streep, elke keer als er een meting binnenkomt. Als die dan stilstaat weet je dat er iets hapert. En als het blijft bewegen geeft het een mooi dopamineshotje ;-)

En op welke plek?

[sdh1981]

memorynl schreef op zaterdag 11 juli 2026 @ 15:32:
[...]

De bovenstaande waarschuwing van @jj85 heeft mij aan het denken gezet (en voorlopig het koelen even uitgezet ). Ik deel graag een aantal dingen met jullie, met de intentie om samen verder te komen, zodat we straks weten onder welke voorwaarden 'veilig' koelen mogelijk is.
Want hoewel ik wat dingen geleerd heb (ja, met Claude-hulp, maar ik neem zeker niet zomaar alles aan), mis ik de intuïtie die een expert op dit gebied heeft. Dus alle discussie is welkom.

Als eerste gaan we kijken naar die superheat. Dat is voor de compressor relevant, want er moet R32 (in mijn V1 in elk geval) in GASVORM doorheen. Als de R32 vloeibaar is gaat de compressor sneller slijten of simpelweg stuk, daar is het ding niet voor gemaakt. Het is dus belangrijk dat de R32 in gasvorm blijft, ofwel het moet heter zijn dan het kookpunt/condensatiepunt (want anders wordt het vloeibaar). Hoeveel heter het gas is, noemen we "superheat", en blijkbaar is het gezond om daar wat marge in te hebben, ergens tussen de 5-10 graden (Kelvin of Celsius maakt niet uit, het gaat om de delta).

Maar dat doet onze (althans mijn V1) Quatt niet zomaar:
Gisteren heb ik een cooling-run gedaan op 30 Hz, in dit plaatje zie je over een half uur tijd de "superheat" (het verschil tussen die twee dus). Na het opstarten (1:08) zie je een flinke marge, maar daarna neemt de superheat langzaam af naar een graadje of een half . Dat lijkt geen lekkere marge.
[Afbeelding]

Maar toch interessant, dacht ik, waarom start hij dan wel lekker? En hij wordt ook niet negatief, hoe dan? Lijkt wel alsof de Quatt dit expres doet, nietwaar? En hoe doet de Quatt dat dan als er een Chill aan hangt? De ODU is dan exact hetzelfde.

Na wat graven kom ik er dan achter dat "moderne" EEV-pompen (Electronic Expansion Valve) inderdaad zouden moeten kunnen werken met een veel lagere superheat. Er is namelijk ook een hogere efficiency mogelijk door strak te sturen op een lage superheat. (In het kort: R32-vloeistof "koken" is efficiëntere energieoverdracht dan R32-gas verder verhitten, en minder superheat = minder "verder verhitten" en "meer koken"). En dat doet o.a. de EEV.
Daar hoort dan ook een ander veiligheidsmechanisme bij; door te kijken naar (plotselinge afwijkingen in) de "discharge temperature" (de output-kant van de compressor) kan de EEV-controller dit blijkbaar zo strak sturen als hij doet. En volgens Claude was de 46 graden discharge temp die ik gisteren stabiel had "healthy".

Onder de streep ben ik iets hoopvoller geworden t.a.v. de geobserveerde lage superheat values. Maar nog wel werk aan de winkel voordat ik "veilig" durf te koelen. Dus het eerdere advies is nog steeds van kracht!

Op dit punt ben ik gestopt. Ik heb nog geen literatuur bekeken hierover, en nog niet veel verder gedoken in wat dan "healthy" is.
Tevens heb ik geen Chill, dus als iemand die heeft zou ik heel benieuwd zijn wat die doet tijdens koelen (compressor-frequentie, superheat values, discharge temperature, etc).

Nog een paar simpele observaties ter referentie:

• de gemeten pressure waarden zijn in gauge-bar
• de door de UDO-gerapporteerde "evaporating temperature" is nauwkeurig
• de namen van de sensoren in HA zijn gebaseerd op verwarmings-modus. In cooling-mode kloppen evaporator_pressure en condenser_pressure wel, maar evaporator_coil_temperature meet dan de temp van de "condensing" en inner_coil_temperature meet de temp van "evaporating". (Het duurde even voordat we de klik gemaakt hadden hier ).

Superheat op het randje of eronder is niet alleen het geval bij koelen maar ook bij verwarmen en in mijn geval in HOT Water mode (CM4) De EEV wordt aangestuurd door de Amitime FW en hebben we niet in de hand. Zoals je zelf aangeeft is net boven de 0K ideaal voor het rendement en moet net genoeg zijn. Er zal best een marge ingebouwd zijn omdat de standaard sensoren niet de beste zijn die er op de markt te krijgen is.

[m10tech]

jj85 schreef op zondag 12 juli 2026 @ 09:06:
[...]
En op welke plek?

Bij overzicht/warmtepompen, voor elke HP één, bij werkmodus. Overigens is een timestamp ook een goede optie en misschien ook makkelijker te maken.
Misschien zelfs een derde bovenin om te laten zien dat er nog contact is met de controller.

[jj85]

mbt de superheat
vandaag al minimaal 7 uur onafgebroken aan het koelen (heb wat extra capaciteit gecreeerd door de Jaga's op de kinderkamers ook van fans te voorzien).
Veelal op 26, 28, of 30Hz (die pieken hieronder zijn de oil return cycles).

De superheat (op basis van R32 tabel) blijft nu best netjes. Heb wel weer wat vertrouwen teruggewonnen hiermee



En dit is best fijn (in combi met een kleine ontvochtiger), resultaat van een halve dag koelen

[ Voor 23% gewijzigd door jj85 op 12-07-2026 21:09 ]

[memorynl]

jj85 schreef op zondag 12 juli 2026 @ 21:06:
mbt de superheat
vandaag al minimaal 7 uur onafgebroken aan het koelen (heb wat extra capaciteit gecreeerd door de Jaga's op de kinderkamers ook van fans te voorzien).
Veelal op 26, 28, of 30Hz (die pieken hieronder zijn de oil return cycles).

De superheat (op basis van R32 tabel) blijft nu best netjes. Heb wel weer wat vertrouwen teruggewonnen hiermee

[Afbeelding]

Ik voel me er ook prettiger bij . Dank dat je hier verder ingedoken bent al.
Tegelijk blijft de vraag: hoe laag kunnen we gaan met die compressor-frequentie. Als 30Hz goed genoeg is voor een systeem (qua afgifte/opname), dan zal het best goed zitten. Maar anderen, waaronder ik, hebben lagere frequenties nodig om een stabiele lange run te realiseren zonder pendelen (helaas niet alles Jaga's en geen vloerkoeling).

Ik wil de komende tijd ook nog eens wat testjes gaan doen. En dan kijken naar die discharge superheat, en EEV-steps. @jj85 weet jij wat het regelbereik van die EEV steps is? t/m 200? Hopelijk krijg ik daarmee wat beter gevoel bij wat er gebeurt bij lagere Hz, en wanneer het systeem instabiel gaat worden ofzo.

@sdh1981 Je zegt dat de Quatt ODU van Amitime is, dat zag ik eerder ergens hier langskomen. Daarvan kan ik helemaal NIETS qua specs vinden. Weet jij (of iemand) wellicht welke compressor er in een Quatt zit? Dan kunnen we wellicht op basis van de documentatie de performance envelope te weten komen (welke Hz onder welke omstandigheden haalbaar zijn).

[jj85]

memorynl schreef op zondag 12 juli 2026 @ 21:19:
[...]

Ik voel me er ook prettiger bij . Dank dat je hier verder ingedoken bent al.
Tegelijk blijft de vraag: hoe laag kunnen we gaan met die compressor-frequentie. Als 30Hz goed genoeg is voor een systeem (qua afgifte/opname), dan zal het best goed zitten. Maar anderen, waaronder ik, hebben lagere frequenties nodig om een stabiele lange run te realiseren zonder pendelen (helaas niet alles Jaga's en geen vloerkoeling).

Ik wil de komende tijd ook nog eens wat testjes gaan doen. En dan kijken naar die discharge superheat, en EEV-steps. @jj85 weet jij wat het regelbereik van die EEV steps is? t/m 200? Hopelijk krijg ik daarmee wat beter gevoel bij wat er gebeurt bij lagere Hz, en wanneer het systeem instabiel gaat worden ofzo.

Bij mij zat hij vandaag op 440 ongeveer... Volgens modbus spec zit hij tussen 0 en 500

@sdh1981 Je zegt dat de Quatt ODU van Amitime is, dat zag ik eerder ergens hier langskomen. Daarvan kan ik helemaal NIETS qua specs vinden. Weet jij (of iemand) wellicht welke compressor er in een Quatt zit? Dan kunnen we wellicht op basis van de documentatie de performance envelope te weten komen (welke Hz onder welke omstandigheden haalbaar zijn).

@TeslaNerd jij bent de uitgelezen persoon om dit eens na te vragen bij je Amitime contact Dat is idd wel zinvolle info.

[pieke]

Hier ook een dagje data van de superheat range in Claude gegooid en de EEV lijkt relatief goed in het corrigeren.

Na pakweg 24 uur draaien 1.1% in de 'critical'- zone. waarvan 70% in de 20-24Hz range. en in totaal 61 dips, waarvan 60 minder dan een minuut duurden en in totaal 16 min 'critical'.

Hoe schadelijk 16 min uit 24 uur (waarvan het gros enkele tientallen seconden) potentieel is zou ik niet durven zeggen, maar Claude is ervan overtuigd dat 20 en 24hz verbannen met waarschijnlijk meer start-stops tot gevolg schadelijker is voor de compressor dan de huidige regeling met af en toe een kort dipje naar 'critical'







En hier nog even het koelresultaat van gisteren 😄



Inmiddels totaal rond de 1400kWh warmte uit mijn huis verbannen met een EER van 6.0. Nog steeds geen condens op de vloeren terwijl ik openquatt vertel dat het water 3.5 graad warmer is dan wat de CiC meet, aangezien ik op vloeroppervlak temperatuur wil meten in plaats van aanvoertemp (afgezien van een klein hoekje van de badkamer waar de vloerverwarming langsloopt op weg naar andere ruimtes, maar goed, dat kan prima in de badkamer). Ik heb wel de badkamersensor uit de dauwpuntmeting gemikt, omdat iemand die een douche neemt de luchtvochtigheid zodanig verhoogt dat het dauwpunt omhoog springt en de regeling de rem erop gooit.

En verder 3x per dag de bak van de ontvochtiger legen en daarna verplaatsen naar de kamer die dan de hoogste luchtvochtigheid heeft 🙃

[sdh1981]

pieke schreef op maandag 13 juli 2026 @ 10:12:
Hier ook een dagje data van de superheat range in Claude gegooid en de EEV lijkt relatief goed in het corrigeren.

Na pakweg 24 uur draaien 1.1% in de 'critical'- zone. waarvan 70% in de 20-24Hz range. en in totaal 61 dips, waarvan 60 minder dan een minuut duurden en in totaal 16 min 'critical'.

Hoe schadelijk 16 min uit 24 uur (waarvan het gros enkele tientallen seconden) potentieel is zou ik niet durven zeggen, maar Claude is ervan overtuigd dat 20 en 24hz verbannen met waarschijnlijk meer start-stops tot gevolg schadelijker is voor de compressor dan de huidige regeling met af en toe een kort dipje naar 'critical'

[Afbeelding]

[Afbeelding]

[Afbeelding]

En hier nog even het koelresultaat van gisteren 😄

[Afbeelding]

Inmiddels totaal rond de 1400kWh warmte uit mijn huis verbannen met een EER van 6.0. Nog steeds geen condens op de vloeren terwijl ik openquatt vertel dat het water 3.5 graad warmer is dan wat de CiC meet, aangezien ik op vloeroppervlak temperatuur wil meten in plaats van aanvoertemp (afgezien van een klein hoekje van de badkamer waar de vloerverwarming langsloopt op weg naar andere ruimtes, maar goed, dat kan prima in de badkamer). Ik heb wel de badkamersensor uit de dauwpuntmeting gemikt, omdat iemand die een douche neemt de luchtvochtigheid zodanig verhoogt dat het dauwpunt omhoog springt en de regeling de rem erop gooit.

En verder 3x per dag de bak van de ontvochtiger legen en daarna verplaatsen naar de kamer die dan de hoogste luchtvochtigheid heeft 🙃

Volgens info uit het verleden gebruikt Quatt/Amitime de Mitsubishi twin scroll compressor. Type onbekend omdat hij niet zichtbaar is in de ODU. Deze vindt alles goed boven de 0K volgens hun spec. blad op pagina 12 compressor specs

Ik heb hier in mijn OQ-fork de Modbus-request om de 5 seconden gecombineerd opgevraagd, waardoor je een nettere superheat en sensordata krijgt.

[joosie]

Ik ben één van de gelukkige testers van de OpenQuatt controller van @leejoow

Ons huis heeft ongeveer 250 m2 vloerverwarming waarvan ik nu ~150 m2 koel. Eerder deden we het met airco's, maar dit is veel 'rustiger' koel, je hebt geen tocht en het gaat heel geleidelijk.

Zie hieronder het verbruik als je hem dagelijks van 8 tot 21 aan hebt staan.





P.S. Quatt Duo V1, ik stuur alles aan met Homey -> MQTT

[Valor]

Hele topic gelezen! Heel gaaf wat er hier is neergezet waarvoor dank voor deze enorme inzet! 👍

Is het al bekend wanneer de OpenQuatt Controller beschikbaar komt?

[harv]

Valor schreef op maandag 13 juli 2026 @ 21:39:
Hele topic gelezen! Heel gaaf wat er hier is neergezet waarvoor dank voor deze enorme inzet! 👍

Is het al bekend wanneer de OpenQuatt Controller beschikbaar komt?

@Valor

Gewoon opnieuw lezen!!

[Valor]

harv schreef op maandag 13 juli 2026 @ 21:55:
[...]

@Valor

Gewoon opnieuw lezen!!

Oh sorry blijkbaar ergens over heen gelezen....

[m10tech]

Het beta-testteam start deze week... me included

[joosie]

joosie schreef op maandag 13 juli 2026 @ 16:51:
Ik ben één van de gelukkige testers van de OpenQuatt controller van @leejoow

Ons huis heeft ongeveer 250 m2 vloerverwarming waarvan ik nu ~150 m2 koel. Eerder deden we het met airco's, maar dit is veel 'rustiger' koel, je hebt geen tocht en het gaat heel geleidelijk.

Zie hieronder het verbruik als je hem dagelijks van 8 tot 21 aan hebt staan.

[Afbeelding]

[Afbeelding]

P.S. Quatt Duo V1, ik stuur alles aan met Homey -> MQTT

En ter vergelijk met eerder toen we met Airco's koelden. Een week met milde temperaturen (gele lijn) gemiddeld 14kWh per dag en met echt hitte (blauwe lijn) 33 kWh per dag! Nu 6kWh per dag met een kleine ontvochtiger.

[ Voor 13% gewijzigd door joosie op 14-07-2026 09:05 ]

[Trackerfire]

m10tech schreef op maandag 13 juli 2026 @ 22:28:
Het beta-testteam start deze week... me included

Nice, nog meer gelukkigen? Ik zit er (helaas) niet bij

[jj85]

m10tech schreef op maandag 13 juli 2026 @ 22:28:
Het beta-testteam start deze week... me included

Van de v1.1 controller
De v1.0 heeft hier inmiddels al 2 weken de CiC vervangen

En he! Mijn V1.5 heeft een lokale flowmeter 'onder de CV' gekregen (alles voor fatsoenlijk testen )

spoiler:

Designfoutje in mijn installatie; doorstoomverwarmer iets teveel boven m'n stopcontact. Was leuk toen ik m'n dauwpuntsmetings op zolder uitgesloten had van de dauwpuntsbewaking bij koelen... Nat stopcontact, gelukkig geen schade/kortsluiting. Vandaar het groene doekje.