SchedulGhost

[krambriw]

Same problem for me when testing with Windows XP.

I have modified your code just for testing

Added/changed the following parts

Added sleep

Code: Select all

from time import mktime, strptime, localtime, sleep


Introduced a retry section with debug printing (line 1856 and forward)

Code: Select all

        now = dt.now()
        now = now.replace(microsecond = 999999)

        for i in range(5):
            if i>0:
                print "Retry nbr: ", i
                try:
                    runTime = dt.strptime(data[0], "%H:%M:%S").time()
                    break
                except ImportError:
                    print "ImportError, trying again..."
                    sleep(0.2)



This modified version works for me here and makes it at the second try.
Here is the plugin with the changes (can maybe be made more professional,,,)

__init__.py

(125.54 KiB) Downloaded 109 times

Please note, I did also create a scheduled task that looks like this, maybe this is why you don't get the problem if it is not created. If I delete it, the problem is gone...

Best regards, Walter

[Pako]

Hello Walter,
I do not know, but that solution is not too much I like it.
I'd rather find the cause of conflict and solve it there.
I have a problem but that with me to this error does not occur.
I created the same schedule as you and I tried both
Windows XP and Windows 7 (32 bit). Unfortunately, nothing.
Can you please try the following configuration?

NHS_OnInit.jpg (16.92 KiB) Viewed 2098 times

Best regards, Pako

[krambriw]

Hello Pako,

No change, error is still there. It is the NHS plugin part that needed to be delayed at startup...and that I could do in my code

I suggest we leave the problem as is because it is only me having the problem and I have a workaround. Either putting your plugin as number one in top of the tree or adding a delay to my plugin startup

Best regards, Walter

[krambriw]

Hello Pako,

After testing a while it is working very fine and I have tested most the scheduler and the egg-timer function. I also have some suggestions to improvements

My tests:

First test is running in my normal working PC using Vista with the following configuration

Image7.jpg (4.96 KiB) Viewed 2086 times

It simply initiates a daily shut-down of the computer before the power is automatically turned off at late night and on in the morning using a device similar to X10 controlled by my home automation PC

Second test is running in my home automation PC using Win XP with the following configuration

Image3.jpg (12.96 KiB) Viewed 2086 times

It turns on the light in my garage if somebody walks where the IR detector detects movements. The macro starts and if the python script accepts, the lights are turned on and the egg-timer to turn off is started. To avoid repeats, I abort all previous egg-timers when a new is created.

The python script is used to control if the sun is up or down and that time is within a certain range to allow this control

Code: Select all

p = eg.plugins.Suntracker.GetSunStatusWeatherCompensated(15)
if p:
    print "Sun is up"
    eg.StopMacro()
import time
trigTime = str(time.strftime("%H%M", time.localtime()))
if trigTime > "0600" and trigTime < "2000":
    print "Time is outside range"
    eg.StopMacro()
   

My suggestions to improvements are
- make it possible to link an egg-timer to one or several schedules (this will allow the start of egg-timer only if time is within allowed ranges)
- make it possible to abort egg-timers individually (if you have several running, you could then abort a specific one. Eventually you need to change to give them unique ID's to be used for abortion)

Best regards, Walter

[Pako]

Dear Walter!
Thank you very much for testing my plugin.
BTW: You did not find any poor English phrases?
And now your suggestions for improvements. Both concern the egg-timer.
Yes, the egg-timer needs improvements.
Apparently, the egg-timers need a manager, as well as schedules.
For this to work as you suggest, each egg-timer must have a unique name and we must be able to disable and enable it.
It must of course be possible through the actions Disable egg-timer and Enable egg-timer too.
Do you think it's the right way?
If so, I'll start work on it.
But I do not I'm sure with one thing. If an egg-timer runs and then will be disabed, what happens? He has run to completion or be aborted?

Best regards, Pako

[krambriw]

Dear Pako! Good to hear from you

So far I have not looked so much into the english, I will do in the next test

It must of course be possible through the actions Disable egg-timer and Enable egg-timer too.
Do you think it's the right way?

Regarding the functions I think this is the way it should work (my suggestion)

Abort all: stop and abort all running egg-timers (this action is already available)
Abort ID=xxx: stop running egg-timer with ID=xxx
Disable ID=xxx: disable the egg-timer with ID=xxx and abort it if it is running (no completion)
Enable ID=xxx: enable the egg-timer with ID=xxx and start it right away (if schedule is allowing it...)

I think that if a user has decided to abort an egg-timer, he has a good reason and he wants it to stop without completion

My best regards, Walter

[Pako]

Dear Walter,
I agree with everything, but with one exception:

Enable ID=xxx: enable the egg-timer with ID=xxx and start it right away (if schedule is allowing it...)

I do not see a reasonable way to do it. I think it would not be right to go this route.
After all, the egg-timer to start based on some event. Enabling and start are two entirely different events
and you are suggesting that under some conditions were merged. Where and how to write these conditions?

I think that good rules are:
A) Event X caused the egg-timer with ID=xxx is currently allowed (for example, the beginning of some period)
B) The same event X may initiate a test, whether the egg-timer to run. If yes, egg-timer is started
C) any event at any time can try to start egg-timer. If the egg-timer is enabled, is started. If currently disabled, nothing happens.

I have another dilemma.
There are two possible scenarios, and both have their own logic:
1) The egg-timer with the same ID (= xxx) can be running at one time more than once.
2) The egg-timer can be run only once (currently running the egg-timer with the same ID will be aborted).
I think it makes more sense to use the second scenario

Now, when I finished writing it I thought one solution that might suit your design.
Each egg-timer, in addition to the existing parameters and new parameters, such as a Name (ID) and Status (Enabled/Disabled) has another new parameter.
This parameter should be named as Start immediately at the time of enabling.
What name would you have had Actions that perform ON and OFF this parameter?
Alternatively, this parameter should be set only in the GUI?

Best regards, Pako

[krambriw]

Dear Pako,

I do not see a reasonable way to do it. I think it would not be right to go this route.
After all, the egg-timer to start based on some event. Enabling and start are two entirely different events
and you are suggesting that under some conditions were merged. Where and how to write these conditions?

You are right, enable shall not start, only make the egg-timer available to be started

I think that good rules are:
A) Event X caused the egg-timer with ID=xxx is currently allowed (for example, the beginning of some period)
B) The same event X may initiate a test, whether the egg-timer to run. If yes, egg-timer is started
C) any event at any time can try to start egg-timer. If the egg-timer is enabled, is started. If currently disabled, nothing happens.

A) Please describe a bit more. I understand that an event enables the egg-timer with ID=xxx. If so this is a very good function. Then a second event can be used to start the egg-timer once it is enabled
B) Yes, very good
c) Perfect

Maybe consider also to allow an event to disable, abort egg-timer with ID=xxx as well as abort all egg-timers

I have another dilemma.
There are two possible scenarios, and both have their own logic:
1) The egg-timer with the same ID (= xxx) can be running at one time more than once.
2) The egg-timer can be run only once (currently running the egg-timer with the same ID will be aborted).
I think it makes more sense to use the second scenario

Number 2) is my favourite. Number 1) can cause confusion. If you need many parallel egg-timers it is better to have unique ID's than having multiple instances. Then they can still be controlled individually, otherwise if you need to abort, you will have to abort all with that same ID

Now, when I finished writing it I thought one solution that might suit your design.
Each egg-timer, in addition to the existing parameters and new parameters, such as a Name (ID) and Status (Enabled/Disabled) has another new parameter.
This parameter should be named as Start immediately at the time of enabling.
What name would you have had Actions that perform ON and OFF this parameter?
Alternatively, this parameter should be set only in the GUI?

I think it is enough if it is a checkbox in the GUI only. I believe this is something you decide during your design of your configuration. The function is very valuable because you can then assign certain events & python scripts with interesting conditions in your macros that disables/enables and automatically restarts egg-timers

Very good!

My best regards, Walter

[Pako]

Dear Walter,
Thank you for your suggestions and comments. I have (in the context EventGhost) two things unfinished. When I finish it, throw again on SchedulGhost.

Best regards, Pako

[krambriw]

Dear Pako,

Just another small thing; I would think that having a "button" to show the SchedulGhost would be great. You could, if possible, put it in the plugin configuration dialog or have another tab for it. As it is right now, I need to add the action "Show SchedulGhost" and run it to be able to see configuration & status details (in case I do not want to build the folder structure)

Best regards, Walter

[Pako]

Dear Walter,
Buttons (also for future egg-timers manager) I added to my ToDo list.
It's a good idea.

Best regards, Pako

[Pako]

Dear Walter,
So far I have not started, but something struck me. I will be glad if you will comment on it.

0) I will create a new action, which will be called Start schedule immediately.

If you want use a schedule, like egg-timer, you can do this:
1) create a schedule type Only Once
2) set any date that has already been
3) set Span as "egg timer" time
4) instead of Start egg timer you use the new action Start schedule immediately

I think that this solution is both simpler and more logical to first.
The egg-timer is designed for other purposes. Furthermore, I think that introducing an additional parameter of type Start immediately at the time of enabling is superfluous.

Best regards, Pako

[krambriw]

Dear Pako,

For me its fine, I just like the word egg-clock because it tells you what it's all about (something starts and at the end of the runtime, an action happens..eggs are ready)
If this can be made with normal scheduling functionality, that's ok I think, and you can always give the schedule a title like "Egg-clock..."

Best regards, Walter

[Pako]

Dear Walter,
Thank you for the comment. This new idea will save a lot of work and speed up development.

Best regards, Pako

[Pako]

The new version (0.0.5) plugin is available.
News:
1) Added button Show SchedulGhost manager ... in the plugin configuration dialog
2) Added action Run schedule immediately
New action Run schedule immediately is especially useful in cases where it is set non-zero span.
Please test new features!
Pako