So here is where it can get a little complicated and upon reflection I question whether the REST POST approach is the best.
There are lots of ways to get info into openHAB from reelyActive, both via a push or a pull. NOTE: Below is what would be best from an openHAB perspective, not necessarily easy or feasible from a reelyActive perspective.
The tl;dr is MQTT would probably be best.
The absolute best here would be to be able to publish a very simple "ON" or "OFF" to a separate URL per device. For example:
The big thing here is that the best way to set this up would be to allow a different URL per device. openHAB's rest API provides a different URL per Item and inside of openHAB one would want to have a separate Item to represent each BT device. So for example I would have:
I would want the events for RichPhone to go to http://localhost:8080//rest/items/RichPhone but the events for WifePhone to go to http://localhost:8080//rest/items/WifePhone.
To further complicate matters, I would want to receive an ON via a POST for "appearance", an ON via a PUT for "keep-alive" or "displacement", and an OFF via POST for a "disappearance".
This would provide the simplest integration from an openHAB perspective (though it does eliminate the potential to use the "displacement" event.
Alternatively one could set up a single incoming Item and then write a rule to parse out all the necessary information. So one would have:
In this case all events from reelyActive would go to http://localhost:8080//rest/items/reelyActive. NOTE: Notice how the last part of the URL corresponds to an OH user defined Item's name.
Then we would need a rule to parse the JSON and extract the device and event type and update the Phone switches as appropriate.
Personally, upon reflection, I find neither of these approaches satisfactory from an openHAB perspective. They both feel hacky and either neuter the full capability of reelyActive or impost a lot of work on the openHAB user.
This would be far more approachable from an openHAB perspective. We can subscribe to a single topic (or different ones if that floats your boat), parse out the data we need in our Item's binding and all without doing anything special or complicated with rules within OH or need to code anything (binding or Rules).
Similarly as simple to setup from an openHAB perspective would be an HTTP REST pull. openHAB can periodically poll a URL for updates out of the box and the data returned from a single pull can be farmed out to multiple Items. But polling, yuck. Plus I saw nothing in your architecture to imply that polling would be easy to support on your side.
I don't know if it is necessary in this case but a separate binding could be written for openHAB. This binding can open up the standard events URL and internally parse out the JSON and update openHAB Items bound to it.
This would provide a more seamless out of the box experience for openHAB users. However, if you are planning to implement MQTT anyway, personally I think that would give you more bang for your buck. We would just need to add an article with instructions for how to set it up on the wiki and we would be good to go without needing to add new code to openHAB and without imposing a lot of extra work on openHAB users.
That's my two cents anyway. I don't speak for the community over all.