Thanks for your quick and detailed answer. Sorry for replying so late.

Default rule = yes
Cell ID rule has no other conditions


I'm not totally sure, as it doesn't happen every time. And I#m not watching all the time my N9s display . I notice it by the beep sound it does when changing profile (beep/normal profile). I'll try to watch my display the next few times I'm entering the elevator.


You were right, there are more cell IDs than I thought. I collected a bit more and it went up from 7 to 14 Cell IDs.

It still does flip flop from time to time, but alot less often and only in corner areas of my collected cell IDs. A user customizable timeout option would help alot I think.

I have instaled profilematic 1.5. Application is awesome. Only problem I see is application startup is very slow & also when I click on + sign for creating new rule..it takes 1 sec to show rule settings screen.

I just like to know is it problem in my device or everyone having slow startup problem??

Probably not a problem with your device. ProfileMatic takes, for me, about 3 seconds to start. All QML applications are slow to start for some reason, there's not much I can do about that (except maybe show a splash screen).

Also the delay when clicking on + sign or opening a rule for editing is normal. I could probably speed it up (might make start-up of application a bit slower though). But I've thought the rules are mucked around quite seldom once they've been set-up, so using development time on speed-up is not "time well used". I may be wrong on that, and would love to hear some opinions.

Thanks for clarification. Ya, ur right about the + thing!

As you're using default rule to change to ringing, it is (at least in theory) that in an elevator where there is no mobile connection the default rule is activated.

Losing the mobile connection does not by itself trigger re-evaluation of the rules. But if, when you enter the elevator, there is a cell id that is not in your rules, then it will re-evaluate your rules and switch to default rule's ringing profile.

I suspect this is the issue here, especially since it does not happen every time. Again it's best to put collecting mode on when entering the elevator for few times to surely catch those flimsy cells.

I'll check in a future version (maybe even in the next version) if I can put some kind of "tolerance" option so that ProfileMatic won't react to cell changes so easily.

I am going to change the rule activation logic in the next version. I estimate it won't affect most users rules, but for sure some rule combinations will work differently after the change. So I'm outlining the intended changes here - now is your time to voice concerns if you see a problem for your use case, so that I may take it into account while I'm implementing the changes.

Currently, ProfileMatic only activates the first rule that matches the conditions (starting from top of the list). I intend to change it so that all the matching rules are activated. Preference is still given to the first matching rule. For example if several rules that match have an action to set the profile, then the first matching rule's profile is used.

The reason for the change is that the increased amount of actions has made it hard and counter-intuitive for users to specify some behaviours.

I'll give one simple use case as an example:

- When I'm in my home WLAN, I don't want the chat accounts online (because I'm logged in with computer). In other situations I want to be online.
- During 22:00 - 06:00 I want Power Saving on because that's when I'm usually sleeping, to preserve battery.
- During 19:00 - 06:00 I want the phone to be silent, because that's when my children are sleeping or getting ready to go sleeping
- When I'm connected to my home WLAN or work WLAN, I wan't 2G to be used to preserve battery, because I don't need 3G speeds when I'm using WLAN.

For these rules, the current rules would need a lot of duplication, because only the first matching rule would be used. That means for example that I'd have to create duplicate rules for the "Time based rules with connected to WLAN" and "Time based rules without being connected to WLAN". While the above rules are possible with current ProfileMatic, it'd be many rules, and it's a bad sign considering I'm using only a small subset of the rules.

But with the changes I've planned, creating the above rules would be quite intuitive:

- When on home WLAN, Availability offline
- When 22:00 - 06:00 Power Saving on, restore previous power saving mode
- When 19:00 - 06:00 Profile silent, restore previous profile
- When home WLAN or work WLAN, 2G mode
- Default: Availability online, 3G mode

Another real-life example is timox's question here and how I outlined the current solution: http://talk.maemo.org/showpost.php?p...&postcount=176. With the changes I've planned his rules would work with a simple re-ordering ("BlueTooth off when connected to WLAN" moved to top).

If what I've outlined above seems strange to you, then most likely the changes I'm intending won't affect you. If you've created rules that rely on only the first matching rule being activated, you'd probably know it and can give me an example of your use case.

I will post a beta of the version with this behavior soon, so interested people can give feedback before I make a release.

Nice approach that should simplify setting up more complex rules as you say. I look forward to trying out the beta...

@ajalkane. Nice approach. Thanks again for a wonderful app.

I find your scenarios very plausible and think it makes sence to let the app make all the autoswitching of network connections (background connection ON/OFF!!!) and profiles.

Why not to make an approach like this: You can create x "Phone Modes". Every mode is based on several IF conditions like time or proximity to a WiFi. Of course you would need to detect overlapping IF-conditions.

And on every phone mode you can simply choose from a list of actions, eg. Select profile [x1, x2, x3], BGConnection (on/off), etc.

This story of a girlfriend in trouble has softened my cold calculating heart. In all seriousness, there's coming the other scriptable option also so I see no good reason why I shouldn't add this one too.

I will add it to the next version.