After a couple of hours with the new parameters I already notice that the broker now shows many more moments of inactivity from this Theengs Bridge. I believe adjusting the scanduration to 30000 is not suitable for my use case.
Ideally I would like to have a very short scanduration and an immediate message to the broker.
Next to my experiments with the Theengs Gateway and Theengs Bridge, I currently have a stable solution running using the BLED112 device, see example code here: bglib/Python/Examples/bled112_scanner.py at master · jrowberg/bglib · GitHub
As far as I understand, the default scan window is 200ms in this situation.
The BLED112 setup is providing excellent results, but of course its not using the Theengs Decoder. I am hoping to use the Theengs Decoder with a similar speed to the BLED112-device.
I mean that the broker is not receiving any message from the Theengs Bridge for at least 20 seconds. This happens a lot when I put the scanduration parameter to 30000.
As far as I understand this is caused by the Theengs Bridge scanning for 30 seconds before sending the messages to the broker. This would work fine if I was collecting sensor information that is not time critical. But in my case I am using also using it to check if devices are arriving home. Every second counts if you are in the rain outside waiting for the garage door to open.
I put the scanduration parameter back to 1000 and now these periods of inactivity (20 seconds) happen just a couple of times a day.
With the Theengs Bridge, I hope to reach the point that we see no periods of inactivity during a day, and I hope to receive messages every second. In my house, and the surroundings, there are many bluetooth devices always advertising every few seconds, so there is plenty of data to communicate.
Just an update, it is still in testing. Even if we have improved the message delivery performances to be very fast but there is still some issues to tackle. I will update you.