It’s easy to get confused about what Ibeacons are, because they’re sort of the opposite of what we’re used to dealing with sensors. But once you get the basic concept, everything else gets a lot clearer.
The Lighthouse Analogy
The usual example is to think of an IBeacon as a lighthouse. All it does is send out its light in a particular pattern. The lighthouse itself doesn’t know whether there are any ships nearby or not. And it doesn’t care if there any ships nearby or not. 
The lighthouse will not change its behavior based on whether a particular ship is nearby. It just does the same thing, over and over, all the time.
That’s the ibeacon. All it does is send out a little signal that identifies the IBeacon itself, over and over. No matter what other devices are nearby.
So the passing ship is a cellphone app
So in order to make use of this, you need a “receiving station” app. That has to be running on a Device with a Bluetooth antenna. So the receiving station detects the IBeacon’s signal when it is physically close enough to do so, and it is the receiving station app that can be programmed to do something differently based on which I Beacon it just detected. The IBeacon behavior never changes, but the receiving station app might well do different things for different Ibeacons.
So back to the lighthouse analogy, the receiving station app is the ship. The ship detects the beam from the lighthouse and makes its own decision as to whether it will go closer or farther away or turn around or whatever. Or use its own radio to send a message to someone else that it has now come within range of that particular lighthouse. 
Different receiving station apps will have different features in terms of what they can do when they detect a particular IBeacon. Some can send a text, some can tweet, some can do a HTTP post, some run their own particular program logic, etc.
The receiving station is a mobile app and it can do pretty much anything a mobile app can do, include contacting a cloud service, it just depends what the program has built-in. But note that just as the ship doesn’t speak back to the lighthouse, the receiving station app isn’t talking back to the Beacon. It’s just using the fact that it saw that particular lighthouse to then make decisions about what actions it should take.
So the IBeacon sends out a one-way message, over and over, whether anyone is there to receive it or not.
The receiving station app detects Ibeacons in its immediate vicinity, and based on the Beacon ID that it receives, it then triggers its own activities.
Same app, different phone
So in order for the same receiving station app installed on two different phones to behave differently when they each detect the same I beacon, it’s the receiving station app that has to have logic that that can store preferences and act on those preferences. Not only does the beacon not know the difference between one cell phone and the other, it doesn’t even know the difference between no cell phones in the area and some cell phones in the area. The beacon just keeps broadcasting its little “I am here” message over and over. Everything else is up to the receiving station app.
very short broadcast range
Strangely, the biggest advantage to Ibeacons for particular use cases is the fact that they have a very short broadcast range. some receiving station apps can be set to only act if and IBeacon is within about 4 inches. The maximum is about 30 feet. And there’s a useful range setting at about 10 feet.
This can let you solve the same kinds of problems as motion sensors. You can detect in a pretty confined area.
The difference is that a motion sensor is an active party. It detects something came into range and it is the sensor that then sends out a notification that it has detected something. But it doesn’t know just which something that is.
An ibeacon is a passive party. It sends out the same signal whether anything is nearby or not. But the receiving station app can recognize the specific Ibeacon that it just came within range of, and act differently based on that beacon’s ID. It’s not the Beacon detecting the phone and then doing something. It’s the phone app detecting the beacon and then doing something based on the specific Beacon that it detected.
The bus stop problem
So for example at my house, I want the front door to unlock for me and only me and only when I get to the base of the wheelchair ramp at my front door. But I don’t want it to unlock while I’m still on the bus. And I don’t want it to unlock for anyone else.
Obviously a motion detector could detect that someone was on the ramp, but it wouldn’t know it was me. And the SmartThings arrival sensor knew it was me, but was triggering while I was still waiting on the bus for the bus driver to operate the wheelchair lift.
The IBeacon broadcast range can be limited to a small enough area that my phone does not detect it until I actually get to the ramp. And because I have an app running on my phone that has my specific information stored in it, the door won’t unlock for anyone else. The receiving station app on my phone recognizes that I beacon, and it then sends a message to my home automation system to unlock the door.
So you can see how this is useful for many different needs. It’s not always quite as good as motion sensors once you’re inside the house, because the IBeacon signal goes through walls. So it’s pretty hard to define a “room” because you pick up the same signal in both the kitchen and the living room since it goes right through the wall. There are ways to deal with that, but they require more equipment and much more complicated receiving station apps.
But as far as zone detection, like Charlie just arrived in this particular area, the IBeacon can give you more range flexibility than most other technologies. 
But the Beacon itself is a very low power, very stupid passive device that just sends out its own ID over and over. Almost all the intelligence is in the receiving station app.