gormanb
commented
1 year ago Hi @KameHouseGit - thanks for the suggestion! Unfortunately this approach is not very feasible, because the hub only reports updates to the blinds' position when the movement completes. If we read the position of the blind after issuing the target request and find that it remains unchanged, we can't conclude that the target request didn't reach the blind; it's more likely that the blind is moving to the requested position, but just hasn't completed its motion yet.
The plugin guarantees that targeting requests will be sent to and acknowledged by the hub (or, if there is a communications issue, that the user will be notified via an error message in the logs) but after that it's up to the hub to get the message to the blinds.
First of all thank you for the plugin since it is helping me a lot in my day to day.
I have 4 awnings that I raise or lower at the same time, but on many occasions one of them (randomly) does not go up or down.
I think this is because the Hub sends all the requests at the same time and some awning may encounter radio interference.
As bidirectional communication, it occurs to me that once the order to move an awning is launched, a few seconds later it will be checked if the current position has changed with respect to the one it was before starting the movement. If the position has changed it means that the awning is moving towards its target (it does not have to have reached its target yet). But if after that time the awning continues in its initial position, it is because the order has not been received from the Hub.
I used this solution in an old homemade plugin I made for Insteon home automation, which also had a Hub that converted to non-online signals.