Emit tag ID with updated tag data

[akomelj]

Hi, would it be possible to emit tag ID with updated tag data as well?

id attribute should be added in emitted event data in the following location: https://github.com/Espesen/node-ruuvitag/blob/5fb169467c4b238c035ad26709b713eb7c4f3972/ruuvi.js#L81

Specifically id: parsed.id in the following block of code:

            ruuviTag.emit('updated', {
              url: url,
              dataFormat: parsed.dataFormat,
              rssi: peripheral.rssi,
              humidity: parsed.humidity,
              temperature: parsed.temperature,
              pressure: parsed.pressure,
              id: parsed.id

[Espesen]

You can access the id in the closure: #4 -- is there a specific reason why it should be emitted also?

[akomelj]

Is the ID that is available in the closure somehow related to the ID that Ruuvi tag sends with the environmental data? Or, to rephrase, is the ID that Ruuvi tag sends with the environmental data derived from the ID that is available in the closure? According to my tests (Raspberry PI 1 w/ Asus BT dongle), they do not appear related.

I'm referencing this ID (from https://lab.ruuvi.com/weather-station/):

What is the "ID"?

If you run one of the latest firmware applications on your RuuviTag, you'll most likely see this new ID row.Don't worry. It's just a new feature users have requested. It helps to differentiate more than one device from each other.The number is "random" but it's generated from a unique ID every device has. So it won't change on reboot.

As far as I understand (from the referenced issue), the ID available in the closure depends on the platform but the ID embedded in Ruuvi data is constant regardless of the "listening" platform.

In my case, Raspberry PI 1, I receive the following data:

• ID from the closure: cfe12ac99f5f
• ID from the tag: 21

I don't see how they are related but it might come in handy, that the ID in the emitted data remains constant regardless of the platform.

[ojousima]

You should use the cfe12ac99f5f as it is the MAC address of tag. The ID in URL mode is just a static random 6 bits which helps users who're running tags in URL mode to differentiate the tags from each other if their platform does not reveal the mac address.

[akomelj]

Hm, yes, that obviously is an option but as one user noted in #4 (and I can confirm), the ID in the closure is not always the MAC address (on Mac, specifically). I'd like to have something independent of the platform.

Believe it or not, I'm reading the data from multiple tags on multiple platforms and sending them to the same Prometheus sink for Grafana charts and sometimes my Mac finds the "Raspberry-assigned" tag on the other side of the house and if I use the closure ID for differentiating the data, I get another tag recorded in Prometheus. :-)

So, for this particular tag:

• ID from the closure on Mac: 8cb4ebf609904a8d947f6518800fc6db
• ID from the closure on RPi: cfe12ac99f5f
• ID from the tag: 21

I can of course submit a pull request - its only a single line that is added - if there's any chance of accepting it.

[Espesen]

Thanks for pointing this out! You were actually referring to the id that is broadcasted only in data format 4 url. In 55d619c6783228704c15f27305d648742861a0c0 that id will be emitted as eddystoneId property. Hope this helps.