I have an OH3 system with about 300 Items (most KNX) running since ages; everything is fine.
But sporadically when adding new KNX Items they will not be updated by calling the given status GA.
Today again I added a new Thing (simple poweroutlet switch) and it is online.
I added 2 switching channels and they are signaled as online.
I linked an Item per channel but as a result I get only NULL.
I tried with GA: 1.001:1/0/1+<1/2/1 and 1/0/1+<1/2/1 but there is no difference.
I have lots of other switches which immediately show the current state.
Reading the GA via ETS provide the current state but it is not taken by the OH3 Item.
In general the new OH3 switches work and are updated after switching them.
It seems that not all Items states are checked after definition.
Is there any reason / condition which drops checking the state of an Item (e.g. 1/0/1+<1/2/1)?
Please post configurations (if applicable):
Thing code:
Most likely we are talking about communication issue if you say it worked till now. What would help is more information about Knx topology and way you connect to it.
Because you have Knx giving it’s status for each item then the default behavior is that op nhab predicts the next status without taking in consideration you Knx status until the next read. What i do is add autoupdate item metadata to false.
I did’nt say it was working up til now, but for some new Items there is no immediate state update as I expect it because defining a GA with a specific status GA (e.g. 1/0/1+<1/2/1).
For other similar Items it worked perfectly. I defined them and immediately I see the correct Item status.
But as said this is not valid for every new Item I set up.
As I understand the documentation, it is said, that giving an specific status channel this will be queried immediately.
When I’m using the new Item (switch) the status gets updated accordingly.
I’m using an KNX/IP GW in Tunneling mode.
I think there is something hidden which skips retrieving the Item state.
I think there is something hidden which skips retrieving the Item state.
When i add a new thing the binding puts it online right away but my bridge is in router mode so it’s normal that behavior. Now the state get updated when the thing it’s set to read at the interval. Normally you can see in group monitor the read requested with the adress you set.
Now if that is not happening check if the Knx group adresses are passing all the way you to your tunnel on that line or main ip line in router.
Most people use dummy devices in the group adress between line to make them available. So maybe more information on that side.
Also a restart like mentioned earlier doesn’t hurt after the modification.
Things and their channels get online in my setup right away as you wrote.
In most cases the Items linked to such channels get updated immediately after linking. But this is not happening in all cases. In these exceptions the Item gets updated when someone else (or the Item itself) triggered a change.
This happens for any case of Items (switches, contacts, measurements, …) sporadically.
I also tried to disable / re-enable the corresponding Thing but without any difference.
On the other hand everything works as expected. So the GA’s are passing in all directions and I don’t see any limitation there.
I think there is something weird in the final step of Item linkage. It’s a bad feeling when Items sporadically are not checking the current status. You don’t know whether you made a config error or it is just a skipped verification action.
There is nothing weird both openhab and knx are event driver. That mean if a message is sent on the bus everybody read it no message then no read. Think of it like a conversation.
I full agree to you. But in KNX Binding documentation it is stated
The optional `<` sign tells whether the group address of the datapoint accepts read requests on the KNX bus (it does, if the sign is there).
So my expectation is that when I define a GA as [1.001:]1/0/1+<1/2/1 that a read request will be sent to immediately retieve the Items current status after its definition or after a system restart. This is not happening for all such Items. That’s inconsistent in my view.
No that is why you have to define the read interval. It’s normal that the binding doesn’t read by itself when you add it first. If you really want just open ets group adress monitor and then go to your group adress that you want to be read and just right click it and ask for a read. Or also in ets program your device to send at certain interval the status
Just some, maybe stupid, idea:
Are the Flags set properly in ETS for the communication object linked to the involved group address ?
Sounds like it does not react to a read request or does not publish state changes…
Can you post your ETS config of the problematic objects?
Regards
Thomas
Items never “check current status”, they just lie there waiting to be updated by a binding.
As @stamate_viorel says, openHAB is event driven. To get status when nothing happens, you need the binding to poll the device.
Things showing as offline/online is just about the pathway to the device - are we able to try to send a read or write command? It is not a strict representation of any particular device availability.
OK, as all of you state the same I think I have to believe it.
But for what reason is there an option to declare a GA as explicit readable (<1/2/1)?
If there are no read requests sent this makes no sense at all. If so I think it would be a good idea to mention that in the corresponding documentation or list an example in which case it will be read.
As I understand the documentation, the “<” only means something can be read, not that it is being read.
I still have the impression that your ETS flags are not correct. Please post the config of the relevant linked communication objects as defined in your ETS project.
You are right, “<” is an option but if there is no way to use it it makes no sense but can be confusing.
Here a ETS screen shot of one of the mentioned GA and a corresponding trace via bus monitor. The flags are set correctly and the device reacts with a GroupValueResponse.
Hello Helmut,
I’m running a similar Actor (MDT AMI 0816.01) and cross-checked with my settings.
The switch object has the flags “K” and “S” set. My status object has “K”,“L” and “Ü” set, exactly like yours.
Digging a bit deeper into the expected behaviour I read that the GA marked with “<” is being read at system startup to set an initial state in OH.
So this read might not be performed when setting up a Thing but only when restarting - I agree that my humble mind would also expect that when creating a thing + linking an item the initial status is queried from the knx bus somewhere during that process.
So question is if the status is reflected correctly after you did a restart of OH. My expectation is that it would be fine then.
Just to verify on my system I monitored the bus when disabling and enabling the thing again. In that case I see that the status group addresses (all being linked to an item, just to be complete) are being read.
Does this work for you as well ?
thanks for your investigations. I tried it as well (disable / enable Thing) but I didn’t see any query in ETS Group Monitor.
Sending a Read request from ETS is answered 4 times. In this special case the GA is only set in the Actor but no other KNX device. It is only used in OH3 because it is a fan which shouldn’t be deactivated by hand. Seems there are no Acks sent by OH?!?
Other identical Actors with a GA set in a KNX switch and the Actor are anwered just once.
