[RELEASE] Date Time Parser driver (aka schedule_ur_garbage_cans)

Okay. so most fun I've had in months! First, playing with dashboards all over the place then. actually writing a garbage can rule using this driver! Short. and. Sweet.

Another use case - water the lawn every other day

Another use case - Tell the kids to wash the car on the 15th each month

Thank you for this code! This is going to come in VERY handy in a few projects I'm currently working on.

I did notice that the TimeHour24NumNoLead is still showing a leading zero for me. This isn't something I need to use, but I just thought you might want to know.

2022-01-23 08_55_24


I have debug and descriptive text turned off. Is there a way to turn this off to not show in my logs?


1 Like

Hi @fdwilson and @curtisZM
Nice catch on the 24hrnolead. I missed that! I set a debug on check for the update line. thanks for that one too!

do HPM Repair to get an immediate update to 0.2.7 on the driver.

Working. Thank you..

Thank you!

I have a question, related to ComparisonDate.
I would like to use this as a trigger in RM, as per the following:

Unfortunately, it insists on the comparison to a numeric field, instead of a character field.
Isn't ComparisonDate a string field?

hi... sorry - but I defined them as numbers when I declared. They are concatenated or derived from other number fields. it seemed most efficient.
attribute "comparisonDate", "number"
attribute "comparisonDateTime", "number"
attribute "comparisonTime", "number"

Do you need string versions? it's no bother really to add 3 xxxxxxStr variables...

Done. I added 3 more variables in as xxxStr for the three comparison values. Hope that helps. (Run HPM upgrade or repair to quickly obtain.)


I think that there might be an issue with the update of the device.
As you can see in the attached screenshot, although it is Jan 27 (lower right corner), the device shows that it is only Jan 26 (even though it's updating every 5 minutes):

I just noticed my wasn't up-to-date. I hit Refresh, and I got this in my logs:

Which comes from this line:

 schedule("0 0/${AutoUpdateInterval} * ? * * *", refresh)  //* 0/45 * ? * * *

AutoUpdateInterval is the last preference. I clicked "Save Preferences" and the next Refresh didn't throw an error but instead installed the cron schedule.

I suggest doing that.

Mine is updating now, but something is wrong because it is rescheduling the refresh 11 times according to the logs:

I don't see how this is happening in the code. Those two log messages come from schedUpdate() (and I didn't have debug logging turned on, or else there'd be a third message). There was only 1 scheduled job shown in the device.

I've turned off automatic updates to see if I can stop it.

hmmm. I'm not seeing that in my logs, the looping of the schedule. as to it throwing a null... That I believe is for an attempt to set it out of range, which I dont' check as the drop down only sets from 1-59... but. maybe you have an older version? have you don the 'update' or repair from HPM? should be on the .28 version
I'm tearing down my office tomorrow to move to a new location. maybe I can look tonite, else I need to hold off on checking this out. Any idea how you got an out of range value on the schedule?

I did install this before it was in HPM, but when you added it there I did a Match Up and have been updating from HPM for the last few weeks. I was up to date (0.2.8), but I did just do an HPM repair anyway to refresh it. The code did not change.

I have no idea how it got "Null" for AutoUpdateInterval; I've had it set at 5 minutes since I installed.

I waited past 2 update intervals with no intervening logs before I turned automatic updates back on. The multitude of schedule updates is still happening.

So I'm not sure why this is happening. Only one job:

I've deleted the virtual device and re-added it to see if that will clear this up.

Looking at the logic, I don't understand how this can happen.

However, I would think you'd only want to call schedUpdate() when the preferences were changed, instead of calling it every time the event goes off. Otherwise, you are just constantly unscheduling and rescheduling the cron entry.

Nope, now I got 12 update messages. Now I'm doing a shutdown/restart of the hub just to be sure (it was up for 25 days). UPDATE: that didn't clear this up; I still got 7 update messages.

thanks for all the input - While it isn't obvious whats the problem, I'm sure I can find the solve. maybe set your update for now to some longer period so you dont overwhelm the logs. I'll look at in in a few days as I'm moving my house atm!!

1 Like

It is August 12 as I type this. The attribute "WeekOfYearNum" indicates 2. I just noticed this. Is it possible it should be called "WeekOfMonNum"?

"WeekOfYearNum" would be good to have too!

most excellent catch. in my date pattern i used W. I should have used w. Per your suggestion, I also put in WeekOfMon, WeekOfMonEven and WeekOfMonOdd. Run Package Manager update to get 0.3.0 and you should be golden.

Download the Hubitat app