Scrin
commented
2 years ago You absolutely can contribute the service setup back to the project, in fact there has been a TODO about this very thing in the readme since forever.
I think the best approach would be to create a directory service-setup in the project root that would contain all of these example .service files, relevant setup scripts, etc, and a README.md (so that it renders by default nicely when viewing the directory through github).
The readme in the service-setup directory would then contain the specific instructions, notes, whatever related to setting up RuuviCollector as a service, and the readme in the repository root could be updated to point to this subdirectory in place of the TODO comment and rephrase it such that the existing manual steps there would be referred as "Running RuuviCollector manually" or something.
Do note that you cannot run two lescans using the same bluetooth adapter simultaneously, the 2nd attempt will fail since the 1st one is keeping exclusive access. This isn't an issue if the service starts lescan first since ruuvicollector just ignores the error, but if ruuvicollector manages to start lescan first, the service trying to do so will fail, so in setups where lescan runs in a separate service, the scan command must be disabled in the config (by setting to an empty string, as described in the sample config).
In my former setup I had the collector and its config under /opt/ruuvicollector/ which I think is better than /usr/local/bin/ or similar, since the config files need to be in the same directory
I think you can open a PR based on this and if I missed some detail, do it as you feel is the best and we'll iterate on the details on the PR then to ensure the setup and documentation is good and clear.
Describe the feature you'd like to have implemented The core desire here is to ensure that the scanning command is always running. My proposed implementation to achieve this is to run the
lescanas a service, rather than being run by RuuviCollector.I'm having troubles with the scan command (
hcitool lescan --duplicates --passive) dying on me. This results in no data coming in, no error messages being printed, and the service does not exit, which makes the recovery process difficult to automate.Describe alternatives you've considered The [ProcessBuilder.start()](https://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html#start()) method does return a Process object. It's be possible to spin up our own thread that would [waitFor()](https://docs.oracle.com/javase/7/docs/api/java/lang/Process.html#waitFor()) the process to exit and then just immediately restart the process.
I have two objections to this alternative approach:
Do you want to implement this feature? Yes
Additional info I've already implemented this as a systemd service in my deployment. My question is if I can and how I should contribute this back to the project. I also have a .service file for RuuviCollector that I'd be willing to contribute as well.
Please let me know if these service files should go in a directory by themselves, whether you'd like an install shell script to set this up, if it's OK to update the README with instructions, and so forth. Also, systemd requires an absolute path to the executable, so if there are any suggestions on where that should go (/usr/local/bin?), I'd be happy to incorporate them.
This merge request would not be any changes to any existing code. The user could change their ruuvi-collector.properties file to make the scan command an empty string (or not, it wouldn't really hurt to have two
lescans running at once, though it'd be unnecessary) and then set up and start the lescan service.