search

zwave-js / node-zwave-js

Z-Wave driver written entirely in JavaScript/TypeScript
https://zwave-js.github.io/node-zwave-js/
MIT License
751 stars 603 forks source link

GE/Jasco Model #14318 Zwave Switch will not update Home Assistant UI when operated manually #3273

Closed crudolphy closed 3 years ago

crudolphy commented 3 years ago

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?

YES, BUT a Home Assistant developer has told me to come here

Is your problem within ZWaveJS2MQTT?

NO, my problem is NOT within ZWaveJS2MQTT

Checklist

Describe the bug

The GE 14318 is described as a zwave plus device, and on HomeSeer and Smartthings it reportedly updated instantly with local control. On zwavejs, the device does not update after local control.

What causes the bug?

What do you observe?

What did you expect to happen?

Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '...'
  3. Scroll down to '...'
  4. See error GE/Jasco Model #14318 Zwave Binary Switch does not update the UI when operated manually. When HA operates the switch it updates the UI with it's current state (on/off) but if I operate the switch manually it does not update the UI. I have been working with @blhoward2 in the forum on this and I have attached at "Silly" log of the re-interview of the switch and I also operated the switch manually while capturing, 1 on tap and 1 off tap. Any questions and you can email me at cfrudolphy@gmail.com. zwave_js (1).log

Device information

Manufacturer: Model name: Node ID in your network: GE/Jasco Model #14318 Node ID: 7

How are you using node-zwave-js?

Which branches or versions?

version: Driver Version: 8.1.1 Server Version: 1.10.0

Did you change anything?

no

If yes, what did you change?

No response

Did this work before?

Yes (please describe)

If yes, where did it work?

I have just switched over from a hybrid solution. I was running Homeseer and the mcsMQTT plugin. Then I had Home Assistant running the Mosquitto MQTT add-on. I configured all of my Zwave Devices to subscribe and post to topics in the broker going in both directions. I decided to get rid of Homeseer and MQTT and go with the ZwaveJS add on.

When these switches (1 have 3 of the them and they all exhibit the same behavior in HA) were included and operated in Homeseer with their Zwave implementation they updated instantly upon operation whether manually or by Homeseer. So yes it worked and updated instantly but with Homeseer's Zwave implementation. It works in HA but again when manually operated it doesn't update the UI.

When I was running it through the MQTT broker: Homeseer -> mcsMQTT -> Mosquitto Broker -. Home Assistant it also updated instantly in HA.

Attach Driver Logfile

zwave_js (1).log

blhoward2 commented 3 years ago

I edited the description a bit. For further context, our device file currently does not define any association groups, so I'm curious whether the Lifeline group is getting setup appropriately. If it is, either the device isn't truly zwave plus or we're missing something.

blhoward2 commented 3 years ago

@cfrudolphy So that we have a complete picture, can you also upload a silly log of what (if anything) comes across when you operate the switch locally?

crudolphy commented 3 years ago

See the attached. 1 tap "On" and 1 tap "Off". zwave_js (2).log

AlCalzone commented 3 years ago

According to the interview, the device supports Z-Wave+, has a single association group and the controller is part of that. So the association part should be correct.

In the second log, I see that the device sends two NIFs with a few seconds inbetween. I only see a report after the device is polled for its current status.

Maybe it has no return route to the controller - try healing the node.

crudolphy commented 3 years ago

Attached are two log files. One is when it healed the device. The other is when I locally operated the switch. 1 did 1 tap up, 1 tap down, 1 tap up, 1 tap down. Let me know if you need anything else. zwave_js_local_operation.log zwave_js_heal_device.log

blhoward2 commented 3 years ago

@AlCalzone Doesn't the description for the compat flag "manualValueRefreshDelayMs" suggest we should be refreshing on the NIF? Also, why are you working on holiday?

"Some legacy devices emit an NIF when a local event occurs (e.g. a button press) to signal that the controller should request a status update. However, some of these devices require a delay before they are ready to respond to this request. manualValueRefreshDelayMs specifies that delay, expressed in milliseconds. If unset, there will be no delay."

This looks like https://github.com/zwave-js/node-zwave-js/issues/398, but the fix there seems like it is only applied if the device isn't zwave plus. https://github.com/zwave-js/node-zwave-js/pull/408/files

Should we refresh on all NIFs? Or should we add a compat flag to remove the zw+ CC since it doesn't seem to actually behave like one?

AlCalzone commented 3 years ago

I wonder why the device even has an association group if it doesn't use it to report. Maybe some configuration needs to be set?

If not, I'd argue it isn't really ZW+ (although it answers that it is) and we need to remove the CC to get the auto-refresh behavior.

blhoward2 commented 3 years ago

There are no parameters for this. It's a pretty feature-less switch. I'll push a PR removing the CC later.

nmpu commented 10 months ago

According to the Z-Wave Alliance website, there have been 3 'certifications' for this device. My switches are labeled 14318-3 with date codes 19xx. Firmware is 5.24. My 3 switches update as expected even without:

"compat": {
  "commandClasses": {
    "remove": {
    // Removes the Z-Wave Plus CC as this device fails to send state updates. It sends NIFs, which are only refreshed for non-plus devices
    "Z-Wave Plus Info": { "endpoints": "*" }
    }
  }
}

Did @cfrudolphy specify his hardware revision? The date code is on the front lower right. The actual model number is back left. The firmware version is available in Z-Wave JS UI. I see 3 possibilities:

1) Chuck's switches are different HW/FW revisions 2) Something else has changed in Z-Wave JS 3) Chuck's switches are somehow defective

All 3 revisions show the 'Plus' logo. Is this yet another blatant example of bogus 'certification'?

blhoward2 commented 10 months ago

Please open a new issue if you're experiencing an issue. We expect some devices to work but if we can't tell them apart from the driver we have to treat them all at the lowest common denominator.

If you're testing this, note that you'd have to reinterview after changing the file to pick the change up.

nmpu commented 10 months ago

Sorry to 'bump' a 'settled' issue. I'm just trying to understand how this works. It looks like a single person can report an issue and you make changes without any consensus? Isn't the 'lowest common denominator' a slippery slope? The average user can't evaluate the severity of a Plus device being demoted to non-Plus. What exactly are the implications? Do any of the other compat mechanisms give a visual indication that something is broken when it probably isn't? no

blhoward2 commented 10 months ago

A single person can report an issue and we will investigate the issue, including reviewing log files. If we agree that it is a actual technical issue that is best addressed in the driver versus them working with the manufacturer to fix it, we will then work around the issue, yes. We aim to support the largest number of devices/people out of the box. The maintainer makes the call.

You can always run zwavejs-ui and run your own device file (stored in a persistent directory) if you disagree with the compat flag. That's a supported feature.

blhoward2 commented 10 months ago

Also worth noting, I'm not sure that flag does what you think it does. There shouldn't be any real issue to you as a result if it's fixed on your device. If your device calls in an update on its own any polling on set would be cancelled. We don't ever poll continuously whether that flag is set or not.