[OTGW] OpenTherm gateway

[Church of Noise]

pistole schreef op vrijdag 13 maart 2026 @ 12:27:
Ik heb geen ervaring met Tado, maar misschien kan je via HA ook monitoren wat Tado doet?
https://www.home-assistant.io/integrations/tado/

Doe ik nu in parallel ook, en Tado gedraagt zich perfect normaal,vsndaar mijn initieel vermoeden dat t bij otgw ligt. Die krijgt nl m.i. de juiste input van tado binnen van alle thermostaten, maar geeft dus niet het logische door aan de ketel.

Dank voor het meedenken overigens!

[Vuur Draak]

Ben aan het uitzoeken of een OTGW op mijn Remeha Calenta met iSense v19 zal gaan lukken.
Suggesties? Gewoon maar proberen of ga ik moeilijke dingen tegen komen?

[pistole]

Church of Noise schreef op vrijdag 13 maart 2026 @ 21:58:
[...]

Doe ik nu in parallel ook, en Tado gedraagt zich perfect normaal,vsndaar mijn initieel vermoeden dat t bij otgw ligt. Die krijgt nl m.i. de juiste input van tado binnen van alle thermostaten, maar geeft dus niet het logische door aan de ketel.

Dank voor het meedenken overigens!

Volgens mij/bij mij doet OTGW uit zichzelf niet zo veel. Maar dat zou kunnen komen doordat ik de thermostaat het meeste laat doen. Wat heb je precies aan automatiseringen gemaakt?

[pistole]

Vuur Draak schreef op vrijdag 13 maart 2026 @ 23:40:
Ben aan het uitzoeken of een OTGW op mijn Remeha Calenta met iSense v19 zal gaan lukken.
Suggesties? Gewoon maar proberen of ga ik moeilijke dingen tegen komen?

Heb je de compatibiliteit gechecked op de website?

[NoFate]

Guys, ik heb deze installatie thuis, wil hem ook smart maken via HA, kan ik hier de gateway voor kopen?
Toevallig komt de onderhoudsman volgende week, dan kan ik de draadjes laten aansluiten?
Ik heb een honeywell SDC controller met een daalderop ketel, gaat dit dan werken met de gateway die ik kan kopen op nodo shop ?

zie fotos

[JBS]

JBS schreef op donderdag 12 februari 2026 @ 07:38:
[...]


[...]

Afgelopen week en afgelopen nacht gebeurde weer hetzelfde. Afgelopen week was een herstart vanuit de UI voldoende om de CV te laten stoppen met verwarmen, vannacht was een fysieke powercycle (voeding eruit en weer terug) nodig om dat voor elkaar te krijgen. Toen ik de voeding uit de OTGW trok, stopte de CV overigens direct met verwarmen. Niet pas nadat de OTGW weer was opgestart.

Heb de logging nog niet geactiveerd...


[...]

Zojuist firmware v1.0.0 geflashed, daarin lijkt logging al te zijn ingeschakeld.

[Afbeelding]

Ik zie nu hetzelfde gebeuren. De OTGW Room Temperature is al ~6 uur ongewijzigd.
Andere entiteiten, zoals bijvoorbeeld OTGW_Boiler_flow_water_temperature en OTGW_DHW_temperature krijgen wel updates.

In de logging in de UI van OTGW zie ik o.a.:

code:

15:04:11.100106 Thermostat         T901813AB  24 Write-Data       > Tr = 19.67 °C
15:04:11.450577 Boiler             B501813AB  24 Write-Ack          Tr = 19.67 °C

Wat kan ik nog meer aan logging aanleeren voor debugging?

\\Edit: Nadat ik wat door de OTGW UI aan 't klikken was, specifiek rondom de logging (capture. download), werd de OTGW Room Temperature ineens wél geupdate. Ik neig ernaar te denken dat dat geen toeval is na ~6 uur geen update.

[ Voor 16% gewijzigd door JBS op 23-03-2026 22:23 ]

[number3]

OTGW-firmware v1.3.0 - PIC Settings, One-Click OTA en flink gehardened

Nieuwe release van de ESP8266-firmware voor de NodoShop OpenTherm Gateway. Backwards-compatible upgrade vanuit v1.2.0, geen breaking changes.

Key features:

• PIC Gateway Settings. Alle 15 PIC-configuratieregisters nu zichtbaar via Web UI, REST API en MQTT. Waarden worden on-demand uitgelezen (PR= polling) en gecached in de browser met kleurcodering (groen = live, oranje = cached).
• Optionele wachtwoordbeveiliging. HTTP Basic Auth voor settings, bestandsbeheer, reboot en OTA. Standaard uit; bestaande setups ongewijzigd.
• MQTT publish gating. Rate-limiting op OpenTherm- en PS=1-berichten om brokerload en WiFi-verkeer te beperken.
• Volledige PS=1-integratie. PS=1 summary output wordt nu geparsed, gepubliceerd naar MQTT en doorgestuurd naar Home Assistant discovery.
• Light/dark theme toggle. Persistent per browser.
• Triple-reset WiFi recovery. 3x snel resetten binnen 10 seconden wist WiFi-credentials en opent het captive portal opnieuw. Geen reflash nodig.
• Non-blocking WiFi reconnect. Geen 30-seconden freeze meer in de main loop bij verbindingsverlies.

Security & stabiliteit:

• Gecentraliseerde auth op alle POST/PUT endpoints, CORS-wildcard vervangen door dynamic origin, webhook SSRF-preventie, XSS-fix
• ArduinoJson verwijderd, settings/state geherstructureerd naar structs, String-class uit hot paths, ~1.400 bytes stackdruk weg
• Bugfixes: hostname die terugviel naar ESP-XXXXXX, iOS Safari settings-pagina blank, millis() wraparound, f8.8 negative encoding

Upgrade: Flash firmware + filesystem, hard-refresh in de browser (Ctrl+F5).

De release zelf kan je hier downloaden: https://github.com/rvdbre...mware/releases/tag/v1.3.0

Als je vragen, opmerkingen, complimenten, bugreports hebt, dan kan je mij vinden op de OTGW discord of natuurlijk gewoon hier een vraag stellen.

Groet,
Robert

[ Voor 4% gewijzigd door number3 op 26-03-2026 22:40 . Reden: Kleine correcties. ]

[JBS]

Heb twee praktische vragen:

1. Kan een OTGW ook tussen een CV en aan/uit relais, zonder de aanwezigheid van een thermostaat?
   Ik ben bekend van de Gateway/Standalone modus, maar wil in dit specifieke geval liever dat een apart relais de CV in- of uitschakelt en niet de OTGW. Wel wil ik graag de OTGW monitoring toevoegen.
2. En: Is het mogelijk een OTGW zonder aangesloten CV te gebruiken om enkel de waardes van een thermostaat (die niet op de CV is aangesloten) te monitoren?

JBS schreef op maandag 23 maart 2026 @ 15:05:
[...]

Ik zie nu hetzelfde gebeuren. De OTGW Room Temperature is al ~6 uur ongewijzigd.
Andere entiteiten, zoals bijvoorbeeld OTGW_Boiler_flow_water_temperature en OTGW_DHW_temperature krijgen wel updates.

In de logging in de UI van OTGW zie ik o.a.:

code:

15:04:11.100106 Thermostat         T901813AB  24 Write-Data       > Tr = 19.67 °C
15:04:11.450577 Boiler             B501813AB  24 Write-Ack          Tr = 19.67 °C

Wat kan ik nog meer aan logging aanleeren voor debugging?

\\Edit: Nadat ik wat door de OTGW UI aan 't klikken was, specifiek rondom de logging (capture. download), werd de OTGW Room Temperature ineens wél geupdate. Ik neig ernaar te denken dat dat geen toeval is na ~6 uur geen update.

[Afbeelding]

Inmiddels durf ik wel te stellen dat het issue vermoedelijk aan de kant van Tado zit en niet aan de kant van de OTGW. Het feit dat alle entiteiten komende van de CV wél geupdate werden, maar de entiteit komende van de thermostaat niet, bevestigd dit vermoeden.

Na een powercycle van óf de Tado Draadloze Ontvanger óf de Tado Internet Bridge is het probleem namelijk steeds opgelost. Soms is een powercycle van de OTGW daarna nog wel nodig overigens, maar dat heeft dan meer met volgorde van opstarten te maken, vermoed ik.

[ Voor 80% gewijzigd door JBS op 30-03-2026 14:18 ]

[DjoeC]

JBS schreef op maandag 30 maart 2026 @ 13:56:
Kan een OTGW ook tussen een CV en aan/uit relais, zonder de aanwezigheid van een thermostaat?
Ik ben bekend van de Gateway/Standalone modus, maar wil in dit specifieke geval liever dat een apart relais de CV in- of uitschakelt en niet de OTGW. Wel wil ik graag de OTGW monitoring toevoegen.

Ik ben hier ook wel benieuwd naar, heb sinds kort een nieuwe ketel en wil die eigenlijk uitsluitend via de OTGW sturen (al dan niet via een relais).

[pistole]

Ik heb een Netatmo en die gedraagt zich als aan/uit terwijl die OT zou moeten kunnen praten. Je hebt dan feitelijk een 'domme' thermostaat (=aan/uit relais) aan de thermostaat kant en vervolgens de ketel aan de ketel-kant van de OTGW.

Met andere woorden: zet de OTGW tussen relais en ketel en dan bereik je wat je wilt (denk ik).

@JBS als je OTGW in monitoring mode zet dan bereik je ook wat je wilt.

[JBS]

@pistole En doel je dan op wens 1 of wens 2?

[pistole]

JBS schreef op maandag 30 maart 2026 @ 15:55:
@pistole En doel je dan op wens 1 of wens 2?

Beide : . Maar ik doelde in eerste instantie op het eerste punt waarbij je de monitoringstand zelf al aanhaalt.

[JBS]

pistole schreef op maandag 30 maart 2026 @ 16:15:
[...]

Beide : . Maar ik doelde in eerste instantie op het eerste punt waarbij je de monitoringstand zelf al aanhaalt.

Als ik de interface PIC firmware flash, wordt de thermostaat wel gevonden, maar gateway mode blijft Detecting.

code:

PIC Firmware Type   interface

MQTT Connected  true
Thermostat Connected    true
Boiler Connected    false
Gateway Mode    Detecting...
Home Assistant Integration  false

Diagnostics PIC firmware hetzelfde:

code:

PIC Firmware Type   diagnose

MQTT Connected  true
Thermostat Connected    true
Boiler Connected    false
Gateway Mode    Detecting...
Home Assistant Integration  false

Is 't correct dat Gateway Mode op Detecting... blijft staan?

Als ik de thermostaat en OTGW wat ga powercyclen (om en om), dan resulteert dat daarna in

code:

Number of Reboots   2
MQTT Connected  true
Thermostat Connected    false
Boiler Connected    false
Gateway Mode    Detecting...
Home Assistant Integration  true

Thermostaat is nu false maar Home Assistant Integration is ineens wel true.

Ook nog even de Gateway firmware voor de PIC geprobeerd:

code:

Number of Reboots   4
MQTT Connected  true
Thermostat Connected    true
Boiler Connected    false
Gateway Mode    Gateway
Home Assistant Integration  false

Terug naar de diagnose PIC firmware en een herstart (vanuit de UI) verder

code:

PIC Firmware Type   diagnose
Number of Reboots   5
MQTT Connected  true
Thermostat Connected    false
Boiler Connected    false
Gateway Mode    Detecting...
Home Assistant Integration  true

Terug naar Gateway PIC firmware

code:

MQTT Connected  true
Thermostat Connected    true
Boiler Connected    false
Gateway Mode    Gateway
Home Assistant Integration  false

Vanwaar onder andere dat verschil in Home Assistant Integration..? Wat heeft dat met de PIC firmware te maken?
Ik snap 't niet meer 😅

[ Voor 42% gewijzigd door JBS op 30-03-2026 23:19 ]

[number3]

@pistole dank voor je bevindingen. De verschillende type firmware ondersteunen niet de PR commando’s.

In feite werkt de detectie alleen juist als je met een firmware type gateway te maken hebt.

De HA integration is misleidende titel, het staat voor OTGW connected (zijnde type firmware gateway). Bovendien is de default true en gaat ie als ie geen OT berichten ziet binnen 30 seconden naar false.

De OTGW connected gaat alleen op true als je dus binnen 30 seconden OT berichten ziet.

Diagnose en Interface firmware ondersteunen geen PR=M commando.

Default van de OTGW connected kan wellicht beter naar false. Zodat na reboot eerst OT verkeer gezien moet worden.

Ik zal in een toekomstige release wat kleine tweaks maken om eea duidelijker te maken.

De meldingen van status zijn uiteraard vooral bedoeld als je een OTGW ook aansluit en voorziet van de gateway modus.

Dank voor je vragen en hoop dat eea nu helderder is.

[JBS]

@number3 Ik vermoed dat je reactie voor mij bedoeld was? :-) Even puntsgewijs mijn reactie:

1. Met 'PR commando's' bedoel je opdrachten die de OTGW naar de CV kan sturen? In deze situatie ben ik daar ook niet op zoek. Ik wil graag dat de OTGW alle info van de CV toont óf alle inkomende berichten van de thermostaat toont (afhankelijk van welke van de twee is aangesloten, in deze use case dus niet beide).
2. M.b.t. PR=M: Als ik dus het gedrag van de CV wil monitoren zal ik de OTGW met Gateway PIC firmware moeten draaien dus? Met welke PIC firmware moet ik 'm draaien als ik enkel een thermostaat heb aangesloten en bijvoorbeeld de actuele door die thermostaat gemeten ruimte temperatuur wil monitoren?
3. Wanneer Home Assistant Integration c.q. OTGW connected true is, hebben de entiteiten in HA daadwerkelijk waardes. Wanneer false, dan zijn ze allen 'Niet beschikbaar'. Dus ergens is het toch wel Home Assistant gerelateerd zo lijkt het?

[number3]

@JBS inderdaad was voor jou bedoeld. 🫣

1. PR commando’s bevragen de PIC controller. Daarmee lees je instellingen uit in de PIC.

De gateway firmware is bedoeld voor normaal gebruik de andere twee firmwares zijn bedoeld om diagnose te doen en om het interface te testen.

2. Ehhh zonder een ketel draaien 😵‍💫 b by design had ik de veronderstelling dat je altijd een warmtebron aansluit die je wilt sturen 🤨

3. Het is een design keuze van mij dat het device offline is als er niets te besturen is.


Kom gerust even op Discord langs dan kunnen we daar uitgevoerd erover hebben.

[JBS]

@number3

1. Helder. Dan blijf ik bij de Gateway firmware.
2 & 3. Op Discord al even over gehad maar voor de volledigheid ook even hier: In de komende fix release is er een thermostaat-only modus toegevoegd die voorkomt dat de OTGW offline gaat als ie geen updates van een CV krijgt. Inmiddels heb ik dat succesvol getest, de OTGW blijft in zo'n situatie online.

[ Voor 6% gewijzigd door JBS op 01-04-2026 18:51 ]

[Church of Noise]

Hoe krijg ik die op mijn otgw?

[JBS]

Church of Noise schreef op woensdag 1 april 2026 @ 21:47:
Hoe krijg ik die op mijn otgw?

Wie? De nieuwe firmware waar ik 't over had in m'n vorige post? Download via https://github.com/rvdbre...mware/releases/tag/v1.3.4 en flash via de web UI van je OTGW.

Voor de volledigheid: Met enkel een thermostaat en geen CV aan de OTGW, krijgt de thermostaat geen antwoorden van de CV en gaat ie afwijkend gedrag vertonen, althans dat doet Tado. Betekent dat de OTGW op deze manier niet als monitor van het thermostaat gedrag te gebruiken is, wat ik graag wilde.

[ Voor 31% gewijzigd door JBS op 01-04-2026 21:59 ]

[Church of Noise]

Zou ik graag proberen,aar ik heb de versie zonder de wemos module... Vandaar de vraag 😊

[htca]

just to confirm.... net geinstalleerd en draait als een zonnetje! Moet eerlijk zeggen dat ik de OTGW ooit gekocht heb en in het begin wat geklooi heb gehad, maar dat kwam vooral door mijn eigen onhandigheid (en brakke wifi). Well done in any case!

in toevoeging; de webhooks werken geweldig!

[ Voor 8% gewijzigd door htca op 02-04-2026 10:37 ]

[Tomba]

number3 schreef op donderdag 26 maart 2026 @ 22:37:
OTGW-firmware v1.3.0 - PIC Settings, One-Click OTA en flink gehardened

Nieuwe release van de ESP8266-firmware voor de NodoShop OpenTherm Gateway. Backwards-compatible upgrade vanuit v1.2.0, geen breaking changes.

Key features:

• PIC Gateway Settings. Alle 15 PIC-configuratieregisters nu zichtbaar via Web UI, REST API en MQTT. Waarden worden on-demand uitgelezen (PR= polling) en gecached in de browser met kleurcodering (groen = live, oranje = cached).
• Optionele wachtwoordbeveiliging. HTTP Basic Auth voor settings, bestandsbeheer, reboot en OTA. Standaard uit; bestaande setups ongewijzigd.
• MQTT publish gating. Rate-limiting op OpenTherm- en PS=1-berichten om brokerload en WiFi-verkeer te beperken.
• Volledige PS=1-integratie. PS=1 summary output wordt nu geparsed, gepubliceerd naar MQTT en doorgestuurd naar Home Assistant discovery.
• Light/dark theme toggle. Persistent per browser.
• Triple-reset WiFi recovery. 3x snel resetten binnen 10 seconden wist WiFi-credentials en opent het captive portal opnieuw. Geen reflash nodig.
• Non-blocking WiFi reconnect. Geen 30-seconden freeze meer in de main loop bij verbindingsverlies.

Security & stabiliteit:

• Gecentraliseerde auth op alle POST/PUT endpoints, CORS-wildcard vervangen door dynamic origin, webhook SSRF-preventie, XSS-fix
• ArduinoJson verwijderd, settings/state geherstructureerd naar structs, String-class uit hot paths, ~1.400 bytes stackdruk weg
• Bugfixes: hostname die terugviel naar ESP-XXXXXX, iOS Safari settings-pagina blank, millis() wraparound, f8.8 negative encoding

Upgrade: Flash firmware + filesystem, hard-refresh in de browser (Ctrl+F5).

De release zelf kan je hier downloaden: https://github.com/rvdbre...mware/releases/tag/v1.3.0

Als je vragen, opmerkingen, complimenten, bugreports hebt, dan kan je mij vinden op de OTGW discord of natuurlijk gewoon hier een vraag stellen.

Groet,
Robert

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

[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.