[How-To] Situations App (trial)

A How-To for the Situations profile app on SFOS (Pastilli Labs, via Jolla Store).

Scope of topic
Starter information is hosted by app owner at https://pastillilabs.com/situations/ : this topic is intended to complement that information with respect to SFOS.

While this How-To is intended for the broad community, my experience is miserably limited to observation of UI behaviour without scripting, and following notes are of this nature:

Manual Control
A profile can be manually activated/de-activated by entering the settings of that profile.

Situation Activity Indicators (Flags)
Both green and yellow flags are used to indicate that a profile is active (ON); the difference signifies the logical status of the (combined) ‘When’ condition:-

  • Green: Active AND (When = TRUE)

  • Yellow: Active AND (When = FALSE, or there are no When conditions)

  • None: Inactive

Actions at Profile (‘Situation’) De-Activation
While the expected purpose is for the App to modify phone settings when a profile is activated, you may be surprised that any OFF-ON settings shown will also be toggled when de-activated.
For simplicity, therefore, any settings which you wish to control by other means - e.g. you rarely use BT and want it normally off - may be best removed entirely from profiles used (hold and drag to waste-bin).

App vs User Control of Parameters
The App merely modifies the phone settings at the moment of profile activation/de-activation; it does not appear to prevent user control.
While not verified, by extension it seems reasonable to assume that other apps are not barred from simultaneous control of mutual settings (should that affect you).

Action Precedence in "overlapping actions"
While https://pastillilabs.com/faq/ (FAQ#1) states that profile precedence is set by the profile ordering, I have not found this to be the case (YMMV).

Automation and Profile Disabling
As long as ‘Situations’ is running, each profile will automatically trigger according to the saved ‘When’ conditions.
Unwanted profiles can of course be deleted; however, they are not recoverable directly through the app (NB for file locations, see post below), nor are they (normally) restored on re-installation.
A workaround to having it both ways, effectively disabling unwanted profiles, is to add impossible AND conditions under ‘When’.

Re-installation restores profiles from the previous installation (i.e. files are not deleted on un-installation), while not restoring any defaults which were previously moved to trash.

Additional Parameters/Add-Ons
Additional parameters (add-ons) can be added via ‘Features’ in pull-down. I found ‘Display’ useful (see next tip).

Use in Power Conservation
Battery consumption can be reduced while device is not in use by application of ‘Display’ feature. In my case, much power was going toward the WLAN function while not in use, so I created a new profile which triggers disabling of WLAN when display is off.

Launch Action
My reading of the intended behaviour was that if a profile is asked to launch an app which is already running, the app should not be launched again.
Specifically with TintOverlay, however, in certain (not all) cases I found that - if already running in the background - profiles triggered TintOverlay to activate (unwanted) into the foreground again (YMMV).
NB there is no UI option of launching into the background.

Situations Auto-start and Schturman 'Auto-start’
It would appear that Situations auto-runs at start-up (and therefore Auto-start (Schturman) might have been superseded by up-issue).
While other actions seem correctly triggered, my finding is that Situations does not perform launch actions at OS start-up (tested: WLAN(Y), TintOverlay(N), Gallery(N)). Please see below post and kindly report here if tried.

Corrections and additions to this post are encouraged. :grinning:


Regarding your auto-start issue with TintOverlay, maybe you should try the solution given in https://together.jolla.com/question/404/autostart-applications/?answer=11430#post-id-11430 which basically creates a systemd service which consists of a shell script where all the auto-startable things can then be put. I used this approach for auto-starting Situations app back when there still was no other way (no autostart app available yet, or at least I hadn’t found it) and basically used that until Situations got the auto-starting functionality built in.

1 Like

One might also want to back up the situations (profiles) before doing any dramatic changes just as a precaution. Not because the app itself would mess things up (I don’t remember that ever happening) but because one might make a mistake when doing complex changes, which them might not ever work as intended). The application saves all its data under /home/nemo/.local/share/harbour-situations2application/harbour-situations2application/situations2, the actions, conditions etc being in situations.json file.

I would not recommend trying to modify that file manually except when absolutely sure what one is doing (and having a back-up available), but I’ve once had to reconfigure some cell based conditions that way (since there’s no way to copy cell locations in the app itself, and re-learning all of the cells would sometimes be pretty slow process).

1 Like

You got me - still haven’t learned my way around basic Linux. :persevere: (ffs)

Schturman linked Apps after boot from TJC question, which I think packages the same scripts; either way it seems that third-party apps like TintOverlay need deeper hacking to auto-start. IDK, until I do my homework (WIP, sorry juggling balls here) I see that I’m out of my depth.

Regardless, thanks for adding all the info - will update if I get to the end of it.

edit: above suggestions linked into original post, thanks again.