Using webCoRE with Hubitat


#61

In the Dashboard app, Adrian wasn’t even declaring a handler for the response data. The Asynch Put was truly a ‘fire and forget’ call, just to update the Dashboard. Making is Asynch meant the code never had to wait for a response. Using the standard httpPut() call, the code will have to wait for a reply. If anyone knows of a method to avoid this, I am all ears. I’m just hacking my way through each error as they pop up! :wink:


#62

So the good news is, waits do indeed now work correctly. But something still isn't right with the execution. Tried this simple piston (turn light on, wait 4 sec, turn light off):

The piston triggers properly and light does turn on, but never turns off; log shows no errors (that's the scary part) and says that physical command execution was skipped because it would make no change to the device:

+1ms ╔Received event [Deck Light].switch = off with a delay of 94ms
+221ms ║RunTime Analysis CS > 161ms > PS > 15ms > PE > 45ms > CE
+269ms ║Runtime (36586 bytes) successfully initialized in 15ms (v0.3.000.20180224) (268ms)
+270ms ║╔Execution stage started
+553ms ║║Comparison (enum) off changes_to (string) off = true (1ms)
+554ms ║║Cancelling condition #2's schedules...
+555ms ║║Condition #2 evaluated true (277ms)
+555ms ║║Cancelling condition #1's schedules...
+556ms ║║Condition group #1 evaluated true (state changed) (279ms)
+557ms ║║Cancelling statement #3's schedules...
+569ms ║║Executed physical command [Kitchen Sink Light].on() (8ms)
+570ms ║║Executed [Kitchen Sink Light].on (9ms)
+575ms ║║Executed virtual command [Kitchen Sink Light].wait (0ms)
+575ms ║║Waiting for 4000ms
+4581ms ║║Skipped execution of physical command [Kitchen Sink Light].off([]) because it would make no change to the device. (1ms)
+4582ms ║║Executed [Kitchen Sink Light].off (3ms)
+4585ms ║╚Execution stage complete. (4314ms)
+4591ms ╚Event processed successfully (4590ms)

As I recall CoRE had an option to turn off command optimization but I can't seem to find a setting to do that in WebCoRE.


Patched webCoRE for Hubitat (2018/09/09)
#63

Maybe the status of the device isn’t being recognized as changed even though the command was sent? Is there a way to confirm the device is on after sending the “on” command?

IF the light is already ON when you send the piston, does it then turn the light off?


#64

Agreed, WebCoRE isn’t seeing the correct state of the device; I don’t think it is sending out the off command (though the log implies it is, somewhat contradicting itself).Turning off the optimization might be an easier workaround (especially if there is a setting somewhere), finding out where the state is being kept (and why it isn’t correct) sounds a lot more difficult.

So when the light is already on, it does turn off after the delay. In this case the optimization (on the front end) works as shown in the log:
3/5/2018, 11:54:49 PM +90ms
+0ms ╔Received event [Deck Light].switch = off with a delay of 100ms
+182ms ║RunTime Analysis CS > 123ms > PS > 16ms > PE > 44ms > CE
+233ms ║Runtime (36587 bytes) successfully initialized in 16ms (v0.3.000.20180224) (232ms)
+234ms ║╔Execution stage started
+545ms ║║Comparison (enum) off changes_to (string) off = true (1ms)
+546ms ║║Cancelling condition #2’s schedules…
+547ms ║║Condition #2 evaluated true (305ms)
+548ms ║║Cancelling condition #1’s schedules…
+548ms ║║Condition group #1 evaluated true (state changed) (306ms)
+550ms ║║Cancelling statement #3’s schedules…
+558ms ║║Skipped execution of physical command [Kitchen Sink Light].on([]) because it would make no change to the device. (3ms)
+558ms ║║Executed [Kitchen Sink Light].on (4ms)
+562ms ║║Executed virtual command [Kitchen Sink Light].wait (0ms)
+562ms ║║Waiting for 4000ms
+4582ms ║║Executed physical command [Kitchen Sink Light].off() (11ms)
+4584ms ║║Executed [Kitchen Sink Light].off (14ms)
+4586ms ║╚Execution stage complete. (4352ms)
+4592ms ╚Event processed successfully (4592ms)


#65

Code around line 1677 of WebCoRE Piston is relevant to command optimization. It can be disabled in that line (by setting disableCommandOptimization from false to true). My test case now works! Not sure if this has any other side effects (and it is only masking the problem); will keep peeling.

Needless to say, it’s probably not a good idea to sequence any rocket launches with WebCoRE on Hubitat at this time.


#66

@Tony WebCoRE does allow you to set the command optimization as well. Simply edit the Piston, click on the piston title to take you to the “Piston Settings” screen, click cog, choose Command Optimizations and then choose Disable


#67

Oh yes, there it is… I was beginning to think I imagined that settings screen.


#68

So did you guys get it to all work? Anybody sharing the code?


#69

@ogiewon created a github repo a few posts up. I have a couple announcement pistons that would be slightly difficult to recreate in Rule Machine (with a lot of local variables) running without issue. I also have the dist folder running on a local web server, so everything including the web interface is running locally! I tested a simple lighting automation and Rule Machine is noticeably faster. There’s a lot of overhead with webCoRE. Right tool for the right job I suppose!


I'm a newbie again... Yey!
#70

Thanks for all that, I was should have it up and running shortly. Does your statement above mean Webcore’s TTS works with hubitat? Also, I have a 24/7 machine sitting next to me what do I need to do to get this all running local?


#71

I actually haven’t worked with webCoRE TTS, so not sure if it’s working. I’m using a custom driver to call a speak() command.

Nice! Just to be clear, the pistons all run locally. The web server is only used for setting up the piston. Currently there aren’t any big advantages to running the web interface locally. A future advantage is if there’s a webCoRE platform change requiring an update to the app code on Hubitat. I doub’t webCoRE is going anywhere so shouldn’t have to worry about access to webcore.co disappearing.

What type of machine do you have running? WAMP is probably the easiest to get set up on Windows. Pretty much the only change to the code is to initialize the endpoint to the local URL instead of cloud URL on line 852:

Original:

                state.endpoint = hubUID ? apiServerUrl("$hubUID/apps/${app.id}/?access_token=${state.accessToken}") : apiServerUrl("/api/token/${accessToken}/smartapps/installations/${app.id}/")

Local update:

                state.endpoint = hubUID ? localApiServerUrl("${app.id}/?access_token=${state.accessToken}") : localApiServerUrl("/api/token/${accessToken}/smartapps/installations/${app.id}/")

Then I just copy the dashboard URL in the app and replace dashboard.webcore.co hostname with the local server address.


#72

I had trouble with WebCore after 704 update, so
I uninstalled webcore, it is not on my apps list anymore.


But I can't remove Webcore storage from device.

If i just try to reinstall Webcore, any piston I create gives me unexpected error...
Any ideas?


#73

YMMV, but I found I had to deselect every device from WebCore to completely delete it.


#74

How to deselect from Webcore, if I don’t have Webcore installed ???


#75

Reinstall, delete pistons, then uninstall.


#76

Every install just creates new instance…


#77

So I just tried installing webCoRE, using Dan's (@ogiewon) fork with modifications for Hubitat, and I'm definitely not off to a good start here.

Keeping mind I've never installed or used it on my ST hub, here's what I've experienced so far:

After saving the 4 app executables and turning on OAuth, I added the webCoRE app and went through the setup. For devices, I just selected 3 (dimmable) lights, a button, and a motion detector to start with.

At some point during that, an error was thrown in logging, but listed as dev:null -

[error] No signature of method: com.hubitat.hub.dao.InstalledAppDao.saveState() is applicable for argument types: (null, java.util.LinkedHashMap) values: [null, [created:1521234584301, modified:1521234584301, build:0, ...]] Possible solutions: saveState(long, java.util.Map) on line 1031

I set my password and went to view the online webCoRE Dashboard interface. I wanted to try adding a piston using a template code, but the menu text stated "there are no templates yet :(" I'm in a TL;DR mood, so I just created a piston from scratch.

Unfortunately, the devices I set up when I initially installed the webCoRE app seemed to have been forgotten, so I couldn't really do anything with the piston yet and I just saved it. I was taken to the Piston overview (??) page, so I clicked the link to go back to the main dashboard display.

Checking in on the Hubitat logs, I saw this error, repeated twice:

[error] No signature of method: com.hubitat.hub.dao.InstalledAppDao.saveState() is applicable for argument types: (null, java.util.LinkedHashMap) values: [null, [created:1521234584301, modified:1521234584301, build:0, ...]] Possible solutions: saveState(long, java.util.Map) on line 1031

Then I checked the Hubitat's Apps page, and the piston is listed twice:

Clicking the [i] to view details about the two instances, I'm pretty sure the first one is a "ghost" or unused app, because nearly all of the Application State data was blank. But I'm not sure of the best way to delete it / get rid of it. So I tried deleting both of them in the webCoRE online interface, and as mentioned in this thread, that doesn't work. Here's the error:

[error] No signature of method: app15212333628131551263922.deleteChildApp() is applicable for argument types: (com.hubitat.app.InstalledAppWrapper) values: [com.hubitat.app.InstalledAppWrapper@638c6876] on line 1419

So I manually removed the child apps in the Hubitat interface, and they disappeared from the webCoRE online interface.

Then I went back to the Hubitat Apps page to try to get the devices I added to show up correctly. Clicked on webCoRE, and see there's two options under the heading "Available devices and contacts":

Based on the link URLs the top one is apparently for configuration and the bottom is for creating a new Child app / new piston (?) So I chose the top link, selected the same devices again. Interestingly , when I click "done", it takes me to a "Available devices" menu, and the only way to get out is the <<App List link.

I enter the online webCoRE Dashboard again, create another "from scratch" Piston, and now my devices are available to choose from. Created a simple if button pushed turn on lights Piston. Now there's only one instance when I check in the Hubitat Apps page.

I'm not at home, so I'll have to continue testing, but just this initial experience has been fairly wonky.


#80

There are several features that never seemed to work properly on Hubitat, even prior to the latest firmware updates. Deleting pistons has been problematic. Pausing pistons also doesn’t work (the UI says they’re paused, but they aren’t).

Having installed it a few firmwares ago (and just having updated to .704) I’m a little relieved to see that it still seems to work about as well as it did before (that is, fairly wonky).

One new error I don’t recall seeing logged before (but it doesn’t seem to cause any problem in bringing up the dashboard):
errorDashboard: Authentication failed due to an invalid token


#81

Oddly, I don’t seem to have any issues at all with my WebCoRE installation, that was done back on firmware 698 I guess.
Pause (delete from WC works as pause) and Resume doesn’t work for me and deleting pistons has to be done via the Hubitat UI. Barring these WebCoRE seems to be doing a great job of handling my more complex conditions without any failures till now.


#82

I installed webCoRE successfully to the point of experimenting with a couple of pistons, but now I can't get to the dashboard (ST webCoRE dashboard is fine, FWIW). I'd appreciate any advice on how to get back to seeing the dashboard.

I've tried on IE, Firefox and Chrome in Windows. To start over, I register a new browser which gives this error:


.
If I try to go directly from the Hubitat apps list of pistons via View Piston in Dashboard link, then I get: