Light switch replacement...that's not a switch

  • 761 Views
  • Last Post 16 March 2017
Dignan17 posted this 09 March 2017

A while back I purchased 2 Enerwave 7-button scene controllers. They mostly worked pretty well, but always seemed cheaply made. Sure enough, one of them burnt out.

Now I'm looking for something to replace it. I don't have much faith in these scene controllers, and I don't need a switch in this location, so I'm looking for something else to go in here, but I can't think of what.

This switch location is just inside the doorway of a bedroom, and the switch was initially set up to control an outlet on the other side of the room. But hey, I use ZWave, what do I need switched outlets for? So I wired the outlet to permanent-on, and put the scene controller in its place. This worked fine until the burnout.

So what else can I put in there? For the time being, I put in a Linear accessory switch and associated it with a floor lamp in the room, and that's ok but I'd rather have it able to control a scene, but I'm not sure if that's possible.

Any suggestions?

Order By: Standard | Newest | Votes
rscott posted this 09 March 2017

Yes, you can use those accessory switches to activate a scene. You'd need to associate it with your controller instead of your outlet. When you do, Axial Server will receive notice of the "on" and "off" states of the accessory switch. You can use this to trigger scenes.

 

Dignan17 posted this 09 March 2017

That might work, but if I'm understanding it correctly, this could get off track pretty easily if I control scenes in the room through any other method. For example:

  • I enter the room with all the lights off
  • Tap up on the switch, the scene turns on
  • Use the app or another controller or a timed event (or anything) to turn the scene off
  • The switch is still in the "up" position
  • Enter the room again and tap up but nothing happens

Am I understanding what would happen correctly? I suppose I could set those scenes to also turn the switch "off," but I worry that sending the state within the scene would retrigger the scene again. So if the lights are off, and I use my phone to start the scene that ends with turning the accessory switch to the "on" position, wouldn't that act of turning it to the on position be recursive, starting that scene again?

Does anyone know of a motion sensor that can be installed in place of a switch? Or perhaps a well-made scene controller that goes over a switch? I suppose I could just shove the wires behind a blank plate, and then put that Aeon Labs Wallmote on top of it...

jonnysax posted this 09 March 2017

From what ive seen, those accessory switches are not typical sitches that have an on/off position, they are like all other zwave toggles of paddles in that there is a central position it always springs back to.  So, it will never get off track.  

Dignan17 posted this 10 March 2017

I think you misunderstand me. I'm not talking about the physical state of the switch, I'm taking about the system state. It has a state, even at the switch its self. The LED shows you, and that's reflected in the software.

nelis249 posted this 11 March 2017

All my zwaves do not 'toggle' like a typical rocker switch. They all just click. From the pictures it looks as though the Linear accessorry switch is the same.

Dignan17 posted this 11 March 2017

Again, this is NOT about the physical state of the switch. My initial post even said that I've already installed the switch, so I'm not sure how I wouldn't notice that it doesn't physically rock like a normal decora light switch.

I'm taking about the state, and so far all my assumptions have borne out. I haven't tried changing the state in a scene yet because I don't want the system to get in an endless loop, and Ryan hadn't commented on whether that would happen or not...

nelis249 posted this 11 March 2017

Maybe those LEDs are for the zone lighting. As far as I'm aware, scenes do not have a 'state'. They are just activated.

  • SceneA turns lights on.
  • Program button1 to SceneA.
  • Press button1 activates SceneA (lets say LED is on).
  • Pressing button1 again doesn't 'deactivate' SceneA, there's no such thing. It activates SceneA.

To actually toggle the lights on and off, your scene would have to 'toggle' the lights and then as you say they might get out of sync. Pressumably making conditions to handle the lights getting out of sync may help. I've only worked with 3 different types of zwave conrollers and there are dozens so maybe others function differently, but I've not encountered one where 'scene' has a state of on or off, they were merely just 'activated'.

 

rscott posted this 11 March 2017

I believe if you hit up twice in a row, you'd send two "on" commands to Axial in a row, so I don't think you'd be able to get out of sync. It probably wouldn't be very hard to setup a test and verify the functionality.

cowinger posted this 11 March 2017

Since the WT00Z-1 has the ability to transmit and receive signals then there is a way to control it also. The LED shows an "on" state when the switch is off (by default and can be changed, see below, and referred to as a night light). So If you press the paddle up to send an on command then your scene then activates and turns on your lights. But you are saying that the switch is still in the 'on' position based on the LED status. If you use the app to turn off the lights then the lights go off but the switch remains the same. Perhaps in your scene you can send an off command to the switch at the same time you send an off to the lights and vice versa. So if you turn the lights on by the switch and turn them off by the app or something else then both the switch and the lights are at the same status level.

Parameter 3 sets the LED as follows:
0-switch off, led on
1- switch on, led on
2-led always on
3-led always off
4-led blinks once for either on or off push

Hope this helps.

Dignan17 posted this 11 March 2017

@nelis249 - I think you're misunderstanding me again. I wasn't talking about scene states, I was talking about the state of the switch in Axial. Let me explain: the Linear accessory switch is like any other zwave switch, it just doesn't support a load. The switch still considers its self to be either "on" or "off." The LED on the switch reflects that state, and should generally be reflected in Axial.

@rscott - Unfortunately, it doesn't look like that is correct. If the switch believes its self to be "on," and the lights were turned off by any other means, tapping "on" again doesn't do anything. If I tap "off" and then "on" again, the scene runs.

@cowinger - That's what I was thinking of doing, but here's the problem I'm seeing, and I was looking for Ryan's guidance on it:

  • switch is tapped "on"
  • scene runs, ending with turning the switch being "turned on" so to speak
  • scene runs again because it sees the trigger of the switch turning on
  • repeat over and over

Is that what would happen? I could just try it and see, but I don't want to crash everything...

cowinger posted this 11 March 2017

Using the scene to set the switch to the same level as the lights should not have any effect other than changing the switch status. Think of it as if the scene sends a command to turn on the lights and a second command to set the LED status of the switch and since the lights are already on there should be no conflicts. It would be like hitting the on to the switch 2-3 times in the on position. The first tap would turn on the lights but the other taps would be ignored and have no effect because the lights are already on. Same for off. If you turn off the lights say by the app and you send a command to change the switch LED to off there is no conflict because the lights are already off.

Hope that helps.

Dignan17 posted this 12 March 2017

I understand that it wouldn't affect the state of the lights, but I was wondering if it would create a loop within Axial that kept the scene looping. The switch turns on the scene which tells the switch to move to the on position which starts the scene, etc.

I tried it anyway, and I can't actually tell whether that's happening or not. It did create some weirdness, though. One of my scheduled scenes didn't run, and when I tried to turn on my lights when I got home they turned on VERY SLOWLY, like one light (out of 10) every 20 seconds. I'm going to restart the controller just to be safe, but I'm taking the switch state command out of those scenes just in case. I'll keep the triggers in place, but even those don't seem to work every time...

cowinger posted this 12 March 2017

If you wouldn't mind could you share one or more of the scenes you have written just in case there is something there that is causing this strange delay. The scenes having the command to change the switches LED on or off shouldn't have any effect or relationship to your lights coming on so slowly. Perhaps something else in one or more of the scenes is the culprit. The reason I say that the switch changing state is not the problem is because that switch is no different than any other switch except it doesn't control a load. All other functions are the same. But, one thing that could be affecting this is if there are any associations that have been created. If there are any those need to be looked into also.

After thought: Have you tried putting a 1 or 2 sec pause in the scene between the lights on or off command and the on or off command sent to the switch?

Dignan17 posted this 16 March 2017

Thanks for your help, but I don't think we're talking about the same things. I'll contact Axial support if I need anything else. Overall, the performance of my entire network has been sub-par for as long as I've used Axial, and every time I've tried to work with support to fix it I've never gotten anywhere. I'm really sick of this.

rscott posted this 16 March 2017

Thanks for your help, but I don't think we're talking about the same things. I'll contact Axial support if I need anything else. Overall, the performance of my entire network has been sub-par for as long as I've used Axial

Happy to help out where possible. Most performance issues are because of the devices themselves. If you have lots of devices, or if your devices have to route commands, that'll really put a damper on commands going out from Axial. 

Here's a common scenario - in order for Axial to know the current status of your devices, it automatically polls them. Polling requires at least two messages in a perfectly tuned z-wave network - one going to the device and one coming back. If your network isn't optimal -- they rarely are -- then that message has to bounce around multiple devices before it gets to the intended device, then multiple other devices to get back to your USB stick. According to the z-wave specifications, it can take up to 50 seconds in worse case scenarios for a command to be sent across the z-wave mesh. During which time, your USB stick is "on hold" waiting for a response. That means if your network is sub-optimal, you'll experience delays when trying to send commands to your devices.

There are things you can do:

  • Make sure you do not poll any battery powered devices unless you queue the commands until the device wakes up
  • Make sure you don't have any dead devices in your network. If you've lost a switch, replace it or remove it from the mesh or other devices will attempt to route messages through it
  • Increase the poll frequency on your devices (i.e, they are at 30 seconds by default; if you can increase that to 60 or 90 seconds or higher, that'll remove a lot of the traffic going over your mesh)

Dignan17 posted this 16 March 2017

Thanks for the response, Ryan. I'll try to address some of your suggestions:

  • I wouldn't be surprised if the problem were with my devices, but it's frustrating to not know which devices might be the problem. I wish there were a way for Axial to take all the data over a period of time - say, a month - and say "Hey, I noticed I'm tripping up all the time with this one device over here, you might want to think about replacing it."

  • I'm very careful to not poll battery-powered devices. All my minimotes are not polled, same with my door lock and anything else without permanent power. It's actually not a very large number of devices.

  • A couple weeks ago I went through a great deal of effort to remove any dead devices from my network. It was a real PITA, too, as my ZStick didn't want me to remove devices through Zensys or anything else, but I eventually got it to stick. Now I only have good devices in Axial.

  • I think I'll increase those poll times like you said. I guess it's not going to diminish anything I've got going on. I can see how the size of my network and the topography might create some traffic. I'll try things out with most of the devices at a full 90 seconds just to see if there's any difference, and if things go really well (hmm) I might walk that back a little.

Thanks again.

Change Language
Categories
Search
Popular Tags
Hot Topics
Close