Document and verify out of date data

[mpvader]

• Test and verify each of below expected behaviours
• Document how this works, probably on the wiki

Expected behaviour:

• the app shows to the user when it can't setup the MQTT connection to the Venus-device, and when it loses the connection.
• the app shows two dashes, --, in case data is not available
• when a device disappears (one of the extra batteries goes away for example); all is fine: either show dashes, or just hide the boxes: to signal the user that something has been disconnected is a different issue; not to be solved here.
• the app shows two dashes, when data becomes stale. Data can become stale in two ways:
  • a service leaves the D-Bus; a NameOwnerChanged signal is sent on D-Bus
  • the service remains, but a value is invalidated, a PropertiesChanged signal is sent on D-Bus, containing DBUS-INVALID.

Note that above item needs to be tested for data retrieved via the .system service; for which in all cases it will be the PropertiesChanged signal thats sent out. And it needs to be tested for data retrieved directly from other services, for example battery data from .battery services (2nd and 3rd battery service).

Signalling to the user, in a notification for example, that a device has been disconnected, is out of scope. Business logic for that needs to made on Venus; which then generates notifications, just like other alarms such as over voltage; and all the HTML5-app needs to do is show those notifications.

[heeboA]

As far as i could test this the MQTT sends null values in the case of the data becoming stale

[mpvader]

A quick summary on how it works in mqtt / html5:

• the html5 app subscribes to paths.
• it does not re-fetch the data every so often;
• also it does not implement timers mark data as being stale; doing so would also not work; since a tank level that never changes will make for a value of which there is never an update; looking stale but being not stale.
• the systemcalc service will never leave the D-Bus. And in case sources of its data leave the d-bus; it will change the source (battery voltage when vebus is still there but .battery service is taken away) and in other cases it will send an D-BUS-INVALID on that path.

Scenario a service is removed from D-Bus:

• when a device is disconnected physically from the system; and the driver removes the service from D-Bus; there is no last PropertiesChanged signal sent on D-Bus. What is happening in that case is that a NameOwnerChanged signal is sent on D-Bus.
• dbus-mqtt; the service that interfaces between mqtt and D-Bus, monitors for this; and publishes None on every topic that it has seen so far for that service.

The best device to test this, is one that is not going through systemcalc. In our use case you can test with a batter. Not the main battery of which data you get through systemcalc ofcourse, but one of the others.