Apps not working with switches/devices

I have install webcore along with a few other apps. I can control the switches from the hub web page interface. However, the apps pistons programs are not turning my switches on/off like they should. Any ideas?

Thanks

James

Welcome to HE! Unfortunately, I don’t have WebCore installed. I just use Rule Machine. I migrated all my pistons to Rule Machine when I made the switch from Smartthings.

You should probably post something in the webcore thread. There are a lot of folks there that would be able to assist.

A few thoughts:

  1. Are these the non-Plus GE switches or others that are known to not report status back to the hub? See this thread for more: Physical Events Not Logging Consistently
    If so, webCoRE uses "command optimizations" by default, which means it won't send (for example) an "off" command to a switch if it already thinks it's off (which may be different from whether it is off due to the aforementioned issue). You can use one (or both) of two solutions to this problem: in the piston settings, find "Command Optimization" and disable it. Alternatively, create something in Rule Machine to periodically poll/refresh the switch based on time, motion, or other desired events/conditions--then webCoRE (and HE itself, so any dashboards you use, etc.) will have the correct value, though possibly at the expense of your mesh network if you poll too much.

  2. Every reboot of the hub, you need to open the piston child app and click "Done" to prevent delays (and warnings in the logs). This is due to slight differences between HE and ST. This is probably not causing your problem, and I think it resolves itself after the piston runs for the first time, but in case the issue is really just a second or two of delay, it could be this.

  3. Consider using Rule Machine or native or community (or self-created) apps instead of webCoRE. I still have a few things running on webCoRE myself, but I'm looking to migrate them to RM or custom apps. They'll run faster (webCoRE adds another layer of interpretation on top of ST's and HE's existing interpreted programming language, Groovy--though HE has the advantage that the pistons run locally), and you won't have to deal with firmware updates (or even reboots) inadvertently causing issues with the complex, albeit powerful, beast that is webCoRE, which happened once in the past but is still occasionally suspected as the culprit in slow or locked-up hubs. I realize this won't help you now, and I'm not even following my own advice yet, but if you can do something "natively," consider doing it that way instead and you'll likely have a better experience.