This idea came from following atamariya's work on CUE:
http://talk.maemo.org/showthread.php?t=81331

He is developing an application to emit an alarm at a location based on cellid based positioning to consume less power. It has a configurable radius for the alarm via the user interface. I was thinking that this was clever, because that location data should even if coarse be good enough via the radius setting to make it much more flexible: as it matured, the action could be selectable as an alarm, or a profile change, or even execution of a command-line function. For example, a profile could be set to silent when at a library, hospital, lecture hall, etc., & back to general at the parking lot.

What would be excluded from those location-based possibilities are things like my forgetting to turn on FM Carkit when I get in the car.

I was thinking that I have an inexpensive ebay OBD2 Bluetooth dongle attached to the car & listed as a trusted device in the N900, & if the N900 detected when it was in range of that particular trusted device, if it would be able to execute a command-line function - like turn on FM Carkit, bring up a mapping application, switch to another profile, etc.

The N900's bluetooth would have to be left on, that would consume a little more power, but I typically charge the phone in the car as well as at home, so it might not be an issue.

It could also be used to change profiles, execute commands, etc. when near trusted BT devices located in other areas like at work, at home - thus mimicking RFID tag detection. BT range is shorter than the grosser positioning of location via cellid, so the two would complement each other well for location-based actions.

You do realise you would need to not only leave your bluetooth on, it would have to be scanning ALL THE TIME? This would be a MAJOR battery drain.

I wondered about that, & was curious about the power consumption versus the rate of polling - once per minute, once per 5 minutes, etc, & if some manageable rate could be found.

The more I think about it, it seems like a sort of medieval approach would not incur much power usage over just that of leaving the bluetooth on all the time.

In the Alarmed thread, it was mentioned that alarmd runs all the time with no additional overhead just for having more entries. I am running a script via alarmd that plays sound files of clock chimes every 15 minutes. When I first began using it, I checked to see what the difference was in battery usage, & it was unnoticeable.

It seems like a program which just checked to see if a trusted BT device showed up as in range would consume less power than playing sound files, even if the program were called every 5 minutes.

I suppose a quick & dirty test mule for assessing battery use could be run by creating a command line program that just checks to see if a particular trusted BT device showed up as in range, then entering it as a command execution type in Alarmed with a cron string to run it every 5 minutes, which looks to me like:
*/5 * * * * *

I think it was mentioned that having BT set to Visible consumes more power than if BT is on without being set to Visible, so for such a test period it seems like BT should not be set to visible.

BT should be set to Visible for it consumes more power than if BT is on.