Rule Runs Very Slow

Can Zipato check into this? I would like to add more devices to my system but am concerned that the slow response has something to do with the number of devices that I current have. I have 33 devices. Can others on this forum say if 33 devices is considered a lot and if there system operates slowly.

How would I go about troubleshooting to determine the issue why the system is running slow.

I wouldn't say 33 is a lot no, I've started to have issues with rules and scenes running slow as well. I've read elsewhere it can be related to Zipabox communicating to other IP devices such as Hue, IP cameras, ect, as a test I removed my recently added Zipato IP camera and things have got a lot faster, however using the Zipato RFID keypad to disarm and arm the alarm seems to still be slow. I've logged a call with Zipato so will see what they say.

Dave,

Thanks for your reply. I do not have any IP devices now unless you consider a virtual weather station to get sunset and sunrise times an IP device.

I have a similar problem but it consider movement sensors outside. When the box is just restarted the lamps turns on immediately. But later on it can takes upp to 5 minutes before they turns on.

Even one minute is too long delay for e.g. light related rules. Very annoying. And very often.

I think it's a bad idea that if a device triggers a rule with a ANY to also change the state of that device in the rule. This could potentially lead to loops (the JOIN complicates things even further). I don't know how the rules are actually implemented in code so maybe it causes some other weird stuff.

The following example is to show what could happen.

1. Starting situation: the switch "All lights off switch" is "On"

1. You switch "All lights off switch" to "Off" this triggers the rule

2. Run scene - all off

3. Switch "All lights off switch" to "On", the rule is triggerd again go to step 2 but because you have defined a join, the current rule executtion is stopped. So what happens now, is the state of the switch "All lights off switch" really set to "On"? Or because the rule execution is stopped only the event is trigger but the state hasn't changed? No idea.

You're starting situation is probably different but this is just to show the possible problems you can cause by change the state of the device in the rule that also triggers it. And if you als add a JOIN, who knows what will happen.

So my solution would be don't change the state. You can keep the any if but add an if statement:

1. WHEN "All lights off switch".ANY
2. IF "All lights off switch".ON
3. Run scene - all off

Geert,

It would be nice to set the "all lights off switch" to on if any of the lights in the scene are on. Do you know of an easy way to check all lights switches in the house and if any are on, turn the "all switch light" to on. I would then also most likely need one to check and turn the all lights switch to off if all are off.

If there is a way I think this would then require the previous rule be changed such that the when all lights off switch "any" be changed to "off" as I would be setting it to ON whenever any of the lights are turned on in the house.

You could easily change the rule above to:

1. WHEN "All lights off switch".OFF
2. Run scene - all off

The name of the switch is a bit confusing. So I assume that when:

- "All lights off switch" = OFF -> All light must be turned off and are off after running the above rule

- "All lights off switch" = On -> Any light is on

I don't know of an easy way to turn it on other than:

1. Modify every rule where you turn on an individual light, also set the "all light off switch" to on.
2. Modify every scene where you turn on lights to also turn on the "all light off switch" (so not in the rule itself but in the scene).

I usually don't turn on and off devices individually but always through a scene. I've just got the box when I'm a bit further along I will post about my setup.

The rule works as you have noted above.. but runs slow. Somewhat useless until Zipato can speed it up. I can eliminate all rules and it will run slow.

The sensor associated with door and the lights work instantly. So a trigger associated with a door sensor is treated differently than a trigger associated with a Z-Wave Switch.

Does anybody know how to get Zibato to think a Z-Wave Switch is a door sensor instead?

I suspect the issue is reporting vs. polling.

Sensors like motion or door open instantly report a change in status to the controller when it happens so the controller can run the rule right away. Lutron owns the patents on light switches reporting their status, so the controllers have to poll them instead. So the delay is likely caused by how long between polling intervals it takes the Zipato to update it's status on the switch. Cooper has either licensed or gotten around Lutron's patents so they are the only other switch allowed to instantly report a status change.

But, I have Cooper switches and am experiencing similar delays between change in status and rules executing so I suspect that Zipato has not implemented the ability for Cooper (and likely Lutron) switches to instantly report their status change. I'm trying to transition from a Vera and I know they have implemented the ability so it is possible to do so.

I haven't looked yet to see if you can use any of the configuration parameters to change the per switch polling time

Ron,

Thanks for your insight into the problem. It sounds like you may have gotten to the route cause of the problem. I will try some other switches to see if I have better luck and report back.

Have you tested how the rules acts during the first hours after a restart of the box?

Does this mean that battery operated switches will drain battery really fast, since they will have to listen for state requests all the time?