webCoRE for Hubitat Updates

Thanks for the idea...WOW that was so simple !! my brain is not wired for simple : ( I implemented it and even added a 70sec wait which I thought would break it but it works perfectly.
Thanks again !

1 Like

I've just started to migrate to HE from ST and I'm finding a few things related to the time/date subsystems that are, well, different. Some better, some not so much.

I've simplified/cleaned up the instances like this example, which is great.

What's odd is having everything report in my hub's timezone including UTC. Some of my pistons calculate different functions based on UTC. This is especially true of API calls and webhooks.

Even internally, $utc = $localnow so there's no way to do any difference calculations to UTC. IMHO, UTC should report UTC not a localized version of UTC.

Am I missing something? Is there a simple way to grab actual UTC or do we need to now that the logic difference between the ST and HE implementations of webCoRE and calculate UTC locally:

RealUTC = $utc+$tzOffset

I'm okay doing that, it just seems odd.

The view is time is the time.

If parsing a time string it should end up as a time

and then there is printing out time to a timezone.

In general most folks only display time on their hub in a single timezone. You may get strings written in various format of ISO 9660, but they all end up with time

So ST made you know timezone to parse strings, where the strings (or numbers) can just be given to webcore. These are the cause of bugs in ST in DST handling, etc....

Fair enough.

The only part that seems odd is having both the $local and $utc epochs as the same value so doing datetime calculations based on UTC requires an additional step. Easy enough to calculate the difference.

I do agree (and like) with not having to deal with time zones when it comes to parsing string.

I don't think there is any additional step.

You can take any time string and convert it to time (or date, or datetime) and print it. While there are variables for tzoffset, in reality you don't need to use this in my view.

ST went thru all kinds of gyrations to sometimes keep time in UTC, and other time UTC-TZOFFSET for no good reason, and often just to cause confusion.

The real questions become
you get time from apps in what string or number formats, and how do these convert to time/datetime/date (which on HE are all UTC)

Then you print an internal time (always in UTC) and HE will print it out in the hub's timezone setting. in short, now should always be now, not some gyration of now. HE added TZoffset if you want to know your tzoffset, but you don't need that to understand now, or now + 4 hrs. It is a factoid.

Webservers can return time in UTC or another timezone, but that is encoded into the string they send, so send midnight UTC or 19:00 EST is the same time....not two different times.

Understood. We're saying the same thing. Once we get past that it's different between the two implementations, the HE implementation makes more sense.

I do see one other odd thing with dates that isn't timezone related. The Date() functions doesn't work as expected. Not sure if it's a bug or I need some enlightenment.

Take the epoch for midnight today, 12/03/2020: 1606971600000 [Date("12/3/2020")]

ST and HE disagree by three hours (10,800 seconds):



My timezone is GMT-5 so 1606971600 is correct. Why the three-hour difference between the two implementations?

I noticed this in moving over one of my pistons that makes an API call which returns data with an "observed date" element and an "observed time" element. When I use:
"AQI "formatDateTime({addHours(date_observed[api_index],hour_observed[api_index])}, "EEE M/d h:mm a ")
the resulting datetime is off. ST has it correct, HE says the even happened three hours later than the actual data elements.

What am I missing?

I would suggest that using $midnight might be a better solution that does not rely that today == midnight (or $noon) for similar purposes

I did make this change as part of the problem in handling DST processing was to move $date to a time outside the DST move around (if you are in a zone with DST).

I think you can also use "10:00" to get 10:00 AM today for example This is more precise than trying to do the math yourself as it will deal with DST processing.

1 Like


Is it possible to get the hub's latitude/longitude/zip code in WebCore?

If you set up locations (Settings|Places) in webCore you can then retrieve the stored information using something like:

I was looking for a way to get the default location set up in the main Hubitat settings, which is accessible through their own API's location object...

Don't see it natively in webCore, but if you create a device using this driver:

 * Hub Info
 *  Licensed Virtual the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *      http://www.apache.org/licenses/LICENSE-2.0
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 *  for the specific language governing permissions and limitations under the License.
 *  Change History:
 *    Date        Who            What
 *    ----        ---            ----
 *    2020-12-07  thebearmay	 Original version 0.1.0

static String version()	{  return '0.1.0'  }

metadata {
    definition (
		name: "Hub Information", 
		namespace: "thebearmay", 
		author: "Jean P. May, Jr."
	) {
        	capability "Actuator"
		attribute "latitude", "string"
		attribute "longitude", "string"
		command "configure", []

preferences {
	input("debugEnable", "bool", title: "Enable debug logging?")

def installed() {
	log.trace "installed()"

def configure() {
    if(debugEnable) log.debug "configure()"
    sendEvent(name:"latitude", value:location.getLatitude())
	sendEvent(name:"longitude", value:location.getLongitude())

def updated(){
	log.trace "updated()"
	if(debugEnable) runIn(1800,logsOff)

void logsOff(){

and add it to webCore you should be able to use it to get the lat and long.

I can add these

If you are doing that, would you also please add the time zone ID?

I'm not sure I have that in HE. If you know the variable let me know, but I think it uses old style time functions.


There is an update to the piston file with $latitude, $longitude, $zipCode and $tzId

Separately, if you use local webcore html server, there are updates to the files for html/css.

These updates are on staging.webcore.co at this time (but not on dashboard.webcore.co)

1 Like

They look correct to me, thanks.

Is it possible to put the system variables section in alphabetical order?

New update posted

It sorts system variables for display in webCoRE IDE UI

There is a new driver for users of $weather, that provides an event when $weather is updated - so pistons using $weather can be event driver to run after an update occurs to $weather variable. The piston will need to decide what changed for values, the 'updated' event provides notification that webcore updated $weather.

If you use HPM, you have to use 'modify' to select to add this device handler.


Manual piston state seems to be broken in this update. I have a bunch of pistons with automatic piston state disabled, and the custom status strings no longer display on the web dashboard.

Edit: the $state variable shows the correct string when I open the piston, but the state string no longer shows up in the piston list, or at the top of the piston in the "state" field.

sounds like you should clear your browser cache. There were no changes in these areas. All my test and product pistons are working correctly.

You might also reboot your hub.

1 Like

Download the Hubitat app