Firmware version 4.0 has been released.

[hvxl]

Summer is here and judging by the amount of messages on the forum that reduces the time spent tinkering with the central heating for many of the beta testers. So I decided the time has come to let the final version of firmware 4.0 escape.

I like to take this opportunity to express my thanks to all the beta testers who were willing to take the risk of running into bugs for the benefit of all gateway users. Their feedback has been crucial to make firmware 4.0 what it is today. Also, very special thanks to Rutger, who was kind enough to loan me his Remeha iSense thermostat for almost a year and a half now. I wouldn't have been able to make all the iSense tweaks and the Smart Power support without it.

The new firmware can be downloaded for the download page. I suggest to check out the rest of the web site as well, which has been updated with all the new features.

[mike7]

Schelte,

I want to confirm, issues with VR & SR=10 commands are solved with the firmware. Special thanks for updated dbus notifications in otmonitor.

May I ask to extend functionality of firmware & otmonitor?
PM=10 command in my case takes a lot of time (I have 43 TSPs), could you please add read/write support for ID 11 without special processing for PM=10?
Could you please add MQTT support for otmonitor, such functionality will allow to add additional processing. It will be useful if you can publish unprocessed messages and responses from gateway with the same list of signals as for dbus. I think 'events' topic from DomoMQTT standard will be the right place with configurable root and device_type/device_id. I found MQTT tcl library here https://github.com/Tingenek/tcl-mqtt.

PS. I think it's time to update dbus.html with full list of signals

EDIT:
I want a bit more , may be you can extend dbus and add http command interface for otmonitor itself, I think following commands will be useful:

• Start/Stop/Pause/Resume writing outputfile, datafile, dbus & mqtt(if will be implemented)
  Publish all current values & states on dbus & mqtt, will be useful on reconnection to otmonitor to get the current state

Looking to the otmonitor code, I found (P) function for a LED, it's missed in documentation.

[blb]

Hi Schelte,

thanks for all your work on this!! I've updated towards this 4.0 version and spotted a minor bug: in the PS=1 output the value of the "Boiler water temperature (MsgID=25)" and the "Max CH water setpoint (MsgID=57)" isn't always a correct value. In most cases the value is in the correct format 'xx.xx', but in some cases the output for these messages this is as 'xx.:0'

[hvxl]

Great! That code hasn't changed since it was introduced in firmware 2.0, over 3 years ago. There have been 4.0 alpha and beta versions for more than a year. And you report this two days after I finally release the 4.0 firmware.

[blb]

Strange, I didn't see this in the latest beta version I have used, I do remember something similar happened before, but you fixed that and again, I didn't see this in the latest beta versions. Sorry .....


BlB

[hvxl]

There is absolutely no need for you to apologize. These things happen. I appreciate that you report bugs as you encounter them. It's just a pity that you only encountered this one right after the release of firmware 4.0.

I checked the code and this can never have worked correctly. It just needs an uncommon situation to occur. If the data bytes represent a floating point number and have a value of, for example, 0x17 & 0xff, that means 23.996. The code prints the 23 before it figures out that the 996 should be rounded up. The rounding results in 100, which doesn't fit in two digits and as a result you get an invalid value of 23.:0. It should have printed 24.00. The reason this doesn't happen very frequently is that most temperature sensors don't provide such a high resolution. It's either 24.0 or 23.9 degrees, or even 23.99, but not 23.996.

I guess the earlier fix you were thinking of was for printing values above 199 (firmware 4.0a9). That was a different case, although it resulted in similar invalid characters in numbers.

[mike7]

Hi Schelte,

I tried to check my code to catch "Thermostat disconnected/connected" events, I set VR=3 and can't reproduce my previous situation, instead I've got a lot of repeated (retransmitted?) messages. Error 01 is still 0, IT=1 didn't help, I restored VR=4 and gateway continued to work perfectly. Small log is attached.

[hvxl]

This is very strange. The VR setting should only be affecting the ability for the gateway to understand the opentherm signals it receives. Your logs shows no issue in that area. Messages are going back and forth once per second without errors.

The setting has no effect on the outgoing opentherm signal. So why your thermostat behaves different with VR=3 and VR=4 (or how it can even detect the change) is a mystery to me.

[hvxl]

I've updated towards this 4.0 version and spotted a minor bug: in the PS=1 output the value of the "Boiler water temperature (MsgID=25)" and the "Max CH water setpoint (MsgID=57)" isn't always a correct value. In most cases the value is in the correct format 'xx.xx', but in some cases the output for these messages this is as 'xx.:0'

Fixed in 4.0.1. Now we have to wait at least another 3 years to see if the corrupt values don't appear anymore

[blb]

Hi Schelte,

Installed version 4.01 1,5 hour ago, I haven't see this error any more .

[mike7]

The setting has no effect on the outgoing opentherm signal. So why your thermostat behaves different with VR=3 and VR=4 (or how it can even detect the change) is a mystery to me.

Unfortunately I don't have oscilloscope. I hope I will choose different thermostat before autumn will come, it's very difficult in Russia.
Thank you very much.

[hvxl]

Could you please add MQTT support for otmonitor [...] I found MQTT tcl library

Since I didn't have any experience with MQTT, I had some studying to do. Unfortunately the Tcl MQTT library you found lacked quite a bit of functionality, so I ended up writing my own. Due to my unfamiliarity with the subject I also had to make some guesses on various MQTT parameters. My first attempt is otmonitor 4.1b0. Please let me know if that is sort of what you were imagining.

[mike7]

Please let me know if that is sort of what you were imagining.

You did it, thank you very much!
There are a lot of forum's members who are using MQTT, I hope they will give useful suggestions.
I'm also starting to lean mqtt, I have got RaspberriPi with mosquitto and Node-RED installed.
I like you idea with persistent messages.

I think following will useful:
- prefix for the topic, for example sweethome/events/... , parentshouse/events/... etc
- unprocessed messages from gateway, your monitor is very useful software and I'm using it, but functionality can be easily extended with additional processing of raw messages.

Currently I'm using http interface for command, in such case I have got response.

PS. I have no knowledge of tcl, but when I looked to the code I found "signal gwreset" but in dbus.tcl "define / GatewayReset"

[mike7]

Hi Schelte,

I think timestamp (ex. in milliseconds since 1970/01/01) and type or format of the value will be useful in json format for mqtt.

[hvxl]

The type of the value is always the same for a particular parameter, so it's a waste of bandwidth to transmit that information every time (I understand MQTT was designed to keep the messages small). But obviously JSON isn't the most appropriate format if bandwidth is a consideration. So I've added two more JSON formats to otmonitor 4.1b1.

Re: Prefix for the topic: I'm not sure that's allowed. The DomoMQTT specification says "The events topic has the following format: events/device_type/device_id/property".

Re: GatewayReset versus gwreset: That's clearly not going to work. I've fixed it. Thanks for reporting.

I don't understand what you are trying to say regarding the unprocessed messages and using http interface for command. If you want me to change something there, please explain a bit more.