OH3: why are some items of a Thing updated and others are not?

  • openHABian 3.3.0 on rPi4 with 4GB

I noticed today that a bunch of items are not being updated.

I have a Thing with 61 channels, which are updated every 10 seconds.

While all related items show values, some of these are not being updated.

I can see the values being sent via MQTT by listening to the topics, but the items in OH3 are not updated. This only applies to some, but not all of them.

The channel topics have been copied (not typed); hence, are correct. I copy and paste these into mosquitto_sub.

A channel example looks like this

  - id: ac_source_status
    channelTypeUID: mqtt:number
    label: AC Source Status
    description: ""
      stateTopic: ArgyleCourt/Shed/Modbus/Data/8059

listening to mosquitto results in this:

[2022-12-19 07:35] maxg@x570 ~ $ 
mosquitto_sub -h -t ArgyleCourt/Shed/Modbus/Data/8059 | xargs -d$'\n' -L1 sh -c 'date "+%Y-%m-%d %T.%3N $0"'
2022-12-19 07:54:05.523 0
2022-12-19 07:54:15.588 0
2022-12-19 07:54:25.651 0

… but the event.log does not record the change, nor is the respective item updated.

Changing the item state via karaf works.

2022-12-19 07:53:33.702 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'spm_AC_Source_Voltage' changed from 1.4 to 1.5
2022-12-19 07:56:41.028 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'spm_AC_Source_Status' received command 6
2022-12-19 07:56:41.035 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'spm_AC_Source_Status' predicted to become 6
2022-12-19 07:56:41.052 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'spm_AC_Source_Status' changed from 0 to 6
2022-12-19 07:56:45.001 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'spm_AC_Source_Status' received command 0
2022-12-19 07:56:45.007 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'spm_AC_Source_Status' predicted to become 0
2022-12-19 07:56:45.042 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'spm_AC_Source_Status' changed from 6 to 0
2022-12-19 07:56:54.984 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'spm_AC_Source_Voltage' changed from 1.5 to 1.4

Most of the 61 channels do update their linked items.

To prove a point, I linked a newly created item to the channel.
It does not get updated either.

I am running my OH2 system in parallel, which is identical, and which receives and updates all items of the thing.

To prove a point, I issued the MQTT topic manually:

# [2022-12-19 08:13] maxg@x570 ~ $ 
mosquitto_pub -h -t ArgyleCourt/Shed/Modbus/Data/8059 -m 6

OH2 reacted, OH3 did not.

Any hints on how to troubleshoot this issue would be appreciated. Thanks.

Make sure your systems are signing on to your broker with different IDs, or the broker will not serve both subscriptions properly.

They are…at least I did not specify one in OH3 (hence, randomly generated), while OH2’s id is openhab2.

At the moment OH2 and OH3 each have their own broker. However, I am listening to the broker on the OH3 machine (; OH2 is .50)

Just so we’re clear about what you are looking at

Comment; no change is shown there.
Normally only Item state changes are shown in the events.log
That is to say updates-to-same will not be logged.

I note the example channel is linked to two Items. Have you been editing configs and links? I’d advise a binding (or openHAB) restart to make sure everything is subscribed as expected now.

Understood… (BTW, thanks for looking into this)

I sent updates of 0, 6, and 7 via mosquitto_pub, and saw no change in the channel, item or events.log.

I added the delete_ACSourceStatus to see if this item changes, but it doesn’t. Which tells me the channel does not get updated. MQTT broker is working.

[Excursion: I had an issue yesterday, where I could not link an item to a channel, creating a new item and linking did work. So I deleted the initial item, and recreated it; linked it and it worked.]

OK, I shall restart OH… it is a worry to me, as I did not experience such (and other observed) weird behaviour in OH2.

This time I captured memory and capacities before rebooting.

# [2022-12-19 08:40] openhabian@openhabian ~ $ 
tail -n 20 -f /var/log/openhab/events.log | grep spm_AC_Source_Status
# [2022-12-19 08:49] openhabian@openhabian ~ $ 
               total        used        free      shared  buff/cache   available
Mem:         3982300     1035456      955380        2032     1991464     2811152
Swap:        3145720           0     3145720

# [2022-12-19 08:49] openhabian@openhabian ~ $ 
zramctl --output-all
/dev/zram2       1G 108.3M   23M zstd            4       5257  50.3M      400M    50.5M       0B /opt/zram/zram2
/dev/zram1     750M 233.6M  7.3M zstd            4       1113 114.7M      300M   114.7M       0B /opt/zram/zram1
/dev/zram0       1G     4K   87B lzo-rle         4          0     4K      400M       4K       0B [SWAP]

# [2022-12-19 08:49] openhabian@openhabian ~ $ 
df -h
Filesystem                                Size  Used Avail Use% Mounted on
/dev/root                                  15G  6.4G  7.4G  47% /
devtmpfs                                  1.9G     0  1.9G   0% /dev
tmpfs                                     1.9G     0  1.9G   0% /dev/shm
tmpfs                                     778M  2.0M  776M   1% /run
tmpfs                                     5.0M     0  5.0M   0% /run/lock
/dev/mmcblk0p1                            253M   50M  203M  20% /boot
/dev/zram1                                721M  178M  491M  27% /opt/zram/zram1
overlay1                                  721M  178M  491M  27% /var/lib/openhab/persistence
/dev/zram2                                974M   40M  867M   5% /opt/zram/zram2
overlay2                                  974M   40M  867M   5% /var/log   21T   11T   11T  52% /media/SynologyBackup
tmpfs                                     389M     0  389M   0% /run/user/1000

# [2022-12-19 08:50] openhabian@openhabian ~ $ 

Update: have rebooted OH3; same result… channel not updated.

Now I had it. I unlinked both items, deleted delete_ACSourceStatus, deleted the channel and recreated it… linked the item, and it is not working. Really :hot_face:

Case closed; though I wonder if I could have detected this; e.g. root cause, rather than deleting and recreating stuff.