CoRE and Piston Rules Engine, first design steps

So you had to tap Done for it to schedule one job? Pistons only schedule one job at any time. This is what allows you unlimited time conditions/triggers, beating the 4 jobs limit. It may also schedule a second “safety net” job while running. Could you please have the IDE open when it next runs and pm the logs? Make sure to enable debug for that piston. Thank you.

You are right. If I add an authorized email, it shows the PUSH option.

v0.0.087.20160612 - Alpha test version - Send notifications to contacts is now enabled

I am also trying to assume next minute if second is 57 or up, to prevent issues with the ST job scheduler being early


v0.0.088.20160612 - Alpha test version - Added the ability to initialize/change variables from within the UI


v0.0.089.20160612 - Alpha test version - Added the ability to delete variables from within the UI


Can’t you use set level by itself without turn on? for me.

@TheFuzz4 I was able to copy your piston and have it working, but only using the Kodi device setup following @joshua_lyon’s instructions. Meaning I HAVE to use the ST app to control Kodi (running on my Nexus Player) to get this piston to work). If I use any normal remote control (universal, Harmony), the piston doesn’t work.

Basically, it seems as if CoRE only looks for the Kodi status from the device in ST, NOT from Kodi running on my Nexus Player. Any idea as to why?

I think some DTHs will turn the bulb on when setLevel has a level > 0. But not sure that is a “standard” across all devices. Lack of extensive documentation and strict requirements for DTHs allow for a lot of things to work differently from device to device. YMMV.

CoRE has no idea how things happen, it subscribes to events and acts upon them. Any events in the logs when using the remote?! Your DTH needs a way to sync with the Kodi status, so that if Kodi’s status changes on its own, it knows…


For anyone reading, G.E. Bulbs and Switches support “set level” without on being needed.

Nope. Hitting Play or Pause on my Harmony gives nothing in the Live Logging. Everything is set properly in Kodi.

Setlevel > 0 will turn dimmers on, this isn’t anything specific to ge products.

I thought so!

So on command is not needed.

So it would seem the DTH isn’t syncing with the Kodi status then? Meaning @joshua_lyon might be able to help?

Pretty much

@ady624 request: Need the dashboard to show when the piston is mode (or other restricted). Trying to debug some restricted pistons, can’t figure out why they are not restricted.

1 Like

I agree, until some DTH comes along that requires an on() regardless. My point was, documentation should at least provide guidlines to how things are expected to work…

1 Like

Yes I can, just didn’t think about it the way Jason had suggested. I have since changed them to set level first…

My question to Adrian was about the ordering of conditions between the Piston and the Dashboard. In the Piston, it is set, Using Light, Turn On, Set Level. In the Dashboard, it’s Using Light, Set Level, Turn on

I thought I remembered reading that he fixed that and was wondering if there is a lingering bug or…


Sorry I don’t have any thoughts on this at the moment. I’m not using a Haromony remote that is compatible with SmartThings (its like 6 years old lol) I just have my piston set to watch the kodi status and if it changes then do the needful.

Maybe I’ve set up CoRE to watch Kodi status wrong then. The ONLY controls that will trigger the CoRE piston are the ones inside the Kodi device in the ST app. It’s not specifically a Harmony compatibility issue, it’s basically CoRE is seeing a change in Kodi status ONLY from the device set up via the DTH.

Thanks for adding the ability to create variables from the UI, it’s been a huge help.

Are you still taking requests before beta? Adding the ability to re-order or insert tasks instead of just being able to add them.

I know this isn’t a simple change and I think when others have asked for it in the past you said it would be added after Beta, but I think it would make things a lot less frustrating.

When testing a piston, I often realize I missed something in the middle and there’s no way to fix it without deleting the entire action and starting over. Now with all the new task related features like looping, starting over can be a time consuming process.

I would just start with the last task and back them out until I get to the change I need to make, but if you then add a variable, it automatically takes on the name of whatever was there before it and there’s no way to rename it.