Problem with MySensors MQTT-client Gateway in 0.52

Configuration
,
1

Hi!

I upgraded to ver. 0.52 and this broke my MySensors setup. I’m using an MQTT-client gateway an it has worked flawlessly until now. Reverting to ver. 0.51.2 removes the issue.

edit: @martinhjelmare do you have any input on this? Any help is greatly appreciated! :slight_smile:

Here is the relevant part of configuration.yaml:

mysensors:
  gateways:
  - device: mqtt
    persistence_file: '/config/mysensors.json'
    topic_in_prefix: 'mygateway1-out'
    topic_out_prefix: 'mygateway1-in'
  optimistic: false
  persistence: true
  retain: false
  version: '2.0'

And here is the error log:

Exception in thread Thread-3:
stdout
14:08:49
Traceback (most recent call last):
stdout
14:08:49
  File "/usr/local/lib/python3.6/threading.py", line 916, in _bootstrap_inner
stdout
14:08:49
    self.run()
stdout
14:08:49
  File "/usr/local/lib/python3.6/site-packages/mysensors/gateway_mqtt.py", line 160, in run
stdout
14:08:49
    response = self.handle_queue()
stdout
14:08:49
  File "/usr/local/lib/python3.6/site-packages/mysensors/__init__.py", line 373, in handle_queue
stdout
14:08:49
    reply = func(*args, **kwargs)
stdout
14:08:49
  File "/usr/local/lib/python3.6/site-packages/mysensors/__init__.py", line 201, in logic
stdout
14:08:49
    ret = self._handle_set(msg)
stdout
14:08:49
  File "/usr/local/lib/python3.6/site-packages/mysensors/__init__.py", line 100, in _handle_set
stdout
14:08:49
    msg.child_id, msg.sub_type, msg.payload)
stdout
14:08:49
  File "/usr/local/lib/python3.6/site-packages/mysensors/__init__.py", line 495, in set_child_value
stdout
14:08:49
    msg.validate(self.protocol_version)
stdout
14:08:49
  File "/usr/local/lib/python3.6/site-packages/mysensors/__init__.py", line 610, in validate
stdout
14:08:49
    const = get_const(protocol_version)
stdout
14:08:49
  File "/usr/local/lib/python3.6/site-packages/mysensors/__init__.py", line 31, in get_const
stdout
14:08:49
    if parse_ver('1.5') <= parse_ver(version) < parse_ver('2.0'):
stdout
14:08:49
  File "/usr/local/lib/python3.6/distutils/version.py", line 58, in __le__
stdout
14:08:49
    c = self._cmp(other)
stdout
14:08:49
  File "/usr/local/lib/python3.6/distutils/version.py", line 337, in _cmp
stdout
14:08:49
    if self.version < other.version:
stdout
14:08:49
TypeError: '<' not supported between instances of 'int' and 'str'
stdout
14:08:49
stdout
14:08:51
2

Interesting. I’ve tested the MQTT gateway with Python 3.4 and the protocol_version set to ‘2.0’ and that works. I also tested just now to just run the offending line 31 in mysensors/__init__.py, in Python versions 3.5.3 and Python 3.6.2, which also works.

Specifically what version of python are you using for home assistant?

python --version

Is this perhaps using hass.io?

3

Same problem here. One of my sensor nodes somehow sends None as protocol version and there is a bug in the pymysensors library that crashes the mysensors stack altogether when mysensors version is None.
I made a temporary fix in pymysensors:
On my computer the file path is: /srv/homeassistant/lib/python3.5/site-packages/mysensors/init.py

I have changed line 496 to read:

        except (TypeError, ValueError, AttributeError, vol.Invalid) as exc:

And that solved the problem with the mysensors stack crashing but the reported sensor data does not get processed anymore.
I could not find any pointers as to what am I missing in that sensor firmware, so for now it is better than nothing.

4

Check the version value of None - it throws an unhandled exception in mysensors library.

5

I’m thinking this has to do with the persistence file having protocol_version saved with null as value under a sensor. Does any of you have the possibility to confirm that?

1 Like
6

I have protocol_version set to null in mysensors.json. Corrected it manually and restarted. Let’s see if that helps.

7

Yes, the sensor started reporting after that change.
The question is still - how the null value got to the json?

1 Like
8

Same here, I have multiple sensors that have reported null as protocol_version. I will do as shprota and edit the persistence file manually when I get home from work. That does seem like a quick fix only, would be good to find the root cause.

1 Like
9

In pymysensors 0.10 protocol_version was initialized as None. In 0.11 it’s initialized as '1.4'. If for some reason the message that presented the node didn’t have the protocol version as payload the None value would remain for protocol_version and be stored in the persistence file. That’s my current explanation.

I’m working on a hotfix that should catch and inform of the error and also validate the payload for node presentations specifically.

1 Like
10

Thank you for the explanation. I think, it is also important to have pymysensors catch the null version condition to not crash the whole mysensors stack in such case.

11

I can confirm that clearing the null values from the persistence file fixes the problem. Had to clear null values for sketch_version as well before it started working.

1 Like
12

Thanks for reporting back. A null value for sketch version should not cause an exception, just prevent the sensor from being added to home assistant. Can you confirm that in your experience?