So I have been using @ThomDietrich miflora daemon for a while, the problem is that some of the plants are having trouble connecting to the RPI with the OH running on it. Same goes with @rlkoshak presence,
Both these tools uses MQTT and publishes to the broker on RPI. So I was wondering if we could increase the bluetooth range by adding some rpi zero
Could we make an image to make it easy for the end user to extend the bluetooth range? That they only need to add wifi credentials, and that it will copy configuration files from the broker?(If you add a plant it gets added to all the rpi zero)
Or is there a better way to extend the bluetooth range?
that’s not even just an idea, that is how it is supposed to be used. It’s why we are utilizing MQTT Just set up a RPi Zero W with a basic system like openHABian, install the miflora daemon and connect it to your MQTT broker. Voilà
There is no need to extend the bluetooth range of one BT master if you can just as well install multiple masters in your home
The idea was that maybe we could do something to make it easier for the user to make sure that the two config files are synchronized… The problem is that we would potentially spam the broker with the same message with small time difference since two rpi might pick up the same sensor. This is however an issue only with tons of sensor and high update frequency.
I don’t use Thoms’s daemon yet, but at least with reelyActive or sensorReporter BT detection, you want OH to report hits from both instances even when they see the same device. Note, I’ve an updated version of that code here: Generic Presence Detection
The fact that only one of your RPis sees a BT device and the signal strength of that detection can tell you not just that the device is nearby but could potentially tell you where in the house the device is located. It also provides redundancy of detection which is what the example presence detection code above relies upon.
So in short, I think it is by design that you would get reports from multiple RPis.
I’ve not run benchmarks but in practice I suspect you would need hundreds of clients each publishing hundreds of messages before mosquitto starts to have latency problems. Of course if you use higher QOS the performance will go down.
When I’m playing with reelyActive, plus my hping3 and arduino sensors reporting I get around 100-200 messages per minute and mosquitto does not appear on the first page of top on my machine in either CPU or memory.