SmartLight App AND WebCore - can we have both the belt and suspenders?

smartapp
#1

This question is more about remote cloud processing failover than WebCore specifically. One of the concerns regarding WebCore is that processing is over the cloud. The advantages are well known and documented so are unnecessary here. The notable disadvantages are process latency and cloud (or internet) outages.

The included ST SmartLight App will process locally, is nearly immediate and does not depend on the cloud. The downside is the limited scope of programming, hence why we use WebCore.

So my question is can we use both? My logic is I would use the SmartLight App to ā€˜kickstartā€™ a light and then Webcore to handle the details.

For example, letā€™s start with my Laundry Room. I have one dumb light fixture on 1 GE On/Off Z-wave Switch and an Iris Motion Sensor. My desired operation is:

  1. On Motion at Night mode, turn on to 10% and then turn off after 4 minutes of inactivity.
  2. On Motion at Home mode, turn on to 70% and then turn off after 4 minutes of inactivity.
  3. On Switch on at all modes, turn on to 100% and then turn off after 4 minutes of inactivity.
  4. On mode changes to Away, turn off.

In Webcore, this is simple enough. Iā€™m sure there is a 100 ways to do it and how to do it is beyond my scope here. However, if the internet/cloud is compromised, this routine will not runā€¦or maybe it takes a second or longer. But to do this in SmartLight alone would require several routines, not just one (specifically above would required 3 routines and item 3 would not be possible). Factor this up for 20 rooms/light groupings and its unmanageable.

So what if I created a SmartLight App that simply:

  1. On motion, turn on 10%, then turn off after 10 minutes of inactivity. Thatā€™s it - just one simple routine that brackets the WebCore routine.

After this executes immediately, Webcore will come in and take it from there. When WebCore is working just fine, my wife, I, an intruder, the cat, etc would notice that the light will turn on to 10% for a fraction of a second and the adjust upward to the appropriate brightness afterwards. If WebCore fails (for whatever reason and for what ever percent probability), the light will at least come on 10% and then can just be manually adjusted afterwards. Then if WebCore fails, the light still turns off after 10 minutes of inactivity. If WebCore works, there is nothing to turn off after 10 minutes.

The only drawback I am seeing is if a light is already on, SmartLight will dim it back to 10% if motion reoccurs during the inactivity period. Also, WebCore might need a 1 second delay so it does not transmit an action code to a switch at the same time as SmartLight. But my assumption is SmartLight will get out first.

Any thoughts? How often as WebCore/cloud processing failed us?

#2

I realize some people may jump in and say item 3 will never happen as GE switches do not report an ā€˜onā€™ press if the light is already on for some other reason. Criteria 3 serves two purposes. First is if the motion sensor fails (battery, dropped, etc). Second is you can actually take a step into the room and press the switch before triggering the motion sensor. The motion sensor is positioned this way because otherwise walking in the hallway or even a small part of my bedroom would turn on the laundry. Irregardless, there is a small legitimate window of opportunity to press the switch instead of using the motion sensor and my intent is bring it to 100%. I also plan to swap out the GE DHā€™s so that I can capture double taps for local overrides to 100%.

#3

in a sense this has nothing to do with webcore. its about cloud processing. if you process the number of events each hub processes in the cloud some failures are bound to happen. if you processed the same number of transactions through amazonā€™s website which is also backed by the same cloud infrastructure you would also see about the same number of failures. that is just the nature of the beast when it comes to cloud processing. :slight_smile:

what would be optimum is if ST started supporting local processing for all DTHs & apps. that would take the network latency out of the execution path and move it to the less time sensitive analytics and modeling workloads which as a framework provider i am sure what ST uses this data for.

ST has been moving to provide more local processing but a bit slowly for me. however i am sure they have their own challenges to deal with before they can support local processing for all DTHs & apps and appreciate the additional support for local processing that they do continue to build out.

so if you would like to see webcore work just as fast as smart lighting encourage ST to move to all local processing ā€¦ faster. :slight_smile:

cheers.

#4

Thanks, you are absolutely correct about WebCore vs cloud. I only mention WebCore specifically, because, well, we are on a WebCore site :slight_smile:

I can understand why there is some requirements for cloud processing. I left the Vera environment to come to STā€¦and now ST/WebCore. Prior to Vera, I was running Homeseer light, or whatever it was called 10 years ago. Local processing gets all the points in latency and reliability, but has a major drawback and that is lack of compatibility with other cloud based platforms. Ehemm, let me clarify that, lack of ā€œmaintainedā€ compatibility. There is not shortage of well intended folks who will right routings to tie your Hue cloud into Veraā€¦but they wonā€™t maintain it. My Vera setup was really greatā€¦5 years ago when I put everything into it. Then people moved on from their projects and they were no longer supported. Ecobee made upgrades, Hue made upgrades, Vera itself made upgrades. If youā€™re not a programmer, you are at the mercy of the community.

At least with WebCore, the language is simplified that someone with my level of competence is comfortable. I used to program databases, so I understand the architecture from Visual Basin and WebCore is very similar to this. The more advanced programming languages required for customizing these local systems is outside my scope and will be for the masses at large.

So the intent of my question is not knock on WebCore or cloud processing at largeā€¦just an inquiry if there is any benefit or unintended consequence to providing a basic local boost.

#5

there really should be no requirement for cloud processing. the hub should be able to download the code and run it locally anytime the code changes on the cloud. if in local execution it runs in to instructions that require it to make a call to cloud for integration with other cloud based platform sure. but that should not be required for native execution supported by the ST framework.

that totally sounds like a lot of fun. :slight_smile:

but you shouldnt have to customize anything, you should be able to write webcore code as you anticipate doing now. that piston in webcore will then become a smartapp that is downloaded from the cloud to your hub and processed locally on your hub whenever a subscribed to event arrives for that piston. so users shouldnt have to do anything to support or customize this. the magic should happen in the cloud so everything does work locally. :slight_smile:

you could complement one with the other however it soon becomes a lot of maintenance and delicate balancing of what each does to get the exact results that you want.

#6

Thanks for your insight. I wonā€™t go point for point, but I will add to this:

Thatā€™s exactly why I am here asking these kinds of questions :smiley: Thanks for your time buddy!

#7

As a interim measure Iā€™m planning on doing something like this.

Use the smart lighting to turn the lights on /off (all local so no issues) but then use WebCoRE to change the levels depending on the conditions IE

IF switch is on and time is

Then set level too

This way we get the best of both untill the magical day comes when WebCoRE is smartlighting fingerā€™s crossed :+1:

#8

As long as your statements are time based, that will work. With motion based, it does not work as there is no setting in Smart Light to prevent an on at motion from overriding an already on. You can only override by mode.