[RELEASE] Qubino Flush 1D Relay, Flush 2 Relays, Flush 1 Relay, & Flush Dimmer

Have a retractive push switch connected to i2 on one Qubino dimmer which I want to use to toggle another Qubino.

Having to use CoRE as Smart Lighting doesn’t have a toggle function.

CoRE is set to toggle the remote Qubino when i2 state changes to closed.

It’s working, but seems to be very sporadic. I’ve tried changing the CoRE trigger between “changes to closed”, “is closed” and “moves away from open” but still very sporadic. Sometimes it works, sometimes it works after delay.

Problem doesn’t seem to be the Qubino child handler- it’s reporting happily:-
7:01:30 PM: debug NotificationReport: NotificationReport(event: 0, eventParameter: [], eventParametersLength: 0, notificationStatus: 255, notificationType: 5, reserved61: 0, sequence: false, v1AlarmLevel: 0, v1AlarmType: 0, zensorNetSourceNodeId: 0)

7:01:30 PM: debug description: zw device: 65, command: 7105, payload: 00 00 00 FF 05 00 00

7:01:28 PM: debug NotificationReport: NotificationReport(event: 2, eventParameter: [], eventParametersLength: 0, notificationStatus: 255, notificationType: 5, reserved61: 0, sequence: false, v1AlarmLevel: 0, v1AlarmType: 0, zensorNetSourceNodeId: 0)
de299f87-a7a8-47be-a9d1-658ce862464b 7:01:28 PM: debug description: zw device: 65, command: 7105, payload: 00 00 00 FF 05 02 00

I’ve not used CoRE too much as Smart Lighting fulfils 90% of my needs…not sure if there’s “scan” times, etc.

Any suggestions for getting a “push” on i2 on one Qubino to toggle another device- with or without CoRE?

It seems like CoRE should do the trick. So if the child device is reporting the correct state open/close, it probably is something with the SmartApp firing. Not sure it would make much of a difference, but WebCoRE might be worth a try.

Thanks. Re-thought and decide to try z-wave tweaker and association groups- this will deal with 90% of my i2/ i3 needs.

This works fine, is fast and removes the dependency on Smartthings. Works if I put the remote address in as just the node ID, or as the node ID:1 (for endpoint 1)

The only problem with this is that the remote Qubino doesn’t update state in SmartThings- I see the power changing but not on/ off. Tried using association groups 6 and 9 to controller, but of course these just update the local i2/ i3 status

Any thoughts on how I can trigger an update of the remote device state?

Sorry…found it! I had to add SmartThings node ID 01 to association group 04 on the remote switch- this now updates status.

Almost seems like this should exist by default.

If you’re doing updates to the handlers could you consider adding the association groups- would be great to set these from within the normal device handler rather than having to switch to the tweaker!
Also means association groups would be visible and “backed up” in SmartThings…the Tweaker makes a bit more difficult to view and remember what associations you have set!

Just added some flush 1 relay devices for the first time, main devices works fine but i2/ i3 not working on two different devices (still works perfectly on dimmers)

Have tried them as binary/ motion, when set to motion this is logged when i3 pressed:- “2523aeee-54b9-4434-b196-0b8662e36b2c 2:11:32 PM: debug SensorBinaryReport: SensorBinaryReport(sensorType: null, sensorValue: 0)
2523aeee-54b9-4434-b196-0b8662e36b2c 2:11:32 PM: debug description: zw device: 6B, command: 3003, payload: 00
2523aeee-54b9-4434-b196-0b8662e36b2c 2:11:30 PM: debug Qubino Flush 1 A077: Unhandled: BasicSet(value: 0)
2523aeee-54b9-4434-b196-0b8662e36b2c 2:11:30 PM: debug description: zw device: 6B, command: 2001, payload: 00
2523aeee-54b9-4434-b196-0b8662e36b2c 2:11:26 PM: debug SensorBinaryReport: SensorBinaryReport(sensorType: null, sensorValue: 255)
2523aeee-54b9-4434-b196-0b8662e36b2c 2:11:26 PM: debug description: zw device: 6B, command: 3003, payload: FF
2523aeee-54b9-4434-b196-0b8662e36b2c 2:11:24 PM: debug Qubino Flush 1 A077: Unhandled: BasicSet(value: 255)
2523aeee-54b9-4434-b196-0b8662e36b2c 2:11:24 PM: debug description: zw device: 6B, command: 2001, payload: FF”

In the child device, state shown as “no state found”

When dealing with I2/I3 on these i would strongly reccomend using Multichannel Lifeline Association, since that will tell you from which endpoint the report originates (this is needed when both are enabled).

If no Multichannel Lifeline Association is created, and just the Singlechannel one is used (via Association Set group1 to node Id 1) then the device will still report Binary Sensor/Notification Reports, but it isn’t allowed by the protocol to report Multichannel Encapsulated Reports, so the endpoint address is missing.

See here for mor eifno regarding this:

Hi Kjamsek,

been having quite a bit of trouble with any form of association! In part this seems to be due to some old associations I had in some devices- have now been round most devices and removed these which seems to have improved things.

Also found the tweaker isn’t working consistently, ie with some devices I’m getting “null object @ line 1619” as per this:-
https://github.com/codersaur/SmartThings/issues/17

Think I understand your comment. In the tweaker I can configure destination association members as node:endpoint- but how do I configure the source:endpoint without having to revert to code? It sounds like for I3, for instance, I need to address the association trap from 0302 rather than from association group 8- but I don’t have a clue how or where to put this!

I’m not big on coding (understatement!), but I’ve had a go at kludging together the group association code from your Qubino dimmer device handler with Eric’s:-
https://github.com/erocm123/SmartThingsPublic/compare/master...chrisgla:patch-1

I think this is nearly there but needs the command logic added to populate/ send the group associations. Sorry, I still really haven’t got my head round Groovy and formatting of these…

I noted your previous comment as well about Eric’s drive not being picked up- I had this problem previously but just added two new Flush 2 and two new Flush 1 relays and re-added a dimmer. These worked perfectly this time although that was before this week’s hub downgrade.

Last i’ve tried to use both inputs enabled on the Flush Dimmer a couple months ago, i’ve had trouble with SmartThings actually executing my handler after inclusion (and didn’t have the chance to re-test it again after these updates, but plan to do so when possible), but i can show you a snippet of how i implemented Multichannel Lifeline setting on the Flush Shutter handler i’ve made, that uses a configurable endpoint 2 to control slat tilting if desired (the same approach is used on all Qubino devices with configurable Z-Wave structure).

First i use the configure capability to remove and re-set the singlechannel Lifeline (this is just for clarity’s sake to make sure it’s set in the first place) and after that i send a MultiChannel Endpoint Get command, that will return the number of endpoints the device supports in it’s current configuration (Z-Wave requires reinclusion after any changes to the device command class structure is made):

def configure() {
	log.debug "Qubino Flush Shutter: configure()"
	state.isMcDevice = false //Internal state used for determining if it's in MultiChannel configuration or not, initially set to false
	def assocCmds = []
	assocCmds << zwave.associationV1.associationRemove(groupingIdentifier:1).format() //We clear the SingleChannel Lifeline if present
	assocCmds << zwave.associationV1.associationSet(groupingIdentifier:1, nodeId:zwaveHubNodeId).format() //We re-establish SingleChannel lifeline in case the device doesn't support any endpoints in it's configuration
	assocCmds << zwave.multiChannelV3.multiChannelEndPointGet().format() //Fetches number of currently supported endpoints
	return delayBetween(assocCmds, 500)
}

This will cause the device to respond with MultiChannel Endpoint Report if any endpoints are supported, along with the number of endpoints. In case no endpoints are supported the device won’t reply to this so it won’t execute.
I then use a Z-Wave event for that command to trigger MultiChannel Lifeline association setting like this:

/**
 * Event handler for received MultiChannelEndPointReport commands. Used to distinguish when the device is in singlechannel or multichannel configuration. 
 *
 * @param cmd communication frame
 * @return commands to set up a MC Lifeline association.
*/
def zwaveEvent(physicalgraph.zwave.commands.multichannelv3.MultiChannelEndPointReport cmd){
	log.debug "Qubino Flush Shutter: firing MultiChannelEndPointReport"
	if(cmd.endPoints > 0){
		state.isMcDevice = true; //We have a greater than zero number of endpoints supported so we mark the state parameter as true, the device is a MultiChannel device
	}
	def cmds = []
	cmds << response(zwave.associationV1.associationRemove(groupingIdentifier:1).format()) //Here we clear the SingleChannel Lifeline since we will set up a MultiChannel one right away
	cmds << response(zwave.multiChannelAssociationV2.multiChannelAssociationSet(groupingIdentifier: 1, nodeId: [0,zwaveHubNodeId,1]).format()) //Here we set the actual MultiChannel Lifeline association, note the formatting of parameters passed to nodeId field, it must match this form
	return cmds
}

To elaborate a bit on the parameters for the MultiChannel Association Set nodeId property:

nodeId: [0,zwaveHubNodeId,1]

The first parameter here needs to be 0, since it’s the SingleChannel Node id (this is used for setting a SingleChannel Lifeline; in this case the other two parameters need to be omitted. This is equivalent to an Association Set.
The second parameter zwaveHubNodeId contains the Node Id value of the primary controller, to which we wish to send MultiChannel Encapsulated Reports.
The third parameter needs to be the endpoint Id that matches the above (zwaveHubNodeId) controller’s endpoint, with ST this is 1.

Now, after the MultiChannel Lifeline is set up you should receive MultiChannel Encapsulated Reports from the device. These are needed so you can diferrentiate between which endpoint sent the specific report. See here from my Shutter handler, i use endpoint Ids to separate reports for main blinds motion (endpoint 1) from the slat tilting (endpoint 2):

/**
 * Event handler for received MC Encapsulated Switch Multilevel Report frames.
 *
 * @param cmd communication frame, command mc encapsulated communication frame; needed to distinguish sources
 * @return List of events to update the ON / OFF and analogue control elements with received values.
*/
def zwaveEvent(physicalgraph.zwave.commands.switchmultilevelv3.SwitchMultilevelReport cmd, physicalgraph.zwave.commands.multichannelv3.MultiChannelCmdEncap command){
	log.debug "Qubino Flush Shutter: firing MC switch multilevel event"
	def result = []
	switch(command.sourceEndPoint){
		case 1:
			result << createEvent(name:"windowShade", value: cmd.value ? "open" : "closed", isStateChange: true)
			if(cmd.value > 99){
				result << createEvent(name:"level", value: cmd.value, unit:"%", descriptionText:"${device.displayName} is uncalibrated! Please press calibrate!")
			}else{
				result << createEvent(name:"level", value: cmd.value, unit:"%", descriptionText:"${device.displayName} moved to ${cmd.value==99 ? 100 : cmd.value}%", isStateChange: true)
			}
		break;
		case 2:
			log.debug "Received command from EP2"
			log.debug cmd
			result << createEvent(name:"venetianState", value: cmd.value ? "Slats open" : "Slats closed", isStateChange: true)
			if(cmd.value > 99){
				result << createEvent(name:"venetianLevel", value: cmd.value, unit:"%", descriptionText:"${device.displayName} is uncalibrated! Please press calibrate!", isStateChange: true)
			}else{
				result << createEvent(name:"venetianLevel", value: cmd.value, unit:"%", descriptionText:"${device.displayName} tilted slats to ${cmd.value==99 ? 100 : cmd.value}%", isStateChange: true)
			}
		break;
	}
	return result
}

You can also find some other Qubino handlers that could serve as an example on how to implement certain features on my GitHub profile below, though for the Flush Dimmer (and other configurable input supported Qubino devices), i have a plan to rework the input detection via child devices once i have some more time, so i didn’t implement this at the moment:

I am trying to use the Flush 1D relay to control my garage door opener. At this point, I can get it only to close the door, but not open it. Any suggestions as to the reason for this?

Does your problem occur both on physical input activation and via Eric’s handler?

EDIT: Ah i think i know why it’s only closing. The Flush 1D module only has 1 output.
If your garage door opener is similar to motorized blinds then the motor should have 2 input lines, one for UP and one for DOWN motion. If this is true i’m afraid you’r not using the right “tool” for the job.

It only occurs when I use the Qubino device. When I use the opener on the wall, it works both ways. There is only one “input” line to the opener. It basically has two screws that need to be connected to close the loop and cause the garage door opener to trigger.

How did you wire the module to the garage door? Because the Flush 1D Relay can only assume 2 states. Either it outputs the voltage supplied to it via Qa through the Qb output or it doesn’t.
So i assume your garage door opener opens the door once the voltage is present on the output and closes it if the voltage isn’t present on the output, correct?

No, it opens/stops/closes based on voltage being present just for a moment. The button on the wall completes the circuit just for a split second while it is being pressed. I have configured the Qubino to turn on and then off again after 1/2 sec, 1 sec and 2 sec. It doesn’t change the result. It only works in one direction. It is a real head scratcher.

Do you know the voltage and duration required for opening and stopping?

If it works for closing you’r clearly getting the voltage through the output at times, so the device itself should be functional in that regard.

The voltage comes from the opener - I believe it is around 24-30v dc. The duration has to be variable since a pushbutton opener on the wall works.

This is really strange. The Qubino needs to act like someone pressing a momentary switch. Having the device automatically turn off after 1 second you think would do the trick. You say that you have tried that right?

Can you verify that when you activate the Qubino that the relay closes for a second and then opens again?

Yes, I did. I hooked it up to a 110 ac power cord connected to a device and confirmed that when I turned the switch on and off, the device turned on and off.

Just to verify (and since I have no idea what else to try). auto off should be set to something like 1 second and auto on should be disabled (with a value of 0).

In regards to setting configuration parameters on the Flush 1D Relay you can basically have only one “pulse regime” at a time set up on the device directly. For greater precision i’d suggest setting parameter 15 to 1 so the time is counted in miliseconds and then set the parameter 11 to the milisecond value needed (so, for 1 second enter 1000 here).

This will make the device turn output off 1 second after it’s on, regardless whether it’s activated via ST commands or the module’s I1 input.

If you need more than one length of the output activation at once i’m afraid you’ll need to modify the handler to send delayed on->off commands for each activation desired, via delayBetween() function.

Additionally, for debugging purposes, you can set parameter 1 to value 1, this will change the input to work as a push button, and then wire a push button connected to the device’s I1 input (note that L line is used on the input) and time the exact values needed to get it just right.

Can you perhaps share the eexact setup you have currently? How did you make delays in output activation? Perhaps a simple wiring image/drawing?

erocm1231 - I have it set as you described. Kjamsek, I have tried both seconds and milliseconds. I will consider the parameter 1 push button test, although the wall button that does work for the garage door doesn’t seem to have a timing configuration for it - I think it just goes off once you quit pushing it.

I will do some more testing and get back with you guys. Thanks for the input. Also, it appears from my timing that the millisecond parameter actually yields tenths of a second, not thousandths. If I set it to 500, it turns off after 5 seconds, not a half a second.