I would like to have the option to make the phone silent at ex. 10.30pm and enable sounds ex. 7.30am automatically. It would also be cool if you could make the phone go to power saving without automatic data connection (like email fetching), or run spesific commands on entering a particular mobile network cell.

The functionality of ProfileMatic in N9 made it possible for user to trigger various commands and actions (e.g. profile changes, entering power-saving mode etc) based on signals/triggers from the system like entering a particular gsm cell, being connected to a spesific WiFi access point, etc. or simply based on a date and time (used as a scheduler).

Now, it would be great to have this kind of scheduler/automation/personalization tool that could even be combined to the Ambience changes in Jolla.

The question has been closed for the following reason "the question is answered, an answer was accepted"by
Jolly-Jo
close date 2015-02-11 15:24:47.518619

Comments

i suppose this is the most relevant answer at the moment: ajalkane, the creator of profilematic, intends to port profilematic to sailfish, if it's feasible. at the moment he is waiting for a jolla device. i don't know if that perhaps means donations would speed up the process :

Hmm, don't you need possibility to run headless daemons for it (and start them during bootup)? Or possibility for running your app on schedule? Both things are possible, both won't let you get through Harbour criteria at the moment.

Profilematic would be fantastic, I hope ajalkane could start working with the port, sooner the better. Anyway I think Jolla could add a simple automated silent feature similar to iOS "Do not disturb" feature. This is something we had already in Symbian devices.

Actually, I think it would be a good idea to integrate the profilematic functionality with the Ambience idea.
Currently, when you are marking as fav an ambience, you can set the ringtone volume and tones for that ambience. The idea would be to include WLAN/bluetooth/IM status/etc and trigger action

5 Answers

I started to write some code (GitHub), to do something like profilematic, but with a much more modern architecture. It's still in the early days of prototyping, and there is nothing interesting to show yet. I didn't know until today that there were already quite a lot of nice preparation work done on TJC, so I will share what I did too, so that we can do it together (c)

I'm at Step 2 of this answer. I'm open to discuss my architecture and will edit the answer if you agree.

Overview

I'm trying to write a library for having a bot reacting to events and executing actions, the phonebot library. Phonebot have

libphonebot, a static library that provides the engine to read and execute rules

plugins to have more capabilities

phonebotd, the daemon that execute these rules

jolla-settings-phonebot, a settings plugin to configure phonebot

harbour-phonebot, a selfcontained daemon + app to pass harbour

Since most of the stuff is done inside libphonebot, I can create several packages that share the same basis, one for harbour, others for openrepos etc. Note that phonebotd and harbour-phonebot might be incompatible, so you would run either phonebotd + settings-phonebot or harbour-phonebot.

Architecture

phonebot isn't trying to reinvent the wheel and takes inspiration from both profilematic, IFTTT and on{X}. The idea is simple: you build rules, either à-la profilematic-IFTTT, with if -> then conditions, or by writing scripts.

Since we are with Qt, we can take advantage of QML and JS to write rules. Actually phonebot is just reading QML files that contains rules. It uses the powerful QQmlEngine to do all the hard work of parsing, interpreting etc.

A Rule in phonebot is a QML component that have 3 properties

trigger: something that triggers the rule

condition: a condition (or conditions) to respect for the rule to be active

actions: a series of actions to execute when the rule is triggered, and when conditions are respected

The Trigger is in charge of emitting signals to run the Rule. Triggers could be: when it's 10pm, when you enter in the home wifi zone, when Battery reached a certain level etc.

The Condition do not provide any signal, and represent more a state. A Condition could be "when driving", "when at home" etc. (even if implementing this kind of condition is rather tricky).

An Action is what to run: execute a program, turn on / off some settings, change an ambience, or use DBus to do stuff.

Here is an example of scripted rule. You will also be able to configure rule with a friendly UI (using default Triggers, Conditions and Actions).

Technologies

I need to check if the QtMobility modues got ported to Qt 5. It's unsure if QSystem* are available. However, a lot of APIs are actually open-source, and, even if they are forbidden in harbour, they can be integrated (statically) in phonebot.

Comments

Wow. IFTTT support sounds very interesting. Your initial proof of concept release seems to have a good key features I miss in sailfishos. In addittion to that I would like too see some time based network management like " turn wifi/mobile data off from 8.00 to 16.00. Thanks for your contribution in bringing new functionalities to jolla :)

Here again, Qt Mobility has a QSystemBatteryInfo class which seems to provide everything needed. There are batteryStatus, chargingState and remainingCapacityPercent properties. And of course, there also are batteryStatusChanged, chargingStateChanged and remainingCapacityPercentChanged SIGNALs.

QSystemDeviceInfo also has the necessary properties : batteryLevel, batteryStatus and currentPowerState.

Comments

5

Key point for me is the question, what Jolla's vision for ambiences is. Should it go towards a system adjusting the phone to a certain situation, i.e. something such as discussed here or will it just remain a fancy word for themes?

Thanks for the link, I didn't realize I could get some information about this subject in a post titled "Screenborder Swipe"... But that's another issue :)

What's described in the post you're referring to is very interesting. I am convinced that providing system settings switches in ambiances is the way to go.

But we would still miss the ability to automatically change the ambiance, depending on some "Events". They are only talking about changing the ambiance manually.

One of the Actions I was thinking about is the ability to change the ambiance. If we manage to do that, and Jolla provide "extended ambiance" support, we achieve our goal.

Moreover, working on Step 1 and 2 could also benefit Jolla.

You know, I just watched Google I/O. And I also watched Apple's WWDC a few weeks ago. We have a lot to catch. We can't just sit here and wait for the small team at Jolla to provide everything, can we ?

I have just made a similar posting as I had not seen this one. So I am going to delete my posting but add my ideas here as an answer (comments cannot be that long). I hope this is OK. In some sense it is an answer as it specifies details of how it can be done.

As a Jolla user I would like to

get maxmium battery life by specifying in which locations (work, home, ...) certain phone functions should be enabled or disabled automatically.

have my Jolla "learn" a location by scanning the cell IDs of the mobile phone base station antennas in range. This is a user-controlled process: A scan is initiated manually and all cell IDs detected within a few minutes will from now on identify this location. I want to give a name to that location. See the Android program "Actions" which implements this very well (also the "Tasker" app). It must be possible to "refresh" a location at a later point in time as cell IDs may change when a base station antenna is replaced/updated.

specify which phone functions should be enabled or disabled upon entering or exiting a location that my Jolla has learned. In particular I want to do this for WLAN and possibly Bluetooth.

when I manually turn on WLAN in a friend's place, the WLAN must stay on, even if this is a location unknown to my Jolla. Automatic enabling/disabling of functions must only occur when a transition from/to a defined location is detected (exit/enter the range of a set of base station antennas that define a known location).

GPS or WLAN should NOT be used to determine location. This is all about battery life and the precision of location achieved by looking at base station antennas in range is sufficient for this purpose.

Usage example: My Jolla would know when I am "at home" and enable WLAN when I return to my place. When all "home antennas" have gone out of range, WLAN will automatically be turned off.

Of course this does not have to be limited to WLAN and Bluetooth. Maybe somebody wants to use a different ringtone or volume setting in a certain location. But I don't think Sailfish OS should implement all kinds of automation functions like the Android apps "Actions" or "Tasker". The OS itself should only be able to dermine location by cell IDs (it naturally has to know about base station antennas in range) and control those functions that have a heavy impact on battery life.
An API can be offered so that native apps can be written that provide more features. But I do not want to have an additional program running just to save battery life.

Comments

Most of those functionalitues and features were present (and still are) in N9 Profilematic, and the Cell Id Identification of location was how I used my phone to detect wherger I was at home or at work, and trigger actions and profiles when enerering and exiting those zones. It also had time based action triggers to e.g. turn WLAN off/on at partticular times or automatically go to silent mode when entering specific places. Excellent for the battery life and really badly needed stuff in our Jolla's ;)

I did not know Profilematic, but it seems to be an excellent example of how automation could work. I hope that knowing locations by cell ID will be integrated into the Sailfish OS itself. It could be a distinctive feature: As far as I know, all other mobile operating systems need an app running for this type of service. Also time-based control sounds like a good idea that could be an integral feature of the Sailfish OS.

All we need is to expand Ambience functionality and include things that Profilematic is doing for N9. For example there is no point changing "ambience" for work or sleeping time. An ambience should be configurable to say e.g. Mon-Fri from 09:00-17:00 go silent mode, etc.

Lack of scheduled profiles is the main reason my Jolla has been in the drawer for last 5 months. Has enyone asked this ajalkane guy if he would be willing to invest his time on porting to SailFish?
Jolla development should send him a unit with a "pretty please" note attached.