Ah, I didn't try to reboot the phone , as I thought (along the lines of using any Linux box) that if all the application processes are restarted, it should be the same as rebooting the whole system... but apparently Sailfish isn't just like that (or Situations taps in pretty deep in the system). Ok, now I know I should also try rebooting next time something like this occurs.

But alright, the app seems to work ok now, situation triggering works as well as recording cell IDs.

BTW, I'm using this autostart solution. Haven't had any issues so far.

Could you tell how often the situation changes in this case (once every X seconds)? I may need to attempt a blind fix, so this would be important to know.

Hej,
@hhaveri, it is like 5-7 times a second.
I guess, it is only the processing speed of the phone and the number of "What"s that limits it.
LVPVS out.

Sadly I have been still having issues with cell ID based situations even after the app update, but it also might be that I have figured out the reason (but let me first describe the issues)...

Each of the previous three mornings when arriving at the office I've had incorrect situation active. This morning it claimed I'd still be around my home, which is over 3 km away from the office and surely no cells are reachable from both locations. Yesterday morning it just didn't seem to notice arriving at the cell ID based area "office".

What is common to these cases now is that if I add a new situation and try to record cell IDs, none are found, even though there's 3G with good signal available. Also, after activating the correct situation (which has mobile data -> on and wifi -> off) things seem to get fixed and when returning home I have no issues even though also then cell ID based conditions are being used.

I have one question related to this about the GUI: When manually enabling a situation, the green icon is first a bit yellowish, turning deeper green only after a while when the incorrectly active situation gets disabled by the app. Does this tell something about the issue?

Also, I noticed that after the correct situations is activated, there is a popup notification telling that mobile data connection is (only then) established, even though mobile data has been enabled ever since I've left the coverage area of my home wifi AP. And here's when we might be getting at the roots of the issue...
There's an open guest wifi AP available at the office, and I only just this morning realised that I had saved a connection to it thus making the phone automatically try to connect to it. However, there's browser based authentication on the AP, and before passing that phase there's no internet connectivity available. Sailfish does recognise the case correcly, firing up the browser with the AP login page opened. However, I wonder if this semi-connected state could be confusing Situations or the API it is using? After all, there's sort of a wifi connection active, which can block using mobile data properly, but I fail to see a direct reason why this would block things with cell IDs...

I'll get back to this next week to let you know if "forgetting" the open wifi AP makes things work ok.

Hej,

I have one CellID-based situation. It activates when around home. It switches mobile data off and wlan on. I can say it pretty much does what it should.

Have you tried uninstalling the app, removing the remnants of its data and installing it again?

LVPVS out.

The "no cells found when trying to record" is definitely connected to this problem. I don't know if it is something in Situations or something in org.ofono or something somewhere else that breaks but for some reason Situations just does not get any cell updates or cannot even read current cell when this happens. Would be interesting to know if any other app can read the cell in this case.

You could also try removing actions from your situations one by one to see if any of them is directly or indirectly causing the issue.

When a situation is activated manually, the color of the circle on the left is yellow indicating that it is not turned on by automation. Green means that automation also thinks the situation should be active (and that automation takes over the control of that situation even if it was manually activated).

When things "get fixed" shortly after manually activating the correct situation, also recording of cell IDs starts to work, so there's definitely a connection between these things.
I can't immediately think of other native apps that would allow testing cell ID reading, any suggestions? There would be plenty of options with Android apps but AFAIK they can't access that information on SFOS at all.

Ok, thanks, that's pretty much what I suspected it to be.

It seems to work also for me around my home, but not around the office, which supports the possibility that the semi-connected guest wifi AP at the office might be a triggering factor... But as I said, I'll report back next week after seeing how the app behaves now after disabling automatic reconnection to that AP. Enabling wifi manually and connecting (without authentication) to the same AP doesn't seem to prevent reading cell IDs, though.

If all other fails, I'll go for uninstall, clean-up and reinstall, but I'd hate to do that even though the rule-set is not that complicated. I might also try with tweaking the actions as @hhaveri suggested, but there're pretty much only mobile data on/off, wifi on/off and ringer volume that are being set (no bluetooth or app launching etc), and of those only volume control can be dropped off without changing the test case altogether...

Hej,

@zagrim, You might be right about the hotspot...
I am not using wlan as a 'When'. I have a gut-feeling that it would be at least as power-hungry as Bluetooth is.
I am testing GPS-based Situations, but I have some doubts about its power efficiency, as well.

I have also went through this uninstall-cleanup-reinstal-reconfigure procedure once.
It was a real pain. I have 9 Situations of which one is a base-line Situation, thus always active, and one temporarily disabled (as audio accessory-triggering has some issues).
So yes, I, too, hate the thought of cleaning up...

LVPVS out.

Wlan is generally not as power hungy as Bluetooth as scanning is much much faster even in crowded environments. But the impact is surely non-zero

GPS condition updates the location in practice continuously, so it eats as much power as if Maps application was on. As many other features, this might also be optimized in the future...

Thanks! I just finished removing my GPS-based 'When's...
LVPVS out.