Ervaringen met Quatt en HA en andere Domotica

[TeslaNerd]

jordy5 schreef op woensdag 9 juli 2025 @ 18:10:
Ik heb zelf al jaren om de omvormer uit te lezen een Elfin RS485 naar Ethernet aangesloten op de RS485 poort. Dit werkt prima en kan de data ook gemakkelijk verwerken. Is zo'n ding ook te gebruiken met de Quatt CiC/HP?

Op ali zijn ze vooral aanwezig: https://nl.aliexpress.com/item/1005006092814219.html (heb zelf de wifi variant)

Waarschijnlijk wel. Probeer het eens met Modbus Poll op een windows pc/laptop

Ik ken het niet maar Grok of Chatgpt kunnen hier goed bij helpen. Geef Grok of Chatgpt ook de link naar de Quatt Modbus sniffer voor de context

https://github.com/M10tech/Quatt-sniffer?tab=readme-ov-file

https://grok.com/share/bG...01-4aca-95be-373b3e8043be

[ Voor 8% gewijzigd door TeslaNerd op 09-07-2025 18:28 ]

[m10tech]

Op zich kun je dit gebruiken. RS485 is RS485.
Wat je daarna met de data doet is een ander verhaal...
Mijn sniffer zorgt dat HA het perfect kan verwerken.
Ik betwijfel dat jouw Elfin met HA samenwerkt.
Maar als dat je doel niet is, dan denk ik dat het wel werkt.

[jordy5]

Hij werkt perfect voor me omvormer in HomeAssistant. Hoewel me omvormer niet via Modbus gaat, maar daar is ook een vrij simpele config voor in HA. Elfin kan gewoon de boel direct op MQTT van me HA zetten. Voor modbus zou het gewoon ook smpel in HA te krijgen zijn: https://community.home-as...-ew11-wifi-modbus-or-mqtt

Ik heb het even goed nagekeken. De Eflin van me omvormer zit er al 5 jaar aan zonder enig issue, dus kijk er niet/weinig naar, maar deze heb ik ook via Modbus in HA, die 1-op-1 de data eruit haalt: https://www.home-assistant.io/integrations/modbus/

Zoals al aangeven, zal ik binnenkort ff een Elfin aan de CiC hangen, maar ik verwacht niet dat het veel spannender zal zijn.

Voor het idee is dit de config om de 40 belangrijkste registers uit mijn omvormer uit te lezen:

code:

modbus:
  - name: modbus_pv
    type: tcp
    host: ip-elfin
    port: port-elfin
    sensors:
      - name: modbus_pvreader
        address: 0x0104
        input_type: holding
        virtual_count: 40
        unique_id: pvreader
        data_type: int16

[ Voor 55% gewijzigd door jordy5 op 10-07-2025 12:53 ]

[TeslaNerd]

jordy5 schreef op woensdag 9 juli 2025 @ 18:39:
Hij werkt perfect voor me omvormer in HomeAssistant. Hoewel me omvormer niet via Modbus gaat, maar daar is ook een vrij simpele config voor in HA. Elfin kan gewoon de boel direct op MQTT van me HA zetten. Voor modbus zou het gewoon ook smpel in HA te krijgen zijn: https://community.home-as...-ew11-wifi-modbus-or-mqtt

Ik zal er eens een bestellen en in de vakantie aansluiten

Succes en wij horen graag hoe het is gegaan

[RickvdT]

Naar aanleiding van de discussie rond koelen met Quatt heb ik flink wat posts terug gelezen omtrent de modbus. Mooi om te zien wat jullie al bereikt hebben!

Aan de slag gaan met ESPHome stond al langer op mijn to-do lijst en dit leek mij een mooi eerste project. Inmiddels is er vanuit Quatt de bevestiging dat koelen native gesupport gaat worden en is de noodzaak er een beetje vanaf. Aangezien ik wat materiaal voor een ander project moest bestellen toch maar een LilyGo T-CAN485 boardje voor 10 euro mee besteld. Ik zal t.z.t. laten weten of dit zo makkelijk gaat werken als gehoopt.

[jordy5]

Voor het communiceren met de Quatt zonder de CiC kan je out-of-the-box met Elfin aan de slag en deze naar HomeAssistant sturen. Helaas zal je dan wel de "aansturing" van de HP's zelf moeten doen ook Heb even korte test gedaan en uiitgelezen:



Met de CiC ingeschakeld werkt het helaas niet samen (2 masters waarschijnlijk) 1 op de 5/6 requests falen met standaard response timeout, lijkt me erg onwenselijk aangezien het vast aan de CiC kant dan ook zal falen. Wat wel mogelijk is de data door te sturen naar MQTT of een TCP server. Dan moet je wel de data pakketten zelf "parsen". Daar moet ik maar 's nog ff induiken Dan kan je in ieder geval monitoren/sniffen.

[ Voor 18% gewijzigd door jordy5 op 10-07-2025 19:05 ]

[RickvdT]

jordy5 schreef op donderdag 10 juli 2025 @ 18:51:
Voor het communiceren met de Quatt zonder de CiC kan je out-of-the-box met Elfin aan de slag en deze naar HomeAssistant sturen. Helaas zal je dan wel de "aansturing" van de HP's zelf moeten doen ook Heb even korte test gedaan en uiitgelezen:

[Afbeelding]

Met de CiC ingeschakeld werkt het helaas niet samen (2 masters waarschijnlijk) 1 op de 5/6 requests falen met standaard response timeout, lijkt me erg onwenselijk aangezien het vast aan de CiC kant dan ook zal falen. Wat wel mogelijk is de data door te sturen naar MQTT of een TCP server. Dan moet je wel de data pakketten zelf "parsen". Daar moet ik maar 's nog ff induiken Dan kan je in ieder geval monitoren/sniffen.

De warmtepomp vind het dus prima zonder CiC? Ik had wel verwacht dat er iets van een health check/handshake zou zijn tussen de CiC en de warmtepomp. Waarbij de warmtepomp in storing/hold zou komen te staan als hij een tijd niks van de CiC hoort.

Dat zou het wel een stuk makkelijker maken om zelf de Quatt aan te sturen.

[jj85]

RickvdT schreef op vrijdag 11 juli 2025 @ 15:33:
[...]


De warmtepomp vind het dus prima zonder CiC? Ik had wel verwacht dat er iets van een health check/handshake zou zijn tussen de CiC en de warmtepomp. Waarbij de warmtepomp in storing/hold zou komen te staan als hij een tijd niks van de CiC hoort.

Dat zou het wel een stuk makkelijker maken om zelf de Quatt aan te sturen.

Warmtepomp blijft vrolijk doorhobbelen op zn laatste instructies vanuit de CiC. Na bijv een power dip op de warmtepomp gaat hij weer in standby, totdat er nieuwe instructies volgen.

[m10tech]

Mijn Quatt(1.0) wordt tegenwoordig anders aangestuurd door de CiC dan wat ik gewend was.

Normaal was dat bij het uitschakelen van de thermostaat (tweede statusbar van onder) de workingmode (onderste) ook meteen naar nul ging en de pomp nog even nadraaide.
Nu lijkt het also er altijd minstens 5 minuten warmte wordt gepompt.
CiC versie 3.5.0

[jj85]

m10tech schreef op zondag 13 juli 2025 @ 18:16:
Mijn Quatt(1.0) wordt tegenwoordig anders aangestuurd door de CiC dan wat ik gewend was.
[Afbeelding][Afbeelding]
Normaal was dat bij het uitschakelen van de thermostaat (tweede statusbar van onder) de workingmode (onderste) ook meteen naar nul ging en de pomp nog even nadraaide.
Nu lijkt het also er oftewel altijd minstens 5 minuten wordt gedraaid.
CiC versie 3.5.0

Was me onlangs ook opgevallen bij m'n pomptesten. Duurde een 'eeuwigheid' voordat de flow weer naar 0 ging

[jordy5]

Ik heb een nieuwe Elfin binnen en zonder protocol naar een simpel opgebouwde TCP server in Python laten connecten. Met copilot en M10Tech zijn repo, kom je een heel eind en heb data in HomeAssistant. Gaan het in de koudere periodes zien: Github Quatt-Elfin-Sniffer

[ Voor 6% gewijzigd door jordy5 op 22-07-2025 16:03 ]

[TeslaNerd]

jordy5 schreef op dinsdag 22 juli 2025 @ 10:34:
Ik heb een nieuwe Elfin binnen en zonder protocol naar een simpel opgebouwde TCP server in Python laten connecten. Met copilot en M10Tech zijn repo, kom je een heel eind en heb data in HomeAssistant. Gaan het in de koudere periodes zien: Github Quatt-Elfin-Sniffer

Heeft Elfin dezelfde modbus registers also de Quatt?

[jj85]

TeslaNerd schreef op dinsdag 22 juli 2025 @ 19:59:
[...]

Heeft Elfin dezelfde modbus registers also de Quatt?

Elfin in niet een warmtepomp, maar een RS485 interface
https://nl.aliexpress.com/item/1005006092814219.html

[ Voor 44% gewijzigd door jj85 op 22-07-2025 20:14 ]

[Lasoul]

Begin juni heb ik een nieuwe beta versie van de Quatt Home Assistant integratie uitgebracht waarin de sensors zijn gesplitst over verschillende devices. Hierdoor kan ook makkelijker de nieuwe Quatt apparaten zoals de All-Electric, Chill etc, worden ondersteund.

Ondertussen draait deze versie bij een aantal personen die ik ken zonder problemen maar ik heb verder geen feedback ontvangen. Het kan natuurlijk zijn dat alles goed werkt maar om het zeker te weten zou ik willen vragen of een aantal mede-tweakers deze versie zouden kunnen testen zodat ik hem kan releasen als een normale versie. Alvast bedankt!

[TeslaNerd]

Lasoul schreef op zondag 17 augustus 2025 @ 13:43:
Begin juni heb ik een nieuwe beta versie van de Quatt Home Assistant integratie uitgebracht waarin de sensors zijn gesplitst over verschillende devices. Hierdoor kan ook makkelijker de nieuwe Quatt apparaten zoals de All-Electric, Chill etc, worden ondersteund.

Ondertussen draait deze versie bij een aantal personen die ik ken zonder problemen maar ik heb verder geen feedback ontvangen. Het kan natuurlijk zijn dat alles goed werkt maar om het zeker te weten zou ik willen vragen of een aantal mede-tweakers deze versie zouden kunnen testen zodat ik hem kan releasen als een normale versie. Alvast bedankt!

[Afbeelding]

Ik wil het graag testen. Mijn HA draait nu nog v0.8. Hoe/waar kan ik upgraden van v0.8 naar v0.9b?

[Lasoul]

TeslaNerd schreef op zondag 17 augustus 2025 @ 14:48:
[...]

Ik wil het graag testen. Mijn HA draait nu nog v0.8. Hoe/waar kan ik upgraden van v0.8 naar v0.9b?

Thx
Je kunt via HACS de beta versie downloaden. Even de Quatt integratie opzoeken en dan rechtsboven op de drie puntjes klikken en dan redownload selecteren. Via het popup scherm kun je dan in de dropdown box Need a different version de nieuwe beta versie selecteren.

[TeslaNerd]

Lasoul schreef op zondag 17 augustus 2025 @ 14:54:
[...]


Thx
Je kunt via HACS de beta versie downloaden. Even de Quatt integratie opzoeken en dan rechtsboven op de drie puntjes klikken en dan redownload selecteren. Via het popup scherm kun je dan in de dropdown box Need a different version de nieuwe beta versie selecteren.

[Afbeelding]

Dankjewel! De update via HACS-redownload ging probleemloos. Morgenochtend wordt het 15 graden en zal ik wat HA-automations testen met deze nieuwe versie van de Quatt-integratie

[FV33]

Beste tweakers,

Vraagje, ik zit in de laatste offerte fase voor:
1x duo + all E large
1x single + all E XL

Nu heb ik behoorlijke overproductie zonnestroom en zou de All E graag smiddags willen laten chargen en in de avond / nacht laten leeg lopen.
Winter periode in de nacht chargen (goedkopere dynamische stroom).

Is dit mogelijk via HA?
Of weten jullie of dit bij quatt er op korter termijn aan komt?

Thanks.

[Timmy]

FV33 schreef op maandag 18 augustus 2025 @ 20:16:

Is dit mogelijk via HA?
Of weten jullie of dit bij quatt er op korter termijn aan komt?

De API heeft op dit moment geen mogelijkheid om Quatt All-E aan te sturen. Het warme water wordt aangevuld zodra Quatt dat nodig vindt.

Er is wel meer intelligentie aangekondigd maar nog niet beschikbaar.

[raven22]

raven22 schreef op zaterdag 15 maart 2025 @ 09:12:
[...]


Er is mij door @CPM gevraagd om een korte toelichting.
Het script doet het volgende:
- van 2200 tot 800 is de ingestelde temperatuur (Tv=vraagtemperatuur) 19 gr.
- tussen 8 en 22 wordt de Ta (actuele temperatuur) in de gaten gehouden, als deze >= is aan Tv dan wordt de nieuwe Tv gelijk aan Ta +0.1, dit met een maximum van 20 graden
- om 2200 gaat de temp weer naar 19.

Hieronder een nieuwe versie van het script want om 22 uur ging de Tv niet naar 19. Nu hopenlijk wel, maar zoals gezegd ik ben geen expert, script is mbv chatgpt gemaakt.

Ik ga ervanuit dat de Tado is toegevoegd aan homeassistant, zo niet volg dan deze instructies https://www.home-assistan...20list%2C%20select%20Tado.

Op het homeassistant dashboard zie je dan vanzelf de tado gegevens. Hier moet je de entiteit van je tado thermostaat uithalen. In het script vervang je climate.woonkamer door deze entiteit van jouw tado.
[Afbeelding]

Verder heb je nog nodig de actuele temperatuur waarde. In het script vervang je sensor.woonkamer_temperature door deze waarde.
[Afbeelding]

code:

alias: Dynamische Temperatuurregeling Woonkamer
triggers:
  - entity_id: sensor.woonkamer_temperature
    trigger: state
  - at: "22:00:00"
    trigger: time
conditions: []
actions:
  - choose:
      - conditions:
          - condition: time
            after: "21:59:00"
            before: "22:01:00"
        sequence:
          - target:
              entity_id: climate.woonkamer
            data:
              temperature: 19
            action: climate.set_temperature
      - conditions:
          - condition: time
            after: "07:59:00"
            before: "21:55:00"
          - condition: template
            value_template: >
              {% set ta = states('sensor.woonkamer_temperature') | float |
              round(1) %} {% set tv = state_attr('climate.woonkamer',
              'temperature') | float | round(1) %} {{ ta >= tv }}
        sequence:
          - target:
              entity_id: climate.woonkamer
            data:
              temperature: >
                {% set ta = states('sensor.woonkamer_temperature') | float |
                round(1) %} {% set new_tv = ta + 0.1 %} {% if new_tv > 20 %}
                  20
                {% else %}
                  {{ new_tv }}
                {% endif %}
            action: climate.set_temperature
mode: single

Nog een slotopmerking:
Het is denk ik belangrijk dat het ingestelde warmteverlies door Quatt goed overeenkomt met de realiteit. Is die te hoog dan worden de stapjes snel doorlopen en mijn bedoeling is juist dat hij er de hele dag over doet.
Is jouw ingestelde warmteverlies aan de lage kant, en duren de stapjes te lang, maak er dan stapjes van 0.2 of zelfs 0.3 van. De cic zal dan sneller een hoger vermogen vragen van de quatt.

Nav een verzoek in het Quatt forum hierbij een verder ontwikkelde versie van het script. Het bestaat om het voor mij begrijpelijker te houden uit 5 delen. Wellicht zit er in deel 2 en 4 wat overlap. Ik ben een leek op dit gebied en heb dit samen met Chatgpt gemaakt. Ik houd me aanbevolen voor verbeteringen, maar onderstaande werkt.

Script bestaat uit 5 delen. Hier in willekeurige volgorde.

1. deze spreekt voor zich, stelt de nachtverlaging in, tijd en temp kun je zelf kiezen

code:

alias: Nachtverlaging
triggers:
- at: "21:58:00"
trigger: time
actions:
- target:
entity_id: climate.tado_smart_thermostat_ru3988930560
data:
temperature: 18
action: climate.set_temperature
- entity_id: input_boolean.tv_verhoging_toegestaan
action: input_boolean.turn_off
mode: single

2. de temp regeling met de stapjes verhoging, ik kies voor 0,15 gr stapjes om afrondingsverschillen te voorkomen. De 20,5 is de max tot waar naar verhoogd wordt

code:

alias: Start temperatuurregeling
description: ""
triggers:
- at: input_datetime.tv_regeling_start
trigger: time
actions:
- entity_id: input_boolean.tv_verhoging_toegestaan
action: input_boolean.turn_on
- target:
entity_id: climate.tado_smart_thermostat_ru3988930560
data:
temperature: >
{% set ta =
states('sensor.tado_smart_thermostat_ru3988930560_current_temperature')
| float %} {% set tv = ta + 0.15 %} {% if tv > 20.5 %} 20.5 {% else %}
{{ tv }} {% endif %}
action: climate.set_temperature
mode: single

3. dit heeft als functie het toevoegen van een hysterese anders blijft het systeem rond de 20,5 jutteren. Nu gaat de vraagtemp naar 20 als 20,5 bereikt wordt. Daar moet hij blijven tot de actuele temp ook weer onder de 20 komt, dan gaat hij weer in stapjes van o,15 omhoog

code:

alias: TV terug als Ta >= 20.5
triggers:
- entity_id: sensor.tado_smart_thermostat_ru3988930560_current_temperature
above: 20.49
trigger: numeric_state
conditions:
- condition: template
value_template: >
{% set start = states('input_datetime.tv_regeling_start') %} {% set
now_time = now().strftime('%H:%M:%S') %} {{ now_time >= start and now_time
<= '21:55:00' }}
actions:
- target:
entity_id: climate.tado_smart_thermostat_ru3988930560
data:
temperature: 20
action: climate.set_temperature
- entity_id: input_boolean.tv_verhoging_toegestaan
action: input_boolean.turn_off
mode: single

4. dit regelt de verhoging

code:

alias: Tv verhogen
triggers:
- entity_id: sensor.tado_smart_thermostat_ru3988930560_current_temperature
trigger: state
conditions:
- condition: template
value_template: >
{% set start = states('input_datetime.tv_regeling_start') %} {% set
now_time = now().strftime('%H:%M:%S') %} {{ now_time >= start and now_time
<= '21:55:00' }}
- condition: state
entity_id: input_boolean.tv_verhoging_toegestaan
state: "on"
- condition: numeric_state
entity_id: sensor.tado_smart_thermostat_ru3988930560_current_temperature
below: 20.5
actions:
- target:
entity_id: climate.tado_smart_thermostat_ru3988930560
data:
temperature: >
{% set ta =
states('sensor.tado_smart_thermostat_ru3988930560_current_temperature')
| float %} {% set tv = ta + 0.15 %} {% if tv > 20.5 %} 20.5 {% else %}
{{ tv }} {% endif %}
action: climate.set_temperature
mode: single

5. deze is nodig om als de tempverhoging onder de 20 gezakt is weer mogelijk t emaken

code:

alias: Verhoging toestaan bij Ta <=20
triggers:
- entity_id: sensor.tado_smart_thermostat_ru3988930560_current_temperature
below: 20.01
trigger: numeric_state
conditions:
- condition: template
value_template: >
{% set start = states('input_datetime.tv_regeling_start') %} {% set
now_time = now().strftime('%H:%M:%S') %} {{ now_time >= start and now_time
<= '21:55:00' }}
actions:
- entity_id: input_boolean.tv_verhoging_toegestaan
action: input_boolean.turn_on
mode: single

Een van de scripts creert een helper in het dashboard (zie screenshot). Daarmee stel je de tijd in wanneer de regeling van start kan gaan. (bv in het voorjaar als de buitentemp snel oploopt na een koude nacht is het efficienter om om 10 te beginnen ipv 8 uur)



Tot slot, ik heb in het script de entiteiten aangepast naar de Tado Homekit integratie en de Tado HA integratie verwijderd om geen problemen met de nieuwe api call limieten te krijgen.

[abbeyrules]

Ik heb recent een AE uitbreiding gekregen, ik kwam er eindelijk toe HA weer eens aan te zetten. Ik dacht gelijk even updaten van 0.6.0 naar de nieuwste 0.9.0 integratie. Nu krijg ik deze fout:


Iemand een idee wat er mis gaat?

[ Voor 15% gewijzigd door abbeyrules op 16-09-2025 21:41 ]

[Lasoul]

abbeyrules schreef op dinsdag 16 september 2025 @ 21:40:
Ik heb recent een AE uitbreiding gekregen, ik kwam er eindelijk toe HA weer eens aan te zetten. Ik dacht gelijk even updaten van 0.6.0 naar de nieuwste 0.9.0 integratie. Nu krijg ik deze fout:
[Afbeelding]

Iemand een idee wat er mis gaat?

Op zich zo niet maar het zou kunnen dat de migratie naar de nieuwe structuur niet wordt uitgevoerd en dat de integratie dan in de config_flow (setup) niet goed gaat. Zou je eens in de logfile willen kijken naar de gedetailleerde foutmelding?

Om het werkend te krijgen zou je de integratie kunnen weggooien en dan opnieuw configuren. Dat zou het probleem moeten oplossen.

[Erveetwee]

Ahem.
Lekkere beginnersvraag: Ik wilde aan de slag met m'n Quatt dashboard in HA, had ik de afgelopen maanden niet meer naar gekeken.

Krijg deze foutmelding te zien:

Ik denk te begrijpen dat ik bij Hub toevoegen het ip adres van mijn cic moet toevoegen.
Stomme is, als ik zoek in mijn netwerk (gebruik Fing op een Iphone) dan zie ik de CIC er niet tussen staan.

Waar maak ik fouten? Of wat voor naam moet ik op zoeken in mijn netwerk?

[Lasoul]

Erveetwee schreef op woensdag 17 september 2025 @ 15:20:
Ahem.
Lekkere beginnersvraag: Ik wilde aan de slag met m'n Quatt dashboard in HA, had ik de afgelopen maanden niet meer naar gekeken.

Krijg deze foutmelding te zien: [Afbeelding]

Ik denk te begrijpen dat ik bij Hub toevoegen het ip adres van mijn cic moet toevoegen.
Stomme is, als ik zoek in mijn netwerk (gebruik Fing op een Iphone) dan zie ik de CIC er niet tussen staan.

Waar maak ik fouten? Of wat voor naam moet ik op zoeken in mijn netwerk?

Je zou de bestaande configuratie kunnen weggooien en dan de CIC herstarten.
Als het goed is wordt de CIC (Quatt) automatisch door Home Assistant ontdekt en kun je hem toevoegen.

[Erveetwee]

Yes, dat deed de truc. Dank!


NB Volgens mij zijn nu wel alle oude entiteiten aangepast of hernoemd.

[Lasoul]

Erveetwee schreef op woensdag 17 september 2025 @ 16:03:
Yes, dat deed de truc. Dank!


NB Volgens mij zijn nu wel alle oude entiteiten aangepast of hernoemd.

Als je ze zelf geen andere naam hebt gegeven, dan zijn ze hetzelfde gebleven anders zijn ze inderdaad teruggezet naar de oorspronkelijke naam.

[Erveetwee]

Dat had ik wel gedaan zie ik.
Heb m'n grafieken aangepast en het werkt weer netjes. Dankjewel.

[TeslaNerd]

Hoe gaat het met jullie modbus sniffers nu de Quatts weer zijn gaan draaien?
Ik heb voor mijn gevoel meer CRC-fouten dan vorig stookseizoen en ik zie een aantal waarden van registers niet of maar incidenteel doorkomen.

[jj85]

@TeslaNerd net vandaag weer aangesloten. Draait als een zonnetje.

[TeslaNerd]

jj85 schreef op woensdag 1 oktober 2025 @ 17:19:
@TeslaNerd net vandaag weer aangesloten. Draait als een zonnetje.

Ik had problemen na de update van ESPHome naar 2025.8 en het werkt weer met 2025.5.2.
Met welke ESPHome firmware werkt het bij jou goed?

[jj85]

TeslaNerd schreef op woensdag 1 oktober 2025 @ 17:31:
[...]

Ik had problemen na de update van ESPHome naar 2025.8 en het werkt weer met 2025.5.2.
Met welke ESPHome firmware werkt het bij jou goed?

2025.6.3

[TeslaNerd]

jj85 schreef op woensdag 1 oktober 2025 @ 17:19:
@TeslaNerd net vandaag weer aangesloten. Draait als een zonnetje.

Ik zie dat mijn quatt sniffer wel data krijgt en via de modbus en modbus controller componenten verwerkt. En dat sommige registers (water temperatuur in en out en de buitentemperatuur) wel meelopen met dezelfde watertemperaturen via de JSON maar veel uitval hebben. Als de compressor aan staat dan zie ik geen beweging in de data voor stroomverbruik en ook niet voor compressorfrequentie etc.

[TeslaNerd]

jj85 schreef op woensdag 1 oktober 2025 @ 17:19:
@TeslaNerd net vandaag weer aangesloten. Draait als een zonnetje.

Bij mij loopt ie niet meer als een zonnetje

Ik zie dat mijn quatt sniffer wel data krijgt en via de modbus en modbus controller componenten verwerkt. En dat sommige registers (water temperatuur in en out en de buitentemperatuur) wel meelopen met dezelfde watertemperaturen via de JSON maar veel uitval hebben. Als de compressor aan staat dan zie ik geen beweging in de data voor overige temperaturen in de buitenunit, niet voor stroomverbruik en ook niet voor compressorfrequentie etc.

code:

INFO ESPHome 2025.6.3
INFO Reading configuration /config/esphome/modbustest.yaml...
INFO Updating https://github.com/M10tech/Quatt-sniffer@None
INFO Starting log output from 192.168.178.10 using esphome API
INFO Successfully resolved modbustest @ 192.168.178.10 in 0.000s
INFO Successfully connected to modbustest @ 192.168.178.10 in 0.109s
INFO Successful handshake with modbustest @ 192.168.178.10 in 0.054s
[09:17:30][I][app:137]: ESPHome version 2025.6.3 compiled on Oct  2 2025, 00:03:54
[09:17:30][I][app:139]: Project Tweakers.Quatt Modbus sniffer version v1.1.0
[09:17:30][C][wifi:613]: WiFi:
[09:17:30][C][wifi:434]:   Local MAC: DC:DA:0C:C5:6E:98
[09:17:30][C][wifi:439]:   SSID: 'RadioJaap'[redacted]
[09:17:30][C][wifi:442]:   IP Address: 192.168.178.10
[09:17:30][C][wifi:451]:   BSSID: 48:D3:43:4C:3C:01[redacted]
[09:17:30][C][wifi:451]:   Hostname: 'modbustest'
[09:17:30][C][wifi:451]:   Signal strength: -61 dB ▂▄▆█
[09:17:30][C][wifi:462]:   Channel: 6
[09:17:30][C][wifi:462]:   Subnet: 255.255.255.0
[09:17:30][C][wifi:462]:   Gateway: 192.168.178.1
[09:17:30][C][wifi:462]:   DNS1: 213.46.228.196
[09:17:30][C][wifi:462]:   DNS2: 62.179.104.196
[09:17:30][C][logger:215]: Logger:
[09:17:30][C][logger:215]:   Max Level: DEBUG
[09:17:30][C][logger:215]:   Initial Level: DEBUG
[09:17:30][C][logger:220]:   Log Baud Rate: 115200
[09:17:30][C][logger:220]:   Hardware UART: USB_CDC
[09:17:30][C][logger:224]:   Task Log Buffer Size: 768
[09:17:30][C][logger:229]:   Level for 'modbus': DEBUG
[09:17:30][C][logger:229]:   Level for 'modbus_controller.sensor': DEBUG
[09:17:30][C][logger:229]:   Level for 'sensor': DEBUG
[09:17:30][C][logger:229]:   Level for 'uart_debug': DEBUG
[09:17:30][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@11160 #20
[09:17:30][E][modbus_controller:176]: No matching range for sensor found - start_address : 0x2B98
[09:17:30][C][uart.arduino_esp32:151]: UART Bus 0:
[09:17:30][C][uart.arduino_esp32:153]:   RX Pin: GPIO20
[09:17:30][C][uart.arduino_esp32:155]:   RX Buffer Size: 256
[09:17:30][C][uart.arduino_esp32:162]:   Baud Rate: 19200 baud
[09:17:30][C][uart.arduino_esp32:162]:   Data Bits: 8
[09:17:30][C][uart.arduino_esp32:162]:   Parity: EVEN
[09:17:30][C][uart.arduino_esp32:162]:   Stop bits: 1
[09:17:30][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:30][C][modbus:176]: Modbus:
[09:17:30][C][modbus:177]: Version: 1.1.X
[09:17:30][C][modbus:179]:   Send Wait Time: 250 ms
[09:17:30][C][modbus:180]:   CRC Disabled: NO
[09:17:30][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:30][D][modbus_controller.sensor:025]: Sensor new state: 1.00
[09:17:30][D][sensor:099]: 'HP1 - Working Mode set by CiC': Sending state 1.00000  with 0 decimals of accuracy
[09:17:30][C][modbus_controller:367]: ModbusController:
[09:17:30][C][modbus_controller:368]: Version: 1.1.X
[09:17:30][C][modbus_controller:369]:   Address: 0x01
[09:17:30][C][modbus_controller:370]:   Max Command Retries: 4
[09:17:30][C][modbus_controller:371]:   Offline Skip Updates: 0
[09:17:30][C][modbus_controller:385]: ranges
[09:17:30][C][modbus_controller:388]:   Range type=3 start=0x7CF count=1 skip_updates=0
[09:17:30][C][modbus_controller:388]:   Range type=3 start=0x7DA count=1 skip_updates=0
[09:17:30][C][modbus_controller:388]:   Range type=3 start=0x7DF count=1 skip_updates=0
[09:17:30][C][modbus_controller:388]:   Range type=3 start=0x833 count=40 skip_updates=0
[09:17:30][C][modbus_controller:388]:   Range type=3 start=0xF9F count=1 skip_updates=0
[09:17:30][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:30][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:30][D][modbus_controller.sensor:025]: Sensor new state: 4096.00
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Compressor Level set by CiC'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][D][uart_debug:114]: <<< 01,06,0F,9F,00,02,3B,31,01,06,0F,9F,00,02,3B,31,01,06,07,CF,00,01,79,41,01,06,07,CF,00,01,79,41,01,06,07,DA,10,00,A4,85
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Pump Mode set by CiC'
[09:17:30]modbus_controller.sensor  State Class: ''
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Pump Level set by CiC'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Working Mode set by CiC'
[09:17:30]modbus_controller.sensor  State Class: ''
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:30][D][modbus_controller.sensor:025]: Sensor new state: 505.00
[09:17:30][D][sensor:099]: 'HP1 - Pump Mode set by CiC': Sending state 505.00000  with 0 decimals of accuracy
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Working Mode Actual'
[09:17:30]modbus_controller.sensor  State Class: ''
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][D][uart_debug:114]: <<< 01,06,07,DA,10,00,A4,85,01,06,07,DF,01,F9,78,96
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Compressor AC Voltage'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'V'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 1
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'voltage'
[09:17:30][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2015 #1
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Compressor AC Current'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'A'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'current'
[09:17:30][D][uart_debug:114]: <<< 01,06,07,DF,01,F9,78,96
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Compressor Frequency Demand'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'Hz'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'frequency'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Compressor Frequency Actual'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'Hz'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'frequency'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Fan Speed Maximum'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'RPM'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'speed'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Icon: 'mdi:fan'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Fan Speed Actual'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'RPM'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'speed'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Icon: 'mdi:fan'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Electric Expansion Valve'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'p'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Other bits R2108'
[09:17:30]modbus_controller.sensor  State Class: ''
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - EV1 steps'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'p'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Outside Temperature'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: '°C'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'temperature'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Evaporator Coil Temperature'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: '°C'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'temperature'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Gas Discharge Temperature'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: '°C'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'temperature'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Gas Return Temperature'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: '°C'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'temperature'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Evaporator Pressure'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'bar'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'pressure'
[09:17:30][D][uart_debug:114]: <<< 01,03,08,33,00,28,B7,BB
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Condenser Pressure'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'bar'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'pressure'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Status bits R2119'
[09:17:30]modbus_controller.sensor  State Class: ''
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Status bits R2120'
[09:17:30]modbus_controller.sensor  State Class: ''
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Status bits R2121'
[09:17:30]modbus_controller.sensor  State Class: ''
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Firmware Version'
[09:17:30]modbus_controller.sensor  State Class: ''
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][D][modbus:140]: good CRC as client for address=1     with FC=3 , offset=3 and len=80  => start@2015 #1
[09:17:30][D][modbus_controller.sensor:025]: Sensor new state: 2.00
[09:17:30][D][sensor:099]: 'HP1 - Pump Level set by CiC': Sending state 0.02000  with 2 decimals of accuracy
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - EEPROM Version'
[09:17:30]modbus_controller.sensor  State Class: ''
[09:17:30]modbus_controller.sensor  Unit of Measurement: ''
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 0
[09:17:30][D][uart_debug:114]: <<< 01,03,50,00,02,00,DA,00,0E,00,1E,00,1E,02,8A,02,6E,00,00,01,2E,08,01,01,F4,11,A1,0E,2C,1A,6E,0E,2C,00,00,38,00,00,58,00,B2,00,00,00,00,00,00,00,00,01,19,00,72,00,02,2E,78,00,00,00,37,0B,B8,0B,B8,00,00,17,50,0E,39,16,16,16,D5,16,69,0B,B8,00,E6,00,00,C5,FC
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Condensing Temperature'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: '°C'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'temperature'
[09:17:30][D][modbus:140]: good CRC as server for address=1     with FC=3 , offset=2 and len=4   => start@11160 #20
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Evaporating Temperature'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: '°C'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'temperature'
[09:17:30][D][uart_debug:114]: <<< 01,03,2B,98,00,14,CD,CE
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Water In Temperature'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: '°C'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'temperature'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Water Out Temperature'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: '°C'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'temperature'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Condenser Coil Temperature'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: '°C'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'temperature'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Pump Power'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'W'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'power'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'HP1 - Pump Flow'
[09:17:30]modbus_controller.sensor  State Class: 'measurement'
[09:17:30]modbus_controller.sensor  Unit of Measurement: 'L/h'
[09:17:30]modbus_controller.sensor  Accuracy Decimals: 2
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Device Class: 'volume_flow_rate'
[09:17:30][C][modbus_controller.sensor:010]: modbus_controller.sensor  Icon: 'mdi:gauge'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Fan Low Speed Mode'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Bottom Heater'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Crankcase Heater'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Fan Defrost Speed Mode'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Fan High Speed Mode'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - 4way Valve'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Pump Relay'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Defrost Mode'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Alarm - Main Line Current'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Info - Compressor Oil Return'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Alarm - High Pressure Switch'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Alarm - 1st Start Pre-heat'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Alarm - AC High/Low Voltage'
[09:17:30][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'HP1 - Alarm - Low Pressure Switch'
[09:17:31][C][esphome.ota:077]: Over-The-Air updates:
[09:17:31][C][esphome.ota:077]:   Address: modbustest.local:3232
[09:17:31][C][esphome.ota:077]:   Version: 2
[09:17:31][C][esphome.ota:080]:   Password configured
[09:17:31][C][safe_mode:018]: Safe Mode:
[09:17:31][C][safe_mode:025]:   Boot considered successful after 60 seconds
[09:17:31][C][safe_mode:025]:   Invoke after 10 boot attempts
[09:17:31][C][safe_mode:025]:   Remain for 300 seconds
[09:17:31][C][api:185]: API Server:
[09:17:31][C][api:185]:   Address: modbustest.local:6053
[09:17:31][C][api:187]:   Using noise encryption: YES
[09:17:31][C][mdns:125]: mDNS:
[09:17:31][C][mdns:125]:   Hostname: modbustest
[09:17:31][D][uart_debug:114]: <<< 01,03,2B,D3,00,14,BD,D8
[09:17:32][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@11160 #20
[09:17:32][E][modbus_controller:176]: No matching range for sensor found - start_address : 0x2B98
[09:17:32][D][uart_debug:114]: <<< 01,06,0F,9F,00,02,3B,31
[09:17:32][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:32][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:32][D][modbus_controller.sensor:025]: Sensor new state: 1.00
[09:17:32][D][sensor:099]: 'HP1 - Working Mode set by CiC': Sending state 1.00000  with 0 decimals of accuracy
[09:17:32][D][uart_debug:114]: <<< 01,06,0F,9F,00,02,3B,31,01,06,07,CF,00,01,79,41
[09:17:32][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:32][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:32][D][modbus_controller.sensor:025]: Sensor new state: 4096.00
[09:17:32][D][uart_debug:114]: <<< 01,06,07,CF,00,01,79,41,01,06,07,DA,10,00,A4,85
[09:17:32][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:32][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:32][D][modbus_controller.sensor:025]: Sensor new state: 506.00
[09:17:32][D][sensor:099]: 'HP1 - Pump Mode set by CiC': Sending state 506.00000  with 0 decimals of accuracy
[09:17:32][D][uart_debug:114]: <<< 01,06,07,DA,10,00,A4,85,01,06,07,DF,01,FA,38,97
[09:17:33][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2015 #1
[09:17:33][D][uart_debug:114]: <<< 01,06,07,DF,01,FA,38,97
[09:17:33][D][uart_debug:114]: <<< 01,03,08,33,00,28,B7,BB
[09:17:33][D][modbus:140]: good CRC as client for address=1     with FC=3 , offset=3 and len=80  => start@2015 #1
[09:17:33][D][modbus_controller.sensor:025]: Sensor new state: 2.00
[09:17:33][D][sensor:099]: 'HP1 - Pump Level set by CiC': Sending state 0.02000  with 2 decimals of accuracy
[09:17:33][D][modbus:140]: good CRC as server for address=1     with FC=3 , offset=2 and len=4   => start@11160 #20
[09:17:33][D][uart_debug:114]: <<< 01,03,50,00,02,00,DA,00,0E,00,1E,00,1E,02,8A,02,67,00,00,01,30,08,01,01,F4,11,A1,0E,2C,1A,6E,0E,2C,00,00,38,00,00,58,00,B2,00,00,00,00,00,00,00,00,01,19,00,72,00,02,2E,78,00,00,00,37,0B,B8,0B,B8,00,00,17,50,0E,39,16,16,16,D5,16,69,0B,B8,00,E6,00,00,EC,67,01,03,2B,98,00,14,CD,CE
[09:17:34][D][uart_debug:114]: <<< 01,03,2B,D3,00,14,BD,D8
[09:17:35][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@11160 #20
[09:17:35][E][modbus_controller:176]: No matching range for sensor found - start_address : 0x2B98
[09:17:35][D][uart_debug:114]: <<< 01,06,0F,9F,00,02,3B,31
[09:17:35][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:35][D][uart_debug:114]: <<< 01,06,0F,9F,00,02,3B,31
[09:17:35][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:35][D][modbus_controller.sensor:025]: Sensor new state: 1.00
[09:17:35][D][sensor:099]: 'HP1 - Working Mode set by CiC': Sending state 1.00000  with 0 decimals of accuracy
[09:17:35][D][uart_debug:114]: <<< 01,06,07,CF,00,01,79,41
[09:17:35][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:35][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:35][D][modbus_controller.sensor:025]: Sensor new state: 4096.00
[09:17:35][D][uart_debug:114]: <<< 01,06,07,CF,00,01,79,41,01,06,07,DA,10,00,A4,85
[09:17:35][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:35][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:35][D][modbus_controller.sensor:025]: Sensor new state: 506.00
[09:17:35][D][sensor:099]: 'HP1 - Pump Mode set by CiC': Sending state 506.00000  with 0 decimals of accuracy
[09:17:35][D][uart_debug:114]: <<< 01,06,07,DA,10,00,A4,85,01,06,07,DF,01,FA,38,97
[09:17:35][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2015 #1
[09:17:35][D][uart_debug:114]: <<< 01,06,07,DF,01,FA,38,97
[09:17:35][D][uart_debug:114]: <<< 01,03,08,33,00,28,B7,BB
[09:17:35][D][modbus:140]: good CRC as client for address=1     with FC=3 , offset=3 and len=80  => start@2015 #1
[09:17:35][D][modbus:140]: good CRC as server for address=1     with FC=3 , offset=2 and len=4   => start@11160 #20
[09:17:35][D][modbus_controller.sensor:025]: Sensor new state: 2.00
[09:17:35][D][sensor:099]: 'HP1 - Pump Level set by CiC': Sending state 0.02000  with 2 decimals of accuracy
[09:17:35][D][uart_debug:114]: <<< 01,03,50,00,02,00,DA,00,0E,00,1E,00,1E,02,8A,02,67,00,00,01,30,08,01,01,F4,11,A1,0E,2C,1A,6E,0E,35,00,00,38,00,00,59,00,B3,00,00,00,00,00,00,00,00,01,19,00,72,00,02,2E,78,00,00,00,37,0B,B8,0B,B8,00,00,17,65,0E,5A,16,16,16,D5,16,69,0B,B8,00,E6,00,00,23,FC,01,03,2B,98,00,14,CD,CE
[09:17:36][D][uart_debug:114]: <<< 01,03,2B,D3,00,14,BD,D8
[09:17:37][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@11160 #20
[09:17:37][E][modbus_controller:176]: No matching range for sensor found - start_address : 0x2B98
[09:17:37][D][uart_debug:114]: <<< 01,06,0F,9F,00,02,3B,31
[09:17:37][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:37][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:37][D][modbus_controller.sensor:025]: Sensor new state: 1.00
[09:17:37][D][sensor:099]: 'HP1 - Working Mode set by CiC': Sending state 1.00000  with 0 decimals of accuracy
[09:17:37][D][uart_debug:114]: <<< 01,06,0F,9F,00,02,3B,31,01,06,07,CF,00,01,79,41
[09:17:37][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:37][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:37][D][modbus_controller.sensor:025]: Sensor new state: 4096.00
[09:17:37][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:37][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:37][D][modbus_controller.sensor:025]: Sensor new state: 506.00
[09:17:37][D][sensor:099]: 'HP1 - Pump Mode set by CiC': Sending state 506.00000  with 0 decimals of accuracy
[09:17:37][D][uart_debug:114]: <<< 01,06,07,CF,00,01,79,41,01,06,07,DA,10,00,A4,85,01,06,07,DA,10,00,A4,85,01,06,07,DF,01,FA,38,97
[09:17:37][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2015 #1
[09:17:37][D][uart_debug:114]: <<< 01,06,07,DF,01,FA,38,97
[09:17:38][D][uart_debug:114]: <<< 01,03,08,33,00,28,B7,BB
[09:17:38][D][modbus:140]: good CRC as client for address=1     with FC=3 , offset=3 and len=80  => start@2015 #1
[09:17:38][D][modbus_controller.sensor:025]: Sensor new state: 2.00
[09:17:38][D][sensor:099]: 'HP1 - Pump Level set by CiC': Sending state 0.02000  with 2 decimals of accuracy
[09:17:38][D][modbus:140]: good CRC as server for address=1     with FC=3 , offset=2 and len=4   => start@11160 #20
[09:17:38][D][uart_debug:114]: <<< 01,03,50,00,02,00,DB,00,0E,00,1E,00,1E,02,8A,02,67,00,00,01,30,08,01,01,F4,11,A1,0E,35,1A,6E,0E,35,00,00,38,00,00,59,00,B3,00,00,00,00,00,00,00,00,01,19,00,72,00,02,2E,78,00,00,00,37,0B,B8,0B,B8,00,00,17,65,0E,5A,16,16,16,D5,16,69,0B,B8,00,E6,00,00,37,E1,01,03,2B,98,00,14,CD,CE
[09:17:39][D][uart_debug:114]: <<< 01,03,2B,D3,00,14,BD,D8
[09:17:40][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@11160 #20
[09:17:40][E][modbus_controller:176]: No matching range for sensor found - start_address : 0x2B98
[09:17:40][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:40][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@3999 #1
[09:17:40][D][modbus_controller.sensor:025]: Sensor new state: 1.00
[09:17:40][D][sensor:099]: 'HP1 - Working Mode set by CiC': Sending state 1.00000  with 0 decimals of accuracy
[09:17:40][D][uart_debug:114]: <<< 01,06,0F,9F,00,02,3B,31,01,06,0F,9F,00,02,3B,31,01,06,07,CF,00,01,79,41
[09:17:40][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:40][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@1999 #1
[09:17:40][D][modbus_controller.sensor:025]: Sensor new state: 4096.00
[09:17:40][D][uart_debug:114]: <<< 01,06,07,CF,00,01,79,41,01,06,07,DA,10,00,A4,85
[09:17:40][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:40][D][modbus:140]: good CRC as client for address=1     with FC=6 , offset=2 and len=4   => start@2010 #1
[09:17:40][D][modbus_controller.sensor:025]: Sensor new state: 506.00
[09:17:40][D][sensor:099]: 'HP1 - Pump Mode set by CiC': Sending state 506.00000  with 0 decimals of accuracy
[09:17:40][D][uart_debug:114]: <<< 01,06,07,DA,10,00,A4,85,01,06,07,DF,01,FA,38,97
[09:17:40][D][modbus:140]: good CRC as server for address=1     with FC=6 , offset=2 and len=4   => start@2015 #1
[09:17:40][D][uart_debug:114]: <<< 01,06,07,DF,01,FA,38,97
[09:17:40][D][uart_debug:114]: <<< 01,03,08,33,00,28,B7,BB
[09:17:40][D][modbus:140]: good CRC as client for address=1     with FC=3 , offset=3 and len=80  => start@2015 #1
[09:17:40][D][modbus_controller.sensor:025]: Sensor new state: 2.00
[09:17:40][D][sensor:099]: 'HP1 - Pump Level set by CiC': Sending state 0.02000  with 2 decimals of accuracy
[09:17:40][D][modbus:140]: good CRC as server for address=1     with FC=3 , offset=2 and len=4   => start@11160 #20
[09:17:40][D][uart_debug:114]: <<< 01,03,50,00,02,00,DB,00,0E,00,1E,00,1E,02,8A,02,67,00,00,01,30,08,01,01,F4,11,A1,0E,35,1A,6E,0E,35,00,00,38,00,00,59,00,B3,00,00,00,00,00,00,00,00,01,19,00,72,00,02,2E,78,00,00,00,37,0B,B8,0B,B8,00,00,17,65,0E,5A,16,16,16,D5,16,69,0B,B8,00,DC,00,00,17,EC,01,03,2B,98,00,14,CD,CE

[jj85]

@TeslaNerd Ik heb, realiseer ik mij nu, de meeste logging een tandje lager staan. Dus waarschijnlijk zie ik daardoor ook geen eventuele CRC-errors

code:

[09:24:05.684][C][logger:215]: Logger:
[09:24:05.684][C][logger:215]:   Max Level: DEBUG
[09:24:05.684][C][logger:215]:   Initial Level: DEBUG
[09:24:05.684][C][logger:220]:   Log Baud Rate: 0
[09:24:05.684][C][logger:220]:   Hardware UART: USB_CDC
[09:24:05.684][C][logger:224]:   Task Log Buffer Size: 768
[09:24:05.685][C][logger:229]:   Level for 'modbus': INFO
[09:24:05.690][C][logger:229]:   Level for 'modbus_controller.sensor': WARN
[09:24:05.690][C][logger:229]:   Level for 'sensor': WARN
[09:24:05.690][C][logger:229]:   Level for 'uart_debug': ERROR

Freq en current gaan hier prima

[TeslaNerd]

jj85 schreef op donderdag 2 oktober 2025 @ 09:25:
@TeslaNerd Ik heb, realiseer ik mij nu, de meeste logging een tandje lager staan. Dus waarschijnlijk zie ik daardoor ook geen eventuele CRC-errors

code:

[09:24:05.684][C][logger:215]: Logger:
[09:24:05.684][C][logger:215]:   Max Level: DEBUG
[09:24:05.684][C][logger:215]:   Initial Level: DEBUG
[09:24:05.684][C][logger:220]:   Log Baud Rate: 0
[09:24:05.684][C][logger:220]:   Hardware UART: USB_CDC
[09:24:05.684][C][logger:224]:   Task Log Buffer Size: 768
[09:24:05.685][C][logger:229]:   Level for 'modbus': INFO
[09:24:05.690][C][logger:229]:   Level for 'modbus_controller.sensor': WARN
[09:24:05.690][C][logger:229]:   Level for 'sensor': WARN
[09:24:05.690][C][logger:229]:   Level for 'uart_debug': ERROR

Freq en current gaan hier prima
[Afbeelding]

Ja, dat klopt. Ik heb wat extra regels toe moeten voegen om de debug aan de praat te krijgen:

code:

external_components:
  # use all components from GitHub repository
  - source:
      type: git
      url: https://github.com/M10tech/Quatt-sniffer
      #type: local
      #path: components
    components: [ modbus, modbus_controller ]
    refresh: 5min  ## use this temporarily if you recently updated the repo, else disable for default 24h  

# Enable logging
logger:
  #baud_rate: 0                         ## Turn off logging via UART (set baudrate to 0) in case the RS485 uses the onboard UART (tx/rx)
                                        ## However, in sniffer mode and with detached TX hardware trace this is not needed
  level: DEBUG
  logs:
    uart_debug: DEBUG                   ## suppress log-messages from uart
    modbus: DEBUG                        ## suppress log-messages from modbus
    modbus_controller.sensor: DEBUG      ## suppress log-messages from modbus_controller.sensor
    sensor: DEBUG                        ## suppress log-messages from modbus_controller  

uart:                 ## Igor Ybema: The RS485 is connected to the ESP32-C3 via hardware uart, rx/tx (gpio20/gpio21).
  id: uart_bus
  # tx_pin: GPIO21    ## just listening: tx_pin not specified
  rx_pin: GPIO20
  baud_rate: 19200    ## start bit na 52us: 19200 baud zie https://discord.com/chann...24364/1232080954466631761
  data_bits: 8
  parity: EVEN
  stop_bits: 1
  debug:
    after: 
      timeout: 10ms
    sequence:
      - lambda: UARTDebug::log_hex(direction, bytes, ',');    ## toon modbus data als hex waarden in uart_debug log

[TeslaNerd]

Het esp32 met rs485 boardje van @thehog is niet meer beschikbaar [out of stock] op Tindie.com.

Wat is jullie advies voor een alternatief boardje voor eenvoudige setup voor de Quatt modbus sniffer?

[ Voor 32% gewijzigd door TeslaNerd op 06-10-2025 12:38 ]

[jj85]

TeslaNerd schreef op maandag 6 oktober 2025 @ 12:36:
Het esp32 met rs485 boardje van @thehog is niet meer beschikbaar [out of stock] op Tindie.com.

Wat is jullie advies voor een alternatief boardje voor eenvoudige setup voor de Quatt modbus sniffer?

Ben wel gecharmeerd van de Atom m5stack met RS485 base, maar die heb ik nog niet werkend gekregen (CiC doet dan helemaal niks meer).

Maar verder wel mooi compact etc. Dus tzt nog eens verder induiken.

[TeslaNerd]

jj85 schreef op maandag 6 oktober 2025 @ 12:54:
[...]

Ben wel gecharmeerd van de Atom m5stack met RS485 base, maar die heb ik nog niet werkend gekregen (CiC doet dan helemaal niks meer).

Maar verder wel mooi compact etc. Dus tzt nog eens verder induiken.

[Afbeelding]

Ja, die ziet er strak uit. Kan jij de tx blokkeren zoals beschreven op de quatt sniffer github?

[jj85]

TeslaNerd schreef op maandag 6 oktober 2025 @ 12:57:
[...]

Ja, die ziet er strak uit. Kan jij de tx blokkeren zoals beschreven op de quatt sniffer github?

Ja vast wel, schematic staat ook gewoon online
https://docs.m5stack.com/...20RS485%20Base#schematics

R1, R4, R5 en R6 eruit zal vast werken, maar ik heb een werkende op het bekende tindie bordje, dus ga m'n M5stack nu niet slopen

Misschien dat @MWink z'n sniffer boardje ook al beschikbaar heeft?

[RickvdT]

RickvdT schreef op donderdag 10 juli 2025 @ 13:13:
LilyGo T-CAN485 boardje voor 10 euro mee besteld. Ik zal t.z.t. laten weten of dit zo makkelijk gaat werken als gehoopt.

Dit is ook een mooi bordje, maar je moet waarschijnlijk ook hier de tx blokkeren wil het werken. Lukte mij in ieder geval niet out-of-the-box. Ik heb de tx gelaten en hem voor een ander project gebruikt.

[RickvdT]

Momenteel is een thuisbatterij nog geen interessante optie voor ons. Afgelopen zomer heb ik een automation gemaakt om bij overtollige PV de zwembad warmtepomp te laten draaien. Ik liep al een tijdje met het idee om hetzelfde te doen in het najaar met de Quatt. Aangezien in het hele huis lage temperatuur vloerverwarming ligt is het idee om met overtollige PV het huis op te warmen en dat dit de rest van de dag wordt afgegeven. Dit idee https://www.weheat.nl/inzichten/warmtepomp-als-thuisbatterij

Na wat tweaken werkt het nu best aardig. Op een wisselvallige dag als vandaag hebben de Quatts toch 4 uur op vrijwel alleen zonne energie gedraait. De 0,9 graad verhoging is ruimschoots genoeg om het warmteverlies te dekken. Ik hoop op deze manier een groot deel van oktober en maart/april kosteloos te kunnen stoken.


Zie onderstaande voor de yaml. p1_vermogen_20_min_ma is een 20 Minute moving average filter helper om bij dagen met wisselend weer geen pendelgedrag te krijgen. Tado entities zijn deels Homekit en deels de officiele Tado integratie. Vanwege de api rate limits was ik met Homekit begonnen om er achter te komen dat deze geen hvac_mode en overlay kent. Mocht iemand opmerkingen of suggesties hebben hoor ik het graag!

code:

alias: Thermostaat op Zonne-energie
description: >
  Past de Tado temperatuur aan op basis van energie teruglevering
triggers:
  - minutes: /5
    trigger: time_pattern
conditions:
  - condition: sun
    after: sunrise
    before: sunset
actions:
  - variables:
      rolling_average_power: "{{ states('sensor.p1_vermogen_20_min_ma') | float(0) }}"
      current_set_temp: >-
        {{ state_attr('climate.tado_smart_thermostat_su3953355264',
        'temperature') | float(0) }}
      max_temp: 22
      min_temp: 19.5
      home_idle_use: 250
      current_actual_temp: >-
        {{
        states('sensor.tado_smart_thermostat_su3953355264_current_temperature')
        | float(0) }}
      increase_step: 0.2
      decrease_step: 0.2
  - choose:
      - conditions:
          - condition: template
            value_template: |
              {{ states('sensor.p1_vermogen_20_min_ma')|float >
               ( home_idle_use + states('sensor.heatpump_total_power_input')|float ) }}
        sequence:
          - target:
              entity_id: climate.kamer_1
            data:
              hvac_mode: auto
            action: climate.set_hvac_mode
      - conditions:
          - condition: numeric_state
            entity_id: sensor.p1_vermogen_20_min_ma
            below: -400
          - condition: template
            value_template: "{{ current_actual_temp < max_temp }}"
        sequence:
          - choose:
              - conditions:
                  - condition: state
                    entity_id: sensor.heatpump_qc_supervisory_control_mode
                    state: Standby
                sequence:
                  - target:
                      entity_id: climate.tado_smart_thermostat_su3953355264
                    data:
                      temperature: >-
                        {{ [current_actual_temp + increase_step, max_temp] | min
                        }}
                    action: climate.set_temperature
            default:
              - target:
                  entity_id: climate.tado_smart_thermostat_su3953355264
                data:
                  temperature: "{{ [current_set_temp + increase_step, max_temp] | min }}"
                action: climate.set_temperature
      - conditions:
          - condition: numeric_state
            entity_id: sensor.p1_vermogen_20_min_ma
            above: 0
          - condition: state
            entity_id: sensor.heatpump_qc_supervisory_control_mode_code
            state:
              - '2'
              - '3'
          - condition: template
            value_template: |
              {{ is_state('binary_sensor.kamer_1_overlay', 'on') }}
        sequence:
          - target:
              entity_id: climate.tado_smart_thermostat_su3953355264
            data:
              temperature: "{{ [current_set_temp - decrease_step, min_temp] | max }}"
            action: climate.set_temperature
mode: single

[maxtrash]

ik weet dat de quatt een beperkt aantal compressorniveaus kent en ik zou graag de quatt graag zo willen sturen dat hij een bepaalde powerinput vasthoudt. Nu kan ik via de diyless thermostaat perfect een room temperature, setpoint en control setpoint doorsturen naar de Quatt.

De control setpoint zet ik op 30 graden.
Als ik de temperatuur op 18 zet en setpoint op 18,1 gaat hij rustig draaien op ongeveer 289 Watt.
als ik nu setpoint verhoog naar 18,2 of 18,3, of 18,4 blijft hij op hetzelfde niveau. Toen ik op 18,5 zette werd het om de 40-50 minuten gegeven moment 516, 711 en 838 Watt.

Dus als de CIC constateert dat er geen schot in zit (verschil blijft 0.5) gaat hij op een gegeven moment het vermogen opschroeven.
Logisch, maar zijn er meer mensen mee bezig en wat is jullie ervaring?
Wat ik zou willen bereiken is dat ik hem kan laten werken op een bepaald vermogen als ik bijvoorbeeld zonnestroom over heb.

[TeslaNerd]

maxtrash schreef op zaterdag 11 oktober 2025 @ 22:50:
ik weet dat de quatt een beperkt aantal compressorniveaus kent en ik zou graag de quatt graag zo willen sturen dat hij een bepaalde powerinput vasthoudt. Nu kan ik via de diyless thermostaat perfect een room temperature, setpoint en control setpoint doorsturen naar de Quatt.

De control setpoint zet ik op 30 graden.
Als ik de temperatuur op 18 zet en setpoint op 18,1 gaat hij rustig draaien op ongeveer 289 Watt.
als ik nu setpoint verhoog naar 18,2 of 18,3, of 18,4 blijft hij op hetzelfde niveau. Toen ik op 18,5 zette werd het om de 40-50 minuten gegeven moment 516, 711 en 838 Watt.

Dus als de CIC constateert dat er geen schot in zit (verschil blijft 0.5) gaat hij op een gegeven moment het vermogen opschroeven.
Logisch, maar zijn er meer mensen mee bezig en wat is jullie ervaring?
Wat ik zou willen bereiken is dat ik hem kan laten werken op een bepaald vermogen als ik bijvoorbeeld zonnestroom over heb.

Ja, ik ben daar mee bezig geweest en inderdaad is de delta tussen kamer temperatuur en room setpoint de belangrijkste driver voor het compressor niveau (9 stappen 30Hz-90Hz) dat de CiC vraagt aan de buitenunit. En er zijn dan andere drivers die in mindere mate invloed hierop hebben, oa de buitentemperatuur en zoals jij aangeeft hoeveel schot er zit in het reduceren van de delta_room_temperature_to_room_setpoint.
Ik heb dit opgelost met een feedback-loop tussen de delta_room_temperature_to_room_setpoint en de compressor_frequency.
NB de CiC stuurt de compressorfrequency maar niet de powerinput. De powerinput wordt door de controller in de buitenunit aangestuurd waarbij de watertemperatuur ook een rol speelt: de powerinput loopt op met de watertemperatuur ook als de compressorfrequentie gelijk blijft.
Ik denk dat een feedbackloop van de delta_room_temperature_to_room_setpoint op het vermogen van de zonnepanelen mogelijk is met de beperking dat de minimale powerinput ook afhankelijk blijft van de watertemperatuur

[s020506]

maxtrash schreef op zaterdag 11 oktober 2025 @ 22:50:
ik weet dat de quatt een beperkt aantal compressorniveaus kent en ik zou graag de quatt graag zo willen sturen dat hij een bepaalde powerinput vasthoudt. Nu kan ik via de diyless thermostaat perfect een room temperature, setpoint en control setpoint doorsturen naar de Quatt.

De control setpoint zet ik op 30 graden.
Als ik de temperatuur op 18 zet en setpoint op 18,1 gaat hij rustig draaien op ongeveer 289 Watt.
als ik nu setpoint verhoog naar 18,2 of 18,3, of 18,4 blijft hij op hetzelfde niveau. Toen ik op 18,5 zette werd het om de 40-50 minuten gegeven moment 516, 711 en 838 Watt.

Dus als de CIC constateert dat er geen schot in zit (verschil blijft 0.5) gaat hij op een gegeven moment het vermogen opschroeven.
Logisch, maar zijn er meer mensen mee bezig en wat is jullie ervaring?
Wat ik zou willen bereiken is dat ik hem kan laten werken op een bepaald vermogen als ik bijvoorbeeld zonnestroom over heb.

Een warmtepomp regeling is gemaakt om je huis warm te houden, niet om maximaal zonnestroom te verbruiken. En dan zit de CiC er nog tussen, die het helemaal onvoorspelbaar maakt. Op een zonnige dag krijg je dit nog wel gemaakt. Als er veel wolkjes zijn, zal het een moeilijke regeling worden die niet goed gaat werken.

Ik zou het simpel houden en het setpoint 0,3 graden hoger zetten als de zijn schijnt.

[raven22]

maxtrash schreef op zaterdag 11 oktober 2025 @ 22:50:
ik weet dat de quatt een beperkt aantal compressorniveaus kent en ik zou graag de quatt graag zo willen sturen dat hij een bepaalde powerinput vasthoudt. Nu kan ik via de diyless thermostaat perfect een room temperature, setpoint en control setpoint doorsturen naar de Quatt.

De control setpoint zet ik op 30 graden.
Als ik de temperatuur op 18 zet en setpoint op 18,1 gaat hij rustig draaien op ongeveer 289 Watt.
als ik nu setpoint verhoog naar 18,2 of 18,3, of 18,4 blijft hij op hetzelfde niveau. Toen ik op 18,5 zette werd het om de 40-50 minuten gegeven moment 516, 711 en 838 Watt.

Dus als de CIC constateert dat er geen schot in zit (verschil blijft 0.5) gaat hij op een gegeven moment het vermogen opschroeven.
Logisch, maar zijn er meer mensen mee bezig en wat is jullie ervaring?
Wat ik zou willen bereiken is dat ik hem kan laten werken op een bepaald vermogen als ik bijvoorbeeld zonnestroom over heb.

ik draai een home assistant script welke de vraagtemperatuur met 0.1 verhoogd op het moment dat de actuele temp de vraagtemperatuur bijna bereikt heeft. in het script zitten een aantal in te stellen parameters, zoals starttijd, max vraagtemperatuur ed. bij jouw zou je er als voorwaarde een overschot aan zonnestroom aan kunnen toevoegen

[TeslaNerd]

Ik heb in Home Assistant met de gegevens uit de Quatt integratie een automatisering gemaakt die de hoeveelheid water in het systeem berekent bij een koude start van de warmtepomp

De automatisering triggered wanneer:
- de flowrate boven de 700 liter per uur komt, en
- de power input boven de 100 Watt komt, dat is wanneer de compressor start met water verwarmen.
Het moment van deze triggers is de starttijd.
Vervolgens stopt de tijd wanneer de tempertuur van het retourwater begint op te lopen nadat het minimaal 1 minuut constant is gebleven.
De gemeten tijdsduur is het verschil tussen eindtijd en starttijd.
In de grafiek was dit 2,5 minuut van 16:44:30 tot 16:46:00.

Is mijn aanname correct dat de hoeveelheid water in het systeem gelijk is aan de flow maal de verstreken tijd dat het duurt om de hoeveelheid water 1 keer rond te pompen?

Met de constante flow van 800 L/uur was de gepasseerde hoeveelheid water dan 2,5 / 60 * 800 = 33 liter water.

NB maak eerst de helper: input_number.water_volume aan in Home Assistant

code:

alias: Bepaal hoeveelheid water in het systeem
description: ""
triggers:
  - entity_id: sensor.heatpump_1_power_input
    above: 100
    trigger: numeric_state
conditions:
  - condition: numeric_state
    entity_id: sensor.flowmeter_flowrate
    above: 700
actions:
  - variables:
      start_temp: "{{ states('sensor.heatpump_1_temperature_water_in') | float }}"
      start_time: "{{ as_timestamp(now()) }}"  # Store timestamp in seconds
      flow_rate: 800
  - delay: "00:01:00"
  - wait_template: >-
      {{ states('sensor.heatpump_1_temperature_water_in') | float > (start_temp + 0.1) }}
    timeout: "00:10:00"
  - variables:
      end_time: "{{ as_timestamp(now()) }}"  # Store timestamp in seconds
      time_delay: "{{ (end_time - start_time) / 3600 | float }}"  # Calculate hours
      water_volume: "{{ flow_rate * time_delay | float }}"
  - target:
      entity_id: input_number.water_volume
    data:
      value: "{{ water_volume | round(1) }}"
    action: input_number.set_value
  - data:
      title: Water Volume Calculated
      message: >-
        Estimated water volume in the system is {{ water_volume | round(1) }} liters.
    action: persistent_notification.create

[ Voor 36% gewijzigd door TeslaNerd op 12-10-2025 21:28 ]

[raven22]

TeslaNerd schreef op zondag 12 oktober 2025 @ 18:02:
Ik heb in Home Assistant met de gegevens uit de Quatt integratie een automatisering gemaakt die de hoeveelheid water in het systeem berekent bij een koude start van de warmtepomp

De automatisering triggered wanneer:
- de flowrate boven de 700 liter per uur komt, en
- de power input boven de 100 Watt komt, dat is wanneer de compressor start met water verwarmen.
Het moment van deze triggers is de starttijd.
Vervolgens stopt de tijd wanneer de tempertuur van het retourwater begint op te lopen nadat het minimaal 1 minuut constant is gebleven.
De gemeten tijdsduur is het verschil tussen eindtijd en starttijd.
In de grafiek was dit 2,5 minuut van 16:44:30 tot 16:46:00.

Is mijn aanname correct dat de hoeveelheid water in het systeem gelijk is aan de flow maal de verstreken tijd dat het duurt om de hoeveelheid water 1 keer rond te pompen?

Met de constante flow van 800 L/uur was de gepasseerde hoeveelheid water dan 2,5 / 60 * 800 = 33 liter water.

code:

alias: Bepaal hoeveelheid water in het systeem?
description: ""
triggers:
  - entity_id: sensor.flowmeter_flowrate
    above: 700
    trigger: numeric_state
  - entity_id: sensor.heatpump_1_power_input
    above: 100
    trigger: numeric_state
actions:
  - variables:
      start_temp: "{{ states('sensor.heatpump_1_temperature_water_in') | float }}"
      start_time: "{{ now() }}"
      flow_rate: 800
  - delay: "00:01:00"
  - wait_template: >-
      {{ states('sensor.heatpump_1_temperature_water_in') | float > (start_temp
      + 0.1) }}
    timeout: "00:10:00"
  - variables:
      end_time: "{{ now() }}"
      time_delay: "{{ (end_time - start_time).total_seconds() / 3600 }}"
      water_volume: "{{ flow_rate * time_delay }}"
  - target:
      entity_id: input_number.water_volume
    data:
      value: "{{ water_volume | round(1) }}"
    action: input_number.set_value
  - data:
      title: Water Volume Calculated
      message: >-
        Estimated water volume in the system is {{ water_volume | round(1) }}
        liters.
    action: persistent_notification.create

[Afbeelding]

Is denk ik afhankelijk van of alle radiatoren openstaan en er goed is ingeregeld. En als je vvw met menging hebt dan is dit een onzekere factor.

[s020506]

Hier maar ff verder. @TeslaNerd

nairolf schreef op maandag 13 oktober 2025 @ 23:12:
[...]

En @TeslaNerd

Je wil kijken naar: binary_sensor.slave_ch_active_boiler

Die komt overeen met de bit die bedoeld wordt, want dat is de “response” van het toestel naar de thermostaat. Die andere is alleen een copy van het “thermostat” equivalent. (Ik heb me altijd afgevraagd waarom er 2 bestaan, 1 voor thermostat & 1 voor boiler, want de beslissing van de waarde ligt altijd bij 1 van de 2 apparaten: thermostaat of boiler. Ze mogen dus eigenlijk nooit verschillen)

Edit: bij mij is ook altijd 1 van de 2 copies “Unknown”, en de andere heeft een waarde (of niet als die nooit gecommuniceerd wordt tussen beide)

Uit welke integratie komt deze sensor? Want deze heb ik niet.

[nairolf]

s020506 schreef op dinsdag 14 oktober 2025 @ 07:29:
Hier maar ff verder. @TeslaNerd


[...]


Uit welke integratie komt deze sensor? Want deze heb ik niet.

OpenThermGateWay (OTGW) integratie (zie eigen topic voor informatie over dit apparaat). Is niet specifiek van Quatt, maar zit in het OpenTherm protocol welke je dus met bijv. een OTGW kan uitlezen. Maar dus ook via de OpenTherm Optimizer die @jbtbnl aan het maken is, al heet de HA sensor waarin deze waarde wordt gestopt waarschijnlijk anders in zin optimizer.

[s020506]

nairolf schreef op dinsdag 14 oktober 2025 @ 08:10:
[...]


OpenThermGateWay (OTGW) integratie (zie eigen topic voor informatie over dit apparaat). Is niet specifiek van Quatt, maar zit in het OpenTherm protocol welke je dus met bijv. een OTGW kan uitlezen. Maar dus ook via de OpenTherm Optimizer die @jbtbnl aan het maken is, al heet de HA sensor waarin deze waarde wordt gestopt waarschijnlijk anders in zin optimizer.

Ik heb deze integratie, maar daar zit deze sensor niet in: https://www.home-assistant.io/integrations/opentherm_gw

Heb jij misschien een andere?

[nairolf]

s020506 schreef op dinsdag 14 oktober 2025 @ 08:34:
[...]


Ik heb deze integratie, maar daar zit deze sensor niet in: https://www.home-assistant.io/integrations/opentherm_gw

Heb jij misschien een andere?

Nee dat is degene die ik ook heb. Het enige wat ik kan bedenken is dat hij nu wellicht toch anders heet. Er is sinds ik hem heb namelijk een redelijke overhaul geweest van de code zodat het 3 “devices” zijn per fysieke OTGW (thermostat, boiler en gateway zijn de 3 devices die de integratie nu aanmaakt) en wellicht zijn sensoren daarmee ook hernoemd, maar niet bij mij omdat ik de integratie al had voordat die splitsing plaatsvond?

Just guessing

[TeslaNerd]

nairolf schreef op dinsdag 14 oktober 2025 @ 08:50:
[...]


Nee dat is degene die ik ook heb. Het enige wat ik kan bedenken is dat hij nu wellicht toch anders heet. Er is sinds ik hem heb namelijk een redelijke overhaul geweest van de code zodat het 3 “devices” zijn per fysieke OTGW (thermostat, boiler en gateway zijn de 3 devices die de integratie nu aanmaakt) en wellicht zijn sensoren daarmee ook hernoemd, maar niet bij mij omdat ik de integratie al had voordat die splitsing plaatsvond?

Just guessing

Met de alternatieve naamgevingen (afwijkend van de lange sensor-namen) is het niet makkelijk om deze sensoren te vinden. Bij mij waren deze alle drie ook disabled. Hoe werkt dat bij Home Assistant dat na het toevoegen van een integratie een deel van de sensoren nog disabled zijn? Wordt dat zo ingesteld door de maker(s) van een integratie?

[s020506]

TeslaNerd schreef op dinsdag 14 oktober 2025 @ 09:28:
[...]

Met de alternatieve naamgevingen (afwijkend van de lange sensor-namen) is het niet makkelijk om deze sensoren te vinden. Bij mij waren deze alle drie ook disabled. Hoe werkt dat bij Home Assistant dat na het toevoegen van een integratie een deel van de sensoren nog disabled zijn? Wordt dat zo ingesteld door de maker(s) van een integratie?

Geen idee. Bij mij was juist bijna alles enabled. En met dan de helft unknown omdat de thermostaat of CiC geen waarde ervoor doorgeeft.

[s020506]

nairolf schreef op dinsdag 14 oktober 2025 @ 08:50:
[...]


Nee dat is degene die ik ook heb. Het enige wat ik kan bedenken is dat hij nu wellicht toch anders heet. Er is sinds ik hem heb namelijk een redelijke overhaul geweest van de code zodat het 3 “devices” zijn per fysieke OTGW (thermostat, boiler en gateway zijn de 3 devices die de integratie nu aanmaakt) en wellicht zijn sensoren daarmee ook hernoemd, maar niet bij mij omdat ik de integratie al had voordat die splitsing plaatsvond?

Just guessing

Bij mij draait de OTGW pas een week of twee. Dus zou kunnen

[nairolf]

s020506 schreef op dinsdag 14 oktober 2025 @ 10:30:
[...]


Bij mij draait de OTGW pas een week of twee. Dus zou kunnen

Ik denk dat de naam die ik noem toch echt de goede is:

https://github.com/mvn23/...yotgw/pyotgw.py#L769-L800

In de pyotgw code (de "backend" die voor de HA integratie gebruikt wordt) wordt de 6e letter (character) van de slave_status omgezet naar integer (getal). Gezien we meestal de grootste getallen links plaatsen en de kleine getallen rechts (123 is 1x 100, 2x 10 en 3x 1) is het 6e getal (geteld vanaf 0) de 1e bit (van de 8 ), dus dat komt overeen met wat @jbtbnl liet zien uit de OT-spec:
https://gathering.tweakers.net/forum/view_message/83669926

Dit wordt geplaatst achter de "DATA_SLAVE_CH_ACTIVE" key, welke de string ("naam") "slave_ch_active" heeft:
https://github.com/mvn23/...master/pyotgw/vars.py#L74

In HA wordt dat vervolgens in deze EntityDescription gezet, kijk specifiek naar "key", die krijgt gewoon exact de string die uit de pyotgw global wordt gehaald, dus "slave_ch_active":
https://github.com/home-a.../binary_sensor.py#L42-L48

En dat wordt dan weer hier gebruikt om het "unique_id" te zetten, wat als het goed is gebruikt wordt om de "entity_id" te kiezen voor een sensor.
https://github.com/home-a...pentherm_gw/entity.py#L45
Edit: verkeerde link aangepast

Je kan proberen hem te zoeken in de settings:
Settings -> Devices & Services -> Klik op "Opentherm Gateway", niet op "3 devices" eronder.
Dan zie je de "integratie pagina" waarop je 3 "rijen" devices ziet. Klik bij de rij "Opentherm Boiler" op de 3 puntjes, en dan op "X entities" (ik zie "76 entities" staan).
Je kan dan eventueel de kolom "Entity ID" toevoegen om precies te kunnen zien hoe alles heet. Hier kan je dan gaan zoeken (handmatig of via de het zoekfilter bovenin).

Ik zie dan bijvoorbeeld:
Daar zie ik bij de "Status" "-" staan, dus beschikbaar, maar bij entities die disabled zijn staat dan een rondje met een streepje erdoor (een "niet parkeren bord" zegmaar). Als dat zo is dan kan je hem idd niet vinden, maar dan kan je hem hier wel enablen zodat de OTGW integratie die sensor vanaf dan wel gaat vullen.

[s020506]

nairolf schreef op dinsdag 14 oktober 2025 @ 11:27:
[...]


Ik denk dat de naam die ik noem toch echt de goede is:

https://github.com/mvn23/...yotgw/pyotgw.py#L769-L800

In de pyotgw code (de "backend" die voor de HA integratie gebruikt wordt) wordt de 6e letter (character) van de slave_status omgezet naar integer (getal). Gezien we meestal de grootste getallen links plaatsen en de kleine getallen rechts (123 is 1x 100, 2x 10 en 3x 1) is het 6e getal (geteld vanaf 0) de 1e bit (van de 8 ), dus dat komt overeen met wat @jbtbnl liet zien uit de OT-spec:
https://gathering.tweakers.net/forum/view_message/83669926

Dit wordt geplaatst achter de "DATA_SLAVE_CH_ACTIVE" key, welke de string ("naam") "slave_ch_active" heeft:
https://github.com/mvn23/...master/pyotgw/vars.py#L74

In HA wordt dat vervolgens in deze EntityDescription gezet, kijk specifiek naar "key", die krijgt gewoon exact de string die uit de pyotgw global wordt gehaald, dus "slave_ch_active":
https://github.com/home-a.../binary_sensor.py#L42-L48

En dat wordt dan weer hier gebruikt om het "unique_id" te zetten, wat als het goed is gebruikt wordt om de "entity_id" te kiezen voor een sensor.
https://github.com/home-a...pentherm_gw/entity.py#L45
Edit: verkeerde link aangepast

Je kan proberen hem te zoeken in de settings:
Settings -> Devices & Services -> Klik op "Opentherm Gateway", niet op "3 devices" eronder.
Dan zie je de "integratie pagina" waarop je 3 "rijen" devices ziet. Klik bij de rij "Opentherm Boiler" op de 3 puntjes, en dan op "X entities" (ik zie "76 entities" staan).
Je kan dan eventueel de kolom "Entity ID" toevoegen om precies te kunnen zien hoe alles heet. Hier kan je dan gaan zoeken (handmatig of via de het zoekfilter bovenin).

Ik zie dan bijvoorbeeld:
Daar zie ik bij de "Status" "-" staan, dus beschikbaar, maar bij entities die disabled zijn staat dan een rondje met een streepje erdoor (een "niet parkeren bord" zegmaar). Als dat zo is dan kan je hem idd niet vinden, maar dan kan je hem hier wel enablen zodat de OTGW integratie die sensor vanaf dan wel gaat vullen.
[Afbeelding]

Ik kom er van het weekend op terug. Ik ben een paar dagen weg en op mijn telefoon krijg ik dit niet uitgevonden

[nairolf]

TeslaNerd schreef op dinsdag 14 oktober 2025 @ 09:28:
[...]

Met de alternatieve naamgevingen (afwijkend van de lange sensor-namen) is het niet makkelijk om deze sensoren te vinden. Bij mij waren deze alle drie ook disabled. Hoe werkt dat bij Home Assistant dat na het toevoegen van een integratie een deel van de sensoren nog disabled zijn? Wordt dat zo ingesteld door de maker(s) van een integratie?

Ik kan in de code niet vinden op basis waarvan vanalles enabled is of niet, maar bij mij was ooit ook heel veel disabled, dus het kan goed dat hij by default niet enabled staat.

[TeslaNerd]

MWink schreef op dinsdag 8 juli 2025 @ 23:06:
[...]

- github repository staat nu nog even private, er moeten nog wat links in de readme aangepast worden, en wat afstemmen met wat mensen. Er staan de orginele Kicad project files en de gegenereerde gerbers en BOM en CPL files in het archief, is beschikbaar onder de CERN-OHL-P v2 license. Prijs bij JLCPCB is 85 euro per 5 PCBs incl import en verzending.

- van de rs-485 transceiver is alleen de Rx verbonden en Rx enable is actief en
- Tx is niet verbonden en Tx enable is niet actief
- geen eindweerstanden want die zitten al op de bus
- ik zie paar keer per minuut CRC fouten, ik ga morgen even de bedrading verbeteren, misschien dat het helpt
- deze modbus sniffer kan alleen maar lezen doordat de Tx is gedisabled. Ik heb wel 0 Ohm weerstanden laten plaatsen op de Rx en Tx enable pinnen om het later mogelijk te maken ook te schrijven op de modbus.

Hoe gaat het met het studentenproject?
En is de github voor dit project al openbaar?

[maxtrash]

TeslaNerd schreef op zondag 12 oktober 2025 @ 01:06:
[...]

Ja, ik ben daar mee bezig geweest en inderdaad is de delta tussen kamer temperatuur en room setpoint de belangrijkste driver voor het compressor niveau (9 stappen 30Hz-90Hz) dat de CiC vraagt aan de buitenunit. En er zijn dan andere drivers die in mindere mate invloed hierop hebben, oa de buitentemperatuur en zoals jij aangeeft hoeveel schot er zit in het reduceren van de delta_room_temperature_to_room_setpoint.
Ik heb dit opgelost met een feedback-loop tussen de delta_room_temperature_to_room_setpoint en de compressor_frequency.
NB de CiC stuurt de compressorfrequency maar niet de powerinput. De powerinput wordt door de controller in de buitenunit aangestuurd waarbij de watertemperatuur ook een rol speelt: de powerinput loopt op met de watertemperatuur ook als de compressorfrequentie gelijk blijft.
Ik denk dat een feedbackloop van de delta_room_temperature_to_room_setpoint op het vermogen van de zonnepanelen mogelijk is met de beperking dat de minimale powerinput ook afhankelijk blijft van de watertemperatuur

Bedoel je met feedback loop een pid algoritme? Ik ben er mee bezig geweest maar het reageert nog wat te agressief. Welke parameters gebruik je?

[TeslaNerd]

maxtrash schreef op dinsdag 14 oktober 2025 @ 21:27:
[...]

Bedoel je met feedback loop een pid algoritme? Ik ben er mee bezig geweest maar het reageert nog wat te agressief. Welke parameters gebruik je?

Niet een PID maar een eenvoudig REPEAT ... WHILE loopje.
Het begint met het vasthouden van een vaste delta tussen de kamertemperatuur en de room setpoint met daarop een extra delta die ik iedere 10 seconden laat bewegen per 1/100ste graad zolang de compressor een stap te hoog of lager staat dan de door mij gewenste compressorfrequentie.

code:

alias: >-
  Change Offset on change in ComprLevel or ComprLevelDemand until ComprLevel
  equal  ComprLevelDemand
description: ""
triggers:
  - trigger: state
    entity_id:
      - input_number.compressorleveldemand
  - trigger: state
    entity_id:
      - sensor.hp1_compressor_level_set_by_cic
  - trigger: template
    value_template: >-
      {{ ( states("input_number.compressorleveldemand") -
      states("sensor.hp1_compressor_level_set_by_cic") ) != 0 }}
conditions:
  - condition: numeric_state
    entity_id: sensor.hp1_compressor_level_set_by_cic
    above: 0
  - condition: numeric_state
    entity_id: counter.aktietimer_quatt_aan
    above: 2
  - condition: numeric_state
    entity_id: input_number.deltat_room2setpoint
    above: -1
  - condition: template
    value_template: >-
      {{ (states('input_number.compressorleveldemand')|int -
      states('sensor.hp1_compressor_level_set_by_cic')|int) != 0 }} 
  - condition: not
    conditions:
      - condition: state
        entity_id: binary_sensor.hp1_defrost_mode
        state: "on"
actions:
  - repeat:
      while:
        - condition: and
          conditions:
            - condition: template
              value_template: >-
                {{ (states('input_number.compressorleveldemand')|int -
                states('sensor.hp1_compressor_level_set_by_cic')|int) != 0 }}
            - condition: numeric_state
              entity_id: sensor.hp1_compressor_level_set_by_cic
              above: 0
      sequence:
        - variables:
            current: "{{ states('input_number.deltat_room2setpoint') | float(0.00) }}"
            oldlevel: "{{ states('sensor.hp1_compressor_level_set_by_cic') | int }}"
        - if:
            - condition: template
              value_template: >-
                {{ (states('input_number.compressorleveldemand')|int -
                states('sensor.hp1_compressor_level_set_by_cic')|int) > 0 }}
          then:
            - data_template:
                entity_id: input_number.deltat_room2setpoint
                value: "{{ current + 0.01 | float(0.00) }}"
              action: input_number.set_value
          else:
            - data_template:
                entity_id: input_number.deltat_room2setpoint
                value: "{{ current - 0.01 | float(0.00) }}"
              action: input_number.set_value
        - delay:
            seconds: 10
  - metadata: {}
    data:
      title: Quatt
      message: >-
        ComprLevel was {{ oldlevel }} is  {{
        states('sensor.hp1_compressor_level_set_by_cic')|int }}
    action: notify.mobile_app_xxxx
mode: single

[TeslaNerd]

Hieronder de Plotly-code waarmee ik deze 3D-puntenwolk heb gemaakt obv sensoren uit de Quatt-integratie in Home Assistant. Hiervoor heb jij de Plotly Graph Card nodig uit HACS.

Als iemand weet hoe ik met Plotly nog een trendvlak kan toevoegen aan deze puntenwolk dan lees ik dat graag.

code:

type: custom:plotly-graph
title: COP vs Tlift (Ta - Buitentemp)
hours_to_show: 960
refresh_interval: 300
no_default_entities: true
raw_plotly_config: true
entities:
  - entity: sensor.heatpump_1_temperature_water_in
    internal: true
    filters:
      - resample: 1m
      - store_var: ta
  - entity: sensor.heatpump_1_temperature_outside
    internal: true
    filters:
      - resample: 1m
      - store_var: buiten
  - entity: sensor.heatpump_1_quatt_cop
    internal: true
    filters:
      - resample: 1m
      - store_var: cop
  - entity: ""
    x: >-
      $fn ({ vars }) => vars.cop.xs.map((x, i) => vars.ta.ys[i] -
      vars.buiten.ys[i])
    z: $fn ({ vars }) => vars.cop.ys
    "y": $fn ({ vars }) => vars.buiten.ys
    type: scatter3d
    mode: markers
    marker:
      color: crimson
      size: 2
      opacity: 0.1
layout:
  margin:
    t: 0
    l: 0
    r: 0
    b: 0
  scene:
    xaxis:
      title: Tlift = Ta - Buitentemp
      range:
        - 0
        - 25
    zaxis:
      title: COP
      range:
        - 1
        - 10
    yaxis:
      title: Buitentemp
      range:
        - 10
        - 16
  height: 600
  plot_bgcolor: white
  hovermode: closest

[ Voor 4% gewijzigd door TeslaNerd op 15-10-2025 23:44 ]

[jj85]

Leuke ontwikkeling (in testfase) in de HA integratie, zowel via lokale connectie (JSON) als remote (mobile-api).
Met die laatste is veel informatie op te halen.

https://github.com/marcob...8#issuecomment-3408062786
https://github.com/marcoboers/home-assistant-quatt/pull/208

(geen idee of ontwikkelaar Wouter hier ook op Tweakers aanwezig is)

[verguldebarman]

jj85 schreef op donderdag 16 oktober 2025 @ 08:23:
Leuke ontwikkeling (in testfase) in de HA integratie, zowel via lokale connectie (JSON) als remote (mobile-api).
Met die laatste is veel informatie op te halen.

https://github.com/marcob...8#issuecomment-3408062786
https://github.com/marcoboers/home-assistant-quatt/pull/208

(geen idee of ontwikkelaar Wouter hier ook op Tweakers aanwezig is)

Ziet er inderdaad geweldig uit en mogelijk dat we alleen maar even hoeven te wachten totdat dit in de HA integratie terecht komt, check deze post

[TeslaNerd]

jj85 schreef op donderdag 16 oktober 2025 @ 08:23:
Leuke ontwikkeling (in testfase) in de HA integratie, zowel via lokale connectie (JSON) als remote (mobile-api).
Met die laatste is veel informatie op te halen.

https://github.com/marcob...8#issuecomment-3408062786
https://github.com/marcoboers/home-assistant-quatt/pull/208

(geen idee of ontwikkelaar Wouter hier ook op Tweakers aanwezig is)

Dat ziet er goed uit. Wat is het verschil tussen local en remote api gebruiken?

[verguldebarman]

TeslaNerd schreef op donderdag 16 oktober 2025 @ 09:19:
[...]

Dat ziet er goed uit. Wat is het verschil tussen local en remote api gebruiken?

simpelweg:
De remote API heeft veel meer info. 😁

[jj85]

TeslaNerd schreef op donderdag 16 oktober 2025 @ 09:19:
[...]

Dat ziet er goed uit. Wat is het verschil tussen local en remote api gebruiken?

Remote (via mobile-api): https://github.com/marcob...8#issuecomment-3402420795

Bevat dus ook alle informatie waarmee in de Quatt app de grafieken gemaakt worden.
En bijv comp freq, pompvermogen, CiC versie, Quatt versie etc.

[ Voor 19% gewijzigd door jj85 op 16-10-2025 09:25 ]

[TeslaNerd]

jj85 schreef op donderdag 16 oktober 2025 @ 09:21:
[...]

Remote (via mobile-api): https://github.com/marcob...8#issuecomment-3402420795

Bevat dus ook alle informatie waarmee in de Quatt app de grafieken gemaakt worden.
En bijv comp freq, pompvermogen, CiC versie, Quatt versie etc.

Als in: alle historische data op basis waarvan de Quatt de grafieken kan maken?

En begrijp ik het goed dat met de truc in deze pull request het niet meer nodig is om een geroote android telefoon te hebben om de data uit de api te krijgen?

[ Voor 14% gewijzigd door TeslaNerd op 16-10-2025 09:36 ]

[jj85]

TeslaNerd schreef op donderdag 16 oktober 2025 @ 09:31:
[...]

Als in: alle historische data op basis waarvan de Quatt de grafieken kan maken?

offtopic:
Die vraag kan je prima zelf beantwoorden als je die link even goed bekeken hebt

GET: /me/installation/INS-HIDDEN/insights?from=2024-01-01&timeframe=all&advancedInsights=true

JSON:

{
    "meta":
    {
        "status": 200,
        "took": 0.111067297
    },
    "result":
    {
        "from": "2023-12-31T23:00:00.000Z",
        "to": "2025-10-14T21:59:59.999Z",
        "totalHpHeat": 11559363,
        "totalHpElectric": 3352891,
        "totalBoilerHeat": 5520,
        "totalBoilerGas": 0.6278,
        "averageCOP": 3.4,
        "savingsMoney": 643.19,
        "savingsCo2": 1641.147,
        "savingsGas": 1314.6844,
        "savingsGasMoney": 1808.34,
        "savingsQuattElectricityCost": 1165.15,
        "co2GasSaved": 2350.3814,
        "co2Electricity": 709.2344,
        "hasTarrifs": true,
        "graph":
        [
            {
                "hpElectric": 1273020,
                "hpHeat": 4482326,
                "boilerHeat": 5520,
                "boilerGas": 0.6278,
                "cop": 3.5,
                "timestamp": "2024-06-30T22:00:00.000Z"
            },
            {
                "hpElectric": 2079871,
                "hpHeat": 7077037,
                "boilerHeat": 0,
                "boilerGas": 0,
                "cop": 3.4,
                "timestamp": "2024-12-31T23:00:00.000Z"
            }
        ],
        "outsideTemperatureGraph": null,
        "waterTemperatureGraph": null,
        "roomTemperatureGraph": null
    }
}

En begrijp ik het goed dat met de truc in deze pull request het niet meer nodig is om een geroote android telefoon te hebben om de data uit de api te krijgen?

Ja, enkel CiC hostname + een druk op de CiC knop.

[s020506]

TeslaNerd schreef op donderdag 16 oktober 2025 @ 09:31:
[...]

Als in: alle historische data op basis waarvan de Quatt de grafieken kan maken?

En begrijp ik het goed dat met de truc in deze pull request het niet meer nodig is om een geroote android telefoon te hebben om de data uit de api te krijgen?

Ik denk niet dat je historische data krijgt. Alleen meer sensoren die je nu kan uitlezen.

En volgens mij begrijp je het goed.

[jj85]

s020506 schreef op donderdag 16 oktober 2025 @ 09:47:
[...]


Ik denk niet dat je historische data krijgt. Alleen meer sensoren die je nu kan uitlezen.

Jawel, alles wat je ook met de Quatt app kunt ophalen (die Mobile API is immers de bron voor de Quatt app). Je zou er in theorie ook settings mee kunnen wijzigen (alle settings die in de app voorkomen), zoals soundslider en tarieven.

[TeslaNerd]

s020506 schreef op donderdag 16 oktober 2025 @ 09:47:
[...]


Ik denk niet dat je historische data krijgt. Alleen meer sensoren die je nu kan uitlezen.

En volgens mij begrijp je het goed.

Ja TLDR hier, maar met de hint van @jj85 begin ik nu te begrijpen hoe veel extra data hiermee beschikbaar komt voor de Quatt integratie

En ja, dat is alle historische data die de app nodig heeft om de grafieken per dag vanaf installatiedatum te kunnen maken

[TeslaNerd]

jj85 schreef op donderdag 16 oktober 2025 @ 09:56:
[...]

Jawel, alles wat je ook met de Quatt app kunt ophalen (die Mobile API is immers de bron voor de Quatt app). Je zou er in theorie ook settings mee kunnen wijzigen (alle settings die in de app voorkomen), zoals soundslider en tarieven.

en ook het installateurs menu van de app?
Geen idee overigens wat er mogelijk is met dat menu

edit: met deze posts uit het andere forum kan de installateur dan ook de stooklijn instellen:
Friezin in "Ervaringen met Quatt Deel 2"

[ Voor 68% gewijzigd door TeslaNerd op 16-10-2025 10:18 ]

[Lasoul]

Het is allemaal nog in testfase maar het ziet er goed uit! Waar we voor moeten uitkijken is dat we de mobile-API van Quatt niet overbelasten. Lokaal kunnen we prima de CIC 1x in de 10 seconden uitlezen maar dit is praktisch gezien niet wenselijk voor de mobile-api.

De gedachtengang die ik nu heb is om eigenlijk lokaal en remote te combineren. Data dat lokaal beschikbaar is wordt ook direct lokaal snel bij de CIC opgehaald en voor data dat alleen maar remote beschikbaar is wordt de update frequentie lager (in lijn met de update snelheid van de mobile app).

[TeslaNerd]

Lasoul schreef op donderdag 16 oktober 2025 @ 10:08:
Het is allemaal nog in testfase maar het ziet er goed uit! Waar we voor moeten uitkijken is dat we de mobile-API van Quatt niet overbelasten. Lokaal kunnen we prima de CIC 1x in de 10 seconden uitlezen maar dit is praktisch gezien niet wenselijk voor de mobile-api.

De gedachtengang die ik nu heb is om eigenlijk lokaal en remote te combineren. Data dat lokaal beschikbaar is wordt ook direct lokaal snel bij de CIC opgehaald en voor data dat alleen maar remote beschikbaar is wordt de update frequentie lager (in lijn met de update snelheid van de mobile app).

Ok, dat is inderdaad de goede gedachtengang. Alle (historische) data komt dan uiteindelijk toch in de Home Assistant database terecht en is dan altijd direct beschikbaar

[Rowwan]

Ben benieuwd hoe lang de remote API open blijft. Leveranciers zitten hier vaak niet op te wachten...

[jj85]

Rowwan schreef op donderdag 16 oktober 2025 @ 10:18:
Ben benieuwd hoe lang de remote API open blijft. Leveranciers zitten hier vaak niet op te wachten...

Hij is niet open. Je connect met de CIC code + druk op de CIC knop.
In weze simuleer je in HA een telefoon met Quatt app via deze route

[Lasoul]

Rowwan schreef op donderdag 16 oktober 2025 @ 10:18:
Ben benieuwd hoe lang de remote API open blijft. Leveranciers zitten hier vaak niet op te wachten...

Dat is ook exact de reden waarom we moeten voorkomen dat we de Quatt mobile-api teveel belasten. Als de data lokaal beschikbaar is dan kun je prima de data 1x per 10 seconden ophalen. Voor de mobile-api zou dat in de minuten moeten zijn.

[JanHenk]

Gave ontwikkeling! Ik ben het met Lasoul eens, reverse-engineered API's moet je voorzichtig mee zijn in gebruik, om te voorkomen dat de fabrikant routes gaat dichttimmeren of algemeen (voor iedereen) time-outs gaat instellen. Zal niet de eerste keer zijn...

Ik denk echter wel dat het een heel goede aanvulling kan zijn op de lokale CIC JSON polling, zou het graag gebruiken.

[ Voor 4% gewijzigd door JanHenk op 16-10-2025 10:49 ]

[Rowwan]

jj85 schreef op donderdag 16 oktober 2025 @ 10:20:
[...]

Hij is niet open. Je connect met de CIC code + druk op de CIC knop.
In weze simuleer je in HA een telefoon met Quatt app via deze route

Bwa... Ik weet niet of dat is hoe Quatt het ziet. De mobile app wordt door veel mensen nauwelijks gebruikt (1x per dag? 1x per week). Als je dit via HA gaat doen, kan het data verbruik vele malen omhoog gaan (geen idee, niet noodzakelijk). En daarmee ook hun hosting kosten, ze kopen waarschijnlijk gewoon bandbreedte in. Als dit ineens explodeert gaan ze maatregelen nemen.

Ik heb dit ook bij andere applicaties gezien (oa. Ford), leveranciers zetten dit vaak snel dicht.

[TeslaNerd]

JanHenk schreef op donderdag 16 oktober 2025 @ 10:49:
Gave ontwikkeling! Ik ben het met Lasoul eens, reverse-engineered API's moet je voorzichtig mee zijn in gebruik, om te voorkomen dat de fabrikant routes gaat dichttimmeren of algemeen (voor iedereen) time-outs gaat instellen. Zal niet de eerste keer zijn...

Ik denk echter wel dat het een heel goede aanvulling kan zijn op de lokale CIC JSON polling, zou het graag gebruiken.

Een timeout instellen is een prima oplossing. Daar kan in de Quatt integratie prima mee worden omgegaan.

@BobVI en Martijn bij @Quatt Support ik neem aan dat jullie hier ook meelezen. Kunnen jullie mee sparren hoe hier mee om te gaan?

[ Voor 7% gewijzigd door TeslaNerd op 16-10-2025 11:11 ]

[Lasoul]

TeslaNerd schreef op donderdag 16 oktober 2025 @ 11:08:
[...]

Een timeout instellen is een prima oplossing. Daar kan in de Quatt integratie prima mee worden omgegaan.

@BobVI en Martijn bij @Quatt Support ik neem aan dat jullie hier ook meelezen. Kunnen jullie mee sparren hoe hier mee om te gaan?

In de basis zou de remote API integratie voor realtime sensor informatie helemaal niet nodig moeten zijn. Zolang de lokale CIC-feed dezelfde realtime sensor informatie bevat als remote dan wordt de lokale feed gebruikt.

Het is anders voor de historische data en de aansturing van bijvoorbeeld de Hybrid (Bijvoorbeeld: Sound slider, quiet mode), All-electric (bijvoorbeeld: boost) of straks de Chill (aan/uit?). Vanuit integratie perspectief wil je graag de mogelijkheid hebben om dit ook aan te kunnen sturen vanuit bijvoorbeeld Home Assistant. Je wil hiervoor niet elke keer de Quatt app moeten hoeven gebruiken.

[RickvdT]

Rowwan schreef op donderdag 16 oktober 2025 @ 10:18:
Ben benieuwd hoe lang de remote API open blijft. Leveranciers zitten hier vaak niet op te wachten...

Hier ben ik ook een beetje bang voor. Het zou vooral mooi zijn om zelf de Full electric slim te kunnen aansturen met wat logica. Dat is niet heel complex en ik ben bang dat dit bij Quatt nog een lange tijd gaat duren zolang je geen Quatt energy en Quatt accu hebt.

[Fragger123]

Het is jammer dat "we" al deze data via de Mobile API moeten ophalen. Ik heb dit ook eerder aangegeven in het zuster topic over Quatt.

Al deze data komt immers uit de CIC en zou prima in de JSON kunnen staan. Dan loopt Quatt niet het risico op meer load/traffic/firebase tokens op de Mobile API. Ik kan me niet voorstellen dat het de bedoeling is om dit op deze manier te doen.

Overigens poll ik al sinds afgelopen winter de mobile API om bij bepaalde frequenties de thermostaat een tikkeltje te verlagen zodat ik geen "last" heb van de 317hz toon in de nachten. En vind het wel fijn om te weten wanneer de CIC firmware wordt bijgewerkt. Voor mij usecase zouden deze twee ook prima in de CIC JSON data kunnen staan

[maxtrash]

hele mooie ontwikkelingen met de nieuwe API. Ben het er mee eens dat sensoren eigenlijk beter in de lokale json zouden kunnen zitten. Misschien is dit een kleine stimulans voor Quatt om deze toe te voegen waardoor de remote API alleen sporadisch gebruikt hoeft te worden.
Persoonlijk ben ik wel geïnteresseerd in de compressor frequency's

[TeslaNerd]

Wow, jullie laten er geen gras over groeien🥳

@BobVI en Martijn van @Quatt Support laten jullie ook nog wat horen vanuit Quatt als leverancier van al dit moois?

[ Voor 27% gewijzigd door TeslaNerd op 17-10-2025 11:59 ]

[mklcln]

Hele mooie ontwikkeling chapeau! vanuit daar kan je straks zelf de slimmigheid regelen met HA.
Maar het gevaar kan nu ook zijn dat ze de mobile api dichttimmeren na al het taggen.

[ Voor 23% gewijzigd door mklcln op 17-10-2025 14:08 ]

[jbtbnl]

mklcln schreef op vrijdag 17 oktober 2025 @ 14:07:
Hele mooie ontwikkeling chapeau! vanuit daar kan je straks zelf de slimmigheid regelen met HA.
Maar het gevaar kan nu ook zijn dat ze de mobile api dichttimmeren na al het taggen.

Ik zou het niet aandurven voor essentiële toepassingen. Ben je op wintersportvakantie, wordt de API aangepast, zit je met een huis zonder verwarming...

Voor logging en monitoring is het natuurlijk wél heel leuk!

Edit: of er zou een goed fallback scenario moeten zijn

[ Voor 5% gewijzigd door jbtbnl op 17-10-2025 14:56 ]

[jj85]

@mklcln @jbtbnl Ik heb niet het idee dat er iets via de mobile API te regelen is, behalve de soundslider, optimaliseer besparingen en de tarieven.
Het blijft de CiC die de warmtepomp aanstuurt.
Met een modbuscontroller zou je het wel zelf kunnen overnemen

[TeslaNerd]

jj85 schreef op vrijdag 17 oktober 2025 @ 15:02:
@mklcln @jbtbnl Ik heb niet het idee dat er iets via de mobile API te regelen is, behalve de soundslider, optimaliseer besparingen en de tarieven.
Het blijft de CiC die de warmtepomp aanstuurt.
Met een modbuscontroller zou je het wel zelf kunnen overnemen

En wat hier al door een aantal tweakers met succes wordt gedaan is een eigen besturing via het room setpoint van de thermostaat obv de data uit de JSON, modbus, en de Quatt api.
Bij mij is dat een regeling op de normale besturing van Quatt en het weekschema voor de thermostaat. Als de zelf getweakte metabesturing hapert dan gaan de Quatt CiC en het weekschema ongestoord verder.
Is minder spannend dan het lijkt

[s020506]

nairolf schreef op dinsdag 14 oktober 2025 @ 11:27:
[...]


Ik denk dat de naam die ik noem toch echt de goede is:

https://github.com/mvn23/...yotgw/pyotgw.py#L769-L800

In de pyotgw code (de "backend" die voor de HA integratie gebruikt wordt) wordt de 6e letter (character) van de slave_status omgezet naar integer (getal). Gezien we meestal de grootste getallen links plaatsen en de kleine getallen rechts (123 is 1x 100, 2x 10 en 3x 1) is het 6e getal (geteld vanaf 0) de 1e bit (van de 8 ), dus dat komt overeen met wat @jbtbnl liet zien uit de OT-spec:
https://gathering.tweakers.net/forum/view_message/83669926

Dit wordt geplaatst achter de "DATA_SLAVE_CH_ACTIVE" key, welke de string ("naam") "slave_ch_active" heeft:
https://github.com/mvn23/...master/pyotgw/vars.py#L74

In HA wordt dat vervolgens in deze EntityDescription gezet, kijk specifiek naar "key", die krijgt gewoon exact de string die uit de pyotgw global wordt gehaald, dus "slave_ch_active":
https://github.com/home-a.../binary_sensor.py#L42-L48

En dat wordt dan weer hier gebruikt om het "unique_id" te zetten, wat als het goed is gebruikt wordt om de "entity_id" te kiezen voor een sensor.
https://github.com/home-a...pentherm_gw/entity.py#L45
Edit: verkeerde link aangepast

Je kan proberen hem te zoeken in de settings:
Settings -> Devices & Services -> Klik op "Opentherm Gateway", niet op "3 devices" eronder.
Dan zie je de "integratie pagina" waarop je 3 "rijen" devices ziet. Klik bij de rij "Opentherm Boiler" op de 3 puntjes, en dan op "X entities" (ik zie "76 entities" staan).
Je kan dan eventueel de kolom "Entity ID" toevoegen om precies te kunnen zien hoe alles heet. Hier kan je dan gaan zoeken (handmatig of via de het zoekfilter bovenin).

Ik zie dan bijvoorbeeld:
Daar zie ik bij de "Status" "-" staan, dus beschikbaar, maar bij entities die disabled zijn staat dan een rondje met een streepje erdoor (een "niet parkeren bord" zegmaar). Als dat zo is dan kan je hem idd niet vinden, maar dan kan je hem hier wel enablen zodat de OTGW integratie die sensor vanaf dan wel gaat vullen.
[Afbeelding]

Zoals beloofd, ik heb er nog even naar gekeken. En ik heb die sensor echt niet. Maar dat is niet zo raar als ik naar de code van de integratie kijk. Bij mij wordt deze netjes hernoemd:

https://github.com/home-a...m_gw/binary_sensor.py#L42

Dus binary_sensor.slave_ch_active_boiler en binary_sensor.opentherm_boiler_central_heating_1 zijn precies hetzelfde. Alleen raar dat deze bij mij hernoemd wordt, en bij jou niet.

[MWink]

TeslaNerd schreef op dinsdag 14 oktober 2025 @ 12:14:
[...]

Hoe gaat het met het studentenproject?
En is de github voor dit project al openbaar?

Helaas (of is het juist heel goed?) heeft de opdrachtgever besloten dat het hardware ontwerp zodanig voldoet aan hun eisen dat het als basis kan dienen voor een product voor oa de service mensen van het bedrijf, dus het wordt niet openbaar gemaakt uit concurrentie overwegingen. Er zijn nu studenten bezig met een aansluitend project voor de firmware, dat zal ook niet openbaar worden gemaakt. Jammer dat ik het niet kan delen .

[nairolf]

s020506 schreef op vrijdag 17 oktober 2025 @ 15:43:
[...]


Zoals beloofd, ik heb er nog even naar gekeken. En ik heb die sensor echt niet. Maar dat is niet zo raar als ik naar de code van de integratie kijk. Bij mij wordt deze netjes hernoemd:

https://github.com/home-a...m_gw/binary_sensor.py#L42

Ah ik wist niet dat daar de translation_key voor is, weer wat geleerd

Dus binary_sensor.slave_ch_active_boiler en binary_sensor.opentherm_boiler_central_heating_1 zijn precies hetzelfde. Alleen raar dat deze bij mij hernoemd wordt, en bij jou niet.

Dat zal dan liggen aan het moment van voor het eerst configureren, want ik denk dat dit in de overhaul gedaan is, maar dan passen ze entity ids niet meer aan als ze al bestaan.

[jj85]

Ongelovelijk hoe snel @Lasoul en Wouter hebben gewerkt!
Ik heb net de beta van de HA-integratie geïnstalleerd en dit ziet er super uit
https://github.com/marcob...uatt/releases/tag/0.9.9b2

[TeslaNerd]

Worden de controle opties voor de Chill hiermee ook toegankelijk voor de Home Assistant integratie?

[Lasoul]

TeslaNerd schreef op dinsdag 21 oktober 2025 @ 11:15:
Worden de controle opties voor de Chill hiermee ook toegankelijk voor de Home Assistant integratie?

[Afbeelding]

Dat zou wel mogelijk moeten zijn maar dan moeten we even de specifieke API weten.
Heb je al een Chill draaien?

Er zit nog geen specifieke ondersteuning voor de Chill in maar de integratie is zo opgebouwd dat dit "eenvoudig" kan worden toegevoegd.

[ Voor 11% gewijzigd door Lasoul op 21-10-2025 11:19 ]

[TeslaNerd]

Lasoul schreef op dinsdag 21 oktober 2025 @ 11:17:
[...]


Dat zou wel mogelijk moeten zijn maar dan moeten we even de specifieke API weten.
Heb je al een Chill draaien?

Er zit nog geen specifieke ondersteuning voor de Chill in maar de integratie is zo opgebouwd dat dit "eenvoudig" kan worden toegevoegd.

Nee, ik heb nog geen Chill draaien. Het Chill-in-de-Quatt-app plaatje komt van de Quatt website. Zijn er al Chill gebruikers hier op Tweakers?

Van een email van Quatt op het Quatt Chill tweakersforum las ik:
“Vanaf september starten we met 50 pilotinstallaties bij geselecteerde klanten. Deze kleine groep klanten zullen we in augustus benaderen met een uitnodiging om deel te nemen aan de pilot. Daarna schalen we de verkoop op in de herfst, maar door de grote vraag (4.000 gepre-orderde units) zullen veel installaties pas in de winter plaatsvinden.”

[ Voor 40% gewijzigd door TeslaNerd op 21-10-2025 11:57 ]

[Toby-Wan]

TeslaNerd schreef op dinsdag 21 oktober 2025 @ 11:50:
[...]

Nee, ik heb nog geen Chill draaien. Het Chill-in-de-Quatt-app plaatje komt van de Quatt website. Zijn er al Chill gebruikers hier op Tweakers?

Van een email van Quatt op het Quatt Chill tweakersforum las ik:
“Vanaf september starten we met 50 pilotinstallaties bij geselecteerde klanten. Deze kleine groep klanten zullen we in augustus benaderen met een uitnodiging om deel te nemen aan de pilot. Daarna schalen we de verkoop op in de herfst, maar door de grote vraag (4.000 gepre-orderde units) zullen veel installaties pas in de winter plaatsvinden.”

Die zullen waarschijnlijk een NDA hebben moeten tekenen, zelfde als met de AE pilots, die mochten ook niks zeggen

[HBO88]

Toby-Wan schreef op dinsdag 21 oktober 2025 @ 16:41:
[...]

Die zullen waarschijnlijk een NDA hebben moeten tekenen, zelfde als met de AE pilots, die mochten ook niks zeggen

Waarschijnlijk. Ik heb nooit iets hoeven tekenen, was meer een gentleman agreement dat ik niets zou zeggen over mijn pilot installatie .
Wacht zelf ook met smart op info

[TeslaNerd]

HBO88 schreef op dinsdag 21 oktober 2025 @ 18:17:
[...]

Waarschijnlijk. Ik heb nooit iets hoeven tekenen, was meer een gentleman agreement dat ik niets zou zeggen over mijn pilot installatie .
Wacht zelf ook met smart op info

Gebruik jij de Quatt integratie in Home Assistant?

[HBO88]

TeslaNerd schreef op dinsdag 21 oktober 2025 @ 19:10:
[...]

Gebruik jij de Quatt integratie in Home Assistant?

ja