This isn’t possible with openHAB. Either read a value periodcally or only at system startup.
Keep in mind that
You can simulate the moving with a rule. As long as the shutter moves, increase or decrease the value every n seconds by 10.
Hello Udo,
the actor knows approximately where the shutter is. The actor was “teached” for each window during configuration, so it knows that the kitchen window for example takes about 40 seconds to drive.
We have several windows with different heights.
With your solution I might have to write rules for each type of window and do this kind of calibration again (so i would have the calibration data twice, in the actor and in the rule).
A nice enhancement would be if the time of periodical request could be a variable instead of a constant.
{ knx="<(NUMBER_VARIABLE):30/2/101" }
For now I’ll try your suggestion.
Thanks,
Marco
This is not the way openHAB works. Even the periodically read request is an awful hack and shouldn’t be necessary at all.
However, it would be nice to have the ability to trigger a read request any time (which would also fit for your necessities).
for info, OH2 does include a mechanism to call a refresh from a rule
sendCommand(myItem, RefreshType.REFRESH)
but - only some bindings support this. It wouldn’t even be sensible for everything, like sleeping zwave devices.
Note that this is not exactly a read-on-demand feature. Triggering a refresh would eventually cause an update (or failure) but the rule will not stop and wait for the result. You’d have another rule to trigger from update most likely.
Thought: if you are looking for this feature, you (or the the device designer) are possibly approaching the problem in the wrong way?
I’ll try that out, thanks.
Well normally I’d expect the KNX device to be able to send values on change and not at the end of the motion.
The problem is that I dont have a visual feedback of the shutters on my mobile for example. I dont know of a better approach. Suggestions welcome. Udos hint would be good if the driving time would be the same for all windows
If the actor/actuator is only really guessing the shutter position during movement, based on the time elapsed …
You might as well do the guessing within OpenHAB.
Kick off a short-duration timer that updates the position indicator, and sets up the next short duration. Or something similar based on a cron, say every ten seconds check if any shutters are in motion and update the indicator(s).
I’m assuming you get ‘real’ events at the end of travel so that you can normalise everything.
In fact, even when there is no motion, the reported position is only a guess relying on last position and based on runtime, direction and configured total runtime. It depends on the hardware how deep the corrections are implemented.
First thing naturally is different runtime for up and down, because there is more load when turning up the roller shutter, but there are other factors such as diameter of the axis, which will change for every turn, temperature and so on. The actuator is not able to measure the height but can only guess, unless the actuator is built in the shutter itself (like this one https://www.rademacher.de/antriebe-steuerungen/produkte/rollotube-xline-xlim?productID=24603595)
I really don’t see the point of frequently updated position during motion (ok, looks cool 
)
I have about 20 roller shutters, most of them work fast, so the position will be reported within half a minute, and that’s the period the UI get’s updated anyway.
@Udo, this is it: It looks cool 