Passing a Time from Tasker to a Hubitat Variable

Hello, I'm one of the many new converts coming over from SmartThings when I heard they were shutting down WebCORE. I've built up rules in Rule Machine to replace most of the pistons I had in WebCORE, but I'm stuck on one thing. Hopefully someone can help.

I have a Tasker widget where I can enter my alarm clock time for the next day, and the widget then opens my alarm clock app so I could set the new time. With WebCORE, Tasker would pass the alarm clock time to a variable in WebCORE using HTTP to control when the lights and thermostat come on in the morning.

I've figured out how to pass illuminance values from Tasker to Hubitat using HTTP and a virtual device, but I'm stumbling on how to pass a TimeDate value. Can anyone help?

I know I could just change the value of the variable in the Hubitat Dashboard, but I like the simplicity of using the single widget to update the lights and thermostat, as well as my alarm clock.

It will be simplest to just use WebCoRE for this. After all, it runs locally on Hubitat.

1 Like

Have you created a date/time Hub variable (connector) and attempted to read or write to it through the Maker API?

1 Like

What if you used tasker to initiate a simple command of some sort on HE when the alarm goes off on your phone, that way if you dismiss the alarm those things don't happen, if that is what you may want. Alternatively, the Tasker profile could also be triggered by dismissing the alarm and send the same command to HE to start the actions on HE earlier.

This falls down somewhat if you want thing like the Thermostat to come on a little earlier to get the house warmed up or cooled down...

I didn't even realize that running WebCORE on Hubitat was an option, I'll check this out.


@LibraSun I did create a DateTime connector, but when I try to setTime, it doesn't update the value, and it shows the data type as a string. Am I messing up the syntax here?

@sburke781 I want to start the thermostat 10 minutes before the alarm, and turn on a light 30 seconds prior, so unfortunately this method won't work.

Although I have no experience setting a DateTime variable in that way, it most defiinitely is a String variable, as far as passing values, and I believe it is supposed to be in this format:


That would represent 5:52 AM on Oct. 4, 2022 (in the Central Standard US Time Zone or CST). Does that help?

NOTE: I haven't looked at the various Commands available to a DateTime variable connector, so I don't presume to judge whether you're "doing it right" as shown, above, lol. I'll experiment on this end and revisit this reply with my findings.

UPDATE: I tried the setTime and setDate commands but could not get either to work (the variable's current value remained unchanged), yet setDateTime worked as expected.

@LibraSun Thanks, I can make it work with setDateTime. I'll just need to enter 9999-99-99 for the date, which the hub will read as time only.

And for posterity/the next person, I'll write up what I had done wrong initially. In the process, I realized that I had set up the DateTime connector wrong. I had gone into Devices, then created a virtual device of the type "Connector DateTime". I should have gone to the global variables, created a variable, then selected Create in the Connector column.


I have no idea what you're talking about. Sounds like @mt113 got his problem resolved.

This is an RM specific bug in 118.

I'm saying that the following Maker API URL, when run against a Hub Variable Connector (dev. #504) of type DateTime, does not update the "Time" portion of the string value:

Similarly, this URL does not update its "Date" portion:

In both instances, the DateTime variable's value remains unchanged.

Am I doing it wrong? (If so, please let me know the correct approach, so I can go tell the other fellow who was attempting to set a DateTime variable from Tasker. Thx!)

Yes, those don't work. You'd have to send the full DateTime string in this format (last 4 digits are GMT offset, so this one is MST), using setDateTime:


Ah, OK. Here I thought all along that the setTime and setDate methods were intended to set those respective parts of the DateTime value. Please excuse the misunderstanding.

They are, but those are both 'pickers' that actually send a string in the above format.

1 Like

Use setDateTime, not setDate, as per my post above.

1 Like

There is a bug in the Connector DateTime driver for setDate. That explains why that part didn't work. Fix will be in the next release.


@mt113, I know you're all set with your workflow, so forgive this final ramble...
Are you content with the following required syntaxes, as they currently stand, for these Commands on a DateTime hub variable (connector)?




In particular, I'm asking whether you would prefer that setTIme allow just a time string without the need for that placeholder date?? Just curious. (If not, then I will concede that I must be in a very small minority of those who expected it to work that way all along. :slight_smile: )

  • Libra

@LibraSun I find the existence of a command called setTime that requires both a date and a time entry confusing. If it's meant to be a "picker", I'd prefer it to be named something different: getTime as a name comes immediately to mind.

I think my larger problem is poor/missing documentation of how to use the capabilities present in Hubitat, and not just this but many things I've struggled through the last couple of days. Maybe this is just me being a noob and not knowing where to look or what search terms to use, but it has been much more difficult for me to find out how to do things like this when compared to using WebCORE on SmartThings.

Where should I look to find out the things that I learned on this thread? Or is my best bet to just do a few different searches and then post a question when I come up empty?

1 Like

We are constantly working on the documentation, so if it's thin in some areas I apologize for causing you headaches. DateTime is sort of messy, no doubt, and needs better and thorough documentation.

Perhaps if I explain a bit it will make more sense for you. All of this started with a time picker input. You can see these in any app context where you can input a time. The time picker yields a string in the format YYYY-MM-DDThh:mm:ss.000-0Z00 with today as the date. Given that starting point, when we went to add date setting, it was natural to want to put the date into that same string. That provides a string recognized by all of the scheduling logic in the hub that includes both date and time. However, the date pickers don't return that string at all, only YYYY-MM-DD. What to do? When both are used, it makes sense to stick them both into the long DateTime String. But, if you have one of those strings, and want to know that it's only a date or only a time, we filled the missing part with 9's.

This is a bit messy when dealing with it at a low level. It works out OK at a UI level, as one can render these strings into any desired date and time format for presentation. Coming at it from Maker API means having to deal with the low level detail.

Hope this helps.

1 Like

I guess the final thing I've learned from this thread is to not hit my head too hard against my keyboard trying to find an already existing answer, but instead just ask after a few empty searches. I just never want to be the person asking the question that gets asked 5 times a day and has an obvious answer in the forums/documentation.

Thanks again for the help @LibraSun

1 Like