zwave-js / node-zwave-js

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

Up/Down and currentValue are reversed in Qubino ZMNHCD #1668

Closed deiger closed 3 years ago

deiger commented 3 years ago

Describe the bug I have two Qubino ZMNHCD roller shutters. In both cases, the Multilevel Switch is reversed: x-38-0-Down results in opening the shutter, while x-38-0-Up results in closing it. Likewise, x-38-0-currentValue is 0 for an open shutter and 99 for a closed one. This is not a wiring issue, as both shutters worked correctly in SmartThings.

Device information Qubino ZMNHCD, firmware 1.1 - 0x0159-0x0052-0x0003

Last Known Working Configuration

Installation information How did you install node-zwave-js?

To Reproduce Steps to reproduce the behavior:

  1. Go to Multilevel Switch value for a Qubino Flush Shutter in the Control Panel.
  2. Click on Perform a level change (Down) or Perform a level change (Up).
  3. The shutter will do the reversed action, and the currentValue is inverted as well.

Additional context This seems to have long been an issue with roller shutters. In the OpenZwave integration of HomeAssistant, there are configuration flags invert_openclose_buttons and invert_percent - see here. I'm not sure if it is better to force the flip or allow the user to inverse them.

hmmbob commented 3 years ago

For what it's worth: if I use UP and DOWN commands in Home Assistant for the same device, the cover moves as expected (UP or DOWN). To put it differently: for me it works as expected (as it did in the old zwave and openzwave integrations in Home Assistant by the way).

Maybe Smartthings did some magic somewhere, but I'm not so sure about your statement that it isn't a wiring issue (respectfully).

edit: just tested with zwavejs2mqtt interface: [6-38-0-Up] Perform a level change (Up) makes my cover go UP, [6-38-0-Down] Perform a level change (Down) makes it go DOWN...

AlCalzone commented 3 years ago

You deleted the most important part of the issue template - the logfile.

I have a couple of Fibaro Roller Shutters and they work perfectly and are not inverted (0 = closed, 99 = open). The commands are guaranteed the same for both devices.

The Window Covering CC specs (I know, different one, but they are designed to be compatible) describe:

Level Change Up = Opening, Level Change Down = Closing The term “Closed” represents the lowest light throughput, while “Open” represents the highest light throughput of the window covering.

Since currentValue and up/down are interpreted in the same inverted way by your device, I'll have to disagree with your assessment that it is not a wiring issue. I'm not sure what SmartThings does differently in this regard, but maybe you had an invert option set somewhere.

If you really need an invert option, I suggest you raise an issue in the HomeAssistant repo.

blhoward2 commented 3 years ago

Just speculating but some of those devices have inversion parameters. Have you checked the configuration for the device? If not, you may want to google around and see if the manual shows such a parameter. Yours may be set funny from SmartThings even if our device file doesn't present the option yet.

AlCalzone commented 3 years ago

I couldn't find any 🤷🏻‍♂️

deiger commented 3 years ago

I couldn't find such parameters either. Also, I did not reset the modules on migration from SmartThings, only excluded and included them - so all set parameters remained the same.

hmmbob commented 3 years ago

Debug info of my node (coming from zwavejs2mqtt): Qubino shutter module.txt

I don't see any config option for this in the file. I don't remember it being configurable in the other zwave integration layer in Home Assistant, other than at the Home Assistant UI layer itself (with the invert settings discussed previously) nor in the VNC like solution that I used to connect to the openzwave daemon before switching to zwaveJS

deiger commented 3 years ago

Here is mine: zmnhcd.txt

hmmbob commented 3 years ago

I compared yours and mine, and did not see significant differences. If AlCalzone doesn't see an issue in our dumps, I'm afraid you'll be needing to get your screwdrivers out and switch the wires ;-)

You'll need to switch Q1 and Q2 either at the module or at the motor side. image

blhoward2 commented 3 years ago

You might try hard resetting the device. Sometimes SmartThings changes weird things that may be undocumented.

kpine commented 3 years ago

If you're talking about SmartThings, I believe you are able to choose a specific Device Handler (or is it autodetected), is that right?

There is a custom Qubino Flush Shutter DH. The open/close functions are peculiar.

def close() {
    setShadeLevel(0x64)
}

def open() {
    setShadeLevel(0x00)
}

def setShadeLevel(level) {
    log.debug "Setting shade level: ${level}"
    encap(zwave.switchMultilevelV3.switchMultilevelSet(value: Math.min(0x63, level)))
}

It looks to me it has inverted the open and close values. Open == 0x0, Close == 0x63. So if you're using the DH, then that might explain why open/close behave opposite of past experience.

There is also a generic "Z-Wave Basic Window Shade" DH with a configurable reverse option. It looks to me the default behavior for that DH is still Open == 0x0, Close == 0xFF.

If I understand SmartThings and these DH correctly, then it seems SmartThings has reversed the meanings of the values as defined by the spec, as Al has mentioned?

(These are the public SmartThings device handlers, not sure if they are available/used by default on a SmartThings hub)

deiger commented 3 years ago

@kpine Nice idea. However I've been using the official DH by Qubino, Which seems to do what it should:

def open() {
    log.debug "Qubino Flush Shutter: open()"
    return zwave.switchMultilevelV3.switchMultilevelSet(value: 0xFF, dimmingDuration: 0x00).format()
}

def close() {
    log.debug "Qubino Flush Shutter: close()"
    return zwave.switchMultilevelV3.switchMultilevelSet(value: 0x00, dimmingDuration: 0x00).format()
}

def setSlatLevel(level) {
    log.debug "Qubino Flush Shutter: setSlatLevel()"
    log.debug level
    if(level > 99) level = 99
    //zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:2).encapsulate(zwave.switchMultilevelV3.switchMultilevelSet(value: level, dimmingDuration: 0x00)).format()
    if(settings.param72 == null){
        return delayBetween([
            zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:2).encapsulate(zwave.switchMultilevelV3.switchMultilevelSet(value: level, dimmingDuration: 0x00)).format(),
            zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:2).encapsulate(zwave.switchMultilevelV3.switchMultilevelGet()).format()
        ], 1500)
    }else{
        def tempTurningTime = settings.param72.toInteger()*10
        return delayBetween([
            zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:2).encapsulate(zwave.switchMultilevelV3.switchMultilevelSet(value: level, dimmingDuration: 0x00)).format(),
            zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:2).encapsulate(zwave.switchMultilevelV3.switchMultilevelGet()).format()
        ], tempTurningTime)
    }
}

I do see though that the DH by SmartThings is messed up:

def close() {
    setShadeLevel(0x64)
}

def open() {
    setShadeLevel(0x00)
}

I guess my best option is to change the wiring. I do think though that an option for inverting the values is a good one to have.

blhoward2 commented 3 years ago

It looks like this may be an HA issue? I saw this on the Community website:

"When I upgrade to 2021.2.3 , my FGRM222 shutter switches are inverted in the UI ?!..(i use open-zwave)"

Have you tried triggering it from with zwave2jsmqtt to see if it works correctly?

deiger commented 3 years ago

The issue appears exactly the same in zwave2jsmqtt. That's why I opened the issue here.

zwave-js-assistant[bot] commented 3 years ago

This issue has not seen any recent activity and was marked as "working as intended ✔". Closing for housekeeping purposes... 🧹

Feel free to reopen if the issue persists.