GE wall switch on/off vs toggle

I can confirm that this is STILL an issue in 0.27 of Home Assistant. I’ve wiped my controller and have most everything else working, but not the z-wave switches. Upon further investigation, it’s exactly as described in the original post. You turn on/off a switch, it turns on and then off. If you click the refresh button, it shows the correct state and can then turn the switch back off again. As suspected, when you turn off, it turns BACK on again.

Any assistance would be greatly appreciated as this is the one item from me dropping my HomeSeer demo install and making the switch to Home Assistant.

My configuration:
Home Assistant 0.27
Raspberry PI3
HomeSeer Stick+
DragonTech and now HomeSeer Z-Wave Plus On/Off and Dimmer switches

I still haven’t fixed it. I’ve just been using refresh.

I’m curious… is your install using the All-In-One Installer or a manual install? I installed using the AIO and had quite a few issues with it initially, so I’m wondering if it this is my problem.

So, I re-installed everything fresh manually and am getting the same exact results. One thing I did try was flipping the switches from a mobile device. Oddly enough, if I have streaming upda tes turned, it works as expected. So, I tried on my Windows 10 Enterprise machine using Chrome, Firefox and Edge and all are yielding the exact same results.

Now, it occurs to me to try in a virtual machine and on a different computer even… once I do that, everything works. So, I can confirm that it’s something that we both are running on our local machines that is causing this and 100% not an error within Open Z-Wave or Home Assistant itself.

Hope this helps.

Interesting. What OS did you use on your VM?

I’ve tried on Windows Server 2008 R2, 2012 R2, OSX, Windows 8.1 and Windows 10. All worked except Windows 10, but all others were VMs except OSX and Windows 10. Try running it on your mobile device and see if it magically works.

Yeah. I found it works on my mobile. It doesn’t work on my Windows 7 box either. I tried every browser. It wad a fresh install of windows 7 too. I don’t know what would be causing it…

FYI, I found this thread while searching on this same problem. If I clicked a switch off, it would still show on. Clicking it to off again would often update the status correctly with no change in the actual light. Sometimes that involved clicking it on and then off again. I was seeing this mostly with some DragonTech dimmers (PD-100, functionally identical to WD-100).

While investigating this, I discovered that the zwave library was making an immediate request for the dimmer’s value after sending a command. That was generally inaccurate, especially for “off” commands, since the dimmer has a ramp-up and ramp-down when the switch state is changed. The default dim time was such that first response to an “off” command usually indicated a value of 66 (in other words, not off!). I observed that there was a two-second delay, followed by another refresh of the value. This was still so fast that it usually got a value of 33 (still not off!).

I went looking and found that there are a couple of Z-Wave options that helped in my situation.

In configuration.yaml, my zwave section looks like this:

zwave:
  usb_path: /dev/ttyACM0
  customize:
    light.dragon_tech_in_wall_dimmer_level_2_0:
      refresh_value: true
      delay: 5

I’m still playing with this a little bit, but five seconds delay and five second refresh seem to fix the problem for me. It DOES take a few seconds for the switch and indicator to show correctly in the interface, but it works correctly.

I have to play with one other bit for these devices, in that they don’t seem to report their value consistently when manually clicked on or off from the dimmer device. I’m not at home right now, so I can’t play with that, but that’s next on my list.

Also note that if you have updated the default dim time on the dimmer module, the switch not sticking problem is mostly solved, as the two-second default refresh is faster than the minimum 10ms dim time. I have a couple of lamps that don’t dim nicely and have the dim time set to minimum, and did not see the problem there. I also have two Everspring appliance on/off modules, but those seemed to do the right thing most of the time. I’ll have to experiment more tonight to see if they also need to be added to the customize section with updated refresh and delay values.

Happy automating…

jonathan

[edit: z-wave parameter reference link: https://home-assistant.io/getting-started/z-wave/]
[edit #2: Another helpful fellow noticed that the docs are incorrect, and the value for refresh_value is a true/false. If true, the value is refreshed after delay seconds. Thanks, @dcnoren and @er0ck !]

1 Like

@jwoytek
thank you. that worked. completely missed this

this seems to have happened with my one z-wave switch all of a sudden. its automation has been working great, but the toggle switch in the UI does not, as of today.
i thought it was when i started exposing it via emulated_hue, but when i set this device to emulated_hue: false, i still have the problem. if i turn off emulated_hue: altogether i still have this problem.
the customization for this device also does not appear to fix it.

i’m using a z-stick and a ge_12720_outdoor_smart_switch_switch_2_0
my zwave polling_interval: 10000

if i send “turn_off” from the developers services util, it still toggles back on, same with toggle

if i manually toggle the switch with its button, they turn off.
but hass still reports it as on, and continues to do so after hass restart

i have a bunch of these in the OZW log:
2017-01-08 21:39:13.671 Detail, Node002, Received: 0x01, 0x07, 0x00, 0x13, 0x17, 0x01, 0x01, 0x9d, 0x61
2017-01-08 21:39:13.671 Detail, Node002, ZW_SEND_DATA Request with callback ID 0x17 received (expected 0x17)
2017-01-08 21:39:13.672 Info, Node002, WARNING: ZW_SEND_DATA failed. No ACK received - device may be asleep.
2017-01-08 21:39:13.672 Warning, Node002, WARNING: Device is not a sleeping node.
2017-01-08 21:39:13.672 Detail, Node001, Expected callbackId was received
2017-01-08 21:39:19.545 Error, Node002, ERROR: Dropping command, expected response not received after 1 attempt(s)
2017-01-08 21:39:19.545 Detail, Node002, Removing current message
2017-01-08 21:39:19.545 Detail, Node002, Notification: Notification - TimeOut

i used alexa to turn these on, that was the most recent hass change. hass automation worked yesterday. i just started using emulated_hue today

Should that not be the following?

zwave:
  usb_path: /dev/ttyACM0
  customize:
    light.dragon_tech_in_wall_dimmer_level_2_0:
      refresh_value: true
      delay: 5

true for refresh_value, and then specify the 5 for delay? It might work with a 5 for both, but technically I think it should be a true for refresh_value?

not according to: Z-Wave - Home Assistant

refresh_value (Optional): Enable refreshing of the node value. Only light component uses this. Defaults to 2 second delay.
delay (Optional): Specify the delay to wait for refresh of node value if you want other than 2 seconds.

edit: oh but the docs are wrong:

you are right. boolean for refresh_value
maybe non0/nonfalse/non-nil is truthy?

i tried a heal_network from hass and got:
2017-01-08 21:53:50.221 Detail, Node001, Removing current message
2017-01-08 21:53:50.221 Detail, Notification: ControllerCommand - InProgress
2017-01-08 21:53:59.415 Detail, Received: 0x01, 0x05, 0x00, 0x48, 0x18, 0x23, 0x89
2017-01-08 21:53:59.415 Detail,
2017-01-08 21:53:59.415 Warning, WARNING: REQUEST_NEIGHBOR_UPDATE_FAILED
2017-01-08 21:53:59.415 Detail, Notification: ControllerCommand - Failed
2017-01-08 21:53:59.416 Info, Requesting Neighbor Update for node 2
2017-01-08 21:53:59.416 Detail, Node002, Queuing (Command) ControllerCommand_RequestNodeNeighborUpdate (Node=2): 0x01
, 0x05, 0x00, 0x48, 0x02, 0x19, 0xa9
2017-01-08 21:53:59.416 Detail, Notification: ControllerCommand - Starting
2017-01-08 21:53:59.416 Detail,
2017-01-08 21:53:59.416 Info, Node002, Sending (Command) message (Callback ID=0x19, Expected Reply=0x48) - Controller
Command_RequestNodeNeighborUpdate (Node=2): 0x01, 0x05, 0x00, 0x48, 0x02, 0x19, 0xa9
2017-01-08 21:53:59.441 Detail, Node002, Received: 0x01, 0x05, 0x00, 0x48, 0x19, 0x21, 0x8a
2017-01-08 21:53:59.441 Detail,
2017-01-08 21:53:59.441 Info, Node002, REQUEST_NEIGHBOR_UPDATE_STARTED
2017-01-08 21:53:59.441 Detail, Node033, Expected callbackId was received
2017-01-08 21:53:59.441 Detail, Node033, Expected reply was received
2017-01-08 21:53:59.441 Detail, Node033, Message transaction complete
2017-01-08 21:53:59.441 Detail,
2017-01-08 21:53:59.441 Detail, Node002, Removing current message
2017-01-08 21:53:59.441 Detail, Notification: ControllerCommand - InProgress
2017-01-08 21:54:07.162 Detail, Received: 0x01, 0x05, 0x00, 0x48, 0x19, 0x23, 0x88
2017-01-08 21:54:07.162 Detail,
2017-01-08 21:54:07.162 Warning, WARNING: REQUEST_NEIGHBOR_UPDATE_FAILED
2017-01-08 21:54:07.162 Detail, Notification: ControllerCommand - Failed

where Node002 is the offending switch.
i moved the switch right next to the controller (z-stick) and it’s still timing out. i’ll try re-pairing it

That’s funny, I read the docs differently than you did; I read it as refresh_value, enable refreshing - so therefore true/false. The refresh_delay option defaults to 2, and only comes in to play if the refresh_value is true.

Anyway, glad it was working anyway! Sorry to nitpick! :slight_smile:

you are right on how it could be read. i PRd to change it but maybe i’ll try to make the language more clear.

unfortunately my switch refuses to reply now

i excluded the offending node, re-included it, restarted hass and its container. now for some reason the zswitch is on a different tty device (no idea).
and the logs say:
2017-01-08 22:55:27.531 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_GET_VERSION: 0x01, 0x03, 0x00, 0x15, 0xe9
2017-01-08 22:55:27.531 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_MEMORY_GET_ID: 0x01, 0x03, 0x00, 0x20, 0xdc
2017-01-08 22:55:27.531 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_GET_CONTROLLER_CAPABILITIES: 0x01, 0x03, 0x00, 0x05, 0xf9
2017-01-08 22:55:27.531 Detail, contrlr, Queuing (Command) FUNC_ID_SERIAL_API_GET_CAPABILITIES: 0x01, 0x03, 0x00, 0x07, 0xfb
2017-01-08 22:55:27.531 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_GET_SUC_NODE_ID: 0x01, 0x03, 0x00, 0x56, 0xaa
2017-01-08 22:55:27.531 Detail,
2017-01-08 22:55:27.531 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x15) - FUNC_ID_ZW_GET_VERSION: 0x01, 0x03, 0x00, 0x15, 0xe9
2017-01-08 22:55:28.532 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2017-01-08 22:55:28.532 Detail, contrlr, Removing current message
2017-01-08 22:55:28.532 Detail, contrlr, Notification: Notification - TimeOut
2017-01-08 22:55:28.532 Detail,
2017-01-08 22:55:28.533 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x20) - FUNC_ID_ZW_MEMORY_GET_ID: 0x01, 0x03, 0x00, 0x20, 0xdc
2017-01-08 22:55:29.533 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2017-01-08 22:55:29.533 Detail, contrlr, Removing current message
2017-01-08 22:55:29.533 Detail, contrlr, Notification: Notification - TimeOut
2017-01-08 22:55:29.533 Detail,
2017-01-08 22:55:29.534 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x05) - FUNC_ID_ZW_GET_CONTROLLER_CAPABILITIES: 0x01, 0x03, 0x00, 0x05, 0xf9
2017-01-08 22:55:30.534 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2017-01-08 22:55:30.534 Detail, contrlr, Removing current message
2017-01-08 22:55:30.534 Detail, contrlr, Notification: Notification - TimeOut
2017-01-08 22:55:30.536 Detail,
2017-01-08 22:55:30.536 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x07) - FUNC_ID_SERIAL_API_GET_CAPABILITIES: 0x01, 0x03, 0x00, 0x07, 0xfb
2017-01-08 22:55:31.536 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2017-01-08 22:55:31.537 Detail, contrlr, Removing current message
2017-01-08 22:55:31.537 Detail, contrlr, Notification: Notification - TimeOut
2017-01-08 22:55:31.537 Detail,
2017-01-08 22:55:31.537 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x56) - FUNC_ID_ZW_GET_SUC_NODE_ID: 0x01, 0x03, 0x00, 0x56, 0xaa
2017-01-08 22:55:32.537 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2017-01-08 22:55:32.538 Detail, contrlr, Removing current message
2017-01-08 22:55:32.538 Detail, contrlr, Notification: Notification - TimeOut
2017-01-08 22:57:53.995 Error, mgr, Manager::GetDriver failed - Home ID 0x00000000 is unknown
2017-01-08 22:57:53.996 Warning, Exception: Manager.cpp:373 - 100 - Invalid HomeId passed to GetDriver

the HomeId GetDriver issues are a bit concerning. that probably means someone is using the openzwave API incorrectly. but those come after the other device timeouts, so it might be unrelated, or it’s just handling exceptions incorrectly…

i think this switch is Fd. it worked for a few days and then crapped itself when it started raining (it’s an “outdoor” switch). the mystery is that it will act like it’s getting excluded and re-included, so that functionality somehow works? i’m kinda out of options at this point, but i have more zwave devices coming, and this was for my christmas lights, so… until next year :innocent:

anyone have other ideas? i guess i kinda took over this post, sorry.
it appears in my case the switch would bounce back because its status wasn’t being updated, because the device node is timing out.

Sorry guys… I was taking the docs at their word. I thought it was odd and couldn’t explain having to enter the number twice, but I also didn’t have time to dig in at the time. “true” makes so much more sense in that context. Evaluated as a python expression, >0 is true, so 5 == true (kind-of). :slight_smile:

jonathan

I have the same issue with GE wall switch, has you fixed it eventually or had to replace it?

This sounds like the GE Dimmer issues. This config solved those problems for me. I never had to apply this to switches.

  usb_path: /dev/ttyACM0
  config_path: /usr/local/lib/python3.4/dist-packages/libopenzwave-0.3.1-py3.4-linux-armv7l.egg/config
  device_config:
    light.living_room_d_level_2_0:
      polling_intensity: 1
      refresh_value: true

I have this on all my light entities and it solved all my issues with on/off delays.

Hey all. For what its worth. I use the AIO install and I have several GE switches (including dimmers) and I have never had this issue.

From my zwave config

light.ge_unknown_type4944_id3033_level_15_0:
ignored: false
polling_intensity: 1

Currently running HA 0.59.2