How to include custom sensor data in Eddystone

[lijundr]

Is it possible to include custom sensor data other than battery level, temperature, advertising counts and uptime to TLM?

[mashbridge]

Not currently, but we've included a version byte in the frame because we know other types of telemetry will be useful. Do you have anything specific in mind?

[lijundr]

There can be various types of sensors which record humidity, pressure, or any custom data types. I am just thinking it will be useful to leave some space for custom data types in TLM.

[roywant]

This is a work in progress. There are several schemes proposed. As soon as
there is wide agreement we'll create either a new Sensor Frame type or add
additional TLM versions

--Roy

On Thu, Sep 10, 2015 at 9:27 AM, lijundr notifications@github.com wrote:

There can be various types of sensors which record humidity, pressure, or
any custom data types. I am just thinking it will be useful to leave some
space for custom data types in TLM.

—
Reply to this email directly or view it on GitHub
#88 (comment).

---

Roy Want
Google Android
MTV-43-206P
Cell: 650 691 3600
www.roywant.com/cs

[bobwhelan]

Sorry to jump in the middle of this thread. You may have already discussed
this, but I was under the impression that the Ephemeral ID was something
that would be added to the TLM packets.
Is there any update on the status of the EID implementation?

Thanks in advance,

Bob Whelan

Bob Whelan
Co-founder
bob@smartwhere.com
voice: 425.941-6045
skype: bob.whelan

On Thu, Sep 10, 2015 at 10:56 AM, Roy Want notifications@github.com wrote:

This is a work in progress. There are several schemes proposed. As soon as
there is wide agreement we'll create either a new Sensor Frame type or add
additional TLM versions

--Roy

On Thu, Sep 10, 2015 at 9:27 AM, lijundr notifications@github.com wrote:

There can be various types of sensors which record humidity, pressure, or
any custom data types. I am just thinking it will be useful to leave some
space for custom data types in TLM.

—
Reply to this email directly or view it on GitHub
#88 (comment).

---

Roy Want
Google Android
MTV-43-206P
Cell: 650 691 3600
www.roywant.com/cs

—
Reply to this email directly or view it on GitHub
#88 (comment).

[mashbridge]

Ephemeral ID will be a new frame type. (And in order to guarantee the best possible security/privacy, we'll recommend that implementors don't interleave EID frames with other frame types that broadcast data unique to that beacon, like TLM data.)

[bobwhelan]

Michael,
I'm eager to hear more... Thanks

Bob

Bob Whelan
Co-founder
bob@smartwhere.com
voice: 425.941-6045
skype: bob.whelan

On Thu, Sep 10, 2015 at 10:37 PM, Michael Ashbridge <
notifications@github.com> wrote:

Ephemeral ID will be a new frame type. (And in order to guarantee the best
possible security/privacy, we'll recommend that implementors don't
interleave EID frames with other frame types that broadcast data unique to
that beacon, like TLM data.)

—
Reply to this email directly or view it on GitHub
#88 (comment).

[glenne]

I envision a beacon that might record physical events like a button press, door opening, or occupancy (parking slot, room presence, bike rack) etc. It would be nice to use eddystone to communicate this data "upstream". In my particular interest is in a timing app where start and finish events are recorded via a key fob like button.

[glenne]

Can you give a link to the 'various schemes' being proposed?

I would like to see a scheme that was not a fixed binary format but rather a form that could be arbitrarily extended with additional (or missing) fields. For example if I send temperature in version 1 and temperature and humidity in version 2 I shouldn't break implementations that understand version 1. I should also be able to just send humidity without temperature. Clients should be forgiving of missing or additional fields to achieve high coefficients of robusticity. This is very important for future extensibility.

I imagine this as a set of name/value pairs efficiently encoded such as a binary form of json: { 't' : 100.0, 'h' : 49.7 }. At it's lowest level it's just name/value,name/value. If I receive a v2 name I don't understand, I can just skip over it. Value should be any type such as int, float, string or a nested map of more name/value pairs. e.g. over and over. Protobuf encoding can be used for efficiency of encoding the values. This would allow tracing and decoding of unknown payloads.

Another aspect to consider is to allow data to be sent for 'custom' applications that do not have a standard set of names defined for the name/value pairs yet. To cover this you could require the first N bytes be the equivalent of a schema reference, perhaps using fewer bytes for 'standardized' items and a 10 byte url hash like the UID for proprietary or standard under development prototypes.

[atsutomiyata]

Roy mentioned about new TLM version in 11th of Sep.
Very interested to know about the new TLM version. What kind of time-frame are you looking at?
End of this year? Next summer?
In addition to already mentioned sensors, motion sensors, open/close sensors for door/window would be nice to apply this technology for security systems.

[mkopa]

Hi,
now I'm using URL frame to sending binary data from devices like
accelerometer or gyroscope. You can encode this data to eg. base 64 and
put it to URL frame.
Anyway, additional frames to any binary data will be very helpful.

On 2 November 2015 at 07:32, atsutomiyata notifications@github.com wrote:

Roy mentioned about new TLM version in 11th of Sep.
Very interested to know about the new TLM version. What kind of time-frame
are you looking at?
End of this year? Next summer?
In addition to already mentioned sensors, motion sensors, open/close
sensors for door/window would be nice to apply this technology for security
systems.

—
Reply to this email directly or view it on GitHub
#88 (comment).

[atsutomiyata]

passage-san,
Thank you for the tips. I see that URL frame can be used to encode data.
However, I am currently interested in applying eddystone-tlm for a commercial products.
Therefore I am eager to see the new TLM version with additional sensor capability.

[ukBaz]

Wouldn't this type of thing be better done using Bluetooth Notifications?

Good overview at: https://vimeo.com/144811493

[petekmet]

Any progress or preview for custom data in eddystone frames ?
Especially custom telemetry frames and ephemeral ID frame (for one-time IDs). For telemetry - since we are very space constrained, maybe you can consider TLV-frame-like which uses BER-TLV-like markup or define tags with predefined length as defined in Bluetooth characteristics specification (https://goo.gl/wU4kKf).

[alexvanboxel]

Hey all, I do see a need for custom frames. So here is a proposal for two custom frames and I think fits nicely in the Eddystone spec. Now let's hope it get's accepted:

Pull request: #122