To answer your question “why”: Because at this moment the weather station example is broadcasting only.
We are adding more features in the future. You are also welcome to contribute the SW projects.
So if the tag is broadcasting the UID and the second part is user programmable wouldn’t it be sensible to let the user add his own identity code to the ‘Instance’ when he uploads fo the tag.
At the moment if two tags are broadcasting and in range the user can’t tell which one he is looking at in the browser and without manually decoding the MAC address through some other app.
Hang on.
That image/example shows just two tags, one near and one far and if there are ten or twenty tags all within BLE range clearly it’s impossible to tell which is which.
Have you thought fhis through at all?
We have. At the moment the Weather Station is a simple application which is broadcasting sensor data in a URL address. And like I just said, it is about to get more features.
If you have many Tags you would like to read at the same time, you should consider setting up a gateway by following, for example, some of these tutorials.
Why would I want to complicate the whole project with a Wifi gatewy when all it needs is being able to program each tag to return a name in plain language that is something relevant to the application of the tags?
The tag currently returns Ruuvitag so why not Cold Room or whatever?
This is just a question of changing the instance part of the Eddystone UUID.
Quote
The Eddystone UID data has Namespace e.g 8b0ca750095477cb3e77 and Instance (e.g. 123456789abc) parts. The Namespace is intended to uniquely identify your company and the Instance identifies the beacon within your company. The Eddystone spec recommends you create the Namespace from either a SHA-1 hash of a fully-qualified (internet) domain name that you own or an elided (iBeacon) UUID.
For the SHA-1 option convert your domain name, without www, with an online tool such as the one at Waraxe IT Security and use the first 20 characters as the Namespace.
The other method is well described by Google:
“Generate a version 4 UUID then remove bytes 5 - 10 (inclusive). For example: from this UUID: 8b0ca750-e7a7-4e14-bd99-095477cb3e77 remove these bytes: e7a7-4e14-bd99. This produces the following namespace: 8b0ca750095477cb3e77.”
You will get a different Namespace either way and that’s intentional/expected.
The 6-byte instance (12 hex digits) value is up to however you choose to
define, based on your places and areas within places.
Unquoye
It would be possible to send unique Eddystone UIDs from tags - in fact you can do this already in the Eddystone application.
However, you cannot send any plain text string as Eddystone UID, since you’re limited to 0 …9 and A … F.
It is possible to tie Eddystone UIDs to real-world events with various applications, you can for example check out Proximi.IO. To get the sensor data combined with the Eddystone UID some software work would be required.
We’re working on bringing more features to the Tag, however it will take a while before we have user-configurable name for the tag. In the meanwhile, you can check out one of the projects for processing the sensor data in Android or Raspberry Pi.
I just want to be able to identify which tag I am reading when more than one is being received.
As I read it, the ‘instance’ part of the UID, is expressly set aside as a unique user programmable identifier for the actual tag using the characters permitted, just as the unique first part is user set to identify the company or organisation.
Read the first and last paragraphs above again.
I think that it would be fine, if there were simple instructions to modify the weather station page and instructions to upload it then into ruuvitag. I think that it is what most of us need. Thanks for great product.
Hi Motobiman,
I guess you made your point out already with several messages with same info and there has been several answers to your questions. Ruuvi team is currently working on bringing more features and ready-made software. This is an open source project where Ruuvi provides a platform and all users are are welcome to contribute on software development.
So, please be most welcome to contribute our fast growing development community and your requested feature might be working soon 
Heh thanks.
Not aware any responses were answers, certainly not solutions.
It would work OK for me if we could just change the local name of the device.
It’s a bit tricky because the name info you see on your phone (HTML page metadata) comes from a web server, not from the RuuviTag. Also, the web server doesn’t know which Tag the exact address came from because those addresses doesn’t include any unique IDs (because of Eddystone-URL space limit).
@otso Or what do you think? Do we have any space left to send for example last two hex numbers of the MAC addresses with each advertisements?
Thanks Lauri.
There needs to be an answer because IMHO the usefulness of BLE sensor tags generally is seriously denigrated if there is no way of telling which individual tag is being read without a separate cross reference system.
We do have 6 bits of data available in the URL, we could put last bits of MAC address and hope that there would not be collisions. We could also make those 6 bits user configurable in the future, so they could assign a new ID in case of a collision.
Right now the idea would be to use those bits for battery voltage, but the battery voltage could be sent in a separate Eddystone TLM package or be read on connection.
Can I ask how the commercial suppliers of tags handle the issue?
Clearly when they sell generic tags the buyer demands his own name returned as the tag identity and that must be programmable.
Just a thought.
Generally the tags come with preprogrammed UUIDs. For example we could make a batch of eddystone tags with namespace UUID client has requested and a random instance ID.
It would also be possible to configure the namespace and instance ID over the air on Eddystone application.
You could create an smartphone app which would continuously scan for Eddystone beacon in configuration mode with name prefix “Ruuvi”. Once beacon would be detected, app would program your namespace and running counter to instance.
Hi I ’ ve managed to decode RuuviTag readings via PhysicalWeb node avaialable . the flow below contains upload to google.docs and visualsiation on node-red dasboard:
[{“id”:“7543a7b7.449e58”,“type”:“PhysicalWeb in”,“z”:“b773c68.2f29c38”,“name”:"",“topic”:"",“duplicates”:true,“x”:98.83332824707031,“y”:47,“wires”:[[“a419f065.47f74”]]},{“id”:“e907ae2c.aca54”,“type”:“debug”,“z”:“b773c68.2f29c38”,“name”:"",“active”:true,“console”:“false”,“complete”:“true”,“x”:806.8332824707031,“y”:376.99998474121094,“wires”:[]},{“id”:“b53412c0.4fbcb”,“type”:“base64”,“z”:“b773c68.2f29c38”,“name”:"",“x”:624.8333129882812,“y”:44.33331298828125,“wires”:[[“61f8ea0.8837918”]]},{“id”:“8579b9e0.db4708”,“type”:“rbe”,“z”:“b773c68.2f29c38”,“name”:"",“func”:“rbe”,“gap”:"",“start”:"",“inout”:“out”,“x”:454.83326721191406,“y”:45,“wires”:[[“b53412c0.4fbcb”]]},{“id”:“a419f065.47f74”,“type”:“function”,“z”:“b773c68.2f29c38”,“name”:“url extract”,“func”:"\nvar lastFive = msg.payload.url.substr(msg.payload.url.length - 8)\nvar newMsg = { payload: lastFive };\nreturn newMsg;",“outputs”:1,“noerr”:0,“x”:290.8332977294922,“y”:45.66668701171875,“wires”:[[“8579b9e0.db4708”]]},{“id”:“61f8ea0.8837918”,“type”:“function”,“z”:“b773c68.2f29c38”,“name”:“decode”,“func”:" var decoded64=msg.payload;\n //node.log(decoded64)\n var humidity = decoded64[1] * 0.5;\n var uTemp = (((decoded64[2] & 127) << 8) | decoded64[3]);\n var tempSign = (decoded64[2] >> 7) & 1;\n var temp = tempSign === 0 ? uTemp/256.0 : -1 * uTemp/256.0;\n var tempF = temp * 1.8 + 32;\n var air_pressure = ((decoded64[4] << 8) + decoded64[5]) + 50000;\n var res={}; \n res.Temp=temp\n res.Humidity=humidity;\n res.Pressure=air_pressure/100;\n //node.log( res)\n var newMsg={ payload: res };\nreturn newMsg;",“outputs”:1,“noerr”:0,“x”:612.8333282470703,“y”:169.00003051757812,“wires”:[[“d9bb357f.34a728”,“5c86ba88.a3f484”,“291bb3a6.38721c”,“5e89fce2.adc8a4”,“e907ae2c.aca54”]]},{“id”:“d9bb357f.34a728”,“type”:“http request”,“z”:“b773c68.2f29c38”,“name”:"",“method”:“GET”,“ret”:“txt”,“url”:“https://docs.google.com/forms/d/e/1FAIpQLSe5y3kieN8awamZH8mddJW8_9TkwCxi_mh38JfxTX6bLN3mWw/formResponse?entry.2129173735={{payload.Temp}}&entry.1724609919={{payload.Humidity}}&entry.392458147={{payload.Pressure}}”,“tls”:"",“x”:848.8332977294922,“y”:103.66665649414062,“wires”:[[]]},{“id”:“37d04bf0.89a474”,“type”:“ui_gauge”,“z”:“b773c68.2f29c38”,“name”:“temp”,“group”:“dcdcb16a.e1794”,“order”:1,“width”:0,“height”:0,“gtype”:“gage”,“title”:“Gauge”,“label”:“units”,“format”:"{{value | number :0 }}C",“min”:"-20",“max”:“50”,“colors”:["#00b500","#e6e600","#ca3838"],“x”:1032.8333587646484,“y”:29.6666259765625,“wires”:[]},{“id”:“5c86ba88.a3f484”,“type”:“function”,“z”:“b773c68.2f29c38”,“name”:“Temp gauge”,“func”:“return {payload:msg.payload.Temp}”,“outputs”:1,“noerr”:0,“x”:854.8332977294922,“y”:29.66668701171875,“wires”:[[“37d04bf0.89a474”]]},{“id”:“5e89fce2.adc8a4”,“type”:“function”,“z”:“b773c68.2f29c38”,“name”:“Humidity Gauge”,“func”:“return {payload:msg.payload.Humidity}”,“outputs”:1,“noerr”:0,“x”:854.8332977294922,“y”:169.66668701171875,“wires”:[[“f2748697.ed1178”]]},{“id”:“291bb3a6.38721c”,“type”:“function”,“z”:“b773c68.2f29c38”,“name”:“Pressure Gauge”,“func”:“return {payload:msg.payload.Pressure}”,“outputs”:1,“noerr”:0,“x”:846.8333282470703,“y”:259.6666717529297,“wires”:[[“8c5e9d0c.1cd61”]]},{“id”:“8c5e9d0c.1cd61”,“type”:“ui_gauge”,“z”:“b773c68.2f29c38”,“name”:"",“group”:“b99d7751.f24e88”,“order”:1,“width”:0,“height”:0,“gtype”:“gage”,“title”:“Pressure”,“label”:“units”,“format”:"{{value}}",“min”:“800”,“max”:“1050”,“colors”:["#00b500","#e6e600","#ca3838"],“x”:1032.8333587646484,“y”:260.3332824707031,“wires”:[]},{“id”:“f2748697.ed1178”,“type”:“ui_gauge”,“z”:“b773c68.2f29c38”,“name”:"",“group”:“2bcb7a68.a61ad6”,“order”:0,“width”:0,“height”:0,“gtype”:“gage”,“title”:“Humidity”,“label”:“units”,“format”:"{{value}}%",“min”:0,“max”:“120”,“colors”:["#00b500","#e6e600","#ca3838"],“x”:1034.8333587646484,“y”:170.33331298828125,“wires”:[]},{“id”:“dcdcb16a.e1794”,“type”:“ui_group”,“z”:"",“name”:“Group”,“tab”:“3ec967de.6c75c8”,“order”:null,“disp”:false,“width”:“6”},{“id”:“b99d7751.f24e88”,“type”:“ui_group”,“name”:“Group”,“tab”:“3ec967de.6c75c8”,“order”:null,“disp”:true,“width”:6},{“id”:“2bcb7a68.a61ad6”,“type”:“ui_group”,“name”:“Group”,“tab”:“3ec967de.6c75c8”,“order”:null,“disp”:true,“width”:6},{“id”:“3ec967de.6c75c8”,“type”:“ui_tab”,“z”:"",“name”:“Tab 1”,“icon”:“dashboard”,“order”:1}]
The second option sounds good, Otso.
At the moment I am having to manually log the first part of the URL in a note and refer to it to check which tag I am looking at.
With only three tags its cumbersome, with twenty in range, it will simply not work and I think many sensor monitoring applications will suffer the same issues.
I’m not an expert in the Eddystone packet format but I agree, wouldn’t using the Eddystone-TML package solve this problem? Using Eddystone-UID to identify the unit and Eddystone-TLM to send sensor data. It would also be good in the future to have the option to use the Eddystone-EID frame type if one needs the information to encrypted.
You are correct, adding Eddystone-TLM, Eddystone-UID and Eddystone-EID would cover a lot of use-cases.
There is a matter of power optimization: if we broadcast 4 packets instead of one in the same interval the power consumption almost quadruples. Therefore user should be able to configure which packets they actually need. Easiest way to approach this would be to modify the Eddystone firmware to detect base url “ruu.vi/#” and fill in the sensor data when applicable.
Even with the Eddystone features the original issue of detecting “which beacon has sent this URL” would not be well resolved, though, as the website is unaware of every other packet in the air. In longer term, having web-bluetooth application read user set name from tags would be ideal.
I cannot promise an exact schedule for a proper web-bluetooth demo for reading sensors, but right now “April - May” looks pretty realistic.