search

pawlizio / my_velux

Custom component of velux integration for Home Assistant
31 stars 9 forks source link

Cover not updating #7

Closed xtimmy86x closed 1 year ago

xtimmy86x commented 3 years ago

Hi, i've installed your plugin in hassio system i configured the plugin and HA see my 3 velux covers as 3 entity correctly if i command a cover in HA it move in the position but if i command the cover on the original velux touchpanel, the entity in ha doesn't upgrade it's value

sorry for my bad english but i'm italian

WhistleMaster commented 3 years ago

Same here, if I use the remote, entities are not updated in HA.

pawlizio commented 2 years ago

I think this should be fixed now, am I correct?

andrazek commented 2 years ago

Hi guys! Is this somehow related to https://github.com/Julius2342/pyvlx/issues/153 ? I can also operate the motor with "target position" but the current position is lost if I send the command "stop" or if someone uses a remote to move the motor.

Can you point me where it was corrected? Should I fork your code and not from Julius2342 to get the current position to work every time as is the case for other Somfy devices?

pawlizio commented 2 years ago

@andrazek: Your log shows just what the KLF200 House status monitor provides, so called NodeStatePositionChangedNotification. Those does not always provide useful data. Finally we cannot change what KLF200 reports, as Velux provides no support for their API.

For blinds i.e. there is already a workaround to get the correct orientation from KLF by sending a seperate status request via heartbeat (every 60s), see. However this workaround is just for Blinds which are defined as EXTERIOR_VENETIAN_BLIND, ADJUSTABLE_SLUTS_ROLLING_SHUTTER, LOUVER_BLIND, referring to pages 104 and 105 of this specification..

If such a workaround will be implemented for your device, may KLF200 would provide also more useful data, but this needs some adjustments and testing.

andrazek commented 2 years ago

Paul, thanks! That was the most complete answer I ever received. I now have some hopes that the solution may exist, just we need to get there. Those slim io receivers+plug are often used in installations and I think there will be more requests in the future for it to work with KLF200 (unless a new device will be released anytime soon). But we are stuck with the KLF200, which seems to be a good device after all.

So even if the House status monitor provides just current_position="0xF7FF" target="0x1000" current_position_fp1="0xF7FF" current_position_fp2="0xF7FF" current_position_fp3="0xF7FF" current_position_fp4="0xF7FF" we might still get the correct current position, am I right? If I understood correctly, for the EXTERIOR_VENETIAN_BLIND, ADJUSTABLE_SLUTS_ROLLING_SHUTTER, LOUVER_BLIND the solution was implemented to do a separate request which contains something else there instead of the meaningless 0xF7FF value?

As the hex code is not defined in const.py, my workaround was to replace the hex code for eg. LOUVER_BLIND with the code of my device (0x0401). However, the major difference I see between the LOUVER_BLIND and eg. VERTICAL_AWNING is that for the former the position was not updated to the value obtained from the Heartbeat, instead, it stayed at the value that was sent as a TARGET_POSITION. So this difference in behavior has something to do with the way a solution was implemented (so perhaps it should be updated after a periodical heartbeat, but this is not the case). Nevertheless, this is already a much better way than if it would be treated as eg. VERTICAL_AWNING where the current_position is immediately replaced by the "0xF7FF" value (that it's converted to -25 or something like that).

Was the mentioned solution already pulled to the Julius2342 release or should I start looking from your fork?

As I'd like to help here to add another device to work as it should, first maybe would be to check whether in a heartbeat response there is any useful information. How could I possibly do that? Currently, when debug mode logs are enabled, I see a status check response every 5 minutes for all the nodes. But there is no useful information on the node that belongs to the slim IO receiver (all values are 0xF7FF). Is there still a hope? Thanks!

pawlizio commented 2 years ago

@andrazek ..are you using my custom component? If so, please just restart your HA. I've modified the section within heartbeat in order to remove the limit to "Blinds", see. So you can check whether you receive now more usefull information.

andrazek commented 2 years ago

No, I've forked Julius2342 and modified const.py so that my device (0x0401) is treated as LOUVER_BLIND. I've tried to reach you over the HA community forum to speed up the discussion. In the logs, I could see a heartbeat response every minute for my "louver blind". But there's, unfortunately, no meaningful info:

https://pastebin.com/Dm0CyS58

Here is a list of commands that I sent through HA during this logging period:

Is there a way to see the raw output of the KLF200 communication with the Somfy device?

Another option is to find someone else with the Somfy Slim IO receiver to try the same to exclude a possible issue with my receiver... I also tried to manually reset the end limits for the receiver, but it did not help.

pawlizio commented 2 years ago

No, the communication between KLF200 and Somfy devices is part of io-homecontrol protocol, which is encrypted and close.

andrazek commented 2 years ago

I guess there's no useful feedback received from my Somfy slim IO receiver. Dunno why. I thought that the end limits were not set during the installation. Because the receiver controls the linear actuator motor that has its own physical end limits, it is not required to have it set. Nevertheless, I tried to set the limits, yet nothing changed, still, no current position was received by KLF200. I'll wait for someone else to come up with the same issue so we can confirm it's device related.

wltng commented 2 years ago

I'm not sure if I have the same issue, but I see the following: When I use a remote, it takes about 2 minutes between stopping the shutter/awning and receiving the FrameNodeStatePositionChangedNotification. So after changing the position using the remote control it takes about 2 minutes before HA reflects the correct position. However if i use HA to change the position, it is updated as soon as the motion stops. Is this normal behavior? I run my KLF 200 on a separate IoT VLAN, but I also see this when it is connected to the same VLAN as HA. I have type ROLLER_SHUTTER and type VERTICAL_EXTERIOR_AWNING