Am I correct is saying I would have to do this 5 times and use restrictions to force it to be different depending on the mode?
Oh, well that wouldn't be too nice, would it?
If setWhiteLevel() is a dimmer level, you could use the Dimmer Per Mode action in RM for that.
1 Like
spot on I will try and find that. I wasn't able to find the setWhiteLevel() capability does RM grab the capabilities from the driver and allow you to utilise them? In this case its a Fibaro RGBW controller which I don't think is supported yet by HE unless its been added and i've missed it?
Assuming that this is a custom capability then you would need to create a Custom Command in RM first. Once saved you can use it on any of these device types.
When you click the New Custom command button, it will pull all the commands available (including custom ones) and allow you to select it and even apply parameters.
1 Like
Tried it but as it's a condition rather than a trigger it just gets stuck in a infinity loop. After managing to delete it I learned and created a virtual switch to disable it, I tried some more things but couldn't get it going. So I've gone back to WC which is now running even smother as I don't need the waits and refreshes in the statements because HE is so much faster than ST. I can literally flick it on and off and it keeps up!
I will try again at some point would be nice to get some ported over
Anyone having issues with webCoRE today? I can get to the dashboard, but thats about it. Try selecting a piston, and it just sits there attempting to bring the piston up, but never does. Logs show the piston is executing as normal. Cheers
Your problem sounds like the symptoms I reported back in Post #337.
I removed (from the authorized webCoRE device list, not from Hubitat) the offending device and have had no dashboard problems since.
1 Like
Ah so I have something in the list its not liking?
Thanks very much @CAL.hub, this was it. Phew!! I think I'll hold off keep authorising things until I have all added, and with the correct drivers. I suspect it was two I had as metered, and then I changed the DTH not be a metered one. Cheers!!
Was any headway made on a docker container for webcore?
I'm not sure if anyone else had this issue, but I wasn't clear on the method to differentiate between SmartThings and Hubitat instances of WebCoRE. I assume it has to do with the Custom hub and Custom webcore instance settings, but whatever I tried resulted in a "page not found" error and I just needed a quick fix to be able to simultaneously open both. Maybe this will help someone else if the appropriate settings aren't clear.
There's a free Mac app called Fluid you can download at fluidapp.com (not affiliated with them) which allows you to create an app file from a url and use custom icons as described below.
-
Using the dashboard url, create two apps (differentiating between them by name and icon).
If you wish, I made different WebCoRE/SmartThings and Hubitat icns files you're welcome to download & use. -
Click "Create" and there will be two new apps in your Applications folder (or wherever you specify under "Location").
-
It will prompt you for the WebCoRE registration code on the first opening of each, which should be generated by the respective SmartThings and Hubitat SmartApps.
1 Like
I got a friend who installed webcore and they have 2 home locations... anyone have a fix ?
Also the SHM status says unknown which is odd.
I currently have about 25 pistons on webcore and am currently experiencing some major lags. The lag seems to happen very randomly. At times motion detected lights would light up instantly, at times up to 30 secs. Again, this happens very randomly.
I have got webcore installed locally on a RPI. Any idea why this happening?
I have taken @jp0550 advice by keeping triggers on a single piston, but still no joy. A simple piston like when motion detected, turn on bulb can fire instantly or take up to 30 seconds.
1 Like
Just had this exact scenario happen in the kitchen.
I just want to make sure you realize that webCoRE actually runs all pistons on your Hubitat hub, Your Raspberry Pi can be turned off, and the pistons will all still run. The webCoRE website is only used to create, edit, and delete pistons. It is purely a configuration tool.
2 Likes
Can I ask a stupid question here, I have debug logging on basically most things at the moment, due to this being new and I want to see what's going on, and trap the issues (of which I've had a few).
Logging in general PC terms doesn't really hamper performance. But is this the same with Hubitat? Its not a PC after all. On the devices I see lag, it tends to be ZigBee devices and not Zwave, they seem pretty much instant.
I figured as much, but thanks for confirming. I was initially afraid that it was the RPI, but can now scratch that off.
I did a test where i walk along a pathway and 3 motion sensors would capture my movement (checked on the event logging for when it was triggered), about 5 seconds apart. All 3 sensors would turn on a different light bulb. When i reach the end, none of the lights would come on. On the Hubitat portal, i would turn the last bulb on and it is instantly turned on. The other 2 would take a few more seconds before coming on.
In my simple mind, this would show that the hub was not the cause of the slow down and in fact would be the piston right? Is there anyway from the logs that are captured, can i see what is causing the slow down? The annoying part is that this is intermittent - sometimes everything works out well, and sometimes it's really, really slow.
Just to add: all are zigbee devices.
The detailed logs under a piston can give you a clue to where the slowdown is coming from if you set the logging level to full for the one in question:
Received event [Bedroom Motion Sensor].motion = active with a delay of ?ms
The first will tell you how long it took to receive the event from hubitat's event loop before your custom piston code starts executing. If this one is long then the hub might be loaded down either from other pistons or apps subscribed to this event that are processing it first.
RunTime Analysis CS > ?ms > PS > ?ms > PE > ?ms > CE
The next line is also before your piston starts executing and shows how long it took to load all the reference data/variables/etc.
Event received
- CS - Child start
call parent to get devices, commands, etc - PS - Parent Start
load reference data - PE - Parent exit
load some more reference data - CE - Child exit
Execute piston
Everything after is your piston executing. Looking at those could also give you some insight to the slowdown.
3 Likes
A new update is available here and on @ajayjohnm's repo. I've updated it with the latest changes from idpaterson for smartthings and updated them to work on Hubitat.
If you're running a local pi instance don't forget to update it as well depending on where it's located. This assumes you followed the guide and it's at the home directory on your server.
cd
cd webCoRE/
git pull
2 Likes
