Node Type 0x0401 not handled

[raphaelzaugg]

I am using the KLF200 with several VELUX blinds and a Somfy motor. The Somfy motor is reported as a node with type 4 and subtype 1. But according to this enum (https://github.com/Julius2342/pyvlx/blob/master/pyvlx/const.py#L297) and also the KLF200 API documentation there is no subtype 1 for type 4. As a consequence the pyvlx module throws an exception when reading the nodes from the KLF200:

Traceback (most recent call last):
  File "/usr/lib/python3.11/asyncio/sslproto.py", line 737, in _do_read
    self._do_read__copied()
  File "/usr/lib/python3.11/asyncio/sslproto.py", line 799, in _do_read__copied
    self._app_protocol.data_received(b''.join(data))
  File "/home/raphael/involi/velux/pyvlx/pyvlx/connection.py", line 62, in data_received
    frame = frame_from_raw(raw)
            ^^^^^^^^^^^^^^^^^^^
  File "/home/raphael/involi/velux/pyvlx/pyvlx/api/frame_creation.py", line 55, in frame_from_raw
    frame.from_payload(payload)
  File "/home/raphael/involi/velux/pyvlx/pyvlx/api/frames/frame_get_all_nodes_information.py", line 151, in from_payload
    self.node_type = NodeTypeWithSubtype(payload[69] * 256 + payload[70])
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/enum.py", line 714, in __call__
    return cls.__new__(cls, value)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/enum.py", line 1137, in __new__
    raise ve_exc
ValueError: 1025 is not a valid NodeTypeWithSubtype

The KLF200 is running latest firmware 0.2.0.0.71.0

I don't understand if this is a new subtype that has been added recently but is not yet documented/handled or if the device is somehow reporting a wrong subtype. Any ideas?

[Julius2342]

Do you know if somfy support is more responsive then Velux support? May you reach out to them?

[raphaelzaugg]

I have no experience with somfy or velux support but will give it a try. do you know if these IDs are directly coming from the somfy device or if its something velux internal?

[empi89]

I had the same issue using latest homeassistant on HAOS with Markilux IO homecontrol and KLF200. Temporary fix for me was to change the line in const.py from 0x0400 to 0x0401.

For HAOS with safe mode off you can use this workaround. However, after Home Assistant update the fix is gone. After execution velux module needs a reload.

docker exec homeassistant sed -i 's/HORIZONTAL_AWNING = 0x0400/HORIZONTAL_AWNING = 0x0401/' /usr/local/lib/python3.12/site-packages/pyvlx/const.py

[empi89]

@Julius2342 does it make sense to introduce a new type (e.g. HORIZONTAL_AWNING_SUB) in const.py and add it to https://github.com/Julius2342/pyvlx/blob/0a3a234d96ac795cabfe9855d854015a17a7e066/pyvlx/node_helper.py#L98? could you suggest a fix so I can create a PR for this?

[raphaelzaugg]

I have contacted both Velux and Somfy support for information on the new node type. But both just answered that they do not provide any support on the API. So I would also appreciate if we can go ahead with a PR to add the missing node type.

[Julius2342]

Im fine with adding a new sub-type. (Please add a comment that this is an undocumented node type and velux refused to provide any futher documentation.)

If you do a pull request i will approve and merge.

[empi89]

As long as this is not merged into home assistant dependencies, after installing a new version you could use

docker exec homeassistant sed -i 's/pyvlx==0.2.21/pyvlx==0.2.25/' /usr/src/homeassistant/homeassistant/components/velux/manifest.json
docker exec homeassistant sed -i 's/pyvlx==0.2.21/pyvlx==0.2.25/' /usr/src/homeassistant/requirements_all.txt
docker exec homeassistant sed -i 's/pyvlx==0.2.21/pyvlx==0.2.25/' /usr/src/homeassistant/requirements_test_all.txt

to update to the version containing this fix.

[Julius2342]

getting this into home assistant shouldnt be a big deal, esp as the interface did not change.

[andrazek]

Thank you for the fix—finally! Hopefully, it will be merged soon. Three years ago, I used a quick hardcode workaround to make it work. I set LOUVER_BLIND = 0x0401, though I don't remember the exact reason (perhaps because it resembles pergola blades more). I've been using this setting ever since with my SOMFY 1811584 Pergola Slim receiver io, which reports this unusual and undocumented node type.

[andrazek]

Thanks, everyone, for the efforts to add 0x0401 and bump pyvlx to 0.2.26 in HA. Now I understand why I chose LOUVER_BLIND = 0x0401. I’m not getting the current_position for my SOMFY 1811584 Pergola Slim receiver IO anymore after the update. The value is -24. @raphaelzaugg, @empi89, as I understand, you also have similar IO receivers, right? How is the current_position attribute working in your case? The set_position command works as it should (it moves the blades to the desired position), so maybe my receiver simply doesn’t report back the current_position, despite knowing it. Moreover, the state is always set to “is opening” while the pergola blades are moving, regardless of the direction. Once they reach the desired position, the state changes to “open” and never really to “closed” even if fully closed. Even before the update (when I was using the older pyvlx 0.2.21 with LOUVER_BLIND=0x0401), the current_position attribute didn’t work quite right. It was stored correctly when using only the set_position command, but as soon as I sent a stop command, the position was lost (e.g., set to -24).

[raphaelzaugg]

I just tested with the latest HA version and everything works fine including the position read back

[empi89]

I also had Slim receiver 1811683 where I was getting weird position information (also something like -24). I changed this to a regular KNX actuator to have reliable position information. For the pergola motor itself it is a Markilux/Somfy motor which is integrated and another somfy device for "Schattenplus". Both do work fine including the position information after having this patch accepted now. Thanks for your effort!

[andrazek]

It appears to be a device-related issue. Upon reviewing the DEBUG pyvlx logs again, I noticed they still report 'UNKNOWN' values for all parameters except the target position (when it sends the command). However, if the current position attribute could be set based on the target position, that would work for me since I’m controlling the device exclusively through HA. Would this adjustment be possible without modifying the pyvlx code?

[Julius2342]

Do you have the latest firmware version installed? (I doubt that the same firmware version acts differently in this aspect ...)

[andrazek]

Yes, I upgraded my KLF-200 interface immediately after unboxing. As far as I understand, none of us have a working Somfy Slim Receiver IO with plug. Is it possible to upgrade the FW of the Somfy receiver as well?

[andrazek]

I just tested with the latest HA version and everything works fine including the position read back

Thanks for the feedback. Do you also have a Somfy Slim Receiver IO? I'm not sure what you mean by "Somfy motor." What do you use this motor for? Could it be a combination of the Slim Receiver and a motor, like in my case (pergola blades)? I'd be surprised if Somfy used the same node type for both the motor and the receiver.

@Julius2342 Could it be that the data received from the device is being misinterpreted in this case? Unfortunately, we don’t have support from Somfy/Velux, but before giving up, I want to ensure there’s absolutely nothing that can be done to resolve the issue of reporting unknown values for this node type. @empi89 had the same experiences with it, so I believe the device itself is not faulty. Unfortunately, I cannot test if the position reporting works with cloud-based solutions.