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: https://github.com/victronenergy/venus/issues/1385

[chriadam]

I can't reproduce either bug, using the Motorhome/Boat 1 demo mode. (We don't have a physical temperature sensor device here to test with.)

The mode must be "User & Installer" or higher, otherwise you cannot modify the Type setting at all. But, according to my testing, so long as you are "User & Installer" or higher, all options are visible in the menu, and setting them "works" (i.e. the value stays, and navigating back to Levels page shows that the temperature gauge is scaled properly with appropriate min/max values).

@ReinvdZee maybe you could test this on a system with a real temperature input?

[ReinvdZee]

@chriadam I tested this on a Cerbo GX Mk2 running 3.50 with a physical temp sensor connected.

For access level "User", the setting is locked. For "User & Installer" and higher, all options (total of 7) are available:

I also played around with setting the temp sensor type and switching between roles. Temp sensor role just stays as configured, no problems there. Can also confirm that the gauge limits of the levels page scale with the type.

[chriadam]

Thank you very much for testing and confirming those results, Rein.

@mpvader given that multiple community members report this issue, I wonder if there is some common denominator for the cases where it reproduces (e.g. some specific type of temperature sensor involved, or some third party extension installed perhaps?)

[mpvader]

Hi @chriadam ,

Note that I’ve added a third (possible) bug.

if you don’t have them yet, please order some Ruuvi sensors from the Ruuvi website. (And charge us).

The other type, wired to the Cerbo GX, should be possible to test already yourself?

i don’t understand why one type freezer, fridge, etc) would work different from other types.

for Ruuvis, this is the source of the driver: https://github.com/victronenergy/dbus-ble-sensors

for analog inputs, its https://github.com/victronenergy/dbus-adc.

[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.

https://github.com/user-attachments/assets/c4557ded-eaa3-49cf-9008-eb23635e0e99

[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.

https://github.com/user-attachments/assets/ce68562f-94de-4e40-a925-38648d5415d1

[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 https://github.com/victronenergy/gui-v2/pull/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.