Is using multiple ST Hubs in the same location a good way to overcome activity delays?


#1

I’m not really sure where to post this…hope this is right.

I have well over 50 ST devices in my system and I am sure some of my WebCore pistons (20-30 pistons) overlap devices and I could do better with that as well. But, I think pistons that end up needing to run at the same time are messing things up…For instance, I have one that triggers the back doors to unlock and the garage to open when I toggle a virtual switch from a wall mounted button controller by the back door.

There is also a piston that triggers when I open the back door to turn the light on outside which usually happens quickly after I trigger the virtual switch I mentioned above and often that light turning on is very delayed or doesn’t happen at all.

I’m just wondering if I purchased one or two more hubs and split the operations/devices between them and then used “super global variables” (which I think would work for this) to keep certain things they all need to know to be in sync with would help?

Has anybody tried this?


#2

I would not advise that. I would think if you wanted to make things operate quicker that you would instead move simple tasks off WC and get them to run locally where possible.

For example, the Smart Lighting app will allow you to run some commands locally off your hub rather than making a round trip up to the cloud and back. If you have a simple automation (when this opens turn on this light) I would consider moving that into Smart Lighting. Then it no longer needs to go out to the cloud.

Beyond that though, if you’re creating complex pistons and you want to know why they are not working turn logging in WC on to FULL and read through the logs to see what is happening. You can also look at the device logs to see what the devices themselves are doing You could also add your own logging information to the logs so you can troubleshoot problems.

Ultimately though, I would entirely agree that it is possible to create an environment within WC that could fall apart based on a myriad of different pistons all competing against each other for the attention of the system. So don’t do that. Keep it simple…and adding more hubs does not keep it simple. .


#3

THANKS!

I will give Smart Lighting a try. I know the answer to the next question is yes to both…but…

In general, is it the latency to/from WebCore servers or the processing power of the hub the biggest cause of slow or dropped requests? There’s no QoS on the Internet, but I’m guessing it’s the under powered CPU/Memory of the ST hub that’s the main culprit. I am also guessing the servers are not where this webpage is (for some reason I thought they were actually in Europe), but it’s round trip time to this web server is quite small.

104.27.186.240 IP Address, CloudFlare, United States, California

ping webcore.co

Pinging webcore.co [104.27.186.240] with 32 bytes of data:
Reply from 104.27.186.240: bytes=32 time=17ms TTL=57
Reply from 104.27.186.240: bytes=32 time=19ms TTL=57
Reply from 104.27.186.240: bytes=32 time=13ms TTL=57
Reply from 104.27.186.240: bytes=32 time=21ms TTL=57

Ping statistics for 104.27.186.240:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 21ms, Average = 17ms

The problem is I do want things like the back porch light to come on when it’s dark anytime I open the door AND I want to be able to trigger the piston that unlocks those doors and open the garage when I go out…as well as most the lights in my house to start to turn off. Those pistons would always compete if all trying to run at the same time. I’d also like things like presence senors to work seamlessly ALL of the time :sunglasses: and totally get home automation is a fledgling field still (and WebCore is the BEST thing out there hands down).

I’ve been networking since the early 90’s and get that it’s not a perfect world and patients is a virtue :slight_smile: …on the other hand…my better half is not and gets a little frustrated when things work “sometimes.”


#4

One thing you could try is more event-based pistons when you have a lot of things triggering at the same time.

For example, rather than having a porch light piston, a garage door piston, and a door lock piston firing when your back door is opened… create one piston that fires when your back door is opened and have it take actions across all devices.

It may help you reduce your numbers of pistons and the dreaded “piston waited at a semaphore for 10 seconds” delays.

I have a combination of activity based and device based pistons now. With over 50 devices connected I still have pretty good piston execution times.


#5

Thanks. Right now I do have all in one piston that is triggered by a virtual switch via a button controller…two back door locks and opening the garage. That works fine. However, to be able to turn the outside the door light on ANYTIME the back door is opened at night that takes a separate piston as it’s technically an unrelated event. I tried adding a “turn on the light” step to the door open piston…but since that has to capture the state…check the sunset/sunrise etc trigger…AND compete with the piston that watches the door all the time…it’s even worse. The button controller is by the back door (since that’s where it’s needed) and that means the trigger from the button controller will always be followed within seconds of opening the back door and both pistons will almost always compete for time slices. Sometimes it works…other times it doesn’t.