Its been a month since I wrote and started using iBeacon2Web. I must say it makes implementing detection and integration of iBeacons easier.
To start, I would need to describe what I am using the technology for. It’s mainly for 2 purposes.
- To track the location of some of my belongings and take certain actions
- to automate certain actions based on the state of my physical presence based on the location of my phone.
Based on this, I do have the following capabilities in my home.
- A web server running on the post 2011 Mac mini, and
- an iPhone 5 that is placed in a required location with iBeacon2web installed
- my mobile phone with iBeacon2Web installed
The purpose of the web server is to be able to run scripts that would serve as the end point of ibeacon2web and the iPhone 5 is to serve as the iOS device that would detect the beacons with ibeacon2web installed. A simple web endpoint is created filtering only the allowed deviceUUID to execute that script. This prevent unauthorized devices from being able to connect to my web endpoint. This UUID is generated on application install of ibeacon2web and can be obtained by looking at the help page. The CGI and a simple perl script is able to then record the state of the detected beacon and store it on the web server.
The process flow can be summarized to be:-
Beacon comes into range -> iPhone detects Beacon -> iBeacon2Web sends the URL to the defined end point -> End point filters the DeviceUUID -> CGI records the state into a simple DB
Once that was done, the web server simply takes over. As the web server is running on a Mac, it was trivial to use launchd as the mechanism to trigger server based actions based on changes in state. This trigger in launchd is then used to run scripts, for example, to turn my Belkin WeMo switches on or off. It can also generate a simple status report of the location of all my devices that has a beacon attached to it. For example, the location of my bicycles or bags.
The process summary is:-
DB state file changes -> launchd detects changes -> launchd runs a script -> script reads the DB and performs logic operations on the state and proximity of the beacons -> scrept performs other intended actions
Remember that each belonging is associated to a specific beacon and thus defines the “region” and the UUID of the item tagged with the beacon. I used a reverse dotted notation to help differentiate between my belongings and to build groups of the items. E.g. sulph.wheels.foldingbike vs Sulph.wheels.roadbike. The above works great for being able to discover if my belongings have been moved out of the house or have been returned. However, there is another angle to the use of iBeacon2web in which we are able to trigger specific actions in specific locations. For example, when you walk into a room.
When using iBeacon2web for specific region detection, the beacon is placed specifically in the area of interest, such as a room. We then make use of the “Near” and “Immediate” proximities to trigger an action. In this case, ibeacon2web is installed on my personal mobile phone (as opposed to a house phone in the earlier part of the post). The resulting endpoint for the web service remains the same and the CGI scripts would only trigger actions based on the right deviceUUID a as well as the right proximity states. I have used this to successfully turn screens on or off, or sending commands to other web services such as those on my Raspberry Pi for specific instructions to be carried out (such as telling me the weather).
Irrespective of whether the beacon is placed on my belongings or in a specific location, the mechanism is the same. The state of beacon detection gets recorded into a web server via ibeacon2web and a web CGI takes over in triggering the intended action.
This fulfills the goal of iBeacon2Web where, as long as you can script it on the server, you can make beacons work for you. This opens up a entire range of possibilities for web developers to be able to make use of this budding new technology and enhances their web services without having to resort to developing an iOS app just for a very specific use.
Hopefully this has made it much easier for other web developers to also leverage this technology and create something awesom too.
Till next time.
Sulphate Software 