• file:///github/workspace/velbusaio/handler.py#L108
  STR100: Calling format with insecure string. Found in 'format(x, "02x")'.
• file:///github/workspace/velbusaio/handler.py#L115
  STR100: Calling format with insecure string. Found in 'format(x, "02x")'.
• file:///github/workspace/velbusaio/helpers.py#L35
  STR100: Calling format with insecure string. Found in 'format(inp, "02x")'.
• file:///github/workspace/velbusaio/messages/dali_device_settings.py#L39
  TRY100: Ignoring exceptions without either logging or handling is not considered good security practice. Found in 'except Exception: # Unknown subtype or error while decoding; leave as bytes ...'.
• file:///github/workspace/velbusaio/util.py#L9
  AST100: Asserts should only be used in tests. Asserts are typically bypassed in a production environment. Found in 'assert len(data) >= MINIMUM_MESSAGE_SIZE - 2'.
• file:///github/workspace/velbusaio/util.py#L10
  AST100: Asserts should only be used in tests. Asserts are typically bypassed in a production environment. Found in 'assert len(data) <= MAXIMUM_MESSAGE_SIZE - 2'.
• file:///github/workspace/velbusaio/util.py#L38
  AST100: Asserts should only be used in tests. Asserts are typically bypassed in a production environment. Found in 'assert 0 <= idx < 8'.
• file:///github/workspace/velbusaio/util.py#L42
  AST100: Asserts should only be used in tests. Asserts are typically bypassed in a production environment. Found in 'assert 0 <= idx < 8'.
• file:///github/workspace/velbusaio/util.py#L43
  AST100: Asserts should only be used in tests. Asserts are typically bypassed in a production environment. Found in 'assert isinstance(value, bool)'.
• enable warnings as errors in the workflow

Is there a reason why support_position returns False, while you do have an implementation for the set_position method? I was hoping to get set position working from home assistant.

Some entities are not updated in Home Assistant in sync with Velbus for the device VMBELO (not sure if other devices have a similar issue).

For example these 3 entities have different values in Velbus and Home Assistant:

This causes an incosistent response as can be seen on this video:
https://github.com/Cereal2nd/velbus-aio/assets/58039006/182dfb66-57f7-448e-a3f2-3a5953ef85d2

In the most recent docker builds for home assistant the velbus integration fails with the following message:

2021-11-09 12:10:26 WARNING (MainThread) [velbus-packet] UNKNOWN module, you should initialize a full new velbus scan: packet=08:00:00:00:00:00:00, address=246, modules=dict_keys([16, 17, 18, 19, 20, 32, 33, 34, 35, 36, 37, 38, 39, 48, 49])

When I turn it on, the entity turns off again after a few seconds. It does switch the channel physically, but then you can't turn it off anymore unless you switch it on and off quickly. If i switch it on in velbuslink it won't see the state in home assistant.

See video

after #53 the connection to host:port fails

urlparse does not parse this url correctly as there is a sheme missing

Warning message when running HomeAssistant 2024.6.0b4

2024-06-02 15:28:50.509 WARNING (MainThread) [homeassistant.util.loop] Detected blocking call to open inside the event loop by integration 'velbus' at homeassistant/components/velbus/__init__.py, line 74: controller = Velbus( (offender: /usr/local/lib/python3.12/site-packages/velbusaio/handler.py, line 40: with open(), please create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+velbus%22

Hi,

I discovered some behavior of velbus-aio that I would like to change. I'm willing to fix this in a PR, but since the current behavior is technically correct, this isn't a simple bug and needs discussing first. Hence this issue.

A temperature sensor (VMB1TS, VMBGP*) can report its current temperature in two forms:

• A Temperature Sensor Status message, containing the temperature with 1/2°C precision.
• A Temperature Sensor message, containing the temperature with 1/16ºC precision.

Currently, the last received message is used to update the state of the temperature channel.

When graphing the temperature data, this causes "glitches" in the high-precision graph when a low-precision message is received: Note the sudden drop to 19.0°C around 9:30

I'm open to discuss this: Do you consider this current behavior as "as designed", or are you open for "improvements"?

One way to enhance this would be to only use the low-res message when it's more than 1/2°C away from the last high-res message.

If you running a supervisor mode, on every upgrade of hass the cache will be cleaned. So make sure we can overrule the cachedir. This way we can store it in the same folder as hass config. This path will be persistent.

Since the move to this library, button presses are no longer being registered.

Before the update, my logbook shows entries like these:

Those 'Push button' events are not there anymore this week.

Side note: I'm not entirely convinced that these binary_sensor's should be visible (enabled) in HA when a new Velbus installation is added. You typically have a lot of buttons, and only want to act on them in a very limited number of cases. We can easily disable them by default: https://developers.home-assistant.io/docs/entity_registry_disabled_by/#integrations-setting-default-value-of-disabled_by-for-new-entity-registry-entries . This way they stay available for users (if they enable them explicitly), but they stop cluttering the list of entities :-)

It looks like the VMBDALI module doesn't load correctly from cache:

2024-05-22 11:13:06.461 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/velbusaio/protocol.py", line 169, in _process_message
    await self._message_received_callback(msg)
  File "/usr/local/lib/python3.12/site-packages/velbusaio/controller.py", line 61, in _on_message_received
    await self._handler.handle(msg)
  File "/usr/local/lib/python3.12/site-packages/velbusaio/handler.py", line 73, in handle
    await self._handle_module_type(msg)
  File "/usr/local/lib/python3.12/site-packages/velbusaio/handler.py", line 131, in _handle_module_type
    await self._velbus.add_module(
  File "/usr/local/lib/python3.12/site-packages/velbusaio/controller.py", line 96, in add_module
    await self._modules[addr].load()
  File "/usr/local/lib/python3.12/site-packages/velbusaio/module.py", line 778, in load
    await super().load(from_cache)
  File "/usr/local/lib/python3.12/site-packages/velbusaio/module.py", line 562, in load
    self._channels[int(num)]._name = chan["name"]
    ~~~~~~~~~~~~~~^^^^^^^^^^
KeyError: 1

When I clear the cache, it starts up correctly, but a restart keeps waiting for the VMBDALI module, presumably because of the above exception.

I'll try to look into this myself, but I wanted to create this issue already for reference.

Hi,

I noticed that my VMBPIRO (outdoor sensor) is not giving any motion updates to HA, the sensor is not dead as it work in the velbus automations and HA is picking up the Temperature and light sensor updates, but not the Motion.

Kind regards,
Jeroen

My HA now contains a plethora of pretty useless LED-entities.

Since HA 2021.11 it is possible to mark such entities as 'Diagnostic': https://developers.home-assistant.io/blog/2021/10/26/config-entity .

In order to update the Velbus-integration to do this, we need to be able to differentiate between these type of LED's and real light-entities. Can we add an attribute (to Channel? ) to them to mark them as such?

To elaborate: I think we should even consider add entity_registry_enabled_default=False to the Button-entities from Velbus. This prevents them from appearing automatically in the HA entities list, while the user can still enable them manually if desired. The VMBELO and VMBGPOD in my installation have now created over 50 entities each, most of which don't have any value at all.

A small illustration:

Hi,

I noticed that the light sensor value of the VMBPIRC allways remains at 0 in HA.
On the VMBPIRO (outdoor sensor) this value is updated correctly.

Kind regards,
Jeroen

Before diving into the issue, I'd like to thank you for updating the Velbus integration! A faster startup thanks to the caching of the modules will be a nice QoL improvement :-)

However, there seems to be an issue for the moment, which causes all kind of issues (state in HA not properly synced with state of Velbus switches for example):

2021-10-08 11:34:59 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: sensor.velbus, climate.velbus, binary_sensor.velbus, switch.velbus, cover.velbus, light.velbus
2021-10-08 11:35:02 ERROR (MainThread) [homeassistant.components.sensor] Setup of platform velbus is taking longer than 60 seconds. Startup will proceed without waiting any longer.
2021-10-08 11:35:02 ERROR (MainThread) [homeassistant.components.climate] Setup of platform velbus is taking longer than 60 seconds. Startup will proceed without waiting any longer.
2021-10-08 11:35:02 ERROR (MainThread) [homeassistant.components.binary_sensor] Setup of platform velbus is taking longer than 60 seconds. Startup will proceed without waiting any longer.
2021-10-08 11:35:02 ERROR (MainThread) [homeassistant.components.switch] Setup of platform velbus is taking longer than 60 seconds. Startup will proceed without waiting any longer.
2021-10-08 11:35:02 ERROR (MainThread) [homeassistant.components.cover] Setup of platform velbus is taking longer than 60 seconds. Startup will proceed without waiting any longer.
2021-10-08 11:35:02 ERROR (MainThread) [homeassistant.components.light] Setup of platform velbus is taking longer than 60 seconds. Startup will proceed without waiting any longer.
2021-10-08 11:39:05 WARNING (MainThread) [homeassistant.bootstrap] Setup timed out for bootstrap - moving forward
2021-10-08 11:44:32 ERROR (MainThread) [velbus] Not all modules are loaded within a timeout of 600 seconds, continuing with the loaded modules

I've increased the logging in HA, and have attached the output of the velbus module (
velbus_init.log ). Some other interesting lines from homeassistant.core are:

2021-10-08 13:27:44 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=velbus, service=scan>
2021-10-08 13:27:44 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=velbus, service=sync_clock>
2021-10-08 13:27:44 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=velbus, service=set_memo_text>
2021-10-08 13:27:44 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=velbus>
2021-10-08 13:28:49 DEBUG (MainThread) [homeassistant.core] Waited 60 seconds for task: <Task pending name='Task-662' coro=<velbus_connect_task() running at /usr/src/homeassistant/homeassistant/components/velbus/__init__.py:58> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f3153a514c0>()]> cb=[<TaskWakeupMethWrapper object at 0x7f3159a2d880>(), <4 more>, <TaskWakeupMethWrapper object at 0x7f3159a333a0>()]>
2021-10-08 13:29:49 DEBUG (MainThread) [homeassistant.core] Waited 120 seconds for task: <Task pending name='Task-662' coro=<velbus_connect_task() running at /usr/src/homeassistant/homeassistant/components/velbus/__init__.py:58> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f3153a514c0>()]> cb=[<TaskWakeupMethWrapper object at 0x7f3159a2d880>(), <4 more>, <TaskWakeupMethWrapper object at 0x7f3159a333a0>()]>
2021-10-08 13:30:49 DEBUG (MainThread) [homeassistant.core] Waited 180 seconds for task: <Task pending name='Task-662' coro=<velbus_connect_task() running at /usr/src/homeassistant/homeassistant/components/velbus/__init__.py:58> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f3153a514c0>()]> cb=[<TaskWakeupMethWrapper object at 0x7f3159a2d880>(), <4 more>, <TaskWakeupMethWrapper object at 0x7f3159a333a0>()]>
2021-10-08 13:31:49 DEBUG (MainThread) [homeassistant.core] Waited 240 seconds for task: <Task pending name='Task-662' coro=<velbus_connect_task() running at /usr/src/homeassistant/homeassistant/components/velbus/__init__.py:58> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f3153a514c0>()]> cb=[<TaskWakeupMethWrapper object at 0x7f3159a2d880>(), <4 more>, <TaskWakeupMethWrapper object at 0x7f3159a333a0>()]>

I've checked my /config/.storage/.velbuscache folder, and can see some files in there:

_  velbuscache ls -lah
total 80K
drwxr-xr-x    2 root     root        4.0K Oct  8 09:02 .
drwxr-xr-x    4 root     root        4.0K Oct  8 11:39 ..
-rw-r--r--    1 root     root        5.1K Oct  8 11:34 1.p
-rw-r--r--    1 root     root        4.5K Oct  8 11:34 16.p
-rw-r--r--    1 root     root        4.6K Oct  8 11:34 17.p
-rw-r--r--    1 root     root        4.6K Oct  8 11:34 18.p
-rw-r--r--    1 root     root        5.1K Oct  8 11:34 2.p
-rw-r--r--    1 root     root        5.3K Oct  8 09:45 22.p
-rw-r--r--    1 root     root        5.1K Oct  8 11:34 3.p
-rw-r--r--    1 root     root        5.1K Oct  8 11:34 4.p
-rw-r--r--    1 root     root        6.9K Oct  8 11:34 6.p

However, if one file per module is to be expected, a lot of them are missing for the moment:

Please let me know how I can help you to debug the issue.

Hass has some usb discovery components, it would be good if we can add usb discovery to this lib so it can be used in hass

Error during initial startup/scan.

2022-12-06 10:59:59.291 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/velbusaio/protocol.py", line 169, in _process_message
    await self._message_received_callback(msg)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/controller.py", line 55, in _on_message_received
    await self._handler.handle(msg)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/handler.py", line 93, in handle
    msg.populate(priority, address, rtr, data)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/messages/channel_name_part3.py", line 35, in populate
    self.needs_one_channel(channels)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/message.py", line 235, in needs_one_channel
    self.parser_error("needs exactly one bit set in channel byte")
  File "/usr/local/lib/python3.10/site-packages/velbusaio/message.py", line 134, in parser_error
    raise ParserError(self.__class__.__name__ + " " + message)
velbusaio.message.ParserError: ChannelNamePart3Message needs exactly one bit set in channel byte
2022-12-06 10:59:59.385 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/velbusaio/protocol.py", line 169, in _process_message
    await self._message_received_callback(msg)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/controller.py", line 55, in _on_message_received
    await self._handler.handle(msg)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/handler.py", line 93, in handle
    msg.populate(priority, address, rtr, data) 
  File "/usr/local/lib/python3.10/site-packages/velbusaio/messages/channel_name_part3.py", line 35, in populate 
    self.needs_one_channel(channels)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/message.py", line 235, in needs_one_channel 
    self.parser_error("needs exactly one bit set in channel byte")
  File "/usr/local/lib/python3.10/site-packages/velbusaio/message.py", line 134, in parser_error
    raise ParserError(self.__class__.__name__ + " " + message)
velbusaio.message.ParserError: ChannelNamePart3Message needs exactly one bit set in channel byte                                                                                                                            

Using latest release 2022.11.5 of HomeAssistant

Anything else you require?

For Nixpkgs the tag 20212.6.2 causes issues for the update process as the package would be downgraded.

Could you please delete/rename the tag 2022.6.2?

Thanks

we need a way to cleanup the velbus cache dir used in this interface
this way we can create a new service in home-assistant to cleanup the cache

Hi,

Is it possible to support the VMBDALI module introduced through the original repository ?
It is the only thing missing for me at this point to fully use HA for my entire home.
The lights are to be supported as dimmers.
My coding skills are absent, but I would be happy to support through testing vigorously!

a mypy run results in a lot of errors, we should solve all these:

helpers.py:26: error: Incompatible return value type (got "bool", expected "Dict[Any, Any]")
helpers.py:65: error: Need type annotation for "result" (hint: "result: Dict[, ] = ...")
helpers.py:97: error: Argument 1 to "join" has incompatible type "Optional[str]"; expected "Union[str, PathLike[str]]"
command_registry.py:12: error: Need type annotation for "_default_commands" (hint: "_default_commands: Dict[, ] = ...")
command_registry.py:13: error: Need type annotation for "_overrides" (hint: "_overrides: Dict[, ] = ...")
command_registry.py:16: error: Incompatible default for argument "module_name" (default has type "int", argument has type "str")
command_registry.py:30: error: Argument 3 to "_register_override" of "CommandRegistry" has incompatible type "Optional[Any]"; expected "str"
command_registry.py:71: error: Incompatible default for argument "module_type" (default has type "int", argument has type "str")
message.py:42: error: Incompatible types in assignment (expression has type "int", variable has type "None")
message.py:43: error: Incompatible types in assignment (expression has type "int", variable has type "bool")
message.py:69: error: Incompatible types in assignment (expression has type "int", variable has type "None")
message.py:130: error: Incompatible return value type (got "List[int]", expected "str")
handler.py:48: error: Unsupported operand types for & ("str" and "int")
handler.py:49: error: Unsupported operand types for & ("str" and "int")
handler.py:61: error: Incompatible types in assignment (expression has type "ModuleSubTypeMessage", variable has type "ModuleTypeMessage")
handler.py:74: error: Argument 1 to "get_command" of "CommandRegistry" has incompatible type "str"; expected "int"
handler.py:75: error: "None" not callable
handler.py:97: error: Need type annotation for "result" (hint: "result: Dict[, ] = ...")
handler.py:99: error: Incompatible types in assignment (expression has type "str", variable has type "int")
handler.py:147: error: "Message" has no attribute "module_type"
handler.py:149: error: "Message" has no attribute "module_type"
handler.py:154: error: "Message" has no attribute "module_type"
handler.py:156: error: "Message" has no attribute "memory_map_version"
handler.py:157: error: "Message" has no attribute "build_year"
handler.py:158: error: "Message" has no attribute "build_week"
handler.py:159: error: "Message" has no attribute "serial"
handler.py:166: error: "Message" has no attribute "sub_address_1"
handler.py:167: error: "Message" has no attribute "sub_address_2"
handler.py:168: error: "Message" has no attribute "sub_address_3"
handler.py:169: error: "Message" has no attribute "sub_address_4"
handler.py:182: error: Unsupported operand types for & ("str" and "int")
channels.py:169: error: Incompatible return value type (got "int", expected "str")
channels.py:172: error: Incompatible return value type (got "None", expected "str")
channels.py:189: error: "None" not callable
channels.py:195: error: "None" not callable
channels.py:201: error: "None" not callable
channels.py:207: error: "None" not callable
channels.py:261: error: "None" not callable
channels.py:312: error: Incompatible return value type (got "None", expected "str")
channels.py:313: error: Incompatible return value type (got "None", expected "str")
channels.py:316: error: Unsupported left operand type for / ("None")
channels.py:319: error: Incompatible return value type (got "None", expected "str")
channels.py:366: error: "None" not callable
channels.py:377: error: "None" not callable
channels.py:409: error: Incompatible return value type (got "None", expected "int")
channels.py:414: error: Incompatible return value type (got "None", expected "int")
channels.py:478: error: Incompatible return value type (got "None", expected "bool")
channels.py:494: error: "None" not callable
channels.py:503: error: "None" not callable
channels.py:524: error: "None" not callable
channels.py:531: error: "None" not callable
module.py:90: error: Need type annotation for "_name" (hint: "_name: Dict[, ] = ...")
module.py:91: error: Need type annotation for "_sub_address" (hint: "_sub_address: Dict[, ] = ...")
module.py:97: error: Need type annotation for "_channels" (hint: "_channels: Dict[, ] = ...")
module.py:167: error: Incompatible return value type (got "Dict[Any, Any]", expected "str")
module.py:260: error: Argument 1 to "_translate_channel_name" of "Module" has incompatible type "int"; expected "str"
module.py:267: error: Argument 1 to "_translate_channel_name" of "Module" has incompatible type "int"; expected "str"
module.py:276: error: Argument 1 to "_translate_channel_name" of "Module" has incompatible type "int"; expected "str"
module.py:304: error: Argument 1 to "_translate_channel_name" of "Module" has incompatible type "int"; expected "str"
module.py:319: error: Argument 1 to "_translate_channel_name" of "Module" has incompatible type "int"; expected "str"
module.py:324: error: Argument 1 to "_translate_channel_name" of "Module" has incompatible type "int"; expected "str"
module.py:329: error: Argument 1 to "_translate_channel_name" of "Module" has incompatible type "int"; expected "str"
module.py:334: error: Argument 1 to "_translate_channel_name" of "Module" has incompatible type "int"; expected "str"
module.py:358: error: Incompatible return value type (got "Dict[Any, Any]", expected "List[Any]")
module.py:420: error: Incompatible types in assignment (expression has type "str", variable has type "Dict[Any, Any]")
module.py:509: error: Incompatible types in assignment (expression has type "None", variable has type "Dict[Any, Any]")
discovery.py:15: error: Argument 1 of "connection_made" is incompatible with supertype "BaseProtocol"; supertype defines the argument type as "BaseTransport"
discovery.py:15: note: This violates the Liskov substitution principle
discovery.py:15: note: See https://mypy.readthedocs.io/en/stable/common_issues.html#incompatible-overrides
controller.py:11: error: Skipping analyzing "serial": found module but no type hints or library stubs
controller.py:11: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
controller.py:12: error: Skipping analyzing "serial_asyncio": found module but no type hints or library stubs
controller.py:38: error: Need type annotation for "_modules" (hint: "_modules: Dict[, ] = ...")
controller.py:39: error: Need type annotation for "_submodules" (hint: "_submodules: List[] = ...")
controller.py:40: error: Need type annotation for "_send_queue"
controller.py:41: error: Need type annotation for "_tasks" (hint: "_tasks: List[] = ...")
controller.py:65: error: Argument 1 to "Module" has incompatible type "str"; expected "int"
controller.py:66: error: Argument 2 to "Module" has incompatible type "str"; expected "int"
controller.py:85: error: Missing return statement
controller.py:117: error: "None" has no attribute "close"
controller.py:118: error: "None" has no attribute "wait_closed"
controller.py:132: error: Incompatible types in assignment (expression has type "None", variable has type "SSLContext")
controller.py:134: error: Incompatible types in assignment (expression has type "StreamReader", variable has type "None")
controller.py:134: error: Incompatible types in assignment (expression has type "StreamWriter", variable has type "None")
controller.py:217: error: "None" has no attribute "write"
controller.py:228: error: "None" has no attribute "read"

Hi,

Not sure if it's relavant for this group, but do you have some documentation how to replace the python-velbus in HA with the velbus-aio?
I'm not sure how the python-velbus or velbus-aio is bound to the HA (core-2021.9.7)

Discovery.py is just an example on how the signum can be discoverd, rework this object so we can add it to the hass discovery system.

This will make installation in case of a signum plug and play

Hi, after updating to 2024.5.3 my kwh-counter returned ‘unavailable’, for both the kw-sensor as the kWh-counter.
I tried deleting the cache en doing a new fresh scan, but after a reload the status still returned ‘unavailable’. I noticed the module found 2 new sensors: a binary sensor kwh and a virtual button.

Restoring a backup to 2024.5.2 didn’t solve the issue.
Restoring to 2024.1.6 fixed it for me.

Grt

velbusaio/messages/module_status.py
PROGRAM_SELECTION is only updated from Velbus.
It can be set correctly and written to Velbus but the value is not updated to selection made.

Hi,

I've noticed after powerfailure that Velbus clock is reset. I now manually sync the clock via HA.
Although I could write an automation that syncs the clock at boot time it would be beter if the velbus integration notices an offset it automaticaly syncs the clock.
This would fix multiple clock issues at once:

• Daylight saving time
• Clock reset due to power failure or velbus power turn off for any reason
• Clock drift of some modules

How i imagine this would work, since the velbus clock of each module is pushed on the bus every once in a while, the integration could pick up on each of these messages and compare them to it's own linux clock. if the offset is greater than, for example 5 seconds, it could force a clock sync to all or that specific module (don't know if one module sync is possible).

Thanks in advance!

Kind regards,
Jeroen

Hi,

Would it be possible to take a look at this, or can anyone advise if they have one working ?

Mine is detected by I can't do anything with it, buttons don't work and it does not display actual status

Regards
Eamon

Hi,
This week, I updated Home Assistant to the 2021.10.0 version and I found out there was a new version of the velbus integration.
I couldn't find any info in the velbus documentation on Home Assistant on how to proceed when having a setup with the old integration? So I removed the velbus line from configuration.yaml. Do I need to remove the old devices?
In velbuslink I could see velbus-aio going trough all addresses and then it started scanning all modules. But at address 9 it halts. At this address, I have an older VMBLCDWB module.

When I download this project on linux and execute the example script, I get the same behavior. On exit with ctrl+C, I get the following debug information:

velbus.txt

The error message "ModuleTypeMessage needs 4 bytes of data have 3" was also present in the old integration, but it didn't stop velbus from working.

Can this be of any help?

In case we do not find the channel, make sure we catch the key-error and throw a nice error message

found via: home-assistant/core#82857

2022-11-30 19:07:25.025 DEBUG (MainThread) [velbus-protocol] RX: RawMessage(priority=fb, address=71, rtr=False, command=245, data=b'f5 10')
2022-11-30 19:07:25.025 DEBUG (MainThread) [velbus-packet] Received {"name": "ClearLedMessage", "priority": 251, "address": 113, "rtr": false, "data": "", "leds": [5]}
2022-11-30 19:07:25.026 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/velbusaio/protocol.py", line 169, in _process_message
    await self._message_received_callback(msg)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/controller.py", line 55, in _on_message_received
    await self._handler.handle(msg)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/handler.py", line 96, in handle
    await (self._velbus.get_module(msg.address)).on_message(msg)
  File "/usr/local/lib/python3.10/site-packages/velbusaio/module.py", line 394, in on_message
    await self._channels[channel].update({"led_state": "off"})
KeyError: 13

          Hi, I updated today from 2024.1.6 to 2024.6.3. At the initial load of HA everything worked fine. After another restart, I encountered the same issue. Is there some extra info/logs I can provide you to see what's going wrong?

Originally posted by @lodebogaert in #100 (comment)

I just updated to the latest HA version; and now all entities are unavailable.

I’ve checked the logs, and I’m getting the following error a lot:
Restarting Velbus writer due to AttributeError(“‘NoneType’ object has no attribute ‘is_closing’”)

Never seen that one before.

My Velbus set-up hasn’t changed, just updated to latest DietPi version (9.5.1) and latest HA (2024.7.1)

I let it sit for the day (because I was at work); was now looking at it , and I thought to get some more logging by reloading the velbus integration... Now I do get a successful sync with a lot of devices and it seems to be working again (I didn't reboot or restart HA or anything, just let it sit for the day)...
Not sure why; can't explain it.

I do notice though that not everything is loading, I have a few devices where all entities are unavailable (mostly VMB4RYNO, VMBEL1, VMBEL2, VMBEL4 and VMBELO)

I've created a bug report and added a ZIP file of my logging file:

Unavailable entities on device:

Same Velbus module but other physical device; all is fine there:

home-assistant_2024-07-08T22-29-29.914Z.zip

Let me know if I can help with something to debug or if I can try something to get the unavailable entities online
Thanks!

Velbus covers always have the state "open". When closing a cover, the state changes to "closed" while closing, but it reverts to "open" when the covers are fully closed. The position is correct though between 0 and 100.

I have 5 Velbus "cover" modules of the same type "VMB2BLE", with Velbus build "1935"

You can see the behavior in the following screenshots.

In the code we have 2 types of message object

• old Message
• new RawMessage

we should replace the Message object with the rawMessage object everywhere

I run version 2021.11.5 of Home Assistant and with the VMBELO there is a gap in the sensor list. Where Velbuslink indicates heater, pump and Alarm1 pressed, HA indicates boost and cooler active. The same occurs with the VMBGPO modules.

Hi,

It takes extremely long for Velbus to get 'settled' as it's waiting on some modules

2022-12-06 10:40:27.705 WARNING (MainThread) [velbus] Waiting for module 197
2022-12-06 10:40:27.707 WARNING (MainThread) [velbus] Waiting for module 198
2022-12-06 10:40:27.711 WARNING (MainThread) [velbus] Waiting for module 198
2022-12-06 10:40:27.713 WARNING (MainThread) [velbus] Waiting for module 224
2022-12-06 10:40:27.714 WARNING (MainThread) [velbus] Waiting for module 224
2022-12-06 10:40:42.718 WARNING (MainThread) [velbus] Waiting for module 160
2022-12-06 10:40:42.722 WARNING (MainThread) [velbus] Waiting for module 160
2022-12-06 10:40:42.725 WARNING (MainThread) [velbus] Waiting for module 167
2022-12-06 10:40:42.728 WARNING (MainThread) [velbus] Waiting for module 167
2022-12-06 10:40:42.730 WARNING (MainThread) [velbus] Waiting for module 194
2022-12-06 10:40:42.732 WARNING (MainThread) [velbus] Waiting for module 194
2022-12-06 10:40:42.734 WARNING (MainThread) [velbus] Waiting for module 197
2022-12-06 10:40:42.736 WARNING (MainThread) [velbus] Waiting for module 197
2022-12-06 10:40:42.737 WARNING (MainThread) [velbus] Waiting for module 198
2022-12-06 10:40:42.739 WARNING (MainThread) [velbus] Waiting for module 198

It keeps looping like this for at least 5 minutes. Then the status becomes OK. This has been happening ever since the 2022.11 release of HA.

There's nothing special about these modules, they function OK.

What information do you need to get the correct detail?

Hi,

I notice that the motion updates from my VMBPIRC sensors shown in HA with a delay between 1-10 seconds.
This could be related to the fact that these are low priority messages or something, but I wonder if this would be fixable.
For me to use the sensors in automations in HA this delay is quite severe.

Kind regards,
Jeroen

I have an issue where the sync clock function uses a system time of the velserv tcp server (which in my case is a docker container with the wrong time).
Using velbuslink software (this uses the same TCP server as connection) I can set the correct time from the software.
Could the integration somehow use the timestamp of home assistant in the sync message?

Hi,
The updated VMBGP4PIR-20 new series does not seem to work.

DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a9, rtr=False, command=255, data=b'ff 5f 8a 7b 04 23 48 20') DEBUG:velbus-packet:Received {"name": "ModuleTypeMessage", "priority": 251, "address": 169, "rtr": false, "data": "", "module_type": 95, "led_on": [], "led_slow_blinking": [], "led_fast_blinking": [], "serial": 35451, "memory_map_version": 4, "build_year": 72, "build_week": 32} WARNING:velbus-packet:Module not recognized: 95 DEBUG:velbus-protocol:TX: RawMessage(priority=fb, address=ab, rtr=True, command=None, data=b'') DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a9, rtr=False, command=176, data=b'b0 5f 8a 7b b9 ff ff ff') DEBUG:velbus-packet:Received {"name": "ModuleSubTypeMessage", "priority": 251, "address": 169, "rtr": false, "data": "", "module_type": 95, "sub_address_1": 185, "sub_address_2": 255, "sub_address_3": 255, "sub_address_4": 255, "serial": 35451, "sub_address_offset": 0}

Upstream seems to have added the moduleprototol - Add new edgelit and glasspanel series protocol

The (de)serialization currently uses Pickle. This breaks when upgrading the classes of the stored objects, since the deserializer can't find the newly added fields in the file.

We need a backward compatible deserialization process. This probably means writing a (de)serializer explicitly instead of relying on pickle. (This has an added security advantage; unpickle-ing isn't very safe to do if the source is not trusted)

See also: #69

At initialization or reload the Velbus integration scans every module address followed by getting channel names (equivalent to VelbusLink scan). This causes extensive use of the canBus resulting in some delay in the modules response messages. Because the module scan sequence does not pause for results, the traffic and delay on de canBus increases significant with higher module numbers because multiple modules are trying to send theire response messages at the same time.
Because of the fixed module timeout module configurations are missed.

Suggestion solution: restart (module) timeout when any message received from scanned module and stop timeout when config load complete.

Hi! 👋

I've been working on upgrading Home Assistant to Python 3.10, and noticed this package isn't compatible with Python 3.10.

Python upgrade PR: home-assistant/core#59729

Error from tests:

  File "/__w/core/core/venv/lib/python3.10/site-packages/velbusaio/protocol.py", line 51, in __init__
  self._send_queue = asyncio.Queue(loop=self._loop)
  TypeError: As of 3.10, the *loop* parameter was removed from Queue() since it is no longer necessary

A quick sneak peek/search revealed more cases of passing the loop argument:

https://github.com/Cereal2nd/velbus-aio/search?q=loop

Could this be fixed? 🙏 ❤️

Thanks!

../Frenck

Hi, a new order with Velbus delivered me a newer version of the VMBDALI module : VMBDALI-20
It looks to be the same module albeit with different connecters and apparently a new module_type
Upstream seems to be documented already moduleprotocol

DEBUG:velbus-protocol:TX: RawMessage(priority=fb, address=01, rtr=True, command=None, data=b'')
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=255, data=b'ff 5a 56 a3 01 23 25 20')
DEBUG:velbus-packet:Received {"name": "ModuleTypeMessage", "priority": 251, "address": 1, "rtr": false, "data": "", "module_type": 90, "led_on": [], "led_slow_blinking": [], "led_fast_blinking": [], "serial": 22179, "memory_map_version": 1, "build_year": 37, "build_week": 32}
WARNING:velbus-packet:Module not recognized: 90
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=176, data=b'b0 5a 56 a3 ff ff ff ff')
DEBUG:velbus-packet:Received {"name": "ModuleSubTypeMessage", "priority": 251, "address": 1, "rtr": false, "data": "", "module_type": 90, "sub_address_1": 255, "sub_address_2": 255, "sub_address_3": 255, "sub_address_4": 255, "serial": 22179, "sub_address_offset": 0}
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=167, data=b'a7 5a 56 a3 ff ff ff ff')
DEBUG:velbus-packet:Received {"name": "ModuleSubTypeMessage", "priority": 251, "address": 1, "rtr": false, "data": "", "module_type": 90, "sub_address_1": 255, "sub_address_2": 255, "sub_address_3": 255, "sub_address_4": 255, "serial": 22179, "sub_address_offset": 4}
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=166, data=b'a6 5a 56 a3 ff ff ff ff')
DEBUG:velbus-packet:Received {"name": "ModuleSubTypeMessage", "priority": 251, "address": 1, "rtr": false, "data": "", "module_type": 90, "sub_address_1": 255, "sub_address_2": 255, "sub_address_3": 255, "sub_address_4": 255, "serial": 22179, "sub_address_offset": 8}

My other installation with the 'older' VMBDALI looks like this for reference:

DEBUG:velbus-protocol:TX: RawMessage(priority=fb, address=01, rtr=True, command=None, data=b'')
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c5, rtr=False, command=237, data=b'ed 70 3f c7 00 00 c1 0a')
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=255, data=b'ff 45 1f 6b 02 22 37 00')
DEBUG:velbus-packet:Received {"name": "ModuleTypeMessage", "priority": 251, "address": 1, "rtr": false, "data": "", "module_type": 69, "led_on": [], "led_slow_blinking": [], "led_fast_blinking": [], "serial": 8043, "memory_map_version": 2, "build_year": 55, "build_week": 0}
INFO:velbus:Load NEW module: 69 @ 1
INFO:velbus-module:Load Module
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=176, data=b'b0 45 1f 6b 02 03 04 05')
DEBUG:velbus-packet:Received {"name": "ModuleSubTypeMessage", "priority": 251, "address": 1, "rtr": false, "data": "", "module_type": 69, "sub_address_1": 2, "sub_address_2": 3, "sub_address_3": 4, "sub_address_4": 5, "serial": 8043, "sub_address_offset": 0}
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=167, data=b'a7 45 1f 6b 06 07 08 09')
DEBUG:velbus-packet:Received {"name": "ModuleSubTypeMessage", "priority": 251, "address": 1, "rtr": false, "data": "", "module_type": 69, "sub_address_1": 6, "sub_address_2": 7, "sub_address_3": 8, "sub_address_4": 9, "serial": 8043, "sub_address_offset": 4}
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=166, data=b'a6 45 1f 6b 0a ff ff ff')
DEBUG:velbus-packet:Received {"name": "ModuleSubTypeMessage", "priority": 251, "address": 1, "rtr": false, "data": "", "module_type": 69, "sub_address_1": 10, "sub_address_2": 255, "sub_address_3": 255, "sub_address_4": 255, "serial": 8043, "sub_address_offset": 8}

Let me know if anything else is required.

cfr #32

Analog values ​​from VMB4AN (velbus) are not read correctly in Home assistant. They always remain at a value of zero.
vmb4an.pdf

Thermostat functions no longer working. The thermostat entities are no longer available.

When no address is assigned to the thermostat of a module, an error will be generated on the response (0xE6) of a temperature request (0xE5). This means that the temperature channel (which is channel number 10 in most cases) must always be available.

See https://community.home-assistant.io/t/support-for-velbus-home-automation/7914/342?u=ddg

When sub addresses are missing the cleanup of channels are handled not properly either, see comments here:

@Cereal2nd , I'll look into this myself if thats ok (when I have time) ?