Reply
Thread Tools
Posts: 51 | Thanked: 41 times | Joined on Feb 2015 @ Mansester, FI
#71
Originally Posted by hhaveri View Post
Hmm... noticed similar problem but a simple reboot helped. Difficult to say what went wrong there. Btw, are you using some auto-start solution? I was just wondering if the cell condition breaks if the background process is started too early on boot - or while sim is just unregistered on network.
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.
 
Posts: 203 | Thanked: 596 times | Joined on Jan 2015 @ Finland
#72
Originally Posted by LVPVS View Post
Hej,

I just noticed that when a Situation is triggered by an 'Accessory' that is my car kit, when the phone receives a call, it starts switching on and off the given Situation, as far as the call is received or declined.

When BT is the condition, the same car kit is connected, everything works fine. Only the power hogging nature of the BT condition is the problem.

LVPVS out.
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.
 

The Following User Says Thank You to hhaveri For This Useful Post:
Posts: 58 | Thanked: 24 times | Joined on Jan 2015 @ Hungary
#73
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.
 

The Following User Says Thank You to LVPVS For This Useful Post:
Posts: 51 | Thanked: 41 times | Joined on Feb 2015 @ Mansester, FI
#74
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.
 

The Following User Says Thank You to zagrim For This Useful Post:
Posts: 58 | Thanked: 24 times | Joined on Jan 2015 @ Hungary
#75
Originally Posted by zagrim View Post
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)...
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.
 
Posts: 203 | Thanked: 596 times | Joined on Jan 2015 @ Finland
#76
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).
 

The Following 2 Users Say Thank You to hhaveri For This Useful Post:
Posts: 51 | Thanked: 41 times | Joined on Feb 2015 @ Mansester, FI
#77
Originally Posted by hhaveri View Post
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.
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.

Originally Posted by hhaveri View Post
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).
Ok, thanks, that's pretty much what I suspected it to be.

Originally Posted by LVPVS
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?
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...
 
Posts: 58 | Thanked: 24 times | Joined on Jan 2015 @ Hungary
#78
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.

Last edited by LVPVS; 2015-02-20 at 11:28.
 
Posts: 203 | Thanked: 596 times | Joined on Jan 2015 @ Finland
#79
Originally Posted by LVPVS View Post
I am not using wlan as a 'What'. 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.
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...
 

The Following 2 Users Say Thank You to hhaveri For This Useful Post:
Posts: 58 | Thanked: 24 times | Joined on Jan 2015 @ Hungary
#80
Thanks! I just finished removing my GPS-based 'When's...
LVPVS out.
 
Reply

Tags
sailfish os, situations

Thread Tools

 
Forum Jump


All times are GMT. The time now is 23:53.