Onewire (using LinkUSB) is working, but openhab can't see devices (or I don't know what to click)

  • Platform information:
    • Hardware: RPi4
    • OS: openhabian openhabian-pi-raspios64-202308121313-gitc6a2fa1-crcaf8d881d.img.xz
    • Java Runtime Environment: 17.0.10+7-1~deb11u1
    • openHAB version: 4.1.1-1
  • Issue of the topic:
    My owsetup apears to work fine but I’m struggling to make any devices appear in openhab. I have quite a lot of owfs experience, but just about none in openhab. I’m not sure if I’m doing it wrong or something is broken.

I have a LinkUSBi USB<->1-wire device plugged in. owserver and ow-shell are installed (3.2p4+dfsg1-4+b1)
I’ve set the device up to use the ftdi interface:
server: link = ftdi:s:0x0403:0x6001:A900fwfb (in /etc/owfs.conf)
owserver is running: ps aux | grep owserver
root 59126 0.0 0.0 172676 4660 ? Ssl Feb08 0:00 /usr/bin/owserver --foreground -c /etc/owfs.conf
I can read sensors from that server from the shell:

$ owdir -s 4304
/28.BA6529020000
/28.737129020000
/01.27A073140000
/bus.0
/uncached
/settings
/system
/statistics
/structure
/simultaneous
/alarm

Same output from ‘owdir -s localhost:4304’ (but not ‘127.0.0.1:4304’ or ‘openhabian:4304’)
This works: ‘owdir -s ::1:4304’ so that means that owserver is binding to the ipv6 loopback address but not the IPv4 one. This may or may not be important…

I can read temps:

owread -s 4304 28.BA6529020000/temperature
       19.25

or owread -s ::1:4304 28.BA6529020000/temperature
or owread -s localhost:4304 28.BA6529020000/temperature

So that looks like it’s all working as it should.
I also have an existing machine that has a load of 1-wire sensors to drive my solar thermal system
I can read that remotely (the host is called ‘control’ and is a Pxa200 balloonboard running ancient debian (‘oabi’) from more than a decade ago):

$ owdir -s control:4304
bus.0
/bus.1
/bus.2
/bus.3
/bus.4
/bus.5
/bus.6
/bus.7
/settings
/system
/statistics
/10.62FC89010800
/10.73288A010800
/28.88FD93112006
/10.E7EE89010800
/28.7AF973010000
/28.959329020000

That system is using i2c to talk to an 8-channel 1-wire multiplex chip (DS2482-800)

So we have two different 1-wire netowrks we can talk to. One local, one remote.

The Onewire bridge binding is installed as a ‘Thing’.
Network Address: localhost
Port: 4304
and if I ‘save’ this it shows Status: OFFLINE (in red), COMMUNICATION_ERROR
but if I configure it for the remote owserver
Network Address: control
Port: 4304
(and save) then is shows Status: ONLINE (in green)

Eventually I worked out that I can get the local one into ‘ONLINE’ state by specifying ‘::1’ instead of localhost. (So why does ‘localhost’ work on the command-line with owdir and owread but not in openhab? Is that a bug?)

The problem is that I cannot work out how to get it to show me the actual devices or their readings. Once it’s working like this shouldn’t there be a list of device-ids that I could add as ‘Items’. What should I click on to get the bus enumerated. Do I have to do that externally myself and manually add the sensors (if so how?)

Also the openhab log is showing:
[WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
4 times/second whether the status is shown as ‘ONLINE’ or ‘OFFLINE’. The log is rapidly becoming huge. Is that message significant?

I’ve tried looking in forum for old questions, but most of them are from 4 or 5 years ago and all talk about the old file-based config from openhab v1 2 or 3. Which doesn’t help much when one is using the UI-based config from openhab 4.

I’ve tried reading OneWire - Bindings | openHAB but again examples are in file-speak, not UI-speak. The file-config looks straightforward - I could put my IDs in there, but I don’t know how to do the equivalent in openhab’s UI.

I still haven’t really got my head around ‘Things’, ‘Items’, ‘Channels’, ‘Locations’ And how those map onto temp sensors.

Suggestions welcome on how to make some temp sensors appear (and get logged, and graphed).

  • Please post configurations (if applicable):
    • Items configuration related to the issue
UID: onewire:owserver:8a7545c675
label: OW Server
thingTypeUID: onewire:owserver
configuration:
  port: 4304
  network-address: control

and

UID: onewire:owserver:8a7545c675
label: OW Server
thingTypeUID: onewire:owserver
configuration:
  port: 4304
  network-address: ::1
  • Services configuration related to the issue
    /etc/owfs/conf
# Sample configuration file for the OWFS suite for Debian GNU/Linux.
#
#
# This is the main OWFS configuration file. You should read the
# owfs.conf(5) manual page in order to understand the options listed
# here.

######################## SOURCES ########################
#
# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = localhost:4304
#
# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
#server: FAKE = DS18S20,DS2405

#Actually installed 2024.02.08
#LinkUSBi USB device access over /dev/ttyUSB0 using ftdi protocol
server: link = ftdi:s:0x0403:0x6001:A900fwfb

# USB device: DS9490
#server: usb = all
#
# Serial port: DS9097
#server: device = /dev/ttyS1
#
# owserver tcp address
#server: server = 192.168.10.1:3131
#
# random simulated device
#server: FAKE = DS18S20,DS2405
#
######################### OWFS ##########################
#
#mountpoint = /mnt/1wire
#allow_other
#
####################### OWHTTPD #########################

OK. After a few more days I’ve made a bit more progress, but I’m finding it way harder to get a simple time-series graph out of this software than I had hoped!

Eventually I worked out that I need a ‘Thing’ for the 1-wire server. a ‘Thing’ for each 1-wire temp sensor. and a ‘Point’ for the temperature value read from that sensor. And then each of these ‘points’ has a ‘Channel Link’ to the Temp sensor (Thing). Is that right?

Everything listed in my ‘Items’ list has ‘NULL’ in the RH column. Is that important/correct?

At no point have I actually seen a temp value on the screen.

I also have rrd4j installed and set as ‘default service’ in ‘settings’->‘persistence’.
The docs talk about setting which items are persited in a config file. “Persistence Strategies are configured in a file named <persistenceservice>.persist, stored in $OPENHAB_CONF/persistence
Do I still need to do this or is there some UI method I should be using now?

When I go to Items → ‘outside temperature’ I see nothing there to specify persistence. The only place is if I go to ‘Model’->‘Outside’->‘outside temperature’, then click on the ‘Channel Link’ to the 1-wire ‘thing’. I get a choice of ‘profiles’. But I only get ‘Default’, ‘Follow’, ‘Offset’, and two sorts of script. Nothing about persistence.

I did previously see ‘update on Change’ in the profile list but it’s gone now. Hoever even where it was there it was greyed-out so I can’t select it. Anyone know why that might be?

Do I have to create a UI page to actually see a read temp somewhere?

I still cannot get any temperature readings. I found a post somewhere showing that if things are working then in the ‘item’ view to the right of each ‘point->measurement->temperature’ the reading is displayed. All my items have ‘NULL’ on the right hand side. So it seems like the temperatures are not actually being read, even though in the ‘Things’ view the connected temp sensors show as ‘online’ (and disconnected ones show as ERROR:COMM, so it is seeing the sensors, just not reading the temps.

Here is a pic:

Is there some way to debug this and work out what is going on? If the binding says ‘online’, how can the point not be reading the temp? Does it need to be told the URL to use when talking to owserver?
(like doing ‘owread -s 4304 /28.616029020000/temperature’, which gets ‘8.5’ right now)
Is it maybe reading it and failing to put it in the persistence database? How do I check?

I’ve been fighting this for 3 weeks now, and am at a bit of a loss.

Can you show the Thing configurations?
How about the debug log of the one-wire binding?

OK. Is there a better way to show config than screenshots? (I’m using the UI-config, so there is nothing but a readme.txt in /etc/openhab/things)
The LinkUSB config:


The outside i-wire temp sensor config:

Where do I find the debug log of the one-wire binding?
/var/log/openhab/openhab.log says:
2024-02-18 02:59:23.896 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
2024-02-18 02:59:23.896 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
2024-02-18 02:59:23.900 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
2024-02-18 02:59:23.904 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
2024-02-18 02:59:23.904 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
2024-02-18 02:59:23.907 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
2024-02-18 02:59:23.908 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
2024-02-18 02:59:23.911 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
2024-02-18 02:59:23.914 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
2024-02-18 02:59:23.918 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed.
Which doesn’t sound good, but my attempts to search the net for this error, and asking about it in another thread on here didn’t really get me any joy. It’s not clear if this warning is actually stopping things working or if it’s harmless. There is 15 MB of that log spitting out several copies of that warning every 5 seconds. It would be nice to stop it even if it’s not causing a problem.

On the Settings page there is a section for Add-on Settings
You can set the log level for each binding from there

Instead of screenshots select the Code tab and copy the contents

Aha. Yes that’s better. Here is the thing (and outside temp item/point) config in code form

UID: onewire:owserver:8a7545c675
label: LinkUSB 1-wire Server
thingTypeUID: onewire:owserver
configuration:
  port: 4304
  network-address: ::1
UID: onewire:basic:8a7545c675:28_616029020000
label: Temperature Sensor (28.616029020000)
thingTypeUID: onewire:basic
configuration:
  refresh: 60
  id: /28.616029020000
bridgeUID: onewire:owserver:8a7545c675
location: outside
channels:
  - id: temperature
    channelTypeUID: onewire:temperature-por-res
    label: Temperature
    description: temperature value of this sensor
    configuration:
      ignorepor: false
      resolution: "10"
label: Outside Temperature
type: Number:Temperature
category: temperature
groupNames:
  - outside
  - Sensors
tags:
  - Temperature
  - Measurement

For the debug. OK found the setting, and now we do indeed have something to go on. Thanks for that pointer.

2024-02-18 03:41:41.653 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHand
ler tried updating the thing status although the handler was already disposed.
2024-02-18 03:41:41.653 [DEBUG] [internal.owserver.OwserverConnection] - Trying to (re)start OW ser
ver connection - previous state: FAILED
2024-02-18 03:41:41.654 [DEBUG] [internal.owserver.OwserverConnection] - could not open owServerCon
nection to openhabian.home.wookware.org:4304: Connection refused
2024-02-18 03:41:41.655 [DEBUG] [internal.owserver.OwserverConnection] - could not open owServerCon
nection to openhabian.home.wookware.org:4304: Connection refused
2024-02-18 03:41:41.656 [DEBUG] [internal.owserver.OwserverConnection] - could not open owServerCon
nection to openhabian.home.wookware.org:4304: Connection refused
2024-02-18 03:41:41.657 [DEBUG] [internal.owserver.OwserverConnection] - could not open owServerCon
nection to openhabian.home.wookware.org:4304: Connection refused
2024-02-18 03:41:41.658 [DEBUG] [internal.owserver.OwserverConnection] - could not open owServerCon
nection to openhabian.home.wookware.org:4304: Connection refused
2024-02-18 03:41:41.658 [DEBUG] [internal.owserver.OwserverConnection] - could not open owServerCon
nection to openhabian.home.wookware.org:4304: Connection refused
2024-02-18 03:41:41.659 [DEBUG] [internal.owserver.OwserverConnection] - OW connection state: set t
o failed as max retries exceeded.
2024-02-18 03:41:41.659 [DEBUG] [ternal.handler.OwserverBridgeHandler] - Updating owserverconnectio
nstate to FAILED
2024-02-18 03:41:41.659 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler OwserverBridgeHand
ler tried updating the thing status although the handler was already disposed.
2024-02-18 03:41:41.807 [DEBUG] [ternal.handler.OwserverBridgeHandler] - onewire:basic:8a7545c675:2
8_BA6529020000 handler missing
2024-02-18 03:41:41.807 [DEBUG] [ternal.handler.OwserverBridgeHandler] - onewire:basic:8a7545c675:2
8_737129020000 handler missing
2024-02-18 03:41:42.808 [DEBUG] [ternal.handler.OwserverBridgeHandler] - onewire:basic:8a7545c675:2
8_BA6529020000 handler missing
2024-02-18 03:41:42.809 [DEBUG] [ternal.handler.OwserverBridgeHandler] - onewire:basic:8a7545c675:2
8_737129020000 handler missing

Over and over.
So that doesn’t look good.

The odd thing is that it’s (trying to) connect to:
openhabian.home.wookware.org:4304
but that’s not what’s configured in the thing. That’s:
::1:4304
Which is sort-of equivalent, but not the same from a networking POV, and on the command line using owdir or owread it matters:
owread -s ::1:4304 28.616029020000/temperature
10.9375
owread -s openhabian.home.wookware.org:4304 28.616029020000/temperature
(no response, return code is 1)
owread -s localhost:4304 28.616029020000/temperature
10.9375

I probably did previously (days ago) set the onewire binding network-address to ‘openhabian’ to see if it worked. But it’s been ‘::1’ for some time now. Could the old setting be ‘leftover’ somehow? Is it also connecting to ::1 but not printing out messages about that because it’s working OK?
Is there some other place to look for where that address is coming from?

I see there is also a ‘trace’ setting. I guess that’s more detail. I’ll give that a go.

Is the OW server on the same machine as Openhab?
If it’s some other server that network address doesn’t seem right

Yes it’s on the same machine. (I do have another on a second machine but that’s not in use yet)

Some experimenting shows that if I change the network-address in the binding (to ‘foobar’) it starts printing debug messges about connections to foorbar:4304 being refused as well.
then if I change it back (to ::1) it’s still complaining about foobar and openhabian.home.wookware.org in the logs, even though the displayed status has changed to ‘ONLINE’ in green.
I as if all previous values of the field are retained and polled, but the working one also is, silently.

And those ‘handler missing’ log lines are about the currently not-connected sensors which I disabled. Not sure why they are still polled when ‘disabled’? If I re-enable them then the ‘handler missing’ complains go away (and the status in the UI goes from ‘UNINITIALISED’ to ‘OFFLINE’.

So the UI seems to show things working as expected, and the errors in the log file are about a config that no longer exists.

Changing to ‘trace’ rather than ‘debug’ log level doesn’t seem to make any difference to how much is logged.

stopping and starting the openhab service seems to have made it forget all those old configs.
Now the log says:
2024-02-18 04:35:20.821 [DEBUG] [internal.owserver.OwserverConnection] - Trying to (re)start OW server connection - previous state: STOPPED
2024-02-18 04:35:20.828 [DEBUG] [ternal.handler.OwserverBridgeHandler] - Updating owserverconnectionstate to OPENED
2024-02-18 04:35:20.833 [DEBUG] [internal.owserver.OwserverConnection] - OW connection state: opened to ::1:4304
2024-02-18 04:35:20.890 [DEBUG] [.internal.handler.OwBaseThingHandler] - configuring sensors for onewire:basic:8a7545c675:28_737129020000
2024-02-18 04:35:20.892 [DEBUG] [.internal.handler.OwBaseThingHandler] - configuring sensors for onewire:basic:8a7545c675:28_BA6529020000
2024-02-18 04:35:20.897 [DEBUG] [.internal.handler.OwBaseThingHandler] - configuring sensors for onewire:basic:8a7545c675:28_616029020000
2024-02-18 04:35:24.807 [DEBUG] [internal.owserver.OwserverConnection] - closed connection
2024-02-18 04:35:24.807 [DEBUG] [ternal.handler.OwserverBridgeHandler] - Updating owserverconnectionstate to CLOSED
2024-02-18 04:35:24.811 [DEBUG] [ternal.handler.OwserverBridgeHandler] - Updating owserverconnectionstate to OPENED
2024-02-18 04:35:24.813 [DEBUG] [internal.owserver.OwserverConnection] - OW connection state: opened to ::1:4304
2024-02-18 04:35:28.158 [DEBUG] [internal.owserver.OwserverConnection] - closed connection
2024-02-18 04:35:28.160 [DEBUG] [ternal.handler.OwserverBridgeHandler] - Updating owserverconnectionstate to CLOSED
(And I’m not getting thousands of “Handler OwserverBridgeHandler tried updating the thing status although the handler was already disposed” messages any more either)

OK. and now the log file has:
2024-02-18 04:38:49.518 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Could not find item ‘outside_temp’ in rrd4j database
2024-02-18 04:38:49.543 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Could not find item ‘outside_temp’ in rrd4j database
2024-02-18 04:38:49.567 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Could not find item ‘outside_temp’ in rrd4j database

This looks like it might actually be relevant.

I got a temperature reading! Only taken 3 weeks.
I’m not quite sure what I did, but I think the secret was adding a channel to the right thing.

So the ‘temperature’ item that is working looks like this:

label: Temperature
type: Number:Temperature
category: ""
groupNames: []
tags:
  - Point
  - Temperature

whilst the temp item I’ve had for ages that hasn’t worked looks like this:

label: Outside Temperature
type: Number:Temperature
category: temperature
groupNames:
  - outside
  - Sensors
tags:
  - Temperature
  - Measurement

I don’t understand why one works and one doesn’t. But recreating all my temp items as ‘points’ from the sensor ‘thing’ listing seems to make them finally start working. I’m still getting complaints that they don’t exist in the rrd4j database:

2024-02-18 06:18:14.151 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Could not find item 'Temperature_Sensor_28737129020000_Temperature' in rrd4j database
2024-02-18 06:18:14.195 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Could not find item 'Temperature_Sensor_28BA6529020000_Temperature' in rrd4j database

The docs (rrd4j - Persistence Services | openHAB) say

The rrd4j persistence services comes with a default persistence strategy which persists every Item on every state change and at least once a minute. Additionally, it restores the last stored value at system startup.

If you want to define a custom behavior, you will need to create a rrd4j.persist file in the persistence configuration folder.

Which seems to suggest it should ‘just work’, so long as I set a default persistence service in settings (which I did). I tried creating an rrd4j.persist file because it wasn’t working, but that doesn’t seem to have helped.

However now that I’m getting temp readings, if I edit that file so it only mentions Temperature* and resave so it gets re-read, the log file tells me stuff is finally working:

2024-02-18 06:27:01.684 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored 'Temperature_Sensor_28616029020000_Temperature' as value '11.0' with timestamp 1708234020 in rrd4j database
2024-02-18 06:27:01.694 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored 'Temperature_Sensor_28BA6529020000_Temperature' as value '17.25' with timestamp 1708234020 in rrd4j database
2024-02-18 06:27:01.705 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored 'Temperature_Sensor_28737129020000_Temperature' as value '17.75' with timestamp 1708234020 in rrd4j database

So I’m perplexed as to what I was doing wrong before, but mainly thinks to Brian showing me the debug log, I’ve now basically got it working.

No doubt I will have more questions soon :slight_smile: