Looks like some this is down with WebCoRE. I'm unable to get browser registration codes for both hubitat and Smartthings.
1 Like
Looks like the cert may have expired…
I love webCoRE but this kind of thing makes me nervous. I run everything local but this is the weak link that I wish could be solved.
Although not recommended, if anyone needs to bypass the security on chrome there is a way.
Search google "chrome thisisunsafe list"
1 Like
You can set up an RPi to run as a webCoRE server so you install/edit/delete pistons locally.
That is what I am doing now. Right now I have no trouble creating/editing/deleting pistons. The problem is registering new browsers. IMO The relyance on api.webcore.co is a weak link.
I'll chat with @ipaterson on ways this can be removed from local deployments of the server.
Something else to check BTW:
When you setup a local webcore server, there is a URL customized to that
HE console -> Apps -> webcore -> Dashboard
I think if you copy and save that, it should be direct (local) access
2 Likes
I think when we have discussed it in the past there were two options – either reverse engineer that endpoint and host it elsewhere to preserve the convenient 4 letter code or allow pasting in the full API URL that targets the webCoRE instance running on your hub. If the registration screen in the dashboard supported a URL then we could also make it accept a custom registration URL like http://192.168.1.99:12345/f4uz (where f4uz is a generated PIN code) for those who want to self-host registration locally.
Hosting the reverse engineered endpoint publicly just puts someone else in charge of renewing SSL and keeping it running, so I think an all-local approach is better. If pasting a large URL is not a problem the simplest approach would be for the HE version to replace that registration screen with a "paste this text to register a dashboard"
1 Like
certificate should be fixed.
3 Likes
I just added a few new devices and added them to WebCore. I replaced some older devices with these on about ten different pistons, and they seemed to be running, but I will see tonight. However, when I look at the old devices, they show that they are still in the pistons I changed, and when I look at the new devices, they show no piston association. Any ideas?
This may not be a solution for you, but it seems to work for me. When I replace devices in a piston with new devices, many times the old devices stick there for a while. If I wait long enough, they seem to replace with the desired device. However, I have had success with going back into webcore from HE and going to the add devices area and un-click the new devices, and then re-click the new devices, and save all the way out. That SEEMS to replace the old devices with the new devices faster for me.
you can pause / resume the piston and see if that adjusts it.
Nope tried both and neither one worked.
I even tried to duplicate the piston and saving that and that did not even work. In fact the new piston that I made does in the list of piston in the new device.
What would happen if I removed the app and reinstalled it. Would that make a difference and would I lose anything
If I create a new piston with the new device it will show up in the list of pistons on the new device. I tried to delete all devices out of the piston, save, and put them in again and save and it still did not show up in the list. It is like the pistons are corrupt but still run
Who-hoo! There's an update in HPM for webCoRE with the following notes: "Latest release for Hubitat to run webCoRE pistons locally on HE - bug fixes, fix stays statements"
1 Like
As mentioned, pushed new release out.
Note 1 has been updated with the release.
It is fixes and optimizations.
1 Like
Any chance the update broke the feature where pistons run based off a global variable changing?
I updated yesterday evening, and noticed this twice already. Might also be due to the fact that I had some power flickering yesterday, as we had a bad storm.
To explain my system as simply as possible: I have a piston which checks a weather API and updates a global variable with a value of 1-5 (integer) based on outside brightness. Once it gets to a 2 or 3 certain lights begin turning on. The piston runs every 10 minutes as that is the refresh of the device API. I just checked that piston and the global variable was set to a 1 (one being dark, 5 being bright). It seems to be working just fine though.
I have 4 pistons that I can think of currently that all run when that global variable changes. None of them had run since this morning. Hitting test caused them to run and function properly for the time being.
I don't think the power outage had any effect on this, as even if the device was on / off and Hubitat thought it was different, the piston still should have ran. I say this because some lights turn on when the power is restored to them, and if they were off, then Hubitat thinks they are still off.
Hubitat, as well as the rest of my network is on UPS devices, and the power wasn't out for more than a second. Though it was enough to flicker the lights, and power off the TV.
Any thoughts why this might be happening? I'll keep monitoring from my end and post updates if it starts working properly. Though this is one of those cases it really only happens twice a day (sun up & down) so its lengthy to monitor.
2 Likes
My global variable changes have all been running properly (both in production and tests).
If you have details of this, send private message with logs for the piston and the global variable events.
1 Like
Hello,
I have noticed this. A day after I updated, some routines weren't firing and I did all kinds of nonsensical things to try to fix. I eventually figured out that it was my 'house awake' variable was not being represented properly and it was only THOSE pistons that contained a conditional global variable weren't firing.
I pulled my hair out for two days, tore down the code, cleared out the variable, and it still seemed to not be working correctly.
At this point I still didn't realize this could be a bug. I reverted my entire hub to 3 days prior and it was the old version of webcore and everything started working again.
After a day or two, I absolutely couldn't stand that there was an update available that I had not applied despite me somehow irrationally blaming the new version on this one tiny component having issues. In my mind it could've been a zillion other things.
I downloaded it again, I was getting messages about the WC DB not being aligned with the same version number. I'm sure its because of the way I reverted. But more importantly everything started working and all was right. WRONG!
It appeared to be working because in the time that I did all this my house awake global variable had gotten manually in sync. This was all coincidental, a day later (yesterday/today) I realized it was having trouble again. So AGAIN I just tore down my code and mary kondo'd it because I was convinced I again have done something wrong. Of course everything is working now but thats just because the global variable is in synch and it will be out of synch by tomorrow.
I still did not realize this was a bug until I accidentally saw this thread and your description fits exactly what is happening to me and its been repeatable through two installs of the new version.
I know how to provide HE logs but I don't do much log reading in WC (although it's my only rules engine). But ill get them whereever they are. You just need the logs from where the global variable is supposed to be getting changed/triggered?
I have pushed an update for the subscription error.
For pistons that have a subscription problem pause/resume or edit/save will update the subscriptions for that piston
4 Likes
I did the updates and resaved the pistons. I'll let you know how it goes tomorrow. I absolutely can't do testing on this global variable when others are asleep
