[OTGW] OpenTherm gateway

[Jpiek]

hvxl schreef op donderdag 30 januari 2025 @ 21:50:
Er bestaan nog behoorlijk wat misverstanden, merk ik. Ik zal proberen een paar uit de wereld te helpen:
[list]
• Als je geïnteresseerd bent in informatie van je ketel/warmtepomp, zoals hier het geval, dan heeft het weinig nut om naar de thermostaat te kijken. Die zal dezelfde dezelfde informatie laten zien, onafhankelijk van de ketel. Het enige dat je zou kunnen zien is dat de eTwist wel de waterdruk opvraagt. Dus als je die niet ziet, dan geeft de ketel die waarschijnlijk niet.

Check, de eTwist RF ondersteunt waterdruk niet. En krijg ik ook niet binnen via de gateway.

Dat ID 28 ontbreekt betekent ook alleen dat de thermostaat die niet opvraagt. Het zegt niets over of de ketel die wel of niet kan rapporteren.

Vraagt de etwist dus blijkbara niet op, na een 'AA=28' krijg ik die data dus wel via de gateway.
Ik had gehoopt dus met de gateway te kunnen wat met de etwist niet gaat. Nogmaals ik ben een N00b vwb Opentherm..

Of, en hoe vaak Burner Operation Hours voorbij komt hangt af van hoe vaak die wordt opgevraagd. De ketel is de slave. Die kan alleen antwoord geven op de gegevens die worden opgevraagd. Hij kan niet uit zichzelf informatie gaan lopen verkondigen.

Ik heb het idee dat de warmtepomp maar heel summier antwoord geeft.

De makkelijkste manier om te bepalen welke berichten de ketel aankan is om een capability log te maken. Als die klaar is moet het lijstje in de statistics tab een stuk langer zijn. Voor elk van de berichten kun je dan zien of de ketel met een Read-Ack of met Unknown-DataID heeft geantwoord. Unk betekent dat de ketel dat ID niet ondersteunt. Het is niet eens noodzakelijk om de log op te sturen. Al is het natuurlijk wel zo sympathiek om dat wel te doen.

Ik zal die dit weekend eens een tijdje open laten staan en kijken wat er uit komt..

[borft]

Jpiek schreef op vrijdag 31 januari 2025 @ 12:59:
[...]


Check, de eTwist RF ondersteunt waterdruk niet. En krijg ik ook niet binnen via de gateway.


[...]


Vraagt de etwist dus blijkbara niet op, na een 'AA=28' krijg ik die data dus wel via de gateway.
Ik had gehoopt dus met de gateway te kunnen wat met de etwist niet gaat. Nogmaals ik ben een N00b vwb Opentherm..


[...]


Ik heb het idee dat de warmtepomp maar heel summier antwoord geeft.


[...]


Ik zal die dit weekend eens een tijdje open laten staan en kijken wat er uit komt..

tip: otmonitor heeft ook een web interface, dus als je hem ergens in een screen oid headless laat draaien, kan je de resultaten in de web interface bekijken.

[hvxl]

Een capability log maken kan alleen via de GUI. De web interface biedt deze mogelijkheid (nog) niet.

[Jpiek]

borft schreef op vrijdag 31 januari 2025 @ 13:16:
[...]


tip: otmonitor heeft ook een web interface, dus als je hem ergens in een screen oid headless laat draaien, kan je de resultaten in de web interface bekijken.

Heb verder niks in m'n netwerk om hem op te laten draaien, Ja een Synology NAS...
Kan net zo goed ff m'n PC aan laten staan..

[tjanssen]

Jerra schreef op vrijdag 31 januari 2025 @ 00:12:
Gebruik je een bedrade of draadloze round modulation?

Een beetje late reactie, maar ik gebruik de bedrade variant.

[Jerra]

Ah oke, die ondersteunt dan blijkbaar wel het overschrijven van het setpoint.

Ik heb zelf de draadloze en daarmee lukt het me niet (en als ik het me goed herinner stond dat ook in die ondersteuningsmatrix)

[tjanssen]

Jerra schreef op maandag 3 februari 2025 @ 11:09:
Ah oke, die ondersteunt dan blijkbaar wel het overschrijven van het setpoint.

Ik heb zelf de draadloze en daarmee lukt het me niet (en als ik het me goed herinner stond dat ook in die ondersteuningsmatrix)

Klopt, set point kan ik overschrijven. Dit werkt perfect. Mijn vraag was eigenlijk meer of ik ook room temperature kan overschrijven, om de thermostaat dus te laten regelen op externe temperatuur sensor ipv zijn eigen meting.

[Jerra]

Dat kan niet voor zover ik weet, maar je kan wel de OTGW laten draaien als "thermostaat simulator" en opentherm monitor tegelijkertijd toch?

Nadeel is alleen dat je het dan niet terugziet op het display van de thermostaat, ik verwacht nou net dat dat hetgene is wat je wilt bereiken?

[hvxl]

Er is in de opentherm spec geen bericht gedefinieerd om de thermostaat een kamertemperatuur te vertellen. Ik heb even geprobeerd om een andere waarde terug te sturen in de Write-Ack als de round modulation de kamertemperatuur opstuurt, maar daar doet hij niets mee, voor zover ik kan bepalen. Dus ik ben ook bang dat dit niet mogelijk is.

[amarkest]

Jpiek schreef op donderdag 30 januari 2025 @ 07:10:
@Tycoontje nee, nog niet gekeken met OTmonitor, wel op de OTGW webinterface.
Maar met het niet kunnen instellen van de max keteltemp mis ik mijn belangrijkste functie helaas al..

Ik gebruik in Homey een flow die elke 10 sec div. apparaten uitleest en de waarden in div. variabelen zet.
Ook de OTGW lees ik zo uit, omdat de OTGW monitor app in Homey niet alles laat zien.
Deze variabelen display ik via een Homey dashboard.
Werkt perfect.


De OpenTherm CV wordt aangestuurd door een 2e otgw via een 2e otgw app op Homey, omdat mn 10jr oude warmtepomp dit niet helemaal goed deed.
Via een flow die elke 30 sec. de door de thermostaat gevraagde Ta set als dat nodig is. " stuur commando: CS={{ gevraagdeketeltemp }} ".

Jpiek schreef op dinsdag 4 februari 2025 @ 16:37:
Ik ben wat aan het spelen/experimenteren geweest met OTGW en Homey, ipv een 'harde' stooklijn in te stellen heb ik er in Homey een formule aan gehangen :

Doeltemperatuur= {{round(46-((Huidige temperatuur)/2),1)}}

Dus uitgaande van een doeltemp van 46 bij 0 graden geeft dat als stooklijn :

[Afbeelding]

[Afbeelding]

Ik ben er nog niet helemaal...

Via de knmi app in Homey kun je de gevoelstemperatuur ms ook meenemen

[ Voor 55% gewijzigd door amarkest op 04-02-2025 16:40 ]

[Jpiek]

Ik ben wat aan het spelen/experimenteren geweest met OTGW en Homey, ipv een 'harde' stooklijn in te stellen heb ik er in Homey een formule aan gehangen :

Doeltemperatuur= {{round(46-((Huidige temperatuur)/2),1)}}

Dus uitgaande van een doeltemp van 46 bij 0 graden geeft dat als stooklijn :





Ik ben er nog niet helemaal...

[Jpiek]

amarkest schreef op dinsdag 4 februari 2025 @ 16:23:
[...]
Via een flow die elke 30 sec. de door de thermostaat gevraagde Ta set als dat nodig is. " stuur commando: CS={{ gevraagdeketeltemp }} ".

[..]

Via de knmi app in Homey kun je de gevoelstemperatuur ms ook meenemen

CS moet toch elke minuut herhaald worden om niet terug te vallen op wat de thermostaat aangeeft ?

Gevoelstemp heb ik iid ook wel mee lopen experimenteren, ben ik nog niet helemaal uit omdat dat geen echt meetgegeven is..

[amarkest]

30sec bij mij omdat 1 minuut niet goed ging

[Jpiek]

Ik merk dat het sturen van CH=1 voor CS blijkbaar verschil maakt.
Ik kan me vergissen, maar houd de CV/WP dan wel de watertemperatuur op de ingestelde waarde van CS ?
Zonder blijkbaar/schijnbaar alleen als de thermostaat er om vraagt ?

[Dutchess_Nicole]

Jpiek schreef op dinsdag 4 februari 2025 @ 21:58:
Ik merk dat het sturen van CH=1 voor CS blijkbaar verschil maakt.
Ik kan me vergissen, maar houd de CV/WP dan wel de watertemperatuur op de ingestelde waarde van CS ?
Zonder blijkbaar/schijnbaar alleen als de thermostaat er om vraagt ?

Je kan idd CH=1 sturen, dat zet de boiler/WP aan. Betekent niet perse dat hij ook gaat werken, daar heb je dan weer CS voor nodig.

In mijn HA automation heb ik oa. dit stuk code opgenomen:

YAML:

  - repeat:
      while: []
      sequence:
        - data:
            topic: OTGW/set/otgw-308398A2F389/ctrlsetpt
            payload: 5
            qos: 0
            retain: false
          action: mqtt.publish
        - delay:
            hours: 0
            minutes: 0
            seconds: 30
            milliseconds: 0

Er zit nog veel meer logica omheen natuurlijk maar idd elke 30 seconden de CS opgeven werkt zolang de CH aan staat. Dat is min of meer de override van wat de thermostaat zelf zou sturen als die een warmtevraag aangeeft.

een controlsetpoint van 5 doet natuurlijk niks in mijn geval omdat dit een boiler betreft en deze niet kan koelen.

[ Voor 4% gewijzigd door Dutchess_Nicole op 06-02-2025 10:52 ]

[Jpiek]

Dutchess_Nicole schreef op donderdag 6 februari 2025 @ 10:52:
[...]
Er zit nog veel meer logica omheen natuurlijk maar idd elke 30 seconden de CS opgeven werkt zolang de CH aan staat. Dat is min of meer de override van wat de thermostaat zelf zou sturen als die een warmtevraag aangeeft.

Precies dat, ik stuurde wel een CS maar er gebeurde erg weinig.

Nu stuur ik een CH=1, bereken de doeltemp voor CS en stuur dan CS=doeltemp (eens per 58 seconden).
Begin nu op een punt te komen dat ik deze flow bijna 's nachts ook durf te draaien (wakker worden in een koud huis is niet fijn, overdag kan ik de grafieken in de gaten houden).

Soms heb ik nog een overshoot van 0,5 a 1 C. Ik zette dan eerst CH=0, maar verlaag nu ff tijdelijk de CS met 4 graden, ff kijken wat ie dan doet.. Het wate helemaal af laten koelen is ook zonde..

een controlsetpoint van 5 doet natuurlijk niks in mijn geval omdat dit een boiler betreft en deze niet kan koelen.

Mijn warmtepomp kan wel koelen, maar daar blijf ik nog ff bij uit de buurt. Heb sowieso weinig zin in problemen met condens op mij radiatoren en dan op mij HH vloer..

[Dutchess_Nicole]

Jpiek schreef op donderdag 6 februari 2025 @ 11:01:
[...]


Precies dat, ik stuurde wel een CS maar er gebeurde erg weinig.

Nu stuur ik een CH=1, bereken de doeltemp voor CS en stuur dan CS=doeltemp (eens per 58 seconden).
Begin nu op een punt te komen dat ik deze flow bijna 's nachts ook durf te draaien (wakker worden in een koud huis is niet fijn, overdag kan ik de grafieken in de gaten houden).

Soms heb ik nog een overshoot van 0,5 a 1 C. Ik zette dan eerst CH=0, maar verlaag nu ff tijdelijk de CS met 4 graden, ff kijken wat ie dan doet.. Het wate helemaal af laten koelen is ook zonde..


[...]


Mijn warmtepomp kan wel koelen, maar daar blijf ik nog ff bij uit de buurt. Heb sowieso weinig zin in problemen met condens op mij radiatoren en dan op mij HH vloer..

YAML:

alias: Set Central Heating temperature for Boiler
description: ""
triggers:
  - entity_id:
      - sensor.boiler_cs_wdc
    id: Active
    trigger: state
  - trigger: state
    entity_id:
      - timer.central_heating_cooldown
    to: idle
    id: Active
  - event: start
    id: turn-on
    trigger: homeassistant
  - event: shutdown
    id: shutdown
    trigger: homeassistant
  - entity_id:
      - input_boolean.central_heating_auto_enabled
    id: boolean_enable
    trigger: state
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - turn-on
        sequence:
          - metadata: {}
            data: {}
            target:
              entity_id: input_boolean.central_heating_auto_enabled
            action: input_boolean.turn_on
          - data:
              topic: OTGW/set/otgw-308398A2F389/ctrlsetpt
              payload: "5"
              qos: "1"
              retain: false
            action: mqtt.publish
      - conditions:
          - condition: trigger
            id:
              - shutdown
        sequence:
          - metadata: {}
            data: {}
            target:
              entity_id: input_boolean.central_heating_auto_enabled
            action: input_boolean.turn_off
          - stop: Shutting down
      - conditions:
          - condition: state
            entity_id: input_boolean.central_heating_auto_enabled
            state: "on"
          - condition: or
            conditions:
              - condition: trigger
                id: Active
              - condition: trigger
                id: boolean_enable
        sequence:
          - choose:
              - conditions:
                  - condition: template
                    value_template: >-
                      {{ (states('sensor.boiler_cs_wdc') | float) | round(1) >
                      10.0 }}
                  - condition: state
                    entity_id: timer.central_heating_cooldown
                    state: idle
                sequence:
                  - data: {}
                    target:
                      entity_id: input_boolean.ch_last_activity
                    action: input_boolean.turn_on
                  - data_template:
                      value: >-
                        {% set accumulator =
                        states('input_number.ch_accumulator') |
                        float(default=0.0) %} {% set offset =
                        state_attr('sensor.boiler_cs_wdc', 'absolute_offset') |
                        float(default=0.0) %} {% set rcf =
                        states('input_number.room_compensation_factor')  |
                        float(default=0.0) %} {% set target_accu = (offset *
                        rcf) - accumulator %} {{ ([-1, ( accumulator +
                        target_accu ) | float(default=0.0) | round(2), 5] |
                        sort)[1] }}
                      entity_id: input_number.ch_accumulator
                    action: input_number.set_value
                  - repeat:
                      while:
                        - condition: template
                          value_template: >-
                            {{ (states('sensor.boiler_cs_wdc') | float) |
                            round(1) > 10.0 }}
                      sequence:
                        - data:
                            topic: OTGW/set/otgw-308398A2F389/ctrlsetpt
                            payload: "{{ states('sensor.boiler_cs_wdc') | float }}"
                          action: mqtt.publish
                        - delay:
                            hours: 0
                            minutes: 0
                            seconds: 30
                            milliseconds: 0
              - conditions:
                  - condition: or
                    conditions:
                      - condition: template
                        value_template: >-
                          {{ (states('sensor.boiler_cs_wdc') | float) | round(1)
                          <= 10.0 }}
                      - condition: state
                        entity_id: timer.central_heating_cooldown
                        state: active
                sequence:
                  - data_template:
                      value: >-
                        {{ (states('input_number.ch_accumulator') |
                        float(default=0.0) * 0.50) | round(2) }}
                      entity_id: input_number.ch_accumulator
                    action: input_number.set_value
                  - if:
                      - condition: state
                        entity_id: input_boolean.ch_last_activity
                        state: "on"
                    then:
                      - data:
                          duration: 0
                        target:
                          entity_id: timer.central_heating_cooldown
                        action: timer.start
                      - data: {}
                        target:
                          entity_id: input_boolean.ch_last_activity
                        action: input_boolean.turn_off
                  - repeat:
                      while: []
                      sequence:
                        - data:
                            topic: OTGW/set/otgw-308398A2F389/ctrlsetpt
                            payload: 5
                            qos: 0
                            retain: false
                          action: mqtt.publish
                        - delay:
                            hours: 0
                            minutes: 0
                            seconds: 30
                            milliseconds: 0
    default:
      - data:
          topic: OTGW/set/otgw-308398A2F389/ctrlsetpt
          payload: "5"
          qos: "1"
          retain: false
        action: mqtt.publish
      - data:
          duration: 0
        target:
          entity_id: timer.central_heating_cooldown
        action: timer.start
      - data:
          value: 0
        target:
          entity_id: input_number.ch_accumulator
        action: input_number.set_value
mode: restart

Ik zal mijn algoritme eens dele ter leering ende vermaeck.

sensor.boiler_cs_wdc is hier best speciaal, dit is een trigger-based template sensor die op zijn beurt alle temperatuurgegevens uit het huis binnenkrijgt en op basis daarvan een setpoint genereert. Inputs daarop zijn
twee thermostaten, de buitentemperatuur, een input_number die bepaald welke temperatuur belangrijker is (binnen of buiten), twee binary sensors die thermostaten tijdelijk kunnen uitzetten, en 4 input_numbers die samen de stooklijn bepalen.

It's a mess, zeker. maar het werkt verbazend goed.



Alle communicatie hiermee inclusief de min of meer permanente override van de hoofdthermostaat via de OTGW werken door dit systeem.

En als HA plat ligt door wat voor omstandigheid dan ook dan neemt de hoofdthermostaat het gewoon weer over.

Dat kan ik handig in het grafiekje rechtsonder zien omdat de setpoint op de laagste stand dan op 10 graden staat. Mijn automation zet die op 5 zodat ik het verschil kan zien.

[Jpiek]

Dutchess_Nicole schreef op donderdag 6 februari 2025 @ 11:50:
[...]

sensor.boiler_cs_wdc is hier best speciaal, dit is een trigger-based template sensor die op zijn beurt alle temperatuurgegevens uit het huis binnenkrijgt en op basis daarvan een setpoint genereert. Inputs daarop zijn
twee thermostaten, de buitentemperatuur, een input_number die bepaald welke temperatuur belangrijker is (binnen of buiten), twee binary sensors die thermostaten tijdelijk kunnen uitzetten, en 4 input_numbers die samen de stooklijn bepalen.

It's a mess, zeker. maar het werkt verbazend goed.

[...]

En als HA plat ligt door wat voor omstandigheid dan ook dan neemt de hoofdthermostaat het gewoon weer over.

In Homey werkt het toch wel heel anders en in HA ben ik niet thuis, dus dit is best lastig lezen voor me..

Ik probeer het in Homey dan ook zoveel mogelijk KISS te houden, als basis een stooklijn met buitentemp en alngzaamaan wat bijsturen als de binnentemp daar aanleiding toegeeft.

[Jpiek]

Nieuwe versie gemaakt die wat meer/beter kijkt naar de ingestelde kamer temperatuur en dan -5 of +2 op de doeltemp. doet, ff kijken of dat genoeg/teveel is.

Weet iemand of je met een paar commando's alle leds (op power na) uit kunt zetten ?
(en de huidige instellingen op kunt slaan om ze later weer aan te zetten) ?

Ik kreeg commentaar dat kerst al voorbij was en dat ik nog wat lampjes had laten hangen in de berging

[Dutchess_Nicole]

Jpiek schreef op vrijdag 7 februari 2025 @ 13:33:
Nieuwe versie gemaakt die wat meer/beter kijkt naar de ingestelde kamer temperatuur en dan -5 of +2 op de doeltemp. doet, ff kijken of dat genoeg/teveel is.

Weet iemand of je met een paar commando's alle leds (op power na) uit kunt zetten ?
(en de huidige instellingen op kunt slaan om ze later weer aan te zetten) ?

Ik kreeg commentaar dat kerst al voorbij was en dat ik nog wat lampjes had laten hangen in de berging

Voorzover ik weet kan dat niet zonder de firmware te hacken. Kun je natuurlijk altijd even in discord vragen als feature request!

[Jpiek]

Ik plak er wel een ducktape overheen

Ik zag wel dat je de functie per led kon aanpassen, maar ik weet niet welke functie ze nu hebben.

dan zou je ze in principe allemaal op 'niks' kunnen zetten ofzo..

[Jpiek]

Ok, gefixed. via de 'options' van OTmonitor alle leds op een functie gezet die niet ondersteunt word.
En dus licht het ledje niet op..

[Refthoom]

Jpiek schreef op vrijdag 7 februari 2025 @ 13:33:
Ik kreeg commentaar dat kerst al voorbij was en dat ik nog wat lampjes had laten hangen in de berging

Wat is er mis met wat lichtjes in de meterkast?

[Jerra]

(off-topic)

Nou circa 25 ledjes van een halve watt kan toch oplopen naar zo'n 25 euro per jaar...

[Jpiek]

Refthoom schreef op maandag 10 februari 2025 @ 16:05:
[...]
Wat is er mis met wat lichtjes in de meterkast?

Niks, heb ik ook, maar dit is in de berging...

[hvxl]

Jerra schreef op maandag 10 februari 2025 @ 16:13:
(off-topic)

Nou circa 25 ledjes van een halve watt kan toch oplopen naar zo'n 25 euro per jaar...

Als je zo rekent hakt het er wel in. Alleen verstoken de ledjes van de OTGW hoogstens 10mW en zijn het er maar 6. Dan kom je uit op €0,15 per jaar, als ze allemaal continue zouden branden.

[Jerra]

Ik had ook even geteld op de foto, en ben wel uitgegaan van behoorlijk felle ledjes ja maar dat kwam ook door desbetreffende foto

[Refthoom]

Jerra schreef op zaterdag 15 februari 2025 @ 00:23:
Ik had ook even geteld op de foto, en ben wel uitgegaan van behoorlijk felle ledjes ja maar dat kwam ook door desbetreffende foto

Omdat de foto in het donker is genomen lijken de ledjes erg fel inderdaad. Maar het zijn allemaal ledjes waar ik niets mee kan. Er is precies 1 apparaat daar met 1 led, wat ik zelf gemaakt heb en waar ik dus iets aan zou kunnen doen. De rest zijn zo gemaakt en geleverd en kan ik dus niet veranderen.

Dat gezegd, al met al best veel ledjes inderdaad en jammer dat er standaard geen opties zijn om ze uit te zetten

[hvxl]

Met LA=D, LB=D, etc kun je de status LEDs uit zetten. De power LEDs zijn inderdaad wel altijd aan als er spanning op de OTGW staat.

[Refthoom]

hvxl schreef op zaterdag 15 februari 2025 @ 11:42:
Met LA=D, LB=D, etc kun je de status LEDs uit zetten. De power LEDs zijn inderdaad wel altijd aan als er spanning op de OTGW staat.

Klopt en die suggestie was al eerder gegeven. Als aanstichter (mea culpa) zeg ik; beter nu stoppen want eigenlijk is het off topic.

[JBS]

Maandenlang heb ik inmiddels een OTGW tussen m'n CV en Tado Draadloze Ontvanger zitten, probleemloos.

De laatste paar dagen verliest de Tado Draadloze Ontvanger regelmatig de verbinding met de Tado bridge, zie ik incorrecte Room Setpoint of Room Temperatures waardes in de OTGW en is een herstart van de Draadloze Ontvanger of OTGW niet genoeg om dit te herstellen. Vaak is beide nodig, of eerst OTGW, dan Tado Draadloze Ontvanger en dan weer OTGW.

Allrnaal afwijkend gedrag vergeleken met de afgelopen maanden.

Herkent iemand dit gedrag in combinatie met Tado (specifiek de laatste paar dagen)?

\\Edit: Heb de OTGW er vanmorgen tussenuit gehaald, maar zojuist verliest de Draadloze Ontvanger wederom z'n verbinding met de Tado Bridge. Niet OTGW gerelateerd dus.

[ Voor 12% gewijzigd door JBS op 18-02-2025 08:54 ]

[Ditbenik]

Misschien een domme vraag van mij en misschien is het ook al lang beantwoord, maar ik be nieuw als het gaat om de gateway. Ik heb deze geinstalleerd in Home Assistant. Aan de ene kant hangt een weheat warmtepomp en aan de andere kant de opentherm module van Evohome. Vanmiddag had ik de verwarming uitgezet. Om 17.45 weer aan. Ik zag dat de warmtepomp daar ook onmiddellijk op reageert en een gevraagde aanvoertemperatuur (in de webportal) toon van 34 graden). De gevraagde aanvoertemperatuur is dus veranderd. Wat ik ook zie in de gateway is dat de opentherm module van Evohome pas een half uur later laat zien dat de gevraagde setpoint omhoog gooit. Doe ik iets fout? Ik zou verwachten dat ik de nieuwe setpoint gelijk zie omdat de warmtepmp die ook gelijk laat zien.

[Jpiek]

@Ditbenik je hebt het over de OT module van Evohome versus de Weheat.... wat zegt de OTGW in HA dan ?

Als de Evohome de Weheat aanstuurdt is dat het device wat de aanvraag voor de aanvoertemperatuur doet toch ? de OTGW en de Weheat volgen daar alleen maar in..

[Ditbenik]

Jpiek schreef op woensdag 19 februari 2025 @ 12:59:
@Ditbenik je hebt het over de OT module van Evohome versus de Weheat.... wat zegt de OTGW in HA dan ?

Als de Evohome de Weheat aanstuurdt is dat het device wat de aanvraag voor de aanvoertemperatuur doet toch ? de OTGW en de Weheat volgen daar alleen maar in..

Ja de opentherm module van evohome stuurt de weheat aan via de gateway (van nodo). Uiteindelijk wil ik het gedrag van de evohome beinvloeden in home assistant via de gateway. Maar dan moet ik daar wel de juiste waarden kunnen lezen van de opentherm module. Vanmorgen zag ik in Home Assistant dat de laatste informatie in de gateway van de opentherm module van 7 uur geleden was. De weheat geeft wel om de paar seconden zijn waarden door aan de gateway. Ter controle heb ik gisteravond ook gateway geinstalleerd op mijn Homey. Daar zag ik wel de een gevraagde setpoint vanuit de opentherm module die voortdurend geactualiseerd wordt. Het lijkt dus niet te liggen aan de hardware, maar aan de software.

[Jpiek]

Ok, ik kon het ook al niet plaatsen. De homey app doet het hier prima..

[AOC]

Graag wil ik thuis een Vaillant Ecotec Plus aansturen.

Wat ik graag wil doen is d.m.v. zigbee temperatuursensoren in verschillende ruimtes de temperatuur per ruimte instellen. Maar dan ook per ruimte een andere setpoint instellen. Dit omdat de ruimtes waar vloerverwarming op een lager setpoint zou kunnen werken, dan de ruimtes waar radiatoren staan. Wel belangrijk dat radiatoren uit staan wanneer vloerverwarming aan staat en vica versa.

Is zoiets te automatiseren met bijvoorbeeld Home Assistent, OTGW en Smart Autotune Thermostat (SAT)?

Heb het gevoel dat dit mogelijk is, maar heb er nog geen kijk op en hopelijk heeft iemand hier wellicht een soortgelijke situatie

[Jpiek]

De setpoint geldt volgens mij voor de ketel niet voor individuele ruimtes.

Ik zou de sensoren combineren met thermostatische kranen met daarop slimme knoppen.

met een HA of Homey vervolgens de kranen open of dicht zetten en aan de hand van o.a. het aantal openstaande kranen de aanvoertemperatuur aansturen met de OTGW.

Maar iets zegt me dat er al thermostaten zijn met koppelbare thermostaatkranen/knoppen die dat beter kunnen dan jij of ik met een Home automation..

[Refthoom]

AOC schreef op donderdag 20 februari 2025 @ 13:43:
Graag wil ik thuis een Vaillant Ecotec Plus aansturen.

Wat ik graag wil doen is d.m.v. zigbee temperatuursensoren in verschillende ruimtes de temperatuur per ruimte instellen. Maar dan ook per ruimte een andere setpoint instellen. Dit omdat de ruimtes waar vloerverwarming op een lager setpoint zou kunnen werken, dan de ruimtes waar radiatoren staan. Wel belangrijk dat radiatoren uit staan wanneer vloerverwarming aan staat en vica versa.

Is zoiets te automatiseren met bijvoorbeeld Home Assistent, OTGW en Smart Autotune Thermostat (SAT)?

Heb het gevoel dat dit mogelijk is, maar heb er nog geen kijk op en hopelijk heeft iemand hier wellicht een soortgelijke situatie

Geen ervaring met vloerverwarming, wel met radiatoren en convectoren.

Snelste en minste omkijken is kopen. Voor de winter bij mijn broer spullen van T*d* geïnstalleerd voor datzelfde doel. Niet goedkoop maar straight forward installatie en werkt heel goed, vind ik. Iets van €1400 voor 10 radiatoren, de huiskamer thermostaat (ondersteunt OpenTherm) en de internet bridge. Met twee uurtjes alles geïnstalleerd en daarna nog wat gepuzzel om de instellingen in de app te vinden en goed ingesteld te krijgen.

Zelf maken kan ook, ben daar mee bezig. Het gaat om warmte opwekking, warmte afgifte en warmte vraag, per ruimte aan elkaar te koppelen, er zijn meer wegen naar Rome om dat te doen.

Dat begint met de temperatuur metingen te verzamelen en in je domotica systeem de setpoints instellen, zodat je een trigger hebt waar je een actie aan kan koppelen. Met een buiten temperatuur sensor kun je eventueel een control setpoint berekenen voor de Taanvoer (of je gebruikt een stooklijn tabel). Vervolgens heb je aanstuurbare kleppen (kranen) nodig om de radiatoren af te sluiten en te openen als dat nodig is. Tegelijkertijd, moet je de warmtebron aansturen voor aan/uit en control setpoint. (Je wil voorkomen dat de CV aangezet wordt als alle radiatoren dicht zijn)
In je domotica heb je wat PID intelligentie nodig voor de aan/uit sturing obv de temperatuur sensoren.

[Proview]

Ik bezit momenteel een opentherm gateway versie met de P16F88 icm NodeMCU v2 ipv de huidige versie met PIC16F1847 en Wemos D1.

Firmware versies:

• Mcu: 0.10.3+e334c42
• PIC: 5.8

Bij deze mijn vragen:

• Wat is het voordeel van de versie met PIC16F1847 icm de Wemos D1 ten opzichte van die met de P16F88
• Ik gebruik de gateway nu met home assistent en ervaar veel drop outs. De gateway is nagenoeg elke twee minuten niet te benaderen (status=unavailable). Zal de nieuwe versie dit probleem kunnen oplossen? Zelf denk ik dat de oorzaak waarschijnlijk bij de wifi verbinding zal liggen, aangezien de gateway op zolder staat en de wifi router twee etages lager.
• Ik heb zelf nog een Wemos D1 pro liggen. Kan die gebruikt worden icm de huidige versie (PIC16F1847) van de gateway?

Ik ben benieuwd naar de antwoorden.

[Refthoom]

Proview schreef op zondag 23 februari 2025 @ 12:20:
Ik bezit momenteel een opentherm gateway versie met de P16F88 icm NodeMCU v2 ipv de huidige versie met PIC16F1847 en Wemos D1.

Firmware versies:

• Mcu: 0.10.3+e334c42
• PIC: 5.8

Bij deze mijn vragen:

• Wat is het voordeel van de versie met PIC16F1847 icm de Wemos D1 ten opzichte van die met de P16F88
• Ik gebruik de gateway nu met home assistent en ervaar veel drop outs. De gateway is nagenoeg elke twee minuten niet te benaderen (status=unavailable). Zal de nieuwe versie dit probleem kunnen oplossen? Zelf denk ik dat de oorzaak waarschijnlijk bij de wifi verbinding zal liggen, aangezien de gateway op zolder staat en de wifi router twee etages lager.
• Ik heb zelf nog een Wemos D1 pro liggen. Kan die gebruikt worden icm de huidige versie (PIC16F1847) van de gateway?

Ik ben benieuwd naar de antwoorden.

Wifi kan zeker een issue zijn als je enige AP in het provider modem zit en 2 verdiepingen lager staat.

Als de D1 pro dezelfde pinout heeft kun je hem wel gebruiken In het geval die een externe antenne heeft zou dat wellicht iets kunnen opleveren, maar als er bijvoorbeeld twee betonvloeren tussen zitten dan zal dat weinig uitmaken.

Bedraad is geen optie? Of een mesh-systeem met bedrade AP's?

Overigens, als uiteindelijk de benodigde gegevens overkomen en het werkt zoals verwacht dan lijken (korte/tijdelijke) drop outs geen issue, denk ik.

[Proview]

Refthoom schreef op zondag 23 februari 2025 @ 12:36:
[...]

Wifi kan zeker een issue zijn als je enige AP in het provider modem zit en 2 verdiepingen lager staat.

Bedraad is geen optie? Of een mesh-systeem met bedrade AP's?

Bedraad heeft sowieso mijn voorkeur, maar helaas is het niet zo gemakkelijk om bedrading door te trekken tot op zolder. Dus ook bedrade AP's zijn lastig te realiseren.

Wellicht biedt het gebruik van MQTT nog een oplossing, maar daar zal ik mij dan eerst in moeten verdiepen.

[Refthoom]

Proview schreef op zondag 23 februari 2025 @ 14:45:
[...]


Bedraad heeft sowieso mijn voorkeur, maar helaas is het niet zo gemakkelijk om bedrading door te trekken tot op zolder. Dus ook bedrade AP's zijn lastig te realiseren.

Wellicht biedt het gebruik van MQTT nog een oplossing, maar daar zal ik mij dan eerst in moeten verdiepen.

Hmmm, hoe zie je verbetering met MQTT, dat gaat over dezelfde wifi verbinding, toch?

Is er geen bestaande koof voor standleidingen die je kunt openen, waar je dan een draad door kan trekken?

[Proview]

Refthoom schreef op zondag 23 februari 2025 @ 15:17:
[...]

Hmmm, hoe zie je verbetering met MQTT, dat gaat over dezelfde wifi verbinding, toch?

Is er geen bestaande koof voor standleidingen die je kunt openen, waar je dan een draad door kan trekken?

Helaas komt de glasvezel hier niet in de meterkast binnenshuis, dus die koof is niet te bereiken zonder dat ik door muren of een verdiepingsvloer moet boren. Bovendien is het een huurhuis, dus ik doe dat ook liever niet.

Wat die MQTT betreft. Ik gebruik de gateway voornamelijk voor het uitlezen van de verschillende sensoren binnen een aantal automations in Home Assistent (HA). Omdat die sensoren zo ongeveer elke twee minuten unavailable raken, heeft dat een negatieve uitwerking op die automations. Ze worden hierdoor onvoorspelbaar, zeker wanneer je deze sensoren binnen state triggers gebruikt. Met MQTT zal dit niet optreden. Berichten die niet compleet mijn mosquitto broker bereiken, veroorzaken niet dat een sensor unavailable wordt binnen HA. Dat was althans mijn theorie. Ik heb dit gisteren getest en het blijkt inderdaad zo te werken. Ik krijg nu alle benodigde waarden binnen, zonder dat de sensoren unavailable raken. Ik moest alleen wel diverse automations bijwerken, maar het werkt nu wel stabiel. Hopelijk blijft dit ook stabiel werken 🤞
Bijkomend voordeel is dat ik binnen HA nu één integratie (OTGW) minder hoef te gebruiken, aangezien ik toch al MQTT gebruik voor diverse andere apparatuur.

[Refthoom]

Proview schreef op maandag 24 februari 2025 @ 07:16:
[...]

Helaas komt de glasvezel hier niet in de meterkast binnenshuis, dus die koof is niet te bereiken zonder dat ik door muren of een verdiepingsvloer moet boren. Bovendien is het een huurhuis, dus ik doe dat ook liever niet.

Wat die MQTT betreft. Ik gebruik de gateway voornamelijk voor het uitlezen van de verschillende sensoren binnen een aantal automations in Home Assistent (HA). Omdat die sensoren zo ongeveer elke twee minuten unavailable raken, heeft dat een negatieve uitwerking op die automations. Ze worden hierdoor onvoorspelbaar, zeker wanneer je deze sensoren binnen state triggers gebruikt. Met MQTT zal dit niet optreden. Berichten die niet compleet mijn mosquitto broker bereiken, veroorzaken niet dat een sensor unavailable wordt binnen HA. Dat was althans mijn theorie. Ik heb dit gisteren getest en het blijkt inderdaad zo te werken. Ik krijg nu alle benodigde waarden binnen, zonder dat de sensoren unavailable raken. Ik moest alleen wel diverse automations bijwerken, maar het werkt nu wel stabiel. Hopelijk blijft dit ook stabiel werken 🤞
Bijkomend voordeel is dat ik binnen HA nu één integratie (OTGW) minder hoef te gebruiken, aangezien ik toch al MQTT gebruik voor diverse andere apparatuur.

Mooie uitleg over MQTT en HA, ik heb weer wat geleerd, dankjewel.

[Proview]

Nog een vraagje over de serial commands om de ingestelde temperatuur te regelen.
Zoals ik het begrijp uit de documentatie kan je de temperatuur (setpoint) op 2 manieren instellen:

• TT=temperature
  Temperature, Temporary — Temporarily change the thermostat setpoint. The thermostat program will resume at the next programmed setpoint change. Values between 0.0 and 30.0 are allowed. A value of 0 indicates no remote override is to be applied.
  Examples: TT=19.5, TT=0
• TC=temperature
  Temperature, Constant — Change the thermostat setpoint. The thermostat program will not change this setting. Values between 0.0 and 30.0 are allowed. A value of 0 cancels the remote override.
  Examples: TC=16.0, TC=0

Ik had verwacht dat TT het setpoint aanpast van de thermostaat en dat deze door de thermostaat pas weer wordt aangepast nadat de volgende fase van het ingestelde programma ingaat.
Bij TC zal ik verwachten dat dit de thermostaat instelt op de 'continu modus', waarbij de ingestelde temperatuur vasthoudt tot deze handmatig wordt aangepast of tot dat handmatig het programma wordt vervolgt.

Echter blijkt het hier anders te werken:

• TT: De temperatuur wordt 'zeer' tijdelijk ingesteld, maar wordt doorgaans binnen 1 tot 2 minuten door de thermostaat weer teruggezet op de instelling die bij de fase van het lopende programma hoort. Dit werkt niet zoals ik het verwacht.
• TC: De temperatuur wordt ingesteld en blijft ingesteld. Dit werkt wel zoals verwacht.

Het probleem dat ik hiermee heb, is dat Home Assistant (HA) een TT command stuurt wanneer je in HA de temperatuur aanpast met als resultaat dat de temperatuur maar zeer tijdelijk wordt aangepast. Ik wil natuurlijk dat de temperatuur wordt aangepast tot dat de volgende fase van het programma ingaat of tot ik het handmatig weer aanpas.

Ligt dit aan mij? Begrijp ik het niet? Kan iemand hier dit wellicht verklaren of toelichten?


--------------------------------------------------------------
OTGW versie:

• Firmware Version: 0.10.3+e334c42 (Robert van den Breemen)
• PIC Firmware Version: 5.8
• PIC Device ID: pic16f88

Thermostaat:

• Honeywell Chronotherm Touch

Ketel:

• Remeha Avanta

Home Assistant:

• 2025.1.4

[ Voor 3% gewijzigd door Proview op 27-02-2025 18:06 ]

[Jpiek]

TT en CS sturen in principe tijdelijk maar worden beide na ca een minuut overruled. Om te voorkomen dat je TT=50 of CS=100 stuurt en de boel over de flos jaagt ofzo...

Staat ook op de pagina met uitleg.
Ik stuur met Homey commando's ipv de flowcard settemp te gebruiken. En stuur elke 58 sec een CS...

Valt Homey uit gaat de thermostaat verder...

[hvxl]

Proview schreef op donderdag 27 februari 2025 @ 17:44:
Ik had verwacht dat TT het setpoint aanpast van de thermostaat en dat deze door de thermostaat pas weer wordt aangepast nadat de volgende fase van het ingestelde programma ingaat.
Bij TC zal ik verwachten dat dit de thermostaat instelt op de 'continu modus', waarbij de ingestelde temperatuur vasthoudt tot deze handmatig wordt aangepast of tot dat handmatig het programma wordt vervolgt.

Het is inderdaad de bedoeling dat het zo werkt.

Heb je misschien de twee commando's met verschillende temperaturen getest? De Honeywell Chronotherm Touch heeft namelijk de vervelende beperking dat hij via Opentherm alleen op hele graden kan worden ingesteld. Als je bijvoorbeeld TT=19.5 hebt getest gaat het niet werken. Als je dan TC=20 test, werkt dat wel. Maar TT=20 zou ook moeten werken. Zo niet, dan kan een log meer duidelijkheid geven.

[hvxl]

Jpiek schreef op donderdag 27 februari 2025 @ 20:23:
TT en CS sturen in principe tijdelijk maar worden beide na ca een minuut overruled. Om te voorkomen dat je TT=50 of CS=100 stuurt en de boel over de flos jaagt ofzo...

Dit geldt voor CS, maar niet voor TT. TT stelt een kamertemperatuur in. Dat zal nooit heel erg uit de klauwen lopen. CS stelt daarentegen een watertemperatuur in. Als die niet na verloop van tijd weer wordt verlaagd, kan het wel erg warm worden. Daarom zit daar een beveiliging op.

[Jpiek]

@hvxl Dan heb ik de TT inderdaad verkeerd begrepen.

Opent wel weer mogelijkheden voor mijn flow. Ik zou dus TT kunnen gebruiken om netjes terug te kunnen laten schakelen naar thermostaat wellicht...

Bij hogere buitentemperaturen heeft mijn warmtepomp onvoldoende mogelijkheden om terug te moduleren...

[Proview]

hvxl schreef op donderdag 27 februari 2025 @ 20:47:
[...]

Het is inderdaad de bedoeling dat het zo werkt.

Heb je misschien de twee commando's met verschillende temperaturen getest? De Honeywell Chronotherm Touch heeft namelijk de vervelende beperking dat hij via Opentherm alleen op hele graden kan worden ingesteld. Als je bijvoorbeeld TT=19.5 hebt getest gaat het niet werken. Als je dan TC=20 test, werkt dat wel. Maar TT=20 zou ook moeten werken. Zo niet, dan kan een log meer duidelijkheid geven.

Dat was het inderdaad. Ik had kennelijk toevallig steeds getest met halve graden. Bij zowel TT als TC wordt de ingestelde temperatuur op de Chronotherm Touch dan naar beneden afgerond op hele graden. Het verschil daarbij is dat bij instellen van TC de (afgeronde) temperatuur wel vastgehouden wordt en bij TT niet. Stuur je enkel hele getallen, dan werkt het wel correct.
Als fix heb ik nu in home assistent ingesteld dat de OTGW thermostaat entity enkel in hele graden te verstellen is.

Ik vind het wel jammer, want ik zet regelmatig de temperatuur een halve graad lager of hoger. Wellicht kan iemand nog een goede thermostaat aanraden? Eén die goed compatibel is met de Remeha Avanta, OTGW en wel halve graden accepteert als override.

[hvxl]

TT en TC werken wat dat betreft precies hetzelfde. Dus ook bij TC met halve graden zal dat niet lang standhouden.

Bijvoorbeeld de Honeywell Chronotherm Modulation accepteert een setpoint override in hondersten van graden. Die kun je dus zelfs op 19.83 graden instellen, indien gewenst. Andere opties zijn te vinden in dit topic op het domoticaforum.

[Jpiek]

Ik heb een Remeha eTwist, werkt op zich heel aardig, kan wel halve graden. De draadloze die ik heb doet dan weer helaas geen waterdruk...
Die krijg ik ook niet via OTGW overigens... Al vermoed ik dat dat aan de regelunit van de warmtepomp ligt...

[hvxl]

Huh? Aan de equipment matrix te zien ondersteunt de eTwist helemaal geen remote setpoint override.

[JBS]

Even dubbelcheck: Ik heb m'n OTGW even losgekoppeld van de CV, betekent dat deze wel gewoon gevoed wordt en bereikbaar is op het IP adres. De debug pagina geeft aan dat MQTT connected is. Via MQTT Explorer zie ik deel van de topics om de seconde vernieuwd worden, maar in HA blijven de entiteiten 'Niet beschikbaar'.
Een losgekoppelde CV zou niet moeten betekenen dat HA ze niet als 'beschikbare entiteiten' ziet, toch?

[Jerra]

Zou eerder gaan kijken dan naar de HomeAssistant integratie zelf, connect die wel naar dezelfde mqtt broker?
Kun je op homeassitant niveau zelf inloggen om te zien of je op het netwerk met mosquitto_sub nog wel kan subscriben bijvoorbeeld?

[JBS]

Jerra schreef op vrijdag 28 februari 2025 @ 12:40:
Zou eerder gaan kijken dan naar de HomeAssistant integratie zelf, connect die wel naar dezelfde mqtt broker?
Kun je op homeassitant niveau zelf inloggen om te zien of je op het netwerk met mosquitto_sub nog wel kan subscriben bijvoorbeeld?

M'n MQTT broker is in orde, onder andere Zigbee2MQTT publiceert daar ook naar. Die data komt ook netjes in HA terecht.

Een specifieke integratie voor OTGW MQTT heb ik niet, hiervoor heb ik m'n Mosquitto MQTT broker.
Ik las elders in het topic dat deze 'offline' relevant is, maar wat die 'offline' nou feitelijk betekent, daar ben ik nog niet achter. De webinterface van de OTGW is namelijk bewoon bereikbaar.



\Edit: De OTGW nog maar eens opnieuw verbonden, en nu zie ik wel dat ie 'online' is en sommige entiteiten in HA zijn inmiddels ook beschikbaar. Het lijkt dan ook een algemeen connectie issue te zijn, hoewel ik geen problemen ervaar met het bezoeken van de webinterface.

[ Voor 12% gewijzigd door JBS op 28-02-2025 15:59 ]

[jwbokx]

Ik heb een otgw overgenomen met WiFi.
Maar bij eerste aansluiten lijkt er niets te gebeuren...

Het is een nodo v2 variant met WiFi module erop.
Horen er geen leds te gaan branden?
Ik ging er vanuit dat de WiFi in accespoint mode zou gaan als er geen verbinding gemaakt kan worden, maar ik zie geen bijzondere WiFi sid verschijnen...

Heeft iemand nog goede documentatie van versie 2?
Ik kan zo alleen de nieuwere vinden...
Op de nodo site wel van de WiFi afgehaald.
Daar staat ook in dat die in accespoint mode zou moeten gaan...
Als ik de WiFi alleen op mijn pc aansluit, hoor ik wel een signaal en de module geeft even een blauwe led.
Maar heb nog niet de driver geïnstalleerd.
Ga ik zo ook nog doen, dan weet ik ook welke firmware erop staat...

Nog dingen om te proberen?
Heb hier ook al gekeken https://otgw.tclcode.com/debugging.html
En ga zo ook even zien of ik daar verder mee kom..

[sjorsjuhmaniac]

JBS schreef op vrijdag 28 februari 2025 @ 15:51:
[...]
M'n MQTT broker is in orde, onder andere Zigbee2MQTT publiceert daar ook naar. Die data komt ook netjes in HA terecht.

Een specifieke integratie voor OTGW MQTT heb ik niet, hiervoor heb ik m'n Mosquitto MQTT broker.
Ik las elders in het topic dat deze 'offline' relevant is, maar wat die 'offline' nou feitelijk betekent, daar ben ik nog niet achter. De webinterface van de OTGW is namelijk bewoon bereikbaar.

[Afbeelding]

\Edit: De OTGW nog maar eens opnieuw verbonden, en nu zie ik wel dat ie 'online' is en sommige entiteiten in HA zijn inmiddels ook beschikbaar. Het lijkt dan ook een algemeen connectie issue te zijn, hoewel ik geen problemen ervaar met het bezoeken van de webinterface.

TLDR: is een semi-handmatige status indicatie. Het online bericht is handmatig, het offline bericht vaak automatisch. Lijkt dat otgw niet handmatig opnieuw 'online' published bij het opnieuw maken van een verbinding.

lang verhaal:

de online/offline die je in mqttexplorer ziet heeft met de gerapporteerde status van je device, in dit geval otgw, te maken.

Er wordt een status in een topic, published van de otgw, waar de online status wordt weergegeven. dat is programmatisch, een device kan dus volledig up en running zijn terwijl hij doodleuk de status offline published.
Dit is niet zo zinvol natuurlijk, maar kan gebeuren.
Het 'online' bericht wordt ook wel 'birth message' genoemd.

Vaak wordt dit echter ism een 'will message' gebruikt. Een onderdeel van het mqtt protocol is de mogelijkheid om bij het eerste contact maken met de mqtt server een 'will message' door te geven. Een 'will' is engels voor erfenis. De server zal bij het 'overlijden' van de verbinding de 'will' uitvoeren. Hier wordt dus vaak 'offline' doorgeven op het topic waar de status wordt bij gehouden.
Wordt de verbinding dan om wat voor reden ook verloren, dan veranderd de status automagisch naar 'offline'.

Nu de kicker: als er opnieuw verbinding wordt gemaakt, wordt 'offline' niet automatisch weer omgezet in online. Dit is zoals eerder benoemd een bewust gestuurd bericht vanuit het device. Als die niet 'weer' een birth-message stuurt blijft de status bij de broker ongewijzigd.

Dus birth-message is client side, will message is server side (maar alleen als de client dit heeft aangegeven bij het verbinding maken).

[jwbokx]

Blijkt dat voeding kapot is van de otgw die ik overgenomen heb.
Dus op zoek naar een andere.
Ik heb versie 2.0, dus 24V
Weet iemand nog dingen om op te letten?
1A genoeg om lang en stabiel te laten draaien?

[Refthoom]

jwbokx schreef op maandag 3 maart 2025 @ 09:58:
Blijkt dat voeding kapot is van de otgw die ik overgenomen heb.
Dus op zoek naar een andere.
Ik heb versie 2.0, dus 24V
Weet iemand nog dingen om op te letten?
1A genoeg om lang en stabiel te laten draaien?

Los daarvan, kun je de ESP die er op zit niet los testen? Daarmee kun je iig zien of er een AP verschijnt en kun je de wifi instellen.

[Gizz]

jwbokx schreef op maandag 3 maart 2025 @ 09:58:
Ik heb versie 2.0, dus 24V
Weet iemand nog dingen om op te letten?
1A genoeg om lang en stabiel te laten draaien?

Ik ken die versie niet, maar een OTGW verbruikt gewoonlijk bijna niks. Ook bij de versie mét ESP/Wifi (dus extra verbruik t.o.v. een kale OTGW) is een 5V/1A voeding meer dan voldoende; dat is de voeding die in deze webshop als bijpassend accessoire meebesteld kan worden.

De 24W voeding die je voorstelt lijkt me behoorlijke overkill. Van te weinig vermogen zul je in ieder geval geen last hebben

[Jpiek]

@Gizz @jwbokx Heeft het over een 24V voeding..

Wat me al een beetje bevreemde, aangezien het afaik om een USB Voeding gaat...

[Gizz]

@Jpiek dat hij het heeft over een 24V voeding weet ik. Daarom kwam ik op 24W uit bij de door hem voorgestelde 1A voeding (24V *1A)

Wat ik al zei, ik ken versie 2.0 niet. Ik ging ervan uit dat dit een oud ding is die nog niet met USB gevoed werd. Verder geen idee of dat klopt, als ik zoek op otgw 2.0 vind ik niet echt iets

[jwbokx]

De versie 2 is inderdaad nog met 24V gaat, niet met USB.
Is inderdaad een vroege versie.
Met een WiFi module die groter is.
Nu is het een mini.

Ik zag op de otgw site niet zo direct hoeveel stroom die nodig heeft.
Spanning is kennelijk wel kritisch.
Iets minder dan 24V en gaat uit.
Oude voeding was 23,1V en toen geen reactie.
Los de WiFi deed het wel

[jwbokx]

Gizz schreef op maandag 3 maart 2025 @ 10:53:
[...]

Ik ken die versie niet, maar een OTGW verbruikt gewoonlijk bijna niks. Ook bij de versie mét ESP/Wifi (dus extra verbruik t.o.v. een kale OTGW) is een 5V/1A voeding meer dan voldoende; dat is de voeding die in deze webshop als bijpassend accessoire meebesteld kan worden.

De 24W voeding die je voorstelt lijkt me behoorlijke overkill. Van te weinig vermogen zul je in ieder geval geen last hebben

Dat is een 5V dus gaat niet werken.
Is maar 5W, dan is inderdaad 1A bij 24V wel veel.
Deze ook https://www.nodo-shop.nl/...ersele-voeding-9-24v.html
Maar hoeft niet perse verschillende spanningen te kunnen...

[Gizz]

jwbokx schreef op maandag 3 maart 2025 @ 12:05:
[...]


Dat is een 5V dus gaat niet werken.

Het was niet mijn suggestie om een 5V voeding te gebruiken, maar ter indicatie voor hoe weinig een OTGW nodig heeft

De ESP in een OTGW verbruikt zo'n 200mA bij 3,3V. Daarnaast zijn er natuurlijk nog wat andere componenten. Maar niets dat veel vermogen vraagt.

[jwbokx]

Aah op zo'n manier.

Ik zag op Amazon 1 van 500mA voor net geen €10.
Maar weet niet hoe betrouwbaar die zijn...
Wel 2 jaar garantie, maar ja voor zoiets liefst 1 die zonder gedoe gewoon blijft werken.
Komt bij de CV, en is niet heel makkelijk bereikbaar

[visleeuw]

jwbokx schreef op maandag 3 maart 2025 @ 12:32:
Aah op zo'n manier.

Ik zag op Amazon 1 van 500mA voor net geen €10.
Maar weet niet hoe betrouwbaar die zijn...
Wel 2 jaar garantie, maar ja voor zoiets liefst 1 die zonder gedoe gewoon blijft werken.
Komt bij de CV, en is niet heel makkelijk bereikbaar

Het is misschien het snelst en zekerst om contact op te nemen met de Nodo shop https://www.nodo-shop.nl/nl/. Tenzij de OTGW volledig zelfbouw was, komt hij waarschijnlijk daar vandaan. Zij kunnen een betrouwbare voeding leveren, denk ik.

[jwbokx]

Heb er even een stroommeter tussen gehangen, rond de 30mA...
Maar nu geen cv of thermostaat aangesloten.
Thermostaat is alleen schakelen, dus zal niet zoveel toevoegen.
cv weet ik niet...

Is het normaal dat als de wifi op de otgw zit, de webpagina wel bereikbaar is, maar verder bij alles wat ik doe weer om wachtwoord vraagt?
Dus eventueel een wijziging submitten niet lukt?

[Dutchess_Nicole]

jwbokx schreef op maandag 3 maart 2025 @ 14:59:
Heb er even een stroommeter tussen gehangen, rond de 30mA...
Maar nu geen cv of thermostaat aangesloten.
Thermostaat is alleen schakelen, dus zal niet zoveel toevoegen.
cv weet ik niet...

Is het normaal dat als de wifi op de otgw zit, de webpagina wel bereikbaar is, maar verder bij alles wat ik doe weer om wachtwoord vraagt?
Dus eventueel een wijziging submitten niet lukt?

Nee, dat is niet normaal. Echter check wel even wat voor soort OTGW je hebt en welke firmware je erop hebt staan. Als je een type hebt met een wemos en de firmware van @number3 dan zou je namelijk helemaal geen login moeten hebben.

[jwbokx]

Oke...

Het password had ik zelf ingesteld, dus is niet zo gek.
Maar dat was met de wifi alleen aan de pc.
Daar ook al de laatste firmware op gezet.
Op zich is password niet heel erg nodig, maar doe het vaak wel bij alle spul op het netwerk.

Ik zag dat de wifi aangeeft nog maar heel kort aan te staan....
Kennelijk start die iedere keer opnieuw op...
Dus gaat iets nog niet echt lekker blijkbaar...

De firmware van de otgw staat als ik naar die pagina ga als de monitor met http server draait dat die niet bekend is...
Heb de laatste al klaar staan, ga die er ook eerst nog opzetten.
En met een goede voeding kijken wat die doet.
Die ik nu even gebruik, is max 24V, wel regelbaar zelfs de stroom, maar heeeel erg oud...
Wel al een jaar of 40 denk ik.... (Oh nu voel ik mij wel heel oud ineens..)
Dus kan zijn dat het nog steeds krap is, stroom is wel ruim voldoende.
Maar kennelijk is de 24V erg kritissch om het goed te laten werken...

[Refthoom]

jwbokx schreef op dinsdag 4 maart 2025 @ 16:42:

Ik zag dat de wifi aangeeft nog maar heel kort aan te staan....
Kennelijk start die iedere keer opnieuw op...
Dus gaat iets nog niet echt lekker blijkbaar...

Misschien nuttig te checken op brownouts, dat is een typische oorzaak van herstarts. Wordt er iets erg warm op de OTGW print en/of is de voedingsspanning van de ESP wel stabiel? Er kan iets zijn wat de oorspronkelijke voeding (uiteindelijk) de das om heeft gedaan, wat nu nog steeds speelt.

[jwbokx]

Er wordt niets warm nu, wat geweest is weet ik niet natuurlijk...
Maar was van een mede tweaker, en krijg deel geld terug nu voeding kapot blijkt.
Heb de 5v zitten meten bij de wifi module, is goed constant wel 4,97V.
Maar nu na wat testen en doen blijft de webpagina van de wifi ook gewoon stabiel en kan weer submitten terwijl die op de otgw zit.

Nu maar eens gaan kijken om de laatste otgw firmware erop te zetten.
Is wel opletten zag ik met versie (2.0) maar ook nog pic variant (16F88) dus moet gaan lukken.
Zag wel ergens staan dat firmware via wifi riskant is?
Klopt dat? en zo ja, hoe dan wel....
Er zit verder geen header op voor seriele verbinding...

[Refthoom]

jwbokx schreef op dinsdag 4 maart 2025 @ 20:56:
Maar was van een mede tweaker, en krijg deel geld terug nu voeding kapot blijkt.

Ik wilde niet suggereren dat je (bewust) getild was, bedoelde het meer in het licht van de leeftijd van de OTGW.

[hvxl]

jwbokx schreef op dinsdag 4 maart 2025 @ 16:42:
Maar kennelijk is de 24V erg kritissch om het goed te laten werken...

De 24V is niet erg kritisch voor de meeste functionaliteit. Alleen voor de detectie dat geen thermostaat is aangesloten moet de spanning op de thermostaat aansluiting hoog genoeg worden getrokken. Dat gaat met de 20V instelling van de universele voeding niet. Vandaar het advies om de voeding op 24V te zetten.

[hvxl]

jwbokx schreef op maandag 3 maart 2025 @ 14:59:
cv weet ik niet...

CV aansluiten heeft geen invloed op het stroomverbruik. De boiler interface is elektrisch gescheiden van de rest van de OTGW. Dat deel van het circuit wordt gevoed vanuit de ketel.

[Proview]

jwbokx schreef op maandag 3 maart 2025 @ 09:58:
Blijkt dat voeding kapot is van de otgw die ik overgenomen heb.
Dus op zoek naar een andere.
Ik heb versie 2.0, dus 24V
Weet iemand nog dingen om op te letten?
1A genoeg om lang en stabiel te laten draaien?

Ik heb dezelfde OTGW versie, gekocht via nodo shop. Daar werd toen een verstelbare voeding van max 24V - 1A bijgeleverd van het merk 'Nedis'. Dus 24V - 1A is zeker voldoende.

[jwbokx]

hvxl schreef op dinsdag 4 maart 2025 @ 22:22:
[...]


De 24V is niet erg kritisch voor de meeste functionaliteit. Alleen voor de detectie dat geen thermostaat is aangesloten moet de spanning op de thermostaat aansluiting hoog genoeg worden getrokken. Dat gaat met de 20V instelling van de universele voeding niet. Vandaar het advies om de voeding op 24V te zetten.

oke, tot nut oe leek het erop dat iets lager er voor zorgt dat de wifi niet of niet goed werkt.
Nu al een tijd aangestaan, en wifi pagina geeft nu wel een lange uptime aan.
Dus kennelijk geen reset meer tussendoor, dus wachtwoord scherm nu ook niet steeds na iedere submit...

[jwbokx]

Nog wel even over wat ik gelezen had...
Zag wel ergens staan dat firmware via wifi riskant is?
Klopt dat? en zo ja, hoe dan wel....
Er zit verder geen header op voor seriële verbinding...

[hvxl]

Ik weet niet precies wat je met "nodo v2 variant" bedoelt. De OTGW's die de nodo shop verkoopt zijn al tijden v2 varianten. De huidige versie is volgens mij v2.12.

Volgens mijn gegevens was v2.0 de laatste die met 24V moest worden gevoed en ook de laatste waar een NodeMCU op kon worden geprikt. Dus ik neem even aan dat je die hebt. Op die v2.0 zit een header gelabeld FTDI die kan worden gebruikt voor een seriële verbinding dmv een FTDI kabel. Je moet dan wel de RxP en TxP jumpers omzetten van ESP/LAN naar FTDI.

Ten tweede zitten er op een OTGW met NodeMCU 2 programmeerbare onderdelen(*): Een PIC en een ESP8266. Beide hebben ze hun eigen firmware. Welke firmware wil je gaan updaten? Een update van de ESP firmware kan gewoon via wifi. Daarna kun je de ESP een update van de PIC firmware laten doen. Dit is naar mijn mening de makkelijkste methode voor de standaard firmware.

Er zijn mensen die zeggen dat ze de PIC hebben gebrickt door een firmware update vanuit OTmonitor over wifi te doen waarbij de verbinding wegviel. Ik heb dat nooit kunnen reproduceren. Zelfs niet door moedwillig de stekker van de OTGW te trekken tijdens een upgrade. Ik doe dan ook zonder te twijfelen een update over wifi. Ik heb natuurlijk een PIC programmer. Dus als het mis gaat is het voor mij geen drama. Maar zoals gezegd, die heb ik nog nooit nodig gehad om te herstellen van een mislukte update.

(*)Ik vergeet voor het gemak even de ATtiny die op de v2.0 nog aanwezig was als externe WDT voor de ESP.

[jwbokx]

Oh, dat de versie zo liep had ik niet gelijk gezien...
Maar is inderdaad de versie 2.0. Met 24V voeding en inderdaad nodemcu op zit.

De header ftdi zit er helaas niet op...
Aangezien door mijn lichamelijke beperking van de laatste paar jaar lukt solderen niet meer, dus er zelf 1 opzetten gaat niet lukken. Als het zou moeten weet ik wel iemand die het voor me wilt doen, maar die zie ik niet wekelijks, dus zou even kunnen duren.

De nodemcu heb ik de laatste firmware al opgezet direct aan de pc gekoppeld omdat die niet zichtbaar werd in het WiFi netwerk. Bleek uiteindelijk helemaal niet te werken op de otgw vanwege voeding van otgw die niet goed blijkt te zijn.

Dus nu de PIC nog de16F88 variant, alles staat klaar ervoor. Maar zag die waarschuwing dus dacht nog even navragen wat ervaring is.
Ik heb geen pic programmer, dus op hoop van zegen dan maar...

[hvxl]

Als "de laatste firmware" van de nodemcu de firmware van @number3 is, dan kun je de PIC via een klik op de web GUI upgraden. Met die methode loop je niet het risico dat met een "upgrade over wifi" wordt bedoeld. In dat geval is het de ESP die de PIC programmeert. Een hik van de wifi heeft dan geen invloed op de upgrade.

[jwbokx]

Ik had de github van hem al gevonden, die firmware stond er nog niet op.
Nu wel, zo ook de PIC laatste firmware erop zetten....

[jwbokx]

Zo nu dus laatste firmware (0.10.3) van number3 en pic (16f88) op laatste versie (5.8)

Loopt nu stabiel, wachten op goede voeding en bij de cv gaan hangen.
Kijken of de openthem van onze atag cv... (A244ec hp) (zat origineel met een honywell round modulation)

[Gameboy]

Even een wellicht gekke vraag tussendoor:

Ik wil wellicht een keer over naar een warmtepomp om mijn woning te verwarmen. Die zou ik dan middels OT willen aansturen, met mogelijk een OTGW ertussen om het een en ander te monitoren en eventueel aan of bij te sturen vanuit HA.

Om alvast wat te oefenen en inzicht te krijgen, wil ik dan nu alvast mijn huidige HoneyWell/Resideo EvoHome koppelen met een R8810A OT module.

Die module heeft voeding nodig, en dat kan vanaf een OT device lijkt me

Ik heb de documentatie van de OTGW doorgenomen, en die kan stand-alone werken (zonder thermostaat direct aan de warmtebron), en als gateway (tussen thermostaat en warmtebron). Dat is logisch en duidelijk.

Echter, heeft iemand ooit al eens geprobeerd om de OTGW alleen aan een OT thermostaat te koppelen, zonder een OT warmtebron?

Zou dat werken om de Resideo R8810A RF module van geschikte voeding te voorzien zodat ik die kan toevoegen aan mijn EvoHome setup? Ik weet dat die dan niks kan en zal aansturen, maar puur voor de voorbereidingen en mijn eigen kennis ben ik benieuwd of dat uberhaubt zou werken

[Jpiek]

@Gameboy
Ik heb een soortgelijke setup nu draaien :

- Remeha etwist (eigenlijk bagger voor een warmtepomp)
- OTGW
- Homey OpenTherm Gateway MQTT
- Weheat Blackbird warmtepomp

ipv thermostaatgeregeld of de stooklijn van de Blackbird heb ik een Homey flow gemaakt die aan de hand van diverse gegevens bepaald wat de watertemperatuur (keteldoel temperatuur in OTGW) moet zijn om het huis te verwarmen.

Ik gebruik als parameters :

- buitentemperatuur (Via KMNI, en Homey weather, komt nog een echte sensor voor + evt uitlezing Outdoorsensor blackbird)
- gevraagde kamertemperatuur (uitgelezen uit de Remeha via een Homey koppeling)
- Gemeten kamertemperatuur (uitgelezen uit de Remeha via een Homey koppeling)
- Opwek van mijn panelen (die gebruik ik als bepaling hoeveel het huis door de zon opgewarmd wordt)

In HA zul je ongetwijfeld iets soortgelijks kunnen doen.
In een setup zonder CV of warmtepomp mis je echter het nodige aan sensoren/uit te lezen waardes, je hebt dan alleen wat gegevens van je thermostaat, en dat is afaik niet heel erg veel zonder CV of warmtepomp.

Maar wat weerhoud je om de OTGW tussen je thermostaat en je huidige CV te hangen ? Je kunt dan iig kijken wat je ongeveer zou kunnen doen/uitlezen, en je hóeft niets aan te sturen met de OTGW, je kunt ook puur monitoren..

[Gameboy]

Jpiek schreef op zondag 16 maart 2025 @ 11:49:
@Gameboy
Ik heb een soortgelijke setup nu draaien :

<Knip>

Maar wat weerhoud je om de OTGW tussen je thermostaat en je huidige CV te hangen ? Je kunt dan iig kijken wat je ongeveer zou kunnen doen/uitlezen, en je hóeft niets an te sturen met de OTGW, je kunt ook puur monitoren..

Ik heb nu nog helemaal geen warmtebron binnenshuis Ik heb stadsverwarming, dus ik heb alleen maar een zoneklep in de aanvoer naar de V.V. verdeler, en HR92 thermostaatknoppen op de radiatoren op de 1e verdieping. Geen ketelmodule of iets...

Er is dus nog helemaal geen OpenTherm apparaat waar ik iets aan kan koppelen, vandaar de vraag of de OTGW kan werken als master en voeding voor alleen een OT thermostaat (R8810A RF module).

[Jpiek]

Voeding in de zin van spanning moet de (Nodoshop) OTGW krijgen via een USB aansluiting.

Je kunt hem vast aansluiten op allen een thermostaat, maar je zult er echt maar heel beperkt wijzer van worden.
je zul denk ik alleen Ingestelde en kamertemperatuur zien, je thermostaat heeft geen ketel om mee te communiceren en dan wordt het erg stil...

maar heb je (specifieke vragen ?) Die kunnen we hier wellicht wél voor je beantwoorden...

[Gameboy]

Jpiek schreef op zondag 16 maart 2025 @ 17:10:
Voeding in de zin van spanning moet de (Nodoshop) OTGW krijgen via een USB aansluiting.

Je kunt hem vast aansluiten op allen een thermostaat, maar je zult er echt maar heel beperkt wijzer van worden.
je zul denk ik alleen Ingestelde en kamertemperatuur zien, je thermostaat heeft geen ketel om mee te communiceren en dan wordt het erg stil...

maar heb je (specifieke vragen ?) Die kunnen we hier wellicht wél voor je beantwoorden...

Mijn specifieke vraag is of de OTGW ook voeding geeft aan een OT thermostaat(-module) als de OTGW niet aan een OT ketel of WP hangt

Ik wil namelijk ook vooral het aantal schakelingen per uur van de EvoHome kunnen verlagen. Op dit moment is het minimum 3 schakelingen per uur, en dat kan niet lager als er geen Warmtepomp of OpenTherm module in het systeem bekend is als ketelmodule.

Met een WP of OT module zou dat naar 1 schakeling per uur kunnen volgens de docs, maar dat soort dingen wil ik dus kunnen testen.

Nu schakelt de zoneklep van de V.V. dus 3x per uur, en gaat dan voor een ~3 minuutjes aan (bij de huidige buitentemperaturen). Dat mag wat mij betreft naar 1x per uur even aan. De afgifte van de vloer is traag genoeg om dat te kunnen opvangen lijkt me.

Ik kan nu natuurlijk ook gewoon een BDR91T ketelmodule kopen die geschikt is voor warmtepompen, dan haal ik dat resultaat ook. Maar als ik de stap ga maken naar een warmtepomp, wil ik die hoogstwaarschijnlijk met OT aansturen, dus kan ik beter de R8810A OT module kopen lijkt me.

Maar die moet dus voeding hebben vanaf een OT apparaat, waarmee ik weer bij de vraagstelling ben.

[Jpiek]

Met voeding bedoel je dan neem ik aan of deze waardes doorgeeft ?

Helaas ben ik verder niet bekend met het aansturen van V.V. met een thermostaat of OTGW.

De gateway geeft vziw alleen ontvangen gegevens door, als er geen communicatie is met een WP of CV zal je dat ws.dus ook niet zien.

Maar dat is een wilde gok van mijn kant. Het spijt me als ik je niet verder kan helpen..

[Gameboy]

Jpiek schreef op maandag 17 maart 2025 @ 10:44:
Met voeding bedoel je dan neem ik aan of deze waardes doorgeeft ?

Helaas ben ik verder niet bekend met het aansturen van V.V. met een thermostaat of OTGW.

De gateway geeft vziw alleen ontvangen gegevens door, als er geen communicatie is met een WP of CV zal je dat ws.dus ook niet zien.

Maar dat is een wilde gok van mijn kant. Het spijt me als ik je niet verder kan helpen..

Nee, met voeding bedoel ik echt de daadwerkelijke spanning-/stroomvoorziening. De R8810A module bevat elektronica, en die moet stroom hebben om te kunnen werken. Er deze kan alleen met OT worden aangesloten, die ook de voeding van deze module voorziet.

Vandaar de vraag of de OTGW deze voeding kan voorzien als die niet op een warmtebron is aangesloten.

[Refthoom]

Gameboy schreef op maandag 17 maart 2025 @ 11:09:
[...]


Nee, met voeding bedoel ik echt de daadwerkelijke spanning-/stroomvoorziening. De R8810A module bevat elektronica, en die moet stroom hebben om te kunnen werken. Er deze kan alleen met OT worden aangesloten, die ook de voeding van deze module voorziet.

Vandaar de vraag of de OTGW deze voeding kan voorzien als die niet op een warmtebron is aangesloten.

Ik heb er ook geen ervaring mee maar dat kun je toch meten als de OTGW aanstaat? Of er op die pinnen naar de thermostaat een spanning staat, bedoel ik.

Mijn thermostaat kan ik overigens van batterijen voorzien, als backup. Weet niet of dat een oplossing zou zijn voor wat jij wil proberen. Heeft die van jou die mogelijkheid?

Ik herken overigens je behoefte wel. Een standaard kamer thermostaat gebruiken heeft o.a. als voordeel dat er een algoritme is voor hysterese en control setpoint wat je dan niet zelf in je domotica hoeft op te nemen. Maar je ketel moet wel een acknowledge sturen voor de door de thermostaat verzonden command's (OT protocol). En als die er niet aan hangt zul je daar iets voor moeten verzinnen anders gaat het niet werken vermoed ik.

[Gameboy]

Refthoom schreef op maandag 17 maart 2025 @ 11:41:
[...]

Ik heb er ook geen ervaring mee maar dat kun je toch meten als de OTGW aanstaat? Of er op die pinnen naar de thermostaat een spanning staat, bedoel ik.

Mijn thermostaat kan ik overigens van batterijen voorzien, als backup. Weet niet of dat een oplossing zou zijn voor wat jij wil proberen. Heeft die van jou die mogelijkheid?

Ik herken overigens je behoefte wel. Een standaard kamer thermostaat gebruiken heeft o.a. als voordeel dat er een algoritme is voor hysterese en control setpoint wat je dan niet zelf in je domotica hoeft op te nemen. Maar je ketel moet wel een acknowledge sturen voor de door de thermostaat verzonden command's (OT protocol). En als die er niet aan hangt zul je daar iets voor moeten verzinnen anders gaat het niet werken vermoed ik.

Ik heb ook nog geen OTGW, die wil ik pas gaan kopen als ik een positief antwoord heb op mijn vraag

De R8810A is overigens geen thermostaat, maar slechts een RF module om het EvoHome paneel met een OT apparaat te kunnen laten praten. Er kunnen geen batterijen in, de voeding moet via de OT terminals komen.

[Refthoom]

Gameboy schreef op maandag 17 maart 2025 @ 13:33:
[...]


Ik heb ook nog geen OTGW, die wil ik pas gaan kopen als ik een positief antwoord heb op mijn vraag

De R8810A is overigens geen thermostaat, maar slechts een RF module om het EvoHome paneel met een OT apparaat te kunnen laten praten. Er kunnen geen batterijen in, de voeding moet via de OT terminals komen.

In de OT documentatie staat ergens de spanning van de lijn. Op https://otgw.tclcode.com/ staat bij de uitleg van de componenten ook iets over die lijnspanning, als ik me goed herinner. Die spanning zou je kunnen aanbieden op de draden waarmee die R8810A normaliter aan een OT ketel hangt maar dan kun je nog weinig meten denk ik. De hardware van de OTGW is er nou juist voor om de signalen van die hogere spanning naar een niveau te brengen waar een MCU niet kapot van gaat. Of begrijp ik je vraag verkeerd?

[Gameboy]

Refthoom schreef op maandag 17 maart 2025 @ 14:57:
[...]

In de OT documentatie staat ergens de spanning van de lijn. Op https://otgw.tclcode.com/ staat bij de uitleg van de componenten ook iets over die lijnspanning, als ik me goed herinner. Die spanning zou je kunnen aanbieden op de draden waarmee die R8810A normaliter aan een OT ketel hangt maar dan kun je nog weinig meten denk ik. De hardware van de OTGW is er nou juist voor om de signalen van die hogere spanning naar een niveau te brengen waar een MCU niet kapot van gaat. Of begrijp ik je vraag verkeerd?

Mja, ik lees idd iets over een nominale lijnspanning van ergens tussen 15 en 24 Volt, en dat lijkt DC te zijn. Bij communicatie wordt dat door de sender omlaag gebracht naar rond de 6 Volt als ik het goed lees.

Dan zou ik normaliter denken dat een voeding van 6 - 12 V DC voldoende zou kunnen zijn om de electronica te voeden.

Well, dank voor de inputs iig, ik ga eens dubben of ik dit experiment aan ga. Het slopen van zo'n module is zonde ;P

[Refthoom]

Gameboy schreef op dinsdag 18 maart 2025 @ 08:26:
[...]


Mja, ik lees idd iets over een nominale lijnspanning van ergens tussen 15 en 24 Volt, en dat lijkt DC te zijn. Bij communicatie wordt dat door de sender omlaag gebracht naar rond de 6 Volt als ik het goed lees.

Dan zou ik normaliter denken dat een voeding van 6 - 12 V DC voldoende zou kunnen zijn om de electronica te voeden.

Well, dank voor de inputs iig, ik ga eens dubben of ik dit experiment aan ga. Het slopen van zo'n module is zonde ;P

Ik heb even gekeken bij mijn opstelling. Dit zijn de DC waarden die ik heb gemeten.
OTGW <--> CVketel = 6V gemeten op een gesloten lus
Thermostaat <--> OTGW = 24V gemeten op een open lus

[Gameboy]

Refthoom schreef op dinsdag 18 maart 2025 @ 13:21:
[...]

Ik heb even gekeken bij mijn opstelling. Dit zijn de DC waarden die ik heb gemeten.
OTGW <--> CVketel = 6V gemeten op een gesloten lus
Thermostaat <--> OTGW = 24V gemeten op een open lus

Ah, dank! Dus ergens tussen 6 V en 24 V zou dus moeten werken. Nou ja in ieder geval de electronica zou dan aan moeten gaan en blijven. Wat er dan uit komt is nog maar de vraag...

[jwbokx]

Hier nu alles actief.
Zal onze ketel (ATAG A244EC HP) ook nog doorgeven, staat niet in de lijst bij https://otgw.tclcode.com/matrix.cgi#boilers

Ik gebruik ook homeassistant en heb de standaard integratie aanstaan.
Had eerst even mqtt aan staan, zodat ik in mqtt explorer kon zien of het werkte.
Die kwamen eerst ook in HA gelijk te staan. Maar voorlopig vind ik de standaard integratie wat makkelijker en beter te overzien.
Wat gebruiken de HA mensen hier meestal?
Zijn er voordelen aan het gebruik van mqtt?

Moet nog kijken hoe ik de buitentemperatuur nu ook door ga geven, de ketel heeft daar ook ondersteuning voor.

Ik zie ook sensor voor centrale verwarming 2, watertemperatuur staat op 255...
Wat is daar de bedoeling van? Of gewoon negeren aangezien we maar 1 cv hebben...

[Djvdb]

Hi allen,

Sinds gisteren OTGW via homeassistant draaien op een Techneco ELGA icm een honeywell modulation touch. Echter bij het aanpassen van het setpoint veranderd er niks en slaat de warmtepomp niet aan. Ik heb al gezocht in het topic maar kan de oplossing niet vinden. Hieronder de log. Heeft iemand enig idee hoe dit is op te lossen?

code:

07:03:43.318624 (  16072| 15400) addOTWGcmdto(1214): CmdQueue: Adding cmd end of queue, slot [0]
07:03:43.321549 (  14728| 14104) addOTWGcmdto(1217): CmdQueue: Insert queue in slot[0]:cmd[TT=22.0] (7)
07:03:43.322937 (  14728| 14104) addOTWGcmdto(1237): CmdQueue: Next free queue slot: [1]
07:03:44.863981 (  14728| 14104) fwreportinfo(1967): Callback: fwreportinfo
07:03:44.865917 (  13384| 12808) fwreportinfo(1970): Current firmware version: 5.8
07:03:44.867082 (  13384| 12808) fwreportinfo(1972): Current device id: pic16f88
07:03:44.867826 (  13384| 12808) fwreportinfo(1975): Current firmware type: gateway
07:03:44.868703 (  13384| 12808) processOT   (1701): Current firmware version: 5.8
07:03:44.869495 (  13384| 12808) processOT   (1703): Current device id: pic16f88
07:03:44.870189 (  13384| 12808) processOT   (1705): Current firmware type: gateway
07:03:44.062666 (  14056| 13456) processOT   (1676): Boiler            BE0190000 (9)[MsgID= 25][DATA_INVALID    ] Tboiler = 0.00 °C
07:03:44.157969 (  14056| 13456) processOT   (1676): Thermostat        T00090000 (9)[MsgID=  9][READ_DATA       ] TrOverride = 0.00 °C
07:03:44.187192 (  13384| 12808) processOT   (1676): Boiler            BF0090000 (9)[MsgID=  9][UNKNOWN_DATA_ID ]-TrOverride = 0.00 °C <ignored> 
07:03:44.355442 (  16072| 15400) handleOTGWqu(1253): CmdQueue: Queue slot [0] due
07:03:44.357591 (  14728| 14104) sendOTGW    (1343): Sending to Serial [TT=22.0] (7)
07:03:44.403622 (  14728| 14104) fwreportinfo(1967): Callback: fwreportinfo
07:03:44.405482 (  13384| 12808) fwreportinfo(1970): Current firmware version: 5.8
07:03:44.406648 (  13384| 12808) fwreportinfo(1972): Current device id: pic16f88
07:03:44.407431 (  13384| 12808) fwreportinfo(1975): Current firmware type: gateway
07:03:44.408326 (  13384| 12808) processOT   (1701): Current firmware version: 5.8
07:03:44.409117 (  13384| 12808) processOT   (1703): Current device id: pic16f88
07:03:44.409818 (  13384| 12808) processOT   (1705): Current firmware type: gateway
07:03:45.040110 (  12752| 12304) processOT   (1676): Answer Thermostat AC0090000 (9)[MsgID=  9][READ_ACK        ]>TrOverride = 0.00 °C
07:03:45.134324 (  13384| 12808) processOT   (1676): Thermostat        T00000000 (9)[MsgID=  0][READ_DATA       ]>Status = Master [-----W--]
07:03:45.595100 (  13384| 12808) processOT   (1676): Boiler            BC0000000 (9)[MsgID=  0][READ_ACK        ]>Status = Slave  [--------]
07:03:45.715111 (  14056| 13456) processOT   (1676): Thermostat        T00090000 (9)[MsgID=  9][READ_DATA       ] TrOverride = 0.00 °C
07:03:46.740299 (  14056| 13456) processOT   (1676): Boiler            BF0090000 (9)[MsgID=  9][UNKNOWN_DATA_ID ]-TrOverride = 0.00 °C <ignored> 
07:03:46.152656 (  13384| 12808) processOT   (1676): Answer Thermostat AC0090000 (9)[MsgID=  9][READ_ACK        ]>TrOverride = 0.00 °C
07:03:46.248219 (  14056| 13456) processOT   (1676): Thermostat        T80640000 (9)[MsgID=100][READ_DATA       ] RoomRemoteOverrideFunction = flag8 = [00000000] - decimal = [  0]
07:03:46.268846 (  14056| 13456) processOT   (1676): Boiler            B70640000 (9)[MsgID=100][UNKNOWN_DATA_ID ]-RoomRemoteOverrideFunction = flag8 = [00000000] - decimal = [  0] <ignored> 
07:03:47.081426 (  14728| 14104) processOT   (1676): Answer Thermostat A40640000 (9)[MsgID=100][READ_ACK        ]>RoomRemoteOverrideFunction = flag8 = [00000000] - decimal = [  0]
07:03:47.099495 (  13384| 12808) processOT   (1676): Thermostat        T10010A00 (9)[MsgID=  1][WRITE_DATA      ]>TSet = 10.00 °C
07:03:47.265366 (  14056| 13456) processOT   (1676): Boiler            BD0010A00 (9)[MsgID=  1][WRITE_ACK       ] TSet = 10.00 °C
07:03:47.361534 (  13384| 12808) processOT   (1676): Thermostat        T90101300 (9)[MsgID= 16][WRITE_DATA      ]>TrSet = 19.00 °C

[JBS]

JBS schreef op vrijdag 28 februari 2025 @ 15:51:
[...]
M'n MQTT broker is in orde, onder andere Zigbee2MQTT publiceert daar ook naar. Die data komt ook netjes in HA terecht.

Een specifieke integratie voor OTGW MQTT heb ik niet, hiervoor heb ik m'n Mosquitto MQTT broker.
Ik las elders in het topic dat deze 'offline' relevant is, maar wat die 'offline' nou feitelijk betekent, daar ben ik nog niet achter. De webinterface van de OTGW is namelijk bewoon bereikbaar.

[Afbeelding]

\Edit: De OTGW nog maar eens opnieuw verbonden, en nu zie ik wel dat ie 'online' is en sommige entiteiten in HA zijn inmiddels ook beschikbaar. Het lijkt dan ook een algemeen connectie issue te zijn, hoewel ik geen problemen ervaar met het bezoeken van de webinterface.

In het verlengde hiervan: M'n OTGW hangt al eventjes zonder verbonden CV. Vlakbij een WiFi accesspoint en de WiFi verbinding is in orde volgens de OTGW webpagina log.

Toch blijf ik veel entiteiten als 'Unavailable' houden, ondanks dat de webpagina gewoon netjes bereikbaar is en blijft, en de MQTT connected status 'true' is.

'Lege' Home page:



MQTT Connected: True.
PIC Available: True.





Wemos al eens opnieuw geflashed, tevens met een nieuwe Wemos geprobeerd. Beide hetzelfde resultaat.

@number3 Kun jij bevestigen of dit normaal is en e.e.a. gewoon zou moeten werken, ook al is er geen CV verbonden, of dat ik moet denken richting een overleden OTGW?

-------------------------------------------------------

@Djvdb Wordt MsgID 9 wel ondersteund met die combinatie? Als ik je combinatie check op https://otgw.tclcode.com/details.cgi heeft '9' '✖ The boiler does not recognise or does not support the data ID'.

[ Voor 137% gewijzigd door JBS op 01-04-2025 20:13 ]