Re: Telemetry Info

[Dylan Oliver]

Including even more everyone.

On Fri, Jan 6, 2017 at 9:22 AM, Dylan Oliver <dol...@mozilla.com> wrote:

+ Sensorweb team

Let's include everyone on these types of discussions.

On Fri, Jan 6, 2017 at 9:07 AM, David Bialer <dbi...@mozilla.com> wrote:

Hi Dave,

Hope you are well and enjoying playing with shiny new hardware!

I had a question for you about telemetry data that may/may not be provided by the device as I am writing stories and requirements.  I haven't started yet on Metrics, both for Mozilla and the device owner,but wanted to ask you if you see any need for telemetry information coming from devices that may indicate how well the device is performing.  Like
*  "I'm Alive" ping (which I guess we would know if it is sending data)

* heat of the device (as opposed to temperature)

* any electronic characteristics that may be useful

* any faults or crashes

* time its been up and running

* getting Hardware and Firmware versions or build numbers (may be needed for OTA, depending on how we do that)

* Getting device model/type, processor type

* problems with communications that occurred (communication errors I guess)

* any drift of data (if we can detect that) from the PM2.5 sensor which could indicate it needs to be cleaned.

Just a few things off the top of my head that may be kind of out-of-band from the normal reporting data use cases.  Obviously not all of these are needed, but wondering if you have some thoughts on these.

Thanks,

David

[Dave Hylands]

What do you mean by the "heat" of the device?

If we want to add electrical characteristics we need to add sensors to obtain the data. Did you have something in mind?

We'll need to decide how to deal with crashes. I think that we can stash a few bytes with some key register values into RAM when a hard fault occurs (which I think is the only detectable type of fault) and then when the MCU resets we can persist that to be sent to the server.

Time its up and running should be collectable, and I believe that this can also be determined server side. Since the device has no backup battery, it needs to synchronize time with the server each time it boots. The server can record the last sync time for each device and then subtract that from the latest sample time to determine uptime.

The device doesn't have much memory to store samples, so things like data drift probably need to be determined server side.

Static information, like firmware versions and stuff is definitely needed for OTA.