[DEPRECATED Thread: visit community.webcore.co for assistance] webCoRE - Piston Design Help (ask your fellow members for assistance)

ok, thank you @ady624

For this I refer to @ady624. I do not know that answer

ady624 ive just updated webcore because there was an update on the ide. since updating all my lights are flashing on and off suddenly and wont stop? is there something wrong with the update or is it something wrong with my st hub?

@ady624 just updated webcore. stays greater than or equal to conditions in existing pistons that used to work fine is now evaluating true when it should be false and causing a bunch of bad behavior.

Thanks!

For your particular use case, timers would be perfect.

uh… am I missing something? This is the way a case statement I have is evaluating:

+408ms ║║Calculating (integer) 300 - (integer) 100 >> (integer) 200
+418ms ║║Comparison 239 is_inside_of_range 0 … 200 = true (8ms)
+422ms ║║Cancelling statement #12’s schedules…

The middle line being the one that’s baffling me. true?

The upper bound of the range is calculated from an expression like so:

switch (sensor illuminance)
case 0 through {@LowSplit-100}

The first line seems to show that it’s calculating the correct value but its returning true for a number not in the range.

This was working yesterday afaik. Did something change?

@wgmcg are you on the latest update of webcore?

I believe so. I updated an hour or so ago.

the latest version may be the problem. i am also seeing comparisons return true when they should be returning false. @Baz2473 also reported some issues above.

@ady624 is there a way to rollback?

Thanks!

I I guess I should have read up in the thread before posting. Not just me!

yeah not just us, but this could become pretty widespread soon if others update without checking in here - which most are likely not to.

@ady624 changed one of the stays greater than or equal to TO rises above or equal to, that seems to have fixed the issue for that piston. if that tells you anything.

Okay, here is the piston built. Couple of things. First, Do With {vMotion} has no task of “Active” or “Inactive” - WebCoRE bug? I tried it with open/closed - never activates the virtual sensor - as it shouldn’t.

Before I posted that holding the physical sensor open for > 10 seconds kept the virtual sensor open - nope. As you believed, it opens after 10 seconds then closes 5 seconds later. That is okay for triggering SHM, but one thing I like to do with SHM is look at “Right Now” to see what sensors are active/open and I will lose that ability with this logic.

Also, when the physical sensor closes the virtual sensor opens/closes again as On Events triggers no matter what the event is. I am curious if a change of temp on the motion sensors will also trigger an open/close?

@ady624 another example this first line is evaluating true, which does not seem to make sense. also, normally that 0.0 would be the actual value of the temperature from a multi-sensor but in the logs its just showing 0.0 now while the current actual value is 76.

I am seeing the same behavior when attempting to save my thermostat’s temperature value into a variable. Temperature always evaluates to “0.0000”, but all other values are correct. I think this is a possible bug with the way that decimals are being handled…

Sorry, there was a bug in the last version, please reupdate the piston smart app - it’s the same version, just re-update it, that will fix the problem. sorry again.

2 Likes

Thank You. Really appreciate the quick fix. And no need to apologise, I should imagine it’s fairly easy to make a mistake with thousands of lines of code, really appreciate the great work, Webcore is absolutely amazing, without it smart things would not be anywhere near as useful :wink:

Hey Adrian, did you see my comment about not having an Active() and Inactive() not being available for a virtual motion device?

@ady624 thank you for the quick turnaround. hey, code breaks so no worries. at least there is code to break. :wink:

I see that the temperature condition checked is fixed. just to confirm, does this fix also address the issue with the stays greater than equal to trigger?

if i may ask a somewhat related question, you have been very clear about calling out that current version is BETA - assuming that means at some point you want to go to a stable RC. Do you have a set of criteria and a way to evaluate them (not asking for timing) for going from BETA to RC? Just thinking if there is anything we as the community can do to help with it. Pardon me if this is already documented elsewhere, just point me to it.

Thanks again!