[OTGW] OpenTherm gateway

[arthurlaurens]

Mijn OTGW device draait op v0.9.5, wat is de juist manier om hem naar de nieuwste versie te updaten?

- alle opvolgendeupdates 1 voor 1 installeren?
- gelijk de laatste versie downloaden en flashen?
- iets anders?

Ik heb niet veel ervaring hiermee, advies is zeer welkom

[pistole]

arthurlaurens schreef op vrijdag 3 april 2026 @ 08:58:
Mijn OTGW device draait op v0.9.5, wat is de juist manier om hem naar de nieuwste versie te updaten?

- alle opvolgendeupdates 1 voor 1 installeren?
- gelijk de laatste versie downloaden en flashen?
- iets anders?

Ik heb niet veel ervaring hiermee, advies is zeer welkom

If it ain't broke, don't fix it.

Maar als je de wifi versie hebt dan kan je via OTA (over the air) updaten met de instructies in de wiki: https://github.com/rvdbre...ing-Over-The-Air-flashing

[arthurlaurens]

pistole schreef op vrijdag 3 april 2026 @ 11:51:
[...]

If it ain't broke, don't fix it.

Maar als je de wifi versie hebt dan kan je via OTA (over the air) updaten met de instructies in de wiki: https://github.com/rvdbre...ing-Over-The-Air-flashing

Dank voor je advies. Dat is inderdaad een handige manier om een update uit te voeren, maar kan ik ook direct de laatste update uitvoeren gezien mijn huidige versie of moet het in stappen?

"If it ain't broke, don't fix it" klinkt inderdaad slim, tegelijkertijd is het ook vaak goed ervoor te zorgen dat software geupdate blijft. Lijken twee tegenstrijdige manieren van denken hier. Ook wil ik graag voorkomen dat ik zo lang wacht met updaten dat het straks helemaal niet meer (makkelijk) mogelijk is...

[Dutchess_Nicole]

arthurlaurens schreef op vrijdag 3 april 2026 @ 11:55:
[...]


Dank voor je advies. Dat is inderdaad een handige manier om een update uit te voeren, maar kan ik ook direct de laatste update uitvoeren gezien mijn huidige versie of moet het in stappen?

"If it ain't broke, don't fix it" klinkt inderdaad slim, tegelijkertijd is het ook vaak goed ervoor te zorgen dat software geupdate blijft. Lijken twee tegenstrijdige manieren van denken hier. Ook wil ik graag voorkomen dat ik zo lang wacht met updaten dat het straks helemaal niet meer (makkelijk) mogelijk is...

Het zou niet uit moeten maken vanaf welke versie je de update doet. Het enige waar je rekening mee moet houden is dat bij de oude versies je eerst even handmatig de settings file moet downloaden.

Anders dan dat is er denk ik geen beperking: alles komt mee met de littlefs update.

[number3]

If it ain’t broken, it doesn’t mean it’s flawless.

De stabiliteit vanaf 0.9.x komt vooral door basis principe van watchdog en reset when in doubt.

Wat is er dan aangepast sinds 0.9.x, lees het hier: https://github.com/rvdbre.../docs/upgrade-from-0.x.md

Issues die lang open hadden gestaan zijn opgelost, features die ik zelf altijd wilde zijn er nu, en zo kwamen er dit jaar al 10 nieuwe releases.

Bepaal zelf of je wilt upgraden. Als de huidige situatie goed voor je werkt, don’t change it just because it’s new and shinny. 😉

[ Voor 32% gewijzigd door number3 op 06-04-2026 10:35 . Reden: Kleine edit ]

[arthurlaurens]

Het is voor mij nu helaas niet direct duidelijk wat ik moet doen om de update goed uit te voeren. Zowel op github als op de webpage zie ik update mogelijkheden voor "ino.bin" en "littlefs.bin":


- Beide (1 voor 1 of tegelijk) installeren?
- Alleen de ino.bin?
- Alleende ino.littlefs?

Heb geprobeerd de info uit de README te halen, de update page en tweakers, maar zie niet zo snel een antwoord. Ben ook benieuwd wat nu precies het verschil is en de overwegingen tussen de twee zijn?

[JBS]

@arthurlaurens Beide zijn vaak noodzakelijk voor een update, maar het wordt per release bij de "Upgrade notes" benoemd. Ik begin altijd bij de eerste, dan de tweede. Maar of het echt maakt, weet ik niet.

[ Voor 18% gewijzigd door JBS op 06-04-2026 19:19 ]

[arthurlaurens]

Dank @JBS . Beide zojuist gedaan, lijkt top gegaan te zijn. Ziet er in ieder geval weer modern uit nu!

[Tomba]

Tomba schreef op donderdag 2 april 2026 @ 15:55:
[...]

Kan ik deze over versie 0.10.2+50c3ed2 heen installeren? (En heeft het zin? t ding draait eigenlijk super stabiel)

Met behulp van deze guide succesvol bijgewerkt:
https://github.com/rvdbre...ing-Over-The-Air-flashing
Blijkbaar liep mijn PIC ook nog achter, erg nice dat dit nu ook via de web interface gaat:

[Tomba]

Hmm upgraden naar 6.6 gaat mis:

gevolgd door:

@number3 is dit een known issue?

[number3]

Nope dit issue is nieuw voor mij. Ik zal eens onderzoeken wat er gebeurt. Kan je beschrijven wat de exacte situatie is?

En graag logging delen. Hier kan je zien wat nodig is:
https://github.com/rvdbre...OTGW-firmware-te-debuggen

Ik ben op Discord goed te bereiken. Hier kijk ik minder 😇😬

[ Voor 46% gewijzigd door number3 op 09-04-2026 18:35 ]

[Tomba]

number3 schreef op donderdag 9 april 2026 @ 18:30:
Nope dit issue is nieuw voor mij. Ik zal eens onderzoeken wat er gebeurt. Kan je beschrijven wat de exacte situatie is?

En graag logging delen. Hier kan je zien wat nodig is:
https://github.com/rvdbre...OTGW-firmware-te-debuggen

Ik ben op Discord goed te bereiken. Hier kijk ik minder 😇😬

Discord doe ik eigenlijk niet in dus ik probeer het toch even hier
Apparaat is een Nodo ESP8266 variant, hier is de debug info:

code:

Developer Robert van den Breemen
Firmware Version 1.3.5+e134814
PIC Available true
PIC Firmware  Version 6.5
PIC Device ID pic16f1847
PIC Firmware Type gateway
Compiled On Apr 6 2026 01:52:17
Hostname OTGW
IP Address x.x.x.x
MAC Address 24:A1:60:xx:xx:xx
Free Heap Memory (bytes) 12584
Max. Free Block (bytes) 11392
Unique Chip ID xxxxxx
Arduino Core Version 2_7_4
Espressif SDK Version 2.2.2-dev(38a443e)
CPU Speed (MHz) 160
Sketch Size (bytes) 685264
Sketch Free (bytes) 1409024
Flash ID 001640D8
Flash Chip Size (MB) 4
Real Flash Chip (MB) 4
LittleFS Size (MB) 1
Flash Chip Speed (MHz) 40
Flash Mode DIO
Wi-Fi Network (SSID) XXX
Wi-Fi Signal Strength (dBm) -61
Wi-Fi Quality (%) 89
Wi-Fi Quality Amazing
NTP Enabled true
NTP Timezone Europe/Amsterdam
Uptime Since Boot 5(d)-03:45(H:m)
Last Reset Reason Software/System restart
Number of Reboots 2
MQTT Connected true
Thermostat Connected true
Boiler Connected true
Gateway Mode Monitor
OpenTherm Active true

Wat doe ik, Advanced --> PIC Firmware --> Install Firmware onto PIC
Dan verschijnt deze melding:


Gevolgd door deze na een tijdje:


Heb met Telnet meegekeken en zie dit:

code:

14:35:12.507594 (  15480| 14696) processOT   (3813): Boiler             BD0010600   1 Write-Ack         TSet = 6.00 °C
14:35:12.642305 (  15480| 14696) processOT   (3813): Thermostat         T00140000  20 Read-Data         DayTime = Unknown - 00:00
14:35:13.754564 (  13888| 13400) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [0]
14:35:13.756547 (  12544| 12104) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[0]:cmd[PR=T] (4)
14:35:13.757997 (  12544| 12104) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [1]
14:35:13.516839 (  15480| 14696) processOT   (3813): Boiler             BF0140000  20 Unknown-Data-Id   DayTime = Unknown - 00:00
14:35:13.640980 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:14.032597 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:14.034966 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=T] (4)
14:35:14.067791 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: T=11] (8)
14:35:14.070214 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=T] from queue
14:35:14.071102 (  14136| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[0]:[PR=T]
14:35:14.072077 (  14136| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ T=11]==>[0]:[PR=T]
14:35:14.072805 (  14136| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [0]:[PR=T] from queue
PR: T=11
14:35:14.529269 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:14.633436 (  15480| 14696) processOT   (3813): Thermostat         T00110000  17 Read-Data         RelModLevel = 0.00 %
14:35:15.537543 (  14136| 13400) processOT   (3813): Boiler             BC0110000  17 Read-Ack        > RelModLevel = 0.00 %
14:35:15.686816 (  15480| 14696) processOT   (3813): Thermostat         T80150000  21 Read-Data         Date =   0 /   0 
14:35:16.759797 (  13888| 13400) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [0]
14:35:16.761597 (  12544| 12104) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[0]:cmd[PR=D] (4)
14:35:16.762804 (  12544| 12104) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [1]
14:35:16.535844 (  15480| 14696) processOT   (3813): Boiler             B70150000  21 Unknown-Data-Id   Date =   0 /   0 
14:35:16.628895 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:17.033845 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:17.036324 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=D] (4)
14:35:17.093488 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: D=R] (7)
14:35:17.097101 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=D] from queue
14:35:17.098107 (  14136| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[0]:[PR=D]
14:35:17.099443 (  14136| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ D=R]==>[0]:[PR=D]
14:35:17.100531 (  14136| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [0]:[PR=D] from queue
PR: D=R
14:35:17.540958 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:17.621834 (  15480| 14696) processOT   (3813): Thermostat         T80190000  25 Read-Data         Tboiler = 0.00 °C
14:35:18.539001 (  14136| 13400) processOT   (3813): Boiler             B401921F0  25 Read-Ack        > Tboiler = 33.94 °C
14:35:18.617230 (  15480| 14696) processOT   (3813): Thermostat         T80160000  22 Read-Data         Year = 0 
14:35:19.759715 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [0]
14:35:19.761956 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[0]:cmd[PR=P] (4)
14:35:19.763145 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [1]
14:35:19.537870 (  15480| 14696) processOT   (3813): Boiler             B70160000  22 Unknown-Data-Id   Year = 0 
14:35:19.616528 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:20.034975 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:20.037434 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=P] (4)
14:35:20.093408 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: P=Low power] (15)
14:35:20.096282 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=P] from queue
14:35:20.097460 (  14136| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[0]:[PR=P]
14:35:20.098163 (  14136| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ P=Low pow]==>[0]:[PR=P]
14:35:20.098841 (  14136| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [0]:[PR=P] from queue
PR: P=Low power
14:35:20.550129 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:20.610371 (  15480| 14696) processOT   (3813): Thermostat         T801C0000  28 Read-Data         Tret = 0.00 °C
14:35:21.555873 (  15480| 14696) processOT   (3813): Boiler             B701C0000  28 Unknown-Data-Id   Tret = 0.00 °C
14:35:21.615660 (  14136| 13400) processOT   (3813): Thermostat         T1018133A  24 Write-Data      > Tr = 19.23 °C
14:35:22.760305 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [0]
14:35:22.762552 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[0]:cmd[PR=R] (4)
14:35:22.764089 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [1]
14:35:22.563316 (  15480| 14696) processOT   (3813): Boiler             BD018133A  24 Write-Ack         Tr = 19.23 °C
14:35:22.626404 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:23.037799 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:23.040309 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=R] (4)
14:35:23.076932 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: R=D] (7)
14:35:23.079347 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=R] from queue
14:35:23.080530 (  14136| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[0]:[PR=R]
14:35:23.081237 (  14136| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ R=D]==>[0]:[PR=R]
14:35:23.081914 (  14136| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [0]:[PR=R] from queue
PR: R=D
14:35:23.573354 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:23.700389 (  14136| 13400) processOT   (3813): Thermostat         T10010600   1 Write-Data      > TSet = 6.00 °C
14:35:24.578645 (  15480| 14696) processOT   (3813): Boiler             BD0010600   1 Write-Ack         TSet = 6.00 °C
14:35:24.693396 (  15480| 14696) processOT   (3813): Thermostat         T801A0000  26 Read-Data         Tdhw = 0.00 °C
14:35:25.761459 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [0]
14:35:25.763482 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[0]:cmd[PR=B] (4)
14:35:25.764652 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [1]
14:35:25.588842 (  14136| 13400) processOT   (3813): Boiler             BC01A2000  26 Read-Ack        > Tdhw = 32.00 °C
14:35:25.693211 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:26.039321 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:26.041674 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=B] (4)
14:35:26.086634 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: B=17:52 12-03-2023] (22)
14:35:26.090025 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=B] from queue
14:35:26.090928 (  14136| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[0]:[PR=B]
14:35:26.091620 (  14136| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ B=17:52 1]==>[0]:[PR=B]
14:35:26.092299 (  14136| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [0]:[PR=B] from queue
PR: B=17:52 12-03-2023
14:35:26.598615 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:26.686570 (  15480| 14696) processOT   (3813): Thermostat         T00110000  17 Read-Data         RelModLevel = 0.00 %
14:35:27.603255 (  14136| 13400) processOT   (3813): Boiler             BC0110000  17 Read-Ack        > RelModLevel = 0.00 %
14:35:28.833559 (  15480| 14696) processOT   (3813): Thermostat         T001B0000  27 Read-Data         Toutside = 0.00 °C
14:35:28.886407 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [0]
14:35:28.888638 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[0]:cmd[PR=C] (4)
14:35:28.890052 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [1]
14:35:28.611003 (  15480| 14696) processOT   (3813): Boiler             B601B0000  27 Data-Invalid      Toutside = 0.00 °C
14:35:28.689019 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:29.052073 (  13888| 13400) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:29.054149 (  12544| 12104) sendOTGW    (2802): Sending to Serial [PR=C] (4)
14:35:29.159553 (  15424| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: C=4 MHz] (11)
14:35:29.162418 (  14080| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=C] from queue
14:35:29.163622 (  14080| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[0]:[PR=C]
14:35:29.164340 (  14080| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ C=4 MHz]==>[0]:[PR=C]
14:35:29.165021 (  14080| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [0]:[PR=C] from queue
PR: C=4 MHz
14:35:29.622251 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:29.677862 (  15480| 14696) processOT   (3813): Thermostat         T80190000  25 Read-Data         Tboiler = 0.00 °C
14:35:30.024717 (  15480| 14696) checklittlef( 509): Check githash = [e134814]
14:35:30.027266 (  14136| 13400) checklittlef( 510): FS githash = [e134814] | FW githash = [e134814]
14:35:30.028588 (  14136| 13400) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [0]
14:35:30.029346 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[0]:cmd[PR=M] (4)
14:35:30.030360 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [1]
14:35:30.060725 (  14848| 13016) logHeapStats( 816): Heap: 14848 bytes free, 13016 max block, level=HEALTHY, WS_drops=0, MQTT_drops=0
14:35:30.631148 (  14136| 13400) processOT   (3813): Boiler             B401921F0  25 Read-Ack        > Tboiler = 33.94 °C
14:35:30.703846 (  15480| 14696) processOT   (3813): Thermostat         T80230000  35 Read-Data         FanSpeed =   0 /   0 Hz
14:35:31.887650 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [1]
14:35:31.889866 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[1]:cmd[PR=Q] (4)
14:35:31.891353 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [2]
14:35:31.076229 (  13256| 12072) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:31.078395 (  11912| 11424) sendOTGW    (2802): Sending to Serial [PR=M] (4)
14:35:31.110896 (  13256| 12072) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: M=M] (7)
14:35:31.114346 (  12584| 12072) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=M] from queue
14:35:31.115273 (  12584| 12072) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[0]:[PR=M]
14:35:31.115957 (  12584| 12072) checkOTGWcmd(2765): CmdQueue: Found value [ M=M]==>[0]:[PR=M]
14:35:31.116634 (  12584| 12072) checkOTGWcmd(2766): CmdQueue: Remove from queue [0]:[PR=M] from queue
PR: M=M
14:35:31.628157 (  15480| 14696) processOT   (3813): Boiler             B70230000  35 Unknown-Data-Id   FanSpeed =   0 /   0 Hz
14:35:31.691193 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:32.076575 (  13888| 13232) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:32.078572 (  12544| 11936) sendOTGW    (2802): Sending to Serial [PR=Q] (4)
14:35:32.117841 (  13888| 13232) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: Q=E] (7)
14:35:32.121154 (  13216| 12584) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=Q] from queue
14:35:32.122072 (  13216| 12584) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[0]:[PR=Q]
14:35:32.122775 (  13216| 12584) checkOTGWcmd(2765): CmdQueue: Found value [ Q=E]==>[0]:[PR=Q]
14:35:32.123678 (  13216| 12584) checkOTGWcmd(2766): CmdQueue: Remove from queue [0]:[PR=Q] from queue
PR: Q=E
14:35:32.631625 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:33.761598 (  15480| 14696) processOT   (3813): Thermostat         T801C0000  28 Read-Data         Tret = 0.00 °C
14:35:33.638704 (  15480| 14696) processOT   (3813): Boiler             B701C0000  28 Unknown-Data-Id   Tret = 0.00 °C
14:35:34.757987 (  15480| 14696) processOT   (3813): Thermostat         T00300000  48 Read-Data         TdhwSetUBTdhwSetLB =   0 /   0 °C
14:35:34.887639 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [0]
14:35:34.890792 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[0]:cmd[PR=N] (4)
14:35:34.892483 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [1]
14:35:34.641769 (  14136| 13400) processOT   (3813): Boiler             BC0304128  48 Read-Ack        > TdhwSetUBTdhwSetLB =  65 /  40 °C
14:35:35.756730 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:35.093923 (  13888| 13400) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:35.095892 (  12544| 12104) sendOTGW    (2802): Sending to Serial [PR=N] (4)
14:35:35.152274 (  15424| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: BV] (6)
14:35:35.154870 (  14080| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
PR: BV
14:35:35.643882 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:36.791135 (  14136| 13400) processOT   (3813): Thermostat         T10010600   1 Write-Data      > TSet = 6.00 °C
14:35:36.648941 (  15480| 14696) processOT   (3813): Boiler             BD0010600   1 Write-Ack         TSet = 6.00 °C
14:35:36.745111 (  15480| 14696) processOT   (3813): Thermostat         T10383C00  56 Write-Data        Reserved in OpenTherm v4.x profile (legacy pre-v4.2 ID 56 ignored)
14:35:37.888241 (  15480| 14696) queryNextPIC( 593): PIC settings readout cycle complete
14:35:37.890627 (  14136| 13400) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [1]
14:35:37.891808 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[1]:cmd[PR=V] (4)
14:35:37.892829 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [2]
14:35:37.249502 (  14600| 13616) triggerPICse( 553): PIC settings readout cycle triggered
14:35:37.656471 (  15480| 14696) processOT   (3813): Boiler             BD0380000  56 Write-Ack         Reserved in OpenTherm v4.x profile (legacy pre-v4.2 ID 56 ignored)
14:35:37.745630 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:38.094176 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [1] due
14:35:38.097628 (  13800| 13400) sendOTGW    (2802): Sending to Serial [PR=V] (4)
14:35:38.144652 (  14736| 13016) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: V=5] (7)
14:35:38.147418 (  13504| 13016) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
14:35:38.148542 (  13504| 13016) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[1]:[PR=V] from queue
14:35:38.149277 (  13504| 13016) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[1]:[PR=V]
14:35:38.149973 (  13504| 13016) checkOTGWcmd(2765): CmdQueue: Found value [ V=5]==>[1]:[PR=V]
14:35:38.150654 (  13504| 13016) checkOTGWcmd(2766): CmdQueue: Remove from queue [1]:[PR=V] from queue
PR: V=5
14:35:38.666552 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:39.769812 (  15480| 14696) processOT   (3813): Thermostat         T00110000  17 Read-Data         RelModLevel = 0.00 %
14:35:39.673694 (  14136| 13400) processOT   (3813): Boiler             BC0110000  17 Read-Ack        > RelModLevel = 0.00 %
14:35:39.734644 (  15480| 14696) processOT   (3813): Thermostat         T00390000  57 Read-Data         Reserved in OpenTherm v4.x profile (legacy pre-v4.2 ID 57 ignored)
14:35:40.888411 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [1]
14:35:40.890611 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[1]:cmd[PR=O] (4)
14:35:40.892172 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [2]
14:35:40.094537 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:40.096847 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=N] (4)
14:35:40.186786 (  14216| 12632) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: BV] (6)
14:35:40.189719 (  12872| 12632) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
14:35:40.190654 (  12872| 12632) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[1]:[PR=O] from queue
PR: BV
14:35:40.679562 (  15480| 14696) processOT   (3813): Boiler             B40394600  57 Read-Ack          Reserved in OpenTherm v4.x profile (legacy pre-v4.2 ID 57 ignored)
14:35:40.741848 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:41.094822 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [1] due
14:35:41.097190 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=O] (4)
14:35:41.142591 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: O=N] (7)
14:35:41.145411 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
14:35:41.147858 (  13800| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[1]:[PR=O] from queue
14:35:41.148766 (  13800| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[1]:[PR=O]
14:35:41.149470 (  13800| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ O=N]==>[1]:[PR=O]
14:35:41.150151 (  13800| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [1]:[PR=O] from queue
PR: O=N
14:35:41.690937 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:41.746375 (  15480| 14696) processOT   (3813): Thermostat         T80190000  25 Read-Data         Tboiler = 0.00 °C
14:35:42.700414 (  14136| 13400) processOT   (3813): Boiler             B401921F0  25 Read-Ack        > Tboiler = 33.94 °C
14:35:43.822386 (  15480| 14696) processOT   (3813): Thermostat         T00710000 113 Read-Data         BurnerUnsuccessfulStarts = 0 
14:35:43.889739 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [1]
14:35:43.891770 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[1]:cmd[PR=S] (4)
14:35:43.892940 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [2]
14:35:43.704302 (  14136| 13400) processOT   (3813): Boiler             B40710001 113 Read-Ack        > BurnerUnsuccessfulStarts = 1 
14:35:44.820297 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:44.097102 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [1] due
14:35:44.099463 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=S] (4)
14:35:44.162627 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: S=16.00] (11)
14:35:44.165387 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
14:35:44.166279 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[1]:[PR=S] from queue
14:35:44.167283 (  14136| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[1]:[PR=S]
14:35:44.168029 (  14136| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ S=16.00]==>[1]:[PR=S]
14:35:44.168711 (  14136| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [1]:[PR=S] from queue
PR: S=16.00
14:35:44.715113 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:45.814735 (  15480| 14696) processOT   (3813): Thermostat         T801C0000  28 Read-Data         Tret = 0.00 °C
14:35:45.097835 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:45.100194 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=N] (4)
14:35:45.150163 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: BV] (6)
14:35:45.152686 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
PR: BV
14:35:45.719124 (  15480| 14696) processOT   (3813): Boiler             B701C0000  28 Unknown-Data-Id   Tret = 0.00 °C
14:35:46.810266 (  15480| 14696) processOT   (3813): Thermostat         T00720000 114 Read-Data         FlameSignalTooLow = 0 
14:35:46.890219 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [1]
14:35:46.892394 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[1]:cmd[PR=W] (4)
14:35:46.893869 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [2]
14:35:46.731136 (  14136| 13400) processOT   (3813): Boiler             BC0720000 114 Read-Ack        > FlameSignalTooLow = 0 
14:35:47.808575 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:47.097912 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [1] due
14:35:47.101175 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=W] (4)
14:35:47.167775 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: W=A] (7)
14:35:47.170160 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
14:35:47.171056 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[1]:[PR=W] from queue
14:35:47.171770 (  14136| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[1]:[PR=W]
14:35:47.172793 (  14136| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ W=A]==>[1]:[PR=W]
14:35:47.173496 (  14136| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [1]:[PR=W] from queue
PR: W=A
14:35:47.732120 (  14136| 13400) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:48.804459 (  14136| 13400) processOT   (3813): Thermostat         T10010600   1 Write-Data      > TSet = 6.00 °C
14:35:48.730224 (  15480| 14696) processOT   (3813): Boiler             BD0010600   1 Write-Ack         TSet = 6.00 °C
14:35:49.797957 (  15480| 14696) processOT   (3813): Thermostat         T80730000 115 Read-Data         OEMDiagnosticCode = 0 
14:35:49.890246 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [1]
14:35:49.892479 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[1]:cmd[PR=G] (4)
14:35:49.893657 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [2]
14:35:49.739335 (  15480| 14696) processOT   (3813): Boiler             B70730000 115 Unknown-Data-Id   OEMDiagnosticCode = 0 
14:35:50.801771 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:50.098914 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [0] due
14:35:50.101263 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=N] (4)
14:35:50.109601 (  14136| 13400) handleOTGWqu(2706): CmdQueue: Queue slot [1] due
14:35:50.110409 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=G] (4)
14:35:50.138880 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: BV] (6)
14:35:50.141397 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
14:35:50.142275 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[1]:[PR=G] from queue
PR: BV
14:35:50.209286 (  12792| 12104) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: G=00] (8)
14:35:50.211219 (  12792| 12104) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
14:35:50.211958 (  12792| 12104) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[1]:[PR=G] from queue
14:35:50.214197 (  13464| 12104) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[1]:[PR=G]
14:35:50.215405 (  13464| 12104) checkOTGWcmd(2765): CmdQueue: Found value [ G=00]==>[1]:[PR=G]
14:35:50.216107 (  13464| 12104) checkOTGWcmd(2766): CmdQueue: Remove from queue [1]:[PR=G] from queue
PR: G=00
14:35:50.742846 (  12544| 12104) processOT   (3813): Boiler             B40000200   0 Read-Ack        >  Status = Slave  [--------]
14:35:51.859013 (  15424| 14696) processOT   (3813): Thermostat         T00110000  17 Read-Data         RelModLevel = 0.00 %
14:35:52.750924 (  14136| 13400) processOT   (3813): Boiler             BC0110000  17 Read-Ack        > RelModLevel = 0.00 %
14:35:52.813451 (  15480| 14696) processOT   (3813): Thermostat         T00740000 116 Read-Data         BurnerStarts = 0 
14:35:52.889751 (  15480| 14696) addOTWGcmdto(2639): CmdQueue: Adding cmd end of queue, slot [1]
14:35:52.891786 (  14136| 13400) addOTWGcmdto(2653): CmdQueue: Insert queue in slot[1]:cmd[PR=I] (4)
14:35:52.892956 (  14136| 13400) addOTWGcmdto(2674): CmdQueue: Next free queue slot: [2]
14:35:53.759235 (  13968| 13400) processOT   (3813): Boiler             B40745040 116 Read-Ack        > BurnerStarts = 20544 
14:35:53.884843 (  14136| 13400) processOT   (3813): Thermostat         T80000200   0 Read-Data       >  Status = Master [-D---W--]
14:35:53.099058 (  15480| 14696) handleOTGWqu(2706): CmdQueue: Queue slot [1] due
14:35:53.101388 (  14136| 13400) sendOTGW    (2802): Sending to Serial [PR=I] (4)
14:35:53.147317 (  15480| 14696) checkOTGWcmd(2742): CmdQueue: Checking if command is in in queue [PR: I=11] (8)
14:35:53.149926 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[0]:[PR=N] from queue
14:35:53.151126 (  14136| 13400) checkOTGWcmd(2753): CmdQueue: Checking [PR]==>[1]:[PR=I] from queue
14:35:53.151894 (  14136| 13400) checkOTGWcmd(2764): CmdQueue: Found cmd [PR]==>[1]:[PR=I]
14:35:53.152584 (  14136| 13400) checkOTGWcmd(2765): CmdQueue: Found value [ I=11]==>[1]:[PR=I]
14:35:53.153260 (  14136| 13400) checkOTGWcmd(2766): CmdQueue: Remove from queue [1]:[PR=I] from queue

[boxtel]

Ik ben nieuw in dit topic.

Ik heb even een vraag voordat ik alles teruggelezen heb.

Ik heb een Toon‑thermostaat in combinatie met een Intergas Xtreme 36‑ketel. Ik zou graag het Toon‑scherm willen vervangen. Er ligt een UTP‑kabel van het Toon‑scherm naar de Toon‑module bij de ketel.

Kan ik het Toon‑scherm vervangen door een Home Assistant‑scherm, en de ketel via een OpenTherm‑gateway bedienen binnen Home Assistant?

Op de muur heb ik verder geen ruimte voor zowel een thermostaat als een HA‑scherm. Het scherm dat ik daar wil plaatsen zal ik uiteraard PoE‑gevoed maken, omdat daar al een UTP‑kabel aanwezig is.

Graag jullie advies over welke OpenTherm‑gateway ik het beste kan gebruiken, hoe de bedrading moet worden aangesloten, en hoe de bediening in Home Assistant werkt.

ps: ik heb ook vloerverwarming

[ramonlambal]

Ik heb vorige week mijn OTGW weer een nieuw leven ingeblazen. Al een hele tijd lang had ik last van super veel reboots, icm een Wemos/wifi/mqtt connectie. Ik had al wel de PLC firmware upgedate naar 5.8, hoger kon niet. om een idee te geven, mijn reboot count stond op 2000 ofzo. Vaak verloor HA ook nog eens de MQTT connectie en moest ik de OTGW alsnog via de webpage resetten, en miste ik dus uren aan data.

Nu zag ik dat ik nooit echt de firmware van de Wemos goed had geupdate, want ik zat nog op 0.13.x ofzo. Heb de Wemos eruit gehaald, via usb geupadate naar 1.4.1 (toen de laatste stable), en alle problemen die ik ervaarde zijn verdrewenen. Geen enkele reboot meer gehad (behalve die ik zelf heb gedaan) en hij loopt echt weer super stabiel nu.

[superduper]

ramonlambal schreef op woensdag 13 mei 2026 @ 16:09:
Ik heb vorige week mijn OTGW weer een nieuw leven ingeblazen. Al een hele tijd lang had ik last van super veel reboots, icm een Wemos/wifi/mqtt connectie. Ik had al wel de PLC firmware upgedate naar 5.8, hoger kon niet. om een idee te geven, mijn reboot count stond op 2000 ofzo. Vaak verloor HA ook nog eens de MQTT connectie en moest ik de OTGW alsnog via de webpage resetten, en miste ik dus uren aan data.

Nu zag ik dat ik nooit echt de firmware van de Wemos goed had geupdate, want ik zat nog op 0.13.x ofzo. Heb de Wemos eruit gehaald, via usb geupadate naar 1.4.1 (toen de laatste stable), en alle problemen die ik ervaarde zijn verdrewenen. Geen enkele reboot meer gehad (behalve die ik zelf heb gedaan) en hij loopt echt weer super stabiel nu.

Nice. Ik heb net mijn kitje binnen en ga morgen lekker solderen en de firmwares flashen. Hopelijk bij mij ook stabiel!

Iemand toevallig een STL / 3D print design voor een behuizing? Anders ga ik die lekker zelf tekenen hoor.

[ Voor 5% gewijzigd door superduper op 13-05-2026 16:52 ]

[number3]

@ramonlambal @superduper nou, ik heb goed nieuws voor jullie. Release 1.5.0 is uit. De nodige fixes, en nog stabieler dan 1.4.1 😇

Laatste release kan je hier vinden: https://github.com/rvdbreemen/OTGW-firmware/releases/tag/v1.5.0-fix

[gazzzman61]

number3 schreef op woensdag 13 mei 2026 @ 17:53:
@ramonlambal @superduper nou, ik heb goed nieuws voor jullie. Release 1.5.0 is uit. De nodige fixes, en nog stabieler dan 1.4.1 😇

Laatste release kan je hier vinden: https://github.com/rvdbreemen/OTGW-firmware/releases/tag/v1.5.0-fix

hoe kan ik deze updaten? ik draai op versie 0.10.2

ik heb een twee binfiles gedownload (info en littlefs). maar weet niet hoe ik nu verder moet.

updaten via de otmonitor lukt niet en ook niet via de webserver via het tipadres.

[Coppertop]

gazzzman61 schreef op woensdag 13 mei 2026 @ 20:53:
[...]

hoe kan ik deze updaten? ik draai op versie 0.10.2

ik heb een twee binfiles gedownload (info en littlefs). maar weet niet hoe ik nu verder moet.

updaten via de otmonitor lukt niet en ook niet via de webserver via het tipadres.

Als je naar de filesystem browser gaat is daar de optie om te update. Aangezien je zo'n grote jump aan features gaat doen zou ik alle release notes met daarin soms de migration notes. Vooral bij versie 1.2.0. Verwacht API veranderingen en MQTT veranderingen.

Maak eerst een backup van je config, ik weet nu even niet zeker of die goed meekomt.

[gazzzman61]

Coppertop schreef op woensdag 13 mei 2026 @ 21:40:
[...]

Als je naar de filesystem browser gaat is daar de optie om te update. Aangezien je zo'n grote jump aan features gaat doen zou ik alle release notes met daarin soms de migration notes. Vooral bij versie 1.2.0. Verwacht API veranderingen en MQTT veranderingen.

Maak eerst een backup van je config, ik weet nu even niet zeker of die goed meekomt.

Dankjewel. Update is gelukt zonder problemen

[htca]

superduper schreef op woensdag 13 mei 2026 @ 16:51:
[...]

Nice. Ik heb net mijn kitje binnen en ga morgen lekker solderen en de firmwares flashen. Hopelijk bij mij ook stabiel!

Iemand toevallig een STL / 3D print design voor een behuizing? Anders ga ik die lekker zelf tekenen hoor.

Ik heb deze geprint

[gazzzman61]

Coppertop schreef op woensdag 13 mei 2026 @ 21:40:
[...]

Als je naar de filesystem browser gaat is daar de optie om te update. Aangezien je zo'n grote jump aan features gaat doen zou ik alle release notes met daarin soms de migration notes. Vooral bij versie 1.2.0. Verwacht API veranderingen en MQTT veranderingen.

Maak eerst een backup van je config, ik weet nu even niet zeker of die goed meekomt.

Vanochtend alles aangesloten, maar toch lijkt er niets niet goed gegaan. webinterface is compleet vernieuwd. er brand een groen bolletje bij connect. otmonitor werkt ook. kan alleen niet de mode instellen: deze blijft op unknown staan en ik wil m graag op monitor hebben.

ook de versie info lijkt niet te kloppen? ben nu de weg kwijt.

een paar plaatjes te verduidelijking.

[hvxl]

In de meeste gevallen moet de OTGW PIC de gateway firmware draaien, niet de diagnose firmware.

[gazzzman61]

hvxl schreef op donderdag 14 mei 2026 @ 12:10:
In de meeste gevallen moet de OTGW PIC de gateway firmware draaien, niet de diagnose firmware.

Hoe kan ik dat wijzigen?

[hvxl]

Er is ergens op de web interface een pagina waar je kunt kiezen tussen diagnose, interface en gateway firmware voor de PIC. Kies daar voor het laden van de gateway firmware.

Ik gebruik zelf de ESP firmware niet. Daarom kan ik je niet precies wijzen waar je moet zijn. Sorry.

[Compizfox]

number3 schreef op woensdag 13 mei 2026 @ 17:53:
@ramonlambal @superduper nou, ik heb goed nieuws voor jullie. Release 1.5.0 is uit. De nodige fixes, en nog stabieler dan 1.4.1 😇

Laatste release kan je hier vinden: https://github.com/rvdbreemen/OTGW-firmware/releases/tag/v1.5.0-fix

Ik heb zojuist geprobeerd 1.5.0 te flashen (vanaf 1.3.5), maar er lijkt iets niet helemaal goed te zijn gegaan.

Ik heb, zoals opgedragen in de release notes van v1.4.1, eerst het file system geflashed (dat ging nog goed), en daarna pas de firmware.

Na die tweede stap komt hij alleen niet meer online...

[superduper]

Ik ben er blij mee. OTGW pakketje komt gisteren binnen, vanmiddag half uurtje solderen, flashen, draadjes verbinden en runnen maar... Beetje kaartjes maken in Home Assistant é voilà:

[number3]

Voor wie de toch nog even wil nalezen hoe een upgrade werkt, zie hier: https://github.com/rvdbreemen/OTGW-firmware/wiki/Upgrade-to-new-release-using-Over-The-Air-flashing

[Ittie]

Ik kan me voorstellen dat deze vraag al eens eerder is gesteld, maar ik kan hem niet zo snel terugvinden op het forum. Daarom stel ik ’m toch nog even, zeker na de laatste update naar 1.5.0.
Ik draai al een paar jaar mijn OTGW van Nodo en heb deze via de OpenTherm Gateway-integratie in Home Assistant hangen.
Maar is er een duidelijke voorkeur voor het integreren van de OTGW: via MQTT of via de OpenTherm Gateway-integratie?
Biedt één van de twee meer functionaliteit, of maakt het in de praktijk weinig uit?

[number3]

@Ittie ik heb de firmware gemaakt met de intentie om MQTT integratie in home assistant te doen. Mijn motivatie om dat te doen was de betrouwbaarheid van MQTT integratie boven een seriële verbinding over wifi 🧐.

Qua functionaliteit was mijn uitgangspunt om de integratie in HA overbodig te maken. Dus als je het mij vraagt dan is MQTT HA Integratie de bedoeling en heeft mijn voorkeur :-). Je krijgt dan als bonus, een webapplicatie met daarin extra functies op de desktop waarmee je de logging kan inzien en grafieken kan maken.

Tevens kan je REST API benutten als je dat wilt.

En ja, je kan ook de seriële integratie doen. Dan is mijn firmware iets wat overkill, maar werkt ook 😉

[Ittie]

@number3 thx voor de uitleg en de effort voor de firmware. Ik ga ze gewoon eens naast elkaar draaien en dan kop of munt gooien om te bepalen welke het wordt

[superduper]

Kan je ergens aangeven welke data er via MQTT verstuurd wordt? Ben onder de indruk wat er allemaal verstuurd wordt zo op een dag; bizar veel eigenlijk (~45MB).

Zie wel dat ik wat aan mijn plaastsing moet doen; af en toe heeft hij niet de beste WiFi verbinding...

[number3]

Ittie schreef op vrijdag 15 mei 2026 @ 17:13:
@number3 thx voor de uitleg en de effort voor de firmware. Ik ga ze gewoon eens naast elkaar draaien en dan kop of munt gooien om te bepalen welke het wordt

Ik raad het af om er twee parallel te draaien. Iets met twee kapiteins op één schip. Echter ik hoor graag wat je ervaringen zijn en wat je nog mist.

[number3]

superduper schreef op vrijdag 15 mei 2026 @ 17:23:
Kan je ergens aangeven welke data er via MQTT verstuurd wordt? Ben onder de indruk wat er allemaal verstuurd wordt zo op een dag; bizar veel eigenlijk (~45MB).

Zie wel dat ik wat aan mijn plaastsing moet doen; af en toe heeft hij niet de beste WiFi verbinding...

Als je eens inlogt op de web applicatie meestal te vinden op http://otgw.local (tenzij je de naam hebt aangepast) en je doet dat vanaf een desktop PC, dan kan je de data live volgen en krijg je een goede indruk wat zoal aan data verscheept wordt over MQTT.

[number3]

gazzzman61 schreef op donderdag 14 mei 2026 @ 12:03:
[...]

Vanochtend alles aangesloten, maar toch lijkt er niets niet goed gegaan.

Het lijkt er dus op dat je per ongeluk de diagnose firmware hebt geflasht. Dat is eenvoudig oplosbaar.

In het webUI zit rechts de knop advanced, met een dropdown menu.

KIes voor de PIC software. Er verschijnt welke firmware op de PIC staat. Daaronder een tabel. Klik op de “gateway” flash knop.

Een progress balk zal het flash proces laten zien. Een reboot is het gevolg. Ververs de web applicatie even.

Als het goed gegaan is dan werkt alles weer zoals je gewend bent.

[gazzzman61]

number3 schreef op vrijdag 15 mei 2026 @ 18:34:
[...]

Het lijkt er dus op dat je per ongeluk de diagnose firmware hebt geflasht. Dat is eenvoudig oplosbaar.

In het webUI zit rechts de knop advanced, met een dropdown menu.

KIes voor de PIC software. Er verschijnt welke firmware op de PIC staat. Daaronder een tabel. Klik op de “gateway” flash knop.

Een progress balk zal het flash proces laten zien. Een reboot is het gevolg. Ververs de web applicatie even.

Als het goed gegaan is dan werkt alles weer zoals je gewend bent.

Dank voor je adviezen. Ik heb het nu goed draaien denk ik.

Wel valt me op dat mijn Weheat warmtepomp niet erg veel data doorstuurt. Misschien wordt dat in de toekomst beter?

Kan ik daarin ook iets bijdragen?

[Compizfox]

Compizfox schreef op donderdag 14 mei 2026 @ 17:34:
[...]

Ik heb zojuist geprobeerd 1.5.0 te flashen (vanaf 1.3.5), maar er lijkt iets niet helemaal goed te zijn gegaan.

Ik heb, zoals opgedragen in de release notes van v1.4.1, eerst het file system geflashed (dat ging nog goed), en daarna pas de firmware.

Na die tweede stap komt hij alleen niet meer online...

Ik heb inmiddels de ESP even uit de OTGW gehaald om hem over USB (met esptool) te flashen. Na hem weer in de OTGW te hebben gestopt, doet hij echter nog steeds niks. Hij komt niet online in mijn netwerk en hij gaat ook niet in AP mode.

@number3 enig idee wat hier misgaat?

EDIT: NVM, ik had het iets meer tijd moeten geven. Hij is weer online!

EDIT: Ik merk wel dat nu zowat elke seconde de entity opentherm_gateway_otgw_otgw_dhw_control van "auto" naar "off" springt en weer terug, wat heel veel traffic veroorzaakt. Enig idee hoe dan komt?

[ Voor 16% gewijzigd door Compizfox op 16-05-2026 21:22 ]

[caspelr]

Compizfox schreef op zaterdag 16 mei 2026 @ 19:20:
[...]EDIT: Ik merk wel dat nu zowat elke seconde de entity opentherm_gateway_otgw_otgw_dhw_control van "auto" naar "off" springt en weer terug, wat heel veel traffic veroorzaakt. Enig idee hoe dan komt?

Zelfde probleem hier. Volgens mij zegt de thermostaat dat dwh enabled aan staat en de boiler dat hij uit staat. Als ik HW=1 stuur gaat dwh enable op aan en blijft de status gelijk. Ik zet HW=0 om 12u als iedereen in bad is geweest. Was bij vorige versie niet.

[number3]

Vermoedelijk een bug in 1.5.0 is dit verandert. Ik heb een oplossing op het vizier. Tot die tijd is terugvallen op 1.4.1 een optie of even accepteren dat dit een “known” issue/bug is.

[number3]

OTGW-firmware v1.6.0 beschikbaar!

Na 25 beta builds is v1.6.0 klaar: een complete MQTT- en Home Assistant-betrouwbaarheidsupgrade, statisch IP-adres instellen, bilateraal OT-bus diagnoserapport, en een heleboel polijstwerk.

Wat is er nieuw:

• HA-entiteiten flapperen niet meer op unavailable (reparatie regressie v1.5.0)
• Statisch IP-adres configureerbaar via de webinterface
• OT-bus support map: zie welke MsgIDs je thermostaat en ketel uitwisselen
• Capability-flag bits 2-5 (koeling, zomer/winter, CH2) niet meer unknown
• MQTT proxy-answer routing gefixed, flash-scripts gehardened met SHA256-check

Download: https://github.com/rvdbreemen/OTGW-firmware/releases/tag/v1.6.0

Speciale dank aan andrebrait voor uitgebreide tests van de statisch IP-instelling over meerdere beta-rondes, en aan crashevans voor grondig beta-testen met gedetailleerde logs!

[ Voor 8% gewijzigd door number3 op 29-05-2026 07:36 ]

[Compizfox]

number3 schreef op vrijdag 29 mei 2026 @ 07:35:
OTGW-firmware v1.6.0 beschikbaar!

Na 25 beta builds is v1.6.0 klaar: een complete MQTT- en Home Assistant-betrouwbaarheidsupgrade, statisch IP-adres instellen, bilateraal OT-bus diagnoserapport, en een heleboel polijstwerk.

Wat is er nieuw:

• HA-entiteiten flapperen niet meer op unavailable (reparatie regressie v1.5.0)
• Statisch IP-adres configureerbaar via de webinterface
• OT-bus support map: zie welke MsgIDs je thermostaat en ketel uitwisselen
• Capability-flag bits 2-5 (koeling, zomer/winter, CH2) niet meer unknown
• MQTT proxy-answer routing gefixed, flash-scripts gehardened met SHA256-check

Download: https://github.com/rvdbreemen/OTGW-firmware/releases/tag/v1.6.0

Speciale dank aan andrebrait voor uitgebreide tests van de statisch IP-instelling over meerdere beta-rondes, en aan crashevans voor grondig beta-testen met gedetailleerde logs!

Thanks!

Helaas komt de ESP wederom (net als bij 1.5.0) niet meer online na het over-the-air flashen... Doe ik iets verkeerd of zit er mogelijk een bug in de OTA-flasher?

[pistole]

Compizfox schreef op vrijdag 29 mei 2026 @ 10:36:
[...]

Thanks!

Helaas komt de ESP wederom (net als bij 1.5.0) niet meer online na het over-the-air flashen... Doe ik iets verkeerd of zit er mogelijk een bug in de OTA-flasher?

Ik heb ook zojuist ge-updated en bij mij geen probleem. Is de ESP misschien in AP-mode geschoten?

[Compizfox]

pistole schreef op vrijdag 29 mei 2026 @ 10:50:
[...]

Ik heb ook zojuist ge-updated en bij mij geen probleem. Is de ESP misschien in AP-mode geschoten?

Nope. Na hem over USB (met ESPTool) opnieuw te hebben geflashed, doet hij het weer. De vorige keer had ik hetzelfde issue.

[Cyberpope]

number3 schreef op vrijdag 29 mei 2026 @ 07:35:
OTGW-firmware v1.6.0 beschikbaar!

Na 25 beta builds is v1.6.0 klaar: een complete MQTT- en Home Assistant-betrouwbaarheidsupgrade, statisch IP-adres instellen, bilateraal OT-bus diagnoserapport, en een heleboel polijstwerk.

Wat is er nieuw:

• HA-entiteiten flapperen niet meer op unavailable (reparatie regressie v1.5.0)
• Statisch IP-adres configureerbaar via de webinterface
• OT-bus support map: zie welke MsgIDs je thermostaat en ketel uitwisselen
• Capability-flag bits 2-5 (koeling, zomer/winter, CH2) niet meer unknown
• MQTT proxy-answer routing gefixed, flash-scripts gehardened met SHA256-check

Download: https://github.com/rvdbreemen/OTGW-firmware/releases/tag/v1.6.0

Speciale dank aan andrebrait voor uitgebreide tests van de statisch IP-instelling over meerdere beta-rondes, en aan crashevans voor grondig beta-testen met gedetailleerde logs!

Ik denk niet voor mijn oude OTGW (de orginele) of wel?

[krijn1985]

Compizfox schreef op vrijdag 29 mei 2026 @ 12:09:
[...]

Nope. Na hem over USB (met ESPTool) opnieuw te hebben geflashed, doet hij het weer. De vorige keer had ik hetzelfde issue.

Welke volgorde flash je? Ik deed perongeluk eerst LittleFS bij upgrade naar 1.5 echter toen kwam hij ook niet meer online (stond natuurlijk ook eerst INO dan LittleFS in 1.5 relase notes). Dus moest ook even met USBkael aan de gang. Echter van 1.4 naar 1.5 en 1.6 ging het prima.

[Compizfox]

krijn1985 schreef op vrijdag 29 mei 2026 @ 15:03:
[...]

Welke volgorde flash je? Ik deed perongeluk eerst LittleFS bij upgrade naar 1.5 echter toen kwam hij ook niet meer online (stond natuurlijk ook eerst INO dan LittleFS in 1.5 relase notes). Dus moest ook even met USBkael aan de gang. Echter van 1.4 naar 1.5 en 1.6 ging het prima.

Voor v1.5 heb ik eerst het filesystem geflashed, dan de firmware (zoals opgedragen in de release notes van v1.4.1). Na die tweede stap kwam hij niet meer online.

Voor v1.6 stond dat het filesystem ongewijzigd was sinds 1.5, dus ik heb alleen de firmware geflashed.

Compizfox schreef op donderdag 14 mei 2026 @ 17:34:
[...]

Ik heb zojuist geprobeerd 1.5.0 te flashen (vanaf 1.3.5), maar er lijkt iets niet helemaal goed te zijn gegaan.

Ik heb, zoals opgedragen in de release notes van v1.4.1, eerst het file system geflashed (dat ging nog goed), en daarna pas de firmware.

Na die tweede stap komt hij alleen niet meer online...

[ Voor 25% gewijzigd door Compizfox op 29-05-2026 15:12 ]

[krijn1985]

Compizfox schreef op vrijdag 29 mei 2026 @ 15:10:
[...]

Voor v1.5 heb ik eerst het filesystem geflashed, dan de firmware (zoals opgedragen in de release notes van v1.4.1). Na die tweede stap kwam hij niet meer online.

Voor v1.6 stond dat het filesystem ongewijzigd was sinds 1.5, dus ik heb alleen de firmware geflashed.


[...]

En dit staat in de release notes van 1.5:

1. Flash firmware (*.ino.bin) via the Web UI update page
2. Flash filesystem (*.littlefs.bin) via the same page — export settings first, the image is a fresh content bundle

Ik had dit dus ook verkeerd om gedaan en toen kwam hij niet up.

[Compizfox]

krijn1985 schreef op vrijdag 29 mei 2026 @ 16:50:
[...]

En dit staat in de release notes van 1.5:


[...]

Ik had dit dus ook verkeerd om gedaan en toen kwam hij niet up.

Ja, maar ik kwam van v1.3.5, en in de release notes van v1.4.1 staat:

CRITICAL: Flash filesystem FIRST, then firmware. The Arduino Core 3.1.2 upgrade changed the LittleFS partition from 1 MB to 2 MB. Flashing in the correct order (filesystem first, firmware second) preserves your settings. If you mistakenly flash the firmware first, the new firmware boots against the old 1 MB layout and spends 5-10 minutes reformatting the 2 MB partition on first boot — the device is unresponsive during that time and all settings are lost. Always flash the filesystem binary before the firmware binary.


Download both OTGW-firmware-*.ino.bin and OTGW-firmware-*.littlefs.bin from this release.
Flash the filesystem binary first via the Web UI update page.
Flash the firmware binary second, immediately after.
Hard-refresh the browser (Ctrl+F5).

Flashing in this order preserves your settings. No settings migration required. The new MQTTdiscoveryAutoVerify setting defaults to true. If you run on a shared MQTT broker with tight wildcard ACLs, set it to false.

Hoe dan ook, met v1.6 had ik weer hetzelfde probleem.

[ Voor 26% gewijzigd door Compizfox op 29-05-2026 16:57 ]

[krijn1985]

Compizfox schreef op vrijdag 29 mei 2026 @ 16:56:
[...]

Ja, maar ik kwam van v1.3.5, en in de release notes van v1.4.1 staat:


[...]


Hoe dan ook, met v1.6 had ik weer hetzelfde probleem.

Dat weet ik daarom had ik het ook "verkeerd" om gedaan. Had je bij update naar 1.6 weer zelfde volgorde aangehouden? Dus eerst filesysteem en toen firmware?

[superduper]

Bij mij gelukt. Moest even flink zoeken naar de pagina waar de flash met eigen bestand zat, maar gevonden. Eerst de ino gedaan, maar toen gaf de OTGW toch aan dat er een mismatch was met de littlefs, dus toen die daarna ook gedaan.

Werkt allemaal prima tot op dit moment.

[number3]

@Compizfox voor 1.4.1 was dat inderdaad de instructie, dit kwam door de nieuwe grootte van de flash partitie voor het filesysteem en de upgrade naar de nieuwe Arduino ESP core. Echter, dat is in 1.5.0 teruggedraaid, de ESP core is nu weer terug naar 2.7.4, dat werkt stabieler... Vervolgens is het in 1.6.0 gewoon zo dat je de firmware en dan het filesysteem (of omgekeerd) kan flashen.

Echter, vastlopen zou niet mogen, een reboot van de ESP werkt meestal EN als dat echt niet werkt, dan is een ESP flash over USB vaak de goede oplossing. Vervelend maar het is wel vaak de enige oplossing waarmee je verder komt.

Hoop dat 1.6.0 het verder goed voor je doet, als je opmerkingen hebt, verbeteringen of bugs vindt, dan graag melden... hier, op github issues of op de discord van mij.

[number3]

krijn1985 schreef op vrijdag 29 mei 2026 @ 17:06:
[...]

Dat weet ik daarom had ik het ook "verkeerd" om gedaan. Had je bij update naar 1.6 weer zelfde volgorde aangehouden? Dus eerst filesysteem en toen firmware?

@krijn1985 dat is dus niet nodig na 1.5.0, was echt eenmalig. Eerst de firmware en dan het filesysteem. Als je het filesysteem niet upgrade, krijg je een vriendelijke en dringende banner die je aangeeft dat dat nog wel moet.

Goede nieuws is je settings blijven dan weer als gewoon werken.

[hvxl]

Cyberpope schreef op vrijdag 29 mei 2026 @ 14:54:
[...]

Ik denk niet voor mijn oude OTGW (de orginele) of wel?

De naam is een beetje misleidend. Deze firmware is niet voor de OTGW PIC, maar voor de NodeMCU of Wemos D1 mini die in eerste instantie bij de wifi versie van de OTGW van de Nodo shop werd ingezet als RS232 naar wifi interface. Maar de esp8266 van deze bordjes kan veel meer, zoals de firmware van Robert bewijst.

De originele OTGW had geen NodeMCU of Wemos D1 mini. Dus dan is deze firmware niet bruikbaar. Dat geldt ook voor de LAN, USB en seriële versies van de OTGW die door de Nodo shop worden verkocht.

[krijn1985]

number3 schreef op vrijdag 29 mei 2026 @ 21:25:
[...]

@krijn1985 dat is dus niet nodig na 1.5.0, was echt eenmalig. Eerst de firmware en dan het filesysteem. Als je het filesysteem niet upgrade, krijg je een vriendelijke en dringende banner die je aangeeft dat dat nog wel moet.

Goede nieuws is je settings blijven dan weer als gewoon werken.

Ik deed altijd eerst firmware daarna filesysteem, maar vandaag dus na de upgrade van 1.4.1 deed ik het andersom wat bij 1.5 problemen gaf. Maar was ook zo weer opgelost met USB kabel.

[number3]

@krijn1985 dankt oor de terugkoppeling. Vreemd. Dus dan toch maar weer firmware en filesystem voortaan. Geen idee waardoor het fout gaat soms.

[superduper]

@number3 Ik ben nog steeds superhappy met de otgw en de implementatie in HA. Er is één ding wat ik er nog heel graag in zou hebben:

Mijn ketel (Atag i28c) heeft een ECO stand waardoor hij niet de boilder voor heet tapwater op temp blijft houden. Dat scheelt echt nog wel wat gas per dag. Alleen is het irritante dat hij regelmatig 'spontaan' van die ECO stand af valt. Ik zou daar heel graag een seintje van krijgen, maar kan in de MQTT gegevens of in de OTGW gateway niet zien of die ECO flag wordt uitgelezen of gerapporteerd.

Heb je hier een tip voor hoe ik dat zou kunnen aanpakken?

[pistole]

superduper schreef op vrijdag 5 juni 2026 @ 10:51:
@number3 Ik ben nog steeds superhappy met de otgw en de implementatie in HA. Er is één ding wat ik er nog heel graag in zou hebben:

Mijn ketel (Atag i28c) heeft een ECO stand waardoor hij niet de boilder voor heet tapwater op temp blijft houden. Dat scheelt echt nog wel wat gas per dag. Alleen is het irritante dat hij regelmatig 'spontaan' van die ECO stand af valt. Ik zou daar heel graag een seintje van krijgen, maar kan in de MQTT gegevens of in de OTGW gateway niet zien of die ECO flag wordt uitgelezen of gerapporteerd.

Heb je hier een tip voor hoe ik dat zou kunnen aanpakken?

Volgens mij is dat de 'Domestic Hot Water Enabled' in de web interface of HW=1 (comfort aan) / HW=0 (comfort uit). In ieder geval is dat met mijn Intergas het geval.

[superduper]

pistole schreef op vrijdag 5 juni 2026 @ 12:09:
[...]

Volgens mij is dat de 'Domestic Hot Water Enabled' in de web interface of HW=1 (comfort aan) / HW=0 (comfort uit). In ieder geval is dat met mijn Intergas het geval.

ok, thanks. Dan ga ik die eens in de gaten houden. Het zou bij mij dan precies andersom zijn: comfort =! Eco mode

edit:
het lijkt bij mij "domestic hot water status" te zijn. Die zie ik wel als ik direct op de opentherm pagina kijk, maar zie ik niet terug in de MQTT? Of is dit eignelijk de DHW vraag ja of nee? Als ik de ECo mode toggle dan gaat hij natuurlijk eerst even opwarmen. Maar de status van DMHW enabled veranderd niet of ik ECO aan of uit zet.

[ Voor 51% gewijzigd door superduper op 05-06-2026 12:50 ]

[pistole]

superduper schreef op vrijdag 5 juni 2026 @ 12:15:
[...]

ok, thanks. Dan ga ik die eens in de gaten houden. Het zou bij mij dan precies andersom zijn: comfort =! Eco mode

edit:
het lijkt bij mij "domestic hot water status" te zijn. Die zie ik wel als ik direct op de opentherm pagina kijk, maar zie ik niet terug in de MQTT? Of is dit eignelijk de DHW vraag ja of nee? Als ik de ECo mode toggle dan gaat hij natuurlijk eerst even opwarmen. Maar de status van DMHW enabled veranderd niet of ik ECO aan of uit zet.

[Afbeelding]

Mijn interpretatie hiervan is: "domestic hot water status" geeft aan of er warm water geproduceerd wordt, ongeacht of er daadwerkelijk getapt wordt.

In de praktijk zie ik dat als ik "domestic hot water" aanzet, dat ook bovengenoemde aangaat om het water op temperatuur te brengen.

In jouw geval zou ik dus een monitor maken die periodiek de status van "domestic hot water" controleert, en if aan then HW=0 sturen.

[superduper]

pistole schreef op vrijdag 5 juni 2026 @ 14:26:
[...]

Mijn interpretatie hiervan is: "domestic hot water status" geeft aan of er warm water geproduceerd wordt, ongeacht of er daadwerkelijk getapt wordt.

In de praktijk zie ik dat als ik "domestic hot water" aanzet, dat ook bovengenoemde aangaat om het water op temperatuur te brengen.

In jouw geval zou ik dus een monitor maken die periodiek de status van "domestic hot water" controleert, en if aan then HW=0 sturen.

Inderdaad. De status is de warm water vraag onafhankelijk van de ECO status of niet. Als je van status ECO on > off gaat, is dat even gelijk aan warm water vraag dus dat was even verwarrend.

Blijft dus staan dat ik niet kan zien wanneer de ECO status veranderd want dat is niet gelinkt aan DMHW enabled ON of OFF. Deze blijft bij mij constant op ON staan.

[Compizfox]

superduper schreef op vrijdag 5 juni 2026 @ 15:04:
[...]

Inderdaad. De status is de warm water vraag onafhankelijk van de ECO status of niet. Als je van status ECO on > off gaat, is dat even gelijk aan warm water vraag dus dat was even verwarrend.

Blijft dus staan dat ik niet kan zien wanneer de ECO status veranderd want dat is niet gelinkt aan DMHW enabled ON of OFF. Deze blijft bij mij constant op ON staan.

Is die eco-stand niet gewoon hetzelfde als wat in de OTGW "Domestic Hot Water Enabled" is? Of ja, het omgekeerde eigenlijk. In jouw screenshot lijkt de eco-stand dus uit te staan op dat moment.

[superduper]

Compizfox schreef op vrijdag 5 juni 2026 @ 16:02:
[...]

Is die eco-stand niet gewoon hetzelfde als wat in de OTGW "Domestic Hot Water Enabled" is? Of ja, het omgekeerde eigenlijk. In jouw screenshot lijkt de eco-stand dus uit te staan op dat moment.

Nee. Als ik de ECO stand toggle dan veranderd de OTGW "Domestic Hot Water Enabled" niet. Deze is eigenlijk sinds het aansluiten ook niet veranderd en staat continu op 'on'

[hvxl]

De meeste ketels hebben drie standen voor warm water. De benamingen kunnen verschillen, maar het komt neer op: eco, auto, comfort. In de "eco" stand wordt er geen water op temperatuur gehouden. In de "comfort" stand wordt er juist altijd water warm gehouden. Alleen in de auto stand kan de aangesloten thermostaat (of OTGW) het regelen. In dat geval zou een (eenmalige) HW=0 moeten voorkomen dat er ongewenst gas wordt verbruikt.
Als ik de handleiding van de Atag i28c lees, lijkt er op deze ketel geen "auto" stand te zijn. In plaats daarvan is er een "timed" stand, waarbij je een schema kunt invoeren voor wanneer er warm water op voorraad moet zijn.
Binnen het Opentherm protocol is MsgID 99 gedefinieerd voor het wijzigen van de comfort mode. Maar volgens de compatibiliteitsmatrix wordt dit bericht niet ondersteund door de i28c.
Kortom, er lijkt bij deze ketel niet echt een mogelijkheid te bestaan om deze situatie te detecteren en al helemaal niet om de eco mode automatisch te herstellen.

[superduper]

hvxl schreef op vrijdag 5 juni 2026 @ 16:42:
De meeste ketels hebben drie standen voor warm water. De benamingen kunnen verschillen, maar het komt neer op: eco, auto, comfort. In de "eco" stand wordt er geen water op temperatuur gehouden. In de "comfort" stand wordt er juist altijd water warm gehouden. Alleen in de auto stand kan de aangesloten thermostaat (of OTGW) het regelen. In dat geval zou een (eenmalige) HW=0 moeten voorkomen dat er ongewenst gas wordt verbruikt.
Als ik de handleiding van de Atag i28c lees, lijkt er op deze ketel geen "auto" stand te zijn. In plaats daarvan is er een "timed" stand, waarbij je een schema kunt invoeren voor wanneer er warm water op voorraad moet zijn.
Binnen het Opentherm protocol is MsgID 99 gedefinieerd voor het wijzigen van de comfort mode. Maar volgens de compatibiliteitsmatrix wordt dit bericht niet ondersteund door de i28c.
Kortom, er lijkt bij deze ketel niet echt een mogelijkheid te bestaan om deze situatie te detecteren en al helemaal niet om de eco mode automatisch te herstellen.

Ah, ok. Dat is dan duidelijk een geval van jammer, maar helaas. Bedankt voor het uitzoeken, ik had dit niet gevonden zo.

[xtr3me]

Hoe zit dit met de Remeha Tzerra M, kan ik hiermee de comfort stand uitschakelen of moet ik toch uitwijken naar een iSense? (ik gebruik nu een Honeywell Lyric T6)
Volgens de matrix reageert de ketel goed op read requests op MSG 99, maar dat is denk ik niet voldoende?

[hvxl]

De Tzerra M heeft de "normale" opties: Comfort/ECO/Regelaar afhankelijk (parameter P4). Als je die op ECO (1) zet, zal hij nooit water warm houden. Op regelaar afhankelijk (2) is het vanaf de OTGW of de thermostaat te regelen. Dit heeft allemaal MsgID 99 niet nodig.

Als je het leuk vindt, zou je eens met het MW commando kunnen experimenteren. Ik heb die functionaliteit aan de hand van de specificatie gemaakt. Maar aangezien mijn ketel MsgID 99 niet ondersteund, heb ik het nooit in de praktijk kunnen testen. Ik zou dan ook graag de resultaten horen.

[xtr3me]

Ik heb helaas nog geen OTGW in bezit, ik twijfel om hem aan te schaffen of op marktplaats een isense thermostaat aan te schaffen en het daarmee 2x per jaar om te zetten. (in de winter wil ik hem aan hebben staan, in de lente wil ik hem uit zetten).

Het gaat om een vakantie huisje en die comfort stand zorgt in de winter voor net genoeg warmte om het in het schuurtje vorst vrij te houden verwacht ik.

[hvxl]

De Tzerra M heeft een vorstbeveiliging functie. Is er een reden om aan te nemen dat die niet afdoende is in jouw situatie? Ik verwacht dat die optie veel minder gas gebruikt dan de ketel de hele winter water warm te laten houden, ook als het helemaal niet zo koud is.

[jaronbor]

number3 schreef op vrijdag 29 mei 2026 @ 07:35:
OTGW-firmware v1.6.0 beschikbaar!

Na 25 beta builds is v1.6.0 klaar: een complete MQTT- en Home Assistant-betrouwbaarheidsupgrade, statisch IP-adres instellen, bilateraal OT-bus diagnoserapport, en een heleboel polijstwerk.

Wat is er nieuw:

• HA-entiteiten flapperen niet meer op unavailable (reparatie regressie v1.5.0)
• Statisch IP-adres configureerbaar via de webinterface
• OT-bus support map: zie welke MsgIDs je thermostaat en ketel uitwisselen
• Capability-flag bits 2-5 (koeling, zomer/winter, CH2) niet meer unknown
• MQTT proxy-answer routing gefixed, flash-scripts gehardened met SHA256-check

Download: https://github.com/rvdbreemen/OTGW-firmware/releases/tag/v1.6.0

Speciale dank aan andrebrait voor uitgebreide tests van de statisch IP-instelling over meerdere beta-rondes, en aan crashevans voor grondig beta-testen met gedetailleerde logs!

Dank voor al het goede werk hierin!

Ik draaide afgelopen halfjaar stabiel met otgw 1.3.5 i.c.m. Home assistant en Weheat Sparrow warmtepomp.

Na upgrade naar 1.6.1 (eerst littlefs daarna firmware geflashed) werd de verbinding instabiel, otgw_boiler_connected en andere status entiteiten flipperden elke paar minuten van "ON" naar unavailable en ik kreeg crashes in otgw met "Access to invalid address (29)."

Na terug flashen naar 1.3.5 is het weer stabiel. Doe ik iets verkeerd?

[tjanssen]

jaronbor schreef op vrijdag 19 juni 2026 @ 12:48:
[...]

Dank voor al het goede werk hierin!

Ik draaide afgelopen halfjaar stabiel met otgw 1.3.5 i.c.m. Home assistant en Weheat Sparrow warmtepomp.

Na upgrade naar 1.6.1 (eerst littlefs daarna firmware geflashed) werd de verbinding instabiel, otgw_boiler_connected en andere status entiteiten flipperden elke paar minuten van "ON" naar unavailable en ik kreeg crashes in otgw met "Access to invalid address (29)."

Na terug flashen naar 1.3.5 is het weer stabiel. Doe ik iets verkeerd?

Ik heb hetzelfde probleem. Apparaat valt steeds van de WiFi af, een hoop packet loss met pingen.

Edit: heb ook terug geflashed naar 1.3.5, nu ook weer stabiel. Lijkt wel of de MCU met 1.6.1 druk bezig is met iets wat de packet loss veroorzaakt. En hiermee vervolgens stopt wanneer je een file upload voor een upgrade (ino dan wel littlefs), want tijdens uploaden is er geen packet loss..

[ Voor 17% gewijzigd door tjanssen op 19-06-2026 15:37 ]

[number3]

Ik was vorige week op zoek naar de oorzaak met een andere gebruiker van mijn firmware.

Zouden jullie een log willen maken van jullie situatie met dit script: https://github.com/rvdbreemen/OTGW-firmware/blob/dev/scripts/capture-mqtt-debug.bat

Mag via Discord of hier gedeeld worden.

[tjanssen]

number3 schreef op vrijdag 19 juni 2026 @ 23:42:
Ik was vorige week op zoek naar de oorzaak met een andere gebruiker van mijn firmware.

Zouden jullie een log willen maken van jullie situatie met dit script: https://github.com/rvdbreemen/OTGW-firmware/blob/dev/scripts/capture-mqtt-debug.bat

Mag via Discord of hier gedeeld worden.

Ga ik regelen. Zal ook proberen vanaf welke versie het probleem erin gekomen is. Moet ik bij iedere update ook de littlefs flashen? Of is alleen de ino afdoende?

[number3]

Ja. Some update the html / js en daarom altijd ook het filesystem updaten.

[tjanssen]

@number3 ik ben wat aan het rommelen met de verschillende firmware versies. Het disconnect probleem lijkt gekomen in 1.6.0. De log staat hier.

Ik denk dat het niet echt bruikbare informatie bevat. Apparaat valt continue van de WiFi. Na eindeloos proberen heb ik 'm terug kunnen flashen naar 1.5.0. Nu is het WiFi signaal niet super sterk op de plek waar mijn OTGW staat, maar met 1.5.0 heb ik dus geen disconnects...

[number3]

Dank je wel. Dit is behulpzaam. Intussen heb een reeks testen en het lijkt er sterk op dat het verwijderen van een delay(1) in de mainloop de root cause is. Snap nog niet goed wat de reden is dat dat zoveel impact heeft.

Er draait bij mij nu een regressie test om te checken of dat echt zo is.

Ik zal je log meenemen in de verdere analyse.

[tjanssen]

number3 schreef op maandag 22 juni 2026 @ 07:10:
Dank je wel. Dit is behulpzaam. Intussen heb een reeks testen en het lijkt er sterk op dat het verwijderen van een delay(1) in de mainloop de root cause is. Snap nog niet goed wat de reden is dat dat zoveel impact heeft.

Er draait bij mij nu een regressie test om te checken of dat echt zo is.

Ik zal je log meenemen in de verdere analyse.

Graag gedaan! Ik hoor het wel als je een eventuele fix wilt testen. Ik kom er nu thuis wel mee weg als de thermostaat een tijdje offline is...

edit:
Wellicht ten overvloede, maar ik maak gebruik van de legacy otmonitor op TCP port 25238

[ Voor 8% gewijzigd door tjanssen op 22-06-2026 07:54 ]

[number3]

@tjanssen de test hebben een fix opgeleverd. Er is een beta build die getest moet worden. Als je die wilt testen, heel graag.

Handigste is dan in de discord community melden, dan voeg ik je toe aan het beta test kanaal.

[tjanssen]

number3 schreef op dinsdag 23 juni 2026 @ 07:29:
@tjanssen de test hebben een fix opgeleverd. Er is een beta build die getest moet worden. Als je die wilt testen, heel graag.

Handigste is dan in de discord community melden, dan voeg ik je toe aan het beta test kanaal.

Thanks! Heb me zojuist aangemeld op je kanaal.

[number3]

@jaronbor er is een nieuwe beta 1.7.0-beta.34 die lijkt het gemelde issue op te lossen. Zoek nog mensen die dat probleem hadden met 1.6.x en deze beta willen valideren, zodat ik een release kan doen.

[Ittie]

@number3 ook ik heb er regelmatig last van. Het rare is dat af en toe na een reboot van de AP het weg is. Dus ik kan/wil die beta ook wel testen. GitHub?

[number3]

Inderdaad kan je de beta op GitHub downloaden: https://github.com/rvdbreemen/OTGW-firmware/releases/tag/v1.7.0-beta.34

Als je het beta kanaal op Discord wilt joinen kan je daar ook rechtstreeks feedback geven.

[number3]

Na diverse validaties van 1.7.0 beta is de nieuwe release een feit, de belangrijkste issues die opgelost zijn:

• Crashproofing van de firmware, de releases sinds 1.6.x bevatten een bug, waardoor HEAP framentatie optrad, met random reboots tot gevolg.
• Flink meer HEAP ruimte door refactoring van aantal geheugen vretende constructies.
• Active gateway overrides nu zichtbaar in UI en MQTT, duidelijkheid voor gebruiker (werkt mijn override of niet kan je nu zien in het interface of op MQTT)
• Wifi kwaliteit toegevoegd aan telnet banner, handig voor debug op afstand.
• Capture script sterk verbeterd voor debug en testing, als gebruikers problemen melden is met dit script eenvoudig een log transcriptie van de situatie te maken, waardoor beter zicht gekregen / gegeven kan worden op de issues die de gebruiker ervaart.
• Reeks bug fixes, van int16 naar uint16, handig als je poortnummers boven de 32677 wilt gebruiken.

Voor deze release waren de melders van de issues, maar ook vooral het testwerk van GeorgeZ83 op de discord, cruciaal om de problemen te doorgronden. De hulp heeft nu een zeer stabiele release tot gevolg, met ontzettend veel vrij heap geheugen. En dat heeft weer een positief effect op de stabiliteit van de firmware.

Installeren van de firmware en filesysteem zoals gewoonlijk over de air mogelijk, maar via USB is er nu ook een script meegeleverd voor de windows gebruikers in de release bestanden:
https://github.com/rvdbreemen/OTGW-firmware/releases/tag/v1.7.0

Problemen, verbetervoorstellen, bugs, patches, of gewoon vragen, dat kan hier op Tweakers, op github issues of op mijn Discord server.

Veel plezier met deze release,

Groet,

Robert

[jelvank]

Ik heb al een paar jaar een TripleSolar PVT systeem dat kan koelen en verwarmen op basis van OpenTherm. Ik heb daarvoor een HoneyWell Round Modulation Heat Cool aangesloten met een OTGW (van nodoshop) ertussen. In de winter stuur ik via HA een programma naar de OTGW en dat werkt prima.

Wat niet goed werkt, is het aansturen/schakelen van koeling en dan het switchen tussen verwarmen en koelen. Ik gebruikte het koelen niet zo vaak, maar het is nu toch wel handig om te hebben... Je kunt de HeatCool instellen op verwarmen, op koelen of op automatisch zetten. Bij automatisch kan je dan een ondertemperatuur (voor verwarmen) en boventemperatuur (voor koelen) instellen, maar HA herkent dat niet. Via de HA integratie is de thermostaat sinds ik deze modus heb geactiveerd, op magische wijze veranderd in een koelthermostaat, maar schakelen naar verwarmen kan nu niet. Bij Mode kan je niet kiezen, de enige optie is nu koelen.

In een poging dit op te lossen, heb ik de OTGW nu aan mijn MQTT gehangen, omdat ik las dat MQTT beter werkt, maar hoewel ook daar "cooling" op aan staat, is die thermostaat een verwarmingsthermostaat die uit zou staan. Het setpoint is overigens weer wél het cooling setpoint. Bij Mode kan je kiezen tussen Verwarmen of Uit.

Ik zie een sensor "Heat Cool Mode Control" die op Uit staat, maar ik kan daar verder niets over vinden. Iemand een idee wat ik zou kunnen doen?

[hvxl]

Zou je een log met OTmonitor kunnen maken van hoe die HeatCool de zaak aanstuurt in koel mode? Dan kan ik kijken of ik nog iets aan de PIC code moet toevoegen om dat op de juiste manier met de OTGW te doen.

[number3]

En ik ben ook geïnteresseerd in je logging. Want dan kan ik eventueel een update doen van de firmware als daar nog iets schort.

Als je dit capture script gebruikt op de nieuwste firmware 1.7.0 dan krijgen we gedetailleerde logs:

https://github.com/rvdbreemen/OTGW-firmware/blob/main/scripts/capture-mqtt-debug.bat#L9

[jelvank]

number3 schreef op vrijdag 26 juni 2026 @ 19:23:
En ik ben ook geïnteresseerd in je logging. Want dan kan ik eventueel een update doen van de firmware als daar nog iets schort.

Als je dit capture script gebruikt op de nieuwste firmware 1.7.0 dan krijgen we gedetailleerde logs:

https://github.com/rvdbreemen/OTGW-firmware/blob/main/scripts/capture-mqtt-debug.bat#L9

Kijk, ik dacht dat ik iets kon/moest doen om dit op te lossen, maar ook fijn als jullie iets kunnen doen

Dat script staat nu te draaien. Zal ik even een issue aanmaken en niet die hele log hier dumpen.

[number3]

@jelvank vermoed dst de bug in de climate entity configuratie zit als ik je verhaal lees. Dat is dan een kwestie van een fix aan de HA kant. Fijn dat je de logs hebt gedeeld. Ik zal erna kijken.

[number3]

@jelvank er is een beta 1.7.1 met een fix voor je issue dat je ervaart. Ik zou je willen vragen om het te testen en vooral te valideren, zie het github issue voor meer informatie.

https://github.com/rvdbreemen/OTGW-firmware/issues/665#issuecomment-4817177926

Voor alle andere warmtepomp gebruikers met koeloptie, dit zou de fix moeten zijn zodat je ook vanuit een home assistant integratie de koeling kan bedienen. Elke validatie van deze beta helpt, dus graag jullie hulp bij het valideren in deze warme periode.

[jelvank]

Thanks voor de snelle reactie en actie! Ik heb de eerste snelle testresultaten in het issue gezet. Ik moet zeggen dat ik, gezien de beperkingen van OpenTherm wel begin te twijfelen of ik die hele HeatCool niet weg moet halen en vervangen door een simpele temperatuursensor aan de gateway. Ik heb ooit contact gehad met TripleSolar omdat ik vond dat mijn warmtepomp nogal vaak aan en uit ging als de kamertemperatuur in de buurt van het setpoint was. Maar ze legden toen uit dat die warmtepomp echt niets meer doet dan aan of uitgaan op basis van de vraag van de thermostaat. Dus als je minder hysterisch gedrag wil, moet je een andere thermostaat nemen. Alleen zijn er weinig die kunnen koelen en verwarmen. Met andere woorden: voor deze warmtepomp doet de thermostaat niet echt iets slims qua moduleren e.d.

Nu blijkt dat ik ook niet via HA laag en hoog setpoint kan aansturen, behalve als ik dat precies time met een moment dat hij toevallig aan het koelen of verwarmen is, wordt het wel een jammer verhaal zeg maar.

Dus heb ik twee opties:

1. OTGW als thermostaat gaan draaien, dat raden jullie geloof ik niet echt aan, maar ik twijfel of het in mijn geval misschien toch de simpeler oplossing is. Voordeel: dan krijg ik wel alle data terug uit de warmtepomp over wat hij aan het doen is.
2. Er zijn ook 2 gewone aan/uit contacten: verwarmen en koelen... Alleen dan dus geen data retour. Ik heb wel begrepen dat er een modbus verbinding is, maar die zal ik dan waarschijnlijk zelf moeten gaan reverse engineeren...

[hvxl]

Er zijn vooralsnog geen wijzigingen van de PIC firmware nodig, begrijp ik? Je zou verwarming nog gewoon door een thermostaat kunnen laten regelen en alleen het koelen via de OTGW doen. Bij koelen is het minder belangrijk om de temperatuur heel constant te houden, dus is zelf aansturen ook minder ingewikkeld en volstaat een simpeler algoritme. De OTGW PIC firmware heeft de CE en CL commando's om koeling aan te sturen. Je zou daar eens mee kunnen experimenteren.

[tjanssen]

@number3 ik heb van het weekend weer een disconnect gehad. Kun je een uptime sensor toevoegen? Dan is een eventuele reset ook gemakkelijk te zien.

[number3]

@tjanssen er is een uptime gepubliceerd op MQTT. Echter nog niet een auto Discovery sensor. Zal hem toevoegen in de volgende beta.

[koningvaagheid]

blauwe eend schreef op zaterdag 1 juni 2024 @ 15:23:
Ik post graag even mijn bevindingen over de Nefit Proline HRC 24/CW4 ketel en Nefit Moduline 400 thermostaat zodat andere mensen niet de zelfde rabbit hole in gaan fout als ik maken .

Heb je de Nefit Proline HRC 24/CW4 (of de nieuwere Nefit Proline NXT HRC 24/CW4)? Dan is home automation geen optie (zie OTGW website: MsgID 9 (Remote override room setpoint) wordt helaas niet ondersteund door deze ketel, dus het op afstand bedienen via bijvoorbeeld home assistant zal dan niet lukken.
Als extra zoektherm. De Nefit Moduline 400 (dan wel moduline 300, 200 of 100 zo neem ik even aan) spreken allemaal de taal van de Nefit Proline HRC 24 ketel. Helaas is dit niet het opentherm en zou je een zogenaamde Nefit OT converter nodig hebben. In de matrix op de otgw website staat dit aangegeven met '+ EMS OT' achter de ketel naam.

Conclusie, heb je deze ketel of thermostaat. Dan is OTGW via de deze weg in ieder geval geen optie naar mijn weten. Gelukkig is deze ketel al vrij oud, dus de kans dat je binnenkort een ander nodig hebt en je er eentje kan kiezen die wel de OTGW ondersteund is stukken hoger

Heb een Nefit Proline NXT HRC 24/CW4 en heb voor dit bericht te zien een OTGW UTP van Nodo aangeschaft. In eerste instantie met de Nefit Moduline 1010 geprobeerd (de originele), maar dat werkte niet. Vervolgens op Marktplaats een Honeywell Round Modulation T87M2018 op de kop getikt (mooi ding) en met de ketel verbonden, hierdoor schakelde deze waarschijnlijk over naar het OpenTherm-protocol. De OTGW er tussen gezet en met de Home Assistant integratie kan ik nu de temperatuurinstelling van de Honeywell T87M2018 wijzigen, lijkt allemaal mooi te werken.

Wel dienen er een aantal data-id's in de OTGW te worden aangeroepen als men deze wil weten, omdat de Honeywell hier niet om vraagt (bijvoorbeeld: AA=18 voor de waterdruk). Nog geen hele duidelijke handleiding gevonden hoe dit allemaal te doen in combinatie met Home Assistant, maar met AI en geduld lukt er veel.

Kortom, de Nefit Proline NXT HRC 24/CW4 kan dus wel werken met de OTGW, mits men de juiste thermostaat gebruikt (de aloude Honeywell Round).

[DjoeC]

Ik heb een Nodo shop OTGW met Wemos. De blauwe Wemos LED knippert, verbinding werkt. Maar de 3 LED's op de OTGW zelf staan op oranje-rood-groen en ik kan eigenlijk nergens een beschrijving vinden van de kleuren en de betekenis daarvan.

Is er ergens een overzichtje van de betekenis van die LED's?

[krijn1985]

DjoeC schreef op maandag 17 augustus 2026 @ 13:43:
Ik heb een Nodo shop OTGW met Wemos. De blauwe Wemos LED knippert, verbinding werkt. Maar de 3 LED's op de OTGW zelf staan op oranje-rood-groen en ik kan eigenlijk nergens een beschrijving vinden van de kleuren en de betekenis daarvan.

Is er ergens een overzichtje van de betekenis van die LED's?

Op pagina 6 van deze handleiding staat wat uitgelegd over de LED's.

[hvxl]

De uitleg staat in principe op de print gedrukt: Groen 3V3, Rood 5V, Oranje 24V.

In meer detail: De print wordt gevoed met 5V en dat gaat ook naar de Wemos D1. Van de 5V wordt daarnaast 3,3V gemaakt voor de PIC en 24V voor de opentherm bus naar de thermostaat. De drie LEDs geven aan of deze spanningen aanwezig zijn.

[DjoeC]

krijn1985 schreef op maandag 17 augustus 2026 @ 14:02:
[...]

Op pagina 6 van deze handleiding staat wat uitgelegd over de LED's.

Toppie! Maar dan moet ik eens heel goed gaan kijken want ik zie geen 6 brandende LED's......

@hvxl Dank je, het "probleem" is dat de OTGW in een verwarmingshok hangt met slechte verliching en in het niet zo eenvoudig te openen doosje zit. Ik zal met extra licht eens eea gaan bekijken zoals: Waarom branden er maar 3 LED's.

Kern van mijn issue: De OTGW lijkt niet (goed) te communiceren met mijn Intergas en Intergas thermostaat terwijl de bedrading correct lijkt (bewuste woordkeuze). Natuurlijk ligt dat dan aan mij, er zal wel een draadje zijn dat in de connector geen/onvoldoende contact maakt (vermoeden). Ik had gehoopt dat de LED's zouden aangeven: ketel communiceert (groen/rood), thermostaat communiceert (groen/rood), OTGW is operationeel (groen/rood) en/of dat dit als status op de webpagina zou worden weergegeven. De webpagina geeft "connected", "Gateway Mode: Detecting". Ik vermoed dat ik geen contact met de ketel maak:

code:

23:38:32.087112 Thermostat         T100201AD   2 Write-Data       > MasterConfigMemberIDcode = Master Config[00000001] MemberID code [173]
23:38:32.879295 Thermostat         T100201AD   2 Write-Data       > MasterConfigMemberIDcode = Master Config[00000001] MemberID code [173]

Morgen maar weer eens de bedrading in de connector van de ketelkant checken. De OTGW zit in de thermostaatkabel, doorgeknipt, beide kanten in de 4 pin connector geklemd. Haal ik de OTGW er tussen uit en verbind ik de kabel weer door werken ketel en thermostaat weer. Het moet naar mijn idee iets heel simpels zijn..

[krijn1985]

@DjoeC hier foto hoe hij bij mij er (werkend) uitziet qua LED's. Misschien heb je er wat aan. Bij mij zijn ze voor mijn gevoel goed zichtbaar.

[hvxl]

DjoeC schreef op maandag 17 augustus 2026 @ 23:44:
[...]

Ik had gehoopt dat de LED's zouden aangeven: ketel communiceert (groen/rood), thermostaat communiceert (groen/rood), OTGW is operationeel (groen/rood) en/of dat dit als status op de webpagina zou worden weergegeven.

Je kunt hiervoor de andere 6 LEDs gebruiken. Bijvoorbeeld door de 'R' functie aan LED C toe te kennen: LC=R. Deze zou dan elke seconde 2x moeten knipperen. De eerste keer geeft aan dat een bericht van de thermostaat is ontvangen, de tweede is voor het antwoord van de ketel. Een andere optie is om de 'B' functie te gebruiken: LC=B. Ook dan moet de LED 2x knipperen. De eerste keer geeft aan dat een bericht naar de ketel wordt gestuurd, de tweede is wederom voor het antwoord van de ketel.

Maar aan je log te zien komt er inderdaad geen antwoord van de ketel. Dus daar lijkt een communicatieprobleem te zijn.

[w2k8]

Goededag,

Ik heb een Shelly walldisplay XL gekregen.
Ik wil het display ophangen op de plaats waar nu mijn thermostaat hangt.
De shelly walldisplay kan niet rechtstreeks de cv-ketel aansturen.
Ik heb Home assistant en zou graag de cv-ketel willen bedienen met de Shelly walldisplay.

Op tweakers heb ik gelezen dat ik hiervoor OpenTherm nodig heb voor de vertaalslag tussen de keten en de shelly / home assistent.

De cv-ketel is een Remeha Avante 35C.
In dit topic heb ik enkele opties gelezen / gezien die ik kan gebuiken.
Ik kan een ESP flashen, maar ik ben op zoek naar een stabiele manier, dus ook als de ketel vervangen wordt.
Ik ken deze link:
https://www.nodo-shop.nl/nl/48-opentherm-gateway
https://www.home-master.eu/shop/opentherm-gateway-59

Ik ben op zoek naar ervaringen van mensen met de nodo-shop of home-master in combinatie met de shelly walldisplay.

[ Voor 7% gewijzigd door w2k8 op 25-08-2026 09:00 ]

[pistole]

In principe kan je met de https://www.nodo-shop.nl/...herm-gateway-builder.html bereiken wat je wilt. Maar als je je volledige thermostaat gaat vervangen dan adviseer ik je om eerst heel goed in te lezen.

Er zijn ook andere (draadloze) thermostaten die kunnen interfacen met enerzijds je (Opentherm) CV-ketel en anderzijds Home Assistant.

In mijn geval: ik gebruik Netatmo als thermostaat en OTGW om te meten/monitoren/bij te sturen waar ik wil. Met uitzondering van de aansluiting op de ketel is alles draadloos.