Chrome widget reports multiple URL for same ruuvi

I was totally confused.

If I use the chrome widget from TODAY from my iPhone it presents https://ruu.vi/#AIQVAMNQ

I thought I was accessing that same url from my MacBook different values are displayed.

Thanks for reporting.

Could you please let us know which values you’re seeing?

Oh you had to ask:
on iPhone/chrome: 21/70 ; 42; 1000
also safari

From macBook safari 17/62; 113;1069.77. ( humidity >100%,)

Interestingly, locate app scan reports AlgVAL9o

I think I see the light. changing temperature changes the URL! the leading A (defining the format ) remains as does the training o ( the tag ID ). The 2nd through 4th vary with temperature.

I thought I saw something relating to this but I cannot find it now. (can you refer me to documentation?)

App needs additional info like time sampled ( even if ruuvi tics since booti then from server app)

Hello,

The data is encoded in URL itself, so same URL should always give same results for everyone. Last character is ID, and it should not affect the data anyone sees. The URL is expected to change, as the data shown on site is encoded to the URL parameters.

Humidity is interesting, it definitely should never read above 100%.

I get the 17/62; 113;1069.77 on Chrome, so I’ll look into how the value is above 100% and see if I can make my tag send such a value.

EDIT: As the locate app gives you different results, I would guess that the issue is in caching the URL somewhere. The sensors on the tag take a while to settle, so it might be that you’re seeing some initial value which gets cached.

1 Like

So it’s a learning experience.
The RuuVi message neglects to send an ID

Ahh - data encoded in URL, web page served by ruu.vi. That explains a lot :slight_smile:

Can I bridge this thread to the broadcast name thread?

on the Chrome plugin for iOS, every one of several active tags show up as “Ruuvi Weather Station” - so I can’t tell which is which. I tried changing the name in boot mode per the other thread, but was only able to change the name from “RuuviBoot” to something else, which stayed to my selection for a while, but then after mashing one of the buttons it reverted back to “RuuviBoot”.

So - any advice for the best place in the docs for Newbies to learn about such stuff?

Step 1 “Hello World” for me would be to change the broadcast name for several tags in weatherstation mode, so that I can tell which is which.

Then Step 2 “Hello World” would be to flash Espruino and replicate the weatherstation firmware functionality, except with unique broadcast names for each of several different tags… I guess for that we should start here…

I believe the firmware in the ruuvi needs to be changed and I am working on that.
Path to source and ability to rebuild firmware seems mysterious though.

I have prepared (the first page of ) a web site to mate with the new firmware:

MyRuuVi.com

Doesn’t do ANYTHING yet. Your comments are welcome.

Looks good @dgerman !
nice of you to open it up like that…
Could you explain what the major and minor fields are for?

The only other thoughts would be to add a time-tag and capture acceleration - might as well get data from each of the sensors. And why not offer a direct JSON export as well as CSV? I’d guess you may anyhow store in Mongo…

  1. It seems that BLE devices include Major and minor items.

  2. I expect complete the registration action page in the next few days.

i.e. create user entry in MySQL table,
create device entries in device table

2b) next device configuration in device table: i.e. measurement, units ( F or C, Kpa or inHg, background image, font(?))

  1. I have acquired domain names to maximize URL datafields.

  2. initial implementation is to simply permit user defined weather stations including
    multiple locations.

  3. Second will be short term history for example temp/humid/pressure for last N periods where a period is M minutes.

  4. Then “delta symbols” (pseudo graph) for example —↑↑↑–↓↓

  5. Additional data items, including (but not limited to) acquisition time, movement user defined measurements (wind speed, indecent sunlight)

  6. Graphing …

  7. Good idea regarding JSON (as well as other export formats) . I plan to store “lots” of data in MySQL.

  8. Do you have any thoughts regarding precision. for example is it acceptable to provide
    10a) temperature in even number if F ?
    10b) humidity to nearest 5%
    10c) pressure in relative change since 4 hrs ago, 3, 2, 1 ?

Additional thoughts welcome.
PS Whats a Mongo…??

Thanks for the lead on Major / Minor. I’m quite new to details of BLE - planning to learn with Ruuvi. Your hint sparked a quick review of https://en.wikipedia.org/wiki/IBeacon, which does a nice job of putting Major / Minor in context…

Mongo is a very popular No-SQL database. It’s great for storing great gobs of unstructured or loosely structured data. Might be worth starting here to learn more: https://en.wikipedia.org/wiki/MongoDB.
You could easily get started on Mongo e.g. with a free sandbox account here: https://mlab.com/, versus setting up a db from scratch… It seems SQL and No-SQL databases each have their own strengths and weaknesses, and I’ve read things indicating that they’re gradually tending to adopt some of the useful characteristics of the other. So many options :slight_smile:

In terms of precision, I prefer to not throw away precision unless it’s mostly noisy detail. Personally I like temp to nearest tenth of a degree and humidity to the nearest whole percentage point. And a trail of recent pressure changes would make a nice touch…

Sounds like you’ve got a good project going on - wish I had more skills to contribute and not just opinions… Thanks for sharing!

10e)Regarding precision: there is a very restrictive limit in the amount of data transferable with eddyStone protocol. So much so that there are special single byte codes for http://, http:// … as well as (believe it or correct me if I’m wrong) for .com, .com/, … .info, .info/ . I agree with you that when possible I prefer not to discard precision and only change the display for more human readable display. In this case precision requires more data. I believe that the precisions I suggested in item 10 is even more that can be appreciated. For example: what does it mean to you if it’s 44F or 45F? Or 50% or 55%. Many of these readings with fine precision are VERY local especially temperature for example in the front of the house verses the side!

Regarding data storage, I’m quite comfortable with MySQL so I’ll be storing the data there.

End user opinions are very important. Many developers fail to enlist the opinions of end users and end up developing over kill applications that contain unused “great features”.