Open dumpfheimer opened 4 years ago
It is exactly like your blind i.e. the blind shows out of the box if orientation is different from 100% which is the case when I open the venetian blind because pyvlx use always target orientation as FP3 parameter when setting position. So I think target orientation should be C8 00 or 00 00 when position is 0. To go further, if we would like to make it perfect, every time that the position is changed, pyvlx should read the current orientation and set it as target orientation. For now target orientation is the last orientation set by HA but if one change the orientation in the meantime with the remote control, the target orientation is not updated.
Ah i misunderstood that... nevermind, I'll just send 0 =)
every time that the position is changed, pyvlx should read the current orientation and set it as target orientation
What are you trying to accomplish with that? Seems like a lot of overhead for very little benefit to me.
I agree, not many advantages. This would perfect the harmony between the HA and external control (e.g. remote control).
Do you mean that HA would overwrite the position set by the remote control?
I have to do some tests tonight but let's take an example to illustrate what I understand pyvlx does:
2 things should prevent that:
I just tested it and the behavior is like my thoughts (see previous post). The thing is that target_orientation is only updated when you change the orientation in HA, not when you change the orientation with the remote. But it is used in set_position. It will make more sense to use current orientation.
Are you sure you used this branch? https://github.com/dumpfheimer/pyvlx/tree/position_parameter_fixes
Sorry, I didn't see that you made some changes this afternoon. I tested it again and it works like a charm!
Sorry, should have mentioned that. Thanks for testing! Good to hear it's working 🙌
I'm really confused. I tested my blinds with pyvlx==0.2.19 just now and without any modification they are completely inserted into their storage box when opened the blinds completely, even if the orientation was 50% before.
Interesting. Are you able to change the orientation when position is 0?
@dumpfheimer No, it's not possible when they are inside the box.
Ok, so at least you should not be affected in a negative way by the changes we want to make?
I've been using this modification for more than 20 days now. it still works perfectly and I couldn't find any side effects, mega! Will this PR make it into an official release? What is still to be done?
Hi!
I too have been using it for quite some time now without any issues. I still have 2 concerns:
First of all I dislike this because it is simply not what I need but also this is a change that might affect many other people in an unexpected undesirable way. I have spent dozens of seconds thinking about how to solve this issue but did not come up with a solution yet.
I would propose to take this change out of the PR anyways and make a separate one for that change. That would make me feel much more confident about the PR.
Hi
@dumpfheimer : can you give more details on point 2? Is that a change I implemented? Can't remember....
Regarding this issue, the idea that come to my mind is to adapt the close fonction (and I assume the open fonction) to behave properly in the both cases based on a parameter value. This parameter could be set manually by the user in the configuration.yml file or automatically from the model of the actuator (readable in KLF200). I thing stephanseitz and myself have Somfy Exterior Venetian blind Type 17 and you should have another one.
It seems like I have confused something. The change is in the master branch and has been since 2 years - unless I am blamimg the wrong line of code: https://github.com/Julius2342/pyvlx/blame/9a6d1d8988157e546e6f25bb78ccd2bfffa24f7d/pyvlx/opening_device.py#L268
Not sure why this never was an issue for me. But that definately makes things easier if I am more of an exception than the rule. Also, this more likely affects the "open" function than "close". Hope I'm not missing anything.
BTW, are you okay with me having created the PR https://github.com/Julius2342/pyvlx/pull/109 ? I don't want to make you feel like I am stealing your work.
Also, I would be very interested in how you found out what the issue was and how to work around it.
Ah, one more thing. The changes in the Parameter class. I was receiving strange values from my blind and was able to fix it by not throwing an exception but rather return UNKNOWN for those values. This is a pretty central change that should probably be reviewed by someone more knowledgeable.
I will revert that change and make a seperate PR for that, so we can move on with the blind orientation fix.
ah cool, thank you very much!
Servus!
Yesterday I started migrating my Home Assistant -> Somfy Connexoon to HA -> Velux KFL 200 which worked kind of nicely, but the "tilt position" (=orientation) was missing. So I went ahead and added that to HA.
Setting the orientation works flawlessly, but it always shows strange "current orientation" values. I then set pyvlx to debug and it seems like it is receiving those strange values from the blind. But I was hoping you could confirm that for me.
IF it is the blind, that is sending strange/unhandled signals, would it be possible to use the sent values as current values for this particular blind/product? It did show the right position in the Somfy App. IF it is not the blind. Do you have any idea what those values could mean? I went through the code and came to the conclusion it actually is within the "position range" which - I guess - would mean it would be a pretty inconvenient "special value"
I appreciate any help.
Vielen Dank!
I copied 2 debug logs from when I tried to set the orientation (it did set it correctly)
EXAMPLE 1
EXAMPLE 2