GE wall switch on/off vs toggle

@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