Guess those who know it already don't feel an obligation to actually read the whole thing. Not to be unduly harsh, but is it too much to expect that prior to making a comment, one should RTFA?
Thank you comment police.
It wasn't enough for one person to tell me I was wrong... you also felt the need correct me.
[CONTENTEMBED=/t/181347/apples-first-ibeacon-hardware-revealed-in-fcc-application#post_2563509 layout=inline]The app is HomeKit.[/CONTENTEMBED]
Status monitoring: Some inexpensive iBeacons are quite intelligent. They can measure temperature, moisture, humidity, movement, etc -- and send that information to a central HomeKit Controller.
So iBeacons can have WiFi and be connected to a network? I did not know that. Do you have any links to these intelegent iBeacons?
I'm not sure he is correct in his phrasing. Bluetooth LE Beacons can transmit data in the beacon signal. There are many on the market that can do this. Apple's iBeacon data format does not really support that. It only sends two numbers and a beacon GUID. The numbers allow for relevant information to the app. You could have a beacon stuff real-time data in those fields, but I have not seen one that does that. They would normally be something like Store # and department in a retail example. The Bluetooth LE Beacons of course just send the data via BT and don't typically connect via Wifi.
To expand on my original assertion: "Status monitoring: Some inexpensive iBeacons are quite intelligent. They can measure temperature, moisture, humidity, movement, etc -- and send that information to a central HomeKit Controller."
You are correct that when acting as an Apple-defined iBeacon, a BLE device conforms to the Apple-defined iBeacon protocol. The device broadcasts a 128-bit UUID (unique identifier) and two 16-bit (sub identifiers denoted as major and minor). A total of 20 bytes. An iBeacon normally broadcasts once per second.
These identifier fields are required but their meaning is discretionary. They are set by the iBeacon deployer and usually define things like
Retail Stores:
UUID -- company -- Apple, Nordstroms, Olive Garden
major -- store number
minor -- department/aisle
The above is a commonly-suggested (default) usage -- where there are many different companies within an area like a mall. An iDevice can listen for up to 20 concurrent iBeacons. The way this would normally work is the user would fire up, say, an app for Nordstroms which would ask if you wanted to "be notified" (listen for) when you approach a Nordstroms store. If yes, then the app would create a listen request. * The listen request gets pushed down into the iDevice's OS and radio where all the listeners are aggregated. The user might repeat the process for each "company's store" he wants to listen for. (The iDevice receives the broadcasts of any beacons within range -- but ignores those that it is not listening for.
* Likely, this request would only listen for the Nordstroms UUID with major/minor as wildcards -- as the app recognizes that you want any nearby Nordstroms store -- rather than a particular Nordstroms store/department/aisle
Alternately, Nordstroms could have an unique UUID assigned for each store -- realizing that you can only be near one Nordstroms store, the app would contain a list of all the Nordstroms stores and pick the one closest to your current location.
By doing this, the iBeacons in the Nordstroms store would not need to broadcast store number in the major field, and they could use that field to broadcast nearby specials, etc.
But, Nordstroms could be really creative:
deploy iBeacons near the store entrances/exits/parking lots -- that broadcast the Nordstroms UUID.
deploy iBeacons within the store -- that use a totally different identifier scheme UUID/msjor/minor scheme
Nordstroms (and it's app) know that you are in the store -- so the app can now listen for any additional information that makes sense -- specials, bathrooms, temperature, longitude/latitude ...
So, these instore iBeacons could broadcast their geolocation (set when the iBeacons were deployed). Then the Nordstroms app could display a map/layout of the store showing where you are and assist you in navigating through the store.
All this accomplished by creatively using the existing iBeacons protocol
Below, are variations on a theme on how custom iBeacon identifier schemes could be used for various needs:
Hospitals/Campuses
UUID -- Building
major -- Floor
minor -- Room
Airports
UUID -- Terminal
major -- Runway
minor -- Gate
Home
UUID -- Room
major -- whatever
minor -- whatever
OK, to get back on topic ...
Let's discuss how an iBeacon could act as a motion detector within the home.
Home
UUID -- Room / motion detector
major -- timestamp/count
minor -- timestamp/count
The UUID is static, but the timestamp (major/minor) fields could change whenever a morion is detected (remember the 1-second broadcast interval). How could it do this?
The iBeacon device:
has the iBeacon identifier fields (UUID, major, minor) stored on the device
the identifier fields are set when the device is deployed and can be changed at anytime
In addition to running the iBeacon broadcast protocol it also runs the lower-level BLE protocol
has various sensors and runs runs an OS on an ARM CPU
in can be programmed to do something when a sensor senses something
in our case , when it detects a motion via an IR sensor
To satisfy the our iBeacon motion detector needs, all the device program has to do is change the timestamp/count fields whenever a motion is detected. The next beacon broadcast will contain different timestamp/count fields. An iDevice or HomeKit controller app listening for this will receive a notification!
For those of you who think that doing things like this will stress the abilities of the iBeacon devices hardware and software -- you are wrong. Many of these devices were prototyped on raspberry class computers -- and have the capability of running Linux, php, etc. That little iBeacon is more powerful than the original Mac.
Below are some links to the Texas Instruments SensorTag -- a $25 (retail) device that can be used as an iBeacon. All of the sensor information is available to an app running on an iDevice or a HomeKit controller.
The Bluetooth SensorTag packs the following sensor:
Contactless IR temperature sensor (Texas Instruments TMP006)
Humidity Sensor (Sensirion SHT21)
Gyroscope (Invensense IMU-3000)
Accelerometer (Kionix KXTJ9)
Magnetometer (Freescale MAG3110)
Barometric pressure sensor (Epcos T5400)
On-chip temperature sensor (Built into the CC2541)
So sorry to offend you. I understand. People who tend to interrupt others from finishing their sentences also tend to resent somebody calling them out on their behavior. I'll try to be more mindful of your personality and temperament in the future.
So sorry to offend you. I understand. People who tend to interrupt others from finishing their sentences also tend to resent somebody calling them out on their behavior. I'll try to be more mindful of your personality and temperament in the future.
No offense taken.
I just find it odd that out of a dozen people reading this thread... one person was able to answer my question with no problem... but two people actually had to show me how wrong I was.
That was some useful information. What appears to have been done here is that the existing SensorTag device, which has all the sensors, now has iBeacon, but there is apparently no direct connection between the sensor information and the iBeacon. The iBeacon could give you a push and then you launch the app to query the sensor data. It is like two separate devices in one. You can now upgrade an existing SensorTag to also be an iBeacon. See the video:
The thing in this video I don't understand is the part about placing a SensorTag in each box when you move so you can track your boxes in transit using your smartphone. This is a mystery to me as I do not understand how a SensorTag in a moving truck out on the road is able to communicate without another smartphone running an app near the boxes. Of course the smartphone would run out of battery pretty quickly if it were just along for the ride in one of the boxes.
That was some useful information. What appears to have been done here is that the existing SensorTag device, which has all the sensors, now has iBeacon,
Yes, the program on the SensorTag now broadcasts iBeacon packets in addition to sending/receiving/scheduling BLE packets.
but there is apparently no direct connection between the sensor information and the iBeacon.
Except that both activities are parts of a program sharing the hardware on the device. The SensorTag has an SDK, so you could write a SensorTag program that, say, reads the accelerometer and puts that into the minor field of the iBeacon broadcast packet.
The iBeacon could give you a push and then you launch the app to query the sensor data. It is like two separate devices in one.
Yes, you can do that too, in a single app ... There are considerations, though -- when you connect to ask for BLE sensor data, the requestor blocks other Other BLE request until disconnect. AFAIK, iBeacon broadcasts continue uninterrupted
I wanted to equate the dual BLE/iBeacon capability to a car with a shiftable automatic transmission -- but that's a bad example
You can now upgrade an existing SensorTag to also be an iBeacon. See the video:
The thing in this video I don't understand is the part about placing a SensorTag in each box when you move so you can track your boxes in transit using your smartphone. This is a mystery to me as I do not understand how a SensorTag in a moving truck out on the road is able to communicate without another smartphone running an app near the boxes. Of course the smartphone would run out of battery pretty quickly if it were just along for the ride in one of the boxes.
Yeah, aside from visual overload, the bit about about tracking boxes was a little far out (this coming from me) ...
Many trucking lines track their trailers via a device with gps and cell on the trailer -- the drivers don't like it.
Likely, some moving companies use similar devices to track their trailers. It appears that at least one extends that service to the customer.
Track Your Shipment
Allied recognizes the value of your belongings. In order to keep our customers informed about the whereabouts of their shipments, Allied has implemented an online shipment tracking feature. From here you can check the current status of your shipment anytime, 24 hours a day, seven days a week. The information provided includes the load date, present location and delivery date for corporate account relocations, household goods shipments and specialized shipments.
But, likely, that's just tracking the trailer -- not your specific load and boxes. That'd be fine if you were the only load on the trailer.
But, often there will be multiple loads from different customers sharing a trailer. And as other loads are added or removed (delivered, put in storage, etc.), some boxes from your load could be lost.
The mover could provide the service described in the video, by adding iBeacon capability to the existing trailer tracking device -- or just carry an iPhone or iPad, Then, track the whereabouts of every iBeacon-taged box.
One nice feature of the iBeacon protocol, is that you get a notification when an iBeacon goes in or out of range -- so the driver could be alerted, within 2-3 minutes, that a box is missing, and rectify the situation.
The $25 TI SensorTag is overkill -- 100 boxes == $2,500 -- soon, I suspect we'll see iBeacons costing only a few $
I suppose a savvy mover could offer the service, provide the iBeacons for a deposit , then refund the deposit upon return of the iBeacons.
Insurance companies might also be interested in this technology.
Ha! Running the SensorTag app on my iPad, I see the usual iBeacon suspects ... But, also my AppleTV (3rd gen) ... and someone nearby has a Gear 2
Except that both activities are parts of a program sharing the hardware on the device. The SensorTag has an SDK, so you could write a SensorTag program that, say, reads the accelerometer and puts that into the minor field of the iBeacon broadcast packet.
I don't think you can do that. Writing an app does not change the behavior of the SensorTag firmware which is just sending out regular iBeacon identifiers. I would be surprised if the interface for programming of the SensorTag would allow you to do that. I can't see it being part of the SDK because that only applies to the app running on the smartphone. To get the data from the sensor and send it to the iBeacon is not likely, but it is not necessary either because the app can query the senor data anyway. I don't think the Sensor tag is sending data to the Internet which is why I found the trucking example curious. I could be wrong, but I don't think you can include a WiFi too along with everything else for only $25. If you have to be in range to query the data it is less practical. Like, if you have to go to a room to find out how hot it is and when you get there you say wow, it feels hot in here.
[CONTENTEMBED=/t/181347/apples-first-ibeacon-hardware-revealed-in-fcc-application/40#post_2563859 layout=inline]Except that both activities are parts of a program sharing the hardware on the device. The SensorTag has an SDK, so you could write a SensorTag program that, say, reads the accelerometer and puts that into the minor field of the iBeacon broadcast packet.[/CONTENTEMBED]
I don't think you can do that. Writing an app does not change the behavior of the SensorTag firmware which is just sending out regular iBeacon identifiers. I would be surprised if the interface for programming of the SensorTag would allow you to do that. I can't see it being part of the SDK because that only applies to the app running on the smartphone. To get the data from the sensor and send it to the iBeacon is not likely, but it is not necessary either because the app can query the senor data anyway. I don't think the Sensor tag is sending data to the Internet which is why I found the trucking example curious. I could be wrong, but I don't think you can include a WiFi too along with everything else for only $25. If you have to be in range to query the data it is less practical. Like, if you have to go to a room to find out how hot it is and when you get there you say wow, it feels hot in here.
You've kinda got me spinning ... not your fault though!
I wanted to show you some before and after shots proving that it can be done!
I haven't worked on any BLE or iBeacon stuff for several months ...
In the meantime I've installed Yosemite on my main iMac and iOS 8 on my main iPhone and Main iPad, and am using Xcode 6 Beta 3 and iTunes Beta.
All my BLE and iBeacon apps won't run on these versions of iOS, OS X, XCode and iTunes.
The SensorTag firmware update that adds iBeacon support would not work -- the SensorTag app just crashed.
I dug out an older iPad 3 running iOS 7 -- the SensorTag Firmware update installed fine!
But, Xcode and iTunes do not see this old iPad ...
We have some iPad 2s and an iPad 1 -- but they don't support BLE.
I could reboot to a Mavericks OS, running older iTunes and Xcode -- but it it is currently inconvenient to do so!
Whew!
Let me see if I can logically talk you through it -- to prove it can be done. When you initially get an Beacon device (SensorTag, Estimate, StickNFine, etc.) the Beacon broadcast settings (UUID, Major, Minor) are in an unusable state -- either unknown or arbitrarily set by the manufacturer.
Here's what the iBeacon deployer must do to make the iBeacon useable:
get a UUID -- generate one with Terminal or get a database-backed one from a web site service (likely common for all your iBeacons)
decide on the major and minor values (likely an unique combination to specifically identify each iBeacon)
install the unique UUID, major, minor broadcast packet on each potential iBeacon device
initiate iBeacon packet broadcasting on the potential Beacon device
verify that each potential iBeacon device broadcasts the correct packet
verify that you can correctly listen for and receive notifications when any of your potential iBeacons are detected -- with various combinations of major, minor and wild cards
Step 3 is done with an app running on your iDevice using BLE protocol -- you can't write to an iBeacon, but you can write to a BLE device to tell it what to broadcast when it is performing as an iBeacon
Step 4 is the first time that the device is performing as an iBeacon
Steps 5 and 6 check that everything is working properly -- if not, rinse and repeat from step 3
You could use separate iDevice apps for the BLE and iBeacon steps -- but in reality, it will be a single app that runs both BLE protocol for setup and iBeacon for testing. In fact, you can use a single app running on a single (or multiple) iDevice to test the whole process before you get any potential iBeacon devices .
The iBeacon deployers use this app as they will need it to install, remove, move iBeacons over time. .
OK, If you are with me so far, I think you'll agree that a potential iBeacon device becomes a valid iBeacon device because it has the ability to run BLE and iBeacon at the same time!
Your point: "Writing an app does not change the behavior of the SensorTag firmware which is just sending out regular iBeacon identifiers." really doesn't apply -- yeah, the firmware is sending out iBeacon identifiers retrieved from storage on the device. The identifier information can be changed at any time by an app using BLE. The firmware doesn't care or need to be changed. The iBeacon software on the device is just restarted, gets the new identifiers and passes that to the firmware for broadcasting.
To close the loop on the motion sensor, the software on the iBeacon device could easily check for a change in the motion sensor status * (time or counter) and whenever it changes change the iBeacon identifier to reflect that ... Done crudely, this would restart the iBeacon as above -- going offline for a second. No big deal, but I think it can be done without a restart by changing RAM as well storage.
* Most of this programming already exists on the device as you can use a BLE app on your iDevice to set, calibrate and monitor changes to the sensors,
Not all beacons are connected to Wi-Fi, there are a few that are. These are called “Connected beacons”. These devices use built-in Wi-Fi to connect to internet. Examples: Paypal and Cloud Beacons. While Paypal is used for contactless payments, Cloud beacons are used for data collection, transmission and receipt of over-the-air information for entire deployments. You can read more here: https://www.linkedin.com/pulse/article/20140929042305-116167892-have-you-heard-of-the-beacon-r-evolution?
Comments
Thank you comment police.
It wasn't enough for one person to tell me I was wrong... you also felt the need correct me.
A full day later too. Congrats.
To expand on my original assertion: "Status monitoring: Some inexpensive iBeacons are quite intelligent. They can measure temperature, moisture, humidity, movement, etc -- and send that information to a central HomeKit Controller."
You are correct that when acting as an Apple-defined iBeacon, a BLE device conforms to the Apple-defined iBeacon protocol. The device broadcasts a 128-bit UUID (unique identifier) and two 16-bit (sub identifiers denoted as major and minor). A total of 20 bytes. An iBeacon normally broadcasts once per second.
These identifier fields are required but their meaning is discretionary. They are set by the iBeacon deployer and usually define things like
Retail Stores:
The above is a commonly-suggested (default) usage -- where there are many different companies within an area like a mall. An iDevice can listen for up to 20 concurrent iBeacons. The way this would normally work is the user would fire up, say, an app for Nordstroms which would ask if you wanted to "be notified" (listen for) when you approach a Nordstroms store. If yes, then the app would create a listen request. * The listen request gets pushed down into the iDevice's OS and radio where all the listeners are aggregated. The user might repeat the process for each "company's store" he wants to listen for. (The iDevice receives the broadcasts of any beacons within range -- but ignores those that it is not listening for.
* Likely, this request would only listen for the Nordstroms UUID with major/minor as wildcards -- as the app recognizes that you want any nearby Nordstroms store -- rather than a particular Nordstroms store/department/aisle
Alternately, Nordstroms could have an unique UUID assigned for each store -- realizing that you can only be near one Nordstroms store, the app would contain a list of all the Nordstroms stores and pick the one closest to your current location.
By doing this, the iBeacons in the Nordstroms store would not need to broadcast store number in the major field, and they could use that field to broadcast nearby specials, etc.
But, Nordstroms could be really creative:
Nordstroms (and it's app) know that you are in the store -- so the app can now listen for any additional information that makes sense -- specials, bathrooms, temperature, longitude/latitude ...
So, these instore iBeacons could broadcast their geolocation (set when the iBeacons were deployed). Then the Nordstroms app could display a map/layout of the store showing where you are and assist you in navigating through the store.
All this accomplished by creatively using the existing iBeacons protocol
Below, are variations on a theme on how custom iBeacon identifier schemes could be used for various needs:
Hospitals/Campuses
Airports
Home
OK, to get back on topic ...
Let's discuss how an iBeacon could act as a motion detector within the home.
Home
The UUID is static, but the timestamp (major/minor) fields could change whenever a morion is detected (remember the 1-second broadcast interval). How could it do this?
The iBeacon device:
To satisfy the our iBeacon motion detector needs, all the device program has to do is change the timestamp/count fields whenever a motion is detected. The next beacon broadcast will contain different timestamp/count fields. An iDevice or HomeKit controller app listening for this will receive a notification!
For those of you who think that doing things like this will stress the abilities of the iBeacon devices hardware and software -- you are wrong. Many of these devices were prototyped on raspberry class computers -- and have the capability of running Linux, php, etc. That little iBeacon is more powerful than the original Mac.
Below are some links to the Texas Instruments SensorTag -- a $25 (retail) device that can be used as an iBeacon. All of the sensor information is available to an app running on an iDevice or a HomeKit controller.
http://newscenter.ti.com/2014-04-16-TI-supports-iBeacon-technology-across-TIs-Bluetooth-Smart-dual-mode-and-combo-connectivity-portfolio
http://processors.wiki.ti.com/index.php/SensorTag_User_Guide
No offense taken.
I just find it odd that out of a dozen people reading this thread... one person was able to answer my question with no problem... but two people actually had to show me how wrong I was.
I feel special
http://newscenter.ti.com/2014-04-16-TI-supports-iBeacon-technology-across-TIs-Bluetooth-Smart-dual-mode-and-combo-connectivity-portfolio
That was some useful information. What appears to have been done here is that the existing SensorTag device, which has all the sensors, now has iBeacon, but there is apparently no direct connection between the sensor information and the iBeacon. The iBeacon could give you a push and then you launch the app to query the sensor data. It is like two separate devices in one. You can now upgrade an existing SensorTag to also be an iBeacon. See the video:
The thing in this video I don't understand is the part about placing a SensorTag in each box when you move so you can track your boxes in transit using your smartphone. This is a mystery to me as I do not understand how a SensorTag in a moving truck out on the road is able to communicate without another smartphone running an app near the boxes. Of course the smartphone would run out of battery pretty quickly if it were just along for the ride in one of the boxes.
Yes, the program on the SensorTag now broadcasts iBeacon packets in addition to sending/receiving/scheduling BLE packets.
Except that both activities are parts of a program sharing the hardware on the device. The SensorTag has an SDK, so you could write a SensorTag program that, say, reads the accelerometer and puts that into the minor field of the iBeacon broadcast packet.
Yes, you can do that too, in a single app ... There are considerations, though -- when you connect to ask for BLE sensor data, the requestor blocks other Other BLE request until disconnect. AFAIK, iBeacon broadcasts continue uninterrupted
I wanted to equate the dual BLE/iBeacon capability to a car with a shiftable automatic transmission -- but that's a bad example
Yeah, aside from visual overload, the bit about about tracking boxes was a little far out (this coming from me) ...
Many trucking lines track their trailers via a device with gps and cell on the trailer -- the drivers don't like it.
Likely, some moving companies use similar devices to track their trailers. It appears that at least one extends that service to the customer.
http://www.allied.com/track-your-shipment.aspx
But, likely, that's just tracking the trailer -- not your specific load and boxes. That'd be fine if you were the only load on the trailer.
But, often there will be multiple loads from different customers sharing a trailer. And as other loads are added or removed (delivered, put in storage, etc.), some boxes from your load could be lost.
The mover could provide the service described in the video, by adding iBeacon capability to the existing trailer tracking device -- or just carry an iPhone or iPad, Then, track the whereabouts of every iBeacon-taged box.
One nice feature of the iBeacon protocol, is that you get a notification when an iBeacon goes in or out of range -- so the driver could be alerted, within 2-3 minutes, that a box is missing, and rectify the situation.
The $25 TI SensorTag is overkill -- 100 boxes == $2,500 -- soon, I suspect we'll see iBeacons costing only a few $
I suppose a savvy mover could offer the service, provide the iBeacons for a deposit , then refund the deposit upon return of the iBeacons.
Insurance companies might also be interested in this technology.
Ha! Running the SensorTag app on my iPad, I see the usual iBeacon suspects ... But, also my AppleTV (3rd gen) ... and someone nearby has a Gear 2
I don't think you can do that. Writing an app does not change the behavior of the SensorTag firmware which is just sending out regular iBeacon identifiers. I would be surprised if the interface for programming of the SensorTag would allow you to do that. I can't see it being part of the SDK because that only applies to the app running on the smartphone. To get the data from the sensor and send it to the iBeacon is not likely, but it is not necessary either because the app can query the senor data anyway. I don't think the Sensor tag is sending data to the Internet which is why I found the trucking example curious. I could be wrong, but I don't think you can include a WiFi too along with everything else for only $25. If you have to be in range to query the data it is less practical. Like, if you have to go to a room to find out how hot it is and when you get there you say wow, it feels hot in here.
You've kinda got me spinning ... not your fault though!
I wanted to show you some before and after shots proving that it can be done!
I haven't worked on any BLE or iBeacon stuff for several months ...
In the meantime I've installed Yosemite on my main iMac and iOS 8 on my main iPhone and Main iPad, and am using Xcode 6 Beta 3 and iTunes Beta.
All my BLE and iBeacon apps won't run on these versions of iOS, OS X, XCode and iTunes.
The SensorTag firmware update that adds iBeacon support would not work -- the SensorTag app just crashed.
I dug out an older iPad 3 running iOS 7 -- the SensorTag Firmware update installed fine!
But, Xcode and iTunes do not see this old iPad ...
We have some iPad 2s and an iPad 1 -- but they don't support BLE.
I could reboot to a Mavericks OS, running older iTunes and Xcode -- but it it is currently inconvenient to do so!
Whew!
Let me see if I can logically talk you through it -- to prove it can be done. When you initially get an Beacon device (SensorTag, Estimate, StickNFine, etc.) the Beacon broadcast settings (UUID, Major, Minor) are in an unusable state -- either unknown or arbitrarily set by the manufacturer.
Here's what the iBeacon deployer must do to make the iBeacon useable:
Step 3 is done with an app running on your iDevice using BLE protocol -- you can't write to an iBeacon, but you can write to a BLE device to tell it what to broadcast when it is performing as an iBeacon
Step 4 is the first time that the device is performing as an iBeacon
Steps 5 and 6 check that everything is working properly -- if not, rinse and repeat from step 3
You could use separate iDevice apps for the BLE and iBeacon steps -- but in reality, it will be a single app that runs both BLE protocol for setup and iBeacon for testing. In fact, you can use a single app running on a single (or multiple) iDevice to test the whole process before you get any potential iBeacon devices .
The iBeacon deployers use this app as they will need it to install, remove, move iBeacons over time. .
OK, If you are with me so far, I think you'll agree that a potential iBeacon device becomes a valid iBeacon device because it has the ability to run BLE and iBeacon at the same time!
Your point: "Writing an app does not change the behavior of the SensorTag firmware which is just sending out regular iBeacon identifiers." really doesn't apply -- yeah, the firmware is sending out iBeacon identifiers retrieved from storage on the device. The identifier information can be changed at any time by an app using BLE. The firmware doesn't care or need to be changed. The iBeacon software on the device is just restarted, gets the new identifiers and passes that to the firmware for broadcasting.
To close the loop on the motion sensor, the software on the iBeacon device could easily check for a change in the motion sensor status * (time or counter) and whenever it changes change the iBeacon identifier to reflect that ... Done crudely, this would restart the iBeacon as above -- going offline for a second. No big deal, but I think it can be done without a restart by changing RAM as well storage.
* Most of this programming already exists on the device as you can use a BLE app on your iDevice to set, calibrate and monitor changes to the sensors,
- Now home automation can track your every move with your iDevice in your pocket.
Possibly/Probably with built-in microphone for Minority Report style home automation (i.e. True hands-free speaking to your house).
That's my guess - And been waiting for it for a while. Not a matter of 'if', but 'when'.
Not all beacons are connected to Wi-Fi, there are a few that are. These are called “Connected beacons”. These devices use built-in Wi-Fi to connect to internet. Examples: Paypal and Cloud Beacons. While Paypal is used for contactless payments, Cloud beacons are used for data collection, transmission and receipt of over-the-air information for entire deployments. You can read more here: https://www.linkedin.com/pulse/article/20140929042305-116167892-have-you-heard-of-the-beacon-r-evolution?