negative outside temperature results in wrong values on MQTT

[gdschut]

Hi, I use your otgw - mqtt bridge for a couple of months now and want to say thanks for creating this! It is awesome! I use it in combination with Home Assistant on a RPi and OTGW with ESP and ESPLink near the central heating system. Recently I found out that it succeeds in changing the outside temperature from HA to MQTT to OTGW, but with temperatures below zero, the returning value is wrong in MQTT. It is correctly received from OTGW into the py-otgw-mqtt (as seen in the log) but placed wrong on MQTT. Seems like a value of 256 minus the temperature. I guess it has something to do with the handling of the floats, but I am not very experienced in python to be sure. some lines from the log (changed one line to warn from debug): Feb 26 05:51:51 pi python[585]: INFO:main:Received message on topic set/otgw/outside_temperature with payload -0.2

Feb 26 05:51:51 pi python[585]: INFO:__main__:Sending command: 'OT=-0.20'
Feb 26 05:51:52 pi python[585]: WARNING:opentherm:Did not understand message: 'OT: -0.20'
Feb 26 06:11:56 pi python[585]: INFO:__main__:Received message on topic set/otgw/outside_temperature with payload -0.1
Feb 26 06:11:56 pi python[585]: INFO:__main__:Sending command: 'OT=-0.10'
Feb 26 06:11:57 pi python[585]: WARNING:opentherm:Did not understand message: 'OT: -0.10'

and on MQTT: pi@pi:~ $ mosquitto_sub -v -h 127.0.0.1 -p 1883 -t '#' |grep otgw/outs

value/otgw/outside_temperature 255.8
set/otgw/outside_temperature -0.1
value/otgw/outside_temperature 255.9

(not exactly from the same moment, but I think it explains what I mean)

Can you fix this or point to any help how I can fix this myself? If I can be of any help in testing or anything I would like to of course! Thanks!

[martenjacobs]

Right. That seems simple enough to fix. I’ll try to have a look sometime in the next few days.

[gdschut]

To be honest I have to admit I am using the version from jodur, as it is working out of the box without any changes. Diffing it shows differences on reconnects, error handling and import select. Seems nothing to do with floats etc. As jodur is not accepting issues and you do, I thought to ask you for the temperatures below zero issue. For me it is a bit diffusing to see 3 (also wouterbaake) repositories with almost the same sources, where no one has "the best one"... I think I do not understand github / software development enough... If you want a version that is working out of the box, and quite stable, you might have a look at jodurs version... (wouterbaake's version seems to me almost the same as jodur's one.) I hope you still want to help me with the outside temperature issue! Thanks anyway for creating this program!

[martenjacobs]

Okay, that means I could still fix the issue in this repo, but it wouldn't be much help to you.

As for you being confused with how software development with git works, I'll try to explain a bit: A few years ago I started building this application to get my serial-based OTGW to work with Home Assistant. I published my work here for others who might find it useful. I built the app so that transport protocols could easily be added, but as my use case involves serial only, I only implemented and tested that one. Jodur found my repo and decided to add tcp-support for his own use case, thus he forked this repo and got to work. After he was finished, he sent me a pull request, asking to merge his code into this repo (#1 and #3), but these were never merged (as for why, please read through the pull requests themselves). Wouterbaake has also made changes in his own fork and asked me to pull these as well (#6), however, he is yet to respond to my review of his changes.

So basically, there is no "best" repo; everyone can create a fork and add the changes they'd like to the source code. You are right in saying this makes deciding which one to use difficult, especially for small apps like this one. You never know which repos will be maintained and which ones wont be.

I'm planning to keep using this app so I'll probably keep maintaining it in this repo. However, as my use case is still serial only, there won't be much new development towards TCP support from me outside of simple fixes. To make it even more difficult for you: there's also a TCP branch in this repo which I've heard is working as well (#13).

[gdschut]

Thanks for explaining. No worries, I can find the change and implement it in my local code if you fix this. Perhaps I have to fork also your repo.... As a matter of fact I use the TCP branche, which I also do not fully understand, because I think it can be merged back into the master to get a full multiprotocol client, is nt it??? Anyway, until the HA implemtation of the Opentherm Gateway component is stable, i will be using the TCP version of the py-otgw-mqtt program. I do know something about software development from the past, but have almost no python experience. But if I can be of any help in testing, please let me know! PS: one change I made locally was to set the mqtt message "online" to always retain=true as you did in the master, but not in tcp branch (line 55 of main.py), but dont know how to fit this in a pull request...

[gdschut]

Regarding the issue: It might be less easy solved as I think there is something wrong with the message received perhaps: I added a logstatement in opentherm.py printing the message like this:

def get_messages(message):
    r"""
    Generate the pub-messages from the supplied OT-message

    Returns a generator for the messages
    """
    info = line_parser.match(message)
    log.info("Message is: '{}'".format(message))
    if info is None:
        if message:

and got this:

Feb 27 10:54:31 pi python[9570]: INFO:opentherm:Message is: 'BC0110000'
Feb 27 10:54:32 pi python[9570]: INFO:opentherm:Message is: 'T80190000'
Feb 27 10:54:32 pi python[9570]: INFO:opentherm:Message is: 'BC019395E'
Feb 27 10:54:33 pi python[9570]: INFO:opentherm:Message is: 'T10101433'
Feb 27 10:54:33 pi python[9570]: INFO:opentherm:Message is: 'BD0101433'
Feb 27 10:54:34 pi python[9570]: INFO:opentherm:Message is: 'T80000200'
Feb 27 10:54:34 pi python[9570]: INFO:opentherm:Message is: 'B40000200'
Feb 27 10:54:35 pi python[9570]: INFO:opentherm:Message is: 'T10011100'
Feb 27 10:54:35 pi python[9570]: INFO:opentherm:Message is: 'BD0011100'
Feb 27 10:54:36 pi python[9570]: INFO:opentherm:Message is: 'T00110000'
Feb 27 10:54:36 pi python[9570]: INFO:opentherm:Message is: 'BC0110000'
Feb 27 10:54:37 pi python[9570]: INFO:opentherm:Message is: 'T80190000'
Feb 27 10:54:37 pi python[9570]: INFO:opentherm:Message is: 'BC019395E'
Feb 27 10:54:38 pi python[9570]: INFO:opentherm:Message is: 'T901814F0'
Feb 27 10:54:38 pi python[9570]: INFO:opentherm:Message is: 'B501814F0'
Feb 27 10:54:39 pi python[9570]: INFO:__main__:Received message on topic set/otgw/outside_temperature with payload -2.5
Feb 27 10:54:39 pi python[9570]: INFO:__main__:Sending command: 'OT=-2.50'
Feb 27 10:54:39 pi python[9570]: INFO:opentherm:Message is: 'T80000200'
Feb 27 10:54:39 pi python[9570]: INFO:opentherm:Message is: 'B40000200'
Feb 27 10:54:39 pi python[9570]: INFO:opentherm:Message is: 'OT: -2.50'
Feb 27 10:54:39 pi python[9570]: WARNING:opentherm:Did not understand message: 'OT: -2.50'
Feb 27 10:54:41 pi python[9570]: INFO:opentherm:Message is: 'T10011100'
Feb 27 10:54:41 pi python[9570]: INFO:opentherm:Message is: 'BD0011100'

Is there realy a minus expected in the message??? Shouldnt be the message matched with the regex??? Perhaps my central heating is not sending a correct message? (I have a CH system from Intergas HRE line)

[andriej]

I'm also using TCP branch (and would like to see further development adding new options - gas fault, heater fault etc. - full protocol) Minus values are working for me.

[martenjacobs]

Hi gdschut,

I've just added a message explaining the fact that I'm not actively maintaining this package anymore. This means I'll not be fixing this bug.

[gdschut]

Hi! Thanks for the message. I switched to a direct connection to OTGW from Home Assistant, which is more or less stable right now.