Ds2401 as reed contact monitor

This topic has probably been addressed multiple times, however, I could not find a solution for my issue:

I have a DS2401 connected to the onewire bus; onewire server works ok.

In my items file it is defined as follows:

Contact W_EG_GM_WZ1 "Fenster [%s]" {onewire="deviceId=01.E50803190000;propertyName=r_id;refreshinterval=2"}

and displayed in the sitemap:

Text item=W_EG_GM_WZ1

If I call the sitemap (in basicui) with no magnet present (switch open -> ds2401 not visible on the bus) the window state is displayed as ‘-’. If I move the magnet towards the reed contact, the state changes to ‘CLOSED’ within seconds (as it should be) without reloading the sitemap in the browser. Removing the magnet triggers a change only after 2-3 minutes to ‘UNDEF’; reloading the page in the browser changes the state to ‘-’ again. What can I do to have the open state indicated without big delay?

Thanks for a hint.


I don’t know OneWire so can’t say why, but for some reason it is setting your Item back to undefined instead of CLOSED.

Have you modified any .items or .rules files in that two to three minutes?

Do you have persistence with restoreOnStartup?

Have you monitored events.log to see the state changes on the Item? Seeing the changes there eliminates refresh or other UI problems causing the delay (i.e. it changes to undefined immediately but takes a couple of minutes for that to show up in the UI).


no to all of your questions.

.items and .rules have not been changed; there is no persistance with an restoreOnStartup strategy and i did not monitor the event.log file. I am just looking to the UI: closed contacts are displayed immediately; open contacts (meaning. the ds2401 dissappears from the onwire bus) is indicated only after about 2 min.


There is so much that goes on and so much that can go wrong between the device and the UI that I cannot recommend strongly enough that you should look at the logs while debugging problems like this. Look at events.log to see your Items changing states and receiving updates. This will tell you when/if Item state changes are taking place that may not be reflected in the UI (e.g. maybe the Items are immediately changing state back to Undefined but its the UI that is taking 3 minutes to update). openhab.log is the file to look for errors. This will tell you if the reason the Items are going back to Undefined is caused by an error or exception in a Rule or the binding.