Active Topics
-
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 1 day, 9 hrs ago -
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 1 day, 10 hrs ago -
Maemo repository (3)
to Community by torsen - 2 days, 1 hr ago -
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 2 days, 23 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 4 days, 5 hrs ago - more...
slarti |
2013-01-09
, 10:09
|
|
Posts: 277 |
Thanked: 319 times |
Joined on Jan 2010
|
#1021
|
Originally Posted by mangoicetea
Your script is probably written in windows and has MS-DOS formatting. Just go to terminal and use nano.
Code:
|
|
2013-01-09
, 19:53
|
|
Posts: 1,313 |
Thanked: 2,978 times |
Joined on Jun 2011
@ Finland
|
#1022
|
Please install and test the new beta to make sure the upcoming release works for your rules. Latest beta is available from here:
http://www.kolumbus.fi/~ks2877/profi...beta_armel.deb
To install, first remove the version you have installed from Nokia Store. Then install the version above.
Changelog (against current release 2.2.2):
- Automatic name for rule translateable (ie. if user has not filled rule name)
- New translations: polish, russian, swedish, Taiwanese
- Existing translations updated from transifex
Last edited by ajalkane; 2013-07-15 at 22:55.
http://www.kolumbus.fi/~ks2877/profi...beta_armel.deb
To install, first remove the version you have installed from Nokia Store. Then install the version above.
Changelog (against current release 2.2.2):
- Automatic name for rule translateable (ie. if user has not filled rule name)
- New translations: polish, russian, swedish, Taiwanese
- Existing translations updated from transifex
__________________
My N9/N950 projects:
My N9/N950 projects:
Last edited by ajalkane; 2013-07-15 at 22:55.
|
|
2013-01-14
, 15:28
|
|
Posts: 277 |
Thanked: 319 times |
Joined on Jan 2010
|
#1023
|
I may have found a bug. I have a rule set up as described here. Today, for some reason it didn't fire off the script when I locked the screen. A reboot cured this but I got some logs before doing that. The name of the rule is "UpdateBB".
| The Following User Says Thank You to slarti For This Useful Post: | ||
|
|
2013-01-18
, 23:56
|
|
Posts: 1,313 |
Thanked: 2,978 times |
Joined on Jun 2011
@ Finland
|
#1024
|
Originally Posted by slarti
Thanks,
I may have found a bug. I have a rule set up as described here. Today, for some reason it didn't fire off the script when I locked the screen. A reboot cured this but I got some logs before doing that. The name of the rule is "UpdateBB".
from the logs I can see you apparently want the script to be invoked immediately when lock screen is activated. The idle condition is optimized on the other hand for longer periods for power consumption, so it can be that in these cases the script can be triggered 1-4 seconds after locking screen. And if the device is unlucked during this time, the script is not executed. Can this be the case here? If this is a realworld problem I can see for a different, more immediate, handling for the "0 minute" idle case.
If this is not the case here, do you remember anymore at what time did this problem happen?
From the logs I see the script was fired at these times:
Code:
ma tammikuuta 14 08:06:35 2013 RulesManager::refresh() ma tammikuuta 14 08:07:45 2013 RulesManager::refresh() ma tammikuuta 14 08:09:44 2013 RulesManager::refresh() ma tammikuuta 14 08:09:59 2013 RulesManager::refresh()
__________________
My N9/N950 projects:
My N9/N950 projects:
Last edited by ajalkane; 2013-01-18 at 23:59.
| The Following User Says Thank You to ajalkane For This Useful Post: | ||
|
|
2013-01-19
, 07:42
|
|
Posts: 277 |
Thanked: 319 times |
Joined on Jan 2010
|
#1025
|
It was like that all morning. I waited a while for the script to fire before unlocking but nothing happened. Like I said, a reboot cured it and I haven't seen this behaviour after that. If I see it again, do you have any suggestions what information to collect?
A completely different question:
I started writing a simple dbus listener in python which listens to dbus messages from the timed daemon and updates a profilematic rule's activation time or active status according to the message.
I wanted to know if using the updateRule method this way would have any adverse effects?
A completely different question:
I started writing a simple dbus listener in python which listens to dbus messages from the timed daemon and updates a profilematic rule's activation time or active status according to the message.
I wanted to know if using the updateRule method this way would have any adverse effects?
|
|
2013-01-19
, 09:16
|
|
Posts: 1,313 |
Thanked: 2,978 times |
Joined on Jun 2011
@ Finland
|
#1026
|
Originally Posted by slarti
Logs as now are useful. But as I said in the logs it was clear that the script was launched, so it's probably something that the script does that doesn't work. If that happens again try running the script manually and see if it does anything: First run it through ProfileMatic's UI with Test button in custom action. If that doesn't work, run it from terminal. See if there's any output.
It was like that all morning. I waited a while for the script to fire before unlocking but nothing happened. Like I said, a reboot cured it and I haven't seen this behaviour after that. If I see it again, do you have any suggestions what information to collect?
I started writing a simple dbus listener in python which listens to dbus messages from the timed daemon and updates a profilematic rule's activation time or active status according to the message.
I wanted to know if using the updateRule method this way would have any adverse effects?
The only caveat is that the object usually changes between each ProfileMatic release. But of course if you take an existing rule and only modify the parts you want, then that's pretty future proof also.
__________________
My N9/N950 projects:
My N9/N950 projects:
|
|
2013-01-19
, 14:59
|
|
Posts: 277 |
Thanked: 319 times |
Joined on Jan 2010
|
#1027
|
Originally Posted by ajalkane
I think I did run the script in terminal and it worked. I should have remembered the test button since I'm the one who requested it. I'll keep my eyes open for similar cases.
Logs as now are useful. But as I said in the logs it was clear that the script was launched, so it's probably something that the script does that doesn't work. If that happens again try running the script manually and see if it does anything: First run it through ProfileMatic's UI with Test button in custom action. If that doesn't work, run it from terminal. See if there's any output.
Originally Posted by ajalkane
I have no idea how to build the object from scratch. I just dumped an existing rule's object and modify that.
That's safe, but I'm surprised that you can use it. It takes as parameter a serialized C++ object. I don't even know how it looks like building that from python or using dbus-send. Out of curiosity do you have some working sample?
The only caveat is that the object usually changes between each ProfileMatic release. But of course if you take an existing rule and only modify the parts you want, then that's pretty future proof also.
I told you it's simple...
At the moment it just listens for the next_bootup_event signal which just so happens to be an epoch timestamp or zero for no alarms. This example works but is pretty stupid at the moment.
You'll need python python-dbus and python-gobject.
| The Following User Says Thank You to slarti For This Useful Post: | ||
|
|
2013-01-23
, 07:30
|
|
Posts: 277 |
Thanked: 319 times |
Joined on Jan 2010
|
#1028
|
Want your phone to do something when an alarm with a certain name goes off? Use this:
The basic idea is to set a special profilematic 'alarm rule' which executes its actions when an alarm with a certain title goes off. The rule gets deactivated when the next active alarm is not one with the set title or there are no alarms. The alarm title is set in the script as the passwd variable. By default, it's Test.
When the script is running, it will create an 'empty' alarm rule once you set or unset any alarm in the clock application. You can modify the rule freely in profilematic, but don't change the name (probably a good idea to not have another rule with the same name). The time and day will be set by the alarm. This rule is basically meant for 'one-shot' actions so design the actions with that in mind.
If you want to try it out, you'll need to apt-get install python python-dbus python-gobject (as root). Start the script and leave it running in terminal. Try setting and unsetting various alarms and see what happens in profilematic.
To make it run on startup, add it to the default rule as custom action.
The script can be found here.
I've tested this for months without any problems or battery drain.
Added some screenshots to maybe make this a little clearer.
Last edited by slarti; 2013-12-04 at 19:57. Reason: Updated for PM 2.4.2
The basic idea is to set a special profilematic 'alarm rule' which executes its actions when an alarm with a certain title goes off. The rule gets deactivated when the next active alarm is not one with the set title or there are no alarms. The alarm title is set in the script as the passwd variable. By default, it's Test.
When the script is running, it will create an 'empty' alarm rule once you set or unset any alarm in the clock application. You can modify the rule freely in profilematic, but don't change the name (probably a good idea to not have another rule with the same name). The time and day will be set by the alarm. This rule is basically meant for 'one-shot' actions so design the actions with that in mind.
If you want to try it out, you'll need to apt-get install python python-dbus python-gobject (as root). Start the script and leave it running in terminal. Try setting and unsetting various alarms and see what happens in profilematic.
To make it run on startup, add it to the default rule as custom action.
The script can be found here.
I've tested this for months without any problems or battery drain.
Added some screenshots to maybe make this a little clearer.
Last edited by slarti; 2013-12-04 at 19:57. Reason: Updated for PM 2.4.2
|
|
2013-01-23
, 21:26
|
|
Posts: 1,313 |
Thanked: 2,978 times |
Joined on Jun 2011
@ Finland
|
#1029
|
Originally Posted by slarti
Very nice.
The basic idea is to set a special profilematic 'alarm rule' which executes its actions when an alarm with a certain title goes off. The rule gets deactivated when the next active alarm is not one with the set title or there are no alarms. The alarm title is set in the script as the passwd variable. By default, it's Test.
A couple of questions:
- Is this basically implementing the functionality you've requested about alarms?
- I see you require only one rule, but since ProfileMatic's interface only provides getting all rules, you need to iterate through them. Would a getRule(ruleId) be something that'd be useful for this?
Now, how to make it run as a daemon on startup?
A more robust way, which will have the benefit of restarting the service if it crashes, is to use Upstart. Simply create a configuration file into /etc/init/apps. You can see profilematicd.conf for example, or anything else that is there. More comprehensive help is in harmattan dev docs and of course in Upstart's docs.
__________________
My N9/N950 projects:
My N9/N950 projects:
| The Following User Says Thank You to ajalkane For This Useful Post: | ||
|
|
2013-01-24
, 07:13
|
|
Posts: 277 |
Thanked: 319 times |
Joined on Jan 2010
|
#1030
|
Thanks, I went with the default rule as that seems to be enough for now. Should have thought of that myself.
Yes, a getRule(ruleid) method would help getting rid of iterating through a list for a list containing a string. On the other hand the weakness of the script is probably more in the way it creates the alarm rule if one doesn't exist and the way that everything is relying on the string 'Alarm rule'. It seems that the appendRule method doesn't care what ruleid it's fed, it creates a new id for it anyway. That's why the script has to ask for it after creating the rule. Of course, this only applies when there isn't an Alarm rule and I guess I wont be deleting it all the time.
This script does do the job for reacting to an alarm but I still like your idea for setting an alarm as an action.
Yes, a getRule(ruleid) method would help getting rid of iterating through a list for a list containing a string. On the other hand the weakness of the script is probably more in the way it creates the alarm rule if one doesn't exist and the way that everything is relying on the string 'Alarm rule'. It seems that the appendRule method doesn't care what ruleid it's fed, it creates a new id for it anyway. That's why the script has to ask for it after creating the rule. Of course, this only applies when there isn't an Alarm rule and I guess I wont be deleting it all the time.
This script does do the job for reacting to an alarm but I still like your idea for setting an alarm as an action.