Patched webCoRE for Hubitat (2018/09/09)

App Update

Good news for those who have been wanting fuel streams for hubitat. With the latest update, I've have made them completely local to the hub! For now you'll need to have a local webcore server running for the ui to reach them, but I've been talking with ipaterson on the webcore forums and he is going to be merging the UI changes dashboard.webcore.co in a few weeks. You just need to install webcore-fuelstream.groovy and have a local UI instance for now. There is a section in the app settings to manage them. The default size is 95KB per stream and that can be adjusted to meet your needs. Once over the limit the app will remove the oldest points to bring it under the size limit.

The code has also been changed so that it works for both Smartthings and Hubitat with just a change with the import statement below for the piston.groovy source.

import hubitat.device.HubAction
import hubitat.device.Protocol
//import physicalgraph.device.HubAction
//import physicalgraph.device.Protocol

This also includes a fix for the location id bug in Hubitat, along with the latest UI changes from ipaterson. Be sure to logout and do a hard reload of the dashboard once updated.

If you are running a local instance don't forget to run these commands:

cd
cd webCoRE/
git pull

Also, if you haven't switched from @ajayjohnm's repo to mine, run these before doing the above:

Patched webCoRE for Hubitat (2018/04/10) Code Share

@Matthew Try this: cd ~/ cd webCoRE/ git remote set-url origin GitHub - jp0550/webCoRE: webCoRE is a web version of CoRE git fetch origin git reset --hard origin/hubitat-patches Make sure you do git reset --hard origin/hubitat-patches above as it's showing as a comment but should be fully pasted.

4 Likes

I've just followed this and defined a fuel stream.
Unfortunately when I click on 'Fuel Streams' all I get is the spinning webCoRE circle.
I have logged out and back in again.
Here is a screenshot from my RPi. Does this look correct? Any ideas why this does not work for me?
image
The new fuel stream directory has been defined OK and has the groovy code inside it.
image

The code for the raspberry pi is only for the dashboard directory for the website. Did you update all the apps in the ady624 and install the new app webcore-fuelstream in the app code section on the hub?

I have been to the github repository and updated the original 4 files and defined the fifth one. (Fuel stream groovy file) in the Apps of the HE.
I then followed the instructions as per post 474.

In the app settings page, underneath where you usually set your devices, is local fuel streams checked?

If it is, did you do a hard reload of the dashboard by holding down Ctrl and F5 while on the webcore ui?

If it's none of those I'd try navigating to it in incognito mode or checking the log output while writing or viewing the fuel streams.

Yes. It is 'ON' as you show above.
I logged out and logged back in again AND did a hard refresh.
Before I did this I was getting the 'New Version Available, please hard refresh' banner.
This has stopped since I have completed the above.

Anything in the logs? If you hit F12 in Chrome right before you click the link, and hit the networking tabs you should see a line like this indicating it's hitting your local instance

where the link is list, your hub ip is at the bottom, and your access token is at the top.

This is what I have seen.
image

Looks like you're still hitting the external fuel streams (which don't work)

Reasons for this could be:

  • Don't have new dashboard code branch or a cache issue (can check by going to F12 in chrome, clicking sources, clicking js/app.js and looking for the listFuelStreams function like in the screenshot. You should see changes like "instance.fuelStreamUrls"

  • Local fuel stream setting is not being picked up. Maybe try clicking save while on the settings screen that you were one before. You can confirm it's working by going to apps and looking for the new fuel stream after you write to it you should see it underneath the app section:

  • Some bug is messing things up somewhere. Try checking the logs when you write to a fuel stream or try to pull them and look for errors.

Most likely it's bullet point #1 as your screenshot shows your are still on v0.3.105.20180628 when it should be v0.3.107.20180806

I noticed the date error when I posted the screenshot.
Also the fuel stream I defined is not defined as a fuel stream.


At the bottom of my piston list I do have this though.

Also in the piston groovy I have this.
image
Which makes me think the code is at the latest version.
Very strange.

Just for clarification, where should I go in the github repository to get the latest file versions.
I use the repository at the start of this thread. Is that correct?

OK. Found the issue. I had to go in and clear the cache even though I had completed a hard refresh.
Thanks for your help.

1 Like

@bravenel @chuck.schwer

How do child apps that are managed only with the parent use "settings." Webcore uses these for caching devices (mainly) and for other metadata. I have not found a way to create a setting using only the app api methods.

app.updateSetting('bin', [type: 'text', value: state.bin ?: ''])
app.updateSetting('author', [type: 'text', value: state.author ?: ''])

These are some examples that never set the setting. In smartthings, if it did not exist, it would create the setting for you. In Hubitat, without having it on the app settings page and clicking install, these type of calls are not working in child apps (which isn't feasible in webcore since the user never manages the child apps themselves). Is there a way to get these working? Without it, with the latest update's changes, it takes several hundred milliseconds to grab the devices from the parent app.

I'm having a hard time understanding what those are used for.. for instance. what is the setting "author" used for, where is it accessed?

Those were the metadata settings I was referring to. The important one is:

private void updateDeviceList(deviceIdList) {
	app.updateSetting('dev', [type: 'capability.device', value: deviceIdList.unique()])
}

Wherever possible, webcore tries to grab the devices for the piston from it's setting cache 'dev', if it comes across a device it doesn't know, it queries the parent for all available devices and matches it against either the id or name.

When the app starts up, the devices are populated

rtData.devices = (settings.dev && (settings.dev instanceof List) ? settings.dev.collectEntries{[(hashId(it.id)): it]} : [:])

If it can't find it, it queries the parent, which has the authorized devices:

def device = rtData.devices[idOrName] ?: rtData.devices.find{ it.value.getDisplayName() == idOrName }?.value
    if (!device) {
    	if (!rtData.allDevices) rtData.allDevices = parent.listAvailableDevices(true)
        ....
        rtData.updateDevices = true

The call to parent.listAvailableDevices(true) is expensive (several hundred milliseconds, a majority of the spin up time) for time sensitive automations so if the app had to grab a new device, it stored it in it's local settings .

if (rtData.updateDevices) {
    	updateDeviceList(rtData.devices*.value.id)
    }

Before the latest update, the app was leveraging allDeviceIds to get around this, but it looks like that is no longer populated for security reasons. With it's absence, can the settings be updated so that they can be managed through the app like they could in Smartthings?

When I create a Fuel Stream, it does not get allocated as a 'webCoRE Fuelstream'.
It shows up as a piston.
I have disabled/enabled 'Local Fuelstreams' in the settings, switched repo's as per post 474, updatedto the latest files and generally had a good play to try and get this to work but it just doesn't want to play. I'm using an RPi for my local server and a new file has been created.
Anyone have any ideas what else I need to do/try?
image

I seem to be having an issue restoring a piston from my ST-based webCoRE instance... I've got auto backup turned on on that side, I grab the backup bin code, switch the drop-down to my Hubitat webCoRE instance on the dashboard. Then I try to do New Piston -> Restore a piston using a backup code -> paste my backup bin code, then hit Create. I then get this message on the webCoRE dashboard on the new piston:

image

and this in the Hubitat Logs:

Any ideas?

Is your HE webCoRE instance running locally?
If it is you will not be able to copy in from the webcore.co

I took a look at the source, and it seems like private backup bins are restricted to the account they are created from (smartthings account id or hubUID for hubitat):

return $http({
method: 'GET',
url: 'https://api.webcore.co/bins/' + md5(inst.account.id) + '/' + binId,

A public anonymized bin should restore just fine though.

I have been using external apps like Workflow to send actions over the webCore which has been working fine until recently. I just realised, that using the cloud.hubitat.com extension no longer works. My format was:-

https://cloud.hubitat.com/api/12345-ab12-1234-124332ndufwd/apps/1/execute/::?access_token=<access_token>

Using IFTTT still works - replacing 'execute' with 'IFTTT/'

Was there a change to the 'execute' command? As it was working well for me until recently.

I get an error message saying "Internal Server Error"