You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Request] >>> Support for a predicted position when using a wall switch long press and for UP/DOWN scenario command; i.e. like already done for UP/DOWN openHAB command. This would make openHAB blind switches and wall switches behave the same or similiar and the pistion reporting for a long wall switch press more timely/accurate
The position reporting problems detailed below would then be resolved.
For openHAB initiated commands:
UP/DOWN sets a predicted 0%/100% position and blinds move to that position unless interrupted. Interruption by sending STOP/UP/DOWN commands causes the position to updated and movement stopped or changed with new predicted position.
For non openHAB commands e.g. Wall switch, Scenario command:
UP/DOWN command short press of wall switch >>> the blinds move a short distance and the position updated.
UP/DOWN with long press on wall switch or UP/DOWN command from MH202 >>>> equivalent to openHAB UP/DOWN command but without the predicted position update.
For actuators F411/4 set as Automation actuator.
There is STOP time setting. After this time an automatic STOP command is sent causing a position update in openHAB.
However, for timely position reporting this STOP time needs to be close to the actual shutter run time as possible.
The STOP time can only be set in 1 sec increments up to 60 sec. After that there are only 1 min increments with a max of 10 min.
Problem 1. For long blinds with run times of just over a minute value need an actuator auto STOP time setting to the nearest but higher minute; otherwise an automatic STOP is sent before a blind has reached its end position. In this case the blind position is not updated for up to a minute after the blind had reached its end position.
Problem 2. For wireless connected shutter actuators there are no settings to configure. ie no automatic STOP time is sent.
Partial workarounds using scenarios for problem blinds:
Add additional STOP commands in MH202 scenario controller to force blind position update. This can be done several ways. Use a Group command or addressable command .
Group command with address type General sends a STOP to all the blinds but the binding doesn’t update the blind positions. Bug???
Group command with address type Group sends a STOP to actuators in the group and the binding does update the blind positions.
Group for WiFi connected actuators it may not be possible as these have to be in Group 1 and that could already be in use. For these extra STOP commands in the MH202 scenarios could be a work around.
Even with workarounds above still two problems remain for a Long press of a wall switch:
1 For shutter runs just greater than 1. 2, 3 min etc the position is not updated for up to 1 minute later, when the actuator sends its automatic STOP command.
2 For WiFi actuators the position is not updated until the switch is short pressed again and this may not happen.
The text was updated successfully, but these errors were encountered:
[Request] >>> Support for a predicted position when using a wall switch long press and for UP/DOWN scenario command; i.e. like already done for UP/DOWN openHAB command. This would make openHAB blind switches and wall switches behave the same or similiar and the pistion reporting for a long wall switch press more timely/accurate
The position reporting problems detailed below would then be resolved.
For openHAB initiated commands:
UP/DOWN sets a predicted 0%/100% position and blinds move to that position unless interrupted. Interruption by sending STOP/UP/DOWN commands causes the position to updated and movement stopped or changed with new predicted position.
For non openHAB commands e.g. Wall switch, Scenario command:
UP/DOWN command short press of wall switch >>> the blinds move a short distance and the position updated.
UP/DOWN with long press on wall switch or UP/DOWN command from MH202 >>>> equivalent to openHAB UP/DOWN command but without the predicted position update.
For actuators F411/4 set as Automation actuator.
There is STOP time setting. After this time an automatic STOP command is sent causing a position update in openHAB.
However, for timely position reporting this STOP time needs to be close to the actual shutter run time as possible.
The STOP time can only be set in 1 sec increments up to 60 sec. After that there are only 1 min increments with a max of 10 min.
Problem 1. For long blinds with run times of just over a minute value need an actuator auto STOP time setting to the nearest but higher minute; otherwise an automatic STOP is sent before a blind has reached its end position. In this case the blind position is not updated for up to a minute after the blind had reached its end position.
Problem 2. For wireless connected shutter actuators there are no settings to configure. ie no automatic STOP time is sent.
Partial workarounds using scenarios for problem blinds:
Add additional STOP commands in MH202 scenario controller to force blind position update. This can be done several ways. Use a Group command or addressable command .
Group command with address type General sends a STOP to all the blinds but the binding doesn’t update the blind positions. Bug???
Group command with address type Group sends a STOP to actuators in the group and the binding does update the blind positions.
Group for WiFi connected actuators it may not be possible as these have to be in Group 1 and that could already be in use. For these extra STOP commands in the MH202 scenarios could be a work around.
Even with workarounds above still two problems remain for a Long press of a wall switch:
1 For shutter runs just greater than 1. 2, 3 min etc the position is not updated for up to 1 minute later, when the actuator sends its automatic STOP command.
2 For WiFi actuators the position is not updated until the switch is short pressed again and this may not happen.
The text was updated successfully, but these errors were encountered: