CoRE and Piston Rules Engine, first design steps

Be patient, trying to figure out the error line number to display in the error message. I think I know what the problem is, you’ve changed a condition from one capability to another, or one attribute to another, causing data type issues.

Yes, I was changing, in the secondary IF, a trigger to a condition. Specifically I was going from “chances to” to “was above”.

Something glitched and it gave me the error

It’s the evaluation of the now “condition” that takes different parameters than the “trigger” - I’ll try-catch it and then you get a chance at fixing the parameters - they’re red and “required” in the UI, if the UI would get to displaying them…

1 Like

Try now: v0.0.03c.20160523 - Alpha test version - Fixed a problem where dry evaluation of a condition may fail when changing the capability or the attribute or the comparison in the UI

Sound like fun, how do I do that?

Just update and publish, then go back to the app, it should not c**p out now. Also, check the logs and paste the error line here pls.

Still getting the flag.

This is in the log

02c8c2e2-5ce1-4549-bb70-7e4e66d17507 10:38:50 AM: error java.lang.ClassCastException

Make sure you filter on the child app only (tap on the child app name on the top). That error belongs to the child app? I never output errors so lacking in details. Mines start with “ERROR: this this and that: details”… What trigger did you choose and what was the condition (include parameters if possible) when you switched to a trigger, so that I can simulate it here please?

@ady624
For the Minimote, I can see the button device and see the Value (held, pushed), but no buttons (4). Just wanted to make sure it was on the radar.

It is, just not there yet.

1 Like

This is all I have in the log. Filtered on the child app.

I was changing the group from -

Pumping switch changes to off
Or
Pump changes to less than 1

Changing it to -

Pumping switch was on for at least 10 minutes
Or
Pump was more than 1 for at least 10 minutes.

I’m not sure if this was a bug in the app because my signal was beginning to fade as I was going through the Talladega national forest. But it glitched when I was changed the pump to was more than.

@bamarayne try updating the app again.

Warning: the “was” conditions do not trigger events when time passes, they simply check to see if the device was in a required state for a required time - you need something to trigger the evaluation, or else, they’ll only run whenever the device with the “was” condition actually changes, at which point it looks at the previous state and checks that state’s duration for the condition.

Things with CoRE have now advanced sufficiently far that I can no longer follow most of the conversations using text to speech. Which is fine, that happens with all of the really complex smart apps.

Anyway, I am no longer going to read this thread, but if you need me for something specific just tag me. Have fun! :sunglasses:

6 Likes

@JDRoberts Thank you for your assistance.

3 Likes

Set up a test rule for the above to try out, seems to fire ok when presence left or arrived but shouldnt it fire when time goes between selected ranges. Didn’t fire when time went turned 6pm?

Making progress with variables. Simple algebra is there, operation-order-aware… the parenthesis are automatic…


Can you check on the IDE and see if there is any job scheduled for the app? Location > Installed Apps…

Just changed time to 19:25BST in app so it should fire in 3 minutes but theres no scheduled job showing in IDE

What version of the CoRE are you running?

latest version 3c from couple of hours ago. Other pistons that have time triggers all have scheduled jobs showing at correct time.

Local variable list for the affected piston shows ‘null’ for $nextScheduledTime