New feature: Range extender (relay) mode

[laurijamsa]

The idea is to give Ruuvi Gateway an ability to act as a Bluetooth beacon range extender by simply relaying Bluetooth advertisements it receives.

Some of the pros:

• Range extender Ruuvi Gateways don't require internet connectivity -> easy installation
• Backend receives less traffic -> cost savings
• Lower backend complexity is required because no need to discard duplicates

Things to consider:

• Could nRF52 handle everything while ESP32 would be just sleeping?
• Should Ruuvi Gateway work automatically in the extender mode with default settings if no network connectivity available? This would make it really simple to use a Gateway in range extender mode as user would need just to power on the Gateway and that's it.
• Ruuvi Gateway operating in range extender mode should cache a certain number of the relayed messages to avoid pingpong if user has more than one Ruuvi Gateway operating in range extender modes (do not relay the exactly same message again). Or could the relayed advertisements have bits that would tell which messages are relayed ones?
• Need to check that MQTT users won't see unwanted duplicates

Not so important, but maybe a future add-on:

• Received coded PHY (Bluetooth long range) advertisements could be relayed as normal ones in order to allow normal receivers to see them

[laurijamsa]

Scrin: "A relay/extender mode would be useful for some, though the immediate concern I have is how would you handle loops if more than one relay/extender is used? The RSSI values would also become inconsistent if a tag is heard by both the "main gw" and the relay. One solution would be to have the extender/relay use some different form of relaying the messages rather than simply repeating, perhaps including a TTL value to prevent infinite relaying loops and to retain the "original" RSSI value from the relay, rather than the RSSI at the "main gateway" (which would be the RSSI of the relay, not the tag)"

[DG12]

Since the high order bit of the MAC address is always set ( top 2 actually) perhaps clearing the bit could be done by the "repeater" as a 'do_not_forward' flag and the "main gateway" could recognize the true MAC address.

[Scrin]

Using parts of the payload for "metadata" like that would make relaying dependent on the forwarded data format so I wouldn't recommend it.

One thought I had is that since power consumption itself is not a concern on the gateway, I suppose a somewhat persistent bluetooth connection (or directed advertisements as opposed to undirected ones?) could be used if the hardware allows for that without any notable degradation to receiving the broadcasts from tags. This would eliminate most size constraints and other limitations that apply to undirected advertisements only, which would make it trivial to include additional metadata such as the original advertisement RSSI value at the relay, and a TTL value if relaying should support multiple hops

Perhaps a gateway in relay mode could search for an active gateway that's in "gateway mode" during startup and then form a connection with it. This would also make it more feasible to implement additional features such as whitelisting entire relays, which could be useful in some setups or environments where multiple distinct "gateway users/setups" exist. A separate "gateway-to-gateway protocol" like this could even be further polished into a "ruuvi mesh" protocol or so