What do you do manually to update each item? I don’t see in the KNX binding code any explicit way to force a fresh read, but there are KNX binding experts lurking here who might know how that is possible, or if there is a feature that could be added for your scenario.
In the KNX programming software (ETS 4) one can select a group address (=item in openhab) and send actively a read (=update value) or write (=set new value) request. In my case I would need same functionality in openhab to actively read the status of the affected items.
Or, just coming into my mind: if I have changed some of this simulation parameters, then have send a “reset” and saving my item-file again, all values are displayed correctly after the reload.
The question is - what happens while all items are newly loaded so that the values are displayed correctly and can I use this functionality anyhow?
Regards
John
It would be great if a KNX expert could join in here, in order to avoid having to resort to tedious workarounds like reloading the items file. As someone who doesn’t know anything about KNX, it would seem more correct that if the value has changed somewhere on the KNX side, it ought to be reported soon thereafter to the KNX binding in openHAB, without the need to force a read or other workarounds. My usefulness in that discussion ends here, I’m afraid! 
There’s no way to request a Bus-Read for KNX yet, so the only way to really “request” is to put the affected items in one .items-File and touch this file in case of Reset.
Another way would be to set an autoRefresh for the DPTs, unfortunatly I didn’t use this feature yet, I don’t know the exact way to configure and it’s not in the wiki yet. Anyhow this would result in periodical read-requests for all affected DPTs.
Thank you anyway. I really appreciate your time and thoughts to help me. 
Since my last posting I was already thinking in the same direction. In another thread we were discussing something similiar.
Maybe this approach can be used for touching the affected items. Will give it a try.
Cool, wasn’t aware that KNX that feature. Do you have any hint where I can get further information?
Thanks & Regards
John
Yes, didn’t find the information in first place, but it is in the wiki:
… knx="[<[(< autoRefresh>)]][< dptId>:]< mainGA>" …
so knx="<(60)1.001:1/2/3" would read from GA1/2/3 every 60 Seconds with DPT 1.001 (I didn’t test this)
But I tested it 
And it’s working for all items except my simulation parameters…strange. Will do some further testing.
Thank you @Udo_Hartmann
It seems an on-demand read request is still not supported. The autoRefresh is not an acceptable solution in many cases.
Is there already an issue for this feature? I couldn’t find one.
Why do you need a read request at all?
I need an up-to-date light value. The value is put on the bus by a sensor every 5 minutes, but at certain times I need an actual value instead of the value of up to 5 minutes ago.
EDIT: ok, just tested in ETS with changing light values, but the value remains the same anyway until the sensor does an update. So this won’t solve my problem.
I’ll leave the story below for whoever is interested 
Why? I’ll explain. It’s quite a story, so bear with me
I have a stairway with 4 presence sensors on 4 floors, which also measure lux. I use the average over those 4 values to determine the Twilight state. Below a certain threshold, say 10 lux, the Twilight switch goes on, and if the average value goes over 10 lux, the switch goes off again. This switch is used to determine whether the lights in the stairway need to go on or not if there is movement (every floor has its own light).
Now the thing is, if it’s dark, and Twilight is set, and there is movement, a light goes on. Now the measured light value at 1 sensor increases, say with 45 lux. Even if the other 3 values are at 0 lux, the average is still above 10, and the Twilight switch goes off, and the light doesn’t turn on anymore if there is movement.
I solved this by decreasing the total light value from all 4 sensors by a certain value for every light that is turned on. So for example with 1 turned on light in total darkness I have the total value 0+0+0+45 lux. 1 light is on, so I decrease with 45 lux, and the total is 0 again. Twilight stays on.
But now there is still a problem: the light values aren’t actual. If a light value update was posted when the light was on, this value will remain on e.g. 45 lux, even after the light is turned off. Since the light is off, there is no compensation, resulting in an average value of more than 10 lux, and the Twilight switch goes off.
I hope I made my problem clear
The next best thing I can do at this point is increase the rate in which the sensor puts light values on the bus, but I don’t like spamming the bus with useless telegrams (most of the time, the values are the same anyway). There is no option in the sensor to withhold a periodic update if the value is the same as the previous. It is possible to send an update if the value changes with a certain absolute amount, for example 25 lux. But the problem here is that lux has a logarithmic scale so in daylight the value changes are much larger than in twilight. The light value may change with hundreds of lux in seconds. So you end up continuously sending light values on the bus, which is even worse.
So in the end, the best solution is an on demand read.
I would suggest not to use the lightness sensor value at all, if the relevant light is switched on, but I guess this would not solve the problem.
Hello,
I’d need a “read value” trigger for KNX group addresses too. The reason is my KNX MDT shutter actor (MDT JAL-0810.02). It sends the position only after the movement has finished. Thus, in openhab the shutter position is only updated at the end of a movement. Direct feedback, e.g. a changing shutter icons during movement is what I want.
Normally the position could be periodically read using:
{ knx="<(1):30/2/101" }
but this would flood the KNX bus.
The actor provides a moving status bit which then can be used to start polling the current position from the shutter.
Some ideas how to achieve that are very welcome.
Marco
This isn’t possible with openHAB. Either read a value periodcally or only at system startup.
Keep in mind that
- While the shutter is moving, you will never get the correct state, but only a expired state
- The UI will not update in time
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.