2-way Communication with Raspberry Pi

[awolfe]

I’m looking to set up 2-way communication between a tag and a Raspberry Pi, triggered when the tag comes within range of the Pi. The Pi should send a message to the tag to turn on one of its LEDs, and continue to send that message as long as the tag is nearby. Once the tag is out of range and no longer receives the messages, it should turn the LED off. Additionally, I would like to take advantage of Eddystone-EID to keep everything secure.

To that end, here are some questions:

1. How can I send a message to turn on an LED?
2. Will I need to rewrite part of the firmware?
3. Can I still use Eddystone to take advantage of Eddystone-EID?
4. Is Eddystone even a 2-way protocol?
5. Can I mix-and-match protocols?
6. Can I use Eddystone-EID just for the beacon’s broadcast, and then send messages with another protocol?
7. Is Espruino the way to do it?
8. Can the ruuvitag_sensor Python package give me proximity data? I’m hoping to trigger everything when the tag is within a few meters of the Pi.

[otso]

Hello,

We’re working on GATT profile which allows for 2-way communication right now.
You can try out the prototype as presented in https://lab.ruuvi.com/iota/.

Proposal for messaging protocol is available at https://github.com/ruuvi/ruuvi-sensor-protocols/blob/master/ruuvi-endpoints.md, please let me know how it fits in your use case.

To answer the questions:

How can I send a message to turn on an LED?
Will I need to rewrite part of the firmware?
Can I still use Eddystone to take advantage of Eddystone-EID?
Is Eddystone even a 2-way protocol?
Can I mix-and-match protocols?
Can I use Eddystone-EID just for the beacon’s broadcast, and then send messages with another protocol?
Is Espruino the way to do it?
Can the ruuvitag_sensor Python package give me proximity data? I’m hoping to trigger everything when the tag is within a few meters of the Pi.

1. You’ll need to send an actuation message as described in the protocol. The actuation messages are not implemented yet, but if you’re eager to try it out I can bump it up on my todo list. Ask me again with the tag @otso if you do not hear a follow-up in a few weeks.
2. Possibly, if you’re willing to help with the protocol implementation you could take a look at temperature handler and implement similar LED handler. Endpoints are defined in llibraries folder: https://github.com/ruuvi/ruuvitag_fw/tree/driver-improvement/libraries/ruuvi_sensor_formats.
3. With this firmware, not really. If you want to use Eddystone-EID you’d need to implement the changes on to of Eddystone firmware. Essentially you’d need to add a custom service to Eddystone program, as changing Eddystone service itself would invalidate the Eddystone certification.
4. Eddystone hsa configuration protocol which is 2-way. Eddystone broadcasts are 1-way.
5. Yes, but please add a custom service rather than modifying existing standard. A Bluetooth profile can contain many services, such as Eddystone Configuration service and Led configuration service.
6. yes, and that would be recommended
7. Probably not, Espruino is not Eddystone-certified and I don’t think a full Eddystone implementation would fit into Espruino with the RAM and Flash available on RuuviTag. If you do not need a compliant Eddystone configuration service, maybe. The Eddystone crypto implementation would probably require a lot of work, though.
8. You can get the RSSI, which is not exactly proximity data but can give a rough guess of when a tag is nearby.