service disappears from dbus-spy or paths not updated are not displayed

Question

question

colin-jones asked Apr 19, '22

service disappears from dbus-spy or paths not updated are not displayed

I have a python service reading aurora pv inverter stats from rs232 over tcpip and updating a dbus service which is published via mqtt to home assistant. It has its origins and runs as a service similar to dbusdummyservice.

It is working fine, except for a high level of read failures, timeouts, on the rs232.

At the end of day I detect inverter shutdown by five failing retries on reading the energy produced.
About this time I notice the service disappearing, and reappearing on the dbus-spy display, and when it reappears, it nolonger has most of the paths, just the one/s most recently updated. It seems to be when the GLIB update runs for more than 30 seconds, due to the read timeouts, but I'm not sure about that. I can write to all of the service paths and they reappear so they dont seem to being dropped from the actual dbus object. Purhaps it is a dbus-spy feature.

The data is still available on the mqtt server as it is published with retain, and no update has been pushed invalidating the data.

In testing, run from the console, I can delay the GLIB update for several minutes, and the dbus paths remain intact, until I kill the main process.

Any ideas of what may be happenning?

Thanks in advance,

cerbo gx Venus OS d-bus

2 |3000

Attachments: Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Modifications Space

Node Red Space

Answer 1 · 2022-09-01T06:03:53Z

colin-jones answered · Sep 01, 2022 at 06:03 AM

Just to close the topic in case somebody else trips over it.

Following ideas found in Louis van de Walt's good work https://community.victronenergy.com/questions/76159/victron-venusos-driver-for-serial-connected-bms-av.html, I modified my GLib update function to spawn a thread to do the actual TCP socket read to the serial server connected to the inverter and update the dbus service values. This means the GLib update has only a dozen or so lines of code before returning to the mainloop. I used a non-blocking Lock call to determine if the thread was still active before spawning another so only one thread is ever trying to access the inverter or update the dbus.

All my problems and strange behavior went away.

If only I could reduce the rate of read timeouts getting data from the invert. Maybe time to try a different serial device server.

2 |3000

Attachments: Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

question