Take it custom commands arenāt so easy to add then? In ST itās just a line at the top and a def further downā¦ is that not the case with Hubitat?
Iāve never automated the function thoughā¦ always been a manual thing as-and-when, so not having the custom command is no biggieā¦ just need the switch.
They are easy to add (I invented a way to use them), but not many apps can use them. so I can add a preference option to enable/disable it. On the newer models I can adjust the check in interval, which will extend battery life when not in use.
I donāt think changing the check in is possible on the two older models as it appears hard coded in the device.
Iām using webCoRE which (should) be able to see the custom commandsā¦ but I havenāt done much testing yet.
WebCoRE canāt see the ācontactā attribute of a virtual contact sensor though, so not holding my breath on that.
Glad to see you here @Robin !
Hoping webCoRE on Hubitat gets more traction with your arriving on the Hubitat scene 
I have webCoRE working to a point, but itās buggy as hell and Iām not the one to fix that!!
Iām a webCoRE power user, but not a coder by any stretch of the imagination!!
With Adrian working for ST now, it would be a huge conflict of interest for him to help out, but hopefully someone will come allong and fix all the glitches!
RuleMachine may not be as feature packed or user friendly, but it works well for basic automations and meets the needs of most.
There's an entire thread dedicated to just that. Check it out below:
Welcome to over here!
I haven't kept up on that news closely enough, but I sure hope that webCoRE remains a "community"-based Smart App rather than co-opted by SmartThings.
+1 Hopefully we can generate some community support for webCoRE on Hubitat.
I've installed @ogiewon's port and have been able to create a simple piston, but it didn't execute properly. That exhausts my expertise.
Can you share your āsimple pistonāā¦ maybe the problem is something simple?
Iāve got some fairly complex stuff running nowā¦
Agree with that.
One of the first things I did was to screen my webCoRE pistons to identify everything that time critical and try to find a way to move them to Rule Machine. Somehow, even if webCoRE also runs locally, the overhead on it makes it nearly 40-60% slower than Rule Machine in most comparable scenarios. Its not a large variation in terms of seconds, but its still noticeable even in the most basic tasks. (Unless I am doing something wrong).
However, in terms of laying out complex logic or even connecting to web-hooks or external end-points, webCoRE absolutely excels! So most of my climate control and device monitoring tasks still run on webCoRE.
Good news that youāre having success. It will greatly ease my transition if pistons can execute on Hubitat. Be happy to share. Glad for the help. I have to get to another computer that will take a little while - perhaps late Friday your time.
It would also be helpful if you could share the errors observed in your Logs section, at the time when the pistonās execution fails.
Thanks again. It's just a test piston that responds to power switch from an Iris 3210-L and speaks a command on TTS devices (LANnouncer). The log shows the event but nothing actually executes. Ideas?
Ahhhā¦ TTS is something Iāve never used so I wonāt be any help thereā¦ but I did read somewhere on here that someone is working on porting over BigTalker?
Looks like webCoRE isnāt recognising your audio device thoughā¦ might just be a capability reference missing from the device driver or something?
I am just finally starting to use webCoRE, so I don't know much, but are there any ways to reduce overhead? Silence the log output for example?
No idea, sorryā¦ Iām a power user of webCoRE but under the hood there is black magic that Iāll never understand lol
I have noticed that the most effective way to reduce latency is to design pistons in an efficient manner.
Did some googling and realized that Adrian has already explained this far better than I could in another thread.
The most efficient way is probably to separate tasks into related groups for each piston. I, for example, have a piston that handles all outside lights (about 15 of them) - it will blink them red when thereās an alert, turn them all white at night and shut them off at dawn, do color schemes on certain special days (canāt wait for July 1st to come to test my 4th of July part). Whenever I have to do something with one of those 15 lights, I do it, then execute the outdoor light piston to reset it to where the light should be. I have another that handles the bedroom lights. Another that handles the kitchen lights. I try to keep each piston concise on its task and make sure no two pistons overlap on their scope. The least pistons subscribing to any device, the better. Scratch that, the least SmartApps subscribing to any device, the better. If you have issues with ST becoming unstable, turn minimum detail logs on for all pistons and get a sense on how often they run. How long do they take to run? Are you using a loop without a wait in it? Enable pistons one by one and see what happens. Also, keep in mind that sending too many commands to devices at the same time floods your radio networks. There are options in webCoRE to inject an inter-command delay - if that is causing an issue.
.
Source: Efficient Piston design in webCoRE (to minimize resource utilization) - #6 by ady624 - webCoRE - SmartThings Community
As for platform features like logging, execution parameters etc., I am in the same boat as Robin and don't fully understand how much of an impact they have. I'll try to test that and report though.
I may be wrong but I donāt think Hubitat support textToSpeech() yet.
SmartThings uses an AWS service called Amazon Polly as its voice interface and I believe a similar service is already on the Hubitat roadmap too. @bravenel: Please correct my if I am wrong.
When the Hubitat equivalent function is ready in a future update, I assume we would only need to update the function name in the webCoRE App code and then the speech feature should start working.
I hope pistons not using Speak are working fine for you.
From the log it looks like the piston isn't see a state change Comparison (enum) off changes = false so it isn't getting to the actual execution. Are you looking to run it if it changes to both on/off? Maybe try changing the statement to changes to on as a test. You can also turn on Trace which will show the results of the conditional statements with the # that correlate to the log.
It was just a test piston that I gen'd up. I thought I was picking something simple that was sure to work. Looks like I stumbled onto a trigger and an action that aren't supported. Indeed, when I fixed the trigger to changes to on and the execution was to turn the switch off, it worked. Also, a test to trigger off motion and to turn a switch on, wait, turn it off is working.
.
Can you elaborate on this, particularly in reference to RM speech capability? I have RM rules that speak to LANnouncer devices. What is it about webCoRE that makes it unable to do what RM can do (other than Bruce is the RM author 
)
I am also curious about the future of webCoRE. As mentioned above, the author is very unlikely to support any platform other than ST, so we are dealing with code that will atrophy on a system that has no incentive to accommodate it going forward. I found myself using webCoRE for just about everything on ST - some dead simple, some very complex. Without webCoRE, I don't see how I can migrate some of the more complex automations; so I guess I will re-implement the simple automations with RM and hope/pray webCoRE works long enough that I can find a way with RM.
Thanks, all.
Download the Hubitat app
