-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect Current Orientation with Somfy Venetian Blind #44
Comments
BTW I'm using pyvlx 0.2.16 |
Hello dumpfheimer, could you explain how have you added the "tilt position" to HA exactly? |
Hi! You are right. HA currently does not support that. I have built it myself but have not yet tested it (especially the close tilt and open tilt correctness) and am not sure about the contribution guidelines so I did not dare to create a merge request YET. Take a look at my changes here if you want to try it yourself: |
Hi! I tried to investigate the values but I didn't really get smart from them. I wrote a script, that changes the orientation and reads back the response fp3 values. I put them in a CSV maybe somebody gets an idea of what could be going on. |
For tilt position the HA integration has to be adjusted. pyvlx already support that since #33 . For testing you can use my HACS custom component where I already modified HA integration slightly, but not yet as a final solution to create a pull request to velux integration. I didn't modified HASS yet, as the tilt function has two different options in terms of implementation, depending on the blinds. At somfy tahoma there was the possibility to configure blinds as either as (+90°/-90°) blinds or 0-100 %. The difference is in the code. Both covers requires a value between 0 and 100 for the tilt position, but the blinds with (+90°/-90°) are open at 50% and close at either 0% (=+90°) or 100% (=-90°) while the others are open at 0% and closed at 100% (inverted logic as in HA). In order to catch these different types of blinds, for each blind an additional configuration step is necessary to give the user the possibility to set the correct blind type. My exterior venetian blinds are from type (+90°/-90°), so I hard coded them to be open at 50 and close at 100. This is currently implemented at Lines 266 to 281 in 9397bbe
and called from HA via: However if you install custom component you can modify config\custom_components\my_velux\cover.py as follows to manually define the position_percent at which the cover is open/close
My HACS custom component: https://github.com/pawlizio/my_velux |
Hi! I modified the Hass code as posted above: dumpfheimer/core@1f5006d The problem is not setting the orientation - that works fine. The problem is that it seems like the blinds are not sending the correct orientation when sending a status update. Do you have any information on that topic? |
You mean that you set them to 100 %, but they confirm their position at 28%? |
But just for clarification, physically they are at 100%? What is reported if you set them to another value like 25% or 30%? |
Yes, exactly. I intend to e.g. close the blinds with a 45° orientation. The blinds act exactly right and stay in the desired state. But the values reported back in fp3 are random other values that have nothing to do with the current orientation. Furthermore I wrote a script that set the orientation from 0-100 and displayed the responses in binary form. Ignoring the timestamp and checksum I was able to find exact the same responses from varying orientations which lets me believe the blinds do not send the orientation with the status update frame. Or it is hidden very well (within the timestamp for example. Those are not real timestamps) |
Any suggestions what I could try? |
If you can't find any systematic within the feedback I only can suggest to ignore the feedback from the KLF with regards to orientation (fp3 value). In this case you would always have the latest status which you set via home assistant. |
I do have a Somfy connexoon AND the velux klf 200. The Somfy App does show the correct orientation. Should I be able to see the traffic between blind and connexoon on the klf200? Maybe I can identify a new frame. |
Actually all frames which are submitted by KLF200 should be visible as pyvlx debug messages.
|
And frames sent between connexoon and the blind? |
No, I mean if you activate the debug mode you will see all available frames submitted by KLF. But you will not see the whole io-homecontrol communication, only the abstract which is provided by KLF200. |
Okay, too bad. Thank you, though. |
How would I enable debug mode? |
Enable logger for pyvlx at your configuration.yaml as follows:
|
Danke! |
Does anyone have a contact from somfy or velux whom I could ask about this? |
@pawlizio is my assumption correct, that you have venetian blinds too? I am trying to find a workaround for the random values of somfy blinds. My first try would be to ignore the value if the first byte is a position and the second byte is not 0x00 |
@dumpfheimer yes I have exterior venetian blinds. If I set the orientation in HA the KLF always confirm only F7FF, which is defined as target valux, but pyvlx ignore this, because only values between 0 and 100% are accepted. I also don't get values on HA if I change the orientation with my remotes. But I have no random values as feedback or at least I never observed them. |
Hello, I installed yesterday my new KLF200 with latest firmware as well as the Velux HA custom component from pawlizio. First, thanks a lot for the great contribution! Thank you! |
Hi! Nothing new on my side. I set this aside for now even though its annoying me. If more people are having this issue it might be better to ignore the FP3 from the venetian blinds all along and just cache the last set value. This of course should only happen if there are no users that actually get useful feedback on FP3, but I dont know how we could find out if such blinds exist. There must be some kind of way to actually get the current position, because the somfy connexoon does load the right angle if you change it by eg a remote control. But I'm afraid that would be a huge trial and error mess. I wrote Velux and Somfy asking for help but neither even bothered to answer me. |
Hi, In the meantime, I started to work on it. The problem comes from the frame received by the HouseMonitoring function in KLF 200 which is used for example by Home Assistant to update Main Parameter (position) and Functional Parameter (FP3 : orientation). The notification frame received periodically from HouseMonitoring contains correct values for Main Parameter but total abberant values for Functional Parameters (FP1-FP7). In our case, we get for the slats orientation values that are either UNKNOWN, 26% or 73%.... I assume this is a bug in the Velux KLF 200 API and since there is no more support, we have to find another way. |
Glad to test it if you check in your changes. And thank you for figuring this out! |
Hi dumpfheimer, I finished the code implementation. I had to put the GW_STATUS_REQUEST call in the Hearbeat loop because if call when receiving GW_NODE_STATE_POSITION_CHANGED_NTF (House monitoring frame), then the KLF200 send another GW_NODE_STATE_POSITION_CHANGED_NTF frame and we end in an infinite loop. I tested it on my side in Home Assistant and it is working well. It would be great if you could also test it on your side. You will find the code in my repository Nicks/pyvlx (master branch). Thank you! |
sorry, I must have missed an email. |
Okay, I'm not home, but everything seems to be working normally and I am not getting randomly jumping values for tilt when I change the tilt position. So this looks like an improvement already. When I'm back I will test changing the orientation with the remote and see what happens. |
According to the velux api documents there is a "default" value: 0xD300 maybe we can send that, when position is 0 and the blind itself will decied what is best? |
Ok, now I got it and yes this need to be adjusted. The blinds are completely closed if position and orientation is 100%. In pyvlx the current orientation will be transmitted as target orientation if the position is changed. What should be considered in case the target position is set to 100% that also the target orientation should be set to 100% in order to completely close the blinds. This is something I have in mind for a long time, but don't find the time for the implementation. |
@dumpfheimer Same thing in my case, HA set the orientation to 50% and I can see partially the venitian blind from inside. On my side, position 0% is fully closed and 100% is fully open but maybe it depends on the venitian blind or the settings in the custom component. |
In HA is 100% fully open, but 100% in HA is 0 in pyvlx and reverse versa. That's always confusing. |
Yes very confusing. I was always talking about HA UI :-) |
@Nicks57 it looks like D800 is working for me (D300 is not) would you be willing to test if it retracts all the way with your blind? https://github.com/dumpfheimer/pyvlx/tree/position_parameter_fixes |
@dumpfheimer I have no access to the code for now, but why not using the hex value corresponding to 100% orientation in HA UI (i.e. C8 00 or 00 00 which correspond to MAX or MIN parameter)? Then we do not need the DEFAULT parameter. |
I would be fine with that but I thought your blind would be positioned in a way that it shows out of the box 🤔 |
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. |
Ah i misunderstood that... nevermind, I'll just send 0 =)
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. |
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.
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. BTW, are you okay with me having created the PR #109 ? 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 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
The text was updated successfully, but these errors were encountered: