Wireless temp (& tank?) sensor issues

[chriadam]

There are a few reports about Ruuvi temperature sensors:

1. After adding a Ruuvi sensor (bluetooth), a reboot is required to make it show up in the device list. (I, Matthijs, have not reproduced it or tried to). Reported here: https://community.victronenergy.com/t/new-venus-os-3-50-ui-issue-adding-bt-sensor-ruvitag/9942/4

2. Temperatures go missing on local GX Touch: https://community.victronenergy.com/t/firmware-3-50-issue-ruvvi-tags-dropping-on-gx-touch-display-but-not-on-remote-console/10225/1.

3. its reported, seen by Matthijs also (while running WASM), that the Bluetooth sensor config menu is sometimes empty. But then reopening it soon, ie 30 minutes, after, it all sensors show up again in that same menu. This could also be a range issue, but from initial investigation in the logs of that system that doesn't seem to be the case. I've asked Dirk-Jan to look into tha side further; meanwhile please check gui-v2 code.

Note that there is also another issue, which has to do with the temperature type selection - but thats not a gui-v2 issue and handled here: victronenergy/venus#1385

[mpvader]

Another Ruuvi bug report: https://community.victronenergy.com/t/firmware-3-50-issue-ruvvi-tags-dropping-on-gx-touch-display-but-not-on-remote-console/10225/1

i’ve added it to the list. (Not sure if this is ruuvi only, also other devices can be lost and come back, but with Ruuvis that is much more common due to wireless)

@chriadam

[chriadam]

@blammit ^ this one looks like the device model isn't handling changes properly.

[mpvader]

An update:

I found the cause of the temperature type configuration issue has been found; its not a gui-v2 issue and will be solved shortly.

But meanwhile there are still other reports. Please look into that @chriadam or @blammit ; and I've asked @dirkjanfaber to look as well as he has god experience with the Ruuvi sensors and has them available.

[nmbath]

Regarding 3, I regularly see this within WASM. A browser refresh brings them back, then after a period of time they disappear and a browser refresh brings them back. See video. On the actual curb display they never disappear.

If any logs would help let me know, also feel free to access my system.

Screen.Recording.2024-11-09.at.08.34.33.mov

[blammit]

Regarding 3, I regularly see this within WASM. A browser refresh brings them back, then after a period of time they disappear and a browser refresh brings them back. See video. On the actual curb display they never disappear.

@nmbath the list in the Bluetooth sensor configs is built by looking under mqtt/ble/0/Devices/<X> on wasm. When the devices disappear, could you check under Settings > Debug > Values and see if there are any values there?

I can have a look on your system too if you can provide access, but if it's difficult to reproduce it might be easier for you to check that.

[nmbath]

@blammit Yes they are listed. See Video. It is easy to reproduce. I have a browser window that is permanently connected. Return after a period of time and they have gone, refresh and they return. I have never timed exactly how long between being there and they disappear.

System is available to you, will message privately the VRM ID.

Screen.Recording.2024-11-12.at.07.44.16.mov

[blammit]

I can reproduce the issue that Mark mentioned in wasm. It seems that the model is losing some of its items for some reason; I need to investigate further.

[blammit]

I think this is what's happening:

1. The Bluetooth sensor list is populated by a VeQItemSortTableModel that is filtered with a FilterOffline flag, so that it only shows 'online' sensors.
2. When the MQTT transport disconnects after some idle period, each VeQItemMqtt object detects the connection state change to VeQItemMqttProducer::Disconnected, and calls produceValue(QVariant(), VeQItem::Offline) to change its state to "offline".
3. At this point, all sensors are removed from the model, due to the FilterOffline flag.
4. When you start using the browser again, the MQTT transport reconnects, but nothing in VeQItemMqtt changes the state back to a non-offline value like VeQItem::Idle, so the items disappear for good until the browser is refreshed.

[blammit]

3. its reported, seen by Matthijs also (while running WASM), that the Bluetooth sensor config menu is sometimes empty. But then reopening it soon, ie 30 minutes, after, it all sensors show up again in that same menu. This could also be a range issue, but from initial investigation in the logs of that system that doesn't seem to be the case. I've asked Dirk-Jan to look into tha side further; meanwhile please check gui-v2 code.

This is a bug in the MQTT producer, and is fixed by #1745. The bug was that the VeQuickItem changed to Offline when disconnected, but never returned back from the Offline state when reconnected.

The first two issues appear to be bugs relating to VeQuickItem on a D-Bus backend. Perhaps the VeQuickItem there is doing something similar where it does not return from an Offline state. @jhofstee is this something you would be familiar with, or know how to debug?

[jhofstee]

@blammit First of all, never going into offline state isn't really a fix, simply removing 'filterFlags: VeQItemSortTableModel.FilterOffline' would fix it as well then. But now disconnected sensors will remain shown, while they shouldn't. I will have a look at the dbus code, but it will require something like, if the child is connected, then the parents must be as well e.g.

[blammit]

The main issue (Bluetooth sensors disappearing) has been resolved. I've created #1791 for the issue Jeroen mentioned where the devices are still shown when disconnected. Closing this one.

[jhofstee]

I checked the dbus implementation, there is no issue there with filtering offline devices and returning later on.