The problem

When I refresh the Velbus Integration i receive the flowing errors in the configuration logs:
Logger: velbus
Source: /usr/local/lib/python3.8/site-packages/velbus/controller.py:311
First occurred: 4:09:17 PM (6 occurrences)
Last logged: 4:09:35 PM

Module VMBGP4PIR does not yet support sub modules
Module VMBGP4-2 does not yet support sub modules

For the modules of this type i also have the flowing error in the configuration logs:
Logger: velbus
Source: /usr/local/lib/python3.8/site-packages/velbus/controller.py:161
First occurred: 4:12:46 PM (4 occurrences)
Last logged: 4:12:46 PM

Failed to completely load module VMBGP4PIRK at address 8 before timeout expired.
Failed to completely load module VMBGP4 at address 176 before timeout expired.
Failed to completely load module VMBGP4PIRBad at address 177 before timeout expired.
Failed to completely load module VMBGP4PIR Living at address 191 before timeout expired.

The rest of the modules works fine only those 2 types are not working and not present in the devices.

Environment

• Home Assistant Core release with the issue:
  Version | 0.118.3
• Last working Home Assistant Core release (if known):
  Not working sinds begin testing.
• Operating environment (OS/Container/Supervised/Core):
  Installation Type | Home Assistant OS
• Integration causing this issue:
  Velbus
• Link to integration documentation on our website:
  https://www.home-assistant.io/integrations/velbus/

Problem-relevant configuration.yaml

It is the discovery that fails

Traceback/Error logs

Source: /usr/local/lib/python3.8/site-packages/velbus/controller.py:311
First occurred: 4:09:17 PM (6 occurrences)
Last logged: 4:09:35 PM

Module VMBGP4PIR does not yet support sub modules
Module VMBGP4-2 does not yet support sub modules

Logger: velbus
Source: /usr/local/lib/python3.8/site-packages/velbus/controller.py:161
First occurred: 4:12:46 PM (4 occurrences)
Last logged: 4:12:46 PM

Failed to completely load module VMBGP4PIRK at address 8 before timeout expired.
Failed to completely load module VMBGP4 at address 176 before timeout expired.
Failed to completely load module VMBGP4PIRBad at address 177 before timeout expired.
Failed to completely load module VMBGP4PIR Living at address 191 before timeout expired.

Additional information

Both VMB2BL (2-channel blind control module) and VMB2BLE (Two-channel blind control module with extended possibilities for din rail) send the blind status via the command_code 0xEC.
blind_status.py was written for VMB2BLE and works correctly for this module. For VMB2BL, blind status messages give an error due to differences in protocol:

VMB2BLE (protocol_info page 7/29)
Transmits the blind status:
DATABYTE1 = COMMAND_BLIND_STATUS (H’EC’)
DATABYTE2 = Blind channel
Contents - Relay number
B’00000001’ - Blind 1
B’00000010’ - Blind 2

VMB2BL (protocol_info page 5/13)
Transmits the blind status:
DATABYTE1 = COMMAND_BLIND_STATUS (H’EC’)
DATABYTE2 = Blind channel
Contents - Blind channel
B’00000011’ - Blind 1
B’00001100’ - Blind 2

According to the error message I got on my Raspberry Pi this gives a problem on line 74 of /python-velbus/velbus/messages/blind_status.py:
self.channel = self.byte_to_channel(data[0])

Error:

Traceback (most recent call last):
File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.5/dist-packages/serial/threaded/init.py", line 211, in run
self.protocol.connection_lost(error)
File "/usr/local/lib/python3.5/dist-packages/serial/threaded/init.py", line 34, in connection_lost
raise exc
File "/usr/local/lib/python3.5/dist-packages/serial/threaded/init.py", line 206, in run
self.protocol.data_received(data)
File "/home/pi/my_velbus/velbus/connections/init.py", line 16, in data_received
self.parser(data)
File "/home/pi/my_velbus/velbus/connections/init.py", line 87, in feed_parser
self.controller.feed_parser(data)
File "/home/pi/my_velbus/velbus/controller.py", line 44, in feed_parser
self.parser.feed(data)
File "/home/pi/my_velbus/velbus/parser.py", line 29, in feed
self.next_packet()
File "/home/pi/my_velbus/velbus/parser.py", line 80, in next_packet
message = self.parse(next_packet)
File "/home/pi/my_velbus/velbus/parser.py", line 127, in parse
message.populate(priority, address, rtr, data[5:-2])
File "/home/pi/my_velbus/velbus/messages/blind_status.py", line 75, in populate
self.channel = self.byte_to_channel(data[0])
File "/home/pi/my_velbus/velbus/message.py", line 132, in byte_to_channel
self.needs_one_channel(channels)
File "/home/pi/my_velbus/velbus/message.py", line 240, in needs_one_channel
self.parser_error("needs exactly one bit set in channel byte")
File "/home/pi/my_velbus/velbus/message.py", line 148, in parser_error
raise velbus.ParserError(self.class.name + " " + message)
velbus.parser.ParserError: BlindStatusMessage needs exactly one bit set in channel byte

Kind regards
NelisG

Hi,

I've executed the scan.py on my pi (and on a x86 linux) and having both the same results.
My VMBGPOD is not getting detected.

Initially I thought that the timings where the problem (since I'm having 53 modules) and my previous problem indicated that the timer in the scan.py is not sufficient.

Out of previous reports on this topic I saw also that the timer was increased from 180sec. to 320 sec.
self.load_timeout = threading.Timer(320, timeout_expired).start()

These are the changes (only for testing that I've did)

• self.load_timeout = threading.Timer(3200, timeout_expired).start() -> Changed to 3200sec
• Exectued callback() in the def module_loaded(): since this one would only call the callback() when all modules are loaded
• Modified some loggings so that I see in the callback what modules are loaded.

If I understand correctly the flow of the python-velbus is that first a 'scan' is done and after this that all the 'scanned' modules are read.

• scan is taking avg. 10sec.
• Reading each modules is taking until the timeout (since the 4xVMBGPOD are never finished), but for reading the 49 modules it's taking avg. 10min

Can you support me in finding why the VMBGPOD are not read fully? Any hints?

scan.log

Hi,

Looks like I have noticed an issue in the Velbus integration of HomeAssistant.
When the temperature is dropping below zero I assume we have somewhere a incorrect translation.
If you look into the logs from the homeassitant you see that the temperatures are around 0°C, where I believe some of them are going below that and so showing the 127°C (where I believe it’s the high bit that is not being used for the - +)

Below is the log file only showing the temperatures (raw is lower in the topic)
2021-12-03 04:56:32 INFO (velbus-process-reader) [velbus] New message: {“name”: “SensorTemperatureMessage”, “priority”: 251, “address”: 15, “rtr”: false, “cur”: 127.875, “min”: 127.5, “max”: 9.0}
2021-12-03 04:56:40 INFO (velbus-process-reader) [velbus] New message: {“name”: “SensorTemperatureMessage”, “priority”: 251, “address”: 15, “rtr”: false, “cur”: 0.0, “min”: 127.5, “max”: 9.0}
2021-12-03 04:56:42 INFO (velbus-process-reader) [velbus] New message: {“name”: “SensorTemperatureMessage”, “priority”: 251, “address”: 42, “rtr”: false, “cur”: 0.0, “min”: 127.4375, “max”: 19.4375}
2021-12-03 04:56:47 INFO (velbus-process-reader) [velbus] New message: {“name”: “SensorTemperatureMessage”, “priority”: 251, “address”: 15, “rtr”: false, “cur”: 127.9375, “min”: 127.5, “max”: 9.0}
2021-12-03 04:56:59 INFO (velbus-process-reader) [velbus] New message: {“name”: “SensorTemperatureMessage”, “priority”: 251, “address”: 23, “rtr”: false, “cur”: 0.8125, “min”: 127.9375, “max”: 9.875}
2021-12-03 04:56:59 INFO (velbus-process-reader) [velbus] New message: {“name”: “SensorTemperatureMessage”, “priority”: 251, “address”: 17, “rtr”: false, “cur”: 127.75, “min”: 127.375, “max”: 20.3125}

Below is the raw data of the log

**2021-12-03 04:56:**47 DEBUG (velbus-process-reader) [velbus] Valid Header Waiting: True(b’\x0f\xfb\x0f\x02\xe5\x00\x00\x04’)
**2021-12-03 04:56:**47 DEBUG (velbus-process-reader) [velbus] Valid Body Waiting: True (b’\x0f\xfb\x0f\x02\xe5\x00\x00\x04’)
**2021-12-03 04:56:**47 DEBUG (velbus-process-reader) [velbus] Processing message b’\x0f\xfb\x0f\x02\xe5\x00\x00\x04
**2021-12-03 04:56:**47 WARNING (velbus-process-reader) [velbus] received unrecognized command 229 from module 15 (44)
**2021-12-03 04:56:**47 DEBUG (velbus-process-reader) [velbus] Valid Header Waiting: True(b’\x0f\xfb\x0f\x07\xe6\xff\xe0\xff\x00\x12\x00\n\x04’)
**2021-12-03 04:56:**47 DEBUG (velbus-process-reader) [velbus] Valid Body Waiting: True (b’\x0f\xfb\x0f\x07\xe6\xff\xe0\xff\x00\x12\x00\n\x04’)
**2021-12-03 04:56:**47 DEBUG (velbus-process-reader) [velbus] Processing message b’\x0f\xfb\x0f\x07\xe6\xff\xe0\xff\x00\x12\x00\n\x04’
**2021-12-03 04:56:**47 INFO (velbus-process-reader) [velbus] New message: {“name”: “SensorTemperatureMessage”, “priority”: 251, “address”: 15, “rtr”: false, “cur”: 127.9375, “min”: 127.5, “max”: 9.0}
**2021-12-03 04:56:**50 DEBUG (velbus-process-reader) [velbus] Valid Header Waiting: True(b’\x0f\xfb\x0f\x08\xedA\x03\x88\x00\x00\xc1\n[\x04’)
**2021-12-03 04:56:**50 DEBUG (velbus-process-reader) [velbus] Valid Body Waiting: True (b’\x0f\xfb\x0f\x08\xedA\x03\x88\x00\x00\xc1\n[\x04’)
**2021-12-03 04:56:**50 DEBUG (velbus-process-reader) [velbus] Processing message b’\x0f\xfb\x0f\x08\xedA\x03\x88\x00\x00\xc1\n[\x04’
**2021-12-03 04:56:**50 INFO (velbus-process-reader) [velbus] New message: {“name”: “ModuleStatusPirMessage”, “priority”: 251, “address”: 15, “rtr”: false}
**2021-12-03 04:56:**59 DEBUG (velbus-process-reader) [velbus] Valid Header Waiting: True(b’\x0f\xfb\x17\x07\xe6\x01\xa0\xff\xe0\x13\xc0\x9f\x04’)
**2021-12-03 04:56:**59 DEBUG (velbus-process-reader) [velbus] Valid Body Waiting: True (b’\x0f\xfb\x17\x07\xe6\x01\xa0\xff\xe0\x13\xc0\x9f\x04’)
**2021-12-03 04:56:**59 DEBUG (velbus-process-reader) [velbus] Processing message b’\x0f\xfb\x17\x07\xe6\x01\xa0\xff\xe0\x13\xc0\x9f\x04’
**2021-12-03 04:56:**59 INFO (velbus-process-reader) [velbus] New message: {“name”: “SensorTemperatureMessage”, “priority”: 251, “address”: 23, “rtr”: false, “cur”: 0.8125, “min”: 127.9375, “max”: 9.875}
**2021-12-03 04:56:**59 DEBUG (velbus-process-reader) [velbus] Valid Header Waiting: True(b’\x0f\xfb\x11\x07\xe6\xff\x80\xfe\xc0(\xa0\xf3\x04’)
**2021-12-03 04:56:**59 DEBUG (velbus-process-reader) [velbus] Valid Body Waiting: True (b’\x0f\xfb\x11\x07\xe6\xff\x80\xfe\xc0(\xa0\xf3\x04’)
**2021-12-03 04:56:**59 DEBUG (velbus-process-reader) [velbus] Processing message b’\x0f\xfb\x11\x07\xe6\xff\x80\xfe\xc0(\xa0\xf3\x04’
**2021-12-03 04:56:**59 INFO (velbus-process-reader) [velbus] New message: {“name”: “SensorTemperatureMessage”, “priority”: 251, “address”: 17, “rtr”: false, “cur”: 127.75, “min”: 127.375, “max”: 20.3125}

Hi, this weekend I've explored a setup for Home Assistant (v. 0.116.2) and Velbus.
I have a working openHAB + velbus setup, but due to high memory usage problems every few weeks, I wanted to try HA instead.
All my Velbus modules are automatically recognized (thank you community!).
Except for:

• VMB4RF (used for opening/closing of a gate)
• VMB1BLS (used for two blinds next to each other)

Although not in the list of supported modules, the module VMBPIRO is recognized with one channel 9 (outside temperature).

I've no coding experience for these kind of py-scripts. Maybe someone can help with one of these modules? Maybe this is possible for VMB1BLS, because there are already some blind-modules supported.

Thank you for more information.
Kinds regards

• This library supports an integration in Home Assistant.
• The upcoming pip resolver will be more strict in resolving package version conflicts:
  http://pyfound.blogspot.com/2020/03/new-pip-resolver-to-roll-out-this-year.html#what-will-change
• To avoid future issues it would be good if this library would change its pinning to allow any higher version and just set a minimum version.

Thanks for your support of Home Assistant!

VMB1BL is detected in Home Assistant, but does not respond to cover up/stop/down - commands.

HA version 0.96.5

It would be very helpful if you could tag releases as well again. This would enable distributions who want to fetch the source from GitHub instead of PyPI.

Thanks

older modules hvae a shorter module type reponse, so we also need to handle this

Hi,

Installed a while ago HA with the connection to my Velbus system.
Some of the modules where not detected and I had quite some warnings

• Unrecognized commands:
  2021-03-25 07:47:28 WARNING (Thread-8) [velbus] received unrecognized command 0 from module 114
  2021-03-25 07:47:28 WARNING (Thread-8) [velbus] received unrecognized command 245 from module 41
  2021-03-25 07:47:28 WARNING (Thread-8) [velbus] received unrecognized command 184 from module 114
  2021-03-25 07:47:29 WARNING (Thread-8) [velbus] received unrecognized command 229 from module 15 (44)
  2021-03-25 07:47:42 WARNING (Thread-8) [velbus] received unrecognized command 237 from module 41
  2021-03-25 07:47:44 WARNING (Thread-8) [velbus] received unrecognized command 229 from module 15 (44)
  2021-03-25 07:48:00 WARNING (Thread-8) [velbus] received unrecognized command 229 from module 15 (44)
  2021-03-25 07:48:16 WARNING (Thread-8) [velbus] received unrecognized command 229 from module 15 (44)
  2021-03-25 07:48:31 WARNING (Thread-8) [velbus] received unrecognized command 229 from module 15 (44)

• OLED not working

• 2021-03-25 07:13:01 WARNING (Thread-8) [velbus] received unrecognized command 229 from module 15 (44)
  2021-03-25 07:13:12 WARNING (Thread-9) [velbus] Failed to completely load module Hal OLED at address 8 before timeout expired.
  2021-03-25 07:13:12 WARNING (Thread-9) [velbus] Failed to completely load module Living OLED at address 9 before timeout expired.
  2021-03-25 07:13:12 WARNING (Thread-9) [velbus] Failed to completely load module Slpk ouders at address 27 before timeout expired.
  2021-03-25 07:13:12 WARNING (Thread-9) [velbus] Failed to completely load module Keuken OLED at address 41 before timeout expired.
  2021-03-25 07:13:12 WARNING (Thread-9) [velbus] Failed to completely load module VMB4DC at address 114 before timeout expired.
  2021-03-25 07:13:12 WARNING (Thread-9) [velbus] Failed to completely load module VMB4DC at address 116 before timeout expired.
  2021-03-25 07:13:12 WARNING (Thread-8) [velbus] received unrecognized command 254 from module 114
  2021-03-25 07:13:12 WARNING (Thread-8) [velbus] received unrecognized command 184 from module 114

In order to debug what is going wrong I've forked your source repo and executed the scan.py
For this one I'm having an exception after a while (I assume in the callback)

INFO:velbus:Sending message on USB bus: {"name": "ReadDataFromMemoryMessage", "priority": 251, "address": 1, "rtr": false}
INFO:root:Exiting ...
WARNING:velbus:Stop executed
INFO:velbus:Sending message on USB bus: {"name": "ReadDataFromMemoryMessage", "priority": 251, "address": 1, "rtr": false}
Exception in thread write_packets_process:
Traceback (most recent call last):
File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
self.run()
File "/usr/lib/python3.7/threading.py", line 865, in run
self._target(*self._args, **self._kwargs)
File "/home/pi/.local/lib/python3.7/site-packages/velbus/connections/serial.py", line 99, in write_daemon
self._reader.write(message.to_binary())
File "/home/pi/.local/lib/python3.7/site-packages/serial/threaded/init.py", line 219, in write
return self.serial.write(data)
File "/home/pi/.local/lib/python3.7/site-packages/serial/serialposix.py", line 615, in write
raise PortNotOpenError()
serial.serialutil.PortNotOpenError: Attempting to use a port that is not open

Any known issues? I'll also debug a bit further in order to see what the issue could be

Only the first 34 channels (button states) are detected of an VMBGPO with 4 buttons. Channels at sub addresses of the module are not exposed.
I’ll try to get this fixed and do a PR when ready...

VMB2BLE does not respond to stop cover command.

Also, VMB2BLE seems to reset to open after a short delay even when the actual cover is closed. Looks like status of the module is not correctly detected.

The cover down command can be issued in the interface of HA. When given a down command the status temporarily changes to closed and the interface shows a clickable cover up. It is then possible to give a cover up command and this works (but stop cover is also not possible).

Currently the parser only parses one packet on every feed of the parser, this can cause the buffer to grow and not parse all data