Strange behaviour of otgw
Moderator: hvxl
Strange behaviour of otgw
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
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
Re: Strange behaviour of otgw
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:
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:
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?
/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
}
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.
I suspect hardware of firmware, but how to test?
Re: Strange behaviour of otgw
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.
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
Re: Strange behaviour of otgw
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:
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:
DP=A5:
That's correct since the flame is on right now.
Again, I will repeat this when leds are on without valid reason.
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
With otmonitor running fine:
PR=L:
Code: Select all
PR: L=FXOMPC
Code: Select all
A5=09
Again, I will repeat this when leds are on without valid reason.
Re: Strange behaviour of otgw
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:
Trying strace didn't bring me a lot further:
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?
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
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...
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?
Re: Strange behaviour of otgw
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:
Next, check the connection to the OTGW:
Unless that returns an error (can't read "dev": no such variable), check the event handler:
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
dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':set errorInfo'
Code: Select all
dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fconfigure $dev'
Code: Select all
dbus-send --dest=com.tclcode.otmonitor --print-reply / com.tclcode.debug.Eval ':fileevent $dev readable'
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
Re: Strange behaviour of otgw
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:
And we're running again. Leds okay, logfile okay, telnet okay, http okay.
Let's try the dbus interface:
I'm done for today. I'll try to fix that another time.
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
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
Re: Strange behaviour of otgw
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.
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.
Re: Strange behaviour of otgw
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.
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.
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
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
Re: Strange behaviour of otgw
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:
So, it is kind of working, but there is no extra.tcl and I have no clue of where to find that?
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""
Re: Strange behaviour of otgw
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.
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
Re: Strange behaviour of otgw
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.
No dev, so skipped the next step.
Try to reconnect.
Looks like reconnecting succeeded.
Try again:
Now seems okay to me?
Since there is a dev, try next step:
Then:
Power off, wait 30 s, power on otgw. Green led starts blinking. Restart otmonitor. Logfile show incoming messages. Everything functioning again.
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
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)}""
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 { }"
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"
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.
Re: Strange behaviour of otgw
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:
What's that WDT reset?? Where is that "À" before "Opentherm" coming from??
Further:
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!
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.
Re: Strange behaviour of otgw
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:
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.
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
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"
Re: Strange behaviour of otgw
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.
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