[OTGW] OpenTherm gateway

[sjorsjuhmaniac]

martinvdm schreef op zondag 28 februari 2021 @ 17:21:
[...]

Ok dan ik jou voorbeeld dus niet gebruiken? en moet ik dus een mqtt climate in HA bouwen met het juiste command_topic welke dus de OTGW serial commands stuurt middels /command

Juist. Je kan mijn voorbeeld wel 'gebruiken' en alleen de topics vervangen scheelt weer werk.

Let op: templating op command topics werkt niet zoals verwacht, in mijn tests.

Ik heb bv het volgende geprobeerd:

code:

temperature_command_template: "TT={{ value }}"

Maar HA vind t niet tof dat er nog iets voor de {{ staat. Ik heb ook nog wel andere dingen geprobeerd maar kwam er niet uit. Je kan het wel oplossen door naar volledige ander topic te pushen, bv OTGW/mooihoor zonder een template te gebuiken, je krijgt hier dan gewoon de value direct op binnen.
Vervolgens kan je een automation maken die subscribed op dat topic, OTGW/mooihoor, en de via template de waarde pakt, samenvoegt met TT= en dat weer naar een nieuw topci , OTGW/command, pushed.

Werkt wel, is niet mooi

[martinvdm]

sjorsjuhmaniac schreef op zondag 28 februari 2021 @ 17:27:
[...]


Juist. Je kan mijn voorbeeld wel 'gebruiken' en alleen de topics vervangen scheelt weer werk.

Let op: templating op command topics werkt niet zoals verwacht, in mijn tests.

Ik heb bv het volgende geprobeerd:

code:

temperature_command_template: "TT={{ value }}"

Maar HA vind t niet tof dat er nog iets voor de {{ staat. Ik heb ook nog wel andere dingen geprobeerd maar kwam er niet uit. Je kan het wel oplossen door naar volledige ander topic te pushen, bv OTGW/mooihoor zonder een template te gebuiken, je krijgt hier dan gewoon de value direct op binnen.
Vervolgens kan je een automation maken die subscribed op dat topic, OTGW/mooihoor, en de via template de waarde pakt, samenvoegt met TT= en dat weer naar een nieuw topci , OTGW/command, pushed.

Werkt wel, is niet mooi

Thanks voor de info. Ik heb hem nu zo gebouwd en dat lijkt prima te werken.

YAML:

  - platform: mqtt
    name: "Thermostaat"
    min_temp: 14
    max_temp: 28
    initial: 21 
    current_temperature_topic: "OTGW/Tr"
    temperature_command_topic: "OTGW/command"
    temperature_command_template: "TT={{ value }}"
    temp_step: 0.5
    precision: 0.5
    modes:
      - "off"
      - "heat"
    mode_state_topic: "OTGW/ch_enable"
    mode_state_template: >
      {% if value == 'ON' %}heat{% else %}off{% endif %}

Weet alleen niet zeker of ik het current_temperature_topic juist heb, maar iig lijkt de temparature_command incl de template wel goed te werken.

[sjorsjuhmaniac]

martinvdm schreef op zondag 28 februari 2021 @ 18:09:
[...]

Thanks voor de info. Ik heb hem nu zo gebouwd en dat lijkt prima te werken.

YAML:

  - platform: mqtt
    name: "Thermostaat"
    min_temp: 14
    max_temp: 28
    initial: 21 
    current_temperature_topic: "OTGW/Tr"
    temperature_command_topic: "OTGW/command"
    temperature_command_template: "TT={{ value }}"
    temp_step: 0.5
    precision: 0.5
    modes:
      - "off"
      - "heat"
    mode_state_topic: "OTGW/ch_enable"
    mode_state_template: >
      {% if value == 'ON' %}heat{% else %}off{% endif %}

Weet alleen niet zeker of ik het current_temperature_topic juist heb, maar iig lijkt de temparature_command incl de template wel goed te werken.

wtf... werkt die template bij jou wel?.... kreeg hem bij mij er niet mee aan de praat.

[martinvdm]

sjorsjuhmaniac schreef op zondag 28 februari 2021 @ 18:12:
[...]


wtf... werkt die template bij jou wel?.... kreeg hem bij mij er niet mee aan de praat.

ja hoor zie hem netjes in MQTT explorer voorbij komen

[sjorsjuhmaniac]

martinvdm schreef op zondag 28 februari 2021 @ 18:12:
[...]

ja hoor zie hem netjes in MQTT explorer voorbij komen

Tr is wel de goede overigens, ID 24. Die moet je hebben.

[martinvdm]

Er lijkt nog wel ergens een issue tussen MQTT en deze sensors te zitten:
Low Water Pressure
Gas/Flame Fault

De Web interface van de OTGW geeft namelijk ON aan, en MQTT staat op Off, en dus HA ook.
Lijkt erop dat deze sensor waardes niet goed middels MQTT gepublished worden.

[sjorsjuhmaniac]

martinvdm schreef op zondag 28 februari 2021 @ 18:43:
Er lijkt nog wel ergens een issue tussen MQTT en deze sensors te zitten:
Low Water Pressure
Gas/Flame Fault

De Web interface van de OTGW geeft namelijk ON aan, en MQTT staat op Off, en dus HA ook.
Lijkt erop dat deze sensor waardes niet goed middels MQTT gepublished worden.

er was vorige week een comment dat de webinterface juist iets verkeerd aangaf/niet refresht. Weet je zeker dat de webinterface de juist waarde aangeeft? in je voorbeeld zou je dus juist een storing moeten hebben ...

[MrBarBarian]

sjorsjuhmaniac schreef op zondag 28 februari 2021 @ 17:09:
[...]


Klopt, dat voorbeeld komt uit py-otgw-mqtt. Dat project heeft standaard geen HA discovery maar er is een pull request dat niet gemerged is wat die functionaliteit wel toevoegd. In dat geval krijg je een device (otgw) met daaronder al je sensoren en een thermostaat. Dat project heeft ook voor de meest gebruikte setting een apart topic waar je gewoon simpel de value naartoe kan pushen (daarnaast ook een 'raw' command topic overigens).

Deze, nav jouw tip in het HA-topic, gister eens geinstalleerd. Maar volgens mij is de gehele TCP-ondersteuning (nog) niet aanwezig?

[sjorsjuhmaniac]

Ooh... ik moet je eerlijk zeggen dat ik dat nooit geprobeerd heb ik heb alleen maar OTGW's met de wifi module en dan gebuik je het 'serial' stuk van de code. Heb me totaal niet gerealiseerd dat je met een lan aansluiting het TCP stuk nodig hebt... sorry.

Ik zie wel een heel stuk voor TCP maar geen idee hoe goed dat geimplementeerd is.

[ Voor 14% gewijzigd door sjorsjuhmaniac op 05-03-2021 11:18 ]

[MrBarBarian]

sjorsjuhmaniac schreef op vrijdag 5 maart 2021 @ 11:18:
Ooh... ik moet je eerlijk zeggen dat ik dat nooit geprobeerd heb ik heb alleen maar OTGW's met de wifi module en dan gebuik je het 'serial' stuk van de code. Heb me totaal niet gerealiseerd dat je met een lan aansluiting het TCP stuk nodig hebt... sorry.

Ik zie wel een heel stuk voor TCP maar geen idee hoe goed dat geimplementeerd is.

Dat zag ik ook, maar als je in die code kijkt zie je vooral veel NotYetImplemented

[number3]

De 9e release van Nodoshop OTGW Firmware (voor de NodeMCU), release v0.8.0.

Opgelet dit is een breaking change voor MQTT integratie met homeassistant.

De release vast de volgende functies:

• breaking change: aangepaste mqtt naming conventie for otgw topics
• toegevoegd: otgw als een device en sensors nu gegroepeerd onder 1 device
• toegevoegd: climate (thermostaat) entity, incl. temperatuur aanpassing
• toegevoegd: override (middels het TT command) - vanaf HA Core v2021.2.0+)
• nieuwe restapi - een eenvoudig json array voor simpele integratie met telegraf (/api/v1/otgw/telegraf)
• fix voor core ot message processing (asf flags en oem code related)
• fix voor GH issue #14 - watchdog reset indien MQTT timeout (>5 sec)
• fix voor ASF flas in web UI (restapi otmonitor)
• toegevoegd een LLMNR voor verbeterde integratie met windows en linux (nu naar: http://otgw/)

Shoutout naar :

• @sjorsjuhmaniac (voor zijn inspanning om de homeassistant integratie te verbeteren)
• @Martinvdm & @tjfsteele (voor eindeloos geduld bij het testwerk en remote debugging ondersteuning)

De release is hier te vinden:
https://github.com/rvdbre...mware/releases/tag/v0.8.0

Veel plezier. Net als altijd, issues en pullrequest zijn welkom via Github. Verder kan me vinden op Discord.

[ Voor 6% gewijzigd door number3 op 07-03-2021 11:25 . Reden: lijstje mooi maken ]

[sjorsjuhmaniac]

@number3

[Mich]

@number3

Zou ik dit ook op een of andere manier werkend kunnen krijgen op een nodeMCU met een ethernet shield er op? Mijn wifi op zolder is kantje boord. Daarom ben ik al over gegaan naar een USR-TCP232-T2 (serieel naar utp) module.

[martinvdm]

Mich schreef op zondag 7 maart 2021 @ 19:43:
@number3

Zou ik dit ook op een of andere manier werkend kunnen krijgen op een nodeMCU met een ethernet shield er op? Mijn wifi op zolder is kantje boord. Daarom ben ik al over gegaan naar een USR-TCP232-T2 (serieel naar utp) module.

Denk niet dat de ondersteuning van de ethernet module in deze firmware zit.

[Bo0bz]

Op een of andere manier krijg ik via de OTGW niet de juiste buitentemperatuur meer door. Op de warmtepomp staat dat het nu 1.5 graden is maar m'n OTGW geeft al uren 5,4 graden aan. Ook op de thermostaat staat 5.4. Heb al even de OTGW van de stroom afgehaald maar dat heeft niet geholpen. Draai de meegeleverde firmware vanuit nodoshop 4.2.5. Iemand een tip?

[sjorsjuhmaniac]

Bo0bz schreef op dinsdag 9 maart 2021 @ 07:04:
niet [...] meer door

Wat is er veranderd?

zit de sensor nog goed aangesloten? Verandert de waarde uberhaupt door de dag heen?

[Bo0bz]

sjorsjuhmaniac schreef op dinsdag 9 maart 2021 @ 08:34:
[...]


Wat is er veranderd?

zit de sensor nog goed aangesloten? Verandert de waarde uberhaupt door de dag heen?

De waarde veranderd helemaal niet meer. Sinds ik mijn domoticz heb overgezet naar een Linux systeem. De andere waarden uit de otgw veranderen wel iedere x minuten zoals het hoort. De sensor kan ik ook uitlezen op mijn warmtepomp en die doet het wel. Iedere keer als ik de otgw even uit en aan komt er een nieuwe waarde maar dus niet uit zichzelf. Als ik de otgw er tussen uit haal leest mijn thermostaat wel de juiste waarde uit.

[sjorsjuhmaniac]

Bo0bz schreef op dinsdag 9 maart 2021 @ 08:40:
[...]


De waarde veranderd helemaal niet meer. Sinds ik mijn domoticz heb overgezet naar een Linux systeem. De andere waarden uit de otgw veranderen wel iedere x minuten zoals het hoort. De sensor kan ik ook uitlezen op mijn warmtepomp en die doet het wel. Iedere keer als ik de otgw even uit en aan komt er een nieuwe waarde maar dus niet uit zichzelf. Als ik de otgw er tussen uit haal leest mijn thermostaat wel de juiste waarde uit.

Dat is heel apart. Domoticz heeft geen invloed op data van de otgw naar thermostaat tenzij je echt commando's stuurt om bepaalde data ID's tegen te houden.

We kunnen proberen of het DATA id misschien even handmatige opgevraagd moet worden om het aan de gang te krijgen. Kun je eens het volgende commando naar de otgw sturen

code:

AA=27

, kijken of je dan binnen 15min wel goede data krijgt te zien.

Kan ook OTMonitor eens draaien? Als je die start moet je wel even de otgw op disabled zetten in Domoticz->hardware omdat ze anders vechten wie de verbinding mag hebben en houden.
Zie je de juiste buiten temp in OTMonitor?

[Bo0bz]

@sjorsjuhmaniac ik ga zo even pielen. Eerst een meeting in. Kom er bij je op terug :-)

EDIT: Command net verstuurd en de temp wijzigt naar 5.8. Even checken of hij blijft bijwerken.
EDIT2: Temp inmiddels 6.2. Het lijkt dus nu wel te werken!

[ Voor 48% gewijzigd door Bo0bz op 09-03-2021 10:06 ]

[bluewalk]

Hier al jaren gebruiker van de OTGW (eerste generatie + ESP-01 met esp-link) altijd goed gewerkt maar de laatste tijd krijg ik erg vaak dat het ding niet respond en dus niet verwarmd of simpelweg niet stopt met verwarmen omdat de gateway communicatie kwijt is.

Wat ik vervolgens kan doen om het op te lossen in de Reference Voltage verhogen of verlagen. Daarna zijn de errors weer een tijdje over (soms een week/maand maar ook soms maar een dag).

Error 03 -> VR=3 -> OK
Daarna weer Error 03 -> VR=6 -> OK
en vice versa met allerlij voltages daar tussenin.

Iemand anders ervaring hiermee, wordt het tijd voor een nieuwe?

[sjorsjuhmaniac]

Bo0bz schreef op dinsdag 9 maart 2021 @ 09:16:
@sjorsjuhmaniac ik ga zo even pielen. Eerst een meeting in. Kom er bij je op terug :-)

EDIT: Command net verstuurd en de temp wijzigt naar 5.8. Even checken of hij blijft bijwerken.
EDIT2: Temp inmiddels 6.2. Het lijkt dus nu wel te werken!

Zie het nu pas maar dat het gewerkt heeft

[Bo0bz]

@sjorsjuhmaniac wat nog wel vreemd blijft is dat op de thermostaat zelf nog steeds de temperatuur blijft hangen. Op de warmtepomp en de OTGW gaat het wel goed. Daar toevallig ook een tip voor?

[stuffer]

Bo0bz schreef op zaterdag 13 maart 2021 @ 09:30:
@sjorsjuhmaniac wat nog wel vreemd blijft is dat op de thermostaat zelf nog steeds de temperatuur blijft hangen. Op de warmtepomp en de OTGW gaat het wel goed. Daar toevallig ook een tip voor?

Gaat dat over de buitentemp? Dat heb ik op de iSense ook gehad maar door de OTGW settings in Domoticz op de juiste temperatuur sensor te te zetten of even geforceerd een ander aan te kiezen en weer terug loste het op.

[Bo0bz]

@stuffer er ging gelijk een belletje rinkelen haha. Inderdaad stond de OTGW temp sensor op user build-in. Nu omgezet en het werkt weer!

[1870henk]

Communicatie fout met iSense F203.

Na een aantal pogingen om OTGW i.c.m. een iSense aan de gang te krijgen, bleek er uiteindelijk een fout op de Nodo print te zitten: R6 was aan 1 kant los, waar die normaal aan R5/pin17 moet zitten.
Nadat ik met een beetje solderen dit weer aan elkaar kreeg, werkte de iSense perfect.
Ik heb nog eens goed naar de Nodo print gekeken en het lijkt er op dat er ook helemaal geen printspoortje loopt naar R6. Die zit alleen maar aan GND.

Ik kwam hier al volgt achter:
tussen IC1-pin17 en X1-pin1 moet 4k7 zijn (dit was dus enkele Mohms)
tussen IC1-pin17 en X1-pin2 moet 33k zijn

[number3]

@1870henk heb je dat ook aan Nodoshop laten weten? Want het kan een productie fout zijn, dat wil hij vast weten.

[Racer89]

Hopelijk kan ik hier terecht met mijn vraag, ik zou niet weten waar ik deze anders moet neer zetten.

Sinds ongeveer 2 weken heb ik één OTGW in elkaar gezet en er tussen geplaatst. Ook mede om te kijken of de ketel moduleert. Dit werkt ook allemaal perfect, was wel een beetje ellende om de juiste drivers te vinden voor de USB kabel ( voor te testen rechtstreeks op de laptop ). Uiteindelijk is de OTGW aangesloten op de RPI i.c.m. Domoticz.

Nu ben ik in het bezit van een Honeywell CMT937M1003 Modulation. Deze is aangesloten op een Bosch HRC30. Ik heb een hele hoop handleidingen gelezen en het zou mogelijk zijn om op de Honeywell rechtsreeks een buitenvoeler aan te sluiten en deze te gebruiken als weersafhankelijke regeling. Vol goede moed een buitenvoeler aangeschaft en aangesloten. En wat blijkt ik kom met geen ene mogelijkheid in het installateurs menu..... Natuurlijk niet v.t.v. getest of ik er wel in kom. ( achter af ben je altijd slimmer, domme fout van mezelf... ) Parameter 10 zou ik de voeler moeten activeren maar ik kom niet verder dan 6. Ik kan verder ook totaal niks aanpassen of veranderen.


Zelf heb ik al getest / geprobeerd:

# OTGW er tussen uit, en thermostaat rechtsreeks op de ketel.
# Andere OT printplaat in de ketel geplaatst ( heb een reserve HRC30 liggen )
# Bedrading nagekeken, dit is allemaal zo ver in orde.

Meet nu ongeveer 17,8 Kohm op de voeler met een buiten temperatuur van 9 tot 10 graden. Helaas kan ik nergens vinden wat deze zou moeten zijn.

Wat ik me nu afvraag, heeft de ketel zo veel invloed op de thermostaat dat deze de menu's blokkeert?

[sjorsjuhmaniac]

Racer89 schreef op vrijdag 2 april 2021 @ 16:45:
Hopelijk kan ik hier terecht met mijn vraag, ik zou niet weten waar ik deze anders moet neer zetten.

Sinds ongeveer 2 weken heb ik één OTGW in elkaar gezet en er tussen geplaatst. Ook mede om te kijken of de ketel moduleert. Dit werkt ook allemaal perfect, was wel een beetje ellende om de juiste drivers te vinden voor de USB kabel ( voor te testen rechtstreeks op de laptop ). Uiteindelijk is de OTGW aangesloten op de RPI i.c.m. Domoticz.

Nu ben ik in het bezit van een Honeywell CMT937M1003 Modulation. Deze is aangesloten op een Bosch HRC30. Ik heb een hele hoop handleidingen gelezen en het zou mogelijk zijn om op de Honeywell rechtsreeks een buitenvoeler aan te sluiten en deze te gebruiken als weersafhankelijke regeling. Vol goede moed een buitenvoeler aangeschaft en aangesloten. En wat blijkt ik kom met geen ene mogelijkheid in het installateurs menu..... Natuurlijk niet v.t.v. getest of ik er wel in kom. ( achter af ben je altijd slimmer, domme fout van mezelf... ) Parameter 10 zou ik de voeler moeten activeren maar ik kom niet verder dan 6. Ik kan verder ook totaal niks aanpassen of veranderen.


Zelf heb ik al getest / geprobeerd:

# OTGW er tussen uit, en thermostaat rechtsreeks op de ketel.
# Andere OT printplaat in de ketel geplaatst ( heb een reserve HRC30 liggen )
# Bedrading nagekeken, dit is allemaal zo ver in orde.

Meet nu ongeveer 17,8 Kohm op de voeler met een buiten temperatuur van 9 tot 10 graden. Helaas kan ik nergens vinden wat deze zou moeten zijn.

Wat ik me nu afvraag, heeft de ketel zo veel invloed op de thermostaat dat deze de menu's blokkeert?

Probeer eens
https://customer.honeywel...nts/69-0000s/69-1812D.pdf

of
https://www.klusidee.nl/F...neywell-modulation.45532/

[Racer89]

@sjorsjuhmaniac bedankt voor je reactie, helaas is dat voor een vision icm een touchscreen. Ik heb een ander type met ander menu opbouw.

[remco_k]

@Racer89
Je kan als alternatief zelf de buitentemperatuur doorgeven via de OTGW.
Ik dacht met OT=
OTGW geeft 'm vervolgens door naar je Honeywell.

Bij mijn Chronotherm Vision i.c.m. exact dezelfde ketel als jij hebt werkt dat prima.

[Racer89]

remco_k schreef op zaterdag 3 april 2021 @ 09:49:
@Racer89
Je kan als alternatief zelf de buitentemperatuur doorgeven via de OTGW.
Ik dacht met OT=
OTGW geeft 'm vervolgens door naar je Honeywell.

Bij mijn Chronotherm Vision i.c.m. exact dezelfde ketel als jij hebt werkt dat prima.

Bedankt voor je reactie, dit had ik al getest en werkt ook. Alleen hangt de buitenvoeler van Domoticz niet op het noorden. De nieuwe voeler heb ik nu wel op het noorden gehangen. Probleem is echter dat ik dan alsnog niet weersafhankelijk kan regelen. Dat moet ook via de parameters worden ingesteld.

Ik was al aan het kijken voor een andere thermostaat waar ook de voeler op werkt. En deze lijkt ook geschikt te zijn voor de Vision of de Touch. Heb jij ook het oudere model bosch met het groene display ?

[pingwim]

Racer89 schreef op zaterdag 3 april 2021 @ 10:06:
[...]


Bedankt voor je reactie, dit had ik al getest en werkt ook. Alleen hangt de buitenvoeler van Domoticz niet op het noorden. De nieuwe voeler heb ik nu wel op het noorden gehangen. Probleem is echter dat ik dan alsnog niet weersafhankelijk kan regelen. Dat moet ook via de parameters worden ingesteld.

Ik was al aan het kijken voor een andere thermostaat waar ook de voeler op werkt. En deze lijkt ook geschikt te zijn voor de Vision of de Touch. Heb jij ook het oudere model bosch met het groene display ?

Of haal de buitentemperatuur op via bijvoorbeeld OpenWeatherMap api. Scheelt gedoe met de buitenvoeler, nauwkeuriger en biedt mogelijkheden als "gevoelstemperatuur".

[remco_k]

Racer89 schreef op zaterdag 3 april 2021 @ 10:06:
[...]
Heb jij ook het oudere model bosch met het groene display ?

Ja.

[Racer89]

Via MP een TH8210M1003 (Modulation touch) kunnen kopen, en hierop werkt de buitenvoeler wel en kan ik ook weersafhankelijk regelen. Ik zie nu ook alle parameters staan.

Snap alleen nog altijd niet waarom de gewone modulation niet werkt. Aangezien het allemaal wel zou moeten kunnen volgens de handleiding.

Alleen zie ik de buiten temperatuur nog niet terug via de OTGW, maar even afwachten...

[1870henk]

@number3. Goed idee. Dat heb ik inmiddels gedaan.

[guus.assmann]

Hallo,
Niet per sé een OTGW vraag, maar toch wel een beetje.
Ik heb een Remeha Quinta28C met een gateway en een Celcia20 thermostaat.
Daar kan de OTGW aan worden gekoppled.
Maar ik heb sinds kort ook een ZentaSol boiler en een remote display.

De vraag is nu, of ik ongestraft die systemen via dezelfde busaansluitingen aan elkaar kan verbinden.
Dit maakt namelijk de bekabeling veel eenvoudiger.
Met name de kabel van de zolder naar de thermostaat is de lastige factor. Die is nu maar 2 aderig.

[1870henk]

Ik gebruik een OT commando om de buitentemp. van Openwheathermap naar de OTGW te sturen. Dat werkt keurig.
Toen besloot ik om een tempsensor aan te sluiten op de GPIO pinnen. Vervolgens de GPIO functies ingesteld.
In de OTmonitor was de waarde van outside temp nu de temp van het return water en return water temp was leeg. Vreemd, maar OK.
Ik moest natuurlijk nog een TS=R commando sturen. Dat veranderde echter niets.
Toen opnieuw OT commando gestuurd en toen kreeg ik weer de juiste buitentemp. Maar nog steeds niks op de return temp.

Ik krijg de sensor nu niet meer aan de praat.
Ik begrijp dat OTGW niet 2 sensoren kan lezen, maar het OT commando heeft toch niets met de GPIO te maken (dacht ik)?
OK, als de sensor nog op TS=O staat EN ik stuur een waarde met OT, dan wordt de waarde overschreven.
Maar als ik gewoon TS=R geef dan zou die toch op return water iets moeten laten zien.

Nog iets:
Ik heb een Nodo print en daar zitten maar 4 LED's op. In de OTmonitor staan echter 6 LED's, dus ook op de pinnen die voor GPIO gebruikt worden.
Kan het zijn dat de pinnen van LED E en F aangestuurd worden terwijl daar ook de GPIO voor de sensor op zit?

[Martidjen]

Voor degenen die de Opentherm Gateway gebruiken in combinatie met de climate entity van de standaard Opentherm Gateway integratie in Home Assistant:

Ik heb een wijziging gedaan aan de opties voor de integratie in Home Assistant, sinds de april update 2021.4.0 zijn deze beschikbaar geworden.



Vanaf nu is de optie voor temperatuur precisie verdeeld in lees- en schrijf precisie. Oftewel, het uitlezen van de huidige temperatuur kan met een andere precisie gedaan worden dan de stapgrootte van het instellen van een nieuwe temperatuur setpoint.

Ook heb ik een optie voor 'Temporary Setpoint Override Mode' toegevoegd. Als deze optie is ingeschakeld dan zal het temperatuur commando voor Temporary Temperature gebruikt worden bij het instellen van een nieuwe temperatuur (ook wel bekend als TT=), als deze optie niet is ingeschakeld zal het commando voor Constant Temperature gebruikt worden (TC=).

Zie hier de Home Assistant Docs voor de Opentherm Gateway integratie: https://www.home-assistant.io/integrations/opentherm_gw/

[bluewalk]

number3 schreef op zondag 7 maart 2021 @ 02:09:
De 9e release van Nodoshop OTGW Firmware (voor de NodeMCU), release v0.8.0.

Opgelet dit is een breaking change voor MQTT integratie met homeassistant.

De release vast de volgende functies:

• breaking change: aangepaste mqtt naming conventie for otgw topics
• toegevoegd: otgw als een device en sensors nu gegroepeerd onder 1 device
• toegevoegd: climate (thermostaat) entity, incl. temperatuur aanpassing
• toegevoegd: override (middels het TT command) - vanaf HA Core v2021.2.0+)
• nieuwe restapi - een eenvoudig json array voor simpele integratie met telegraf (/api/v1/otgw/telegraf)
• fix voor core ot message processing (asf flags en oem code related)
• fix voor GH issue #14 - watchdog reset indien MQTT timeout (>5 sec)
• fix voor ASF flas in web UI (restapi otmonitor)
• toegevoegd een LLMNR voor verbeterde integratie met windows en linux (nu naar: http://otgw/)

Shoutout naar :

• @sjorsjuhmaniac (voor zijn inspanning om de homeassistant integratie te verbeteren)
• @Martinvdm & @tjfsteele (voor eindeloos geduld bij het testwerk en remote debugging ondersteuning)

De release is hier te vinden:
https://github.com/rvdbre...mware/releases/tag/v0.8.0

Veel plezier. Net als altijd, issues en pullrequest zijn welkom via Github. Verder kan me vinden op Discord.

Valt deze ook te flashen op een ESP serial tranciever boardje, denk aan: https://nl.aliexpress.com/item/32673603743.html

[_jap_]

1870henk schreef op woensdag 14 april 2021 @ 15:08:
Ik gebruik een OT commando om de buitentemp. van Openwheathermap naar de OTGW te sturen. Dat werkt keurig.
Toen besloot ik om een tempsensor aan te sluiten op de GPIO pinnen. Vervolgens de GPIO functies ingesteld.
In de OTmonitor was de waarde van outside temp nu de temp van het return water en return water temp was leeg. Vreemd, maar OK.
Ik moest natuurlijk nog een TS=R commando sturen. Dat veranderde echter niets.
Toen opnieuw OT commando gestuurd en toen kreeg ik weer de juiste buitentemp. Maar nog steeds niks op de return temp.

Hier een soortgelijke situatie - ik heb hier een 18B20 op de retourwaterleiding geplakt en die aan m'n OTGW gehangen, en met de nieuwste firmware meet-ie die temperatuur en stuurt dat naar de thermostaat door. De buitentemperatuur (die ik met OT= erin schiet) wordt nu helaas niet meer over de bus verstuurd, en verschijnt niet meer op het display van de thermostaat.

Volgens mij is het een bugje in de firmware dat dit niet werkt (ik ben er ooit eens vluchtig doorheen gegaan, en had het idee dat voor de buitentemperatuur en de retourwatertemperatuur hetzelfde stukje geheugen gebruikt wordt), maar ik ben niet diep genoeg erin gedoken om een fix in te typen. Misschien met het lange koningsweekend voor de boeg een leuk project, tussen al het andere door

[1870henk]

_jap_ schreef op vrijdag 23 april 2021 @ 09:29:
[...]


Hier een soortgelijke situatie - ik heb hier een 18B20 op de retourwaterleiding geplakt en die aan m'n OTGW gehangen, en met de nieuwste firmware meet-ie die temperatuur en stuurt dat naar de thermostaat door. De buitentemperatuur (die ik met OT= erin schiet) wordt nu helaas niet meer over de bus verstuurd, en verschijnt niet meer op het display van de thermostaat.

Volgens mij is het een bugje in de firmware dat dit niet werkt (ik ben er ooit eens vluchtig doorheen gegaan, en had het idee dat voor de buitentemperatuur en de retourwatertemperatuur hetzelfde stukje geheugen gebruikt wordt), maar ik ben niet diep genoeg erin gedoken om een fix in te typen. Misschien met het lange koningsweekend voor de boeg een leuk project, tussen al het andere door

Als ik TS=R stuur, dan krijg ik via OTmonitor wel de buitentemp binnen via OT. Als ik TS=O stuur dan wordt de temp via OT overschreven door de sensor.
Ik heb een Remeha Avanta en die meet zelf de return water temp. Na het sturen van AA=28 zie ik die nu ook in de OTmonitor.
Het lukt niet om de externe sensor te gebruiken voor de return water temp. Hopelijk een oplosbaar bugje.

Ik heb ook al eens door de code gescand, maar ik moet er weer even aan wennen. PIC's programmeren is voor mij al weer zo'n 30 jaar geleden.

[bprak]

Helaas heeft mijn WiFi otgw het begeven door een lekkage. Is er een thermostaat die rechtstreeks werkt met domoticz? Of iemand toevallig een otgw over die via WiFi werkt?

[Jeroen1985vag]

Gebruik Plugwise Anna onder domoticz ook ondersteund en zeer tevreden over

[vanenkelen]

Ik heb een vraag die enige jaren geleden ook al eens gesteld is, maar voor zover ik het goed doorgelezen en doorzocht heb nog niet is beantwoord. Mocht ik het antwoord over het hoofd gezien hebben, mijn excuses :-).

Templar schreef op zondag 29 november 2015 @ 20:44:
[...]
Is het een idee om naast de 24 V laagspannings-connector Bus tbv de stekkertrafo ook een (optionele) 24 V schroefklem-locatie op het PCB aan te brengen? Mijn Intergas ketel heeft namelijk een optionele 24 V 2VA aansluiting tbv een klokthermostaat. Ik neem aan dat zulke aansluitingen gebruikt kunnen worden voor het voeden van de OTGW?

Mijn Intergas HReco 36 ketel heeft op Connector X4 op aansluitingen 6 en 7 de mogelijkheid een "Aan/uit kamerthermostaat en/of vorstthermostaat (24Vdc of ± 125mA)" te verbinden. Is het mogelijk om deze aansluitingen te gebruiken om de OTGW te voeden? Of raakt de ketel hierdoor in de war omdat hij denkt dat er een aan/uit thermostaat is aangesloten? Is dit een (verstandige) optie, of gewoon lekker een externe voeding gebruiken?

Update:
Ik had de vraag ook gesteld aan de Nodo Shop en van hen inmiddels een antwoord gekregen. Ik zal die voor eventuele andere geïnteresseerden hier ook even terugkoppelen.

Hun advies/antwoord is dat dit niet mogelijk/verstandig is. Los van het feit of het verstandig is omdat de aansluitingen bedoeld zijn voor een On/Off thermostaat, is in mijn geval de +/- 125 mA aan de krappe kant om de OTGW te kunnen voeden.

[ Voor 41% gewijzigd door vanenkelen op 24-06-2021 09:17 ]

[vanenkelen]

Heeft iemand ervaring met het aansluiten van een DS-18B20 Temperatuur Sensor op de Opentherm Gateway van Nodo-Shop?

Ik heb hem aangesloten, maar na een tijdje (minuut ongeveer) gaat een ledje op de OTGW rood branden en lijkt de communicatie te stoppen naar Domoticz. Sensor afkoppelen en otgw opnieuw opstarten en het werkt weer.

Daarnaast hoe zorg ik er voor dat ik de waarden van die sensor doorkrijg in Domoticz, ben het spoor even kwijt 🤪.

[Racer89]

@vanenkelen Ik heb de sensors wel op de raspberry aangesloten. Hier moeten een weerstand tussen. Ik weet niet of dat ook op de OTGW moet ?

[vanenkelen]

Racer89 schreef op zondag 4 juli 2021 @ 20:13:
@vanenkelen Ik heb de sensors wel op de raspberry aangesloten. Hier moeten een weerstand tussen. Ik weet niet of dat ook op de OTGW moet ?

Ja, ik heb de instructie op http://otgw.tclcode.com/peripherals.html gevolgd en een 4k7 weerstandje geplaatst tussen pootje 2 en 3 van de SV3 connector op de OTGW. Als het goed is zijn dat pootje 15 en 16 (RA7 en RA6) op de PIC16F88P. Op het oog heb ik die op de juiste plek op het printje gesoldeerd. Vervolgens de sensor volgens specs (GND, Data en VCC) aangesloten.

Ik zou graag van iemand horen die het ook heeft gedaan en het werkend heeft gekregen, ook qua configuratie in de OTGW zelf en in Domoticz.

[PimW]

Afgelopen weekend heb ik de Opentherm Gateway via de nodo-shop.nl besteld, inclusief de NodeMCU, behuizing en voeding. Op de NodeMCU heb ik de NodeMCU OTGW Firmware gezet. Deze verzorgt de communicatie naar Home Assistant via MQTT.

Mijn verdere 'setup' is:
Ketel: Ferroli MegaDens 3 222
Thermostaat: Honeywell Round Modulation T87M1003

De setup werkt vlekkeloos, ik ben er heel tevreden mee. Binnen Home Assistant heb ik het zodanig ingesteld, dat:

• Het automatische stookschema alleen actief is/wordt als er mensen thuis zijn en niet slapen (bewegingsdetectoren)
• Het automatische stookschema houdt in: ochtends 18,5 graden, middag 19,5 graden, avond 20,5 graden, late avond/nacht 19,5 graden.
• Als niemand thuis is of iedereen slaapt, dan gaat de thermostaat naar 15 graden.

Bovendien wordt het automatische stookschema volledig stopgezet zodra op de 'ouderwetse' manier via de thermostaat de temperatuur wordt ingesteld. Het automatische stookschema wordt dan pas weer actief wanneer een de volgende situaties optreedt:

• Direct onder de thermostaat heb ik een Ikea Tradfri Snelkoppelknop gemonteerd. Wanneer je hier op drukt, wordt het automatische stookschema weer actief.
• Het automatische stookschema wordt automatisch actief rond 4:00 's nachts (waarbij wordt geconstateerd dat iedereen slaapt en de verwarming dus niet aangaat ).
• Iedereen gaat slapen
• Iedereen is van huis

Door het op deze manier in te stellen, heb ik drie grote voordelen gecreëerd:

• Het systeem past zich aan op de mens, niet andersom, want: geen weekschema's. Weekschema's ervaar ik als hopeloos ouderwets: een mens is geen robot die iedere dag strak op dezelfde tijd thuis is, weg is, wakker is, gaat slapen. Door betrouwbare presence en slaap detectie (dus niet alleen door verbonden te zijn met je mobiel op wifi, maar ook door beweginsgdetectie) past het systeem zich aan op de mens.
• Automatische temperatuuraanpassing gedurende de dag (ochtend koeler, avond warmer)
• Eenvoud voor jong en oud! Bij handbediening van de ouderwetse thermostaat probeert het systeem niet 'slim' te doen door de handmatige stand te overriden. Op de thermostaat kan ik altijd direct aflezen of de automatische of de handmatige stand actief is. Wil ik weer terug naar automatisch? Prima, gewoon even op de Tradfri knop drukken.

Allicht geeft dit wat inspiratie voor anderen. Ik ben ook heel benieuwd welke oplossingen de mede-tweakers hier bedacht hebben?

[DRAFTER86]

PimW schreef op woensdag 14 juli 2021 @ 23:47:
Afgelopen weekend heb ik de Opentherm Gateway via de nodo-shop.nl besteld, inclusief de NodeMCU, behuizing en voeding. Op de NodeMCU heb ik de NodeMCU OTGW Firmware gezet. Deze verzorgt de communicatie naar Home Assistant via MQTT.

Mijn verdere 'setup' is:
Ketel: Ferroli MegaDens 3 222
Thermostaat: Honeywell Round Modulation T87M1003

De setup werkt vlekkeloos, ik ben er heel tevreden mee. Binnen Home Assistant heb ik het zodanig ingesteld, dat:

• Het automatische stookschema alleen actief is/wordt als er mensen thuis zijn en niet slapen (bewegingsdetectoren)
• Het automatische stookschema houdt in: ochtends 18,5 graden, middag 19,5 graden, avond 20,5 graden, late avond/nacht 19,5 graden.
• Als niemand thuis is of iedereen slaapt, dan gaat de thermostaat naar 15 graden.

Bovendien wordt het automatische stookschema volledig stopgezet zodra op de 'ouderwetse' manier via de thermostaat de temperatuur wordt ingesteld. Het automatische stookschema wordt dan pas weer actief wanneer een de volgende situaties optreedt:

• Direct onder de thermostaat heb ik een Ikea Tradfri Snelkoppelknop gemonteerd. Wanneer je hier op drukt, wordt het automatische stookschema weer actief.
• Het automatische stookschema wordt automatisch actief rond 4:00 's nachts (waarbij wordt geconstateerd dat iedereen slaapt en de verwarming dus niet aangaat ).
• Iedereen gaat slapen
• Iedereen is van huis

Door het op deze manier in te stellen, heb ik drie grote voordelen gecreëerd:

• Het systeem past zich aan op de mens, niet andersom, want: geen weekschema's. Weekschema's ervaar ik als hopeloos ouderwets: een mens is geen robot die iedere dag strak op dezelfde tijd thuis is, weg is, wakker is, gaat slapen. Door betrouwbare presence en slaap detectie (dus niet alleen door verbonden te zijn met je mobiel op wifi, maar ook door beweginsgdetectie) past het systeem zich aan op de mens.
• Automatische temperatuuraanpassing gedurende de dag (ochtend koeler, avond warmer)
• Eenvoud voor jong en oud! Bij handbediening van de ouderwetse thermostaat probeert het systeem niet 'slim' te doen door de handmatige stand te overriden. Op de thermostaat kan ik altijd direct aflezen of de automatische of de handmatige stand actief is. Wil ik weer terug naar automatisch? Prima, gewoon even op de Tradfri knop drukken.

Allicht geeft dit wat inspiratie voor anderen. Ik ben ook heel benieuwd welke oplossingen de mede-tweakers hier bedacht hebben?

Begrijp ik goed dat je zowel vanuit Home Assistant als op je Honeywell thermostaat een temperatuur setpoint kan opgeven? Weet de Honeywell thermostaat het ook als je je setpoint vanuit Home Assistant stuurt? En zou dat ook werken met een Tado?

[PimW]

Dat klopt: als de temperatuur vanuit Home Assistant wordt doorgegeven aan de OpenTherm Gateway, wordt een remote override room setpoint ingesteld en teruggekoppeld aan de thermostaat. Op de thermostaat is dit op twee manieren zichtbaar: 1) er wordt linksonderin een huisje zichtbaar 2) als je aan de ring draait, zie je de nieuw ingestelde temperatuur.

Op de website van de opentherm gateway wordt een matrix bijgehouden van ondersteunde thermostaten en ketels: https://otgw.tclcode.com/matrix.cgi#thermostats

Bij deze specifieke feature gaat het om message_id 9 (Remote override room setpoint). Vanuit de matrix lijkt het erop dat deze feature niet ondersteund wordt door de Tado thermostaat. Maar allicht dat anderen (of Google) hands-on ervaring met deze combinatie hebben?

Edit: om je andere deel van de vraag te beantwoorden: via de thermostaat kan ik de room setpoint ook instellen. Daarmee gaat de "Remote override room setpoint" automatisch terug naar 0. Dit laatste gebruik ik als herkenningspunt in Home Assistant om de handmatige stand actief te laten en de automatische stand inactief te laten.

[ Voor 19% gewijzigd door PimW op 18-07-2021 21:05 ]

[Dutchess_Nicole]

Ik heb vorige week een OTGW binnengekregen van nodo-shop. Erbij heb ik de NodeMCU besteld en natuurlijk een PSU. Vandaag heb ik de laatste onderdelen binnengekregen en de boel aangesloten.

Helaas lijkt het niet helemaal te werken. De NodeMCU werkt en de basic webinterface doet het. Daarmee heb ik dus mijn wifi ingesteld en dat gaat goed.
Tevens het instellen van MQTT werkt prima, HA heeft de topics herkend en mijn entities gemaakt.
Climate device bestaat dus prima.

Echter wat niet werkt is de daadwerkelijke communicatie met de thermostaat en boiler.
Beiden blijven staan op not connected:

code:

Thermostate connected false
Boiler connected false
Pic connected false

en volgens dit overzicht is dus ook de PIC zelf niet aangesloten.
Ik snap niet helemaal hoe dit kan.

Volgens de nodo-shop specificaties zou de PIC voorgeprogrammeerd zijn?
Maar als ik dus in de NodeMCU interface kijk dan zie ik geen versienummer van de PIC voorbij komen

code:

Developer Robert van den Breemen
NodeMCU Firmware Version 0.8.5+dc3dc14 (30-06-2021)
OTGW PIC Firmware Version No version found
Compiled on (date/time) Jun 30 2021 21:56:59
HostName OTGW-NodeMCU

Is dit iets waarvoor ik terug zou moeten naar nodo-shop denken jullie?
Ik zou de debug steps wel willen doorlopen maar die lijken nog gebaseerd te zijn op een heel oud model OTGW die ik dus niet heb: ik heb de V2 WIFI uitvoering.

[number3]

@Dutchess_Nicole vervelend om te horen dat je problemen hebt met het werkend krijgen van de OTGW met mijn firmware.

Als er berichten binnenkomen binnen 30 seconden na het opstarten van OTGW dan trekt de firmware de conclusie dat de boiler of thermostaat offline zijn.

Dat duidt op dat je de stekkers mogelijk verkeerd aangesloten hebt.

Vraag: Zie je wel elke paar seconde de groene led knipperen?

Je bent van harte welkom op de Discord waar ik uithang om het te bespreken. Discord uitnodiging: https://discord.gg/zjW3ju7vGQ

Groet
Robert

[Dutchess_Nicole]

number3 schreef op zaterdag 24 juli 2021 @ 22:43:
@Dutchess_Nicole vervelend om te horen dat je problemen hebt met het werkend krijgen van de OTGW met mijn firmware.

Als er berichten binnenkomen binnen 30 seconden na het opstarten van OTGW dan trekt de firmware de conclusie dat de boiler of thermostaat offline zijn.

Dat duidt op dat je de stekkers mogelijk verkeerd aangesloten hebt.

Vraag: Zie je wel elke paar seconde de groene led knipperen?

Je bent van harte welkom op de Discord waar ik uithang om het te bespreken. Discord uitnodiging: https://discord.gg/zjW3ju7vGQ

Groet
Robert

Er komen helemaal geen berichten binnen als ik de otmonitor log mag geloven.
Ik zie wel idd de blauwe led die als heartbeat van de nodemcu dient en elke seconde knippert de tweede groene led twee keer.
Maar buiten dat dus geen indicatie dat er ook maar iets gebeurt.

edit:

Ben even op discord wezen babbelen en er miste nog een setje jumpers. Blijkbaar is die PIC niet standaard aangesloten aan de datalijnen van de nodemcu en moet je dat handmatig doen met jumpers.

Dus na het insolderen van de jumperheaders en het oprakelen van wat oude jumpers werkl het nu idd.

[ Voor 14% gewijzigd door Dutchess_Nicole op 25-07-2021 12:04 ]

[Dutchess_Nicole]

1870henk schreef op donderdag 1 april 2021 @ 14:38:
Communicatie fout met iSense F203.

Na een aantal pogingen om OTGW i.c.m. een iSense aan de gang te krijgen, bleek er uiteindelijk een fout op de Nodo print te zitten: R6 was aan 1 kant los, waar die normaal aan R5/pin17 moet zitten.
Nadat ik met een beetje solderen dit weer aan elkaar kreeg, werkte de iSense perfect.
Ik heb nog eens goed naar de Nodo print gekeken en het lijkt er op dat er ook helemaal geen printspoortje loopt naar R6. Die zit alleen maar aan GND.

Ik kwam hier al volgt achter:
tussen IC1-pin17 en X1-pin1 moet 4k7 zijn (dit was dus enkele Mohms)
tussen IC1-pin17 en X1-pin2 moet 33k zijn

Ik heb nu dus ook deze communicatie fout met mijn iSense en de OTGW. F203 op de iSense, en de OTGW krijgt geen packets binnen van de thermostaat.

Apart is ook dat ik op het moment de thermostaat wel heb aangesloten en de boiler niet (die doet het nu goed), maar de nodeMCU geeft aan dat de thermostaat niet is aangesloten en de boiler wel...

Gezien het feit dat ik geen schema heb van de print (schijnbaar ligt de site waar die op zou staan plat?)

Klopt het dan dat ik die 4.7kOhm tussen rood en groen zou moeten zien, en 33kOhm tussen rood en blauw?



If so, dan is het bordje denk ik niet goed want ik heb 1kOhm tussen rood en groen en 20kOhm tussen rood en blauw

[1870henk]

Schema staat gewoon op http://otgw.tclcode.com/schematic.html#schematic
m.u.v. seriële interface (max232) en voeding is dat gelijk aan de Nodo versie.
Inderdaad tussen rood-groen en tussen rood-blauw
1k en 20k weerstand is niet juist.
Heb je dat goed gemeten, dus de print op een geïsoleerd oppervlak?
Misschien lukt het om R5 los te solderen aan de kant van R6 en dan de waarde te meten.
smd solderen vergt enige voorzichtigheid; niet te lang heet stoken.

[number3]

@dunklefaser je kan ook even contact opnemen met Nodoshop. Het kan ook zijn dat dit een productie fout is, en dan is het handig als je dat even met Remco (eigenaar van Nodoshop) checkt.

Gr.
Robert

[dunklefaser]

number3 schreef op zondag 25 juli 2021 @ 16:30:
@dunklefaser je kan ook even contact opnemen met Nodoshop. Het kan ook zijn dat dit een productie fout is, en dan is het handig als je dat even met Remco (eigenaar van Nodoshop) checkt.

Gr.
Robert

Ik denk dat je @Dutchess_Nicole bedoelde.

[number3]

Yep, foutje 🙈

[Dutchess_Nicole]

1870henk schreef op zondag 25 juli 2021 @ 15:02:
Heb je dat goed gemeten, dus de print op een geïsoleerd oppervlak?

Het lijkt me niet nuttig om dat in een aquarium te doen, nee. Het is gewoon in de lucht gemeten uiteraard.

Wederom was ik ff op discord gegaan om de boel na te vragen en zoals het altijd gaat, toen ik de boel nog eens aansloot en terugkwam van met de hond lopen werkte het.. Go figure.

Ik ben overigens best bekend met regulier solderen maar SMD spul waag ik me niet aan... Ik heb zeker niet de vaste hand die nodig is om daarmee om te gaan.

Thanks idd voor het schema. ik heb de weerstanden gevonden.

[1870henk]

OK, dan werkt het blijkbaar ook met 1k en 20k weerstanden.
Mogelijk moet je dan Vref nog aanpassen.

[DYM]

Wolfram55 schreef op vrijdag 29 december 2017 @ 11:29:
Hoe pas ik de frequentie aan die de json/mqtt verstuurd ...... ?

Nu is dat bij bv controlsetpoint alleen als hij verandert. Ik wil het zeg maar om de 5s/1s of zo hebben.
Wil eea in grafana via node-red doen en dat geeft rara sprongen waar ik niks aan heb nu.

code:

web {
  enable true
  port 8080
  nopass true
  sslport 0
  graphlegend false
  theme default
  sslprotocols tls1,tls1.1,tls1.2
  certonly false
}
connection {
  type tcp
  enable true
  port 23
  host 192.168.1.130
  device {}
}
server {
  enable true
  port 7686
  relay true
}
mqtt {
  enable true
  broker 192.168.1.15
  port 1883
  devicetype central_heating
  deviceid otmonitor
  format simple
  retransmit 10
  qos 1
  keepalive 120
  messages true
  client otgw-vm
  username {}
  password {}
}

Dit is mijn otmonitor.conf die ik aanroep.
Berichten komen aan maar alleen als de waardes zich wijzigen .... is dat normaal ?

Verder zie ik qos 1 staan maar als ik via MQTTfx kijk zie ik de qos op 0 staan ??
In esp-link kan ik de qos niet instellen ....

Wie-o-wie duwt me in de goeie richting


Edit: solved ..... trigger-node in Node-Red

Ik probeer de otgw data nu via mqtt, mosquitto en telegraf in influxdb te krijgen. Voorheen deed ik dat met de 'bijmij-otmonitor-influxdb.py' oplossing en dat werkte perfect maar ik wil alle software vernieuwen en krijg deze 'bijmij-oplossing' niet meer aan de gang.

Nu geeft mosquitto netjes alle waarden van de otgw weer maar ik zie in influxdb alleen nieuwe data komen als ik het vinkje 'mqtt' in otmonitor even uit- en weer aanzet.
Uit bovenstaande verhaal begrijp ik dat ik otmonitor moet triggeren maar hoe? Ik gebruik geen Nod-Red maar alleen mosquitto en telegraf.

otgw firmware 4.2.5
otmonitor 5.1
mosquitto 1.6.15 (in docker)
telegraf latest (in docker)

Kan iemand mij verder helpen?

[Dutchess_Nicole]

Ik heb net de OTGW werkend via MQTT en op zich werkt het prima zoals het standaard is.
Het enige is dat je idd zoals je zelf al aangaf, ergens in de 30 seconden misschien een bepaalde message krijgt. Wat ik doe om dat op te lossen is HA de gegevens van de OTGW laten verzamelen en dan HA als data source gebruiken voor in mijn geval Prometheus en Grafana.

Ik scrape de HA topic 1x per minuut en dan krijg ik dus netjes elke minuut alle gegevens binnen die bij HA bekend zijn. De kans blijft dat een bepaalde message ouder is dan dat maar daar kun je helaas gewoon niks aan doen.

Eventueel zou je kunnen proberen om de retain op de MQTT message publish aan te zetten, dan blijven de messages bewaard totdat ze overschreven worden. Maar dan nog heb je een manier nodig om er 1 batch van te maken.

Ik gebruik hier overigens geen OTMonitor voor. als MQTT eenmaal draait hoef je er niks meer aan te doen hier.

[DYM]

Dank voor je antwoord.

Ik krijg helaas alleen MQTT data door van de OTGW als ik die net opstart of als er een waarde verandert. Als bijvoorbeeld, zoals nu in de zomer, het 'control setpoint' van de CV niet verandert omdat de verwarming in de zomer niet aanslaat, krijg ik dus maanden lang geen nieuwe data van het 'control setpoint' binnen en deze waarde verdwijnt dan ook in mijn grafieken in Grafana. Ik had daar met het oude Python script geen last van.
Misschien dat ik me dan toch nog maar eens in dat oude Python script moet gaan verdiepen om dat werkend te krijgen. Ik vind MQTT helemaal super maar op deze manier heb ik er niks aan om op deze manier de otgw uit te lezen. Het is denk ik een probleem aan de kant van de OTmonitor. Ik heb dat probleem namelijk niet met P1monitor. Daarvan verandert ook niet alle data elke keer en komt uiteindelijk wél alle data netjes in Influxdb terecht.

Ik zou niet weten hoe ik de retain op de MQTT message publish aan moet zetten want dan moet je dat toch doen in de software van de publisher en dat is in dit geval dan toch OTmonitor? Daar is die mogelijkheid mijns inziens niet aanwezig.

Ik zit ook steeds vaker te denken of ik ook niet eens HA uit moet gaan proberen. Daar zijn inmiddels zoveel mensen op overgeschakeld dat daar ook heel veel over te vinden en te lezen is

[PimW]

Een minder nette oplossing (work-around), zou kunnen zijn om een timegroup toe te voegen aan de 'group by' binnen Grafana: $__timeGroup(dateColumn,'5m', previous)


Allicht dat dat helpt.

[PimW]

Even getest, gaat niet helpen. Ik zie hetzelfde als jou: "no data" wanneer je uit het bereik bent van het laatste meetpunt. In mijn geval is de temperatuur een paar uur geleden aangepast. Grafiek met 1 uur tijdspanne geeft aan "no data", grafiek met tijdspanne van 4 uur trekt het laatste datapunt door. Ik snap je probleem, en besef me dat ik eigenlijk zelf ook een probleem heb haha.

Mijn setup is: Opentherm Gateway -> Mosquitto Broker -> Home Assistant -> TimescaleDB (via LTSS integratie) -> Grafana.

[PimW]

In deze post staat een oplossing beschreven, mits je via Home Assistant gaat werken. Ik heb het zelf nog niet getest, maar dit python script zou volgens deze gebruiker precies moeten doen wat je wil: periodiek de actuele waarde doorgeven, ook als de waarde niet gewijzigd is.

https://community.home-as...gger-mqtt-update/119387/9

[PimW]

Deze oplossing werkt heel goed. De sensor laat ik nu iedere minuut verversen (hij schrijft dan dus een nieuwe waarde weg, ook als dat exact dezelfde waarde is). Zie hieronder een printscreen met een tijdsperiode van 10 minuten waarin ik de temperatuur niet aangepast heb, maar er wel data doorkomt sinds 13:06 (het moment waarop ik de oplossing heb geïmplementeerd.

[Dutchess_Nicole]

PimW schreef op vrijdag 30 juli 2021 @ 13:09:
Deze oplossing werkt heel goed. De sensor laat ik nu iedere minuut verversen (hij schrijft dan dus een nieuwe waarde weg, ook als dat exact dezelfde waarde is). Zie hieronder een printscreen met een tijdsperiode van 10 minuten waarin ik de temperatuur niet aangepast heb, maar er wel data doorkomt sinds 13:06 (het moment waarop ik de oplossing heb geïmplementeerd.

[Afbeelding]

Dat is precies wat ik bedoelde inderdaad. Het probleem is dat als de boiler/thermostaat niks nieuws te melden heeft je dus inderdaad geen datapunten binnenkrijgt. Dat is het ding dat HA (en ik denk ook dat script) oplost, door de waarden die *ooit* eens binnengekomen zijn terug te geven in een data scrape. Ook al zijn die heel oud.

Je hebt dus een oplossing nodig die alle binnengekomen gegevens opslaat en vasthoudt voor als er een scrape request langs komt. Of dat HA is of iets anders maakt natuurlijk niet uit.

Met MQTT en de retain setting los je het probleem maar half op want je hebt dan misschien uiteindelijk wel alle gegevens beschikbaar maar je moet ze dan nog steeds allemaal tegelijk ophalen en aan elkaar relateren met de timestamp van de scrape.

Dat is het punt wat ik oplos door alle gegevens in HA te zetten en via de prometheus_exporter alles in 1 keer te laten scrapen. TSDBs are fun

edit:

Overigens:
volgens http://otgw.tclcode.com/firmware.html kun je met PS=1 een compleet overzicht van alle relevante messages opvragen! In het uiterste geval kun je gewoon elke minuut dit command naar de OTGW sturen en zo alle data alsnog binnenharken!

Niet super mooi maar als het werkt...!

[ Voor 8% gewijzigd door Dutchess_Nicole op 30-07-2021 15:32 ]

[PimW]

Yeah, awesome! Wat hebben we een leuke hobby. Heerlijk pielen, en mooi om andere invalshoeken te zien.

Ik begrijp alleen je oplossing niet helemaal. In geval van DYM (en mijzelf) laat Grafana geen data zien als het meest recente datapunt zover in het verleden ligt, dat deze buiten het bereik van de x-as valt. Als ik je goed begrijp, scrape je periodiek alle data naar je database? Creëer je in dit proces nieuwe datapunten met de last known value?

[DYM]

@PimW : Ik ga even naar het Python script in de link kijken. Dank hiervoor.
Misschien moet ik dan toch maar eens over van Domoticz (wat ik al vanaf het prille begin gebruik) naar Home Assistant ;-)

@Dutchess_Nicole : Nu je het zegt, het staat mij inderdaad bij dat het PS=1 commando alle data genereert. Ik kan dus eerst nog even kijken of ik een Python script kan schrijven (ben daar niet heel handig in) wat b.v. elk kwartier een PS=1 commando richting de OTGW stuurt. Dan zou het ook opgelost moeten zijn.

Nog een vraagje: Draaien jullie HA in Docker of HA OS?

[PimW]

HA in Docker (supervised). Hierdoor kan ik mijn Raspberry Pi ook voor andere dingen gebruiken die buiten het HA OS vallen. Ideaal qua flexibiliteit, maar wel ontzettend oppassen: een paar maanden geleden was er een breaking update van Docker, waardoor Home Assistant bij mij down ging (pijnlijke les: eerst volledige backup maken alvorens sudo update & upgrade te draaien). Dit soort gedoe zal veel minder snel voorkomen als je HA OS draait.

[Dutchess_Nicole]

Ja. Ik zal het proberen uit te leggen.

Mijn data pad gaat als volgt:

Boiler/Thermostaat -> OTGW -> MQTT -> HA -> Prometheus -> Grafana

De boiler en thermostaat sturen maar eens in de 30 seconden oid een message over een bepaald topic. Dit gebeurt wel constant bij mij, maar dat kan iets te maken hebben met de PS=1 setting die ik eerder noemde. Je forceert daarmee een data retrieval maar ik meen me te herinneren ergens eerder in dit topic dat dat misschien voorkomt dat de OTGW standaard data uitzendt?

De OTGW hier is uiteraard alleen de vertaler voor de messages en gooit alles wat langs komt in MQTT. Timing is hier dus niet relevant: komt de message langs, dan wordt ie in de topic geschopt.

Met mijn versie van de OTGW firmware is HA in staat om automatisch entities te creeren voor alle messages die langs komen, dus voor elke message type verschijnt er in HA een entity die die waarde bijhoudt.

Die entities heb ik in een lijst gezet welke ge-exporteerd worden naar Prometheus. Dit is waar het batchen gebeurt, want Prometheus scraped elke minuut elke entity (en ook andere data) en batcht ze allemaal samen met de timestamp. Dit gebeurt op een vast ritme, ongeacht of de entity in HA aangepast is in die tijd. Omdat elke entity in 1 keer ge-exporteerd wordt krijg je dus elke minuut een nieuwe datapoint voor elke entity.

Daardoor kan grafana dus onverstoorde data laten zien. De entities in HA houden gewoon hun waarde, ookal veranderen ze een tijdje niet.

Aan het einde van de rit ziet het er dus zo uit bij mij:





Met deze lijst aan exports:

code:

namespace: "hassio"
filter:
  include_entities:
    - sensor.energy_consumption_tarif_1
    - sensor.energy_consumption_tarif_2
    - sensor.energy_production_tarif_1
    - sensor.energy_production_tarif_2
    - sensor.power_consumption
    - sensor.power_production
    - sensor.power_tariff
    - sensor.voltage_phase_l1
    - sensor.voltage_phase_l2
    - sensor.voltage_phase_l3
    - sensor.voltage_sags_phase_l1
    - sensor.voltage_sags_phase_l2
    - sensor.voltage_sags_phase_l2
    - sensor.voltage_swells_phase_l1
    - sensor.voltage_swells_phase_l2
    - sensor.voltage_swells_phase_l3
    - sensor.current_phase_l1
    - sensor.current_phase_l2
    - sensor.current_phase_l3
    - sensor.power_consumption_phase_l1
    - sensor.power_consumption_phase_l2
    - sensor.power_consumption_phase_l3
    - sensor.power_production_phase_l1
    - sensor.power_production_phase_l2
    - sensor.power_production_phase_l3
    - sensor.energy_consumption_total
    - sensor.gas_consumption
    - sensor.hourly_gas_consumption
    - sensor.shellymqtt_janey_energy
    - sensor.shellymqtt_janey_power
    - sensor.shellymqtt_living_sa_energy
    - sensor.shellymqtt_living_sa_power
    - sensor.electricity_produced_high_daily
    - sensor.electricity_produced_low_daily
    - sensor.electricity_used_high_daily
    - sensor.electricity_used_low_daily
    - sensor.gas_consumption_daily
    - sensor.electricity_produced_high_monthly
    - sensor.electricity_produced_low_monthly
    - sensor.electricity_used_high_monthly
    - sensor.electricity_used_low_monthly
    - sensor.gas_consumption_monthly
    - sensor.thermostat_temperature_sensor
    - sensor.thermostat_humidity_sensor
    - climate.otgw_nodemcu_thermostat
    - sensor.mobile_temperature_sensor
    - sensor.otgw_nodemcu_burnerstarts
    - sensor.otgw_nodemcu_chpumpstarts
    - sensor.otgw_nodemcu_control_setpoint
    - sensor.otgw_nodemcu_dhwburnerstarts
    - sensor.otgw_nodemcu_dhwpumpvalvestarts
    - sensor.otgw_nodemcu_outside_temperature
    - sensor.otgw_nodemcu_relative_modulation_level
    - sensor.otgw_nodemcu_room_setpoint
    - sensor.otgw_nodemcu_room_temperature
    - binary_sensor.otgw_nodemcu_domestic_hot_water_enable
  include_domains:
    - binary_sensor
    - sensor
    - climate

[ Voor 37% gewijzigd door Dutchess_Nicole op 30-07-2021 16:45 ]

[PimW]

Dutchess_Nicole schreef op vrijdag 30 juli 2021 @ 16:23:
want Prometheus scraped elke minuut elke entity (en ook andere data) en batcht ze allemaal samen met de timestamp.

Aah, ik moest je tekst even 3 keer lezen, maar het kwartje is gevallen. Handig opgelost!

[PimW]

Dutchess_Nicole schreef op vrijdag 30 juli 2021 @ 16:23:
De boiler en thermostaat sturen maar eens in de 30 seconden oid een message over een bepaald topic. Dit gebeurt wel constant bij mij, maar dat kan iets te maken hebben met de PS=1 setting die ik eerder noemde. Je forceert daarmee een data retrieval maar ik meen me te herinneren ergens eerder in dit topic dat dat misschien voorkomt dat de OTGW standaard data uitzendt?

Ik heb geen PS=1 setting ingesteld. Iedere seconde krijgt ik alle sensordata binnen op de verschillende MQTT topics. Dankzij de auto-discovery van de firmware wordt dat automatisch omgezet in Home Assistant sensor data.

[DYM]

Als ik een PS=1 commando naar de OTGW stuur stopt de datastroom naar mosquitto (en te zien in MQTT Explorer). Als ik dan weer een PS=0 stuur start de datastroom weer maar ik krijg de events niet meer te zien in MQTT Explorer. Die krijg ik wel weer als ik het vinkje MQTT in OTMonitor weer even uit en aan zet. Het lijkt er dus op dat ik ook met het PS commando niet verder kom.

Nu HA geïnstalleerd maar ik zie al dat ik daar ook niet 1,2,3 in thuis ben. Dus nu eerst weer een hoop lezen en hopelijk ook leren :-)

[Dutchess_Nicole]

Heeft iemand trouwens een suggestie voor een thermostaat die Opentherm kan praten en de TT (Temperature, Temporary) of TC (Temperature, Constant) messages accepteert?

Ik het op het moment een Remeha iSense v19 en deze kan ik wel de TT message sturen maar hij kent deze denk ik niet. Er gebeurt iig niks met de ingestelde temperatuur waarde.

Dus ik kan OF proberen het ingebouwde algorithme voor het modulere van de Control Setpoint gaan proberen na te maken (veel werk en een beetje zonde van mn tijd) of gewoon een thermostaat aanschaffen die die messages ondersteunt.

Qua eisen is het vrij simpel: mijn CV werkt op 24v dus dat moet de thermostaat ondersteunen; het ding is natuurlijk verbonden met de OTGW dus ik heb geen behoefte aan internet verbindingen en apps. HA doet dat allemaal al.

Ik zat te denken aan een Nest, die ziet er qua gebruik vrij simpel uit, maar ik vraag me dus af hoeveel nut het heeft als ik die zou gebruiken zonder alle Google fratsen erbij.

Andere goeie suggesties of ervaringen?

edit:

Toevallig scroll ik 1 pagina terug in dit topic en ik kom
https://gathering.tweaker...message/64581132#64581132 deze post tegen waarin precies mijn probleem staat uitgelegd!

Het was even zoeken maar op de iSense is er dus een setting waarmee je die TT en TC commands kan aanzetten.

Nog steeds geinterresseerd in suggesties maar iig weet ik nu dat zelfs mijn huidige thermostaat dit wel kan.

[ Voor 18% gewijzigd door Dutchess_Nicole op 01-08-2021 13:28 ]

[remco_k]

De "Honeywell Chronotherm Modulation Touch".
Althans, ik heb de vorige versie hangen en die kan het. Zij het alleen hele graden overigens.

[pingwim]

Misschien even kijken in de matrix van de OTGW ?

[PimW]

Ik raad de Nest waarschijnlijk af: ik lees veel verhalen dat deze middels aan/uit werkt en dus niet moduleert. Zelfs V3, die praat via Opentherm, schijnt domme aan/uit signalen door te sturen en niet te moduleren. Kan iemand dit bevestigen?

[Dutchess_Nicole]

Ik heb inmiddels idd wat door zitten lezen over de Nest en wat je er nou wel en niet mee kan en idd, het is min of meer een on/off apparaat wat wat opentherm kan praten. Zeker aangezien ik de wifi functionaliteiten niet wil gaan gebruiken is dat ding gewoon z'n geld niet waard.

Ik denk dat ik deze iSense maar gewoon laat hangen. Hij werkt op zich nog redelijk (scherm begint een beetje dood te gaan maar aangezien we hem toch niet veel meer hoeven te gebruiken nu... whatever) en vreet batterijen maar screw it...

[PimW]

De tactiek die ik bewandeld heb, is:

• Een simpele maar goede thermostaat gebruiken (Honeywell Round Modulation), zonder thermostaatprogramma. Hierdoor is geen noodzaak meer voor een TT-signaal
• Een stookprogramma in Home Assistant programmeren. Door presence en slaap detectie kun je dit stookprogramma aan/uit zetten in Home Assistant.

Ik denk dat dit je een beter eindresultaat geeft dan welke programmeerbare thermostaat dan ook, en het scheelt je geld in de aanschaf van een complexe thermostaat.

[ Voor 4% gewijzigd door PimW op 02-08-2021 13:34 ]

[glaswerk]

PimW schreef op maandag 2 augustus 2021 @ 13:34:
De tactiek die ik bewandeld heb, is:

• Een simpele maar goede thermostaat gebruiken (Honeywell Round Modulation), zonder thermostaatprogramma. Hierdoor is geen noodzaak meer voor een TT-signaal
• Een stookprogramma in Home Assistant programmeren. Door presence en slaap detectie kun je dit stookprogramma aan/uit zetten in Home Assistant.

Ik denk dat dit je een beter eindresultaat geeft dan welke programmeerbare thermostaat dan ook, en het scheelt je geld in de aanschaf van een complexe thermostaat.

Dat is wat ik ook gedaan heb. Ik stook via HA weersafhankelijk (buitentemperatuur via weerlive.nl iedere 10min) met kamercorrectie (temperatuur via thermostaat en Aqara-sensoren). Aangevuld met presentiedetectie en de workday-integratie. Met HA's proximity-integratie kun je zelfs de verwarming aan sturen als je met minimaal 50km/u richting huis beweegt vanaf je werk, om maar wat te noemen.

Verdere leuke extraatjes die je met een thermostaat niet zomaar voor elkaar krijgt, zijn bijvoorbeeld dynamische vermogensbegrenzing van de CV (bijvoorbeeld, als CV 's ochtends wordt aangeschakeld, hoeft hij echt niet altijd volle bak --en daarmee energie-onzuinig-- te gaan blazen, als het buiten boven de 10 graden is). Ik heb dus eigenlijk twee stooklijnen, eentje voor de watertemperatuur, en eentje voor het max CV-vermogen, waarbij de laagste van die twee inputs het gedrag van de CV bepaalt.

Overigens voor logging bij mij wat minder stappen dan ik hier in de thread zie: OTGW rechtstreeks -> HA (via de OTGW-integratie in HA, die leest de OTGW uit, OTMonitor of MQTT niet nodig) en HA schrijft vervolgens rechtstreeks weg naar InfluxDB.

[PimW]

Mooi hoor! Ik ga daar ook maar mee aan de slag Ik heb reeds sensoren die de huidige buitentemperatuur en de maximaal vandaag verwachte temperatuur laten zien (OpenWeatherMap). Alleen zit ik eraan te denken om het simpeler op te lossen:
-Als in de ochtend de huidige kamertemperatuur dichtbij de gewenste kamertemperatuur zit (minder dan een graad kouder), dan: kijk eerst of de maximaal verwachte temperatuur vandaag op/boven gewenste kamertemperatuur zit. Zo ja: niet stoken. Zo nee, wel stoken.

Wat dit feitelijk zou moeten doen, is zorgen dat de ketel in de ochtend minder vaak stookt, en er vaker gratis gebruik wordt gemaakt van buitenwarmte/zonlicht. Ik woon in een modern appartement met absurd goede isolatie, grote ramen en balansventilatie met een warmtewisselaar, dus warmte wordt heel efficiënt gevangen. Daarom ben ik niet zo bang voor temperaturen die al te laag worden. Deze aanpak zou ik echter niet proberen met een minder goed geïsoleerde woning.

[PimW]

Inmiddels ook geïmplementeerd, maar een iets andere versie:
-Als in de ochtend of middag de huidige kamertemperatuur dichtbij de gewenste kamertemperatuur zit (minder dan een halve graad kouder), dan: kijk eerst of de maximaal verwachte temperatuur vandaag minimaal een halve graad boven de gewenste kamertemperatuur zit, en het niet later is dan 15:00. Zo ja: zet het stookprogramma een halve graad lager dan de gewenste kamertemperatuur. Zo nee, zet het stookprogramma op de gewenste kamertemperatuur.

[ Voor 4% gewijzigd door PimW op 02-08-2021 17:40 ]

[PimW]

Ik bedenk me ineens dat dit niet alles afdekt: in jou voorbeeld is het buiten een stuk kouder ("10 graden of hoger") dan in mijn scenario. Daarom wil ik toch wel gebruik maken van dynamische vermogensbegrenzing. Zou je willen uitleggen hoe je dat voor elkaar krijgt?

[ Voor 8% gewijzigd door PimW op 02-08-2021 19:08 ]

[glaswerk]

PimW schreef op maandag 2 augustus 2021 @ 17:48:
Zou je willen uitleggen hoe je dat voor elkaar krijgt?

Mijn situatie is inderdaad heel anders: jaren '30-huis, grotendeels steense buitenmuren, gratis "natuurlijke" ventilatie. Temperatuur huiskamer zakt 's nachts gemakkelijk 4 graden naar beneden (in mijn vorige nieuwbouwhuis met vloerverwarming was dat eerder 0.4 graden, verschil is echt gigantisch).

Dit is stukje uit mijn HA-script dat het CV-vermogen begrenst.
Tijdens een periode van aanwarmen (lengte van die periode langer naarmate buitentemperatuur lager), wordt het maximum relatief hoog gesteld, zodat het niet onaangenaam lang duurt voor het warm wordt in huis:

- service: opentherm_gw.set_max_modulation
data:
gateway_id: 1
level: >
{{ [ ( 95 - 3.5 * ( states('sensor.outside_temperature')|float + 10 ) )|int, 90 ]|min }}
Voorbeeld: als het buiten 0 graden is, wordt vermogen gemaximeerd op 60%

Na de aanwarmfase wordt de "vermogensstooklijn"
{{ [ ( 50 - 2.7 * ( states('sensor.outside_temperature_stats')|float + 10 ) )|int, 0 ]|max }}
Bij buiten 0 graden maximaal vermogen dus 23%. Gevolg is dat op koude winterdagen de ketel de hele dag op laaglast staat te snorren, i.p.v. aan-uit. In de meeste ruimtes hangen "domme" thermostaatknoppen met een instelbaarr weekprogramma (€8 bij Amazon.de, aanrader).

Uiteraard zijn die parameterwaardes proefondervindelijk vast te stellen! De besparing die je hier mogelijk mee realiseert is waarschijnlijk achter-de-komma-werk, zeker in jouw geval met uitstekende isolatie. Maar hé, het voelt goed dat die ketel niet onnodig staat te loeien en langer in efficiënte laaglast draait. En dat alles dankzij die fijne OTGW.

Oh ja, ook een leuke: naast een binnentemperatuurcorrectie heb ik op de watertemperatuur-stooklijn ook een correctie berekend met de 1-uur-vertraagde opbrengst van mijn zonnepanelen als proxy voor zoninval.
Ik stook overigens met een weersafhankelijke stooklijn omdat er meerdere ruimtes in huis zijn warm te houden. Als het niet per se nodig is, zou ik het bij kamertemperatuur-stoken houden.

[PimW]

Thanks! Respect hoe je dit hebt aangepakt.

In mijn geval levert dit waarschijnlijk inderdaad zo weinig winst op, dat het niet de moeite loont om deze paramaterwaardes proefondervindelijk vast te stellen. Ik ga komende herfst bijhouden hoe vaak ik gratis buitentemperatuur/zonlicht kan meepakken met mijn bestaande logica, ben heel benieuwd.

[Dutchess_Nicole]

glaswerk schreef op maandag 2 augustus 2021 @ 22:31:
[...]


Mijn situatie is inderdaad heel anders: jaren '30-huis, grotendeels steense buitenmuren, gratis "natuurlijke" ventilatie. Temperatuur huiskamer zakt 's nachts gemakkelijk 4 graden naar beneden (in mijn vorige nieuwbouwhuis met vloerverwarming was dat eerder 0.4 graden, verschil is echt gigantisch).

Dit is stukje uit mijn HA-script dat het CV-vermogen begrenst.
Tijdens een periode van aanwarmen (lengte van die periode langer naarmate buitentemperatuur lager), wordt het maximum relatief hoog gesteld, zodat het niet onaangenaam lang duurt voor het warm wordt in huis:

- service: opentherm_gw.set_max_modulation
data:
gateway_id: 1
level: >
{{ [ ( 95 - 3.5 * ( states('sensor.outside_temperature')|float + 10 ) )|int, 90 ]|min }}
Voorbeeld: als het buiten 0 graden is, wordt vermogen gemaximeerd op 60%

Na de aanwarmfase wordt de "vermogensstooklijn"
{{ [ ( 50 - 2.7 * ( states('sensor.outside_temperature_stats')|float + 10 ) )|int, 0 ]|max }}
Bij buiten 0 graden maximaal vermogen dus 23%. Gevolg is dat op koude winterdagen de ketel de hele dag op laaglast staat te snorren, i.p.v. aan-uit. In de meeste ruimtes hangen "domme" thermostaatknoppen met een instelbaarr weekprogramma (€8 bij Amazon.de, aanrader).

Uiteraard zijn die parameterwaardes proefondervindelijk vast te stellen! De besparing die je hier mogelijk mee realiseert is waarschijnlijk achter-de-komma-werk, zeker in jouw geval met uitstekende isolatie. Maar hé, het voelt goed dat die ketel niet onnodig staat te loeien en langer in efficiënte laaglast draait. En dat alles dankzij die fijne OTGW.

Oh ja, ook een leuke: naast een binnentemperatuurcorrectie heb ik op de watertemperatuur-stooklijn ook een correctie berekend met de 1-uur-vertraagde opbrengst van mijn zonnepanelen als proxy voor zoninval.
Ik stook overigens met een weersafhankelijke stooklijn omdat er meerdere ruimtes in huis zijn warm te houden. Als het niet per se nodig is, zou ik het bij kamertemperatuur-stoken houden.

Dit komt dan wel weer overeen met onze situatie hier thuis.

Ook een huis uit de 30-er jaren, enkelsteense muren, en nog simpel dubbel glas in houten sponningen (die we hopelijk binnenkort gaan laten vervangen!) dus zo'n beetje hetzelfde.

Ik moet inderdaad nog even kijken naar de modulatie optie want de thermostaat kent wat dat betreft maar 2 opties, 0 of 100 procent.

Als ik die formule van boven bekijk, let je dan inderdaad alleen op de buiten temperatuur om te bepalen wat je modulatiewaarde moet zijn? Of is dat onderdeel van een veel groter geheel waarin meer factoren meespelen?

[glaswerk]

Dutchess_Nicole schreef op dinsdag 3 augustus 2021 @ 08:59:
[...]
Als ik die formule van boven bekijk, let je dan inderdaad alleen op de buiten temperatuur om te bepalen wat je modulatiewaarde moet zijn? Of is dat onderdeel van een veel groter geheel waarin meer factoren meespelen?

De formule hierboven stelt alleen een maximum aan de door de CV gekozen modulatie.
Vervolgens heb ik daarnaast een "traditionele" stooklijn, waarbij HA dus een CV-watertemperatuur vraagt o.b.v. i) buitentemperatuur, ii) neerwaartse correctie voor zoninval (proxy met opbrengst zonnepanelen), iii) (indien gewenst) correctie o.b.v. verschil tussen waargenomen en gewenste kamertemperatuur. Die correctie kan zowel naar boven als naar beneden zijn.

Verder zijn voorverwarm-tijden ook weer afhankelijk van de buitentemperatuur, doel is om het binnen iedere dag op hetzelfde moment warm te hebben. En er zitten nog wat floors en caps in het systeem; als de formule bijvoorbeeld water van minder dan 32 graden vraagt, laat ik de hele CV uitschakelen, want dan is er in mijn geval toch nauweiljks warmteafgifte meer. En boven de 60 graden mag ie ook niet, behalve in specifieke gevallen x, y en z (een toevoeging gemaakt toen het 10 graden vroor afgelopen winter).

Voorbeeld: stooklijn vraagt 's ochtends water van 55 graden. Normaliter zou CV dan volle bak gaan branden om dat z.s.m. voor elkaar te krijgen. Maar de "modulatie-stooklijn" capt op dat moment het vermogen, zodat CV zuiniger brandt. Keerzijde is uiteraard dat het langer duurt om de boel warm te krijgen, dat is dus even zoeken naar een evenwicht. Als water eenmaal op temperatuur is, moduleert de CV natuurlijk gewoon terug naar het benodigde vermogen; dat ligt dan onder het plafond van de modulatie-stooklijn.

Ondanks dat maker OTGW het (terecht) afraadt zelf een thermostaat te bouwen, lukt het hier toch redelijk aardig om met HA de kamertemperatuur meestal in een bandbreedte van 0.5 graden te houden, en dat dus met heel beheerst ketel-gedrag.

[Tuskermalt]

Is er iemand die mij kan helpen? Ik heb mijn OTGW geprobeerd te updaten via de ethernet module maar dat is niet goed gegaan nu krijg ik echter de OTGW niet meer aan de praat.

Ik heb het geprobeerd via de FTDI op het bordje maar dat lukt ook niet krijg geen communicatie met de PIC.
Moet die op een speciale manier aangesloten zijn of iets dergelijks of kan ik de PIC niet programmeren via FTDI.

Als dat niet mogelijk is is er iemand hier bij mij in de buurt woon tussen Deventer en Zwolle die de PIC kan herprogrammeren met de laatste software.

[PimW]

De grootste kan heb je op discord: https://discord.gg/zjW3ju7vGQ , subchannel nederlandse-ondersteuning

[CurlyMo]

Weet iemand hier op de deze shield genoeg power heeft om ook een thermostaat zelf te voeden?


https://diyless.com/product/slave-opentherm-shield

[number3]

Deze week is release 0.8.6 uitgekomen voor de Nodoshop OTGW-firmware. De 15e release zorgt voor het oplossen van wat kleine bugs en bevat enkele kleine verbeteringen.

De release kan je hier vinden: https://github.com/rvdbreemen/OTGW-firmware/releases

Indien je issues hebt mag dat via GitHub issues of rechtstreeks in het discord kanaal (https://discord.gg/zjW3ju7vGQ).

Groet
Robert

[CurlyMo]

Voor alle Honeywell Chronoterm Touch eigenaren. Kan iemand eens meten hoeveel stroom die thermostaat trekt? Of weet iemand of die met Low power mode te voeden is?

Low Power:
• Idle current low
• idle voltage is low
• Available power 40 mW (5mA at 8V) *
Medium Power:
• Idle current high
• idle voltage is low
• Available power 136 mW (17mA at 8V) *
High Power:
• Idle current high
• idle voltage is high
• Available power 306mW (17mA at 18V) *

Het in mijn vorige reactie gelinkte bordje kan alleen low-power mode leveren.

@number3 De reden dat ik kijk naar bovenstaand bordje en niet de bekende OTGW gateway van nodo-shop is dat ik een paar simpele acties zou willen automatiseren. Bijv. het verwarmen / koelen signaal vertalen naar het aan / uitschakelen van respectievelijk een tweetal relais die weer twee contacten van mijn warmtepomp schakelen. Ik wil daarvoor niet afhankelijk zijn van externe domotica. Is de firmware voor de NodeMCU een beetje makkelijk uit te breiden om zoiets te bewerkstelligen? En kan ik makkelijk relais aansluiten aan de gateway?

[ Voor 31% gewijzigd door CurlyMo op 17-09-2021 21:44 ]

[DRAFTER86]

Hm ik probeer op mijn gateway (Nodoshop OTGW met NodeMCU) een DS18B20 temperatuur sensor aan te sluiten, maar dat lijkt nog niet helemaal te werken.
Het is me ook niet helemaal duidelijk hoe e.e.a aangesloten moet worden; de OTGW heeft een header voor een sensor (http://otgw.tclcode.com/peripherals.html), en in de Nodo NodeMCU firmware kun je ook een GPIO sensor instellen, voor poort 10 van de GPIO: https://github.com/rvdbre...blob/main/sensors_ext.ino
Zijn dat dezelfde? Of is het de een of de ander?

[vanenkelen]

DRAFTER86 schreef op zondag 26 september 2021 @ 11:57:
Hm ik probeer op mijn gateway (Nodoshop OTGW met NodeMCU) een DS18B20 temperatuur sensor aan te sluiten, maar dat lijkt nog niet helemaal te werken.
Het is me ook niet helemaal duidelijk hoe e.e.a aangesloten moet worden; de OTGW heeft een header voor een sensor (http://otgw.tclcode.com/peripherals.html), en in de Nodo NodeMCU firmware kun je ook een GPIO sensor instellen, voor poort 10 van de GPIO: https://github.com/rvdbre...blob/main/sensors_ext.ino
Zijn dat dezelfde? Of is het de een of de ander?

Op mijn OTGW van Nodo shop zat een 4.x firmware. De externe temperatuur sensor werkt pas vanaf firmware 5.1. Misschien is dat bij jou ook het geval?

Bij mij ging de firmware upgrade trouwens wel mis…. Dus had een nieuwe PIC nodig met de juiste firmware. Daarna werkte de temp sensor goed.

Je moet wel nog een weerstand erbij plaatsen om de temp sensor aan het werk te krijgen.

[number3]

@DRAFTER86 er zijn twee opties inderdaad. Als je de nodoshop nodemcu gebruikt dan is het pin 10 op de nodemcu. Of anders via de PIC en de aansluiting op de pcb. Dit zijn inderdaad twee verschillende manieren om aan te sluiten.

Groet,
Robert

[ Voor 3% gewijzigd door number3 op 26-09-2021 16:56 ]

[number3]

@CurlyMo de nodemcu is in mijn beleving vrij eenvoudig aan te passen. Het aansturen van een extern relais is al ingebouwd, echter zal als dat niet het geval zou zijn is het vrij overzichtelijk opgezet. Zelfs zonder externe Domoticz of Home Assistant kan je een gehee standalone variant maken van de OTGW oplossing. Het heeft namelijk ook een web interface.

Anyway, ik hoor graag wat je uiteindelijk gekozen hebt,
Robert

[DRAFTER86]

vanenkelen schreef op zondag 26 september 2021 @ 15:10:
[...]


Op mijn OTGW van Nodo shop zat een 4.x firmware. De externe temperatuur sensor werkt pas vanaf firmware 5.1. Misschien is dat bij jou ook het geval?

Bij mij ging de firmware upgrade trouwens wel mis…. Dus had een nieuwe PIC nodig met de juiste firmware. Daarna werkte de temp sensor goed.

Je moet wel nog een weerstand erbij plaatsen om de temp sensor aan het werk te krijgen.

Ok,maar geen suggestie hoe ik er voor zorg dat ik m'n PIC niet brick? 😎

[DRAFTER86]

DRAFTER86 schreef op zondag 26 september 2021 @ 17:03:
[...]


Ok,maar geen suggestie hoe ik er voor zorg dat ik m'n PIC niet brick? 😎

number3 schreef op zondag 26 september 2021 @ 16:56:
@DRAFTER86 er zijn twee opties inderdaad. Als je de nodoshop nodemcu gebruikt dan is het pin 10 op de nodemcu. Of anders via de PIC en de aansluiting op de pcb. Dit zijn inderdaad twee verschillende manieren om aan te sluiten.

Groet,
Robert

Ah check, dacht al zoiets! Die via de PIC wordt gewoon direct als opentherm message verpakt ofzo?
En via pin 10, dan moet ik dat ff op de 'verkeerde' kant aan de pinheader van de NodeMCU prutsen ofzo?