Opentherm Gateway 4.0 alpha/beta testers wanted

[nlrb]

Just want to report that I'm running firmware 4.0b1 for a week now and it runs stable without any problems. Thanks for making sure it doesn't reset anymore .

BTW: only issue I had is that OH was set to 0 instead of 1, which should be the default. This is probably due to the fact that the new otmonitor copies EEPROM settings by default. I would propose to turn this off by default (because of backward/forward compatibility of settings).

[Warwar]

I expect people will either want to use the gateway with or without a thermostat all the time. Remotely disconnecting the thermostat when you're far away doesn't sound like a common use-case to me.

thanks for your replay
just today i thought about it right this way!

Furthermore it's already possible to take over control of the boiler from the connected thermostat by overriding the control commands the thermostat sends (using the CS and MM commands).

thanks, i want to try it, just in case...
read alpha/beta firmware changes many times, still found commands i don't know yet...

If your aim is to use the gateway as a simple opentherm to serial converter, it makes more sense to do that with dedicated firmware rather than trying to cram that function into the very limited remaining space left in the current firmware.

yes, actually i understand your point, and i respect it...
i just so excited about possibilities given by OTGW...
and i want to explore all boiler capabilities...
i don't see 'Ferroli' in your Equipment matrix, so i want to fill this hole.
you did great work... you connect different thermostats, boilers... you follow OT specs and try to make some 'workaround' for those thermostats/boilers which don't do this... it's a lot of work... i know...
i have a skill in atmega/pic programming, but it's not so good as it needs to be to implement OpenTherm by myself, i suppose...
so my point is... let's pretend you have a lot of free time and don't know what to do... just pretend...
maybe you can do such 'custom firmware' without affecting working one?

ps: I'm running firmware 4.0b1 for a week now and it runs stable without any problems, too.
upd: MM command "does not work", because thrmostat does not write message 14 to the boiler. CS works.

[hvxl]

BTW: only issue I had is that OH was set to 0 instead of 1, which should be the default. This is probably due to the fact that the new otmonitor copies EEPROM settings by default. I would propose to turn this off by default (because of backward/forward compatibility of settings).

It would be a pretty useless option if it wasn't supposed to handle differences between firmware versions. However, currently it only handles those differences on a byte level. The OH option was just a new bit in a byte that was already used before. Obviously I will have to make sure that gets handled properly as well.

[hvxl]

Would you make some sort of command line otmonitor? Maybe ncurses..?
Even just the ability to flash firmware without GUI will be perfect!

Starting with otmonitor 4.0b0 it was already possible to run the program without a GUI, using the --daemon command line option. You can then interact with it using a web browser or via dbus. Version 4.0b2, which has just been published, includes a web page for upgrading the firmware. Note: This web page uses websockets and has only been tested with Firefox 25.0.

If you just want to flash the firmware without a GUI, that's now possible with the --upgrade command line option:

Code: Select all

$ otmonitor --upgrade gateway.hex
Current firmware version: 4.0b0
Target firmware version: 4.0b1
Switching gateway to self-programming mode
Bootloader version 1.1: F00-FFF
Firmware download succeeded - 0 retries

[hvxl]

Would it be possible to add an outside temperature offset? ie OO=-1.5 ? The placement of the dallas probe isn't optimal in my case and it allways reads the temp too high.

I haven't been able to come up with a way to do this without consuming an unreasonable amount of PIC resources for the number of users that would benefit from such a feature. So I'm afraid it doesn't look promising.

[sappien]

I've got a problem with the setpoint setting. When I send a TT= to the gateway, the setpoint is correctly adjusted. But after 30/40 minutes the iSense restores the setpoint.
(iSense program is 07:00 21C - 21:00 15C) (using OTC+Eco mode setting)

14:00 i've send TT=15
14:40 Setpoint is set back to 19

The 19 degrees didn't come from the thermostat schedule or a serial command to the gateway. Maybe someone manually adjusted the setpoint on the thermostat? Do you have a log?

@hvxl

I've uploaded the log in my own topic. (domoticaforum.eu/viewtopic.php?f=75&amp ... amp;t=9211)

[hvxl]

so my point is... let's pretend you have a lot of free time and don't know what to do... just pretend...
maybe you can do such 'custom firmware' without affecting working one?

Mwah, what else to do on a rainy Sunday? Try this.

That firmware only reports the messages it receives without taking any action on them. It expects to be told via the serial interface which messages to send. The messages must be specified as 8 hex digits, including a correct parity bit, terminated by a CR (0x0d). Only a few of the other serial commands work, like VR, IT, and GW=R. It does have one safety feature: If no messages have been sent to the boiler for 5 seconds, the line to the boiler is made high. Otherwise a boiler may interpret the situation as an OT/- heat request.

I haven't done much testing. I'll leave that up to you.

[Warwar]

Mwah, what else to do on a rainy Sunday? Try this.

That firmware only reports the messages it receives without taking any action on them. It expects to be told via the serial interface which messages to send. The messages must be specified as 8 hex digits, including a correct parity bit, terminated by a CR (0x0d). Only a few of the other serial commands work, like VR, IT, and GW=R. It does have one safety feature: If no messages have been sent to the boiler for 5 seconds, the line to the boiler is made high. Otherwise a boiler may interpret the situation as an OT/- heat request.

I haven't done much testing. I'll leave that up to you.

WOW! Thank you so much! I'll definetly try it!... I did not expect it so fast, so now i must write my part - a program to generate messages.
does it cut off thermostat line completely? or it passes thermostat messages through, so i need to cut off thermostat line if i need do thermostat job by myself?

Last sunday, yesterday, i was testing my boiler/thermostat using gateway-4.0b1.hex firmware and otmonitor.exe 4.0b2.
Now i have 3 logs and some questions.
1st log - OTGW in monitor mode, i did not push any buttons on thermostat or boiler, just start, watch and record. I only set room setpoint to 20 shortening thermostat's GSM contacts to record log with boiler working.
2nd log - OTGW in monitor mode, i tried to push all buttons on thermostat, change settings, show data which thermostat can show
3d log - OTGW in GW mode, i add AA=16 and search supported id which thermostat does not ask for.

How can i send this logs to you?
Through "Upload log file" on site i can't add notes to logs. I can add remarks to the head of each log.

Setup (3d log):
- OTGW in GW mode
- UI=16
if i set AA=ID, where ID<128, all work as expected regardless of ID's known/unknown state
if i set AA=ID, where ID>128, and this id is Unk ID, this ID 'automaticaly' deleteed from alternatives list, so next command DA=ID, return NF
if i set AA=ID, where ID>128, and this id reports some data, all works as expected and i need to set DA=ID to delete alternative from list
- is it bug or feature?

there is some unpredicted behavior with UI if alternatives list is empty:
- OTGW in GW mode
- UI=16
- AA='ID_1'
output shows command ID_1 send to boiler
- DA='ID_1' (list of alternatives became empty)
- AA='ID_2'
fifty/fifty... sometimes OTGW sends command ID_2, sometimes 16, like i set KI=16 before
but, if i do above in revers order, first AA='ID_2', then DA='ID_1' - works as it should in 100%!
- is it bug or feature?

in additon, i have found some IDs abve 128, for which boiler return some data... i don't know what to do with it just watching now
common question: why it's called OPENtherm if spec does not published for public?
if someone can find spec 3.0... or maybe i should ask my local dealer for supported IDs well, i wrote e-mail... let's wait a bit...

btw, i saw your message about 'guiless' mode of otmonitor, where i can find detailed info about supported flags/features and how to use otmonitor in 'daemon' mode?

[hvxl]

So many questions ...

does it cut off thermostat line completely? or it passes thermostat messages through, so i need to cut off thermostat line if i need do thermostat job by myself?

As mentioned, opentherm messages received are reported on the serial interface, messages specified via the serial interface are transmitted via opentherm. If the specified message is a Master-to-Slave message, the gateway sends it to the boiler. A Slave-to-Master message is sent to the thermostat.

How can i send this logs to you?

I'll send you my email address via PM.

if i set AA=ID, where ID>128, and this id is Unk ID, this ID 'automaticaly' deleteed from alternatives list, so next command DA=ID, return NF

Any ID specified via AA will be removed from the list when the gateway determines that it is not supported by the boiler. There is no difference between ID's above and below 128. The gateway considers an ID unsupported when the boiler returns Unk-DataID 3 times in a row. If an ID is specified in the AA command that the gateway already considers unsupported, it will only be sent once before it is removed from the list again upon receipt of an Unk-DataID response. Maybe this is the difference you saw?

sometimes OTGW sends command ID_2, sometimes 16, like i set KI=16 before but, if i do above in revers order, first AA='ID_2', then DA='ID_1' - works as it should in 100%!

There should be no difference. Which log contains this scenario?

if someone can find spec 3.0... or maybe i should ask my local dealer for supported IDs well, i wrote e-mail... let's wait a bit...

The opentherm spec 3.0 will not have information about IDs above 128. Those are vendor specific IDs, not standardized.

btw, i saw your message about 'guiless' mode of otmonitor, where i can find detailed info about supported flags/features and how to use otmonitor in 'daemon' mode?

You can get information about the supported flags by running otmonitor --help. I have no idea whether that works on windows. Probably not.

In daemon mode, otmonitor does exactly the same things it normally does, it just doesn't display a GUI. So, if configured, it will write the logfile and datafile, it listens on the relay server port, the web server will be up and running, it keeps the gateway updated with the current time, it provides its dbus interface, and I may have forgotten something.

Obviously not having a GUI makes it hard to configure otmonitor. Therefor I suggest to run it at least once with a GUI, configure it, and close it. That is supposed to save the settings which it will use when you subsequently run it in daemon mode.

[Warwar]

As mentioned, opentherm messages received are reported on the serial interface, messages specified via the serial interface are transmitted via opentherm. If the specified message is a Master-to-Slave message, the gateway sends it to the boiler. A Slave-to-Master message is sent to the thermostat.

ok, got it, maybe
so if i will be read messages from com-port and send them back as-is, thermostat and boiler should be talking to each other as there is no OTGW in between.
am i right?

I'll send you my email address via PM.

i send you logs.

if i set AA=ID, where ID>128, and this id is Unk ID, this ID 'automaticaly' deleteed from alternatives list, so next command DA=ID, return NF

Any ID specified via AA will be removed from the list when the gateway determines that it is not supported by the boiler. There is no difference between ID's above and below 128. The gateway considers an ID unsupported when the boiler returns Unk-DataID 3 times in a row. If an ID is specified in the AA command that the gateway already considers unsupported, it will only be sent once before it is removed from the list again upon receipt of an Unk-DataID response. Maybe this is the difference you saw?

maybe, but why OTGW considers unsupported all messages with ID > 128?
you've said, what OTGW monitors for Unk ID only messages with ID < 128... could it be problem point?

sometimes OTGW sends command ID_2, sometimes 16, like i set KI=16 before but, if i do above in revers order, first AA='ID_2', then DA='ID_1' - works as it should in 100%!

There should be no difference. Which log contains this scenario?

i attache new log, just created, to this post.
in OTGW i have already set UI=16, AA=18, then i start otmonitor:
blocks, showing UI&AA is working

03:20:42.536822 T90100B00 Write-Data Room setpoint: 11.00
03:20:42.542145 R00120000 Read-Data CH water pressure: 0.00
03:20:42.726941 B40120166 Read-Ack CH water pressure: 1.40
03:20:42.732452 A50100B00 Write-Ack Room setpoint: 11.00

then DA=18, list of alternatives empty

03:21:10.653869 T90100B00 Write-Data Room setpoint: 11.00
03:21:10.834022 B50100B00 Write-Ack Room setpoint: 11.00

as it should be
then i AA=18 again, but nothing changes, still

03:21:38.814179 T90100B00 Write-Data Room setpoint: 11.00
03:21:38.963367 B50100B00 Write-Ack Room setpoint: 11.00

just after UI=16

03:23:03.320735 T90100B00 Write-Data Room setpoint: 11.00
03:23:03.326478 R00120000 Read-Data CH water pressure: 0.00
03:23:03.421323 B40120166 Read-Ack CH water pressure: 1.40
03:23:03.426896 A50100B00 Write-Ack Room setpoint: 11.00

works as it should be

2nd bug/feature:

egrep "(129|DA)" otlog-20131222_log3.txt:
21:11:29.807583 Command: AA=129
21:11:29.847053 AA: 129
21:12:01.640613 R00810000 Read-Data Message ID 129: 0
21:12:01.797892 BF0810000 Unk-DataId Message ID 129: 0
21:12:34.826998 Command: DA=129
21:12:34.874298 DA: NF

today i was exploring IDs only above 128, so
- i set UI=16, AA=235 (for example)
- wait till OTGW receive ID 16 and sent ID 235 to the boiler, get Unk ID from boiler (once)
- try to delete DA=235, got a NF response.

You can get information about the supported flags by running otmonitor --help. I have no idea whether that works on windows. Probably not.

In daemon mode, otmonitor does exactly the same things it normally does, it just doesn't display a GUI. So, if configured, it will write the logfile and datafile, it listens on the relay server port, the web server will be up and running, it keeps the gateway updated with the current time, it provides its dbus interface, and I may have forgotten something.

Obviously not having a GUI makes it hard to configure otmonitor. Therefor I suggest to run it at least once with a GUI, configure it, and close it. That is supposed to save the settings which it will use when you subsequently run it in daemon mode.

thanks
i've tried to get --help some time ago, but probably i was trying with 3.3 version - nothing happened
can you show some code how to use dbus? or is it question of dbus faq?

[hvxl]

so if i will be read messages from com-port and send them back as-is, thermostat and boiler should be talking to each other as there is no OTGW in between.
am i right?

Correct. That's exactly how my test program for this firmware started out. You do have to strip the T and/or B form the reported messages.

you've said, what OTGW monitors for Unk ID only messages with ID < 128... could it be problem point?

You're right. Sorry for any confusion my remark may have caused. In any case the gateway will not count 3 Unk-DataID responses. I'm not sure if it will consistently flag a message as unsupported after 1 Unk-DataID, or if the behavior depends on random data. I will investigate this.

can you show some code how to use dbus?

The easiest way from the command line is to use qdbus. Here's an example for when you don't have qdbus (e.g. on a raspberry pi):

Code: Select all

$ dbus-send --print-reply --dest=com.tclcode.otmonitor / com.tclcode.otmonitor.Command :PR=A
method return sender=:1.92 -> dest=:1.97 reply_serial=2
   string "PR: A=OpenTherm Gateway 4.0b1"

Many scripting languages have dbus libraries that will also allow you to interact with otmonitor. For example to do the same thing in python:

Code: Select all

import dbus
bus = dbus.SessionBus()
ot = dbus.Interface(bus.get_object('com.tclcode.otmonitor', '/'),
        dbus_interface='com.tclcode.otmonitor')
print ot.Command('PR=A')

I'll get back to you on the other points after I have examined the logs.

[Warwar]

About interface converter: now i've got all needed info and it's my turn.

The easiest way from the command line is to use qdbus. Here's an example for when you don't have qdbus (e.g. on a raspberry pi):
...
Many scripting languages have dbus libraries that will also allow you to interact with otmonitor. For example to do the same thing in python:
...

Thanks in advice.
I've already found 'com.tclcode.otmonitor', but i used dbus-monitor, to monitor events, generated by otmonitor. I did not found, how to send messages and get some feedback.
I will probably use dbus-glib, anyway thanks.

[sappien]

I can't start otmonitor as a daemon... When starting it with gui is runs without any problem.

Code: Select all

root@voyage:~# ./otmonitor1 --webserver=85 --daemon /dev/ttyUSB50
can't read "gui::imgdir": no such variable
    while executing
"wibble handle /images staticfile root $gui::imgdir"
    (file "/root/otmonitor1/web.tcl" line 132)
    invoked from within
"source /root/otmonitor1/web.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source [file join /root/otmonitor1 $file]]"
    (procedure "include" line 2)
    invoked from within
"include web.tcl"
    (file "/root/otmonitor1/otmonitor.tcl" line 1416)
    invoked from within
"source /root/otmonitor1/otmonitor.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source [file join /root/otmonitor1 $file]]"
    (procedure "include" line 2)
    invoked from within
"include otmonitor.tcl"
    (file "/root/otmonitor1/main.tcl" line 11)

[hvxl]

I can't start otmonitor as a daemon... When starting it with gui is runs without any problem.

Thanks for the report. I made a slight change to the program to fix this. You didn't specify which platform you are running this on, but I guess it's linux-x86. I have created a version 4.0b2.1 of otmonitor only for that platform.

[trie]

I can't start otmonitor as a daemon... When starting it with gui is runs without any problem.

Thanks for the report. I made a slight change to the program to fix this. You didn't specify which platform you are running this on, but I guess it's linux-x86. I have created a version 4.0b2.1 of otmonitor only for that platform.

Do you also have a Linux x86_64 or the raspberry version of this? Then I can get the logging on console as well.