[SOLVED]Erratic behaviour/lock-ups/com errors Calenta/iSense

[Mars]

I'm using otmonitor 4.1.1 (windows exe) and teamviewer for remote access.
F12 does nothing! The other function keys like F2-F7 work.

So either F12 is blocked by teamviewer, or F12 should be another function key. Tried F8-F12, but none of those give me the console window.

[hvxl]

Fixing problems in your windows/teamviewer environment is your own responsibility. F12 is definitely the correct function key.

[Mars]

If F12 is the right function key, I will try RDP or hook up a keyboard to the server, and follow the steps you described.

The gateway is stable as a rock with VR=5, so MQTT must work to integrate the otgw with Homeseer and OpenHAB

Got it @22:30:

Code: Select all

my message DISCONNECT
Message sent to sock1488
my message SUBSCRIBE {topics {actions/otmonitor/+ 2}}
Not connected
my message CONNECT {client domiduca-otmon keepalive 120 clean 1}
Message sent to sock1488
my message SUBSCRIBE {topics {actions/otmonitor/+ 2}}
Message sent to sock1488
Queue: 
Event: receive
Queue: 
signal roomtemperature 19.64
can't read "key": no such variable
    while executing
"format {"name": "%s"} $key"
    (procedure "mqttjson2" line 14)
    invoked from within
"mqttjson2 $key $args"
    (procedure "mqttsignal" line 11)
    invoked from within
"mqttsignal 19.64"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 $n $args"
signal dhwsetpoint 60.00
can't read "key": no such variable
    while executing
"format {"name": "%s"} $key"
    (procedure "mqttjson2" line 14)
    invoked from within
"mqttjson2 $key $args"
    (procedure "mqttsignal" line 11)
    invoked from within
"mqttsignal 60.00"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 $n $args"
signal chsetpoint 60.00
can't read "key": no such variable
    while executing
"format {"name": "%s"} $key"
    (procedure "mqttjson2" line 14)
    invoked from within
"mqttjson2 $key $args"
    (procedure "mqttsignal" line 11)
    invoked from within
"mqttsignal 60.00"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 $n $args"
(Desktop) 25 % 

BTW: F12 is definitely NOT working on Windows 8.1 in the otmonitor.exe window (F12 works in Notepad++).
The only way I got the console is to run TclKit.exe, and then open main.tcl.

[hvxl]

Sorry, I made a mistake in the debug code. Can you try with the attached version? And this time please send me the complete output as I requested. It will be a bit much to inline it in a code block, so you may include it as an attachment in your response, or in a PM to me. But please don't edit it.

[Mars]

You are great, It works

I loaded your new mqtt-debug script and mqtt messages started to come in right away. I can also set the setpoint to control the thermostat.
The only problem I have is that it seems that only changed values are sent by otmonitor, even after an disconnect/connect.

And finally, the connection with OpenHAB also works.

I've added the logfile as attachment.

[hvxl]

Huh? The debug code was not supposed to fix anything. It should just provide some more information on what is happening so I could hopefully determine what is going wrong. If things start working correctly with the debug code, I still don't know what the problem might be.

[Mars]

That is very weird.

So I did some extra testing for otmonitor in general and found the following:

• Running the exe windows version sometimes does connect to mqtt, but most of the times it doesn't
• The tclkit version does it right every time I use it. So that is currently the way it works on my server
• otmonitor's RAM and CPU usage do increase every day. I can't find why. Ram usage goes from 80MB up to 200-500MB !!! and at the same time the CPU load goes up from 3% to around 10-15%
• otmonitor is sometimes unable to detect disconnects from the otgw. It keeps telling me that it is connected (green connection symbol in the lower right corner), but it simply isn't. I have to use the connect button in the connection tab to have it really connect
• the connection between otmonitor and the TP Link wifi is very, very, very unreliable. No idea who's problem that is yet. Communication simply stops about every few days or sometimes every day

Remember that I'm only using otmonitor as a otgw-MQTT gateway, nothing else. The above problems make the current solution very WAF unfriendly, so looking at the above problems, I'm considering connecting a JeeNode/Arduino with LAN to the serial line of the otgw and connect it directly to my mqtt server. This setup should solve the high CPU and RAM usage, and also the unreliable TP Link connection.

That would leave reliability to the otgw (and of course the Arduino).
The otgw itself runs ok in general (meaning I see no problems at the boiler or thermostat side), but the connection to the outside is having problems: I do receive mqtt values, but can't set the setpoint anymore. According to otmonitor the otgw is in this case in "unknown mode" (not gateway/monitor mode). In this state the otgw does not respond to any command. I have to reset the otgw to get it up and running again. I have no idea if this is related to the TP Link connection problems.


Example of otgw in unknown operating mode. Does not respond to GW=1 command, nor to any other command.

[hvxl]

Just some remarks:

• The gateway is not running in unknown operating mode. But if it doesn't respond to commands, otmonitor is unable to determine the mode it is in.
• The tclkit and exe versions run the exact same code, they are only packaged differently. If one doesn't work correctly, it is probably damaged. Try downloading it again.
• The green icon only indicates (in your case) that a TCP connection exists. If the TCP connection is not properly disconnected, otmonitor has no way of knowing about that. A work-around I suggested in the past is to enable automatic clock updates. That way otmonitor will send a command every minute, at which point it will detect a broken TCP connection.
• The program collects data and messages to display in the graph- and log tabs. As this data grows, so will the RAM and CPU use. But this should stabilize after a few hours when otmonitor starts discarding old data.
• If you're just using otmonitor as an otgw-MQTT gateway, why don't you run it in daemon mode? Then it won't collect all that useless data.
• If LAN is available near the gateway (as you seem to imply with your JeeNode/Arduino remark), then I would switch the TP-LINK from wifi to LAN. That should solve much of the instability issues with the connection.
• I created otmonitor as a debugging aid. It wasn't originally my intention for people to leave it running 24x7. If a JeeNode/Arduino can do the job, I'd say: Go for it!

[Mars]

Just some remarks:

• The gateway is not running in unknown operating mode. But if it doesn't respond to commands, otmonitor is unable to determine the mode it is in.
• The tclkit and exe versions run the exact same code, they are only packaged differently. If one doesn't work correctly, it is probably damaged. Try downloading it again.
• The program collects data and messages to display in the graph- and log tabs. As this data grows, so will the RAM and CPU use. But this should stabilize after a few hours when otmonitor starts discarding old data.

Ok. Thanks for the explanation. I will download otmonitor again and see if that helps!

[*]The green icon only indicates (in your case) that a TCP connection exists. If the TCP connection is not properly disconnected, otmonitor has no way of knowing about that. A work-around I suggested in the past is to enable automatic clock updates. That way otmonitor will send a command every minute, at which point it will detect a broken TCP connection.

My findings are with the 'Automatically update the gateway clock' flag enabled, so that's weird that a broken TCP connection is not properly handled. I still think that the TP-Link software is not very reliable.

[*]If you're just using otmonitor as an otgw-MQTT gateway, why don't you run it in daemon mode? Then it won't collect all that useless data.

Good idea, but I have no idea how to run otmonitor in deamon mode. Will check the documenation.

[*]If LAN is available near the gateway (as you seem to imply with your JeeNode/Arduino remark), then I would switch the TP-LINK from wifi to LAN. That should solve much of the instability issues with the connection.
[*]I created otmonitor as a debugging aid. It wasn't originally my intention for people to leave it running 24x7. If a JeeNode/Arduino can do the job, I'd say: Go for it![/list]

Currently there is no LAN available in the boiler room, that's why I'm using the TP-Link WIFI as a gateway. But yes, it could possibly solve the connection issues. The best solution for me would be to use the JeeNode/Arduino with MQTT either via LAN or using a JeeNode and JeeLink, and send the serial data with a simple script to Mosquitto.

So I still have some work to do
My original problem with the otgw is completely solved, and altough the current solution (TP-Link, otmonitor, Mosquitto, OpenHAB) is not as stable as I want, it seems to have nothing to do with the otgw

Thanx for all your help in finding solutions and work arounds!

[pak]

I get the impression you are not running your gateway with the default setting for IT, i.e.: PR=T will return a 0 in the first position. The first thing to try is to set it back to default with the IT=1 command.

The OTGW doc says about IT:
Ignore Transitions - If the opentherm signal doesn't cleanly transition from one level to the other, the circuitry may detect multiple transitions when there should only be one. When this setting is off (IT=0), the gateway will report "Error 01" for those cases. With this setting on (IT=1), any rapid bouncing of the signal is ignored. This is the default.

Does this imply also that "Error 01" can simply not occur with setting IT=1?

The reason for asking is that I had very similar problems as described in this post. Also with Remeha Calenta and Isense.
But I don't remember having ever touched the IT setting.
Also setting VR=5 (1.667V) worked for me during some time, and then communication locked up.
Resetting usually didn't help. Some uncoordinated and irrational action (power cycling, resetting, disconnection the OTGW, measuring voltages, changing cabling) seemed to help but only for short.
After getting completely desperate and frustrated I reflashed the PIC (from 4.1 to 4.2) which of course also undid all the setting changes I made when experimenting.
Guess what: no more Errors01 and running smooth since about one week.

[hvxl]

Correct, with IT=1 Error 01 can not occur.

Reflashing the PIC does not necessarily clear all settings. If you select the "Transfer old EEPROM settings to the new firmware" option in otmonitor, it will do its best to preserve the settings. That may also be how your IT setting was cleared. IT=0 was the default on firmware 3.X. If you upgraded from 3.X to 4.X with the above option on, you would still have IT=0 on the new firmware.

[pak]

Correct, with IT=1 Error 01 can not occur.

I can confirm that after setting IT back to 1, the OTGW has been running perfectly stable for the past week, and not shown Error01 anymore.
It must have been cause by me when exploring the effect of all settings.