Pre-amble
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.
…
Starter
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
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. 
