Motionblinds bluetooth "end positions" missing about core HOT 15 CLOSED

Hey there @LennP, @jerrybboy, mind taking a look at this issue as it has been labeled with an integration (motionblinds_ble) you are listed as a code owner for? Thanks!

_{^{(message by CodeOwnersMention)}}

motionblinds_ble documentation
motionblinds_ble source
_{^{(message by IssueLinks)}}

from core.

Hi fevo21!

Thanks for reporting this issue. The error you are seeing is built in to show the user the end positions of the motor have not been set. However, this error should of course not happen when the motor does have end positions.

• How frequent do you encounter this issue?
• Does reconnecting to the motor fix it, or is it only fixed when you connect using the mobile application?

Could you generate debug logs when the problem occurs again? The debug logs show the exact message that was received from the motor which may help figure out why you are receiving this error
https://www.home-assistant.io/docs/configuration/troubleshooting/#enabling-debug-logging

from core.

Thanks for your quick reply! It occurs multiple times a week, so I expect to investigate your questions somewhere in the coming days. I just stopped the debug logging and have attached the file to this post. Earlier this afternoon there as an issue, but now it's rock solid again.

home-assistant_motionblinds_ble_2024-06-18T14-19-54.931Z.log

Just connecting to the motor will not solve the problem, the issue simply does not become apparent because there is no motion command involved. From the logging it shows that the connecting command will retrieve the "end position: UNKNOWN" status, but only leads to an error in HA when a motion command is involved.

EDIT:
Some additional information: The blind is connected via ESP32-POE-ISO (ethernet cable) running ESPHome proxy with the following settings:

esp32_ble_tracker:
scan_parameters:
interval: 1100ms
window: 1100ms
active: true

bluetooth_proxy:
active: true

from core.

Thanks! I found the issue. As you can see the motor sends back a message starting with 12040f02, where the next byte can either be 02 (no end positions) or 0e (it has end positions). However, it turns out you are getting 4e which I did not account for, as in my testing I never got back 4e but only 02 or 0e (that's why it says end positions UNKNOWN).

Do you know what you are doing differently to cause this, as you are saying it does not always happen? I will make sure to fix it, but it would be beneficial to know what the 4 in 4e means

from core.

Great, that all makes sense. I messed around a bit more and it seems I can reproduce the issue. Some further background: my roller blind is not free hanging, it is installed in the ceiling and might experience some slight resistance when opening and closing. Further, there is a window which can block the opening of the blind when it's open (I want to prevent that in HA with a window sensor).

I'm not sure how the position measurement and control of the blind works, but it seems the above can result in a small mismatch between configured end positions and actual end positions. To further confirm this hypothesis I unrolled/opened the blind whilst holding the bottom of the blind still (as if it was blocked) and let it run for just a couple of seconds. In this way the blind unrolls around its own axis. Accordingly I rolled up/closed the blind again via HA controls. At the point the blind stopped, it got into the '4e' state and I was not able to control it anymore via HA.

At this point the Motionblinds app was required to get things moving again. Although the position in the app says zero, I was still able to move de slider slighty further up, which gave a small rotation on the blind. From there on the blinds could be controlled again via HA.

The above was repeated a couple of times. Logging can be found here:

home-assistant_motionblinds_ble_2024-06-18T18-58-02.001Z.log

Looking at the logs I was wondering why the "Tilt" parameter has different values? To my knowledge a roller blind cannot tilt.

from core.

Interesting! So if I understand correctly you consistently get it to report 4e when you add resistance, but when you don’t you get 0e?

Would you be able to share a short video showing the resistance the blind is getting from opening and closing from within the ceiling, and of you holding the bottom of the blind still as you mentioned which results in 4e?

Looking at the logs I was wondering why the "Tilt" parameter has different values? To my knowledge a roller blind cannot tilt.

A roller blind can tilt if it is used as a double roller blind. Essentially, tilting is just moving the blind up and down in small increments. The motor always reports these values but if your blind is not a double roller blind you don’t use them. You can actually configure your roller blind as a double roller blind in home assistant and you will see that tilting moves the blind up and down within a small range.
https://motionblinds.com/products/double-roller/

from core.

Interesting! So if I understand correctly you consistently get it to report 4e when you add resistance, but when you don’t you get 0e?

I cannot relate it directly to resistance, but this could be a factor resulting in some slight positional offset over time. Hence I don't get the error very often. However, I can consistently get it to report 4e when holding the blind during unrolling/closing. Maybe this forces an positional offset.

Would you be able to share a short video showing the resistance the blind is getting from opening and closing from within the ceiling, and of you holding the bottom of the blind still as you mentioned which results in 4e?

Normal operation:
https://github.com/home-assistant/core/assets/96230951/6aeed272-547c-4814-9762-7526689b97bb

Holding the blind to force 4e:
https://github.com/home-assistant/core/assets/96230951/cc4069b9-731e-4dff-a1e3-c1a96ff6d48f

As I explained above. After holding the blind it can be rolled up again via HA, but accordingly 4e occurs. From that point it is required to make a positional change via the motionblinds app. Accordingly the 4e is gone.

Another logfile added matching the situation on the second video. I included some comments in the logfile for explanation.
home-assistant_motionblinds_ble_2024-06-19T10-04-23.545Z.log

from core.

Thanks! I am not sure whether setting the behavior of 4e to be the same as 0e (end positions are set) will fix the problem, or if it requires some extra command to be sent to fix the issue.

I created a version where 4e no longer results in the error. If you know how to get access to your Python instance, then you can use this command to install it:
python -m pip install --force-reinstall --no-cache-dir --no-deps git+https://github.com/LennP/PyPi-MotionBlinds_BLE@test_endpositions_fix

If not no worries, then I will have to test it using a CMD-03 motor and try to reproduce the problem to see if that fixes the problem.

from core.

Great! I installed the package successfully in the HA docker container and will perform some testing tomorrow. Just for my info, will the package be overwritten when I install an update of Home Assistant?

from core.

If you installed it in the Python environment that is used by home assistant it should not overwrite it, as the version is unchanged. However, I am not very familiar with the many different ways of running home assistant, and the corresponding directory structures and locations of the Python environment.

For example, for a dev container I usually use the script/run-in-env.sh file to access the Python environment that is used by home assistant, but for the installation with HA OS I think you need access to the host to install something manually into Python environment.

script/run-in-env.sh python -m pip install --force-reinstall --no-cache-dir --no-deps git+https://github.com/LennP/PyPi-MotionBlinds_BLE@test_endpositions_fix

from core.

I just went into the HA docker container by using the docker exec -it <container name> bash command. I will check if the fix is still there after an update of HA.

Anyway, this morning I tested the updated package and everything is/remains working great now. I blocked the blind multiple times and in the logging the 4e is showing up, but recognized as a valid end position. The controls in HA continue to work as expected and after using an open/close command the 4e is magically transformed into 0e again, like it was the case with the official motionblinds app.

Some logging:
home-assistant_motionblinds_ble_2024-06-21T07-44-12.430Z.log

I will keep on using the fix for a longer period of time, but I expect it won't give issues anymore. Big thanks to your quick response and fix!! Do you want me to test anything else at this point?

from core.

Awesome, good to hear! I have created a new release that fixes the issue and I will create a PR to bump to the new version in home assistant (but I don't think home assistant will overwrite it either way since the version is unchanged).

Thank you too for reporting the issue and providing the necessary logs for me to fix it! Other than the above issue the integration works as expected? There is still an open PR that adds sensors so hopefully that will be approved soon to give even more insights into your blinds!

from core.

Thank you too for reporting the issue and providing the necessary logs for me to fix it! Other than the above issue the integration works as expected? There is still an open PR that adds sensors so hopefully that will be approved soon to give even more insights into your blinds!

Yes it would be great to have the connection state and battery status as mentioned on above pull request!

Further, the position reporting could be improved in my opinion. I would like to have a position sensor which reports the actual or the latest known position. Currently the position is reported as an attribute of the cover entity, but only when the device is connected. I made a sensor which retrieves the position from that attribute and maintains value unless there is a change. This works fine, but there is an issue: the connection window is rather short, so the blinds can still be moving while the connection is dropped. In this case the position attribute will not be updated and remains at initial value.

I would like to limit the amount of update entity calls to preserve battery of the blinds. Therefore it would make more sense to disconnect the blinds after a minimum time (e.g. 15s) or when the blinds are not moving anymore + 5s margin whichever is longer.

Maybe I am missing something or there is a better way, just let me know. If required we can continue more in depth discussion in a separate improvement issue.

from core.

The default disconnect time is currently set to 15 seconds. I have previously worked on an options branch that includes the option to either:

• have a permanent connection to the blind (which would only really be useful for blinds that are wired, since the battery will otherwise be drained pretty fast. Also, in this case the Motionblinds mobile app won't work anymore since the blind only accepts one connection at a time).
• or to change the disconnect time

Feel free to create another issue if you are interested in these features explaining how you would like it to work, then we can discuss it there!

from core.

Done: #120105

from core.