Yes, I tested the Pushover device. Unknown device is my Pushover device. I just looked at the logs and it appears to be seeing the thermostatMode as false for both heat and cool. Which is odd because right now Ecobee is in heat mode. But when I check ecobee it has the modes as Heat, Cool, Auto and the choices in webcore are heat, cool, auto. I am wondering if this makes a difference.
You're conflating Thermostat Mode and Current Program which are different. Can you post the logs from webCoRE?
I just imported your piston from the backup code and did not modifications and it worked perfectly.
Here is all that is in the logs;
11/17/2018, 5:52:58 PM +248ms
+1ms ╔Starting piston... (v0.3.108.20180906)
+94ms ║╔Subscribing to devices...
+107ms ║║Subscribing to EcobeeTherm: Ecobee.currentProgram...
+122ms ║║Subscribing to Jane's Pushover...
+123ms ║╚Finished subscribing (31ms)
+149ms ║Comparison (enum) is (string) cool = false (0ms)
+153ms ║Comparison (enum) is (string) heat = false (1ms)
+160ms ╚Piston successfully started (158ms)
11/17/2018, 5:40:34 PM +601ms
+0ms ╔Starting piston... (v0.3.108.20180906)
+92ms ║╔Subscribing to devices...
+110ms ║║Subscribing to EcobeeTherm: Ecobee.currentProgram...
+144ms ║║Subscribing to Jane's Pushover...
+145ms ║╚Finished subscribing (54ms)
+167ms ║Comparison (enum) is (string) cool = false (0ms)
+171ms ║Comparison (enum) is (string) heat = false (0ms)
+178ms ╚Piston successfully started (178ms)
Can you post a screenshot of your ecobee's attributes?
Funny thing is it doesn't show any Current status info.
Then that's your problem. There is no attribute for it to react to. Do you have the Ecobee suit manager app installed and configured?
Yes, I have Ecobee Suite Manager. I thought everything was configured. Maybe I will need to re-install it.
@Ryan780 I uninstalled all of Ecobee Suite and Devices and re-installed and now I am getting a Current Status in the Main Thermometre. Hopefully this will help with my Pistons working now. 
Thanks for all the help! Hopefully I will be able to get the Alexa Skill working soon!
Can't help you on that one, I am a Google Home guy. 
So, I think I might have figured out two things that are causing other people to see race conditions or hub lock ups. Whenever you execute a piston that modifies a global variable, I am seeing in the logs that EVERY piston that uses a global variable is evaluated. If you have a ton of global variables, I can see how this would very quickly cause major problems with your system.
Also, if you are using an external link trigger, like from IFTTT, when that event is received, every piston that has an IFTTT trigger in it will also be evaluated, to see if it's the right piston to execute.
Between these two, I'm almost positive that is what was causing some of the major lock-ups people were seeing. If you have 15 pistons that set global variables and every time one of them is changed it has to re-evaluate every piston, that is going to cause a HUGE drain on the resources of your hub.
I still experience occasional lockups on my hub, and I haven't isolated the problem to webCoRE, but Support was definitely leaning that way when the firmware update caused major issues for most/all webCoRE users a while back. However, I don't use global variables in webCoRE or external link triggers, and I only have two pistons (plus a few more "paused"). My hub, however, still occasionally locks up, but now it's mostly just after I start it when I try to load the piston child apps to click the "Done" button (and make them go faster the first time they run). So, while that may explain some people's problems, I'm not sure it explains mine. But then again, I don't have constant lockups.
FWIW, I'm also apparently capable of locking it up myself by writing bad custom app code--I think I was writing an app and pointed "nextPage" accidentally to one that didn't exist, and the only response I was able to get from my hub was by CURLing it a POST to reboot, which still took a couple minutes to respond. While they don't claim to be a developers' platform and aren't responsible for saving us from ourselves, I wonder if there isn't a bit more they could do to prevent runaway apps from taking the whole hub down (something I thought the update that broke webCoRE for many was actually supposed to help with).
Yeah...your problem can't be webCoRE because I have a dozen pistons and before today was using 10 different global variables and I still never had a lockup. And I never had any issue during the firmware update either.
I haven't tried to attribute the hub lockups to a single piston yet and I came back here to see if it has been solved. I do use some global variables but nothing super crazy or is only used by maybe a couple pistons. I did have several pistons that were set to fire trough a remote trigger and is probably one of my main uses of webcore is to send push notifications or run things on the hub when one of my diy devices makes a webhook to webcore.. That said I only had about 6 active pistons at the time of my blunders... I'm kind of nervous to re instate them as I have left them all paused since that day.
I'm getting a notice from Webcore that it needs to be updated to a 12/2018 version. I updated the version in ST, but I cannot find the updated version for Hubitat. Does it exist yet?
The latest update was mostly for an ST issue.
Hi everyone
Firstly, Happy New Year to you all.
I am now awaiting my new Hubitat hub to be dispatched from the US.
I am currently planning my migration across from STT.
On STT I use a mix of Smart Lighting apps and webCoRE pistons.
The Smart Lighting apps for simple lighting and to encapsulate 2+x motion sensors into a single virtual switch in rooms.
Having just read this discussion I am wondering if its easy to port my pistons across from STT? The pistons address things like the level of luminance in our house and then lighting that depend on the current level of illuminance etc...
Or will it be better to use the Rules Machine and then fill the gaps with webCoRE
I look forward to reading your suggestions.
ps. I see the god @bangali is around these parts. Has the room manager been ported across then?
yes 
WebCoRE running on Hubitat is know to cause hub performance issues. Therefore, the Hubitat Staff has made it their policy that if you experience hub issues, and have webCoRE installed,the first thing they will ask you to do is remove webCoRE before they will be able to provide support. This sounds worse than it actually is. You can easily backup your Hubitat hub’s apps, devices, and settings before making any changes. That way you can restore this database backup afterwards should you find the problems lies elsewhere.
With that being said, I would recommend that you use the built-in Apps, including Rule Machine, to perform as many of your automations as possible. This will provide the best performance and make your system simpler to support in the long run.
