Situations app - bugs, questions, answers, help etc.. - Page 49 - maemo.org

Active Topics

Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 2 days, 19 hrs ago
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 4 days, 16 hrs ago
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 5 days, 13 hrs ago
more...

Page 49 of 54

Thread Tools

hhaveri	2020-01-07 , 06:23
Posts: 203 \| Thanked: 596 times \| Joined on Jan 2015 @ Finland	#481

Originally Posted by P@t

- I have not anymore the two-cells bug but I started with one cell while I thought it should be from zero

Situations automatically records the first cell when you start creating a new Network Cells condition. I suppose this is what happened?

Originally Posted by P@t

- with flight mode on, the situation was still on

Very good finding, that probably needs separate handling with the new interface then.

Originally Posted by P@t

- the situation seems to react as expected when moving but I will test more during the day

This sounds like an improvement over the previous version, so perhaps the blind implementation is on the right track

Originally Posted by P@t

- enabling/disabling mobile data does not seem to work; it could be related to the fact that there is something special about having 2 sim slots.

You are probably right. Is there a separate mobile data switch for both sim slots in the system settings?

Br,
Heikki

Quote & Reply |

P@t	2020-01-07 , 14:09
Posts: 343 \| Thanked: 819 times \| Joined on Jan 2010 @ Paris, France	#482

Thanks for your blind work

The application seems to handle neatly cell towers.

I can confirm that there are settings to handle the possibility to use 2 sims. You can activate one or two sims, and then you can choose one or the other for mobile data. So activating mobile data for 'situations' needs likely to add which one...

Quote & Reply |

	nonsuch	2020-08-27 , 06:22
	Posts: 584 \| Thanked: 1,550 times \| Joined on Sep 2019	#483

I have been using Situations for a while.
It works well with switching wifi on and off depending on whether I'm home or not.
Now I am trying to activate BatteryBuddy when the charger is connected, and deactivate it when the charger is disconnected.
I figured out that I need the Command module for both actions, because I just want to launch the daemon.
So I have:

Name: Charging
When: Device = Charger
What: Command: harbour-batterybuddy-daemon
What: log to situations-buddy-on.txt

This works as expected. (*)

Name: Not Charging
When: Device != Charger
What: Command: /home/nemo/situations/kill-batterybuddy-daemon <=== Problem here
What: log to situations-buddy-off.txt

This works so far that the situation changes correctly when I disconnect the charger, but the command does not: first I just used "killall harbour-batterybuddy-daemon". This works when executed on the command line (ssh), but not through Situations.
Then, I wrapped it in a shell script. Again, this works when executed on the command line but not through situations. (*)

Nothing helpful in the logs (just START/STOP messages).

I told the kill script to log its activity, too, but it logs only when executed manually. Which leads me to believe that Situations does not execute the kill script at all.
Why?

(*) I am confirming with 'ps aux | grep buddy'.

__________________
N900 in 2020
SFOS in 2021

Quote & Reply |

	nonsuch	2020-08-28 , 05:25
	Posts: 584 \| Thanked: 1,550 times \| Joined on Sep 2019	#484

Progress.
The command script now executes. I had to use the full path when calling it.

I had to change the script so that it takes a START and STOP option, and added full paths to all commands just to be sure, as well as some narrative for the logs:

Code:

#!/bin/bash

exec > "$HOME/situations/situations-batterybuddy.txt" 2>&1

whoami
date
echo $1

sleep 5

case $1 in
START)
if /sbin/pidof harbour-batterybuddy-daemon ; then
        echo "no action, harbour-batterybuddy-daemon is already running"
else
    	echo "launching harbour-batterybuddy-daemon"
        /usr/bin/harbour-batterybuddy-daemon & disown
fi
;;
STOP)
if /sbin/pidof harbour-batterybuddy-daemon; then
        echo "killing harbour-batterybuddy-daemon"
        /usr/bin/killall -vw harbour-batterybuddy-daemon
else
    	echo "not killing harbour-batterybuddy-daemon because it is not running"
fi
;;
esac

But harbour-batterybuddy-daemon neither starts nor stops, even though this works when the script is executed manually, as a normal user.

When executed manually, "$HOME/situations/situations-batterybuddy.txt" contains:

Code:

nemo
Fri Aug 28 08:18:54 EEST 2020
STOP
25045
killing harbour-batterybuddy-daemon
Killed harbour-batterybuddy-daemon(25045) with signal 15

When executed through Situations, "$HOME/situations/situations-batterybuddy.txt" contains:

Code:

nemo
Fri Aug 28 08:18:54 EEST 2020
STOP

I am stumped.

PS: this is academic; at this point itwould be much more practical to just leave BatteryBuddy running and do its thing without help from Situations, but I want to know why the Command plugin isn't doing what I think it should.

__________________
N900 in 2020
SFOS in 2021

Quote & Reply |

hhaveri	2020-08-29 , 16:31
Posts: 203 \| Thanked: 596 times \| Joined on Jan 2015 @ Finland	#485

Originally Posted by nonsuch

Progress.
The command script now executes. I had to use the full path when calling it.

I had to change the script so that it takes a START and STOP option, and added full paths to all commands just to be sure, as well as some narrative for the logs:
Code:
#!/bin/bash

exec > "$HOME/situations/situations-batterybuddy.txt" 2>&1

whoami
date
echo $1

sleep 5

case $1 in
START)
if /sbin/pidof harbour-batterybuddy-daemon ; then
        echo "no action, harbour-batterybuddy-daemon is already running"
else
    	echo "launching harbour-batterybuddy-daemon"
        /usr/bin/harbour-batterybuddy-daemon & disown
fi
;;
STOP)
if /sbin/pidof harbour-batterybuddy-daemon; then
        echo "killing harbour-batterybuddy-daemon"
        /usr/bin/killall -vw harbour-batterybuddy-daemon
else
    	echo "not killing harbour-batterybuddy-daemon because it is not running"
fi
;;
esac
But harbour-batterybuddy-daemon neither starts nor stops, even though this works when the script is executed manually, as a normal user.

When executed manually, "$HOME/situations/situations-batterybuddy.txt" contains:
Code:
nemo
Fri Aug 28 08:18:54 EEST 2020
STOP
25045
killing harbour-batterybuddy-daemon
Killed harbour-batterybuddy-daemon(25045) with signal 15
When executed through Situations, "$HOME/situations/situations-batterybuddy.txt" contains:
Code:
nemo
Fri Aug 28 08:18:54 EEST 2020
STOP
I am stumped.

PS: this is academic; at this point itwould be much more practical to just leave BatteryBuddy running and do its thing without help from Situations, but I want to know why the Command plugin isn't doing what I think it should.

Hi,

Hard to say what the problem is, since I had no problems running your script with the command action. I'm running Situations 3.2.258 on Sailfish 3.3.0.16 (Jolla 1).

Which Situations & Sailfish version are you on?

Br,
Heikki

Quote & Reply |

The Following User Says Thank You to hhaveri For This Useful Post:
nonsuch

hhaveri	2020-08-29 , 16:35
Posts: 203 \| Thanked: 596 times \| Joined on Jan 2015 @ Finland	#486

By the way, you don't need two situations to execute the scripts. You can add one command action with the "START" argument and another command action with "STOP" argument to the same situation. You just need to select "At situation end" for the latter one.

Br,
Heikki

Quote & Reply |

The Following 2 Users Say Thank You to hhaveri For This Useful Post:
nonsuch, olf

	nonsuch	2020-08-31 , 19:20
	Posts: 584 \| Thanked: 1,550 times \| Joined on Sep 2019	#487

^ thanks for the tip, already implemented!

SailfishOS 3.3.0.16
Situations v3.2.258
Sonar 0.0.5

I solved it!
Something weird happened to the input field for the command for When = Charger. I moved around in it with arrow keys (special keyboard layout) and suddenly there was more text than there was before. I erased it. Still didn't work.
Then I looked at ~/.local/share/harbour-situations2application/harbour-situations2application/situations2/situations.json and found that the command entry had a superfluous '\n' at the end, like so: ... START\n
Apparently this was passed to the shell script _literally_ so that the case/esac did not match.
I removed it manually (edit the .json in nano).

Solution:
- no newlines at the end of the command
and/or
- add a * to the case/esac options:
START*)
STOP*)

It is working now, batterybuddy-daemon is active when I plug the charger in, and stops when I unplug it.
It just takes a couple of minutes to switch states; I guess that's by design (taking less resources).

__________________
N900 in 2020
SFOS in 2021

Quote & Reply |

The Following User Says Thank You to nonsuch For This Useful Post:
hhaveri

	nonsuch	2020-08-31 , 19:31
	Posts: 584 \| Thanked: 1,550 times \| Joined on Sep 2019	#488

I am trying to implement the following _without GPS_:

- switch on the Wifi when I'm home
- switch it off when I'm away

I have been using the Network cells condition; it scans and finds 2 cells - does that mean cell towers?
It's been working so-so, sometimes it recognizes when I'm home, sometimes not.
Is there a better way?
I guess I cannot scan for my home wifi ssid when wifi is off?

Additionally I cannot concatenate the 2 Home/Elsewhere conditions into 1 because I cannot choose Wifi state a 2nd time in the same condition (to switch it off at condition end, instead of switching it off in a separate condition, as hhaveri told me).
Why?

__________________
N900 in 2020
SFOS in 2021

Quote & Reply |

hhaveri	2020-09-01 , 04:47
Posts: 203 \| Thanked: 596 times \| Joined on Jan 2015 @ Finland	#489

Originally Posted by nonsuch

Is there a better way?

I guess Network cells (yes, basically cell towers) is your best bet. But it does have drawbacks.

First of all, if I remember correctly. it does not work well on Sailfish when the device is sleeping -> Situations might recognise cell changes only after user wakes up the device.

Secondly you need to cover (record) cells in all network technologies (2G/3G/4G/...) and over a long time span to make it as reliable as possible. But of course the location accuracy then suffers.

Originally Posted by nonsuch

Additionally I cannot concatenate the 2 Home/Elsewhere conditions into 1 because I cannot choose Wifi state a 2nd time in the same condition (to switch it off at condition end, instead of switching it off in a separate condition, as hhaveri told me).
Why?

When a situations ends, it should restore settings like wifi state to the value before that situation was activated. So there is no need to do it explicitly. But if you want to be absolutely sure regardless of the previous state, then you can of course use another situation for it.

Br,
Heikki

Quote & Reply |

The Following User Says Thank You to hhaveri For This Useful Post:
nonsuch

	nonsuch	2020-09-02 , 06:09
	Posts: 584 \| Thanked: 1,550 times \| Joined on Sep 2019	#490

Originally Posted by hhaveri

Secondly you need to cover (record) cells in all network technologies (2G/3G/4G/...) and over a long time span to make it as reliable as possible. But of course the location accuracy then suffers.

Aha!
So does that mean more is better (when Situations is scanning network cells)?

~~I thought maybe the logic is that ALL cells need to be present for the What to apply...~~
I collected 8 cells with 2 sim cards, switching all available network modes (2G/3G/4G - took almost half an hour), and still Situations immediately recognizes my "Home" Situation, so that proves that logic wrong.
I will now test how it fares when I leave home, and if it generally switches Wlan off reliably.

__________________
N900 in 2020
SFOS in 2021

Last edited by nonsuch; 2020-09-02 at 06:49.