Home Automation Domotica Forum Europe, Bwired Forum

> keep an eye on it when it starts to get colder again in the autumn

Good idea. Will do.

Just to report that I have been running v5.4 for a few weeks, and all seems to be Ok. In conclusion it looks like I probably had a flaky CPU chip, and the combination of replacing it with a new chip, plus running v5.4 on it, has resolved my issue.

Cool. Many thanks for your kind support. Much appreciated.

^
I am using the version where the WDT reset causes the processor to restart, so I suppose the new builds are not for me??

> Do you have (a friend who has) a PIC programmer? Just to let you know that I finally got my hands on 1) a PIC programmer, and 2) a new PIC16F88 chip. It took longer to get the chip because of a) long lead times on the chip, and b) the first chip that arrived was faulty. Anyway, just for the record...

You are aware that you need to either order a PIC with the firmware (or at least the bootloader) preinstalled, or use a PIC programmer to program it yourself? A blank PIC16F88 can also not magically be programmed by OTmonitor. Ah! No. Your reference to "The method used to update the firmware i...

you may want to get a PIC16F1847 instead of a PIC16F88 I tried the PIC16F1847 but unfortunately it does not work on my Nodo board. I tested it using otmonitor.exe v6.0 (to try to flash gateway.hex v6.0) but it does not work. Otmonitor says first "Please manually reset the OpenTherm Gateway&quo...

^
Thanks for the tip.

Ok, I will buy another PIC and keep you posted.

> You can also check your logs for the "WDT reset!" string. That is what I am doing. So for me the PR=Q is not really needed. Many thanks for the 5.3.1 build. Insofar as I have not (yet) seen a WDT reset, this build has "fixed" that problem. It seems that whatever you did in that...

Many thanks for your response. See my answers to your points inline below.. > This looks to me like a baud rate mismatch and could be the USR-TCP232 that got confused. Interesting suggestion. The garbled characters do indeed look like a baud rate issue. But I wonder what could have triggered it to “...

Arrgh! The OTGW just crashed again. This time, it sent two garbage messages (see log below) and then simply stopped working. There was no WDT reset. The boiler console showed an OpenTherm comms error, so the OTGW was communicating neither on the OT bus nor on the serial side. And I had to power cycl...

^ Indeed. And the messages seem to come pair-wise starting with xxx00 and following by xxxNN with the last two characters different. So there is certainly some structure there. If you think the USR-TCP might be responsible for dropping the first characters, I have the following questions.. - Have yo...

It is certainly not the binding (it has no way to 'imagine' reading unknown rubbish). But it might indeed be the USR-TCP. But I also have no way know however..

I don't know if it is relevant, but in my ongoing logging, I noticed this morning the following 9 messages. The OpenHAB binding considered them to be 'unknown' messages, so they do stand out. This sequence of 9 messages was repeated three times. However the OTGW did NOT go into 'WDT reset'. And afte...