[DEPRECATED] webCoRE Beta Milestone 2

Looks like all 7 of my installs are still working.

Thanks it must just be something with my account are shard then.

IMPORTANT

There was a bug introduced in 0c5 while attempting to refactor date/time. 0c6 fixed parts of it, but it appears boolean and dynamic data types were affected. Namely, under certain circumstances, a false set via the script is found to be true. This is because source data type is now enforced, due to the time data type refactoring - the value set by the JS UI in the script is considered a boolean type but it’s actually a string representation of it, namely the string ‘false’. The string ‘false’ evaluates as true (non-empty string) though webCoRE has mechanisms in place to detect certain known strings and make them boolean false. But since the variable swore it was a boolean, it circumvented the string manipulations that would figure out it really means false. Speed optimizations, but this time they failed. I’ve made sure that dynamic and boolean variables are thoroughly inspected instead of trusting the data type. Will publish 0c7 in a few minutes, sorry for all the trouble.

v0.2.0c7.20170621 - BETA M2 - A bug fix for boolean and dynamic types - thoroughly inspect their values rather than rely on the data type

6 Likes

I appreciate your quick response to these bugs

I think there are still some issues with functions but I am busy pouring concrete in my backyard lol - will look into it as soon as I can

3 Likes

Global Boolean variable seems to be working OK now.

So who are you burying in your pool? :stuck_out_tongue:

1 Like

My shed. So that hurricanes cannot lift t.

2 Likes

Hi @ady624, would this be the right phase to pick up the orientation capability request? I’ve been keeping an eye on the device capabilities for my Mood Cube device within WebCore and haven’t seen it. Wanted to ask as those are my only pistons still running on CORE. Appreciate it’s not priority but wanted to check in. Thanks

1 Like

Yeah, I think we’re still missing the orientation and the followed by. I’ll add them to the //todo list and will get them done, hopefully before July 1st. I was planning on getting a release on July 1st, but I don’t think I’ll make it, so aiming at a beta M3 before July 1st, and that orientation should make it there before that. There’s a little algorithm @Mike_Maxwell helped with (thank you) that handles that orientation face detection :smiley: I just need to move it over.

4 Likes

I am having issues where all my timed pistons are running exactly 4 hours early. For example, I have the lights set to turn on at 6AM and they turned on this morning at 2AM. Strangely, the countdown in WebCore shows the correct time to be triggered but runs 4 hours early.

Yesterday morning (around 9AM) I upgraded to v0.2.0c7.20170621 so I am running the latest version as of this post. Do I need to re-create my pistons? I am on EST if that matters. Any assistance would be appreciated.

Pause and resume one such piston, see if it fixes it, or wait another day and they will fix themselves

1 Like

Sorry if it’s been brought up - but when I select “Virtual device” “Routine” then “What kind of comparison?” ends up being an empty dropdown.

I’ve got a couple of “If routine ran” in CoRE that I’d like to transfer to WebCoRE but can’t work out how that’s possible as is?

Edit: I was trying to add this into the the “only when” restriction. My bad

Any idea why, when this piston is run, that it does not schedule a wakeup to 2:00 PM Today. Seems to be jumping ahead to tomorrow. I could have sworn I had this working in previous versions.

Basically sets my thermostats for a PG&E SmartDay Event. Triggered by another piston and using IFTTT.

Capture of the trace:

And logs:

I think it’s because when you specified a time with the WAIT, it essentially becomes a DAILY timer, and since you’re already part-way through the current day, it schedules it for the next day. An example of this is if you set a YEARLY timer for the 4th of July — it schedules it for the 4th of July of the NEXT year, even though it’s currently June.

Otherwise, the piston looks fine to me … just wait until tomorrow at 2pm.

BTW, if you edit the piston and save, or pause then resume the piston, the same thing (reschedule for the next day) will happen. Do all your editing of this piston after 7pm :smile:

UPDATE:
OK, it was a bug, LOL

My IFTTT Trigger piston executes it at 8:00 AM of the event day (I get the notification email from PG&E the day before the event).

For now, I am using [$noon} + 7200000. Not the most elegant, but it works.

I guess I could also launch before midnight. That would be more elegant :slight_smile:

When we get a break form this heat wave, I’ll adjust.

Thanks for the insight.

1 Like

Sharing is caring :slight_smile: just the codes and name of them is more that enough :slight_smile:
Saves me a lot of debug :smiley: I could even include a “please” hehe

There was a bug with that kind of wait introduced with 0c5 - fixed in 0c8, please update.

2 Likes

@BlackCatPeanut Surprise!

2 Likes

And I care for you too, LOL … if you really care, you’d ship some cold weather out our way in the southwest part of the U.S., hehe

Here you go:
Door Locks Status, kn6p
Door Status, w4d7
Notify To Open/Close Sliding Door, g56b

The Door Locks Status and Door Status pistons are the same — only the devices and attributes (and piston titles) were changed to protect the innocent :smile: … the last piston not so much, LOL. The keys to the last piston are the variable defines and the piston state statement at the very bottom. I did it this way so I could change the order of the variable output if needed/wanted.

1 Like