Feature proposal: sitemap selected based on which Bluetooth beacons are nearby.

[Br3nda]

An android device can determine location within a building using eddystone, or some other Bluetooth beacon technology. Would a feature to change sitemap based on a which room you are in be welcome in the codebase? Any preference to particular standards? I'm pretty keen to play with eddystone.

[digitaldan]

Your timing is great! See https://github.com/openhab/openhab.ios/pull/82. , it would be awesome to do something similar with android using beacons.

[Br3nda]

choice.. I will hit alieexpress for some eddystones.

[fspiekermann]

I am currently writing my bachelor thesis, and it is exactly about this topic! Its title is (translated) “Location based filtering and automatisation in Smart Home environments through the example of openHAB” and will be finished by begin of January. As part of this thesis, I will provide a solution for indoor localization for openHAB with beacons. At the end it should be possible to filter the shown devices and maybe get an interface for rules to switch devices when you are near. To get this functionality, I want to use the openHAB Android App and iBeacons. The iBeacons would be stored in an openHAB binding. In this binding there could also be stored how many persons are nearest to a specific beacon, according to the number of nearest persons it could be possible to write rules in openHAB. I would like to contribute my solution and discuss concrete requirements with you in this issue.

[digitaldan]

@Spieki that sounds great, your work would be most welcome. In order to keep the client single focused and not tied directly to any one binding, I would recommend something similar to how NFC support works in the app. Here you tie a NFC tag to some element in a sitemap, beacons could work similarly where you could tie a beacon to a sitemap page (I walk into the kitchen and my app knows to display the Kitchen page) or tie a beacon directly to an item ( I walk into the Kitchen and the switch "Kitchen_Beacon" turns on, which then executes a rule). Thoughts?

[fspiekermann]

I thought about it the last hours. My first idea was to hold the functionality in the app, too. But after some researches I saw some problems with it. Its beginning with, that the most of the beacons have to configure over a third Party application, but after an installation session, it would not been any problem. But there I see some problems more. If you look for example at iBeacons, there will no chance to save an event in the beacon like you can program a NFC-Tag. This is because of the definition of iBeacons, they are send only an ID and the app has to decide what happen in near of the beacon. So somewhere have to be stored the beacons. Perhaps there is a chance to use Eddystone-Beacons, but there is a limitation of 17 Bytes for the output. Maybe next Year with Bluetooth 5 it will be easier, when the package Size gets bigger, but at the moment I think there is a better use of an Instance where the beacons can be saved. At this instance there will be the possibility to give them advantage Informations, too. The next Point is, if you use the beacons only with the app, there will be in the most cases a limitation of one action per beacon. At the prices of beacons, it will be more expensive to build a location based automation, as with NFC-Tags. I thought about to place only one beacon per room, so there will only be a relative Location Combining both points there will be more benefit to save the beacons in openHAB and implement a counter, how many persons are nearest to this beacon. On the one Hand there is the possibility to change the sitemap in the app belonging to the informations stored for the beacon. On the other hand, rules can be created to automate the whole House with one beacon. If the counter is used, there is a greater guaranty, that the light will not turning off if someone leaves the room and another person is still in the room, because of the counter greater than zero. Another nice fact is, that it will be possible to create actions for every amount of persons in the room. Like one Person the Light turns on, two persons the light will become red, three persons the light will become green and so on. Another example is, that the heater will turn off, if too many peoples are in the room. If this is ok, i would build it on a way, that the location only can be used if the binding is installed. It would be nice, if the user can install the binding via this app. The beacon installation in the app, will be no big problem.

[kaikreuzer]

I agree with @digitaldan that there should be no need for any binding on the runtime, this simply does not make sense from an architecture point of view.

I think we are talking about different use cases here anyhow and should discuss them separately:

1. What is stated in this issue title: "sitemap selected based on which Bluetooth beacons are nearby" Here the user actively does something (opening the app on the phone) and at that moment, the app checks for beacons around it and opens a preconfigured page. This could be fully built into the app and it would be completely transparent to the runtime (which doesn't have to know anything about locations and beacons). It could be a new context menu entry in the app for a currently display page saying "always open this page at the current location", which will make the app scan for beacons and store the id of the strongest one. The difference to the NFC mechanism would be that the information is not stored in the beacon, but in the app (so it needs to be done on every phone separately), but I'd think this is acceptable.
2. Track a user's location: Here, the phone simply become an external sensor for data (=location). It should provide this data even if the app is not launched (i.e. silently in the background). Such a feature is actually not specific to beacons; you can also say that the GPS coordinates could be used for such use cases. So beacons would only be another way of providing more suitable information for indoor localisation (i.e. rather relative than absolute information). ESH comes with the LocationItem for this. As data, it currently only supports geo-coordinates, so for relative locations, this would need to be extended in a suitable way. The issue to discuss such topics is https://github.com/eclipse/smarthome/issues/582.

I would think (1) should be fairly easy for you to implement. (2) is probably a bit challenging within the given timeframe until early January.

[fspiekermann]

Thanks @digitaldan and @kaikreuzer, you got me some new ideas.

I will try to implement the first use case in the next days. I see this has its own advantages compared to my first idea.

I am going to think about extending Eclipse SmartHome, as described in the second use cse, after my bachelor thesis.