webCoRE for Hubitat Updates

It is working now for me using the "Send IFTTT maker event" from the location action menu. Do you have your IFTTT maker webhooks link pasted in the dashboard options? it looks like you haven't.

I am sending 2 variables: the currenteventdevice and currenteventvalue. Do those work for you?

And yes I have the webhooks URL configured in the integrations page of WebCore.

Can you show a screenshot of your piston? Are you getting any errors in Hubitat or just in webCoRE?

Update:
No, it does not work with passing system variables as values. Again, you can build that as a simple HTTP request in WebCoRE just fine and that works. I don't understand why don't just do that. Do you not know how? If that's all it is, I can show you how to do that.

Thank you for all your help. I do know how to do it with an HTTP request. Can you do an HTTP request with system variables?

I think i read above that variables do not work with webcore/HE...if that is true which ones? All variables? System variables?

You can send any of the webCoRE system variables in an HTTP request. The easiest way you can do that is with an expression.

New release available

Current Release Updated April 4, 2020

  • Adds use of async http for ifttt access
  • expanded use of attribute value subscriptions (device GETS, device RECEIVES triggers)
  • optimizations to reduce code size and execution
  • latest fixes for webCoRE on ST
  • Ability to reset your webCoRE access token (will affect all external URL access to require new URL)
5 Likes

I've just set up WebCore, and all is well apart from the logging level not persisting in the settings of the pistons within Hubitat.

After pressing "Done", and re-opening the settings, the logging level reverts to "Piston logging". I tried setting what I thought might be a default at the Webcore app level to no avail.

Seems like I must be missing something.

image

Cheers

Its not a great idea to log all pistons, the hubs don't particularly like it.

If you're looking to check the logs of a particular piston, its best to enable that in the piston itself.
I have all logging off, unless I need to troubleshoot a piston.

1 Like

Exactly what I'm trying to do. I just want to view the logs until I'm satisfied all is working as intended, and then I'll disable. The issue I'm having is that the logging level does not save when changed - it stays on "Piston logging".

I have to be honest with you, I've never tried that way, I just carried on how I did it on ST :slight_smile:

Within the piston itself :+1:

2 Likes

This is correct, the piston itself is showing the setting, but the UI always overrides. (webcore dashboard)

Thanks. A couple of things...

I'm fairly new to both Hubitat and Webcore, so still not entirely following.

Within Hubitat, it seems that settings for webcore logging can be applied at the webcore app and piston level, but I'm unclear as to what each setting does - see highlighted boxes below. Also, not sure how the webcore dashboard logging figures into the equation. Not trying to be a pendant, just like to understand how things work and would be grateful if you can shed light.

Second point, not sure if this is a bug, but I noticed that no matter what logging level was applied in the piston settings, the logging enum in the App List was always set to 3:

When digging through the piston code I noticed that the first line of the initialize() method below was receiving values not defined within the options map of the logging input. Instead of 0-3 being retrieved, the values returned are one of 48-51. The value then subsequently returned by your setLoggingLevel() method always defaults to 3 no matter what is selected in the logging level drop down.

Changing the first line of the Initialize() to def tt1=settings.logging seems to work, although I don't know why it does this in the first place, and of course I could be completely wrong.

input 'logging', 'enum', title:'Logging Level', options:[0:"None", 1:"Minimal", 2:"Medium", 3:"Full"], description:'Piston logging', defaultValue:state.logging?:0`

        void initialize(){
        	**Integer tt1=settings.logging**
        	Integer tt2=state.logging
        	if(tt1==null)Map a=setLoggingLevel(tt2 ? tt2.toString():'0')
        	else if(tt1!=tt2)Map a=setLoggingLevel(tt1.toString())
        	cleanState()
        	clearMyCache('initialize')
        	if((Boolean)state.active) Map b=resume()
        }


        public Map setLoggingLevel(String level){
        	Integer mlogging=level.isInteger()? level.toInteger():0
        	**mlogging=Math.min(Math.max(0,mlogging),3)**
        	app.updateSetting('logging', [type:'enum', value:mlogging])
        	state.logging=mlogging
        	if(mlogging==0)state.logs=[]
        	cleanState()
        	clearMyCache('setLoggingLevel')
        	return [logging:mlogging]
    }

Just found that today also. Fix is posted.

The logging can be set in HE via the webcore dashboard (when editing a piston) or via the application settings in the HE console -> apps -> selecting the piston

@nh.schottfam Following on from above. I have set the logging level to none for the webcore app, and for all pistons, I am still seeing the below in the HE log for one of the pistons which uses a time-window restriction. I wouldn't expect to see anything. Is this by design?

image

It seems that is the design of original webCoRE. I did not change it - warnings and errors are sent to the logging.

I can describe a way to change it if it really bothers you.

I thought your were Adrian to be honest.

Anyway, I'm coming from the context that there is a lot of emphasis on disabling logging in your original post, so thought it might be of interest if it's incorrect. Broadly though, I'm not highlighting stuff for fun, I'm just trying to assist in making the app be as good as it can be.

EDIT:

If there is a quick way to sort it out, I would be interested, as I've got hundreds of entries. Just comment out the line?

...or reduce it in severity to log.debug or log.trace

(or more pleasingly fix the reason it's generated in the first place)

If you update, I pushed a change to make it debug from warning.

Some interesting data I"m seeing with the latest firmware 2.2 release:

The performance has meaningfully improved on the platform.

Prior to 2.2, simple piston test would execute on average in 15 ms.

I'm now seeing this average be 8-9ms. Not sure what changed, but looks nice...

It is easy to see the in webCoRE given the tracing reports and graphs it does automatically

3 Likes

Need quick/simple help that is making me pull my hair out please!

I am a webcore newbie and Hubitat. Before yesterday, I was able to use a very slick dimmer switch piston for my Inovelli Red Series dimmer on SmartThings. I have since bought a Hubitat hub to try and get the response much faster for these (the wife-approval factor on the ST lag has been problematic). I understand the way webcore is implemented on HE vs ST has the button logic much different. And this is what is a huge problem, as if I use the import code to bring my existing one in from ST to HE, it's all messed up.

Can someone please show me a webcore example that shows how the heck buttons work in Hubitat?

I need to "translate" what the ST version shows the button logic, in to how HE does it:

  • if Inovelli Dimmer's button #1 gets pushed.... do _______

If it's helpful to see the ST piston, it is backup code "ats7v"

Thanks so much!
Brian