Strange behaviour of otgw

This Forum is about the Opentherm gateway (OTG) from Schelte

Moderator: hvxl

Strange behaviour of otgw

Postby bartgv » Sat Feb 22, 2020 9:38 am

Hi,

A few weeks ago I bought the otwg from Nodo, mainly to be able to remote control the thermostat and secondary for logging. When connected to my laptop running otmonitor (with gui in linux) i see the log messages passing, I can control the room setpoint with both the otgw and my thermostat and everything is working well.

But after a few days or hours, that varies, strange things start to happen. Last night the room setpoint went up to 35 degrees C! The log in otmonitor showed just the last two hours and the setpoint change happened longer ago (acually it happened about 5 hours earlier according to my smartmeter log). Yes, i woke up in a pretty warm house... Normal day and night room setpoints are respectively 19 and 14 degrees C.

This weekend I'm going out and since I don't really trust the otgw anymore, I temporarily removed it and connected the thermostat directly to the boiler for now.

But it's not my first issue. A few days ago i ran the system with the command line version of otmonitor and suddenly all leds went off, otmonitor couldn't connect the otgw anymore and the only solution was to unplug the power for a few seconds. Another time more or less the same issues (no connection), but only the red led was continually burning.

Next week i will try to log all messages to file and see if that gives any clues.

Btw, the thermostat is a Honeywell Round Modulation and the boiler is a Nefit proline nxt hrc24.

Any ideas of what could be wrong?
Bart
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby bartgv » Sun Mar 01, 2020 1:04 am

Okay, last tuesday the OTGW was placed between the themostat and boiler again. This time no telnet sessions of http request to otmonitor, just logging to file and nothing else (otmonitor-ahf --daemon -f /etc/otmonitor.conf -o /otmonitor.log). CH temperature controlled by thermostat itself.

/etc/otmonitor.conf:
Code: Select all
web {
  enable true
  port 8181
  nopass true
  graphlegend true
  theme default
}
connection {
  device /dev/ttyUSB0
  type serial
  enable true
}
server {
  enable true
  port 7686
  relay true
}


In 4 days otmonitor stopped logging 2 times (wednesday and saturday). When otmonitor stopped, the green led on the OTGW was still blinking and I could still setup a telnet connection to otmonitor. But sending a "PS=1" resulted in:
Code: Select all
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain;charset=utf-8
Content-Length: 422
Connection: close

*** INTERNAL SERVER ERROR (BEGIN #3) ***
port: 8181
socket: sock837010
peerhost: 192.168.1.11
peerport: 35472
rawtime: 1583014933
time: Sat Feb 29 23:22:13 CET 2020
errorinfo: can't read "uri": no such variable
while executing
"regexp {^([^?]*)(\?.*)?$} $uri _ path query"
(procedure "getrequest" line 7)
invoked from within
"getrequest $port $socket $peerhost $peerport"
*** INTERNAL SERVER ERROR (END #3) ***
Connection closed by foreign host.


Another issue started on friday. Somewhere between friday morning and friday evening the yellow led (flame on) went on and didn't go off anymore. Even while the flame was off and StatusFlames was 0 (Status: 00000010 00000000). Then, when I turned on the hot water tap, the boiler flame started, status indicated the flame was burning (Status: 00000010 00001100) and yellow led was on. After turning off the hot water tap, the flame went of, status went back to 00000010 00000000, but the yellow led stayed on. After completely powering off and on the OTGW everything went back to normal.

I suspect hardware of firmware, but how to test?
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby hvxl » Sun Mar 01, 2020 12:14 pm

It seems you used the web server port (8181) rather than the telnet port (7686) to issue your "PS=1" command. Since that is not a proper HTTP request, you get an error message.

Your yellow LED may have indicated something other than the flame state. What does "PR=L" report? If that shows F for LED A, check address 0xA5 (DP=A5). When (only) LED A is configured to indicate the flame status, that should show A5=08 when the flame is off and A5=09 when the flame is on. If that is not the case, you should be able to correct it by running the command "LA=F". But it means something is corrupting the data on address A5. That would then need further investigation.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1276
Joined: June 2010

Re: Strange behaviour of otgw

Postby bartgv » Mon Mar 02, 2020 8:49 pm

Well, the funny thing is that is got the HTTP 500 internal server error after sending "PS=1" through telnet (port 7686).

Good to know that the yellow led has other funtions; I didn't read the documentation that far... If it happens again I will try those "Print Report" commands.

This morning at 05:17 otmonitor stopped writing messages to the logfile, although it is still running and I can send commands via telnet. Those commands appear in the log file. After sending for example "PS=1" the last four lines in the logfile are:
Code: Select all
05:17:03.514197  B50100E00  Write-Ack   Room setpoint: 14.00
05:17:04.402981  T80190000  Read-Data   Boiler water temperature: 0.00
05:17:04.498077  BC0191C00  Read-Ack    Boiler water temperature: 28.00
19:48:39.665547  Command (via relay server, from 192.168.1.11:55424): PS=1

I restarted otmonitor. Next time it stops logging I will try to to attach strace to see if that gives anything useful.

With otmonitor running fine:
PR=L:
Code: Select all
PR: L=FXOMPC

DP=A5:
Code: Select all
A5=09

That's correct since the flame is on right now.
Again, I will repeat this when leds are on without valid reason.
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby bartgv » Wed Mar 04, 2020 8:20 pm

When I came home today I turned the thermostat a bit higher. A little later I checked the otgw and all led were off. First, I checked the logfile and it stopped logging exactly at the moment I turned the thermostat higher.

Connecting with telnet did work, so otmonitor was astill running, although there was no output at all. I tried some Print Report commands, but none returned anything. They did however show up in the logfile:
Code: Select all
19:42:19.225370 Command (via relay server, from [::1]:59384): PR=L
19:43:55.668816 Command (via relay server, from [::1]:59386): PR=A


Trying strace didn't bring me a lot further:
Code: Select all
strace -p 8247
strace: Process 8247 attached
futex(0x18d535c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1583346821, tv_nsec=858565000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
write(4, "\0", 1) = 1
futex(0x1773df0, FUTEX_WAKE_PRIVATE, 1) = 1
write(4, "\0", 1) = 1
futex(0x1773df0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x18d535c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1583346821, tv_nsec=960786000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
write(4, "\0", 1) = 1
futex(0x1773df0, FUTEX_WAKE_PRIVATE, 1) = 0
write(4, "\0", 1) = 1
futex(0x1773df0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x18d535c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1583346822, tv_nsec=62990000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
write(4, "\0", 1) = 1
futex(0x1773df0, FUTEX_WAKE_PRIVATE, 1) = 1
write(4, "\0", 1) = 1
futex(0x1773df0, FUTEX_WAKE_PRIVATE, 1) = 1

and so on...

Connection timed out?

Then I restarted otmonitor. Then the green led started blinking, but still nothing in logfile.

For now I leave it in this state. Is there anything I could try?
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby hvxl » Wed Mar 04, 2020 10:11 pm

On linux, there is a "hidden" way to talk to the running Tcl interpreter. So, the first thing to try is to see if it has any helpful error message:
Code: Select all
dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':set errorInfo'

Next, check the connection to the OTGW:
Code: Select all
dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fconfigure $dev'

Unless that returns an error (can't read "dev": no such variable), check the event handler:
Code: Select all
dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fileevent $dev readable'

If there is no connection to the OTGW and you're running otmonitor without a GUI, you can attempt a reconnect using:
Code: Select all
qdbus com.tclcode.otmonitor / com.tclcode.otmonitor.Reconnect
# or
dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.otmonitor.Reconnect
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1276
Joined: June 2010

Re: Strange behaviour of otgw

Postby bartgv » Thu Mar 05, 2020 1:02 am

There is no tcl interpreter to talk to... I'm running the pre-compiled otmonitor-ahf (from Oct 11, 2019). To run the tcl script, tclkit is required. But building tclkit failed somehow (did it some time ago, but I don't know what went wrong exactly) and I didn't put any effort in that anymore.

While typing this post I'm trying to compile tclkit again to see where it fails.

And that takes some time on and rpi3...

Finally compilation failed with a fuzzy error:
WARNING: this is an unstable beta version - use for testing only! Really.
make: *** [../../makefile.include:30: tclkit-dyn] Error 1
Zucht... I'll try to get a tclkit binary somewhere. Done.

Power off, power on for otgw, start otmonitor:
Code: Select all
./tclkit-8.6.3-raspbian-arm main.tcl --daemon -f /etc/otmonitor.conf -o /otmonitor.log

And we're running again. Leds okay, logfile okay, telnet okay, http okay.

Let's try the dbus interface:
Code: Select all
dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fconfigure $dev'
Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.tclcode.otmonitor was not provided by any .service files

I'm done for today. I'll try to fix that another time.
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby bartgv » Thu Mar 05, 2020 5:50 pm

Today I came home and thought "nice and warm in here". But I was really sure that I set the thermostat to 14 degrees yesterday evening late. So I checked the thermostat (Honeywell Round Modulation) and it says alternately "19.5" and "Ot". "Ot" indicates an Open Therm error according to the Honeywell docs. I didn't touch it and checked the boiler: running and flame on, as expected. All leds on the otgw are off. I could connect with telnet, but no response on "PR=A" and other commands.

After power off, power on the otgw everything is running again.

I'll will try to get the dbus stuff going, but if that doesn't bring me any further I will contact Nodo.

Thanks for helping me so far.
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby hvxl » Sat Mar 07, 2020 10:27 pm

I guess there's some misunderstanding. The pre-compiled otmonitor is just a Tcl interpreter and the scripts and libraries wrapped up into a single file. When that runs, there is a Tcl interpreter to talk to. You don't need to build anything. And if you want to run the latest git version, you can use one of the tclkits I provided on the site.

When using otmonitor without a GUI, it's probably easiest to run your own session dbus, unrelated to an X session.

Code: Select all
dbus-daemon --session --print-address --fork

This prints something like:
unix:abstract=/tmp/dbus-CDf8RsSKwv,guid=65b0213872b6fe231031693c5e640b8c

Save the reported address somewhere (the guid part is optional) and use it as the DBUS_SESSION_BUS_ADDRESS when you start otmonitor and then again later when you want to talk to it.

Code: Select all
export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-CDf8RsSKwv
otmonitor --daemon

Code: Select all
export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-CDf8RsSKwv
dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':set errorInfo'
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1276
Joined: June 2010

Re: Strange behaviour of otgw

Postby bartgv » Mon Mar 09, 2020 11:12 pm

I realised later that de pre-compiled otmonitor contained the tcl intepreter. Anyway now I can run both the pre-compiled otmonitor and the tcl scripts with tclkit.

For now I'll stick to the precompiled otmonitor.

I started my own session dbus at address "unix:abstract=/tmp/dbus-QpefZhUUuI", exported the DBUS_SESSION_BUS_ADDRESS and started otmononitor. In another console I exported the same DBUS_SESSION_BUS_ADDRESS and then:
Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':set errorInfo'


Code: Select all
method return time=1583790131.797320 sender=:1.3 -> destination=:1.4 serial=4 reply_serial=2
   string "couldn't read file "/usr/local/bin/otmonitor-ahf/extra.tcl": no such file or directory
    while executing
"source /usr/local/bin/otmonitor-ahf/extra.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source [file join /usr/local/bin/otmonitor-ahf $file]]"
    (procedure "include" line 2)
    invoked from within
"include extra.tcl""

So, it is kind of working, but there is no extra.tcl and I have no clue of where to find that?
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby hvxl » Tue Mar 10, 2020 1:29 pm

OK, that error message is not a problem. You don't need extra.tcl. It's just an optional way to include customized code into otmonitor.

Now when otmonitor starts behaving badly again, repeat this command and the others I mentioned. Hopefully that gets us closer to figuring out what is going on.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1276
Joined: June 2010

Re: Strange behaviour of otgw

Postby bartgv » Thu Mar 12, 2020 1:10 pm

I just checked my OTGW and the green led was continue on. Last message in log file was from 10:13:03 this morning. Display of room thermostat showed current room temperature and no errors.

Code: Select all
# export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-MMeasgLFKD


Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':set errorInfo'
method return time=1584011677.372926 sender=:1.0 -> destination=:1.1 serial=3 reply_serial=2
   string "couldn't read file "/usr/local/bin/otmonitor-ahf/extra.tcl": no such file or directory
    while executing
"source /usr/local/bin/otmonitor-ahf/extra.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source [file join /usr/local/bin/otmonitor-ahf $file]]"
    (procedure "include" line 2)
    invoked from within
"include extra.tcl""


Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fconfigure $dev'
Error org.freedesktop.DBus.Error.Failed: can't read "dev": no such variable

No dev, so skipped the next step.

Try to reconnect.
Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.otmonitor.Reconnect
method return time=1584011872.077175 sender=:1.0 -> destination=:1.4 serial=6 reply_serial=2


Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':set errorInfo'
method return time=1584011959.959562 sender=:1.0 -> destination=:1.6 serial=22 reply_serial=2
   string "can't read "gui(maxmod)": no such element in array
    while executing
"expr {$float != $gui($name)}""

Looks like reconnecting succeeded.

Try again:
Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fconfigure $dev'
method return time=1584011964.160870 sender=:1.0 -> destination=:1.7 serial=23 reply_serial=2
   string "-blocking 0 -buffering line -buffersize 4096 -encoding utf-8 -eofchar {{} {}} -translation {crlf cr} -mode 9600,n,8,1 -xchar { }"

Now seems okay to me?

Since there is a dev, try next step:
Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fileevent $dev readable'
method return time=1584012071.980287 sender=:1.0 -> destination=:1.8 serial=37 reply_serial=2
   string "receive"


Then:
Code: Select all
# telnet localhost 7686
Trying ::1...
Connected to localhost.
Escape character is '^]'.
PS=1
PS: 1
PS=0
PS: 0
PR=A
PR: A=OpenTherm Gateway 4.2.5
PR=L
PR: L=FXOMPC
PR=B
PR: B=17:59 20-10-2015
PR=C
PR: C=4 MHz
PR=I
PR: I=00
PR=M
PR: M=G
PR=O
PR: O=N
PR=P
PR: P=Low power
PR=R
PR: R=D
PR=S
PR: S=16.00
PR=T
PR: T=11
PR=V
PR: V=3
PR=W
PR: W=A
^]
telnet> quit
Connection closed.


Power off, wait 30 s, power on otgw. Green led starts blinking. Restart otmonitor. Logfile show incoming messages. Everything functioning again.
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby bartgv » Mon Mar 16, 2020 9:34 pm

I disconnected the otgw for the weekend and reconnected it today around lunch time. 9 hours later I check the leds and this time the red led is on continuously.

The last 4 lines in the logfile:
Code: Select all
20:22:39.057988  T10010A00  Write-Data  Control setpoint: 10.00
20:22:39.201722  BD0010A00  Write-Ack   Control setpoint: 10.00
20:22:39.972681  ÀOpenTherm Gateway 4.2.5
20:22:39.984365  WDT reset!

What's that WDT reset?? Where is that "À" before "Opentherm" coming from??

Further:
Code: Select all
# export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-tHZB5eCkrF
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':set errorInfo'
method return time=1584389006.559921 sender=:1.0 -> destination=:1.1 serial=726 reply_serial=2
   string "can't read "gui(temperature)": no such element in array
    while executing
"expr {$float != $gui($name)}""

# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fconfigure $dev'
method return time=1584389080.797230 sender=:1.0 -> destination=:1.5 serial=730 reply_serial=2
   string "-blocking 0 -buffering line -buffersize 4096 -encoding utf-8 -eofchar {{} {}} -translation {crlf cr} -mode 9600,n,8,1 -xchar { }"

# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fileevent $dev readable'
method return time=1584389136.413916 sender=:1.0 -> destination=:1.6 serial=731 reply_serial=2
   string "receive"

# telnet localhost 7686
Trying ::1...
Connected to localhost.
Escape character is '^]'.
PR=A
PR=L
^]
telnet> quit
Connection closed.
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby bartgv » Tue Mar 17, 2020 2:41 pm

The thermostat is just set to its maximum value of 35 degrees. Something (?) tried to set it even to 67.22 degrees (see logfile 13:17:08.869582).

I attach quite a bit of lines from the log file for context, with some comments:
Code: Select all
13:16:46.064621  T80000200  Read-Data   Status: 00000010 00000000
13:16:46.170612  B40000200  Read-Ack    Status: 00000010 00000000
13:16:47.050608  T00110000  Read-Data   Relative modulation level: 0.00
13:16:47.155609  BC0110000  Read-Ack    Relative modulation level: 0.00
13:16:48.036730  T00090000  Read-Data   Remote override room setpoint: 0.00
13:16:48.047843  R00740000  Read-Data   Burner starts: 0
13:16:48.138970  B40746068  Read-Ack    Burner starts: 24680
13:16:48.151468  AC0090000  Read-Ack    Remote override room setpoint: 0.00
13:16:49.021480  T00390000  Read-Data   Max CH water setpoint: 0.00
13:16:49.123977  BC0394100  Read-Ack    Max CH water setpoint: 65.00
13:16:50.006223  T80190000  Read-Data   Boiler water temperature: 0.00
13:16:50.107543  BC0191C00  Read-Ack    Boiler water temperature: 28.00
13:16:50.992328  T10010A00  Write-Data  Control setpoint: 10.00
13:16:51.092093  BD0010A00  Write-Ack   Control setpoint: 10.00
13:16:51.976859  T80000200  Read-Data   Status: 00000010 00000000
13:16:52.076722  B40000200  Read-Ack    Status: 00000010 00000000
13:16:52.964213  T00110000  Read-Data   Relative modulation level: 0.00
13:16:53.058963  BC0110000  Read-Ack    Relative modulation level: 0.00
13:16:53.950218  T00090000  Read-Data   Remote override room setpoint: 0.00
13:16:53.961252  R00770000  Read-Data   DHW burner starts: 0
13:16:54.046122  BC0773CB8  Read-Ack    DHW burner starts: 15544
13:16:54.057207  AC0090000  Read-Ack    Remote override room setpoint: 0.00
13:16:54.935714  T1002010D  Write-Data  Master configuration: 00000001 13
13:16:55.029462  BD002010D  Write-Ack   Master configuration: 00000001 13
13:16:55.921839  T80190000  Read-Data   Boiler water temperature: 0.00
13:16:56.015457  B40191B00  Read-Ack    Boiler water temperature: 27.00
13:16:56.907721  T10010A00  Write-Data  Control setpoint: 10.00
13:16:57.000078  BD0010A00  Write-Ack   Control setpoint: 10.00
13:16:57.893731  T80000200  Read-Data   Status: 00000010 00000000
13:16:58.053716  B40000200  Read-Ack    Status: 00000010 00000000
13:16:58.879966  T00110000  Read-Data   Relative modulation level: 0.00
13:16:59.037224  BC0110000  Read-Ack    Relative modulation level: 0.00
13:16:59.864711  T00090000  Read-Data   Remote override room setpoint: 0.00
13:16:59.877076  R00780000  Read-Data   Burner operation hours: 0
13:17:00.021950  B4078056B  Read-Ack    Burner operation hours: 1387
13:17:00.033094  AC0090000  Read-Ack    Remote override room setpoint: 0.00
13:17:00.850327  T00030000  Read-Data   Slave configuration: 00000000 0
13:17:01.006450  B40034183  Read-Ack    Slave configuration: 01000001 131
13:17:01.836586  T80190000  Read-Data   Boiler water temperature: 0.00
13:17:01.991520  B40191D00  Read-Ack    Boiler water temperature: 29.00
13:17:02.822476  T10010A00  Write-Data  Control setpoint: 10.00
13:17:02.928446  BD0010A00  Write-Ack   Control setpoint: 10.00
13:17:03.808469  T10010A00  Write-Data  Control setpoint: 10.00
13:17:03.937074  BD0010A00  Write-Ack   Control setpoint: 10.00
13:17:04.794581  T80000200  Read-Data   Status: 00000010 00000000
13:17:04.920818  B4000020C  Read-Ack    Status: 00000010 00001100
13:17:05.779462  T80000200  Read-Data   Status: 00000010 00000000
13:17:05.905580  B4000020C  Read-Ack    Status: 00000010 00001100
13:17:06.764326  T00110000  Read-Data   Relative modulation level: 0.00
13:17:06.889315  BC0110000  Read-Ack    Relative modulation level: 0.00
13:17:07.750446  T80000200  Read-Data   Status: 00000010 00000000
13:17:07.874065  B4000020C  Read-Ack    Status: 00000010 00001100
13:17:08.736330  T00090000  Read-Data   Remote override room setpoint: 0.00
13:17:08.747301  R007B0000  Read-Data   DHW burner operation hours: 0
13:17:08.858562  BC07B008D  Read-Ack    DHW burner operation hours: 141
13:17:08.869582  AC0094338  Read-Ack    Remote override room setpoint: 67.22     # What the heck is going on here??
13:17:09.721818  T00090000  Read-Data   Remote override room setpoint: 0.00
13:17:09.734308  R00740000  Read-Data   Burner starts: 0
13:17:09.842945  BC0746069  Read-Ack    Burner starts: 24681
13:17:09.853987  AC0094338  Read-Ack    Remote override room setpoint: 67.22
13:17:10.708960  T00050000  Read-Data   Application-specific flags: 00000000 0
13:17:10.827706  BC0050000  Read-Ack    Application-specific flags: 00000000 0
13:17:11.695221  T00090000  Read-Data   Remote override room setpoint: 0.00
13:17:11.706338  R00770000  Read-Data   DHW burner starts: 0
13:17:11.811198  B40773CB9  Read-Ack    DHW burner starts: 15545
13:17:11.822512  AC0094338  Read-Ack    Remote override room setpoint: 67.22
13:17:12.681075  T80190000  Read-Data   Boiler water temperature: 0.00
13:17:12.795948  BC0192900  Read-Ack    Boiler water temperature: 41.00
13:17:13.667077  T10010A00  Write-Data  Control setpoint: 10.00
13:17:13.779690  BD0010A00  Write-Ack   Control setpoint: 10.00
13:17:14.652274  T80000200  Read-Data   Status: 00000010 00000000
13:17:14.764697  B40000200  Read-Ack    Status: 00000010 00000000
13:17:15.638365  T80000200  Read-Data   Status: 00000010 00000000
13:17:15.748302  B40000200  Read-Ack    Status: 00000010 00000000
13:17:16.623205  T00110000  Read-Data   Relative modulation level: 0.00
13:17:16.733071  BC0110000  Read-Ack    Relative modulation level: 0.00
13:17:17.609175  T80000200  Read-Data   Status: 00000010 00000000
13:17:17.716549  B40000200  Read-Ack    Status: 00000010 00000000
13:17:18.596433  T00090000  Read-Data   Remote override room setpoint: 0.00
13:17:18.607416  R00780000  Read-Data   Burner operation hours: 0
13:17:18.700919  B4078056B  Read-Ack    Burner operation hours: 1387
13:17:18.713437  AC0094338  Read-Ack    Remote override room setpoint: 67.22
13:17:19.583315  T900E6400  Write-Data  Maximum relative modulation level: 100.00
13:17:19.685549  B500E6400  Write-Ack   Maximum relative modulation level: 100.00
13:17:20.567807  T80190000  Read-Data   Boiler water temperature: 0.00
13:17:20.670293  BC0192600  Read-Ack    Boiler water temperature: 38.00
13:17:21.555225  T10014100  Write-Data  Control setpoint: 65.00
13:17:21.653818  BD0014100  Write-Ack   Control setpoint: 65.00
13:17:22.539802  T00000300  Read-Data   Status: 00000011 00000000
13:17:22.638553  BC0000300  Read-Ack    Status: 00000011 00000000
13:17:23.525799  T00110000  Read-Data   Relative modulation level: 0.00
13:17:23.623179  BC0110000  Read-Ack    Relative modulation level: 0.00
13:17:24.512933  T00090000  Read-Data   Remote override room setpoint: 0.00
13:17:24.525416  R007B0000  Read-Data   DHW burner operation hours: 0
13:17:24.607659  BC07B008D  Read-Ack    DHW burner operation hours: 141
13:17:24.618779  AC0094338  Read-Ack    Remote override room setpoint: 67.22
13:17:25.497543  T90102300  Write-Data  Room setpoint: 35.00                         # Not my preferred room temperature!
13:17:25.592385  B50102300  Write-Ack   Room setpoint: 35.00
13:17:26.483323  T80190000  Read-Data   Boiler water temperature: 0.00
13:17:26.576790  BC0192600  Read-Ack    Boiler water temperature: 38.00
13:17:27.469173  T10014100  Write-Data  Control setpoint: 65.00
13:17:27.561668  BD0014100  Write-Ack   Control setpoint: 65.00
13:17:28.455359  T00000300  Read-Data   Status: 00000011 00000000


Besides that, is it normal to have so many lines of "Relative modulation level: 0.00"?

What's going on below? Messages are still appearing in the logfile.
Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':set errorInfo'
method return time=1584450069.798269 sender=:1.0 -> destination=:1.2 serial=1231 reply_serial=2
   string "couldn't open "/dev/ttyUSB0": no such file or directory
    while executing
"open $cfg(connection,device) {RDWR NOCTTY NONBLOCK}""


Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fconfigure $dev'
method return time=1584450188.946261 sender=:1.0 -> destination=:1.3 serial=1237 reply_serial=2
   string "-blocking 0 -buffering line -buffersize 4096 -encoding utf-8 -eofchar {{} {}} -translation {crlf cr} -mode 9600,n,8,1 -xchar { }"


Code: Select all
# dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fileevent $dev readable'
method return time=1584450220.365366 sender=:1.0 -> destination=:1.4 serial=1240 reply_serial=2
   string "receive"
bartgv
Starting Member
Starting Member
 
Posts: 11
Joined: February 2020

Re: Strange behaviour of otgw

Postby hvxl » Sat Mar 21, 2020 10:44 am

This is all quite strange. WDT reset means that the program went walkabout. The controller resets when that is detected. The "À" is sent by the firmware upgrade code in the PIC to inform the controlling program that it is ready to receive new firmware. So at least that is normal.

Your log doesn't show any commands to set the override temperature. Another reason for an override setpoint to kick in is if one of the GPIO ports has been configured as Home or Away. You can check that, as well as the configured setback temperature, using PR=G and PR=S.

But given that you also saw a WDT reset and other strange phenomena, I start to suspect your firmware may have developed one or more weak bits or bits that have fallen over. You can try to reflash the firmware.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1276
Joined: June 2010

Next

Return to Opentherm Gateway Forum

Who is online

Users browsing this forum: No registered users and 0 guests

cron