Homie-Statistical-Values

[timpur]

There has been talk if we should implement device stats as a node. The Mian reason (IMHO) is so that the user can add there own device sensor out side of the spec, and these stats would automatically be discoverable.

We could leave the spec as is, recommending the most common stats, but also recommend implentations implent stats as a node if they like.

I'm not sure of the solution, but I like the idea, as I don't want to be adding every possible stat to the convention.... (Over time)

[ThomDietrich]

Hey,
could you please summarize what counts as "device stats" and why we need it? Why is an extension needed?

[davidgraeff]

Any user defined (probably read-only) Property serves as a "statistic value". It probably makes sense to define some "$type"s instead like "battery" etc.

[timpur]

So currently in 3.0 we have a section defined as Device Statistics, this included stats like:

• $stats/signal
• $stats/cputemp
• $stats/freeheap
• ...

The spec, doesn't specify if this is or isnt open to users or implementation to add there own device stat or not. The issue is, if it is locked down then over time will have request to add more and more stats... and if it is open for user or implementation to add there own, then how do we auto discover these dynamic stats? My proposal is to just have a these implemented as a node, which comes with property discoverabilty, with unit and format ect....

[davidgraeff]

We are on the same side here. Statistics should become node/properties. The issue: at the moment the convention doesn't want to specify nodes (that do not start with a $), see Thomas comments. it'd vote for removing the current flawed design and specify those nodes separately as in #101

[timpur]

Sorry @davidgraeff , that as a response to @ThomDietrich request, just to clarify things hopefully for anyone else reading.

[davidgraeff]

To resurrect this old topic: Is everybody d'accord to remove $stats for 4.0 and reintroduce it in a different form (probably via extension?)?

[timpur]

@davidgraeff sounds good, lets come up with an extension

[arjanmels]

I think the arguments to limit the $stats section are sound.
One feature that will also be lost however, is the heartbeat (removal of $stats/interval $stats/uptime).

How will online/offline detection be handled going forward?

[davidgraeff]

How will online/offline detection be handled going forward?

MQTT last will.

[arjanmels]

@davidgraeff Thanks, that is indeed a clean solution.

[EP-u-NW]

With the specification of the stats extension in #171, what further steps need to be taken to close this issue?

[davidgraeff]

@timpur Please reopen if necessary