Some notes

[cxtal]

This is a very cool project and hopefully it is still being developed! I would like to add some notes (summarized here) since I have been struggling with the setup quite a bunch and perhaps it will provide a milestone for others struggling.

• Compiling or running find3-client-scanner fails with the provided instructions spectacularly.

If you are using a Raspberry Pi (armf arch), you need to build the image yourself, although I suggest Raspberry Pi’s just built natively above.

First, building the image via Docker fails with a non-zero code and sadly Docker spews the entire shell command out such that it is difficult to track where the problem may be in the whole command chain.

Compiling natively fails on all Go versions I have tried (about 4 versions; patience is my new redeeming virtue) except 1.13 which succeeds to compile find3-client-scanner on a Raspberry Pi W running Raspbian Jessie. The command used to successfully compile was:

GO111MODULE=on go get -v github.com/schollz/find3-cli-scanner

Note that this command seems to change a lot throughout the documentation, sometimes it is: go get -v github.com/schollz/find3-cli-scanner, other times it is GO111MODULE=on go get -v github.com/schollz/find3-cli-scanner/v3 (which does not exist?) and the above command is what did it but only with golang version 1.13 and on Raspbian jessie.

• Compiling the Find3 server on the most recent stable Debian distribution (at the time of writing, Buster) fails with errors during compilation.

Running the Docker image seems to be the way to go and tends to work properly out of the box.

And some remarks:

• On the cli scanner page, under Usage -> Active scanning, the example does not supply the -wifi parameter but just -bluetooth. It is not that much of an issue because re-reading the documentation multiple times does hint that -wifi should be there too for wifi scanning.

• The Raspberry Pi W does support monitor mode via Nexmon. Perhaps that can be added to the documentation on the cli scanner page under Usage -> Passive scanning? It is very tough to get Nexmon to compile and patch the kernel properly but it works a treat once it succeeds. There is a Raspbian Jessie pre-made image available that contains both Nexmon patches as well as a compiled find3 client made to just start passive scanning and transmitting on startup - perhaps it helps someone build a better provisioning image.

• There seems to be a minor issue where a device is added by MAC (and without the wifi- prefix) to the dashboard "Toggle learning" form that makes the table bug out and display empty / broken entries.

Clicking "Stop" does not remove the entries and I have tried to dig into the sqlite3 database and locate these entries manually to delete them to no avail. Perhaps the form is not performing sufficient sanity checks on what can be entered on the "Toggle learning" form?

• One parameter that I would add to the Docker command when running the Find3 server would be --restart always to ensure that the container restarts properly after a reboot.

• find3-cli-scanner contains an elusive -gps parameter about which I have found very little information. I assume that the -gps is meant for Android devices. If so, ESP and Raspberry Pi devices are easily equipped with GPS addons and wouldn't it be better to allow some access to a GPS device (let's say, via serial / NMEA)? Otherwise, I am not really sure how the -gps parameter and GPS functionality works.

• Regrettably the openHAB instructions seem outdated and the new MQTT module has a very different syntax. I have long since moved away from openHAB exactly for the same reason since the MQTT update made me have to rewrite everything again.

Overall, the project is great and I am having a lot of fun with it. It is very useful and seems like the best option for my usage case out there. The only major major issue is just getting the tools to compile properly. Otherwise, once compiled, everything works a treat. Thanks!

[nash-stokes]

I agree the documentation could use some cleaning up. I reached out to the creator about this. He was very open to the idea of open sourcing this. My biggest hurdle was overcoming the initial installation steps, like you mentioned. Creating clear, consistent instructions between the github page and the project website would be helpful. I've gotten the project to work with passive and active scanning, but it was a painful process. Let me know if you would like to work together on this.

[cxtal]

I am very happy to contribute. My biggest gripe is that I am impartial to Go and have never programmed anything in Go (some long-standing alternatives there from Perl, Ruby through Python and up to Node.js and not sure where Go fits in). I can do others and with some help of the fellow contributors that I work with we have managed to fix the ESP8266 / ESP32 component since the API is very clear on the payloads sent back and forth between the client and the server.

The major issue that I see is that the project is alright even with the mentioned issues but also quite old in terms of requirements. I had to install Debian Jessie (2 stable releases back, at the time of writing) just to get proper compatibility with all the libraries that Go needs. I am not sure whether "just updating" is an easy fix or whether a hefty re-write is necessary.