I've just tested this and it works OK.
This is only for testing and I've not used it but it does convert F to C.
Instead of copying into a variable, just copy it into a virtual temperature device.
EDIT: Probably better to use 1f instead of 2f as shown above.
Just tried your method and this works too.
Plus it's a hell of a lot simpler.
Spoilt for choice now!!!! 
@bobbles, thank you very much for all your help. I have now implanted this function and it works like charm 
. Now back to the issue I have with the webrequest issue. I have no clue why $response doesnt work as it should.
In HE, $response should already be parsed. Have you looked at $response.variable that you expect?
Otherwise would need to see more logs. You can do this as a private message to not share too much publicly.
Here is my test program
I would love to narrow this problem down, I have other webrequest and these are working fine, but these are most POST.
The only thing that diff is that this webrequest use a huge {token} that get fetched with a POST before the actual GET. All commands results with 200 even the GET but the $response is totally diffrent than it should be, Can it be the big {token tat messes something up.
Sure we can do this is private.
Thank you..
There are limits in HE for cloud endpoints of 128KB - headers. So if the data you are trying to return is really large, and you are using cloud endpoints, this could be an issue of truncation. See note 1 and 2 of this thread as it is mentioned.
I'm not sure if this is part of your issue or not.
New Release out today, see note 1 in thread for updates. It is available in HPM also
Can't update the piston either through package manager or manually.
Correction. I can get it manually.
Hi, I don't write that much but I currently have automations in WebCore to program functions to the Iris keyfob. One of those is to open the front door lock when one button is pressed and held. My issue here is that the lock doesn't respond to the lock/unlock commands from WebCore but it works flawlessly from the rule machine or the native button controller. I don't want to use it since I want it to work solely from webcore.
The lock is an August Smart Lock Pro 3rd Gen with the Z-Wave bridge. I had never tried using core for it until I realized that I wanted more custom functions related to the HSM.
It would help if you post the working rule from RM and the none working piston so others can try and help.
Well, I know for a fact that the lock is not responding to actions from WebCore but it is from the Button Controller (which internally uses Rule Machine). I replaced the lock with a switch and it worked as intended. The logs don't mention any issue with the lock, so to me it's a bug. I will share the piston as soon as I can. Right now I'm not at home and haven't set up anything for remote access, not even a VPN.
I'm having the problem of the $utc time being wrong. It looks like it is being set to my local time (ie, $utc = $now = $localNow). But my hub is set for my current location in Colorado. Is this a bug in Webcore for Hubitat? It looks like the times are right in Webcore for ST.
post your green piston here or as private message so I can have a look
In HE, webcore's time handling is done like unix systems.
Can you share you piston?
In unix there is only one time, and then display's adjust. The trying to handle long times based on timezone's is just strange and causes many other issues.
I got this. I was also trying to get an image of the global variables but for some reason, Webcore is giving me troubles now. If you need it, I will keep trying.
I circled the line that shows the problem. That calc gives me 0, whereas in ST, it gives me a -21600 (if I remember right).
Update: Here is a screen capture of the variables. You can see that $localNow = $utc.
Another thing about this piston. The calculations produce different results in Hubitat Webcore vs ST Webcore. I imported the piston from ST to Hubitat, so they are identical. Why should there be a difference? Actually, even the response from the URL is different between them. How can that be?
So this is a difference in HE vs. ST, but the answer is things are simpler in HE
The core difference is HE displays time in your hub's timezones, where ST does not. Timehandling in ST is schizophrenic, but not so in HE
In ST, you have the line:
In HE it would be
to elaborate. HE all internal times are unix times (epoch based). This website sends times in UTC, which datetime() parses into epoch. When you print epoch, it displays in your hub's timezone.
So I ran a test piston on my door lock and it worked.
Note I had to put a wait in, as my lock does not accept new commands so quickly after reporting unlocked. I have a Yale lock and I'm using the generic z-wave lock
Here is my test piston:
hi
how can I remove duplicate devices?
as an, it has cleared up it was show devices from my st that is now offline
Download the Hubitat app
