Closed deiger closed 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...
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.
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.
I couldn't find any 🤷🏻♂️
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.
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
Here is mine: zmnhcd.txt
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.
You might try hard resetting the device. Sometimes SmartThings changes weird things that may be undocumented.
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)
@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.
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?
The issue appears exactly the same in zwave2jsmqtt. That's why I opened the issue here.
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.
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
[ ] New device
[ ] Previously working device (node-zwave-js)
[x] Previously working device (other platform)
Installation information How did you install
node-zwave-js
?zwavejs2mqtt
(latest) docker imagezwavejs2mqtt
(dev) docker imagenode-zwave-js
branch:zwavejs2mqtt
branch:zwavejs2mqtt
Home Assistant add-onTo Reproduce Steps to reproduce the behavior:
Multilevel Switch
value for a Qubino Flush Shutter in the Control Panel.Perform a level change (Down)
orPerform a level change (Up)
.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
andinvert_percent
- see here. I'm not sure if it is better to force the flip or allow the user to inverse them.