1-Wire refresh time (about 60 1W elements, and good portion of complex RULES)

I think I have problem with refresh time of my 1-Wire things. I have about 25 temperature sensors, and about 30-40 inputs/outputs. Over the time, when my rules grow to today scale, everything was warking fast. Now, after some time, I have quite large delays reading those values (sometimes from 1W state change to action it takes about 5-10s. Maybe standard OH settings are not enough for my system. Is there anything I could trim up?

From physical state change or openhab state change?

Can I suggest tracing the path from sensor to OpenHAB to understand where the time goes?

So much depends on the length and quality of the 1-Wire bus that I’d start there. There are settings to tweak down at the protocol level, mostly around the length of your bus and timing.

What hardware driver are you using? If you are using the ‘owserver’, with a little fiddling, you can directly check what nodes are connected and their status - this would separate owserver from OpenHAB.


For example, after setting up owserver and /etc/owfs.conf on a RaspberryPi with a DS1490F USB hub…

owdir					# N.B. presence is cached
owdir /uncached				# gives immediate readings
owget /81.EFB82F000000/type		# idenfity the part code
owget /28.0B75EE020000/address		# get the FULL address
owget /28.0B75EE020000/temperature	# take a temp reading (not cached)

If the delay is down at the OneWire hardware level, can you break your 1-Wire bus up into separate links, perhaps via separate interfaces or a hub?

You can be sure that my complex 1W infrastructure is not based on only one bus. :wink: I have 4 1W buses. To the first one are connected temperature sensors from all rooms (star structure). To second one are conected temperature sensors on my heatstove and rest of heating system (line structure - they cannot be mixed). Third supports all inputs and outputs (connected “locally”, near my linux server). Fourth for a change is used for “long range” 1W components (distant by several meters). Before i have switched to OpenHAB, all my “inteligent logic” was made by myself (Apache as UI [some html, php, cgi inside], custom 1W daemons, custom bash scripts, Nagios, and losts more). Even then response time was pretty good (despite high server load). As here, on the beginning (except load, here still is low), but in meantime something has changed and I’m looking what. That’s the reason I anticipate the cause in non free thread’s.

Now, on OH I’m using owserver and in my 1W config’s (buses linked inside) are:
cache_size 0
server: timeout_volatile = 60
owfs: timeout_volatile = 60
server: timeout_stable = 1
owfs: timeout_stable = 1
server: timeout_directory = 600
owfs: timeout_directory = 600
server: timeout_presence = 600
owfs: timeout_presence = 600
server: timeout_serial = 10
owfs: timeout_serial = 10
server: timeout_usb = 10
owfs: timeout_usb = 10
server: timeout_network = 10
owfs: timeout_network = 10
server: timeout_server = 20
owfs: timeout_server = 20
server: timeout_ftp = 900
owfs: timeout_ftp = 900

That’s a lot of 1-Wire kit, which further suggests to me that you need to break the issue into parts to understand it. The more custom a solution is, the less tested it it likely to be, sadly.

A few approaches spring to mind:

  • If your custom software stack worked fine, can you integrate it into OpenHAB instead of owserver? I have a few rules which call out to the command line (even remote SSH) to get/ set custom components. Another option could be to use the HTTP binding to get values into OpenHAB, although that might be better suited to polling data collection rather than fast asynchronous events.
  • Have you traced the delays you’re seeing to owserver or the OpenHAB binding please? If it is owserver, does that project have a more specific community to ask?
  • Apologies if this is obvious, but is it possible to run separate instances of owserver on different serial ports to allow specific tuning of the bus timing?

I’ve not had much trouble with owserver myself after giving up on using devices for I/O, and just polling it for DS18B20 temps. Using 1-Wire counters and presence to build a weather station always seemed neat, but the kit was always out of stock!

I’ve decided to escape from my fuzzy, complex and heavy load solution to OpenHAB just to lower server loads and simplify infrastructure.

Calling shell scripts and other “outside commands” (even if I have them ready) is not the solution I want in this case. :wink:

As I said, 1W configuration is based on 4 buses. Each on separate ACTIVE (not PASSIVE) controller build by myself (I had to dig through my diagrams to tell you on which components I based them…). I did… It’s basicly EM-218 USB2UART converter (based on FT-232RL) with ACTIVE RS232-1W converter build on DS2480B (with ESD line protection based on DS9503P). Whole set works great on lines between 1 and 100m.

On Linux each is mapped as static device (I had to do some coding to each device had it’s own static name). On software side, there are 4 one-wire configs, 1 for each controler. Those configs are linked to each other via “server: configuration = </next/config.file>” parameter. So all 4 runs on 1 owserver instance, and after all they work preaty fast. :wink:

My primary target building this whole 1W infrastructure (task fully accomplished) was lowing build costs to extreame minumum, with simultaneous simplicity of solution working on 1 or 2 cables (first 1W components was temperature sesnsors in each room, intergated with PIR alarm system sensors, using free pair of alarm system cables). Whle infrastructure grew with time and now its:

  • about 30 temperature sensors,
  • about 20 inputs,
  • about 20 outputs,
  • few flood sensors (placed under sinks, bath, behind walls in bathrooms where pipes are connected to valves and taps - weak points/possible water leaks) based on temperature senseors,
  • similarly build moisture sensors placed in lawn and garden flowerbeds,
  • and many more…

Back to the topic… The development of my OH configuration is at (lets say) an advanced stage. It takes place at the same time on many levels. - I’m tying to quick reflect built for years logic in the new OH environment. Most of work is done (few detriments to correct) and I’ll have to deal with stabilization process. :wink:

For now, taking into account that server running whole thing is quite powerfull, and fact that my home infrastructure if quite big (mantioned 1W infrastructure, over a dozen CCTV cameras, DVR’s, fully integrated alarm system, water valves, electrical brake circuits, modbus electrical meters, few mqtt devices, MI, Google Home and Chromecast devices, garage doors, gates, wickets, watering system, lights and other devices - it take a lot of logic and rules to run them), I’ve added some aditional threads to OH system. Now I have to monitor situation and times in my system, detect all bottlenecks and hopefully with your help to get rid of them. :wink:

Unfortunately you have not answered my question above. Is the delay between the time of the physical change (i.e. within owfs) and the time OH picks it up (i.e. the channel value is updated) or is it between the time the channel value changes and the time the rule gets executed?

Delay between the time of the physical change (i.e. within owfs) and the time OH picks it up, but I’ll do some aditional tests. I’ll read values at the same time directly from 1W and OH and get back to you with results.

1 Like

Sorry for long no reply from me - other problems and private matters had a higher priority for long time and I had to put aside analysis of this case. Now I’m back with onewire on my openhab config. Problem unfortunately persisted and it’s still quite a nuisance.

So, it looks like I said before. Phisical change (gate opening) it is reflected almost immediately in onewire state change (owread test, and simple cat on OWFS confims that - look for times bellow). Problem is that openhab doesn’t see that change in the same time.

cat:		2021-11-26 22:21:19 CET	1,1,1,1,1,0,1,1
owread:		2021-11-26 22:21:19 CET	1,1,1,1,1,0,1,1
openhab:	2021-11-26 22:21:33.907 [vent.ItemStateChangedEvent] - Stan_bramy_wjazdowej changed from ON to OFF

I would be grateful for further help with the analysis.

PS I have to add, that refresh time in things config for that onewire component is set to 1s.