I don’t know what values to enter…Enlighten me, please.
we’ll check the conversion factor from the Google
And then apply the conversion in value field of the query
You can then edit the header of graph in “General” tab
Thanx for responding.
I would like to store data to two separated DB’s at same time, for backup purposes. I am currently taking backups on OS-level by shutting down DB and tarring&zipping needed DB-files followed by startup of the DB.
It would be handy to store data from collector directly to two DB’s, something like this:
.# Base url to connect to, including protocol, hostname or ip address, and port
.# InfluxDB Database to use for measurements
.# InfluxDB measurement name to use for measurements
.# Username and password to use in influxdb. These can be ignored if you don’t use authentication in InfluxDB.
This requires code change of course…
If source DB gets corrupted or data erased by some reason, live backup is not option.
Technically speaking fully-automatic live-backup-replication is not a backup at all (same reason why RAID is not a backup), so in that sense it makes sense to store the data in parallel, rather than replicating it forwards like a chain. It is actually on my long-term roadmap to support multiple simultaneous database/storage types, so I may as well adjust that a bit and support ambiguous database/storage types (ie. multiple InfluxDB) to support this use-case as well
I’ll bump this feature forwards on my todo-list a little bit, but I don’t want to give any promises yet on when this will be done
transfer the data measured by ruuviTag to my influxDB database
had to install this image again on a new card. Now I cannot find a/the guide on how to remove the bridge br0 and enable wlan0 with a static IP.I need to have the rb pi connected to my wifi at home.
Can some one please link to a complete guide or just tell me the steps.
but how do I remove the br0 and wlan0 ruuviGW?
I don’t want/need anything else than just a simple wifi connection from ti PI to my router.
Hello, I though you had it already done.
Anyway, it might be easiest to follow the above steps to setup the Raspberry Pi, it takes something like 15-30 minutes and you get the updates to software while you set it up.
This is a great project and ruuvi collector seems to be “the” implementation for parsing ruuvitag data.
I would love to see the data parsing part separated and published more widely, e.g. in maven central. This would facilitiate easier reuse of the parsing part in other java projects.
In fact, I’m thinking of implementing small openHAB bluetooth addon for reading ruuvitags based on the excellent you have done here.
@Scrin any thoughts on this?
I have actually been considering this, but haven’t done it yet as the ruuvitag-sensor python library is usually the choice for custom implementations while the main goal for RuuviCollector is being a “full software” to glue the gap between RuuviTags and InfluxDB (and other databases in the future).
Though if there’s interest in having a similar library for Java, I may reconsider separating the pieces into a library and publish to maven central or something.
thanks for the swift reply!
I would definitely be interested in such a library. There is already an openHAB implementation for blukii sensors (github) which looks pretty similar the way the ruuvitags work.
With openHAB I think we would cover “native support” (no mqtt or other additional software needed) for the common open source home automation solutions (other one being home assistant of course)?
Naturally you have used a liberal license so forking and/or incorporating the code in openHAB code base would be possible for me (within the limits set by the license). But instead I would like to have common library for the parsing, and reuse that for other projects. Contributions for new formats etc. would be handled in one open source project…
A common library would definitely be the way to go here then, added it to my todo-list.
I don’t know how much you have looked at the RuuviCollector sources, but I was thinking about refactoring (and renaming) so that there would be an “extra layer” between the HCIData output from HCIParser and the actual DataFormat parsers (implementations of BeaconHandler, to be renamed to RuuvitagParser or something?) so that the parsers would just receive the raw payload (ie. the eddystone packet which includes the eddystone url, or the raw manufacturer specific data used by the RAW data formats) as a
byte data array.
This extra layer would then be RuuviCollector specific and contain the HCIData to data mapping as well as the shouldUpdate() logic currently present in the parsing classes (that logic shouldn’t even be there in the first place…)
That way the common library would offer parsers that simply accept a byte array as a parameter and produce a RuuviMeasurement object as output. Any comments? (anyone else may comment as well, of course)
I don’t think it would make sense to include the HCIParser itself in the library, especially considering I’m working on getting rid of the hcitool and hcidump dependencies as they’re getting deprecated due to the lack of maintainers.
It’ll be probably late next week or something before I have time to get all this done, especially since I need to figure out the necessary requirements and steps for publishing libraries to eg. maven central.
Excellent and thank you already in advance!
Looked at the code and I understand what you mean. Agree that this separation would indeed make the code cleaner as well as more testable.
Let me know if I can help in any way, review the code or similar. When you have separated parsers from the rest, let me know and I can have a look.
Btw, it might be that the maven central part is actually not so important for me personally since I probably have to distribute the parser
.jar inside the openHAB/eclipse smarthome code base (maven
<dependencies> are not used there for whatever OSGI/setup reason).
Yeah now that I think about it probably the first step is to simply copy/refactor the code out into another repository as a “pre-release version”, then do the cleanup/documentation, write tests, etc. to eventually make it a “clean 1.0 version” of the library, and once all that is done then publish it to maven central or so and only then refactor RuuviCollector to use the library.
Slightly more work (and duplicate code while working on it) to do it in “individual steps over time” like this, but on the other hand it makes the library usable earlier on before the “stable 1.0 release” is ready and published to maven central. I might actually have time to do the “first step” during this weekend, if so I’ll let you know so you (or anyone else) can review, comment and/or contribute.
Alright I created the repository now: https://github.com/Scrin/ruuvitag-common-java/ and did some light and untested (well, I tested that the code compiles but nothing more ) refactoring and basically set up the base foundation for the library. In theory it might actually already work as it is, but there’s still much to do. Comments, suggestions and contributions are more than welcome (here on the forums, Ruuvi slack, or on Github)
trying to join in this discussion.
Awesome! Will have a look as soon as I have a moment. Can contribute some tests…