Anyone using ST with Qubino Flush Shutter DC interface?


(David Webster) #1

New user here: I have had mixed results with using a Qubino Flush Shutter DC (Z-Wave Plus type) and my UK Hub v2.

Initially ST added the device and it was seen as a Metering Dimmer. On, Off and even Position setting commands (after it self calibrated) seemed to work OK. However after a few On, Off cycles and attempts to includes these commands into Routines the ST app appears to have lost all control functions.

Excluding & re-Including the Qubino module sometimes brings back functionality but it does not last.

ST support in the UK do not have a solution, instead they simply state that it is not an officially supported device, so try the Community.

It does seem odd that there appears to be no ST device type for blinds/shutters/window-treatments?

I am at a loss now on how to get ST to control my blinds. Anyone had better experiences of using this Qubino interface or another product for blinds with a DC motor?


(sidjohn1) #2

I don’t know why this is odd, very few home automation systems have official support for this.

This part is one of the strengths of SmartThings… you can code the support for this device yourself and it sounds like you already have a valid template to work from the “Z-Wave Metering Dimmer”. I’d also recommend checking out he “Z-Wave Switch Secure” device as it has some add-ons for zwave plus.

Another thing to look into is range/interference. It also sounds like this might be an issue. I’d try leaving your Qubino Flush Shutter DC with in 10ft of the hub and test it. If it works consistently with in 10ft of your hub, your issue is range/interference. Adding plugin/wirein zwave devices between your hub and blinds can help with this .


(David Webster) #3

Thanks very much for the tips about range and interference. I shall look into this but I had assumed that since the Qubino was communicating well enough to Include or Exclude it probably was in range for device control too.

I agree that creating the device type for myself is probably the way forward. But being completely new to the ST platform at the moment I don’t have the first idea on how to even begin that yet.

As there are so many Z-Wave interfaces available (and for other protocols like X10 and Insteon too) that are dedicated to shutter and blinds control, I presume there must be many homes that, like mine, would employ them as part of an automation project.

Certainly more professional platforms like Savant, Crestron, Control4 and Lutron make blinds control an integral part of what they offer, and lighting scenes (natural and electric), simulated occupancy and energy saving are important features that perhaps ST should also embrace?


(David Webster) #4

Here is the Qubino Shutter DC product page


(Rafi Tahmazian) #5

Hi David,
Can you help me understand how did you manage to connect the device to ST? did you write any device type for it as it is not supported as out of the box device.
I am interested in the same and ordered mine to be tested.


(David Webster) #6

Hi,

I bought the Qubino Shutter DC interface since it is the only z–wave device I have found that can control a 12V blind motor by switching polarity. There are many other shutter interfaces but they all seem to use 3-wire 240VAC coonections.

The Qubino was connected to a 12VDC PSU and to the blind motor then setup by using the ST App Connect New Device process. It was identified as a Z-Wave Metering Dimmer. The interface does measure load power consumption and is therefore able to self calibrate the time needed to go full open or full closed.

As I mentioned initially I was pleased as the On and Off commands opened and closed the blind and even the “dimmer” set level control made a good attempt at positioning the blind in intermediate positions.

I thought all was good but as I started to incorporate the blind “on” and “off” into Routines it became very intermittent and finally lost all controls.

I did not write my own Device Handler as I noticed that the one used by ST was written by Samsung and so I assumed it had been fully tested.

I have since contacted Support and been told that it has its origins in the Community and is not officially supported as working. Perhaps this is the root cause of my unreliable control?

In an attempt to improve matters I have used the IDE to modify the Device Handler by editing the labels used to read Open & Close instead of On and Off but really this makes no difference especially since there is no ST category other than Garage Doors that make use of Open & Close commands.

My hunch is that the Device Handler is not processing feedback from the Qubino correctly and so it eventually locks up. Sadly I don’t understand the code well enough to make further progress yet.

The Qubino interfaces are very compact and there are many types to choose from so it would be great if there were official Device Handlers for perfect ST integration… However ST also need to add window blinds/shutters functions.

While I appreciate the appeal of being an open platform, in the UK at least, the ST system is sold as a consumer electronics device and I really think full blinds/shutters integration is a serious omission.

I would be very interested to learn how you get on with your Qubino as you may get different results to me.


(Derek Drea) #7

Hi David,

What brand roller motors did you use?

Hi,

I bought the Qubino Shutter DC interface since it is the only z–wave device I have found that can control a 12V blind motor by switching polarity. There are many other shutter interfaces but they all seem to use 3-wire 240VAC coonections.

The Qubino was connected to a 12VDC PSU and to the blind motor then setup by using the ST App Connect New Device process. It was identified as a Z-Wave Metering Dimmer. The interface does measure load power consumption and is therefore able to self calibrate the time needed to go full open or full closed.

As I mentioned initially I was pleased as the On and Off commands opened and closed the blind and even the “dimmer” set level control made a good attempt at positioning the blind in intermediate positions.

I thought all was good but as I started to incorporate the blind “on” and “off” into Routines it became very intermittent and finally lost all controls.

I did not write my own Device Handler as I noticed that the one used by ST was written by Samsung and so I assumed it had been fully tested.

I have since contacted Support and been told that it has its origins in the Community and is not officially supported as working. Perhaps this is the root cause of my unreliable control?

In an attempt to improve matters I have used the IDE to modify the Device Handler by editing the labels used to read Open & Close instead of On and Off but really this makes no difference especially since there is no ST category other than Garage Doors that make use of Open & Close commands.

My hunch is that the Device Handler is not processing feedback from the Qubino correctly and so it eventually locks up. Sadly I don’t understand the code well enough to make further progress yet.

The Qubino interfaces are very compact and there are many types to choose from so it would be great if there were official Device Handlers for perfect ST integration… However ST also need to add window blinds/shutters functions.

While I appreciate the appeal of being an open platform, in the UK at least, the ST system is sold as a consumer electronics device and I really think full blinds/shutters integration is a serious omission.

I would be very interested to learn how you get on with your Qubino as you may get different results to me.
[/quote]

Hi,

I bought the Qubino Shutter DC interface since it is the only z–wave device I have found that can control a 12V blind motor by switching polarity. There are many other shutter interfaces but they all seem to use 3-wire 240VAC coonections.

The Qubino was connected to a 12VDC PSU and to the blind motor then setup by using the ST App Connect New Device process. It was identified as a Z-Wave Metering Dimmer. The interface does measure load power consumption and is therefore able to self calibrate the time needed to go full open or full closed.

As I mentioned initially I was pleased as the On and Off commands opened and closed the blind and even the “dimmer” set level control made a good attempt at positioning the blind in intermediate positions.

I thought all was good but as I started to incorporate the blind “on” and “off” into Routines it became very intermittent and finally lost all controls.

I did not write my own Device Handler as I noticed that the one used by ST was written by Samsung and so I assumed it had been fully tested.

I have since contacted Support and been told that it has its origins in the Community and is not officially supported as working. Perhaps this is the root cause of my unreliable control?

In an attempt to improve matters I have used the IDE to modify the Device Handler by editing the labels used to read Open & Close instead of On and Off but really this makes no difference especially since there is no ST category other than Garage Doors that make use of Open & Close commands.

My hunch is that the Device Handler is not processing feedback from the Qubino correctly and so it eventually locks up. Sadly I don’t understand the code well enough to make further progress yet.

The Qubino interfaces are very compact and there are many types to choose from so it would be great if there were official Device Handlers for perfect ST integration… However ST also need to add window blinds/shutters functions.

While I appreciate the appeal of being an open platform, in the UK at least, the ST system is sold as a consumer electronics device and I really think full blinds/shutters integration is a serious omission.

I would be very interested to learn how you get on with your Qubino as you may get different results to me.
[/quote]


(David Webster) #8

Hi Derek,

I’m using some 12V roller blind motors I found on eBay and used them with fabric from some Ikea roller blinds.
The blinds work well as they have adjustable limit switches for fully open and fully closed positions.
The Qubino interface operates the motor perfectly and has learnt the transit time, so intermediate positions are possible.
Initially I was very pleased but as you will have read the ST does not reliably operate the interface even though it appears to have correctly assigned the Z-Wave Metering Dimmer driver. After a few operations the ST just loses control and although I have played around with delay values in the code I cannot improve matters.


(Derek Drea) #9

Thank you for your reply David.

I’m looking at something similar on Ebay.

But the wiring seems to be 12v with two wires a positive and negative.

How did you wire for up and down?

Maybe I’m over thinking it.

Thanks Derek


(David Webster) #10

Hi Derek,

Two wires are all that is needed. Apply 12v DC power in one direction for Up and simply reverse the DC power connections for Down.

The Qubino Shutter DC interface is designed specifically for this kind of motor control. Apply the 12V DC power supply to the interface (it will power the interface and the motor this way) and connect the blind motor to the two output terminals. Easy!

All other shutter/blind control interfaces I have found are intended for AC mains motors, and these do have 3 wires; Common, Up and Down and so cannot be used directly with 12V DC motors.

Although it should be possible to use two external relays with such AC interfaces to adapt them to DC motor control the resulting work needed, cost, complexity and size makes this solution unattractive when compared to the very compact Qubino Shutter DC product.

I recently experimented with a similar shutter control micro-interface from Insteon that had two switched live AC outputs (Up and Down)and eventually designed a compact solid state alternative to physical relays using opto-isolators to control a SilentGliss AutoGlide curtain track that also uses a DC motor.

I had considered using the same idea with a Z-Wave Blinds AC control interface and looked for a ST supported product to no avail, before settling on the Qubino Shutter DC.

Curiously, in the last week or so, my ST Morning and Dusk routines do seem to be opening and closing my blinds correctly on my set schedules. If this is now reliable behaviour (was this a result of recent firmware updates I wonder? We shall see), then I might forgive the present Z-Wave Metering Dimmer device driver a little for not working 100% when operated manually repeatedly from the App.

My last resort for blinds control is to use a ST plug-in AC Power Control module (this is almost certain to have reliable control) and design an interface that takes its switched AC output and converts it to bi-directional 12V motor control. However since this would preclude the possibility of ever being able to stop the blinds in intermediate positions, it is not my preferred solution.


(Derek Drea) #11

Thank you David, I have the motors and Qubino on order, I will let you know how I get on,

KR

Derek


(Derek Drea) #12

Hi David,

My Roller Blinds and Qubino has arrived,

Can you confirm the wiring if possible, on the Qubino DC Shutter,

Do I put the Wires from the roller blind into Q1/Q2 and the 12v power plug to +/-,

Thanks for your help,

Derek


(David Webster) #13

Hi Derek,

Yes my wiring is exactly as you described.
The Qubino controls the motor very well but I’m still not having reliable operation from ST, so I hope yours does better!

David


(Derek Drea) #14

Thanks David


(Derek Drea) #15

Hi David,

I’m not having much luck getting the Qubino up and running.

Just wondering did you have set parameters to calibrate on set up,

I have been in contact with Qubino they said the following…

“You need to calibrate the module first. Set parameter 78 to 1 and press save. Calibration will start automatically. After calibration is done, set parameter beck to 0.”

But I don’t see anywhere to edit in the ST App or IDE.

Thanks Derek


(David Webster) #16

Hi Derek,

The Qubino self calibrates.

After power up just use the I1 and I2 inputs to trigger a few Ups and Downs. I used a piece of wire to make momentary connections from the + terminal.

It measure the motor current when it is motion so can figure out how long it takes to go fully up or fully down. There are instructions for this in the box. It is all I did, and once calibrated the ST app will permit the blind to go directly to intermediate positions.

Since the ST app is unreliable, I have Reset the Qubino and removed it from ST numerous times and allowed it to self calibrate again & again. It seems to recover for a while but it is the ST system that is the problem. I can’t recall the Qubino Reset process now but it is in the instruction sheet in the box.

The ST always discovers the Qubino and assigns it the Z-Wave Metering Dimmer device type, which would seem to be the correct one for it. I also have a POPP plug-in dimmer module that ST also identifies as a Z-Wave Metering Dimmer and I find that it has the same unreliable operation as the Qubino. Hence my conclusion it is the ST device driver not the device itself that is the problem. I note that the Z-Wave Metering Dimmer is a “SmartThings Labs” created driver which is not officially supported, so getting it fixed by ST seems unlikely :frowning:
I also note that the Qubino and the POPP are Z-Wave Plus devices and perhaps this is the reason the current ST driver has some issues?

The Z-Wave parameters that Qubino list do look very useful but I have yet to find any way of accessing them. I suspect it would require a different software tool from ST and I have yet to find one!

David


(David Webster) #17

After discussions with Qubino staff, I have now made my Qubino ShutterDC interface work reliable by changing its Parameter 85 to be value=3

e.g.

zwave.configurationV1.configurationSet(configurationValue: [3], parameterNumber: 85, size: 1).format(), // default = 8 (800ms), range 3 – 50 = 0.3 seconds – 5 seconds (100 ms resolution)

I have made a clumsy edit to the default template for a Z-Wave metering dimmer switch to achieve this, so the next step is to create a simpler device handler that supports the windowShade capabilities and to make position feedback more reliable.


(Aaron Preston) #18

Hi David,

Can you past up your modified device type so I can see how you sent the parameters to the device?

Aaron


(David Webster) #19

Hi Aaron,

The way I have set the parameter is very clunky as it involves manually pressing once a new button that I have named INIT.

I’m sure there is a better way of doing this as a one-time automatic start-up procedure but not figured out how to yet. I also think that the position slider and feedback could be made smoother.

I’m also sorry, but I’m not sure how to post the code so for now forgive me if I just list it here instead.

David

/**

  • Copyright 2015 SmartThings
  • Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except
  • in compliance with the License. You may obtain a copy of the License at:
  •  http://www.apache.org/licenses/LICENSE-2.0
    
  • Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
  • on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
  • for the specific language governing permissions and limitations under the License.
  • Z-Wave Metering Dimmer
  • Copyright 2014 SmartThings
  • Modified for Qubino Shutter DC by David Webster 2016

*/
metadata {
definition (name: “Z-Wave Blinds - Base”, namespace: “smartthings”, author: “David Webster”) {
capability "Switch"
capability "Polling"
capability "Power Meter"
capability "Energy Meter"
capability "Refresh"
capability "Switch Level"
capability "Sensor"
capability “Actuator”

	command "reset"

	fingerprint inClusters: "0x26,0x32"
}

simulator {
	status "on":  "command: 2603, payload: FF"
	status "off": "command: 2603, payload: 00"
	status "09%": "command: 2603, payload: 09"
	status "10%": "command: 2603, payload: 0A"
	status "33%": "command: 2603, payload: 21"
	status "66%": "command: 2603, payload: 42"
	status "99%": "command: 2603, payload: 63"

	for (int i = 0; i <= 10000; i += 1000) {
		status "power  ${i} W": new physicalgraph.zwave.Zwave().meterV1.meterReport(
			scaledMeterValue: i, precision: 3, meterType: 4, scale: 2, size: 4).incomingMessage()
	}
	for (int i = 0; i <= 100; i += 10) {
		status "energy  ${i} kWh": new physicalgraph.zwave.Zwave().meterV1.meterReport(
			scaledMeterValue: i, precision: 3, meterType: 0, scale: 0, size: 4).incomingMessage()
	}

	["FF", "00", "09", "0A", "21", "42", "63"].each { val ->
		reply "2001$val,delay 100,2602": "command: 2603, payload: $val"
	}
}

tiles {
	standardTile("switch", "device.switch", width: 2, height: 2, canChangeIcon: true) {
		state "on", label:'${name}', action:"switch.off", icon:"st.switches.switch.on", backgroundColor:"#79b821", nextState:"turningOff"
		state "off", label:'${name}', action:"switch.on", icon:"st.switches.switch.off", backgroundColor:"#ffffff", nextState:"turningOn"
		state "turningOn", label:'${name}', icon:"st.switches.switch.on", backgroundColor:"#79b821"
		state "turningOff", label:'${name}', icon:"st.switches.switch.off", backgroundColor:"#ffffff"
	}
	valueTile("power", "device.power") {
		state "default", label:'${currentValue} W'
	}
	valueTile("energy", "device.energy") {
		state "default", label:'${currentValue} kWh'
	}
	standardTile("reset", "device.energy", inactiveLabel: false, decoration: "flat") {
		state "default", label:'reset kWh', action:"reset"
	}
	controlTile("levelSliderControl", "device.level", "slider", height: 1, width: 3, inactiveLabel: false) {
		state "level", action:"switch level.setLevel"
	}
	standardTile("refresh", "device.switch", inactiveLabel: false, decoration: "flat") {
		state "default", label:"", action:"refresh.refresh", icon:"st.secondary.refresh"
	}
    standardTile("Init", "device.switch", inactiveLabel: false, decoration: "flat") {
	state "default", label:"Init", action:"paramInit"
	}
}

main(["switch","power","energy"])
details(["switch", "power", "energy", "levelSliderControl", "refresh", "reset", "Init"])

}

// parse events into attributes
def parse(String description) {
def result = null
if (description != “updated”) {
def cmd = zwave.parse(description, [0x20: 1, 0x26: 3, 0x70: 1, 0x32:3])
if (cmd) {
result = zwaveEvent(cmd)
log.debug("’$description’ parsed to $result")
} else {
log.debug(“Couldn’t zwave.parse ‘$description’”)
}
}
result
}

def updated() {
response(refresh())
}

def zwaveEvent(physicalgraph.zwave.commands.basicv1.BasicReport cmd) {
dimmerEvents(cmd)
}

def zwaveEvent(physicalgraph.zwave.commands.basicv1.BasicSet cmd) {
dimmerEvents(cmd)
}

def zwaveEvent(physicalgraph.zwave.commands.switchmultilevelv3.SwitchMultilevelReport cmd) {
dimmerEvents(cmd)
}

def dimmerEvents(physicalgraph.zwave.Command cmd) {
def result = []
def value = (cmd.value ? “on” : “off”)
def switchEvent = createEvent(name: “switch”, value: value, descriptionText: “$device.displayName was turned $value”)
result << switchEvent
if (cmd.value) {
result << createEvent(name: “level”, value: cmd.value, unit: “%”)
}
if (switchEvent.isStateChange) {
result << response([“delay 3000”, zwave.meterV2.meterGet(scale: 2).format()])
} //Orignal value 3000
return result
}

def zwaveEvent(physicalgraph.zwave.commands.meterv3.MeterReport cmd) {
if (cmd.meterType == 1) {
if (cmd.scale == 0) {
return createEvent(name: “energy”, value: cmd.scaledMeterValue, unit: “kWh”)
} else if (cmd.scale == 1) {
return createEvent(name: “energy”, value: cmd.scaledMeterValue, unit: “kVAh”)
} else if (cmd.scale == 2) {
return createEvent(name: “power”, value: Math.round(cmd.scaledMeterValue), unit: “W”)
} else {
return createEvent(name: “electric”, value: cmd.scaledMeterValue, unit: [“pulses”, “V”, “A”, “R/Z”, “”][cmd.scale - 3])
}
}
}

def on() {
delayBetween([
zwave.basicV1.basicSet(value: 0xFF).format(),
zwave.switchMultilevelV1.switchMultilevelGet().format(),
], 5000) //Orignal value 5000
}

def off() {
delayBetween([
zwave.basicV1.basicSet(value: 0x00).format(),
zwave.switchMultilevelV1.switchMultilevelGet().format(),
], 5000) //Orignal value 5000
}

def poll() {
delayBetween([
zwave.meterV2.meterGet(scale: 0).format(),
zwave.meterV2.meterGet(scale: 2).format(),
], 1000) //Orignal value 1000
}

def refresh() {
delayBetween([
zwave.switchMultilevelV1.switchMultilevelGet().format(),
zwave.meterV2.meterGet(scale: 0).format(),
zwave.meterV2.meterGet(scale: 2).format(),
], 1000) //Orignal value 1000
}

def setLevel(level) {
if(level > 99) level = 99
delayBetween([
zwave.basicV1.basicSet(value: level).format(),
zwave.switchMultilevelV1.switchMultilevelGet().format()
], 5000) //Orignal value 5000
}

def paramInit() {
log.debug(“Initialising Parameters”)
delayBetween([
zwave.configurationV1.configurationSet(configurationValue: [3], parameterNumber: 85, size: 1).format(), // default = 8 (800ms), range 3 – 50 = 0.3 seconds – 5 seconds (100 ms resolution)
], 500)
}


(Aaron Preston) #20

Thanks for getting back to me David

Having a button that can set the various parameters would be fine for me, I can then try out changing the various settings that the device has, and just press the button to apply them

unfortunately your code didn’t paste in properly, would you mind trying it again?