Away Mode Random Lights

The device tracking file is generated when the current "Season" has expired and no file exists for the current season. It's deleted once the new season file is compiled.
I don't know how you've gotten into this situation, but the solution will be:
1 - Stop the Events associated with this script. I believe there were two events.
2 - Delete the Season_1 file.
3 - Edit your INI as I'd instructed above but set Recording = TRUE

I'd also suggest the following edits:
[Seasons]
Season1 = Spring|03/21|06/20 {This would be March 21 to June 20}
Season2 = Summer|06/21|09/20 {This would be June 21 to September 20 }
Season3 = Fall|09/21|12/20 {This would be September 21 to December 20}
Season4 = Winter|12/21|03/20 {This would be December 21 to March 20 }
(You can adjust the dates or add new seasons as you like. Just make sure the date ranges don't overlap; there was no check for this in the script)

4 - Make sure the device names you've defined in the ini DO exist by name (Including Location 1 (Floor or whatever you've used to define that in your system). If there are no exact matches you'll likely end up with an empty file.
5 - Re-enable the events.

The tracking phase will run for seven days and begin to build the DeviceTracking.csv file, provided your defined devices do exist. DO NOT EDIT this file. Each time one of your devices changes state during your defined times of day, an entry is made in this file and later used to create Away Mode events.
After the seven day period, the Season_1 file should be compiled and the DeviceTracking file will be deleted after which time the script will begin to control your devices..
Once that file has been created, you'll be able to edit it using the ASP page.

This is all from memory as, as I've said, it's been more than two years since I've looked at this and I don't currently have the script installed on my systems. It may be a while before I can do so to try to duplicate your situation.

It seams to be working. I will leave it running.

Thanks a lot

[Wadenut]

The device tracking file is generated when the current "Season" has expired and no file exists for the current season. It's deleted once the new season file is compiled.
I don't know how you've gotten into this situation, but the solution will be:
1 - Stop the Events associated with this script. I believe there were two events.
2 - Delete the Season_1 file.
3 - Edit your INI as I'd instructed above but set Recording = TRUE

I'd also suggest the following edits:
[Seasons]
Season1 = Spring|03/21|06/20 {This would be March 21 to June 20}
Season2 = Summer|06/21|09/20 {This would be June 21 to September 20 }
Season3 = Fall|09/21|12/20 {This would be September 21 to December 20}
Season4 = Winter|12/21|03/20 {This would be December 21 to March 20 }
(You can adjust the dates or add new seasons as you like. Just make sure the date ranges don't overlap; there was no check for this in the script)

4 - Make sure the device names you've defined in the ini DO exist by name (Including Location 1 (Floor or whatever you've used to define that in your system). If there are no exact matches you'll likely end up with an empty file.
5 - Re-enable the events.

The tracking phase will run for seven days and begin to build the DeviceTracking.csv file, provided your defined devices do exist. DO NOT EDIT this file. Each time one of your devices changes state during your defined times of day, an entry is made in this file and later used to create Away Mode events.
After the seven day period, the Season_1 file should be compiled and the DeviceTracking file will be deleted after which time the script will begin to control your devices..
Once that file has been created, you'll be able to edit it using the ASP page.

This is all from memory as, as I've said, it's been more than two years since I've looked at this and I don't currently have the script installed on my systems. It may be a while before I can do so to try to duplicate your situation.

I don't have an operational copy here myself at the moment having recently rebuilt my system, so we'll have to troubleshoot one step at a time.
It's been some time since I've done anything with this script, but it looks like you've been in Recording Mode since April 30th. This state shouldn't last more than 7 full days if the script is run regularly (once per minute usually), after which a Season file should have been created, and the temporary collection file deleted (this is the file you seem to be missing in the middle of the collection phase).
Since Daylight hours vary throughout the year, I'd also suggest defining at least four seasons (Spring, Summer, Fall, Winter), with appropriate date ranges. You could define as many as 52 seasons, one for each week of the year. Personally, I used 26 two week period seasons (Season_1 to Season_26). I know, the word 'Seasons' turned out to be a bit of a misnomer.

Do you have a file called something like \Data\Away Mode Random Lights\RandomLights_Season_1.csv ?


If you do have that file, and it appears to contain a complete set of data, I'd suggest this:
In the INI File, under the DATA section, set the following:

StartTime=
Counted=0
Compiling=
Recording =False
EditFile=1
LastEdit=5/1/2019 12:00:00 PM
.
If not, then delete that file if it exists, and \Data\Away Mode Random Lights\DeviceTracking.csv if it exists.
This should enable you to start from scratch. This might be the best idea in any case.

Note: It is important that the script be allowed to run uninterrupted during the recording phase.

I have the RandomLights_Season_1.csv file. But it is 0 kb. I dont have DeviceTracking.csv. How is that generated?

Thanks

[Wadenut]

I don't have an operational copy here myself at the moment having recently rebuilt my system, so we'll have to troubleshoot one step at a time.
It's been some time since I've done anything with this script, but it looks like you've been in Recording Mode since April 30th. This state shouldn't last more than 7 full days if the script is run regularly (once per minute usually), after which a Season file should have been created, and the temporary collection file deleted (this is the file you seem to be missing in the middle of the collection phase).
Since Daylight hours vary throughout the year, I'd also suggest defining at least four seasons (Spring, Summer, Fall, Winter), with appropriate date ranges. You could define as many as 52 seasons, one for each week of the year. Personally, I used 26 two week period seasons (Season_1 to Season_26). I know, the word 'Seasons' turned out to be a bit of a misnomer.

Do you have a file called something like \Data\Away Mode Random Lights\RandomLights_Season_1.csv ?


If you do have that file, and it appears to contain a complete set of data, I'd suggest this:
In the INI File, under the DATA section, set the following:

StartTime=
Counted=0
Compiling=
Recording =False
EditFile=1
LastEdit=5/1/2019 12:00:00 PM
.
If not, then delete that file if it exists, and \Data\Away Mode Random Lights\DeviceTracking.csv if it exists.
This should enable you to start from scratch. This might be the best idea in any case.

Note: It is important that the script be allowed to run uninterrupted during the recording phase.

Let's start by looking at your configuration.
Can you ZIP your Away Mode Random Lights.ini file (in the HS \Config folder) and post it here?

Here you go.

[Wadenut]

Let's start by looking at your configuration.
Can you ZIP your Away Mode Random Lights.ini file (in the HS \Config folder) and post it here?

I get this error in the log:

May-22 22.27.42

Error

Could not find file 'C:\Program Files (x86)\HomeSeer HS3\Data\Away Mode Random Lights\DeviceTracking.csv'.

May-22 22.27.42

RandomLights

Error reading the tracking data

My csv file is called: RandomLights_Season_1.csv

Anybody that know why?

Thanks

/Claus

[Wadenut]

Sorry for the delay. I've been away from the board for some time. First, I think you may need to rename the file to RandomLights.ASH in order to use it.

[Heychristian]

Thank you very much for this great plugin!

Can you please instruct how to view/execute the "ASP" page named "RandomLights HS3.ASH" so user can modify the schedule? For now, I'm connecting to the hometroller computer remotely and using Notepad to edit the file "RandomLights_Season_1.csv"

thank you

[Wadenut]

Perhaps another trap I can add then, although I think either ought to have worked.

[Stewart Baker]

As soon as you mentioned "date format" a light went on !

I had read the help .pdf without thinking that the UK and US date formats are different. DD/MM/YY vs MM/DD/YY.

I had |01/01|01/20 changing to |01/01|20/01 works...

Many thanks

Stewart

[Wadenut]

Hi,
I used your application about a year ago, and today I installed the latest version. You seem to have put a lot of effort into making it a very useful tool.

Everything is working except I get an error involving seasons. e.g.

Error in GetSeason: Conversion from string "01/20/2017" to type 'Date' is not valid.

As expected it defaults to season_0.

I wonder if there is something I have missed in the update.

Best regards

Stewart

hmmm. I wouldn't expect that date to cause an issue, but I do wonder why the script would be looking at January 20 at all now that we're in May. Are you using the format DD/MM/YYYY or MM/DD/YYYY or something else? I'd have thought all possibilities would be handled, but I may have missed something.

I did run into a problem with Feb 29 this year (my schedule had been generated last year) and did take steps to deal with that before I posted the update.

I'll ask you to ZIP up all of your schedule files so far, as well as your Configuration file and the Log snippit, so I can have a look. Just include the Zip file with a response. I'll try to duplicate the error.

[Stewart Baker]

Error in GetSeasion

Hi,
I used your application about a year ago, and today I installed the latest version. You seem to have put a lot of effort into making it a very useful tool.

Everything is working except I get an error involving seasons. e.g.

Error in GetSeason: Conversion from string "01/20/2017" to type 'Date' is not valid.

As expected it defaults to season_0.

I wonder if there is something I have missed in the update.

Best regards

Stewart

[Wadenut]

BUG ALERT

IF you have a season beginning or ending on Feb 29 (leap year) you will encounter an error. Since I've had no complaints, I expect I'm the only one affected so far.

I've fixed this in the upcoming version, but in the meantime, if you have this case, simply edit your config and change the season parameter to 02/28 in place of 02/29. The next leap year will be 2020.

[Wadenut]

I got it to work. I replaced your occupied device with mine and got past the initial error but the script did not like using the device code of I1. I changed Light 1 to the device location and name and it did work.

To that end, I can set the time for each device in your ASP but is there a way to define sunset instead of a fixed time? Also, I notice a couple of entries in the homeseer log every minute or so. Is there a way to suppress these? The log ends up with a LOT of entries and it is difficult to find other logged items. It would be nice to suppress log entries all together and enable them for troubleshooting.

There is no way to detect sunset/sunrise directly. My intention here was to use the "Home/Away" device as the switch to control this. What I'd suggest is creating a composite device, Night + Away, which you'd have to control via your own events of course. "Seasons" were meant to help overcome this as well by defining date ranges or periods during which a particular data (schedule) file is active. Originally there would have been four seasons, hence the nomenclature, however later I expanded this to a user defined set (I've defined 26 periods here, each active for two weeks. This seems to have worked well for me).

As for the logging, 1st you'll want to turn off logging for the script event; I expect you already have done this. Unfortunately however, HS has never provided any means to supress logging of delayed events such as those created by the script during Away execution. I find this annoying as well, but it's out of my control.