| Author |
|
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: November 14 2014 at 16:23 | IP Logged
|
|
|
All,
Work continues on 2.1.5b and Im implementing a significant change to current functionality and wanted to get user feedback.
The timed events system has been totally rewritten to solve current issues that seem to have been introduced in 2.1.5 as well as deficiencies (in my mind) that have been there from the beginning.
The major changes here are that a timed event cant be created in the past. In other words, through the PowerHome Explorer or any of the timedevent ph_ functions, you will not be able to create a timedevent that is older than the current time. In the case of the PowerHome Explorer, based upon the time you put in reftime and all the other variables, if the starttime is calculated to be earlier than the current time, the system will automatically adjust the reftime and starttime to be the first logical time slot past the current time based upon the settings you've chosen. In the case of functions, you'll get an error returned if the calculated time is in the past.
The way it currently works, depending upon combinations of settings, you can set a timed event to be in the past. Other combinations will set it in the future similar to the new functionality.
The other significant change in timed events is how past due timed events are processed. In the current system, if past due timed events are processed, they are executed in order as many times as necessary until the starttime is in the future. If you have a timed event that executes every minute and timed events have been turned off for an hour, then that timed event will execute 60 times to catch it up.
The new methodology is that if a timed event is past due, it will be executed only 1 time and the reftime and starttimes will be adjusted to be the next logical timeslot in the future.
Let me know your thoughts or if anyone sees any potential problems with the new methodology. In my testing so far, I have had no issues and the timed events system is more than stable than previously.
Thanks,
Dave.
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: November 14 2014 at 18:12 | IP Logged
|
|
|
I like that. Will help after power outages. ;)
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: November 14 2014 at 19:16 | IP Logged
|
|
|
Dave,
That makes a lot of sense.
For me, I don't programmatically create timed events, but I have seen start-up issues related to timed events.
Thanks for all your efforts.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: December 09 2014 at 08:22 | IP Logged
|
|
|
A month late but sounds good to me also. There is a bunch of unexplained TE failures tied to 2.1.5. Maybe this will clear some of them up. I can't tie down the root cause because the Event Log also has gaps in it.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 14 2014 at 15:11 | IP Logged
|
|
|
Hi Dave - this is in the right direction. I have no problem with disallowing scheduling in the past. But when Powerhome boots up and finds forgotten events, ideally it would start with the state of the system at shutdown, make a pass through all the unexecuted events to determine what the state of the system should be now, and then apply only the commands needed to achieve that state.
What worries me about your current proposal if I read it correctly is that if you have an unexecuted history of
turn a off
turn a on
turn a off
I -think- you're saying the 2nd off will be skipped, resulting in an incorrect final state.
I personally don't consider getting this right a high priority (since for me it's a rare event) but since you're asking for feedback...
best
/j
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 15 2014 at 10:34 | IP Logged
|
|
|
Jeff,
I guess it would depend upon how a is being turned off and on. If you had a separate timed event that turned a on at certain times and another that turned a off at certain times, then we should be good. The timed events (on and off) should execute in the proper order and then bring the next timed event runtime to the appropriate time in the future.
Now if you had a single timed event that was doing something like a "toggle" of a (if on then off, if off then on) then I can see how that may be a problem. Ideally, it would be nice if PowerHome could figure out what the state should be but it would be impossible to determine without actually executing through the formulas (which is the way it used to be done). If you had a timed event that ran every 10 minutes and PowerHome had been down for a couple of days, that timed event would run approx 288 times (along with any other past due events) 1 right after another (also probably not an ideal solution).
Since Im nearly done with this next release (just working the install and documentation), I'd like to see how the new method works and if its an issue for some, I can then make an INI entry for those who prefer the old way (run all time events in sequence) so you'll have a choice.
Appreciate the feedback.
Dave.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 15 2014 at 10:44 | IP Logged
|
|
|
Hi Dave - I totally support whatever solution you're developing, I was just shooting the breeze. But I don't think I explained myself. In an ideal universe, the code would indeed "execute through all the formulas" but -without- actually signaling the devices. It would take note of the final state of each deice, and then just send out the final state, one command to each device. However, given the rareness of the event, I agree this could be a disproportionate amount of coding.
best
/j
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 15 2014 at 11:38 | IP Logged
|
|
|
Jeff,
No problem  . I understood what you were trying to say and that would be the ideal situation. Unfortunately, due to the way PowerHome is put together regarding formula execution, I cant determine ahead of time what the outcome would be without actually performing the operation (the parsing and execution is actually done by a datawindow within the PowerBuilder environment). Now of course if your action was something simple like a device control string then I would be able to make that determination (device control strings are parsed internally) but formulas and macros are a different story (if a macro consisted of only simple direct actions on a device, it could be done as well but as soon as a formula comes into play, I cant determine the result without actually executing it).
I'll do some digging though and see what options may be available.
Dave.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 15 2014 at 12:10 | IP Logged
|
|
|
Hi Dave - thanks. Again - don't feel like this is important enough to -do- anything - was just having a theoretical discussion. I vaguely remember you telling me years ago that PH didn't work this way - which is cool.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: December 15 2014 at 12:36 | IP Logged
|
|
|
If I may add an observation:
If PH were to crash, or the computer were to crash, the state of any (un-polled) device would be unknown. If the system were to crash, an unknown number of issues could be missed.
In my start-up / re-init macro, I set things to the state they should be in based on the current time, or until I can make the proper determination again. I can see that there could be an issue with devices that are not clock dependent. If, for example, you turn on the outside sprinkler system for a wait time of 5 minutes, you could have problems. If the system stopped during that wait, you would have a running sprinkler.
I agree that this issue's solution has multiple ramifications. Maybe Dave's idea of a ini setting would allow the user to decide. I will set it to delete/ignore past due events because I set things on start up/re-init. To me, the current problem/lockup is more painful than losing past due events.
I would invite you to think about other real world device controlling software. Take for example a washing machine. If the machine is running, all is fine. If the machine gets unplugged (re-booted) mid cycle, the software needs to handle this situation. The washing machine may have water in it, it may be mid spin cycle, it may have the door locked.... Programmers can't rely on everything working perfectly. This is called error handling.
Perhaps PH users need to rethink and create or enhance their start up / re-init macros.
Just my thoughts.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 15 2014 at 12:41 | IP Logged
|
|
|
If only I were lucky enough to have a simple enough setup that I could easily write a macro that would put everything to the "right" state based on the time. :-)
And again, I'm not suggesting Dave DO anything. When a crash occurs, I reset things manually, and that's fine.
/j
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: December 15 2014 at 15:01 | IP Logged
|
|
|
Jeff, if you're willing to share.....
I'm just curious; what type of condition are you thinking about that can't be re-init'd with a system status of "booting" or some other init flag, that couldn't re-align itself?
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 15 2014 at 15:07 | IP Logged
|
|
|
I have a few dozen insteon modules in my home. The correct setting for them depends on time of day, and perhaps other variables, so writing static code to predict these settings is non-trivial. But it's easy to make a manual pass at the time.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: December 15 2014 at 16:01 | IP Logged
|
|
|
Thank you for sharing.
Have you thought about, in your start up / re-init macro, a case statement of hour(now())? That might handle a lot of those devices to reduce your manual settings. Might not be accurate to the minute, but it might be close enough in the rare case of a re-init.
Just some thoughts.
Then again, you know much more about your program.
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: Upcoming version
