I have the android weather station app working fine on ruuvi tag.
I understand you are about to bring out iOS version soon.
Perhaps on this version, you could improve the alerts in terms of adding vibration alert option as well as longer/stronger alert tones. If you use tag for say lost luggage, then vibration alert is essential. Also, in android if you get one notification on screen, then further notifications are silent until you clear all other tag notifications. It would be great to improve alerts as above in new iOS app ?
Also, can you use commercial bluetooth gateway with wifi to connect to say Streamr service and do you recommend one suitable ? Can the phone be used as gateway to Streamr service ?
We do not officially recommend any commercial WiFi-BLE gateways as of right now but weāre using Raspberry Pis ourselves. You could also look into Rigado, their gateways might suit your needs.
The Android app Ruuvi Station can be used to send data to a proxy server which then relays data to stream, for example with https://github.com/ruuvi/ruuvi.streamrproxy.js. .The library is at alpha stage, but Iām running it at stream.ruuvi.com. You can set up the Ruuvi Station to use stream.ruuvi.com/ruuvistation as the gateway url to send your data to me, or you can clone that repository on your server, run NPM install and copy the example configuration to āstreamr-configuration.jsā . Then youāll need to route the port 80 on your server to the nodes application port or configure the gateway URL to send to your serverās port.
If there is enough interest in this weāll make proper tutorials and docs on streamr integrations.
Iāve been interested in this for some time. I have Ruuvi tags in my boat and am tracking inside, outside, and motor room temp/pressure/humidity and acceleration. Iād like to implement a graph/trend served file on my raspberry pi.
Do you mean a setup where you have a raspberry pi collect the data from tags and then serve graphs of the data? If so, you may be interested in this setup. In the comments near the bottom thereās an updated, pre-made raspberry pi image if you donāt want to setup the individual parts yourself
I had ruuvi mobile station working fine until I installed IoTool and now neither app works !
Data does not change in weather station display and Iotool app does not pick up ruuvi tag. Tag seems to work on core beacons app. Any ideas to get both of them working ?
Thanks
Could you give us more details?
What is the model and Android version of your phone? Are IoTool and RuuviStation latest versions?
Have you tried turning Bluetooth or phone off and on again?
Hi, I turned off/on the BT and now it works. I use Android 4.3 HTC phone and use the latest apps. I also re-installed Iotool.
Any news on iOS version of ruuvi mobile station ?
Also, do you think IoTool will be released for iOS ?
Thanks for your help.
iOS version of Ruuvi Station is under development right now.
I do not know about IoTool on iOS, in general iOS has some challenges in background BLE scanning functionality.
I ordered 3 RuuviTags to display temperatures. I have one inside of the house, one outside (at the terrace) and one in the sauna outside.
Problem is that I get a little poor reception from the sauna. I have to go by the window to get connection to my cellphone or tablet.
I thought that RuuviTags would use Mesh connection that my outside Ruuvi would pass the information from the sauna to my phone/tablet? Whats the problem here?
RuuviTags are not using mesh networking. Note that some receivers have better antennas than others. You can also try to adjust the sauna tagās location to gain range.
I updated my RuuviTagās to firmware 2.2.2. So far itās working nice and Iām happy about the new v5 data format. I noticed that I can now connect and make changes to the device without touching the buttons (eg. change its name or do a DFU). Does it mean that my neighbors or random people walking next to my house can destroy my devices now? How to prevent that?
That is a good point, it would be possible to craft a malicious DFU packet which bricks the tag.
Maybe some kind of physical interaction should be required before enabling the wireless DFU? i.e. NFC scan or button press?
Totally agree, connecting to the tag should depend on some kind of physical proof that Iām there. Could be the button as it used to be, but thatās a bit inconvenient. NFC would be awesome. But it could also be based on RX power which lets you guess how close the user is, or if the protocol supports it then some kind of PIN code. Either way, it should not be open to the world by default, thatās how you end up with Ruuvi botnets .
PIN code would be doable, but a lot more work than NFC .
Maybe later on weāll add a feature to enable the DFU updates remotely, but for now I think Iāll compile a package which enters connectable mode after NFC or button press.
With respect to my remark on the MAC addressā¦ Either you utilize the URL as-is and get to the ruu.vi site, which will overlook the additional piece of data (to the extent the client goes in any case). Or on the other hand you will need to process the data yourself, which implies you need to recover the data from the promoted bundle and for some odd reason the parcel additionally contains the MAC address of the senderā¦ so regardless I donāt perceive what āuse caseā you had at the top of the priority list while including that ID byte. Kindly do illuminate me.
The ID byte was to help users to differentiate the tags back when we had only the URL mode with no Android app. Google does no longer show the Eddystone URLs to visitors, so the URL mode is deprecated.
On new raw data format the MAC address is present in data payload for the iOS users: iOS does not let the userland see the MAC address, but rather provides the applications with obfuscated UUID of tag.
.
.
