Hello, the steps are at https://blog.ruuvi.com/rpi-gateway-6e4a5b676510
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.
/Andreā
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.
Hi,
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?
Best
Sami
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).
Best,
Sami
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ā¦
@Scrin, thanks for this!
Just wanted to update: it seems to work in real life as well ā got this hooked up to openHAB.
Would appreciate if you can make a release so I would not have to use a snapshot version.
Sorry for the delay, Iāve been way too busy lately. I have now released the current version as 1.0.0
All but given up on this.
Clearly its beyond my level of competence as the link to the raspberrypi website, here:
has several options I cant follow; I am not using a cable and whilst I can see the RuuviGW network but cant connect to and have no wif networks detected on the Rpi GUI, so I end up with no connection on the router.
Its the Rpi instructions I find difficult and obciouslly some of the changes have already been made but some are still needed, static ip addressing etc, so would it be possible for someone to clarify what specific changes to the Rpi are needed?
Thanks in advance
Hi. I donāt seem to be able to get any data to show on Grafana. The InfluxDB is on, RuuviCollector is on and listening. HCItool lescan gives Input/Output error which it didnāt give before I rebooted the machine. I tried to reset it with hciconfig hci0 reset, which worked yesterday in this same error but now it doesnāt. I made the image/built according to https://blog.ruuvi.com/rpi-gateway-6e4a5b676510 . I also tried with the latest Ruuviberry image I could find, but that also had somewhat similar problems.
I tried to fix the hcitool error with restarting bluetooth and dbus but the system went on to some weird limbo and I had to unplug the machine for it to work. Iām kind of in a dead end and would appreciate if anyone is able to suggest something.
Best,
Pasi
Have you tried selecting a specific value inside field(value)
? For example field(temperature)
.
Iām using ruuviberry image ā2018_05_minimalā, where I have updated Grafana from 5.0.4 to 5.4.3 and InfluxDB from 1.5.2 to 1.7.4 manually.
How can I show in Grafana pressure difference between two different tags?
As far as I know Grafana / InfluxDB does not support this in an easy manner, youād probably need some kind of continuous query which creates difference data . @Scrin would you happen to know an elegant way to do this?
As far as I know you are correct, InfluxDB does not support on-the-fly calculation between separate measurements (pressure values from two different measurements in this case), and as far as I know, the InfluxDB builtin Continuous Queries are restricted by this same limitation. The method recommended by InfluxData is to use Kapacitor, which is their data processing engine, to perform this kind of calculations.
I used to have Kapacitor tickscripts created for calculating some of the āextra valuesā (such as dew point and absolute humidity), but I have since implemented them straight into the collector itself because Kapacitor tickscripts are rather clumsy to work with compared to doing the same with Java straight in RuuviCollector.