alles in de xtend staat in fabrieks instelling laat alles mooi staan cv hre op 30% vermogen ingesteld pompsnelheid op 75% heb T22 radiatoren
Onze Xtend is ook geupdate. Het valt mij wel op dat het gedrag ineens heel anders is. Zie onderstaande screenshots. Gisteren rond het middag uur is de update gedaan. Onze Xtend is nog niet aan het werk geweest, dus dit is het gedrag "in ruste". Wat is er gewijzigd in de update dat er voor zorgt dat hij nu veel "activer" is?
:strip_exif()/f/image/zUOLnkpSXXpHydadC34QWGGq.png?f=user_large)
:strip_exif()/f/image/9aRdbJEathdPxFCtn8892Smi.png?f=user_large)
:strip_exif()/f/image/XWMATHXikNeVDucdzTi7Ggjj.png?f=user_large)
:strip_icc():strip_exif()/u/1472328/crop63aecfb78b989_cropped.jpg?f=community)
Sinds enkele dagen eindelijk ook een Intergas Xtend en een nieuwe Intergas Kombi Kompakt HRE en die moest natuurlijk in HA. Na wat onderzoek in dit draadje uiteindelijk gegaan voor een combinatie tussen https://github.com/DSchoutsen/HA_connection_Xtend en de ldanicel/ha-intergas-orion (integration) via HACS. Om aan de ene kant uit te lezen en aan de andere kant te kunnen aansturen.
Eerst een update naar v1.30 gedaan (https://xtend-updates.orion.intergas.nl).
Na veel gedoe met een instabiele Xtend-koppeling (polling die stopte, sensors op unavailable, AP dat uitviel) draait het hier nu eindelijk stabiel. Samenvatting van wat er mis bleek en wat ik heb aangepast, wellicht heeft iemand er wat aan.
Setup: HAOS op een Proxmox-VM met een USB-wifi-dongle (pass-through) naar de VM.
1. Geen gateway op het Xtend-interface
Via de HA GUI kon ik de verbinding niet maken zonder een gateway in te stellen en leek de connectie ook niet persistent. Uiteindelijk via de Terminal werkte het beter.
2. Weg van de REST-integratie: de Xtend-webserver hangt op keep-alive
Dit was de grootste uitdaging. De rest-platform-sensor van HA hergebruikt HTTP-verbindingen (keep-alive). De embedded webserver van de Xtend lekt daarbij sockets en stopt na verloop van tijd met antwoorden terwijl een losse curl vanaf de terminal op de HA wel gewoon wérkt. Na een herstart doet alles het even, daarna gingen de sensors weer naar unknown.
Mijn oplossing: een command_line-sensor met curl, die per poll een verse verbinding opent en expliciet sluit. Met retries en een cache-fallback zodat één mislukte poll niet meteen alles op unavailable zet:
Deze constructie zorgt er bij mij voor dat een half mislukte download de cache niet vervuilt. Faalt de poll ondanks de retries, dan wordt de laatste geslaagde data geserveerd en blijven alle template-sensors gewoon gevuld. Bonus: omdat de data dan niet wijzigt, blijft last_updated staan, zo zie je aan de sensor alsnog dat er een storing is.
3. Eén poll voor alles (ook de ketel)
Wie ook de Xtreme-ketel uitleest: plak die veldcodes gewoon achter dezelfde fields-lijst in plaats van een tweede poller te draaien. Twee clients die om die fragiele embedded server concurreren maakt het alleen maar erger. Het voorbeeld hierboven is één curl per minuut die n nu ~100 velden voor pomp én ketel op haalt.
4. Zelfherstel van de wifi-link
Als de associatie wegvalt reconnect de NetworkManager niet altijd, en als er te lang geen client op het AP zit schakelt de Xtend zijn wifi-modus uit en kan je weer naar zolder. Daarom heb ik een shell_command die de verbinding via de Supervisor-API opnieuw opzet (deze draait vanuit de HA-core-container, die heeft SUPERVISOR_TOKEN):
Gekoppeld aan een automation: valt de uitlezing 10 minuten stil → reconnect → verse poll afdwingen → 3 minuten wachten → alleen een melding als het níet gelukt is (dan is het AP vermoedelijk al uit en moet de pomp alsnog weer in wifi-modus gezet worden):
5. Valkuil in de template-sensors: hoofdletters
De veelgedeelde template-bestanden verwijzen naar sensor.Intergas_Xtend (met hoofdletters). Renderen werkt dan gewoon, maar de update-listeners worden op exact die string geregistreerd en entity-id's zijn lowercase, de templates krijgen dus nooit nieuw data. Resultaat: na een herstart één keer waardes, daarna bevriest alles. Alle verwijzingen lowercase maken (sensor.intergas_xtend) en het probleem was bij mij weg. Check ook interne verwijzingen in icon-templates (sensor.xtend_errorCode e.d.).
6. Kleine puntjes
- Velden 77dd (systemstatus), 777d (heatpump mode) en 47e0 (softwareversie) ontbreken in de veelgedeelde fields-lijst, waardoor die sensors altijd unavailable zijn. Toevoegen aan de URL en ze doen het. Zelfde geldt voor 7191 (gasmeter) in de Xtreme-set.
- USB-passthrough in Proxmox op Vendor/Device-ID zetten i.p.v. op poort, anders raak je de dongle kwijt bij backups.
/f/image/r0M31cZg9ygKxexL5txkTZQa.png?f=fotoalbum_small)
Eerst een update naar v1.30 gedaan (https://xtend-updates.orion.intergas.nl).
Na veel gedoe met een instabiele Xtend-koppeling (polling die stopte, sensors op unavailable, AP dat uitviel) draait het hier nu eindelijk stabiel. Samenvatting van wat er mis bleek en wat ik heb aangepast, wellicht heeft iemand er wat aan.
Setup: HAOS op een Proxmox-VM met een USB-wifi-dongle (pass-through) naar de VM.
1. Geen gateway op het Xtend-interface
Via de HA GUI kon ik de verbinding niet maken zonder een gateway in te stellen en leek de connectie ook niet persistent. Uiteindelijk via de Terminal werkte het beter.
code:
(dus zónder --ipv4-gateway)1
2
3
4
5
6
| ha network update <wifi-interface> \ --wifi-ssid "Xtend-XXXXXXXXXX" \ --wifi-psk "<jouw-psk>" \ --wifi-auth wpa-psk \ --ipv4-method static \ --ipv4-address 10.20.30.2/24 |
2. Weg van de REST-integratie: de Xtend-webserver hangt op keep-alive
Dit was de grootste uitdaging. De rest-platform-sensor van HA hergebruikt HTTP-verbindingen (keep-alive). De embedded webserver van de Xtend lekt daarbij sockets en stopt na verloop van tijd met antwoorden terwijl een losse curl vanaf de terminal op de HA wel gewoon wérkt. Na een herstart doet alles het even, daarna gingen de sensors weer naar unknown.
Mijn oplossing: een command_line-sensor met curl, die per poll een verse verbinding opent en expliciet sluit. Met retries en een cache-fallback zodat één mislukte poll niet meteen alles op unavailable zet:
code:
Ik heb deze in mijn configuration.yaml geplaatst.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| command_line:
- sensor:
name: Intergas Xtend
unique_id: <uuid>
command: >-
curl -sS --max-time 15 --retry 2 --retry-delay 2 --retry-connrefused
-H "Connection: close"
"http://10.20.30.1/api/stats/values?fields=77dd,777d,47e0,79b3,7921,7940,50f2,503e,5041,5088,5077,50ae,50f7,5099,506a,63f0,63b3,63df,6a8e,6ac5,6a6c,71a7,7160,6a53,6a8d,8e00,8ef9,8e37,8e18,f9f2,65b0,6579,7ed3,629c,6280,62e7,7767,65d9,6505,77c3,7e51,77d2,65c1,6cfb,6c33,65a7,658a,6c8a,6c61,6578,65d0,6c66,62d1,b38c,b3bc,84d1,7e2c,8439,4133,6c53,6c26,6ceb,7ee6,7e81,7e31,4e3a,4eeb,4e13,4a22,4a3c,4aeb,5008,63a7,5051,63e4,6a28,6a78,503f,2963,4a76,50ff,6358,5031,6339,5098,7fec,625b,623c,7e7a,7191,8e1e,8ecc,8edb,8ecb,8e7f,8e8f,848e,8434,844c"
-o /config/.intergas_tmp.json
&& mv /config/.intergas_tmp.json /config/.intergas_cache.json
&& cat /config/.intergas_cache.json
|| cat /config/.intergas_cache.json
scan_interval: 60
command_timeout: 55
value_template: "Ok"
json_attributes:
- stats |
Deze constructie zorgt er bij mij voor dat een half mislukte download de cache niet vervuilt. Faalt de poll ondanks de retries, dan wordt de laatste geslaagde data geserveerd en blijven alle template-sensors gewoon gevuld. Bonus: omdat de data dan niet wijzigt, blijft last_updated staan, zo zie je aan de sensor alsnog dat er een storing is.
3. Eén poll voor alles (ook de ketel)
Wie ook de Xtreme-ketel uitleest: plak die veldcodes gewoon achter dezelfde fields-lijst in plaats van een tweede poller te draaien. Twee clients die om die fragiele embedded server concurreren maakt het alleen maar erger. Het voorbeeld hierboven is één curl per minuut die n nu ~100 velden voor pomp én ketel op haalt.
4. Zelfherstel van de wifi-link
Als de associatie wegvalt reconnect de NetworkManager niet altijd, en als er te lang geen client op het AP zit schakelt de Xtend zijn wifi-modus uit en kan je weer naar zolder. Daarom heb ik een shell_command die de verbinding via de Supervisor-API opnieuw opzet (deze draait vanuit de HA-core-container, die heeft SUPERVISOR_TOKEN):
code:
Je kan deze in configuration.yaml plaatsen.1
2
3
4
5
6
| shell_command:
xtend_wifi_reconnect: >-
curl -sS -X POST -H "Authorization: Bearer ${SUPERVISOR_TOKEN}"
-H "Content-Type: application/json"
http://supervisor/network/interface/<wifi-interface>/update
-d '{"enabled":true,"ipv4":{"method":"static","address":["10.20.30.2/24"],"nameservers":[],"gateway":null},"wifi":{"mode":"infrastructure","ssid":"Xtend-XXXXXXXXXX","auth":"wpa-psk","psk":"<jouw-psk>"}}' |
Gekoppeld aan een automation: valt de uitlezing 10 minuten stil → reconnect → verse poll afdwingen → 3 minuten wachten → alleen een melding als het níet gelukt is (dan is het AP vermoedelijk al uit en moet de pomp alsnog weer in wifi-modus gezet worden):
code:
Je plaats dit dus in je automations.yaml.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| - alias: "Xtend: verbinding weggevallen (zelfherstel)"
triggers:
- trigger: template
value_template: >-
{{ states.sensor.intergas_xtend is not none and
(now() - states.sensor.intergas_xtend.last_updated).total_seconds() > 600 }}
actions:
- action: shell_command.xtend_wifi_reconnect
- delay:
seconds: 20
- action: homeassistant.update_entity
target:
entity_id: sensor.intergas_xtend
- delay:
minutes: 3
- if:
- condition: template
value_template: >-
{{ (now() - states.sensor.intergas_xtend.last_updated).total_seconds() > 240 }}
then:
- action: notify.<jouw-notify>
data:
message: "Xtend-uitlezing gestopt; automatisch herstel mislukt — pomp kort spanningsloos maken."
else:
- action: notify.<jouw-notify>
data:
message: "Xtend-uitlezing was gestopt; wifi-link automatisch hersteld."
mode: single |
5. Valkuil in de template-sensors: hoofdletters
De veelgedeelde template-bestanden verwijzen naar sensor.Intergas_Xtend (met hoofdletters). Renderen werkt dan gewoon, maar de update-listeners worden op exact die string geregistreerd en entity-id's zijn lowercase, de templates krijgen dus nooit nieuw data. Resultaat: na een herstart één keer waardes, daarna bevriest alles. Alle verwijzingen lowercase maken (sensor.intergas_xtend) en het probleem was bij mij weg. Check ook interne verwijzingen in icon-templates (sensor.xtend_errorCode e.d.).
6. Kleine puntjes
- Velden 77dd (systemstatus), 777d (heatpump mode) en 47e0 (softwareversie) ontbreken in de veelgedeelde fields-lijst, waardoor die sensors altijd unavailable zijn. Toevoegen aan de URL en ze doen het. Zelfde geldt voor 7191 (gasmeter) in de Xtreme-set.
- USB-passthrough in Proxmox op Vendor/Device-ID zetten i.p.v. op poort, anders raak je de dongle kwijt bij backups.
:strip_exif()/f/image/r0M31cZg9ygKxexL5txkTZQa.png?f=user_large)
[ Voor 3% gewijzigd door x5serv op 17-10-2026 15:47 ]
ik heb de Xstore nu sinds maart ongeveer hangen. Gezin van 5 met 3 kinderen tussen de 10 en 4 jaar.
Over het algemeen vrij lange douchers, met name de vrouw
. Het is net wanneer iedereen doucht, want als we allemaal achter elkaar gaan is de boiler natuurlijk zo leeg. Maar met een beetje plannen, boiler is met een goed uur weer op voldoende temp. voor de volgende persoon, is het WW gasverbruik naar 0,05 a 0,10 m3 per persoon.
Xstore staat ingesteld op 60 graden, ketel verwarmt hij wanneer de aanvoer 40 graden of minder is. Bij een snelle douchebeurt hoeft de ketel bijna niks te doen. Enige is dat de ketel initieel aangaat bij de eerste warmtevraag. Dit omdat het water in de leiding onder de 40 graden is.
Aanleg is gedaan door een bekend installateur in de avonduren. Moet zeggen dat het boven verwachting prima werkt.
Over het algemeen vrij lange douchers, met name de vrouw
. Het is net wanneer iedereen doucht, want als we allemaal achter elkaar gaan is de boiler natuurlijk zo leeg. Maar met een beetje plannen, boiler is met een goed uur weer op voldoende temp. voor de volgende persoon, is het WW gasverbruik naar 0,05 a 0,10 m3 per persoon. Xstore staat ingesteld op 60 graden, ketel verwarmt hij wanneer de aanvoer 40 graden of minder is. Bij een snelle douchebeurt hoeft de ketel bijna niks te doen. Enige is dat de ketel initieel aangaat bij de eerste warmtevraag. Dit omdat het water in de leiding onder de 40 graden is.
Aanleg is gedaan door een bekend installateur in de avonduren. Moet zeggen dat het boven verwachting prima werkt.
/u/2511816/crop6a7cec0230c01.png?f=community)
Hoe werkt het qua verwarmen? Is het of de Xstore of de CV die verwarmt wordt of doet de Xtend ook tegelijk? Zodra de temperatuur nog iets naar beneden gaat draait de WP hier veel uren op zijn laagste vermogen.:
ik heb de Xstore nu sinds maart ongeveer hangen. Gezin van 5 met 3 kinderen tussen de 10 en 4 jaar.
Over het algemeen vrij lange douchers, met name de vrouw
Xstore staat ingesteld op 60 graden, ketel verwarmt hij wanneer de aanvoer 40 graden of minder is. Bij een snelle douchebeurt hoeft de ketel bijna niks te doen. Enige is dat de ketel initieel aangaat bij de eerste warmtevraag. Dit omdat het water in de leiding onder de 40 graden is.
Aanleg is gedaan door een bekend installateur in de avonduren. Moet zeggen dat het boven verwachting prima werkt.
Full electric Xtend, 300L boiler 2kW E, WTW Brink Flair 400 (Multi Air Supply), Oost 2175Wp West 3915Wp PV.
:strip_exif()/u/29037/sousuke02a.gif?f=community)
Full electric Xtend, 300L boiler 2kW E, WTW Brink Flair 400 (Multi Air Supply), Oost 2175Wp West 3915Wp PV.
:no_upscale():strip_icc():strip_exif()/f/image/FVddptmitUX6LvtEC0QB4rnn.jpg?f=user_large)
Waarom vertoont de Xtend gisteren bovenstaand gedrag?
Thermostaat staat continue op 19,5.
Zou hij toch kortstondig teveel warmte produceren?
Huis was gisteren comfortabel warm.
/u/35508/crop61e6aa7b579e2_cropped.png?f=community)
Bij mijn installatie is een Caleffi ontluchter geplaatst na het voorschakelvat (vat in serie, in de retourleiding).
:no_upscale():strip_icc():strip_exif()/f/image/HtSseOFugTrONTljuHVgzrpi.jpg?f=user_large)
[ Voor 15% gewijzigd door WillemD61 op 28-10-2026 17:35 ]
Die is het en de kleine c. (althans bij mij). Ik heb nog even zitten zoeken omdat het wellicht anderen helpt, het staat dus blijkbaar in het installatiedocument van de Xtend. Bizar dat zelfs dat soort instellingen door installateurs niet eens uitgevoerd worden.
:strip_exif()/f/image/qRinAVryUaldV17xz7A8Kbjb.png?f=user_large)
Had iemand al succesvol de nieuwe firmware i.c.m. de ESP boardjes gemigreerd?
Wil misschien wel updaten, maar dan gaat mijn overzichtje stuk las ik.
/f/image/F0NNSlgXiGr7933xnolzooAa.png?f=fotoalbum_large)
Wil misschien wel updaten, maar dan gaat mijn overzichtje stuk las ik.
:strip_exif()/f/image/F0NNSlgXiGr7933xnolzooAa.png?f=user_large)
[ Voor 71% gewijzigd door Vorkie op 04-11-2026 19:20 ]
3-fase Victron 3x MP 6.5kVA | 30kWh Voltsmile LFP | MPPT 450/100 + 2x MPPT | VM-3P75CT Grid Meter
Hier de temperatuur 24/7 21 graden constant. 2 onder 1 kap, uitbouw + opbouw garage.
Omdat de aanvoertemperatuur toch laag is ook alle radiatoren boven en garage open gezet voor een zo grote mogelijke flow met vloerverwarming beneden om het pendelen zoveel mogelijk tegen te gaan.
Helemaal tevreden!
:strip_exif()/f/image/HfhIReFktVXqfOQKgQMtQIrH.jpg?f=fotoalbum_large)
Omdat de aanvoertemperatuur toch laag is ook alle radiatoren boven en garage open gezet voor een zo grote mogelijke flow met vloerverwarming beneden om het pendelen zoveel mogelijk tegen te gaan.
Helemaal tevreden!
:no_upscale():strip_icc():strip_exif()/f/image/HfhIReFktVXqfOQKgQMtQIrH.jpg?f=user_large)
[ Voor 4% gewijzigd door nietnodig op 04-11-2026 23:37 ]
Dit jaar kan ik nog salderen met de zonnestroom van mijn zonnepanelen. Ontdooien doe ik ook op stroom. Volgend jaar kijk ik verder. Maar dat vroeg je niet, dus ik heb je vraag niet beantwoord.
Tis maar een vraag he
Wat ik zie in de sensoren is dat de CV 4 tot 8 KW aan energie opwekt voor het ontdooi moment. Mijn idee is dat dit best fors is. Dat geeft in de laatste dagen 0.12 m2 gas verbruik voor elke ontdooi sessie. Ik snap dat het een hybride systeem is dus verder prima. Vorig jaar een tijdje de parameter aangepast dat de CV alleen wordt gebruikt als het nodig is (voor ontdooien) maar dat maakte dat de Xtend steeds minder energy had om te ontdooien en uiteindelijk in storing ging. Al was het toen wel dik onder nul.
Op zich zou je kunnen stellen dat de Xtend zo'n 4-5 kw aan warmte onttrekt uit het huis, want ontdooien doet hij op maximaal vermogen in de tegenovergestelde richting, dus als de ketel dan 4-6 zou doen, zou ik dat eigenlijk super netjes vinden. Nu vinden veel ketels het moeilijk om echt op laag vermogen te draaien. De HRE-ketels van Intergas bijv. Zitten al snel boven de 6 kW. De Xtreme's kunnen wel zo'n 4 kW leveren. En op zich maakt het niks uit waar je het maximale vermogen van de ketel op instelt; dat verandert z'n minimum niet, aangezien dat gewoon een gegeven is voor een bepaald model. Dus als dat het geval is dan zou het geen zin hebben.:
[...]
Tis maar een vraag he
Vorig jaar een tijdje de parameter aangepast dat de CV alleen wordt gebruikt als het nodig is (voor ontdooien) maar dat maakte dat de Xtend steeds minder energy had om te ontdooien en uiteindelijk in storing ging. Al was het toen wel dik onder nul.
Als het probleem de aansturing van de Xtend is, dat die via the opentherm te hoge vermogens/temperatuur zou vragen, dan zou het wel kunnen helpen natuurlijk. Of als het een aan/uit aansturing is, dan ook, want dan zou hij natuurlijk altijd vol aan, of uit zijn.
[ Voor 10% gewijzigd door GroundBreaking op 06-11-2026 17:05 ]