This is what I have seen.
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.
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
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?
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:
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"
Just ran one to be sure and got this response. Are you seeing that internal server error after about 10 seconds from clicking the link? If so that might be a timeout from their services trying to reach your hub.
You can verify by calling the execute link from the local hub api.
http://192.168.2.124/apps/api/#/execute/:##################:?access_token=#################
My cloud link that worked was below:
{"result":"OK","timestamp":1534771494249}
Did a restart to the hub and things are back to working.
Sorry for that.
putnamjwp,
I'm having problems getting {$hsmStatus} to work after the latest updates with message: "Variable '$hsmStatus' not found"
I have all of the latest updates that you just did but still getting that message.
Piston State:
Evaluation Console:
Here's the variable I have setup:
It does show to be displaying correctly on the Variables list:
I was seeing that too. It should work now with the latest piston.groovy file I just pushed.
I just the most stupid thing a NON NEWBIE should never do........... I now have 2 friggin fuelstream goovy apps installed because I AM FLIPPIN STUPID....
Now I can't delete the extra one
Whew restored last nights backup.........
Now I am seeing this error.....
`+673ms ║Unable to update setting 'dev' from child app. Open piston 'HSM show visual armed status change' and click 'Done' for faster operation`
1 Like
I see this is really old, but did you ever get this working? I have the same piston, and yeah worked amazing on ST. Cheers
Also getting the same here.
