Domoticz

Haha nice one.

Is is definitely faster to setup compared to the also working 100% 'node' solution described in the beginning of this post.
Tnx for sharing.

Hi all,

I'm having problems with my OTGW and Domoticz (as already explained in other topics). (Very) short version: When running the OTGW with OTMonitor everyhing is fine, but when I connect Domoticz to it, it only gives me the messages that start with B or T.

sincze pointed me to this topic, and I have tried the node.js-script. When I run the script (I'm using Putty), I see only one message in the domoticz-log: I see the script running in Putty, but nothing happens within domoticz. Very strange. Can anybody think of a reason for this?

Happy user of the script here.

I've created a (quick and dirty) docker container where otmon and the script are combined:
https://hub.docker.com/repository/docke ... rben/otmon

ernorv wrote: ↑Thursday 02 February 2017 7:12 @jake

Voila

[...]

A bit of a bump after 4 years, but the OTGW firmware got an update to v5 with extra fields in the PS=1 command, can this be adapted for the nodejs app? I've looked myself but I don't understand it completely.

Lizard wrote:

ernorv wrote: ↑Thursday 02 February 2017 7:12 @jake

Voila

[...]

A bit of a bump after 4 years, but the OTGW firmware got an update to v5 with extra fields in the PS=1 command, can this be adapted for the nodejs app? I've looked myself but I don't understand it completely.

I read through the script and I came across a line that verifies that there are 25 responses. I think that as soon as you change that to the new 34, it is supposed to work again

It is not only that the V5 firmware now has 34 instead of 25 fields, also the order of the fields has changed (still the order is the OpenTherm MsgIDs but some new MsgIDs have been added in between)

kiddigital wrote:It is not only that the V5 firmware now has 34 instead of 25 fields, also the order of the fields has changed (still the order is the OpenTherm MsgIDs but some new MsgIDs have been added in between)

This script allows users to exchange what they want to show up in the ps=1 string. For myself I have exchanged an unused parameter for my solar boiler temperature. I don't think that the new order matters here. That is taken care of in domoticz by the normal OTGW hardware

jake wrote:

kiddigital wrote:It is not only that the V5 firmware now has 34 instead of 25 fields, also the order of the fields has changed (still the order is the OpenTherm MsgIDs but some new MsgIDs have been added in between)

This script allows users to exchange what they want to show up in the ps=1 string. For myself I have exchanged an unused parameter for my solar boiler temperature. I don't think that the new order matters here. That is taken care of in domoticz by the normal OTGW hardware

I updated my Opentherm Gateway over the weekend to 5.2. I couldn't find the previous version, but I expected 5.0 or 5.1.
From that moment my solar boiler reported 0.0'C in Domoticz, but still the correct temperature in OTmonitor. It scared me, since I had replaced a faulty temperature sensor in the solar boilier just that same afternoon. To find a 0.0'C temperature in Domoticz wasn't funny.

Anyway, after comparing, splitting the PS=1 string etc. I was 'rescued' by my own input here above: I obviously didn't run a +5.0 firmware, because the otgwmod was using position 11 for solar temperature ID=29. Position 11 originally was used for DHW temperature, which my boiler doesn't supply. I used that position for the solar boiler instead, using the same type of temperature sensor in Domoticz.

After I put ID=29 on position 15 and the sample change (ID=29) from position 12 (<5.0 version) to the current (+5.0 version) position 22, Domotidz was happy again.

in OTGWmod.js I also change the code tmp.length == 25 to tmp.length == 34 to meet the current PS=1 length.

Summary:
OTGWmod works just fine in +5.0 versions of the gateway as long as:
- New position in the PS=1 string is used for the value that needs to be replaced
- tmp.length == 25 is changed to tmp.length == 34