How to prevent one device confusing the whole network?

Posted on
Fri Mar 09, 2018 7:04 pm
superholz offline
Posts: 22
Joined: Jun 10, 2015

How to prevent one device confusing the whole network?

Following remark/question about Z-wave and Indigo in specific.

Is there a way to teach indigo that it should ignore if a device does not respond in order to keep the whole scene running and not slowing down the whole network?

Background is the following: Sometimes our cleaning woman or my wife takes a device (eg. a z-wave RGB bulb) from the electricity and forgets to put it in.
When a scene like all lights out is triggered than this light can not respond. This leads to quite strange behavior of the rest of the network. Like seamingly arbitrate switching of lights. And that’s I think because the system tries to finish the task and switch also the RGB bulb off and get it confirmed.
A better solution would be if the light is ignored until it comes back up and still executions and finalizing the scene.

To me it seems that a little disturbance of the network (in form of an unreachable node) brings the basic functionality into danger. Of cause for some scenes this might be useful. Eg. Do not close window shutters when the window does not respond (and could be still open). But for others it seems to be absurd to create a disco light because one of the nodes is not responding.

Are there possibilities to tell Indigo to be more flexible there?




Gesendet von iPad mit Tapatalk

Posted on
Sat Mar 10, 2018 11:18 am
matt (support) offline
Site Admin
User avatar
Posts: 18380
Joined: Jan 27, 2003
Location: Texas

Re: How to prevent one device confusing the whole network?

A lot of the slow down you see occurs at the protocol / Z-Wave interface level. If it doesn't receive an ACK for a command then it will retry, and try using different routes. As you've seen, this can be very slow as it tries to discover another path to reach the module. Indigo has no control over that, but I think what you are requesting is that after that occurs the first time that Indigo then flag that device as unreachable and skip sending commands to it. Indigo doesn't currently support that functionality. I'll add it to the list. It would be somewhat tricky to implement because for some device one would want Indigo to persist in re-trying even if it is momentarily unavailable.

Image

Posted on
Sat Mar 10, 2018 3:39 pm
superholz offline
Posts: 22
Joined: Jun 10, 2015

Re: How to prevent one device confusing the whole network?

Hi Matt, thanks for the reply.
Indigo should finalize the scene and ignoring the device for the further execution of the scene. At the current behavior the whole system is more or less as a bug on his back struggling to reach the device and not able to perform other tasks.
But is it the z-wave low level behavior trying to find another path Or could indigo stop this proces and go further with other tasks?
If this is possible I would definitely recommend to put it on the list. Somehow crucial dependencies within a scene have to be still considered, as the example with the window I mentioned. But still that should be possible to define criteria to interrupt the scene and having the system responsive for other tasks again.

One could also try to proactively let indigo define what will happen if a device was not “seen” in the network for some time.



Gesendet von iPad mit Tapatalk

Posted on
Sat Mar 10, 2018 6:49 pm
jay (support) offline
Site Admin
User avatar
Posts: 14156
Joined: Mar 19, 2008
Location: Austin, Texas

Re: How to prevent one device confusing the whole network?

superholz wrote:
Hi Matt, thanks for the reply.
Indigo should finalize the scene and ignoring the device for the further execution of the scene. At the current behavior the whole system is more or less as a bug on his back struggling to reach the device and not able to perform other tasks.
But is it the z-wave low level behavior trying to find another path Or could indigo stop this proces and go further with other tasks?
If this is possible I would definitely recommend to put it on the list. Somehow crucial dependencies within a scene have to be still considered, as the example with the window I mentioned. But still that should be possible to define criteria to interrupt the scene and having the system responsive for other tasks again.

One could also try to proactively let indigo define what will happen if a device was not “seen” in the network for some time.


To reinforce what Matt said, Indigo has no control over that level of communication. For instance, Indigo doesn't control what routes a given command will take. Indigo can tell the network to rebuild itself, but that's about it. That, of course, isn't what you want since the device has only temporarily been disabled. Indigo can disable the device within it's own context, but that's not going to avoid the network issues.

Bottom line: you need to figure out how to prevent the situation in the first place. Solve the problem and not the symptom as we often say.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Sun Mar 11, 2018 4:12 am
superholz offline
Posts: 22
Joined: Jun 10, 2015

Re: How to prevent one device confusing the whole network?

Jay, thanks for clarifying a bit more. I don’t completely agree regarding not fighting the only the symptoms. The problem is not to avoid when you think of having home automation (at least half) fool proof. It is an absolut likely scenario that a device is unplugged. It’s also what would be intuitive to many people, that they just unplug a light for instance when the uitlet should be used for a vacuum cleaner. I often see in the discussion and also discussed in these forum when you read of wife’s having to deal with her husbands home automation ;-). I understand that a lot depends on the z-wave design it’s left and I’m not blaming you for that. What I still not completely understand is what indigo could have on - indeed - fighting the symptoms of a not reacting device. What I still not completely understand: The delay that I’m experiencing when a scene is triggered and one device is not reachable - is that cause by the z-wave low level functionality to reach that device or has indigo an influence how long the next action in the scene is executed and how long it takes for the whole system to be responsive again? Indigo will get the info from the Z-wave controller that one device is not reached within x time? Could indigo than do something with this information and cancel the request to this specific device?



Gesendet von iPad mit Tapatalk

Posted on
Sun Mar 11, 2018 1:22 pm
jay (support) offline
Site Admin
User avatar
Posts: 14156
Joined: Mar 19, 2008
Location: Austin, Texas

Re: How to prevent one device confusing the whole network?

superholz wrote:
The delay that I’m experiencing when a scene is triggered and one device is not reachable - is that cause by the z-wave low level functionality to reach that device or has indigo an influence how long the next action in the scene is executed and how long it takes for the whole system to be responsive again? Indigo will get the info from the Z-wave controller that one device is not reached within x time? Could indigo than do something with this information and cancel the request to this specific device?


That is a Z-Wave routing issue - if the stick isn't first successful communicating through the first route it tries, then it tries another rout. While that's happening, the stick doesn't send out other commands to control other devices, thus the delay. Indigo will eventually get a 'no ack' error from the stick when the command fails all attempts from the stick, but there's not much we can do about it then: we can disable the device in Indigo, but then it will never come back until you reenable it (the Z-Stick will never tell is it's back). Also, the Z-Stick may continue to try to use that node as a route, so it'll continue to cause slowness until a network reorg happens within the stick. Network reorgs are slow and costly so you don't really want to do them very often, not to mention that you don't want to remove a device that is transiently gone since you know it'll eventually come back (or not).

Indigo also can't cancel a request to the stick - the interface will just eventually fail.

If the device in question ends up being a bottleneck to reach other devices (there isn't another available route or the other route requires lots of extra hops), then you'll want to add another routing device that has little to no chance of ever being accidentally removed (like a wall wart). I'm going to go out on a limb here and say that you may have some mesh weaknesses if one device being turned off so significantly impacts your overall network performance. I, too, have devices that sometimes go off line but I never have a noticeable delay. You might try adding a plug-in repeater to see if that helps strengthen your network.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 1 guest

cron