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.
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.
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) - CoRE - 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.