Ervaringen met Quatt en HA en andere Domotica

[JazekerXX]

patrickvdhart schreef op dinsdag 9 april 2024 @ 07:43:
[...]


KISS: Keep it Simple, Stupid. Oftewel hou dingen binnen de mogelijkheden zo simpel mogelijk.

Wat betreft ESPHome, ben ik ook groot fan van en gebruik ik veel. Daarom baalde ik dat ik de shield niet via ESPHome kon aansturen.
Ben nu bezig zelfbouw radiator fans to bouwen met hulp van ESPhome waarbij ik ook de in en uit water temperatuur meet en doorstuur. Bijna klaar.

aha, thx..

er zijn wel wat projecten met esphome en OT alleen heb ik die niet geprobeerd zoals deze:
https://github.com/rsciriano/ESPHome-OpenTherm

ook zag ik ergens misschien wel in die github dat je ook je eigen module als het ware in esphome kunt laden.
dus ergens in een mapje kun je dat dan neerzetten en in esphome gewoon includen of zo iets. maar goed daar heb ik me nog niet verder in verdiept.. maar wel interessant want ik ben ook wel fan van die esphome, het werkt gewoon makkelijk en ook fijn dat je online logging etc kunt bekijken en ook de firmware gewoon online aankunt passen. top systeem!

voor de radiator fans had ik idd dat ook al gemaakt met esphome met een mosfet op 17,5khz pwm zodat je geen coilwhine hebt. en ds18b20 temp sensoren die je op de cv leidingen kunt tapen.. maar goed achteraf had ik het niet nodig.

hier de esphome code waarmee je ook sliders etc hebt om de pwm sturing te kunnen bedienen:

code:

esphome:
  name: radiator-ventilators-sk-dm-sk-j
  friendly_name: Radiator ventilators sk-dm sk-j

esp8266:
  board: d1_mini

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "jouw key"
  
  services:
    - service: set_fans_sk_dm_percent_pwm_2
      variables:
        percentage: int
      then:
        - lambda: |-
            id(fans_sk_dm_percent_pwm) = percentage;
            id(fans_sk_dm_pwm_level).publish_state(percentage);
    - service: set_fans_sk_j_percent_pwm
      variables:
        percentage: int
      then:
        - lambda: |-
            id(fans_sk_j_percent_pwm) = percentage;
            id(fans_sk_j_pwm_level).publish_state(percentage);

ota:
  password: "jouw pw"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Radiator-Ventilators-Sk-Dm-Sk-J"
    password: "pw"

# Enable Web server
web_server:
  port: 80

captive_portal:

#GPIO's GPIO 5 (D1), GPIO 4 (D2), GPIO 0 (D3), GPIO 2 (D4), GPIO 1 (TX), GPIO 3 (RX).
#GPIO's GPIO 16 (D0), GPIO 14 (D5), GPIO 12 (D6), GPIO 13 (D7), GPIO 15 (D8).

#DS18B20 temperature sensors pin
dallas:
  - pin: D0

output:
  - platform: esp8266_pwm
    pin: D5
    frequency: 17500 Hz
    id: fans_sk_dm
    min_power: 0.00
    max_power: 1.00
  - platform: esp8266_pwm
    pin: D6
    frequency: 17500 Hz
    id: fans_sk_j
    min_power: 0.00
    max_power: 1.00

globals:
#Sensor om PWM percentage weer te geven
  - id: fans_sk_dm_percent_pwm
    type: int
  - id: fans_sk_j_percent_pwm
    type: int

sensor:
#Sensor om PWM percentage weer te geven
# example: https://community.home-assistant.io/t/esphome-configuration-for-pwm-to-0-10v-output-sensor-and-control/296445/14
  - platform: template
    name: "Fans SK-DM (PWM level)"
    id: fans_sk_dm_pwm_level
    lambda: 'return id(fans_sk_dm_percent_pwm);'
    update_interval: 60s
    unit_of_measurement: "%"
    accuracy_decimals: 0
    icon: "mdi:pulse"
    on_value:
      then:
        - lambda: |-
            id(fans_sk_dm).set_level(x/100);
  - platform: template
    name: "Fans SK-J (PWM level)"
    id: fans_sk_j_pwm_level
    lambda: 'return id(fans_sk_j_percent_pwm);'
    update_interval: 60s
    unit_of_measurement: "%"
    accuracy_decimals: 0
    icon: "mdi:pulse"
    on_value:
      then:
        - lambda: |-
            id(fans_sk_j).set_level(x/100);

#DS18B20 sensoren    
  - platform: dallas
    address: 0x953c01a816e55928
    id: "retour_cv"
    name: "Retour CV"
    unit_of_measurement: "°C"
    #resolution: 9
    filters:
    - offset: 3.0
    #- filter_out: "nan"
  - platform: dallas
    address: 0x0c3c01a8161a9328
    name: "Aanvoer CV"
    unit_of_measurement: "°C"
    #resolution: 9
    filters:
    - offset: 2.3
    #- filter_out: "nan"

#Fan speed sensoren
  - platform: pulse_counter
    pin: D7
    name: "Fan speed SK-DM"
    unit_of_measurement: 'RPM'
    filters:
      - multiply: 0.5
    count_mode:
      rising_edge: INCREMENT
      falling_edge: DISABLE
    update_interval: 3s
  - platform: pulse_counter
    pin: D8
    name: "Fan speed SK-J"
    unit_of_measurement: 'RPM'
    filters:
      - multiply: 0.5
    count_mode:
      rising_edge: INCREMENT
      falling_edge: DISABLE
    update_interval: 3s

edit: code toegevoegd

[ Voor 57% gewijzigd door JazekerXX op 09-04-2024 20:17 ]

[Freeckje]

Is er een forumlid die een Evohome thermostaat/systeem in bedrijf heeft, en ook de json data logt?
Of een andere TS die de CiC op watertemperatuur aanstuurt.

Sinds gisteren staat mijn CiC op watertemperatuur aansturing. Na 1 dag testen geeft dat qua kamertemp en qua kw_verbruik, een heel stabiel beeld. Geen overshoots meer . Ik gebruik daarvoor een DIY-thermostaat (esp8266 icm Opentherminterface).
Echter bij een overgang van het watertemp-setpoint (otFtControlSetpoint) van bv 30 naar 28 graden C zie ik een pendelende Wp, ca 6 keer aan en uit per uur. Op het laagste vermogensnivo (ca 370 watt input) ! Qua verwarming doet ie het prima, maar ja, wat vindt de compressor hiervan?
Is dit normaal (PWM)gedrag van de CiC, en constateren jullie cq de Evohome-gebruikers dit ook? Je zou toch verwachten dat de CiC dit in de hand houdt!

[ Voor 34% gewijzigd door Freeckje op 12-04-2024 09:13 ]

[Flesym]

Freeckje schreef op donderdag 11 april 2024 @ 16:35:
Is er een forumlid die een Evohome thermostaat/systeem in bedrijf heeft, en ook de json data logt?
Of een andere TS die de CiC op watertemperatuur aanstuurt.

Sinds gisteren staat mijn CiC op watertemperatuur aansturing. Na 1 dag testen geeft dat qua kamertemp en qua kw_verbruik, een heel stabiel beeld. Geen overshoots meer . Ik gebruik daarvoor een DIY-thermostaat (esp8266 icm Opentherminterface).
Echter bij een overgang van het watertemp-setpoint (otFtControlSetpoint) van bv 30 naar 28 graden C zie ik een pendelende Wp, ca 6 keer aan en uit per uur. Op het laagste vermogensnivo (ca 370 watt input) ! Qua verwarming doet ie het prima, maar ja, wat vindt de compressor hiervan?
Is dit normaal (PWM)gedrag van de CiC, en constateren jullie cq de Evohome-gebruikers dit ook? Je zou toch verwachten dat de CiC dit in de hand houdt! [Afbeelding]

PS: ik heb een workaround in gedachten. Moduleer het setpoint met bv + en - 2 graden om het half uur, en vergroot daarmee de hysterese van de regellus. Timing afhankelijk van vertraging afgifte systeem maar hierdoor zal de compressor naar schatting max 2 per uur schakelen.

Geen Evohome meer en nu sturing op 'room temperature'.

Maar weet je zeker dat het de thermostaat is die schakelt? Ik zag dat gedrag 1,5 week geleden ook af en toe terwijl ik nu 'room temperature' gebruik. En bij mij stond in die situaties de 'thermostat heating' continue op 2. Dus mijn conclusie was dat dit de CIC was die het veroorzaakte (er was wel continue vraag vanuit de thermostaat).
Overigens leek het alleen bij specifieke buitentemperaturen voor te komen. De laatste dagen is het iets warmer en zie ik het niet meer.

[Freeckje]

Flesym schreef op donderdag 11 april 2024 @ 21:13:
[...]


Geen Evohome meer en nu sturing op 'room temperature'.

Maar weet je zeker dat het de thermostaat is die schakelt? Ik zag dat gedrag 1,5 week geleden ook af en toe terwijl ik nu 'room temperature' gebruik. En bij mij stond in die situaties de 'thermostat heating' continue op 2. Dus mijn conclusie was dat dit de CIC was die het veroorzaakte (er was wel continue vraag vanuit de thermostaat).
Overigens leek het alleen bij specifieke buitentemperaturen voor te komen. De laatste dagen is het iets warmer en zie ik het niet meer.

Dat de CiC schakelt en niet de TS beweer ik ook in mijn post. (Ik heb zelfs nog geen Evohome ). Ik stuur alleen met de esp8266 het controlsetpoint, verder niets. Quatt gaf eerder te kennen dat de Evohome (een instelling van deze TS) niet meer dan 3 keer per uur mag schakelen. Echter de CiC schakelt zelf al 5 tot 6 keer per uur.
Waarom hebben ze geen tijdsvertraging ingebouwd oid om te snel schakelen te voorkomen???
Mogelijk dat Evohome er een regeling bovenop gooit, geen idee dus, vandaar mijn post....

[ Voor 16% gewijzigd door Freeckje op 12-04-2024 09:14 ]

[Flesym]

Freeckje schreef op donderdag 11 april 2024 @ 22:14:
[...]

Dat de CiC schakelt en niet de TS beweer ik ook in mijn post. (Ik heb zelfs nog geen Evohome ). Ik stuur alleen met de esp8266 het controlsetpoint, verder niets. Quatt gaf eerder te kennen dat de Evohome (een instelling van deze TS) niet meer dan 3 keer per uur mag schakelen. Echter de CiC schakelt zelf al 5 tot 6 keer per uur.
Waarom hebben ze geen tijdsvertraging ingebouwd oid om te snel schakelen te voorkomen???
Mogelijk dat Evohome er een regeling bovenop gooit, geen idee dus, vandaar mijn post....

PS: je krijgt naar zeggen (ergens op een Quatt forum gelezen) alleen tempaansturing als je een Evohome of Nest gebruikt. Dus dat heb ik maar aan Quatt doorgeven. Niet verder vertellen

Sorry, was me niet helemaal duidelijk.
Ik zie inderdaad veel CIC gedrag waaruit lijkt dat ze bij Quatt vooral aan 'happy flow coding' doen en weinig inbouwen voor fout of anomaly situaties.

[0xygen500]

Is het ook mogelijk je cv verbruik voor de quatt uit de integratie van HA te halen?

[Flesym]

Nooit geprobeerd maar in theorie moet het volgens mij wel kunnen als je een P1 meter hebt. HA logt het gasgebruik dus zou je de op de momenten dat Heatpump boiler heating aan is het gasgebruik moeten cummuleren.

[0xygen500]

Flesym schreef op vrijdag 12 april 2024 @ 12:23:
Nooit geprobeerd maar in theorie moet het volgens mij wel kunnen als je een P1 meter hebt. HA logt het gasgebruik dus zou je de op de momenten dat Heatpump boiler heating aan is het gasgebruik moeten cummuleren.

Maar hoe weet je dan of het gasgebruik heatpump is of ook gedeeltelijk douche? 😋

[RxRxR]

Je kan het geleverde vermogen van de CV bepalen aan de hand van het temperatuursverschil tussen Quatt water uit, de temperatuur van de flowmeter, en de flow. Zo zal de quatt app dat ook doen verwacht ik

[0xygen500]

RxRxR schreef op vrijdag 12 april 2024 @ 12:37:
Je kan de geleverde vermogen van de CV bepalen aan de hand van het temperatuursverschil tussen Quatt water uit, de temperatuur van de flowmeter, en de flow. Zo zal de quatt app dat ook doen verwacht ik

En hoe/waar in ha krijg ik zo'n formule werkende? 😁

[Timmy]

0xygen500 schreef op vrijdag 12 april 2024 @ 12:48:
En hoe/waar in ha krijg ik zo'n formule werkende? 😁

Dat doe je aan de hand van templates, met wat rekenwerk op basis van verschillende sensoren en de waardes.

[0xygen500]

Timmy schreef op vrijdag 12 april 2024 @ 12:50:
[...]

Dat doe je aan de hand van templates, met wat rekenwerk op basis van verschillende sensoren en de waardes.

Thanks, ga ik ff daar in duiken

[rvdgaag]

Flesym schreef op vrijdag 12 april 2024 @ 12:23:
Nooit geprobeerd maar in theorie moet het volgens mij wel kunnen als je een P1 meter hebt. HA logt het gasgebruik dus zou je de op de momenten dat Heatpump boiler heating aan is het gasgebruik moeten cummuleren.

Ware het niet dat de gasmeter 1x per uur zijn data draadloos aan de slimme meter stuurt, de P1 data van gas heb je dus vrijwel niets aan.

[Flesym]

rvdgaag schreef op vrijdag 12 april 2024 @ 14:39:
[...]


Ware het niet dat de gasmeter 1x per uur zijn data draadloos aan de slimme meter stuurt, de P1 data van gas heb je dus vrijwel niets aan.

Dat klopt volgens mij niet, HA leest iedere 5 minuten de P1 meter uit.

[Flesym]

0xygen500 schreef op vrijdag 12 april 2024 @ 12:32:
[...]

Maar hoe weet je dan of het gasgebruik heatpump is of ook gedeeltelijk douche? 😋

Omdat SWW een aparte sensor heeft (Heatpump boiler domestic hot water), in ieder geval bij mijn CV ketel..

[ Voor 5% gewijzigd door Flesym op 12-04-2024 17:41 ]

[0xygen500]

Even wat zitten prutsen in home assistant om de Quatt inzichten na te maken.

[TeslaNerd]

Flesym schreef op donderdag 11 april 2024 @ 22:51:
[...]


Sorry, was me niet helemaal duidelijk.
Ik zie inderdaad veel CIC gedrag waaruit lijkt dat ze bij Quatt vooral aan 'happy flow coding' doen en weinig inbouwen voor fout of anomaly situaties.

Quatt heeft van alle geïnstalleerde Quatts de historie per 15 seconden en Quatt heeft op alle aangesloten Quatts een real time monitoring waarmee deze happy flow wordt bewaakt binnen de marges die ze bij Quatt acceptabel vinden.
Binnenkort krijgen wij voor een aantal van deze items in de app een nieuw dashboard voor bijvoorbeeld het aantal aan/uit schakelingen, aantal defrosts en de flow rate.

[TeslaNerd]

Freeckje schreef op donderdag 11 april 2024 @ 16:35:
Is er een forumlid die een Evohome thermostaat/systeem in bedrijf heeft, en ook de json data logt?
Of een andere TS die de CiC op watertemperatuur aanstuurt.

Sinds gisteren staat mijn CiC op watertemperatuur aansturing. Na 1 dag testen geeft dat qua kamertemp en qua kw_verbruik, een heel stabiel beeld. Geen overshoots meer . Ik gebruik daarvoor een DIY-thermostaat (esp8266 icm Opentherminterface).
Echter bij een overgang van het watertemp-setpoint (otFtControlSetpoint) van bv 30 naar 28 graden C zie ik een pendelende Wp, ca 6 keer aan en uit per uur. Op het laagste vermogensnivo (ca 370 watt input) ! Qua verwarming doet ie het prima, maar ja, wat vindt de compressor hiervan?
Is dit normaal (PWM)gedrag van de CiC, en constateren jullie cq de Evohome-gebruikers dit ook? Je zou toch verwachten dat de CiC dit in de hand houdt! [Afbeelding]

Mooi resultaat met de DIYLESS op waterbesturing.

Ik heb dit ook gezien in de 3 weken in januari dat mijn Quatt op waterbesturing werkte icm mijn Honeywell Round die control setpoint, room temperature en heating on/off doorgeeft. De thermostaat stond continu AAN en de CiC liet de compressor uit gaan als de warmtepomp het water te warm liet worden en de compressor al op de laagste frequentie draaide.
Ergens hier op het forum staat het geen probleem moet zijn als de compressor vaker aan en uit schakelt

Zie de discussie in februari in deel 2 van het hoofdforum voor de Quatt:

Gerardwaz schreef op zaterdag 17 februari 2024 @ 19:18

NB stel jouw vraag aan EvoHome bezitters ook in het hoofdforum dan is de kans op respons een stuk groter

[ Voor 13% gewijzigd door TeslaNerd op 13-04-2024 12:44 ]

[Freeckje]

TeslaNerd schreef op zaterdag 13 april 2024 @ 11:14:
[...]

Mooi resultaat met de DIYLESS op waterbesturing.

Ik heb dit ook gezien in de 3 weken in januari dat mijn Quatt op waterbesturing werkte icm mijn Honeywell Round die control setpoint, room temperature en heating on/off doorgeeft. De thermostaat stond continu AAN en de CiC liet de compressor uit gaan als de warmtepomp het water te warm liet worden en de compressor al op de laagste frequentie draaide.
Ergens hier op het forum staat het geen probleem moet zijn als de compressor vaker aan en uit schakelt

Zie de discussie in februari in deel 2 van het hoofdforum voor de Quatt:

Gerardwaz schreef op zaterdag 17 februari 2024 @ 19:18

[Afbeelding]

[Afbeelding]

Momenteel ben ik bezig een (vrij simpel) algoritme te ontwikkelen die dat aan- en uitschakelen onderdrukt.
Er zit in de regeling van de CiC m.i. een fundamentele fout: de CiC regelt obv de aanvoertemperatuur en niet op de retour temperatuur!! Maw als de wp inschakelt zal na een paar minuten het setpoint bereikt worden en schakelt de CiC de wp af, en kort daarna weer aan. Hij pendelt als een gek, wel 6 a 7 keer per uur, ook al mag dat off the record van Quatt, mij staat het niet aan. Het bereiken van het setpoint wordt daarmee ook onnodig vertraagd. Quatt gebruikt geen buffervat en adverteren daar ook mee. Maar ondertussen maken ze geen gebruik van de bufferwerking van de CV-installatie, en laten de wp onnodig pendelen. Hopelijk heb ik de regelaar van het weekend gereed en laat de resultaten zien.

[TeslaNerd]

Freeckje schreef op zaterdag 13 april 2024 @ 12:59:
[...]

Momenteel ben ik bezig een (vrij simpel) algoritme te ontwikkelen die dat aan- en uitschakelen onderdrukt.
Er zit in de regeling van de CiC m.i. een fundamentele fout: de CiC regelt obv de aanvoertemperatuur en niet op de retour temperatuur!! Maw als de wp inschakelt zal na een paar minuten het setpoint bereikt worden en schakelt de CiC de wp af, en kort daarna weer aan. Hij pendelt als een gek, wel 6 a 7 keer per uur, ook al mag dat off the record van Quatt, mij staat het niet aan. Het bereiken van het setpoint wordt daarmee ook onnodig vertraagd. Quatt gebruikt geen buffervat en adverteren daar ook mee. Maar ondertussen maken ze geen gebruik van de bufferwerking van de CV-installatie, en laten de wp onnodig pendelen. Hopelijk heb ik de regelaar van het weekend gereed en laat de resultaten zien.

Scherp gezien. Ik had mijn eigen indirecte waterbesturing recent ook al aangepast naar de retourtemperatuur (dat is de hp1.temperatureWaterIn in de json) maar met de lage delta t in mijn systeem was mij dat nog niet opgevallen dat de CiC op WaterOut stuurt.
Of stuurt de CiC op de watertemperatuur van de Flowsensor?
Ik heb nu zelf een paar tijdvertragingen in mijn besturing in Home Assistant ingebouwd waarmee het aantal aan- uitschakelingen maximaal 2 a 3 keer per uur is. Met de huidige temperaturen dat prima. Als het (eind dit jaar?) weer echt koud wordt moet ik dat misschien wat bijstellen. Ook benieuwd hoe jij dit in jouw regelaar gaat inrichten.

[ Voor 14% gewijzigd door TeslaNerd op 13-04-2024 13:24 ]

[Freeckje]

TeslaNerd schreef op zaterdag 13 april 2024 @ 13:17:
[...]

Scherp gezien. Ik had mijn eigen indirecte waterbesturing recent ook al aangepast naar de retourtemperatuur (dat is de hp1.temperatureWaterIn in de json) maar met de lage delta t in mijn systeem was mij dat nog niet opgevallen dat de CiC op WaterOut stuurt.
Of stuurt de CiC op de watertemperatuur van de Flowsensor?

Die twee meetwaarden zijn nagenoeg gelijk, dus dat maakt voor de regeling niets uit. Ik gebruik voor de regeling alleen meetwaarden via Opentherm: retourtemperatuur (of is dat ook de aanvoertemp ), aan/uit status, buitentemperatuur, en voor de aansturing het setpoint vd watertemp.

PS:
1:De CiC retourneert gelukkig de retourtemperatuur via Opentherm!
2: heb mijn punt mbt de regeling doorgegeven aan Quatt, ben benieuwd hoe ze reageren.

[ Voor 12% gewijzigd door Freeckje op 13-04-2024 13:41 ]

[Freeckje]

TeslaNerd schreef op zaterdag 13 april 2024 @ 13:17:
[...]

Scherp gezien. Ik had mijn eigen indirecte waterbesturing recent ook al aangepast naar de retourtemperatuur (dat is de hp1.temperatureWaterIn in de json) maar met de lage delta t in mijn systeem was mij dat nog niet opgevallen dat de CiC op WaterOut stuurt.
Of stuurt de CiC op de watertemperatuur van de Flowsensor?
Ik heb nu zelf een paar tijdvertragingen in mijn besturing in Home Assistant ingebouwd waarmee het aantal aan- uitschakelingen maximaal 2 a 3 keer per uur is. Met de huidige temperaturen dat prima. Als het (eind dit jaar?) weer echt koud wordt moet ik dat misschien wat bijstellen. Ook benieuwd hoe jij dit in jouw regelaar gaat inrichten.

De regelaar heb ik als volgt ingericht (min of meer hetzelfde als wat jij doet?) en kan met esp8266-DIYless combinatie , of met de HA-OTGW combinatie gebruikt worden:
1: lees de aan-uit status uit van de wp (via status OT request-message of via json workingmode)
2: status==aan? Verhoog het watersetpoint met 2,5 graad
3: status==uit? Verlaag het setpoint met 2,5 graad
Je kunt 2 en 3 combineren met een tijdsvertraging om de PWM aan-uit tijden te optimaliseren.
Resultaat: je introduceert meer hysterese en daarmee een rustiger verloop van de regelaar en de watertemperatuur, veel minder aan uit schakelingen van de wp. Gemiddelde watertemp komt beter overeen met het watersetpoint. Na 1 dag testen niet te snel conclusies trekken, maar het ziet goed uit.

Volgende stap:
1: Regeling TS obv stooklijnregeling implementeren in een standalone esp8266-DIYless combinatie (tot Qstat gedoopt ), OF:
2: Huidige iSense TS handhaven icm esp8266-DIYless gateway met daarin de nieuwe regeling.

Voordelen optie 2: Het display is er al, incl timing en andere functies. Minder softwareontwikkeling .

[ Voor 11% gewijzigd door Freeckje op 15-04-2024 12:46 ]

[TeslaNerd]

Freeckje schreef op maandag 15 april 2024 @ 12:18:
[...]

De regelaar heb ik als volgt ingericht (min of meer hetzelfde als wat jij doet?) en kan met esp8266-DIYless combinatie , of met de HA-OTGW combinatie gebruikt worden:
1: lees de aan-uit status uit van de wp (via status OT request-message of via json workingmode)
2: status==aan? Verhoog het watersetpoint met 2,5 graad
3: status==uit? Verlaag het setpoint met 2,5 graad
Je kunt 2 en 3 combineren met een tijdsvertraging om de PWM aan-uit tijden te optimaliseren.
Resultaat: je introduceert meer hysterese en daarmee een rustiger verloop van de regelaar en de watertemperatuur, veel minder aan uit schakelingen van de wp. Gemiddelde watertemp komt beter overeen met het watersetpoint. Na 1 dag testen niet te snel conclusies trekken, maar het ziet goed uit. [Afbeelding]

Volgende stap:
1: Regeling TS obv stooklijnregeling implementeren in een standalone esp8266-DIYless combinatie (tot Qstat gedoopt ), OF:
2: Huidige iSense TS handhaven icm esp8266-DIYless gateway met daarin de nieuwe regeling.

Voordelen optie 2: Het display is er al, incl timing en andere functies. Minder softwareontwikkeling .

Niet slecht voor een weekendje coden. Benieuwd hoe de grafiek van de watersetpoint er nu uit ziet. En wat is de Flow waarde op 6.84?

[Freeckje]

TeslaNerd schreef op maandag 15 april 2024 @ 14:29:
[...]

Niet slecht voor een weekendje coden. Benieuwd hoe de grafiek van de watersetpoint er nu uit ziet. En wat is de Flow waarde op 6.84?

Sorry, die flow had ik door 100 gedeeld om hem binnen de grafiek te houden . Dus die stond op 684 l/u. Hierbij plaatje incl watersetpoint. Het watersetpoint stond op 27,5 grC.


PS: het coderen viel wel hoor, quick&dirty al met al 4 regels code Quatt kan dat zo in de CiC coderen, echter hun regelfilosofie ken ik niet. Waarbinnen deze ingreep mogelijk niet past...

[ Voor 10% gewijzigd door Freeckje op 15-04-2024 15:15 ]

[TeslaNerd]

Freeckje schreef op maandag 15 april 2024 @ 14:53:
[...]

Sorry, die flow had ik door 100 gedeeld om hem binnen de grafiek te houden . Dus die stond op 684 l/u. Hierbij plaatje incl watersetpoint. Het watersetpoint stond op 27,5 grC.
[Afbeelding]

PS: het coderen viel wel hoor, quick&dirty al met al 4 regels code Quatt kan dat zo in de CiC coderen, echter hun regelfilosofie ken ik niet. Waarbinnen deze ingreep mogelijk niet past...

Waarom haalt jouw Flow geen 800 l/u?

[Freeckje]

TeslaNerd schreef op maandag 15 april 2024 @ 15:48:
[...]

Waarom haalt jouw Flow geen 800 l/u?

Is dat een noodzaak, is mij niet bekend? Bij installaties met naregeling zal vermoedelijk die flow nog sterker varieren. Ik speel nogal eens met de flow van de vvw (icm de radiatoren), waardoor die zo maar weer richting 800 kan gaan. Koude radiatoren vinden we nogal oncomfortabel, ben zoekende naar de optimale instellingen, en dan knijp ik soms de vvw af .

[ Voor 5% gewijzigd door Freeckje op 15-04-2024 16:28 ]

[TeslaNerd]

Freeckje schreef op maandag 15 april 2024 @ 16:10:
[...]

Is dat een noodzaak, is mij niet bekend? Bij installaties met naregeling zal vermoedelijk die flow nog sterker varieren. Ik speel nogal eens met de flow van de vvw (icm de radiatoren), waardoor die zo maar weer richting 800 kan gaan. Koude radiatoren vinden we nogal oncomfortabel, ben zoekende naar de optimale instellingen, en dan knijp ik soms de vvw af .

Misschien niet noodzakelijk maar ik dacht dat de Quatt altijd probeert de 800 l/u te halen door de waterpomp in de buitenunit dan harder te laten draaien. Zie jij dat in het stroomverbruik als de Quatt aan gaat voordat de warmtepomp begint draaien?

[Freeckje]

TeslaNerd schreef op maandag 15 april 2024 @ 16:40:
[...]

Misschien niet noodzakelijk maar ik dacht dat de Quatt altijd probeert de 800 l/u te halen door de waterpomp in de buitenunit dan harder te laten draaien. Zie jij dat in het stroomverbruik als de Quatt aan gaat voordat de warmtepomp begint draaien?

Meestal gaat voorafgaande de start van de wp, het gebruik van 5 naar 50 watt.

[TeslaNerd]

Freeckje schreef op maandag 15 april 2024 @ 17:11:
[...]

Meestal gaat voorafgaande de start van de wp, het gebruik van 5 naar 50 watt.

Met alles max open draait mijn pomp 800 l/u op 27-5=22 watt

Misschien ook eens proberen of mijn Quatt langere runs maakt als ik ook ga afknijpen op een lagere flow zodat de radiatoren warmer worden. Hoe bepaal je de ideale flow bij een systeem met radiatoren?

[ Voor 28% gewijzigd door TeslaNerd op 15-04-2024 17:40 ]

[Freeckje]

TeslaNerd schreef op maandag 15 april 2024 @ 17:35:
[...]

Met alles max open draait mijn pomp 800 l/u op 27-5=22 watt

Misschien ook eens proberen of mijn Quatt langere runs maakt als ik ook ga afknijpen op een lagere flow zodat de radiatoren warmer worden

Aha, dus jij zit met hetzelfde probleem als ik . Ja de temp schiet dan omhoog. Ik ga dat mogelijk met een proportionele klep in de aanvoerleiding dynamisch inregelen (volgend project). Een soort DHZ Evohome systeem.

[TeslaNerd]

Freeckje schreef op maandag 15 april 2024 @ 17:44:
[...]

Aha, dus jij zit met hetzelfde probleem als ik . Ja de temp schiet dan omhoog. Ik ga dat mogelijk met een proportionele klep in de aanvoerleiding dynamisch inregelen (volgend project). Een soort DHZ Evohome systeem.

Ja daar lijkt het wel op. Moeten wij eigenlijk ook gewoon eens aan Quatt support vragen zodat zij de flow lager kunnen zetten zonder dat de pomp harder hoeft te werken

Welke temp schiet dan omhoog? En heb jij ook andere flowrates langdurig getest hoger of lager dan deze ca 680 l/u?

[ Voor 14% gewijzigd door TeslaNerd op 15-04-2024 17:53 ]

[Freeckje]

TeslaNerd schreef op maandag 15 april 2024 @ 17:48:
[...]

Ja daar lijkt het wel op. Moeten wij eigenlijk ook gewoon eens aan Quatt support vragen zodat zij de flow lager kunnen zetten zonder dat de pomp harder hoeft te werken

Welke temp schiet dan omhoog?

De flowtemp, dus de uitgaande temp van de wp.

Ik heb de toevoerklep van de vvw statisch ingesteld zodanig dat de radiatoren (bij dit weertype) voldoende flow krijgen. Maar daar moet ik verder mee experimenteren. De vraag is of die instelling ook voldoet als het vriest...

[ Voor 24% gewijzigd door Freeckje op 15-04-2024 18:32 ]

[TeslaNerd]

Freeckje schreef op maandag 15 april 2024 @ 17:53:
[...]

De flowtemp, dus de uitgaande temp van de wp.

Ik heb de toevoerklep van de vvw statisch ingesteld zodanig dat de radiatoren (bij dit weertype) voldoende flow krijgen. Maar daar moet ik verder mee experimenteren. De vraag is of die instelling ook voldoet als het vriest...

Ik zie dat jij met de lage flow en lage power input een warmte output van 2,5 kW haalt. Gaat jouw cop en de warmte output omhoog of omlaag als jij de flow laat oplopen naar 800 l/u?

[Freeckje]

TeslaNerd schreef op maandag 15 april 2024 @ 18:37:
[...]

Ik zie dat jij met de lage flow en lage power input een warmte output van 2,5 kW haalt. Gaat jouw cop en de warmte output omhoog of omlaag als jij de flow laat oplopen naar 800 l/u?

In het algemeen zal de Cop omhoog gaan als de flow hoger wordt omdat de gemiddelde temp van de warmtewisselaar aan de CV-kant van de wp wat lager wordt, en daarmee de warmteoutput (kw) hoger.

[ Voor 25% gewijzigd door Freeckje op 15-04-2024 19:28 ]

[TeslaNerd]

Freeckje schreef op maandag 15 april 2024 @ 18:53:
[...]

In het algemeen zal de Cop omhoog gaan als de flow hoger wordt omdat de gemiddelde temp van de warmtewisselaar aan de CV-kant van de wp wat lager wordt, en daarmee de warmteoutput (kw) hoger.

Ik bedoel hoe de delta temperatuur bij jou reageert op de lagere flow bij de laagste compressor frequentie die wij nu met dit voorjaarsweer hebben. Reageert de verandering in delta temperatuur omgekeerd evenredig op de verandering in de flowrate?

[Freeckje]

TeslaNerd schreef op maandag 15 april 2024 @ 19:47:
[...]

Ik bedoel hoe de delta temperatuur bij jou reageert op de lagere flow bij de laagste compressor frequentie die wij nu met dit voorjaarsweer hebben. Reageert de verandering in delta temperatuur omgekeerd evenredig op de verandering in de flowrate?

Ok.
Ik heb dat niet uitgeprobeerd omdat ik de flow nu statisch heb ingesteld. Echter het antwoord volgt rechtstreeks uit de warmte die elke WP produceert nl:
Output = flow (liters/minuut) * delta T (Tuit - Tin).
Dus het antwoord is ja echter binnen bepaalde grenzen , nl binnen de randvoorwaarden die de fabrikant als optimum opgeeft. Als je het echt wilt weten zal je dat proefondervindelijk moeten vaststellen.

[ Voor 11% gewijzigd door Freeckje op 15-04-2024 22:21 ]

[TeslaNerd]

Freeckje schreef op maandag 15 april 2024 @ 20:43:
[...]

Ok.
Ik heb dat niet uitgeprobeerd omdat ik de flow nu statisch heb ingesteld. Echter het antwoord volgt rechtstreeks uit de warmte die elke WP produceert nl:
Output = flow (liters/minuut) * delta T (Tuit - Tin).
Dus het antwoord is ja echter binnen bepaalde grenzen , nl binnen de randvoorwaarden die de fabrikant als optimum opgeeft. Als je het echt wilt weten zal je dat proefondervindelijk moeten vaststellen.

Ik heb het geprobeerd op de ca 680 l/u statisch. Dat geeft ongeveer dezelfde warmteopbrengst met een evenredig hogere delta t. Ik moest mijn radiatoren zoveel dichtdraaien dat het flink begon te ruisen in de leidingen. Als ik meer tijd heb kan ik proberen het afknijpen beter te verdelen over de radiatoren met mogelijk minder geruis.
Hoe ben jij op de statische instelling van 680 l/u uitgekomen? Was dat toeval waar jij op zoek was naar meer warmteafgifte op jouw radiatoren?

[Freeckje]

TeslaNerd schreef op maandag 15 april 2024 @ 23:06:
[...]

Ik heb het geprobeerd op de ca 680 l/u statisch. Dat geeft ongeveer dezelfde warmteopbrengst met een evenredig hogere delta t. Ik moest mijn radiatoren zoveel dichtdraaien dat het flink begon te ruisen in de leidingen. Als ik meer tijd heb kan ik proberen het afknijpen beter te verdelen over de radiatoren met mogelijk minder geruis.
Hoe ben jij op de statische instelling van 680 l/u uitgekomen? Was dat toeval waar jij op zoek was naar meer warmteafgifte op jouw radiatoren?

Dat laatste, Ik was teleurgesteld in de lage gevoelstemp van de radiatoren (en te koele badkamer), daarom heb ik de vvw afgeknepen tot de huidige waarde. Echter wat doet dat in de winter?

Bovengenoemde heeft op zich niet persee met een wp te maken, bij onze gas-cv had ik de TS op stooklijnbedrijf staan en voelde de radiatoren ook koel aan. Ook dan merk je bij omgevingstemp vanaf ca 10 graden dat de gevoelstemp van de radiatoren achterblijft. TS op kamertemp-aansturing instellen gaf ook een slecht resultaat: beneden alles warm, boven te koud!

Mogelijke aanpak is om een vorm van zoneregeling te gaan toepassen door actief de vvw af te knijpen als functie van de buitentemp.

We dwalen wel af van het topic

[TeslaNerd]

Freeckje schreef op maandag 15 april 2024 @ 14:53:
[...]

Sorry, die flow had ik door 100 gedeeld om hem binnen de grafiek te houden . Dus die stond op 684 l/u. Hierbij plaatje incl watersetpoint. Het watersetpoint stond op 27,5 grC.
[Afbeelding]

PS: het coderen viel wel hoor, quick&dirty al met al 4 regels code Quatt kan dat zo in de CiC coderen, echter hun regelfilosofie ken ik niet. Waarbinnen deze ingreep mogelijk niet past...

Ja verder on topic:
Zet jij zelf de water setpoint op 27,5? Of is dat wat DIYLESS thermostaat vraagt?
En jij verhoogt de water setpoint met 2,5 graden als de Quatt aan gaat, zodat de Quatt een langere run gaat maken. En door die extra 2,5 graden groter of kleiner te maken wordt de run nog langer of weer wat korter?

[Freeckje]

TeslaNerd schreef op dinsdag 16 april 2024 @ 00:30:
[...]

Ja verder on topic:
Zet jij zelf de water setpoint op 27,5? Of is dat wat DIYLESS thermostaat vraagt?
En jij verhoogt de water setpoint met 2,5 graden als de Quatt aan gaat, zodat de Quatt een langere run gaat maken. En door die extra 2,5 graden groter of kleiner te maken wordt de run nog langer of weer wat korter?

Btw: ik gebruik geen DIYless thermostaat, ik heb zelf een TS gemaakt bestaande uit esp8266 en een OT-module. En genereer inderdaad zelf het setpoint precies zoals je het beschrijft. M.n. de langere runs (de CiC hanteert zo te zien runs van ca 5 minuten...terwijl ze max 3 runs (aan/uit) per uur aanbevelen).
Daardoor minder gependel bij lage vermogensvraag. Regelen op watertemp werkt als een speer, totaal geen overshoots meer!

[ Voor 7% gewijzigd door Freeckje op 16-04-2024 09:18 ]

[TeslaNerd]

Freeckje schreef op dinsdag 16 april 2024 @ 09:07:
[...]

Btw: ik gebruik geen DIYless thermostaat, ik heb zelf een TS gemaakt bestaande uit esp8266 en een OT-module. En genereer inderdaad zelf het setpoint precies zoals je het beschrijft. M.n. de langere runs (de CiC hanteert zo te zien runs van ca 5 minuten...terwijl ze max 3 runs (aan/uit) per uur aanbevelen).
Daardoor minder gependel bij lage vermogensvraag. Regelen op watertemp werkt als een speer, totaal geen overshoots meer!

O ja dat had jij al eens gepost. De OT master shield van Igor Ybema als ik het goed zie op de foto. Wat is die witrode draad die jij er aan hebt gesoldeerd?

https://www.tindie.com/pr...er-shield-for-wemoslolin/

[Freeckje]

TeslaNerd schreef op dinsdag 16 april 2024 @ 09:26:
[...]

O ja dat had jij al eens gepost. De OT master shield van Igor Ybema als ik het goed zie op de foto. Wat is die witrode draad die jij er aan hebt gesoldeerd?

https://www.tindie.com/pr...er-shield-for-wemoslolin/

[Afbeelding]

Dat is het kabeltje naar de tempsensor DS1820, die zat gesoldeerd op de print. Dat is niet aan te bevelen vanwege opwarming van de sensor via de print.
Daarom is ie nu aangesloten via een 50 cm lang 3 aderig kabeltje.

[TeslaNerd]

Freeckje schreef op dinsdag 16 april 2024 @ 15:16:
[...]

Dat is het kabeltje naar de tempsensor DS1820, die zat gesoldeerd op de print. Dat is niet aan te bevelen vanwege opwarming van de sensor via de print.
Daarom is ie nu aangesloten via een 50 cm lang 3 aderig kabeltje.

Is de voeding van deze thermostaat via de aansluiting op de CiC?

[Freeckje]

TeslaNerd schreef op dinsdag 16 april 2024 @ 16:23:
[...]

Is de voeding van deze thermostaat via de aansluiting op de CiC?

Nee, via een usb-adapter op het esp8266-bordje.

[TeslaNerd]

Ik heb de esp32 met rs485 binnen en via ESPHome geïnstalleerd in mijn Home Assistant. Dat lijkt allemaal goed te zijn gegaan en ik heb vervolgens het boardje met 3 draadjes aangesloten op de AGB poort van de CiC waar ook de kabel naar de Quatt unit op zit.
Alles weer aangezet en ik zie het Rx ledje op het boardje vrolijk knipperen



En hier nogmaals de documentatie bij het boardje van Igor Ypema via https://www.tindie.com/pr...s-and-optional-touch-tft/

What is it?
This is an ESP32-C3-MINI-1-N4 with RS485 all together on one board. The ESP32-C3-MINI-1-N4 contains the ESP32-C3 SoC which is a successor for the well known ESP8266 microcontroller. The RS485 exists of auto-send-receive with MAX485 chip.

IOT home users who want to talk to modbus devices generally some ready available components are connected together to create a arduino modbus capable device. However this is often not the best of connection due to all the wiring which is necessary between all the components. This board makes it easy and allows you to run you modbus code.

It is an intergrated complete design. Just connect power (USB-C) and your modbus device, upload some code, and you have a nice working device!
The RS485 is connected to the hardware uart rx/tx (gpio20/gpio21). Therefore you can't use serial output and RS485 together.

The basic option contains of only the PCB with the ESP32-C3-MINI-1-N4, the USB-C connector and a soldered connector for the RS485 connection. This allows it to be used as basic ESP32-C3-MINI-1-N4 modbus master or slave.

The module is powered using the USB-C connector or with external 5v soldered to the power connections on the board.

ESPhome can also be installed but make sure to turn of logging via UART (set baudrate to 0) as the RS485 uses the onboard UART (tx/rx).

[ Voor 243% gewijzigd door TeslaNerd op 23-04-2024 20:03 ]

[rvdgaag]

[quote]TeslaNerd schreef op vrijdag 19 april 2024 @ 18:34:
Ik heb de esp32 met rs485 binnen en via ESPHome geïnstalleerd in mijn Home Assistant. Dat lijkt allemaal goed te zijn gegaan en ik heb vervolgens het boardje met 3 draadjes aangesloten op de AGB poort van de CiC waar ook de kabel naar de Quatt unit op zit.
Alles weer aangezet en ik zie het Rx ledje op het boardje vrolijk knipperen


Als ik naar je filmpje kijk is hij parallel aangesloten op de uitgang naar de Quatt buiten unit , probeer hem eens op de poort te zetten waar het computer symbool op staat.

De massa poort kan je weglaten, wordt alleen aangesloten wanneer je een modbus 2 aderige kabel hebt met een massa mantel eromheen. Schermt af van externe invloeden bij lange lengtes (radioantenne princiepe).

[ Voor 21% gewijzigd door rvdgaag op 20-04-2024 11:16 ]

[TeslaNerd]

rvdgaag schreef op zaterdag 20 april 2024 @ 11:13:
[quote]TeslaNerd schreef op vrijdag 19 april 2024 @ 18:34:
Als ik naar je filmpje kijk is hij parallel aangesloten op de uitgang naar de Quatt buiten unit , probeer hem eens op de poort te zetten waar het computer symbool op staat.

De massa poort kan je weglaten, wordt alleen aangesloten wanneer je een modbus 2 aderige kabel hebt met een massa mantel eromheen. Schermt af van externe invloeden bij lange lengtes (radioantenne princiepe).

Ik heb de instructies van de maker van het boardje gevolgd: “You could connect the controller to that AGB (A, gnd, B ) port and just listen on modbus was it going on there.”

Ik heb A met A, B met B en G met G verbonden. Hoe zou ik het anders moeten aansluiten?

Die andere poort met de pc afbeelding heb ik ook geprobeerd maar dan zag ik het Rx ledje niet branden

Ik heb in ESPHome nu gekozen voor het direct uitlezen van de uart maar ik kan ook gebruik maken van de modbus controller. Die heeft wel meer instellingen nodig zoals baudrate stopbits bytesize parity en method rtu/tcp. Is daar voor de modbus van Quatt al iets van bekend?

[ Voor 31% gewijzigd door TeslaNerd op 20-04-2024 12:32 ]

[TeslaNerd]

Ok, het was de baudrate die moet op 9600 19200. Ik krijg nu met uitlezen van uart in ieder geval een datastroom die lijkt te matchen met de QC supervisory control mode in de json als ik die van standby naar heating en weer terug naar standby laat gaan door de thermostaat even omhoog en weer omlaag te zetten

[ Voor 237% gewijzigd door TeslaNerd op 23-04-2024 20:05 ]

[RxRxR]

edit:niet meer van toepassing

[ Voor 147% gewijzigd door RxRxR op 20-04-2024 13:11 ]

[RxRxR]

Interresant om te volgen of je er iets uit krijgt. Kan je zien wat er over de bus gaat? Is dat enkel aan/uit en een bepaald vermogen, of zie je ook specifieke instellingen voor bijvoorbeeld compressor, fan, etc?

[TeslaNerd]

RxRxR schreef op zaterdag 20 april 2024 @ 13:10:
Interresant om te volgen of je er iets uit krijgt. Kan je zien wat er over de bus gaat? Is dat enkel aan/uit en een bepaald vermogen, of zie je ook specifieke instellingen voor bijvoorbeeld compressor, fan, etc?

Ja, dat is uiteindelijk wat ik hoop te gaan zien. Eerst eens kijken of ik, niet gehinderd door veel kennis van arduino, esp boardjes, home assistant, rs485 en modbus, chocola kan maken van de data die ik nu voorbij zie komen. Volgende stap is volgens mij te kijken of ik met esphome in home assistant de gelezen data kan koppelen aan registers

alle suggesties zijn welkom

Maar zoals de maker van het boardje mij al voorspelde:
"that is really a big hill you need to climb first"

[TeslaNerd]

Ik vond dit project voor het modbus sniffen van een new motion laadpaal met deze aanpak:

https://github.com/tnagels/newmotion_energy_sniffer

So the device passively listens to the messages being sent. Unfortunately the Modbus protocol used unfortunately does not easiliy allow to differentiate between messages sent by the master and those sent by the slave. To solve this I wait for a timeout in the communication, then after that I assume what follows is a new message by the master, followed by the reply from the slave. This is a really messy, nasty way of doing things, but it works.

Is dat een methode die ik voor de Quatt modbus ook kan toepassen?

[Freeckje]

TeslaNerd schreef op zaterdag 20 april 2024 @ 13:34:
Ik vond dit project voor het modbus sniffen van een new motion laadpaal met deze aanpak:

https://github.com/tnagels/newmotion_energy_sniffer

So the device passively listens to the messages being sent. Unfortunately the Modbus protocol used unfortunately does not easiliy allow to differentiate between messages sent by the master and those sent by the slave. To solve this I wait for a timeout in the communication, then after that I assume what follows is a new message by the master, followed by the reply from the slave. This is a really messy, nasty way of doing things, but it works.

Is dat een methode die ik voor de Quatt modbus ook kan toepassen?

Leuk dat al zover gekomen bent .
Je moet mi eerst de timing van het dataverkeer zien uit te pluizen. Normaal gesproken zal de master in een kort berichtje data aan de slave opvragen. Na het antwoord zal de master meestal een delay inbouwen voordat het volgende register request/update (read of write register(s)) volgt. Heb je een scoop of logic analyzer, dan zou je dat kunnen meten/zien.
Wireshark heeft Modbus analyzer mogelijkheden, je zou de seriele data (is dat de ruwe data of reeds geconverteerd naar HEX?) vanuit de esp32 via een seriele usb-ttl adapter aan Wireshark kunnen koppelen.

[ Voor 3% gewijzigd door Freeckje op 20-04-2024 14:26 ]

[TeslaNerd]

Freeckje schreef op zaterdag 20 april 2024 @ 13:47:
[...]

Leuk dat al zover gekomen bent .
Je moet mi eerst de timing van het dataverkeer zien uit te pluizen. Normaal gesproken zal de master in een kort berichtje data aan de slave opvragen. Na het antwoord zal de master meestal een delay inbouwen voordat het volgende register request/update (read of write register(s)) volgt. Heb je een scoop of logic analyzer, dan zou je dat kunnen meten/zien.
Wireshark heeft Modbus analyzer mogelijkheden, je zou de seriele data (is dat de ruwe data of reeds geconverteerd naar HEX?) vanuit de esp32 via een seriele usb-ttl adapter aan Wireshark kunnen koppelen.

Ik heb geen scoop of logic analyzer.
Kan ik dat nu ik de ruwe data heb (als ik het goed zie in HEX) niet met Home Assistant analyseren?

[Freeckje]

TeslaNerd schreef op zaterdag 20 april 2024 @ 15:02:
[...]

Ik heb geen scoop of logic analyzer.
Kan ik dat nu ik de ruwe data heb (als ik het goed zie in HEX) niet met Home Assistant analyseren?

Ik ben onbekend met alle mogelijkheden van HS . Lijkt me lastig als het protocol niet gespecificeerd is je het met HA kunt decoderen. Je moet echt op low level nivo kijken wil je verder kunnen komen. Zie de suggestie in mijn vorige post.
Of: met een PC of Arduino-programmaatje de serieele handshake en data zien te ontwarren. Kan ook in die esp32 , dan zit esphome je ook niet in de weg. Dus uitgaan van de originele ruwe data die je van de CiC ontvangt.

[ Voor 11% gewijzigd door Freeckje op 20-04-2024 15:36 ]

[RxRxR]

Je zal er achter moeten komen wat de verschillende positites in de berichten betekenen. Ik zou een tijdje data verzamelen en vervolgens kijken of sommige posities correleren met andere waardes die je via de json implementatie in HA krijgt. Dus aan/uit, vermogen, temperaturen.

Wellicht dat er in het algemene (niet quatt) warmtepomp topic nog tips zijn hoe dit aan te pakken. De implementatie van Quatt zal waarschijnlijk anders zijn, maar de methodes kunnen allicht helpen. Als ik het me goed herinner is het modbus protocol van de Samsung pompen ook uitgezocht

[TeslaNerd]

RxRxR schreef op zaterdag 20 april 2024 @ 15:40:
Je zal er achter moeten komen wat de verschillende positites in de berichten betekenen. Ik zou een tijdje data verzamelen en vervolgens kijken of sommige posities correleren met andere waardes die je via de json implementatie in HA krijgt. Dus aan/uit, vermogen, temperaturen.

Wellicht dat er in het algemene (niet quatt) warmtepomp topic nog tips zijn hoe dit aan te pakken. De implementatie van Quatt zal waarschijnlijk anders zijn, maar de methodes kunnen allicht helpen. Als ik het me goed herinner is het modbus protocol van de Samsung pompen ook uitgezocht

Ik heb met de zoekfunctie in de Quatt topics hier gezocht maar kom nog weinig concrete informatie tegen over de modbus in de Quatt. De controller print zit in de buitenunit met die Hiplus 3000 D printplaat van Megmeet uit China die ook in andere warmtepompen schijnt te zitten. Daar zal het modbus protocol dan ook wel vandaan komen en niet van Quatt in Nederland

[Freeckje]

Misschien kan je hier inspiratie uit halen?
Zie deze post:https://gathering.tweaker...message/77048650#77048650

[TeslaNerd]

deze ESPHome pagina ben ik nu aan het bestuderen voor het ontcijferen van de ontvangen regels
https://esphome.io/compon..._controller.html#examples

[ Voor 125% gewijzigd door TeslaNerd op 23-04-2024 20:01 ]

[TeslaNerd]

Zonder scoop of logic analyzer lukt het mij nog niet de juiste communicatie instellingen te vinden die met het Modbus protocol van de Quatt bruikbare data oplevert.

Kan iemand die wel over deze tools beschikt meten wat de juiste waarden zouden moeten zijn voor:
baud rate, data bits, parity, stop bits?
Ik begrijp inmiddels dat de gangbare waarden hiervoor 9600-8-N-1 zijn maar ook als ik die gebruik veel CRC fails in de ingelezen data

[JazekerXX]

TeslaNerd schreef op zondag 21 april 2024 @ 14:41:
Zonder scoop of logic analyzer lukt het mij nog niet de juiste communicatie instellingen te vinden die met het Modbus protocol van de Quatt bruikbare data oplevert.

Kan iemand die wel over deze tools beschikt meten wat de juiste waarden zouden moeten zijn voor:
baud rate, data bits, parity, stop bits?
Ik begrijp inmiddels dat de gangbare waarden hiervoor 9600-8-N-1 zijn maar ook als ik die gebruik veel CRC fails in de ingelezen data

9600 baud is de oude standaard. tegenwoordig wordt 115200 veel gebruikt.
maar krijg je naast de crc fails wel leesbare data uit? het is namelijk zo dat wanneer de baudrate goed is, dat je leesbare data ziet ipv rare tekens..

ik zie nu dat je hex codes er uit krijgt. dat is niet echt leesbaar.. kun je het niet op ascii zetten zodat je leesbare tekst krijgt?

[ Voor 8% gewijzigd door JazekerXX op 21-04-2024 16:26 ]

[TeslaNerd]

JazekerXX schreef op zondag 21 april 2024 @ 16:22:
[...]


9600 baud is de oude standaard. tegenwoordig wordt 115200 veel gebruikt.
maar krijg je naast de crc fails wel leesbare data uit? het is namelijk zo dat wanneer de baudrate goed is, dat je leesbare data ziet ipv rare tekens..

ik zie nu dat je hex codes er uit krijgt. dat is niet echt leesbaar.. kun je het niet op ascii zetten zodat je leesbare tekst krijgt?

ESPHome en modbus controller maken er leesbare tekens van maar als ik die door een online modbus parser haal dan wordt het niet herkend. De eerste output hierboven was op 115200 baud en dat gaf vooral veel nullen. De laatste output met meer inhoud is op 9600. Als ik 1 of 2 stopbits kies zie ik de inhoud wel veranderen maar de online modbus parser zegt er nog niets van te kunnen maken. En ik blijf die CRC fails houden

https://rapidscada.net/modbus/

[JazekerXX]

TeslaNerd schreef op zondag 21 april 2024 @ 18:14:
[...]

ESPHome en modbus controller maken er leesbare tekens van maar als ik die door een online modbus parser haal dan wordt het niet herkend. De eerste output hierboven was op 115200 baud en dat gaf vooral veel nullen. De laatste output met meer inhoud is op 9600. Als ik 1 of 2 stopbits kies zie ik de inhoud wel veranderen maar de online modbus parser zegt er nog niets van te kunnen maken. En ik blijf die CRC fails houden

https://rapidscada.net/modbus/

ik denk dat af een toe een crc check fail niet zo erg is, misschien normaal zelfs.

[Freeckje]

TeslaNerd schreef op zondag 21 april 2024 @ 18:14:
[...]

ESPHome en modbus controller maken er leesbare tekens van maar als ik die door een online modbus parser haal dan wordt het niet herkend. De eerste output hierboven was op 115200 baud en dat gaf vooral veel nullen. De laatste output met meer inhoud is op 9600. Als ik 1 of 2 stopbits kies zie ik de inhoud wel veranderen maar de online modbus parser zegt er nog niets van te kunnen maken. En ik blijf die CRC fails houden

https://rapidscada.net/modbus/

Esphome maakt er blijkbaar leesbare hex-code van. Je moet m.i. echter de ruwe data door de Modbus-parser halen. Verder voegt esphome er timestamps aan toe met een resolutie van slechts 1 seconde terwijl de reso in de orde van 10 tot 100 milliseconde moet zijn om de handshake tussen master en slave te kunnen zien in deze records.

Dus die HEX conversie en die time stamps moeten er uit, puur de ruwe data analyseren cq door die Modbus-parser. Het is dan nog de vraag welke variant van Modbus Quatt toepast, misschien weet die parser daar raad mee. Zie dit verhaal:
https://jarnobaselier.nl/hoe-werkt-modbus/

[ Voor 33% gewijzigd door Freeckje op 21-04-2024 20:19 ]

[TeslaNerd]

Freeckje schreef op zondag 21 april 2024 @ 18:46:
[...]

Esphome maakt er blijkbaar leesbare hex-code van. Je moet m.i. echter de ruwe data door de Modbus-parser halen. Verder voegt esphome er timestamps aan toe met een resolutie van slechts 1 seconde terwijl de reso in de orde van 10 tot 100 milliseconde moet zijn om de handshake tussen master en slave te kunnen zien in deze records.

Dus die HEX conversie en die time stamps moeten er uit, puur de ruwe data analyseren cq door die Modbus-parser. Het is dan nog de vraag welke variant van Modbus Quatt toepast, misschien weet die parser daar raad mee. Zie dit verhaal:
https://jarnobaselier.nl/hoe-werkt-modbus/

Kun jij hier wat meer mee?

code:

INFO ESPHome 2024.4.0
INFO Reading configuration /config/esphome/modbus.yaml...
INFO Starting log output from 192.168.178.121 using esphome API
INFO Successfully connected to uarttest @ 192.168.178.121 in 0.032s
INFO Successful handshake with uarttest @ 192.168.178.121 in 0.068s
[21:11:23][I][app:100]: ESPHome version 2024.4.0 compiled on Apr 21 2024, 14:30:44
[21:11:23][C][wifi:580]: WiFi:
[21:11:23][C][wifi:408]:   Local MAC: DC:DA:0C:C5:6E:98
[21:11:23][C][wifi:413]:   SSID: [redacted]
[21:11:23][C][wifi:416]:   IP Address: 192.168.178.121
[21:11:23][C][wifi:420]:   BSSID: [redacted]
[21:11:23][C][wifi:421]:   Hostname: 'uarttest'
[21:11:23][C][wifi:423]:   Signal strength: -61 dB ▂▄▆█
[21:11:23][V][wifi:425]:   Priority: 0.0
[21:11:23][C][wifi:427]:   Channel: 6
[21:11:23][C][wifi:428]:   Subnet: 255.255.255.0
[21:11:23][C][wifi:429]:   Gateway: 192.168.178.1
[21:11:23][C][wifi:430]:   DNS1: 213.46.228.196
[21:11:23][C][wifi:431]:   DNS2: 62.179.104.196
[21:11:23][C][logger:166]: Logger:
[21:11:23][C][logger:167]:   Level: VERY_VERBOSE
[21:11:23][C][logger:169]:   Log Baud Rate: 0
[21:11:23][C][logger:170]:   Hardware UART: USB_CDC
[21:11:23][C][uart.arduino_esp32:137]: UART Bus 0:
[21:11:23][C][uart.arduino_esp32:139]:   RX Pin: GPIO20
[21:11:23][C][uart.arduino_esp32:141]:   RX Buffer Size: 256
[21:11:23][C][uart.arduino_esp32:143]:   Baud Rate: 9600 baud
[21:11:23][C][uart.arduino_esp32:144]:   Data Bits: 8
[21:11:23][C][uart.arduino_esp32:145]:   Parity: NONE
[21:11:23][C][uart.arduino_esp32:146]:   Stop bits: 1
[21:11:23][C][modbus:143]: Modbus:
[21:11:23][C][modbus:145]:   Send Wait Time: 250 ms
[21:11:23][C][modbus:146]:   CRC Disabled: NO
[21:11:23][C][modbus_controller:298]: ModbusController:
[21:11:23][C][modbus_controller:299]:   Address: 0x01
[21:11:23][C][modbus_controller:301]: sensormap
[21:11:23][C][modbus_controller:305]:  Sensor type=3 start=0x1 offset=0x0 count=1 size=2
[21:11:23][C][modbus_controller:307]: ranges
[21:11:23][C][modbus_controller:310]:   Range type=3 start=0x1 count=1 skip_updates=0
[21:11:23][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Heat Pump Return Water Temperature'
[21:11:23][C][modbus_controller.sensor:010]: modbus_controller.sensor  State Class: ''
[21:11:23][C][modbus_controller.sensor:010]: modbus_controller.sensor  Unit of Measurement: '°C'
[21:11:23][C][modbus_controller.sensor:010]: modbus_controller.sensor  Accuracy Decimals: 0
[21:11:23][C][mdns:115]: mDNS:
[21:11:23][C][mdns:116]:   Hostname: uarttest
[21:11:23][V][mdns:117]:   Services:
[21:11:23][V][mdns:119]:   - _esphomelib, _tcp, 6053
[21:11:23][V][mdns:121]:     TXT: version = 2024.4.0
[21:11:23][V][mdns:121]:     TXT: mac = dcda0cc56e98
[21:11:23][V][mdns:121]:     TXT: platform = ESP32
[21:11:23][V][mdns:121]:     TXT: board = esp32-c3-devkitm-1
[21:11:23][V][mdns:121]:     TXT: network = wifi
[21:11:23][V][mdns:121]:     TXT: api_encryption = Noise_NNpsk0_25519_ChaChaPoly_SHA256
[21:11:23][C][ota:096]: Over-The-Air Updates:
[21:11:23][C][ota:097]:   Address: uarttest.local:3232
[21:11:23][C][ota:100]:   Using Password.
[21:11:23][C][ota:103]:   OTA version: 2.
[21:11:23][C][api:139]: API Server:
[21:11:23][C][api:140]:   Address: uarttest.local:6053
[21:11:23][C][api:142]:   Using noise encryption: YES
[21:11:24][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:11:24][V][modbus:042]: Modbus received Byte  144 (0X90)
[21:11:24][V][modbus:042]: Modbus received Byte  209 (0Xd1)
[21:11:24][V][modbus:042]: Modbus received Byte  144 (0X90)
[21:11:24][V][modbus:042]: Modbus received Byte  221 (0Xdd)
[21:11:24][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:11:24][W][modbus:108]: Modbus CRC Check failed! D12D!=14DD
[21:11:24][V][modbus:042]: Modbus received Byte  224 (0Xe0)
[21:11:24][V][modbus:042]: Modbus received Byte  246 (0Xf6)
[21:11:24][V][modbus:042]: Modbus received Byte  31 (0X1f)
[21:11:24][V][modbus:042]: Modbus received Byte  255 (0Xff)
[21:11:24][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:11:24][W][modbus:108]: Modbus CRC Check failed! 5E76!=14FF
[21:11:24][V][modbus:042]: Modbus received Byte  100 (0X64)
[21:11:24][V][modbus:042]: Modbus received Byte  250 (0Xfa)
[21:11:24][V][modbus:042]: Modbus received Byte  255 (0Xff)
[21:11:24][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:11:24][V][modbus:042]: Modbus received Byte  65 (0X41)
[21:11:24][W][modbus:108]: Modbus CRC Check failed! FF32!=4114
[21:11:24][V][modbus:042]: Modbus received Byte  194 (0Xc2)
[21:11:24][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:11:24][V][modbus:042]: Modbus received Byte  205 (0Xcd)
[21:11:24][V][modbus:042]: Modbus received Byte  250 (0Xfa)
[21:11:24][V][modbus:042]: Modbus received Byte  144 (0X90)
[21:11:24][V][modbus:042]: Modbus received Byte  255 (0Xff)
[21:11:24][W][modbus:108]: Modbus CRC Check failed! 17E5!=FF90
[21:11:24][D][uart_debug:114]: <<< 14:90:D1:90:DD:14:E0:F6:1F:FF:14:64:FA:FF:14:41:C2:14:CD:FA:90:FF

[TeslaNerd]

en met stopbits op 2 ipv ziet het er zo uit:

code:

INFO ESPHome 2024.4.0
INFO Reading configuration /config/esphome/modbus.yaml...
INFO Starting log output from 192.168.178.121 using esphome API
INFO Successfully connected to uarttest @ 192.168.178.121 in 0.065s
INFO Successful handshake with uarttest @ 192.168.178.121 in 0.078s
[21:14:52][I][app:100]: ESPHome version 2024.4.0 compiled on Apr 21 2024, 21:13:43
[21:14:52][C][wifi:580]: WiFi:
[21:14:52][C][wifi:408]:   Local MAC: DC:DA:0C:C5:6E:98
[21:14:52][C][wifi:413]:   SSID: [redacted]
[21:14:52][C][wifi:416]:   IP Address: 192.168.178.121
[21:14:52][C][wifi:420]:   BSSID: [redacted]
[21:14:52][C][wifi:421]:   Hostname: 'uarttest'
[21:14:52][C][wifi:423]:   Signal strength: -61 dB ▂▄▆█
[21:14:52][V][wifi:425]:   Priority: 0.0
[21:14:52][C][wifi:427]:   Channel: 6
[21:14:52][C][wifi:428]:   Subnet: 255.255.255.0
[21:14:52][C][wifi:429]:   Gateway: 192.168.178.1
[21:14:52][C][wifi:430]:   DNS1: 213.46.228.196
[21:14:52][C][wifi:431]:   DNS2: 62.179.104.196
[21:14:52][C][logger:166]: Logger:
[21:14:52][C][logger:167]:   Level: VERY_VERBOSE
[21:14:52][C][logger:169]:   Log Baud Rate: 0
[21:14:52][C][logger:170]:   Hardware UART: USB_CDC
[21:14:52][C][uart.arduino_esp32:137]: UART Bus 0:
[21:14:52][C][uart.arduino_esp32:139]:   RX Pin: GPIO20
[21:14:52][C][uart.arduino_esp32:141]:   RX Buffer Size: 256
[21:14:52][C][uart.arduino_esp32:143]:   Baud Rate: 9600 baud
[21:14:52][C][uart.arduino_esp32:144]:   Data Bits: 8
[21:14:52][C][uart.arduino_esp32:145]:   Parity: NONE
[21:14:52][C][uart.arduino_esp32:146]:   Stop bits: 2
[21:14:52][C][modbus:143]: Modbus:
[21:14:52][C][modbus:145]:   Send Wait Time: 250 ms
[21:14:52][C][modbus:146]:   CRC Disabled: NO
[21:14:52][C][modbus_controller:298]: ModbusController:
[21:14:52][C][modbus_controller:299]:   Address: 0x01
[21:14:52][C][modbus_controller:301]: sensormap
[21:14:52][C][modbus_controller:305]:  Sensor type=3 start=0x1 offset=0x0 count=1 size=2
[21:14:52][C][modbus_controller:307]: ranges
[21:14:52][C][modbus_controller:310]:   Range type=3 start=0x1 count=1 skip_updates=0
[21:14:52][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Heat Pump Return Water Temperature'
[21:14:52][C][modbus_controller.sensor:010]: modbus_controller.sensor  State Class: ''
[21:14:52][C][modbus_controller.sensor:010]: modbus_controller.sensor  Unit of Measurement: '°C'
[21:14:52][C][modbus_controller.sensor:010]: modbus_controller.sensor  Accuracy Decimals: 0
[21:14:52][C][mdns:115]: mDNS:
[21:14:52][C][mdns:116]:   Hostname: uarttest
[21:14:52][V][mdns:117]:   Services:
[21:14:52][V][mdns:119]:   - _esphomelib, _tcp, 6053
[21:14:52][V][mdns:121]:     TXT: version = 2024.4.0
[21:14:52][V][mdns:121]:     TXT: mac = dcda0cc56e98
[21:14:52][V][mdns:121]:     TXT: platform = ESP32
[21:14:52][V][mdns:121]:     TXT: board = esp32-c3-devkitm-1
[21:14:52][V][mdns:121]:     TXT: network = wifi
[21:14:52][V][mdns:121]:     TXT: api_encryption = Noise_NNpsk0_25519_ChaChaPoly_SHA256
[21:14:52][C][ota:096]: Over-The-Air Updates:
[21:14:52][C][ota:097]:   Address: uarttest.local:3232
[21:14:52][C][ota:100]:   Using Password.
[21:14:52][C][ota:103]:   OTA version: 2.
[21:14:52][C][api:139]: API Server:
[21:14:52][C][api:140]:   Address: uarttest.local:6053
[21:14:52][C][api:142]:   Using noise encryption: YES
[21:14:53][V][modbus:042]: Modbus received Byte  160 (0Xa0)
[21:14:53][V][modbus:042]: Modbus received Byte  240 (0Xf0)
[21:14:53][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:14:53][V][modbus:042]: Modbus received Byte  224 (0Xe0)
[21:14:53][V][modbus:042]: Modbus received Byte  246 (0Xf6)
[21:14:53][V][modbus:042]: Modbus received Byte  31 (0X1f)
[21:14:53][V][modbus:042]: Modbus received Byte  255 (0Xff)
[21:14:53][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:14:53][V][modbus:042]: Modbus received Byte  100 (0X64)
[21:14:53][V][modbus:042]: Modbus received Byte  250 (0Xfa)
[21:14:53][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:14:53][V][modbus:042]: Modbus received Byte  254 (0Xfe)
[21:14:53][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:14:53][V][modbus:042]: Modbus received Byte  39 (0X27)
[21:14:53][V][modbus:042]: Modbus received Byte  144 (0X90)
[21:14:53][D][uart_debug:114]: <<< A0:F0:14:E0:F6:1F:FF:14:64:FA:14:FE:14:27:90
[21:14:54][V][modbus:042]: Modbus received Byte  160 (0Xa0)
[21:14:54][V][modbus:042]: Modbus received Byte  243 (0Xf3)
[21:14:54][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:14:54][V][modbus:042]: Modbus received Byte  224 (0Xe0)
[21:14:54][V][modbus:042]: Modbus received Byte  246 (0Xf6)
[21:14:54][V][modbus:042]: Modbus received Byte  31 (0X1f)
[21:14:54][V][modbus:042]: Modbus received Byte  255 (0Xff)
[21:14:54][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:14:54][V][modbus:042]: Modbus received Byte  100 (0X64)
[21:14:54][V][modbus:042]: Modbus received Byte  250 (0Xfa)
[21:14:54][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:14:54][V][modbus:042]: Modbus received Byte  254 (0Xfe)
[21:14:54][V][modbus:042]: Modbus received Byte  20 (0X14)
[21:14:54][V][modbus:042]: Modbus received Byte  39 (0X27)
[21:14:54][V][modbus:042]: Modbus received Byte  144 (0X90)
[21:14:54][D][uart_debug:114]: <<< A0:F3:14:E0:F6:1F:FF:14:64:FA:14:FE:14:27:90

[Freeckje]

Komen onderstaande records rechtstreeks uit je modbus module of de modbusparser of HA?

"[C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sen......"

...modbus_controller.sensorModbus Controller Sensor 'Heat Pump Return Water....

21:14:52][C][modbus_controller:299]: Address: 0x01
[21:14:52][C][modbus_controller:301]: sensormap

De records met "Bytes" die er onder staan, zijn zo te zien geen leesbare ascii-codes maar binaire codes. Ascii loopt normaal van 0 tot 127, ik zie veel codes die hoger waarden aannemen.

PS: ik zie ook veel storende esp32 debug messages voorbijkomen. Kan je niet zelf een esp32 programmaatje downloaden?

[ Voor 16% gewijzigd door Freeckje op 21-04-2024 22:02 ]

[TeslaNerd]

Freeckje schreef op zondag 21 april 2024 @ 21:50:
Komen onderstaande records rechtstreeks uit je modbus module of de modbusparser of HA?

[...]


De records met "Bytes" die er onder staan, zijn zo te zien geen leesbare ascii-codes maar binaire codes. Ascii loopt normaal van 0 tot 127, ik zie veel codes die hoger waarden aannemen.

PS: ik zie ook veel storende esp32 debug messages voorbijkomen. Kan je niet zelf een esp32 programmaatje downloaden?

Dat kan natuurlijk ook maar ik heb geen idee met welk esp32 progje ik dan moet starten. Uiteindelijk wil ik de Modbus waarden in HA kunnen gebruiken. Daarom deze poging met ESPHome direct in HA de Quatt modbus te ontcijferen

[Freeckje]

..

[ Voor 108% gewijzigd door Freeckje op 22-04-2024 15:38 ]

[Freeckje]

Top dat je die spec gevonden hebt!
https://gathering.tweaker...message/78786392#78786392
Ondertussen heb in een laatje een losse RS485 adapter gevonden die ik aan een esp32 kan interfacen. Als ik zin en tijd heb, en jij loopt vast, dan ga ik ook een poging wagen de Quatt communicatie af te luisteren.
En nu maar hopen dat de firmware van de Quatt, qua modbus-registers, overeenkomt met die spec.

[ Voor 15% gewijzigd door Freeckje op 22-04-2024 15:39 ]

[TeslaNerd]

Freeckje schreef op maandag 22 april 2024 @ 15:25:
Top dat je die spec gevonden hebt!
https://gathering.tweaker...message/78786392#78786392
Ondertussen heb in een laatje een losse RS485 adapter gevonden die ik aan een esp32 kan interfacen. Als ik zin en tijd heb, en jij loopt vast, dan ga ik ook een poging wagen de Quatt communicatie af te luisteren.
En nu maar hopen dat de firmware van de Quatt, qua modbus-registers, overeenkomt met die spec.

En ik heb toch maar zo een logic analyzer besteld bij Amazon

[0xygen500]

@TeslaNerd leuk project! Gaat mij de pet de boven, maar leuk dat je het uitvogelt.

[TeslaNerd]

Freeckje schreef op maandag 22 april 2024 @ 15:25:
Top dat je die spec gevonden hebt!
https://gathering.tweaker...message/78786392#78786392
Ondertussen heb in een laatje een losse RS485 adapter gevonden die ik aan een esp32 kan interfacen. Als ik zin en tijd heb, en jij loopt vast, dan ga ik ook een poging wagen de Quatt communicatie af te luisteren.
En nu maar hopen dat de firmware van de Quatt, qua modbus-registers, overeenkomt met die spec.

Zet de communicatie op 19200 als jij de Quatt communicatie gaat luisteren.

Dat heb ik samen met Sieb van de ESPHome Discord gisteravond uitgevonden door via de Remote Receiver functie van ESPHome het electrische signaal te bekijken op de RX pin.

Die liet zien dat de start bit er 52us over doet, ergo 19200 baud

code:

[00:49:41][VV][remote_receiver.esp32:092]: START:
[00:49:41][VV][remote_receiver.esp32:099]: 0 A: OFF 52us (52 ticks)

https://discord.com/chann...24364/1232080954466631761

Ik heb de communicatie parameters nu op 19200-8-E-1 staan

[TeslaNerd]

En nog een modbus topic voor ESPHome aangemaakt in Discord:

ESPHome tools for reverse engineering modbus register definitions

https://discord.com/chann...24364/1232233910688284683

[ Voor 21% gewijzigd door TeslaNerd op 23-04-2024 12:05 ]

[Flesym]

Flesym schreef op donderdag 28 maart 2024 @ 22:49:
[...]

Bedankt, inderdaad onlogische naam. Maar probleem is hiermee niet opgelost. Het lijkt erop dat Google Home via Smart Life gewoon beide huizen aanleert. Dus Google Home bedient nog steeds alle Smart WCD's in beide huizen en alles uit is dus nog steeds alles.
En in HA zijn de Smart WCD's inderdaad niet meer zichtbaar. Dus dit werkt dus precies verkeerd om.

Dit probleem eindelijk opgelost.
Local Tuya werkte niet omdat Tuya tegenwoordig een key heeft toegevoegd die iedere maand moet worden vernieuwd.
Maar er zijn gelukkig 2 HA-integraties, 1x Tuya en 1x SmartLife. Dus 2 SmartLife accounts gemaakt (1 met Google Home koppeling) en ieder account aan een eigen HA-integratie gekoppeld. Dat werkt goed.

[Flesym]

Flesym schreef op zondag 7 april 2024 @ 19:28:
[...]


Dank je, ik ga me inlezen en indien ik het een beetje begrijp mee beginnen, wordt een leuk voorjaarsproject.

Mijn DIYLESS staat al 2 weken in bestelling en via Track-and-trace na Warschau (15 april) niet meer te vinden dus waarschijnlijk zoekgeraakt in de post , grrrr. Is er net zo'n lekker weer voor.

[TeslaNerd]

Ik heb de logic analyzer binnen en heb een sample gemaakt van de quatt modbus op de AGB contacten van de CiC. Ik heb er zelf geen verstand van maar hoor graag van de logische analysten hier of dit een goede sample is en wat hier in te zien is

Gemaakt met de Saleae Logic v1.2.40

https://www.dropbox.com/s...8fpf4xihdcnqbec959mu&dl=0

https://www.dropbox.com/s...gr7q2ljj53r9fvpyb1fd&dl=0

[ Voor 40% gewijzigd door TeslaNerd op 23-04-2024 19:02 ]

[TeslaNerd]

En ook een update van het modbus in HA project. Met de input van het ESPHome Discord team ziet mijn yaml voor ESPHome in HA er nu zo uit. Hiermee heeft mijn HA toegang tot 44 modbus registers van de Quatt: 1999, 2010, 2015, 2999 t/m 3039 en 3099.

Wat deze registers doen en wat de waarden betekenen in deze registers is voor mij nog een raadsel.
Maar het is een begin

de logfile met de modbus data

https://www.dropbox.com/s...ppkkzwacryie7amc75ye&dl=0

code:

esphome:
  name: uarttest

esp32:
  board: esp32-c3-devkitm-1
  framework:
    type: arduino

# Enable Home Assistant API
api:
  encryption:
    key: " xxx "

ota:
  password: " xxx "

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Enable logging
logger:
  baud_rate: 0                         ## Igor Ybema: make sure to turn of logging via UART (set baudrate to 0) as the RS485 uses the onboard UART (tx/rx)
  level: DEBUG
  logs:
    uart_debug: DEBUG                  ## toon uart_debug data wel
    modbus: ERROR                      ## onderdruk log-berichten van modbus
    modbus_controller.sensor: ERROR    ## onderdruk log-berichten van modbus_controller

# Configuratie van UART op Quatt modbus connectie-parameters
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

# Configuratie modbus in ESPHome
modbus:
  uart_id: uart_bus
  id: mod_bus

# Configuratie modbus_controller voor wegschrijven Quatt modbus-data uit uart naar HA-sensoren
modbus_controller:
- id: modbus_device
  address: 1              ## address of the Modbus slave device on the bus
  modbus_id: mod_bus
  update_interval: 10s     ## schrijf iedere 10 seconden de modbus-data uit de uart weg naar de sensoren hieronder

sensor:
# lees 40 keer met modbus-functie 0x03 (3) - Read Holding Registers uit de Quatt-modbus registers: 2999 tot en met 3039    
  - platform: modbus_controller
    name: "Modbus 2099"
    register_type: holding
    address: 2099
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3000"
    register_type: holding
    address: 3000
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3001"
    register_type: holding
    address: 3001
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3002"
    register_type: holding
    address: 3002
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3003"
    register_type: holding
    address: 3003
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3004"
    register_type: holding
    address: 3004
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3005"
    register_type: holding
    address: 3005
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3006"
    register_type: holding
    address: 3006
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3007"
    register_type: holding
    address: 3007
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3008"
    register_type: holding
    address: 3008
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3009"
    register_type: holding
    address: 3009
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3010"
    register_type: holding
    address: 3010
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3011"
    register_type: holding
    address: 3011
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3012"
    register_type: holding
    address: 3012
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3013"
    register_type: holding
    address: 3013
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3014"
    register_type: holding
    address: 3014
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3015"
    register_type: holding
    address: 3015
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3016"
    register_type: holding
    address: 3016
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3017"
    register_type: holding
    address: 3017
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3018"
    register_type: holding
    address: 3018
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3019"
    register_type: holding
    address: 3019
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3020"
    register_type: holding
    address: 3020
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3021"
    register_type: holding
    address: 3021
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3022"
    register_type: holding
    address: 3022
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3023"
    register_type: holding
    address: 3023
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3024"
    register_type: holding
    address: 3024
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3025"
    register_type: holding
    address: 3025
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3026"
    register_type: holding
    address: 3026
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3027"
    register_type: holding
    address: 3027
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3028"
    register_type: holding
    address: 3028
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3029"
    register_type: holding
    address: 3029
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3030"
    register_type: holding
    address: 3030
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3031"
    register_type: holding
    address: 3031
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3032"
    register_type: holding
    address: 3032
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3033"
    register_type: holding
    address: 3033
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3034"
    register_type: holding
    address: 3034
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3035"
    register_type: holding
    address: 3035
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3036"
    register_type: holding
    address: 3036
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3037"
    register_type: holding
    address: 3037
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 3038"
    register_type: holding
    address: 3038
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000                                                                                                                                                               
  - platform: modbus_controller
    name: "Modbus 3039"
    register_type: holding
    address: 3039
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000

  # lees vier keer met modbus-functie 0x06 (6) - Write Single Register uit de Quatt-modbus registers: 1999, 2010, 2015 en 3999    
  - platform: modbus_controller
    name: "Modbus 1999"
    register_type: read
    address: 1999
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000  
  - platform: modbus_controller
    name: "Modbus 2010"
    register_type: read
    address: 2010
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000
  - platform: modbus_controller
    name: "Modbus 2015"
    register_type: read
    address: 2015
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000   
  - platform: modbus_controller
    name: "Modbus 3999"
    register_type: read
    address: 3999
    value_type: U_WORD
    modbus_controller_id: modbus_device
    unit_of_measurement: UoM_onbekend
    filters:
      multiply: 1.000000

[ Voor 201% gewijzigd door TeslaNerd op 02-05-2024 15:51 ]

[Freeckje]

TeslaNerd schreef op dinsdag 23 april 2024 @ 19:07:
En ook een update van het modbus in HA project. Met de input van het ESPHome Discord team ziet mijn yaml voor ESPHome in HA er nu zo uit. Hiermee heeft mijn HA toegang tot 40 modbus registers van de Quatt: 1999, 2010, 2015, 2999 t/m 2039 en 3099.

Wat deze registers doen en wat de waarden betekenen in deze registers is voor mij nog een raadsel.
Maar het is in ieder geval een begin

Gaat de goede kant op!
Komen die registers dan niet overeen met die spec van die print die je laatst gevonden had?

[TeslaNerd]

Freeckje schreef op dinsdag 23 april 2024 @ 19:12:
[...]

Gaat de goede kant op!
Komen die registers dan niet overeen met die spec van die print die je laatst gevonden had?

nee, helemaal niet. Die heb ik alleen nog bewaard voor de lijst met mogelijk modbus functies

Wel leuk om te te zien dat de hele code bestaat uit deze yaml en HA en ESPHome verder alles voor je doen.

[ Voor 26% gewijzigd door TeslaNerd op 23-04-2024 19:28 ]

[TeslaNerd]

Freeckje schreef op woensdag 24 april 2024 @ 21:43:
[...]

Dat antwoord kreeg ik tijdens de demo avond in Amsterdam.

Heb jij de analyser data , die je op dropbox hebt gezet, nog kunnen decoderen met het programma behorende bij je analyzer?
Ik nog niet, want het dataformat hoort bij de oude versie van hun software.

Ja, ik heb die data inderdaad met de oude versie gemaakt, v1.2.40. Die versie is ook te downloaden van de website

https://support.saleae.co...e/older-software-releases

[ Voor 33% gewijzigd door TeslaNerd op 24-04-2024 22:00 ]

[Freeckje]

TeslaNerd schreef op woensdag 24 april 2024 @ 22:00:
[...]

Ja, ik heb die data inderdaad met de oude versie gemaakt, v1.2.40. Die versie is ook te downloaden van de website

https://support.saleae.co...e/older-software-releases

Maar als ik dat programma opstart zie ik geen optie om die datafile te openen

[TeslaNerd]

Freeckje schreef op woensdag 24 april 2024 @ 22:02:
[...]

Maar als ik dat programma opstart zie ik geen optie om die datafile te openen

ik ga zelf even kijken. Ik heb dat programma ook maar 1 keer gebruikt

In het menu met Options (rechts boven in beeld) is bij mij (Windows) de eerste optie: Open capture / setup
Daar kan ik het bestand .logicdata en de settings-file opnieuw openen

[ Voor 25% gewijzigd door TeslaNerd op 25-04-2024 09:41 ]

[TeslaNerd]

Freeckje schreef op zaterdag 13 april 2024 @ 12:59:
[...]

Momenteel ben ik bezig een (vrij simpel) algoritme te ontwikkelen die dat aan- en uitschakelen onderdrukt.
Er zit in de regeling van de CiC m.i. een fundamentele fout: de CiC regelt obv de aanvoertemperatuur en niet op de retour temperatuur!! Maw als de wp inschakelt zal na een paar minuten het setpoint bereikt worden en schakelt de CiC de wp af, en kort daarna weer aan. Hij pendelt als een gek, wel 6 a 7 keer per uur, ook al mag dat off the record van Quatt, mij staat het niet aan. Het bereiken van het setpoint wordt daarmee ook onnodig vertraagd. Quatt gebruikt geen buffervat en adverteren daar ook mee. Maar ondertussen maken ze geen gebruik van de bufferwerking van de CV-installatie, en laten de wp onnodig pendelen. Hopelijk heb ik de regelaar van het weekend gereed en laat de resultaten zien.

Nu jij op besturing op watertemperatuur bent overgezet door Quatt support, zie jij dan de kamertemperatuur nog doorkomen in de Quatt app?

[Freeckje]

TeslaNerd schreef op vrijdag 26 april 2024 @ 14:10:
[...]

Nu jij op besturing op watertemperatuur bent overgezet door Quatt support, zie jij dan de kamertemperatuur nog doorkomen in de Quatt app?

Nee, die lees ik nu zelf uit via de sensor op de OT-module. Zodra Quatt een kamersetpoint ziet doorkomen dan schakelen ze me mogelijk weer op kamersetpoint-aansturing...
Alle OT-variabelen en temp-sensor, worden via MQTT beschikbaar gesteld voor andere apps zoals HomeAssistant of Nodered, naar believen. Daarnaast het watersetpoint als input.
Was nog wel van plan mijn oude TS te koppelen aan de esp8266-module zodat ik de timerfunctie, het kamersetpoint en het display kan hergebruiken.

[ Voor 11% gewijzigd door Freeckje op 26-04-2024 14:23 ]

[Flesym]

@TeslaNerd ik heb de DIYLESS inmiddels binnen. Toen bij jou de Quatt nog op room temperatuursturing stond, heb jij toen nog gespeeld met P en I om een optimale waarde te vinden (en wat waren die voor jou)?
De standaardwaarden(gebaseerd op setpoint sturing en CV verwarming) werken slecht omdat de DIYLESS steeds afschakelt (dus heel veel pendelen) en de kamer pas op temperatuur komt als de CV bijschakelt. Ik heb hem nu op P=3 en I=0,1 gezet wat een stuk beter werkt maar begrenst de Quatt aan de bovenkant helemaal niet wat bij dit warmere weer wel zou mogen.
Zie ook screenshots. Het zou mooi zijn als ik met wat input snel naar optimale waardes kan nu het koude weer bijna over is.

[ Voor 4% gewijzigd door Flesym op 27-04-2024 17:42 ]

[Flesym]

@TeslaNerd , nog even een vraagje als het mag. Standaard meet de DIYLESS op 0,1 maar instellingen werken op 0,5⁰C. Kun je hem softwarematig wel instellen op 0,1⁰C?. Ik gebruik namelijk 0,5⁰C verhoging in de avond en wil deze aan het eind van de avond eigenlijk geleidelijk in stapjes van 0,1⁰C afbouwen. Bij 0,5⁰C stopt namelijk de Quatt een tijdje met een undershoot en extra vermogen om dit weer te corrigeren.

[TeslaNerd]

Flesym schreef op zaterdag 27 april 2024 @ 17:57:
@TeslaNerd , nog even een vraagje als het mag. Standaard met de DIYLESS op 0,1 maar instellingen werken op 0,5⁰C. Kun je hem softwarematig wel instellen op 0,1⁰C?. Ik gebruik namelijk 0,5⁰C verhoging in de avond en wil deze aan het eind van de avond eigenlijk geleidelijk in stapjes van 0,1⁰C afbouwen. Bij 0,5⁰C stopt namelijk de Quatt een tijdje met een undershoot en extra vermogen om dit weer te corrigeren.

Dat had ik met de Honeywell Round Modulation ook (ik heb de DIYLESS wel overwogen maar bij de Honeywell gebleven icm een OTGateway) en ben daarom overgegaan naar een HA automation die iedere minuut checkt wat de opwarm-/afkoelsnelheid van mijn huis doet. Als de opwarmsnelheid (nadat de Quatt is gestopt) langer dan 10 minuten onder de 0,3 graden Celsius per uur blijft dan zet HA de thermostaat 0,75 graden boven de huidige kamertemperatuur en een halve minuut later weer een halve graad omlaag. Dat is het opwarmschema.
Als het huis warmer is dan de gewenste temperatuur plus 0,05 graden dan hanteer ik het warmhoudenschema. Dat werkt hetzelfde maar dan aan als langer dan 10 minuten onder de 0 graden per uur opwarmsnelheid en dan zet HA de thermostaat de eerste halve minuut niet 0,75 maar 0,5 graden omhoog en daarna weer 0,5 omlaag.
Dat zijn waarden die goed werken bij de opwarmsnelheid en het warmteverlies van mijn huis en iets anders kunnen zijn voor een ander huis. Maar itt tot de Quatt app heb je dan wel knoppen waar je aan kan draaien als dat nodig is.
Ik heb door Quatt het voor de CiC in te stellen warmteverlies wel zo laag mogelijk laten zetten. Als dat in de praktijk te laag is dan zet ik met HA de thermostaat gewoon hoger boven de huidige temperatuur en dan laat de CiC ook meer warmte produceren.
Aan de bovenkant laat ik HA de thermostaat een hele graad omlaag zetten als de waterIN temperatuur hoger wordt dan 40 minus de buitentemperatuur.
Ik geef HA daarmee een set eigen regels waarmee HA als een echte controlfreak iedere minuut mag beslissen of er aan de thermostaat moet worden gedraaid :-)

Zag er vandaag zo uit:

[ Voor 25% gewijzigd door TeslaNerd op 27-04-2024 20:52 ]

[Flesym]

TeslaNerd schreef op zaterdag 27 april 2024 @ 20:29:
[...]

Dat had ik met de Honeywell Round Modulation ook (ik heb de DIYLESS wel overwogen maar bij de Honeywell gebleven icm een OTGateway) en ben daarom overgegaan naar een HA automation die iedere minuut checkt wat de opwarm-/afkoelsnelheid van mijn huis doet. Als de opwarmsnelheid (nadat de Quatt is gestopt) langer dan 10 minuten onder de 0,3 graden Celsius per uur blijft dan zet HA de thermostaat 0,75 graden boven de huidige kamertemperatuur en een halve minuut later weer een halve graad omlaag. Dat is het opwarmschema.
Als het huis warmer is dan de gewenste temperatuur plus 0,05 graden dan hanteer ik het warmhoudenschema. Dat werkt hetzelfde maar dan aan als langer dan 10 minuten onder de 0 graden per uur opwarmsnelheid en dan zet HA de thermostaat de eerste halve minuut niet 0,75 maar 0,5 graden omhoog en daarna weer 0,5 omlaag.
Dat zijn waarden die goed werken bij de opwarmsnelheid en het warmteverlies van mijn huis en iets anders kunnen zijn voor een ander huis. Maar itt tot de Quatt app heb je dan wel knoppen waar je aan kan draaien als dat nodig is.
Ik heb door Quatt het voor de CiC in te stellen warmteverlies wel zo laag mogelijk laten zetten. Als dat in de praktijk te laag is dan zet ik met HA de thermostaat gewoon hoger boven de huidige temperatuur en dan laat de CiC ook meer warmte produceren.
Aan de bovenkant laat ik HA de thermostaat een hele graad omlaag zetten als de waterIN temperatuur hoger wordt dan 40 minus de buitentemperatuur.
Ik geef HA daarmee een set eigen regels waarmee HA als een echte controlfreak iedere minuut mag beslissen of er aan de thermostaat moet worden gedraaid :-)

Zag er vandaag zo uit:

[Afbeelding]

Bedankt voor het uitgebreide antwoord, het geeft mij weer meer inzicht. Omdat het stookseizoen over is wilde ik de Diyless in eerste instantie standaard gebruiken en van de zomer wat met programmeren gaan oefenen.
Vandaar dat ik op zoek ben naar standaard instellingservaringen van anderen. En teruglezend zie ik inderdaad dat jij de Diyless niet gebruikt maar o.a. JazekerXX. Maar nogmaals bedankt dat je me wilde helpen, gaat me zeker helpen.

[JazekerXX]

Flesym schreef op zaterdag 27 april 2024 @ 21:15:
[...]


Bedankt voor het uitgebreide antwoord, het geeft mij weer meer inzicht. Omdat het stookseizoen over is wilde ik de Diyless in eerste instantie standaard gebruiken en van de zomer wat met programmeren gaan oefenen.
Vandaar dat ik op zoek ben naar standaard instellingservaringen van anderen. En teruglezend zie ik inderdaad dat jij de Diyless niet gebruikt maar o.a. JazekerXX. Maar nogmaals bedankt dat je me wilde helpen, gaat me zeker helpen.

Ja klopt. Ik gebruik de Diyless. Deze werkt erg goed. Ik heb de arduino code gedeeld hier, dus die kun je er zo in knallen..

[m10tech]

Lasoul schreef op maandag 8 januari 2024 @ 13:33:
[...]

Ik mijn code staat een stuk voor OTA (Over The Air) updates. Als je dan in je eerste versie opneemt dan kun je via de Arduino IDE icm LAN/WiFi je boardje voorzien van nieuwe versies.

Je kunt DIYLess in principe op twee plekken in de keten zetten als je een Quatt hebt

1. Tussen T6 en CiC
2. Tussen CiC en CV

Als je hem tussen T6 en CiC zet dan kun je als het ware de OpenTherm commando's van de T6 overrulen en als je hem tussen de CiC en de CV zet dan kun je de CiC overrulen richting de CV.

Ik zou in de eerste versie gewoon alle OpenTherm berichten monitoren en tussen slave/master 1-op-1 overzetten en nog niet ingrijpen. Als dat werkt kun je hem redelijk "veilig" er tussen zetten. Als je dan verder bent dan kun je bijvoorbeeld een switch maken in Home Assistant die je functionaliteit in de Gateway aan of uit zet. Dus standaard doet hij alleen een copy van de berichten en als je de switch omzet dan grijpt hij ook in en past OpenTherm berichten aan of genereert zelf OpenTherm berichten.

Als je een eerste versie hebt dan zou je ook een GitHub repository kunnen aanmaken zodat meer personen er aan kunnen meehelpen.

Ik zit eigenlijk nog een stuk verder te denken...
Code schrijven die thermostaat is (dus alleen master OT), tevens ingrijpen tussen CIC en CV (dus master slave gateway) maar OOK ingrijpen in de lijn tussen CIC en Quatt.

Daarover zag ik nog niets geschreven, dus ik vroeg me af of dat al ergens wordt gedaan/beschreven.
Uit de JSON output screenshots verwacht ik dat hier MODBUS wordt gebruikt, en dat zou ook prima door een gateway gemanipuleerd kunnen worden.

Ik heb zat ervaring met dingen reverse engineeren en daarna alles te ontwerpen en bouwen, maar dit is een vraag over de strategie.
Als ik het goed heb dan zijn er maar 3 OT commandos uit de Quatt slave, roomSet, roomTemp en CHenable, wat natuurlijk schandalig weinig is. Of is dat achterstallige documentatie op de Quatt deel2 pagina?

Betekend dit dat we de CIC ook helemaal kunnen vervangen? Dat zou ook helemaal niet verkeerd zijn.

PS. Ik moet mijn Quatt nog wel aanschaffen, maar dat gaat niet lang meer duren...

[patrickvdhart]

Flesym schreef op zaterdag 27 april 2024 @ 17:31:
@TeslaNerd ik heb de DIYLESS inmiddels binnen. Toen bij jou de Quatt nog op room temperatuursturing stond, heb jij toen nog gespeeld met P en I om een optimale waarde te vinden (en wat waren die voor jou)?
De standaardwaarden(gebaseerd op setpoint sturing en CV verwarming) werken slecht omdat de DIYLESS steeds afschakelt (dus heel veel pendelen) en de kamer pas op temperatuur komt als de CV bijschakelt. Ik heb hem nu op P=3 en I=0,1 gezet wat een stuk beter werkt maar begrenst de Quatt aan de bovenkant helemaal niet wat bij dit warmere weer wel zou mogen.
Zie ook screenshots. Het zou mooi zijn als ik met wat input snel naar optimale waardes kan nu het koude weer bijna over is.
[Afbeelding]

[Afbeelding]

Het viel me op dat je voor I 0.1 gekozen hebt. De meeste systemen is de eenheid van de I (integral time) in minuten. 0.1 Minuut is razendsnel en veel te snel typisch voor een verwarming systeem, meer iets hoe je een flow regelt. Ik zou die in orde grootte uren verwachten, dus meer richting 60. Maar is een samenspel met de P.
Jammer dat ik na mijn solderen en eeste test, nog steeds niet de DIYless heb aangesloten op de Quatt, anders zou ik met je meespelen. Maar has prio aan mijn radiator fans regeling gegeven..

[Freeckje]

m10tech schreef op zondag 28 april 2024 @ 17:18:
[...]


Ik zit eigenlijk nog een stuk verder te denken...
Code schrijven die thermostaat is (dus alleen master OT), tevens ingrijpen tussen CIC en CV (dus master slave gateway) maar OOK ingrijpen in de lijn tussen CIC en Quatt.

Daarover zag ik nog niets geschreven, dus ik vroeg me af of dat al ergens wordt gedaan/beschreven.
Uit de JSON output screenshots verwacht ik dat hier MODBUS wordt gebruikt, en dat zou ook prima door een gateway gemanipuleerd kunnen worden.

Ik heb zat ervaring met dingen reverse engineeren en daarna alles te ontwerpen en bouwen, maar dit is een vraag over de strategie.
Als ik het goed heb dan zijn er maar 3 OT commandos uit de Quatt slave, roomSet, roomTemp en CHenable, wat natuurlijk schandalig weinig is. Of is dat achterstallige documentatie op de Quatt deel2 pagina?

Betekend dit dat we de CIC ook helemaal kunnen vervangen? Dat zou ook helemaal niet verkeerd zijn.

PS. Ik moet mijn Quatt nog wel aanschaffen, maar dat gaat niet lang meer duren...

Daar is al meerdere keren iets over geschreven: zoek oa op "modbus"

[JazekerXX]

m10tech schreef op zondag 28 april 2024 @ 17:18:
[...]


Ik zit eigenlijk nog een stuk verder te denken...
Code schrijven die thermostaat is (dus alleen master OT), tevens ingrijpen tussen CIC en CV (dus master slave gateway) maar OOK ingrijpen in de lijn tussen CIC en Quatt.

Daarover zag ik nog niets geschreven, dus ik vroeg me af of dat al ergens wordt gedaan/beschreven.
Uit de JSON output screenshots verwacht ik dat hier MODBUS wordt gebruikt, en dat zou ook prima door een gateway gemanipuleerd kunnen worden.

Ik heb zat ervaring met dingen reverse engineeren en daarna alles te ontwerpen en bouwen, maar dit is een vraag over de strategie.
Als ik het goed heb dan zijn er maar 3 OT commandos uit de Quatt slave, roomSet, roomTemp en CHenable, wat natuurlijk schandalig weinig is. Of is dat achterstallige documentatie op de Quatt deel2 pagina?

Betekend dit dat we de CIC ook helemaal kunnen vervangen? Dat zou ook helemaal niet verkeerd zijn.

PS. Ik moet mijn Quatt nog wel aanschaffen, maar dat gaat niet lang meer duren...

geen idee waarom je dat zou willen maar het kan wel natuurlijk.

ik gebruik de diyless als thermostaat, dus geen andere thermostaat dan de diyless.
deze dus: https://diyless.com/product/master-opentherm-shield
simpel gezegd is dit shield de master en de ketel of cic is de slave.

dus idd zoals je zelf al aangaf kun je met een gateway tussen de master en slave in gaan zitten en de data door laten of veranderen voordat je het doorstuurt.
dan heb je deze nodig: https://diyless.com/product/esp8266-opentherm-gateway
of 2 dan als je zowel tussen CIC en Quatt / CIC en CV wil.

maar of het dan ook lekker gaat werken weet ik niet...

ik vind dat de sturing van Quatt redelijk goed werkt, alleen vind ik dat hij soms te ver onder de setpoint gaat maar dat is simpel op te lossen door een automation te maken.

je moet het zelf weten natuurlijk maar ik zou het eerst eens gewoon proberen en kijken hoe het gaat. ik had ook allerlei wilde plannen maar vond het achteraf allemaal niet nodig.

[JazekerXX]

patrickvdhart schreef op maandag 29 april 2024 @ 09:11:
[...]


Het viel me op dat je voor I 0.1 gekozen hebt. De meeste systemen is de eenheid van de I (integral time) in minuten. 0.1 Minuut is razendsnel en veel te snel typisch voor een verwarming systeem, meer iets hoe je een flow regelt. Ik zou die in orde grootte uren verwachten, dus meer richting 60. Maar is een samenspel met de P.
Jammer dat ik na mijn solderen en eeste test, nog steeds niet de DIYless heb aangesloten op de Quatt, anders zou ik met je meespelen. Maar has prio aan mijn radiator fans regeling gegeven..

de P, I en D waardes zijn niet in tijd.

[Freeckje]

Even reclame maken voor mijn regelaar
https://gathering.tweaker...message/78824982#78824982
Als reactie op bovenstaande discussie:
Persoonlijk geloof ik niet (meer) in een PID-regelaar. Tegenwoordig worden zelflerende (PID-)regelaars toegepast of fuzzy regelaars.
Echter als je een vvw hebt is een konstante toevoer van warmte om je transmissieverliezen te compenseren belangrijker dan het continue proberen te stabiliseren van de kamertemp.
Maar ieder zijn voorkeur hoor

[Flesym]

JazekerXX schreef op zondag 28 april 2024 @ 16:24:
[...]


Ja klopt. Ik gebruik de Diyless. Deze werkt erg goed. Ik heb de arduino code gedeeld hier, dus die kun je er zo in knallen.

Thanks, ik had hem inderdaad teruggevonden en ga ermee aan de slag. Wordt wel flink inlezen op 'ontwikkelomgeving opzetten en programmeren' omdat dit allemaal nieuw voor me is, maar is alleen maar leuk. Bijna jammer dat het nu lente wordt 😂😂.

[TeslaNerd]

m10tech schreef op zondag 28 april 2024 @ 17:18:
[...]


Ik zit eigenlijk nog een stuk verder te denken...
Code schrijven die thermostaat is (dus alleen master OT), tevens ingrijpen tussen CIC en CV (dus master slave gateway) maar OOK ingrijpen in de lijn tussen CIC en Quatt.

Daarover zag ik nog niets geschreven, dus ik vroeg me af of dat al ergens wordt gedaan/beschreven.
Uit de JSON output screenshots verwacht ik dat hier MODBUS wordt gebruikt, en dat zou ook prima door een gateway gemanipuleerd kunnen worden.

Ik heb zat ervaring met dingen reverse engineeren en daarna alles te ontwerpen en bouwen, maar dit is een vraag over de strategie.
Als ik het goed heb dan zijn er maar 3 OT commandos uit de Quatt slave, roomSet, roomTemp en CHenable, wat natuurlijk schandalig weinig is. Of is dat achterstallige documentatie op de Quatt deel2 pagina?

Betekend dit dat we de CIC ook helemaal kunnen vervangen? Dat zou ook helemaal niet verkeerd zijn.

PS. Ik moet mijn Quatt nog wel aanschaffen, maar dat gaat niet lang meer duren...

Ik heb hierboven een aantal posts geplaatst met mijn modbus verkenningen tussen CiC en de Quatt buitenunit. Daar staat ook een datafile en een logfile van de modbus samples die ik vorige week heb gemaakt. Daar kun je ook zonder eigen Quatt al naar kijken. Ben benieuwd wat jij daar uit haalt. Ik sta open voor alle suggesties voor een vervolg om het Quatt modbus protocol te ontcijferen

[patrickvdhart]

JazekerXX schreef op maandag 29 april 2024 @ 17:31:
[...]


de P, I en D waardes zijn niet in tijd.

Dank voor je reactie maar dat begrijp ik niet.

P is nooit in tijd, is meestal een rechtstreekse gain (bijv Honeywell) of gedefinieerd als proportionele band, gain = 100 / Pb (bijv in Foxboro). Heeft over het algemeen geen eenheid want %verandering/%verandering
I staat voor integral time en is nu eenmaal een tijd,
D voor derivative en is normaal ook in tijd units.

Waarom denk jij dat het geen tijd is? Is dat anders in de DIYless? Of heb ik iets totaal gemist in de discussie, hebben we het hier niet over een PID, dat sluit ik ook niet uit.....

[Flesym]

patrickvdhart schreef op dinsdag 30 april 2024 @ 11:52:
[...]

Dank voor je reactie maar dat begrijp ik niet.

P is nooit in tijd, is meestal een rechtstreekse gain (bijv Honeywell) of gedefinieerd als proportionele band, gain = 100 / Pb (bijv in Foxboro). Heeft over het algemeen geen eenheid want %verandering/%verandering
I staat voor integral time en is nu eenmaal een tijd,
D voor derivative en is normaal ook in tijd units.

Waarom denk jij dat het geen tijd is? Is dat anders in de DIYless? Of heb ik iets totaal gemist in de discussie, hebben we het hier niet over een PID, dat sluit ik ook niet uit.....

P en I waardes zijn niet gefixed omdat het PI(D) algoritme voor veel doeleinden wordt gebruikt (van sturing van in ms tot bv uren. De tijd is wat ik begrijp afhankelijk van het halen van het doel en krimpt naarmate de hysteresis kleiner wordt. En I is het vermogen (proportional) x de tijd die hiervoor nodig is. Bij mij lijken overigens de waardes P=3 en I=1,5 goed te werken.
De theorie kun je hier teruglezen.
Wikipedia: Proportional–integral–derivative controller

[ Voor 10% gewijzigd door Flesym op 30-04-2024 17:04 ]