Open laurijamsa opened 1 year ago
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)"
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.
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
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:
Things to consider:
Not so important, but maybe a future add-on: