Scense 8 offers Location Services. How does it work? What is possible and what isn’t?
A first glance at the location configuration ‘tools’ in Scense Explorer does not immediately make things clear. There’s the ‘location levels manager’ and the ‘pattern matching manager’ and with a bit of clicking around we can find the ‘location root’, but it doesn’t get clear on how to use them.
The Scense Administrator Guide sheds some light on the subject and describes a clear route on how to approach the location services, starting with the location definitions.
Step 1: Set the location levels
The location levels manager, which can be opened from the ribbon in the system tab, shows 12 hierarchical levels of location types from Global to Desk. Some of the levels are checked, others are not, and there seems to be a possibility to choose custom names for the levels.
The levels that are checked out-of-the-box are just a suggestion and can, of course, be changed.
It’s important to think about which levels will be appropriate for you and select them before you build the location tree. It’s easy to add a level afterwards, but removing one is not so easy.
In our example we use only 4 levels where the ‘Building’, ‘Floor’ and ‘Room’ levels are the important ones because we pretend to have 2 buildings with each 2 floors with 2 rooms on each floor. They’re all in one city so there’s no real need to add any more levels, with perhaps the exception of ‘Global’.
Step 2: Build the location tree
After we set the location levels the ‘location tree’ should be created. The location tree is a representation of the real-life locations. You can build the location tree under the location root within the Administrative Tools node in Scense Explorer, like this:
After we created the 1st floor we just copied and renamed it to save time. We did the same trick with the entire building structure. All our locations are represented by a ‘location object’ and the hierarchy looks ok, so let’s continue to step 3.
Step 3: Define the scope of a location
So we finished creating the definitions of our locations and now we have to create the link to the Scense runtime system. We need to tell the system how it can determine on which location a workstation resides. That’s where it might get complex because there needs to be a detectable difference in the locations. The Scense system should be able to notice when a computer is in Room 2 on the first floor of Building 1. In practice there are very few (often just 1) ways of detecting where a computer might be.
Fortunately in this example the administrator has created 2 separate DHCP scopes, one for each building. Computers in Building 1 get an IP-address in the 192.168.1.0 network and computers in Building 2 go in the 192.168.2.0 network. So now we have something detectable to keep the buildings apart.
To exploit this we can add a condition to the scope of both buildings.
If the above condition is true, it means that the computer is somewhere in Building 1 because it got an IP-address in the range for Building 1. If the computer is moved to the other building it will get an IP-address in the range for Building 2 and the similar condition in the scope for the Building 2 will tell Scense that the computer is now somewhere in Building 2.
While we have a fairly solid way of detecting in which building a computer is, we still have no clue on which floor or in which room it is… In most situations the IP-subnet is the only way of automatically detecting a location and dependent on the way IP-addresses are distributed we can create scopes for certain location levels, but that’s probably where it ends.
In part 2 we will explore the possibilities for achieving greater accuracy.