Position.position_percent returns 124 for a non-position raw, surfacing as current_position = -24 after a KLF200 reconnect

[fireto]

Summary

After every KLF200 reconnect, all six of my cover nodes report
current_position = -24 in Home Assistant, and they hold it until the node
next reports a real position — 33 s in one case, nearly 2 h in another.

-24 is the arithmetic signature of a non-position raw reaching
100 - position_percent:

>>> raw = bytes([0xF7, 0xFF])   # Parameter.UNKNOWN_VALUE
>>> int(raw[0] / 2 + 0.5)       # Position.to_percent
124
>>> 100 - 124                   # homeassistant/components/velux/cover.py
-24

to_percent() reads only raw[0], so every raw from 0xF700 to 0xF8FF
maps to 124. All of them are above Parameter.MAX (0xC800), so none of them
is a position.

The other sentinels leak the same way, just less visibly: CURRENT (0xD200)
and TARGET (0xD100) give position_percent = 105, and IGNORE (0xD400)
gives 106.

Environment

• Home Assistant 2026.8.1, which pins pyvlx==0.2.36
• KLF200 gateway, 6 exterior venetian blind nodes (Somfy io), device_class: blind

What I measured

A sweep of 10 days of Home Assistant state history, 2026-08-07 to 2026-08-17:

• 36 out-of-range readings, every one exactly -24
• each one directly follows the entity going unavailable and back, that is, a
  KLF200 reconnect
• all 6 nodes inside the same 100 ms
• 6 reconnects in the window, so 6 x 6 = 36
• no other out-of-range value appears at all

How long the value survives depends only on when something next moves:

reconnect	-24 persisted
2026-08-12 13:09	33 s — a cover moved right afterwards
2026-08-17 08:16	about 1 h 49 min

known was True at the time

homeassistant/components/velux/cover.py already guards both
current_cover_position and is_closed with if not position.known: return None, so on the path I can read this should surface as None, not as -24.

It does not. At the moment -24 was recorded the entity state was open, not
unknown. So is_closed returned False, which means position.known was
True. Since known compares against one single value:

@property
def known(self) -> bool:
    return self.raw != self.from_int(Position.UNKNOWN_VALUE)

the raw must be inside 0xF700–0xF8FF but not exactly 0xF7FF.

I could not identify which path seeds such a raw, and I do not want to guess
in a bug report. Parameter.__init__ routes through from_raw(), which maps
anything above MAX to UNKNOWN_VALUE, and NodeUpdater skips non-concrete
positions through _is_concrete_position(). The Position.position int setter
does not validate, so that is the shape of path I would look at first, but I
have not proven it. I am happy to run a patched build or turn on pyvlx debug
logging and wait for the next reconnect, which happens every few days here.

Why this is worse than an unknown

The value is not only cosmetic. It is a plausible number that compares as
smaller than any real position, so it passes range tests that None would
fail. A Home Assistant automation of mine waited for the blinds to shut with:

{{ state_attr('cover.x','current_position') | int(100) <= 2 }}

-24 satisfies that at once, so the automation carried on while the blinds
were still travelling and set the slat tilt at the wrong moment. With None
the int(100) default would have caught it and the wait would have held.

Suggested direction

Stop position_percent from returning a percentage for a raw that is not a
position, so the value cannot leak whatever path produced the raw. Either raise,
or return None, or widen known to the whole non-concrete range:

@property
def known(self) -> bool:
    return self.to_int(self.raw) <= Parameter.MAX

That last one would make the guard that Home Assistant already has fire for
every non-concrete raw instead of only the exact sentinel.

One caveat on that sketch: CURRENT, TARGET and IGNORE are command
sentinels as well as read values, so widening known may affect code that
sends them. You will know better than I do whether the guard belongs in known
or in position_percent.

[wollew]

My guess is that your KLF/Somfy combination produces unexpected values after a reconnect. If you can provide a debug log from such a cycle that would be helpful. I have one request though: I do like to communicate with humans instead of machines, so please do not let a LLM produce a WoT that I have to read through. If you don't feel comfortable in English, that is fine, just use an LLM to fix your language but don't let it generate all the output.

[fireto]

@wollew I'm terribly sorry. the stupid bot was supposed to help me investigate an issue, but I never realized it raised an Issue.
The fault is in the custom velux component I'm running (pawlizio/my_velux 2.9.23), which reads position_percent without checking known.

[wollew]

🤣️

All good.

[wollew]

I am curious though: what is your reason to use my_velux instead of the core integration? I've trying to get most of the missing features into core over the last year, one major thing that is still not there is speed support, but hopefully we'll have that soon as well (home-assistant/core#176231 is a prerequisite).

[pawlizio]

Hi @wollew, has the core integration a configuration option for cover tilt position? The only reason creating custom component at that time was to set the cover tilt open position to 50, since my covers (exterior venetian blinds) are closed on 0% and 100%. So I created a configuration slider to set the default open/close position.

[wollew]

has the core integration a configuration option for cover tilt position?

It does not! I kind of forgot about this. This is a bit unfortunate because I don't think it will be easy (possible at all?) to get support for this into core.

[wollew]

@pawlizio: so the cover tilt position configuration is something that you'd normally would set exactly once per blind and a use case to regularly change it does not really exist. Do I understand this correctly?

[pawlizio]

Correct, it is a configuration per blind/cover. Actually I have Somfy J4 Motor. Within Tahoma, you can configure blinds with two options, slats with+90°/-90° tilt or with +90°/0°, where 0° is open. This 0° open position on +90°/-90° blinds corresponds to 50% on pyvlx.

[wollew]

Sorry, I have one more question, just to make sure I fully understand the requirements: setting the orientation targets for open/close helps to make the actions cover.open_cover_tilt/close_cover_tilt and the corresponding buttons "do the right thing", but if I configured the open target to be the 50%, I then click "tilt open", the slats will be open but HA still shows them at 50%. Is this all or am I missing an aspect?

[pawlizio]

Yes, percentage remains 50% in HA, the desired action for commands cover.open_cover_tilt/close_cover_tilt is more or less the only aspect of this configuration.