You should update so it recognizes the new data
I would update just after you update the groovy code
Dont have old js with new groovy
1 Like
@nh.schottfam Can you please explain in short, what to update and how is the easiest way? Have my webCoRE local running on a Raspberry Pi?
webCoRE is not a problem via HPM but JS on the Pi would be very appreciated to get some hints.
Thanks in advance
There is information here under section Running a local webCoRE Server
There is no strong reason to do this now, as HE will transition the public servers to their accounts
1 Like
Just nitpicking here:
- Can we get a hub icon that isn’t a SmartThings hub?
- Can we get a higher resolution (2x) icon for the mode?
- Can we get an armed status icon with transparent background so it works in dark mode?
1 Like
Try staging.webcore.co. (ie work in progress) for the hub icon
The other two @ipaterson will have to look at.
3 Likes
Yeah these icons are terrible and they are hardcoded into the stylesheet rather than being hosted somewhere, it's weird. The new one that Hubitat provided is about 1.5X not full retina and kind of aliased but it's better than nothing, surely not as bad as that mode icon. I prefer to use icons from Font Awesome 5 if you would like to search and recommend icons to use there.
Originally there was an "SHM Mode" that could be either "off" "home" or "away" and could have an alarm state, so the icons were as follows:
You can make the modes whatever you want in HE so I'm not sure there is much value in having any icon there unless you can configure it (see the wiki for how icons are specified). We would provide sensible icons for the default modes Day/Night/Evening/Away if you want to help choose those.
1 Like
The ability to configure icons would be fantastic.
I use Location Mode extensively, but the default modes were not helpful to me, so instead I have e.g. an Awake mode and a Sleep mode.
I know it's just an aesthetic thing, but I, personally, think that it would be amazing if we could customize icons and be able see the current Location Mode at a quick glance in the dashboard!
1 Like
I just updated webCoRE and notice when attempting:
- Hygiene after an upgrade: going into the Hubitat Console and selecting: "Apps" -> "webCoRE" -> "Settings" -> "Cleanup and rebuild data cache" is a good thing to do.
there no longer seems to be a 'Cleanup' choice. Is there an alternative mechanism to accomplish this?
I should clean up the docs.
There are some cleanup options under
HE console -> apps -> webCoRE -> "Engine Block".
(need to have 'Full' debugging on to see them on main webCoRE)
In general you should not need to do this (or politely rebooting your hub does this)
1 Like
Sorry if this is not the right Topic to post this question under.
I have some drivers where I use momentary capability , these device in HE has singel Push button and works as they should, I have these added to Webcore under section momentary but in all my pistons where I was using this momentary "push()" are now broken and webcore insist that I need to add a button number rather than just push().
I cant undersatnd Why webore identifyed momentary as pushablebutton now,
I have now modified the drivers with a button nr as a quick fix
def push(button = 1)
Thanks in advanced
Is this the right group to list WebCore bugs?
I have v0.3.114.20221228_HE. In a new piston, I defined a device variable. In the body of the piston I initialized the variable to Nothing Selected. But then if I do a count on the variable, I get a count of 1. Shouldn't that be 0?
Recently I have noticed issues with the Set Level for smart vents and lights (Hue bulbs and Zwave GE Light Switches). The Keen Zigbee vents will not set the level if using Set Level but they will work if using Fade Level with a final level and 0 Seconds. I have noticed my lights not always setting the level either and in all cases looking at the Events for the Device in Hubitat I see the command-setLevel but the value is blank. It works fine if I set the level on the device directly in the Hubitat app.
would need to see the piston. Some pistons using setLevel have a (?) in them, and this seems to be showing a missing duration parameter HE added to the commands.
I'm not sure this is the issue, but look at your piston and see if you see something like:
If so you may want to edit that and fill in the duration parameter or make sure it show 'Nothing selected'
If you still have a problem full logs and view of the piston will help debugging.
I did have the ? when I imported everything from SamrtThings but I clicked on all of them and hit save and it looked good after that. I created a test Piston that just uses Set Level on a single vent and I get the same issue.
For the Vent the log does show:
groovy.lang.MissingMethodException: No signature of method: user_driver_lgkapps_Keen_Home_Smart_Vent___lgk_V2_631.setLevel() is applicable for argument types: (java.lang.Integer, java.lang.Integer) values: [0, 0]
I am not sure if this is an issue with the Driver but it does work fine from the devices page in Hubitat and the App I use to control all the vents works fine. Since I have random issues with lights not being set to the right value I wasn't sure if it was because there is no value in the Events when webcore sends the level to it. I also removed and added the vent to WebCore in case it was because the driver changed. I can look into more logs as well to see if I see anything else.
The driver is missing a required parameter
See
Goto switchLevel
so what error are you seeing (ie mixing threads?). the original was referring to the setLevel failure.
I installed the latest firmware to my hub yesterday, and all of my pistons that used audio output (via chromecast integration and google nest mini speakers) stopped working. I was getting device not found errors in the piston logs. Eventually, I found that the google nest mini speakers were erased from the webcore device list. I re-added the speakers, and the pistons still had no audio ouput and there were no more errors in the piston logs. I reinstalled the previous hub firmware, and everything is working again.
I don't see any errors at all in the logs.
The device remains set at 30 for volume but the code sets it to 59. The level never propogates to the device. If I do a Set Volume as a separate command ahead of the Speak command it all works.
There seems to be a problem with the latest hubitat fw I assume..
