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

After several resets, uninstalling the app.
I finally got iT working again.
I excluded and included the devices on location.
Pull out the hubs power, took a long ethernetcable and preformed the exclusion and inclusion (3clicks)
Did this with three devices and looks like they Made a new mesh.

Edit…

They all dropped off the network… :frowning:

Yes, I have replaced the device handler, I tried all of the Qubino handlers and nothing works. No temperature appears to be sensed and selecting to turn on gives me “turningon” for a few minutes then resets to off. I never get anything logged other than the on event that is sent in the first place.

Same here with a Qubino Flush pilot Wire module (ZMNHJD1) :frowning:

1 Like

@erocm1231
All new to Smartthings (have been using Vera for several years).
I am able to include other Qubino devices (Flush 2 relay, Dimmer, Flush shutter), but the Flush 1 relay doesn’t work. I have spend 6 hours including/excluding with the hub within 1 meter from the my 2 Flush 1 relays.
I have been able to include

  • 1 as a Flush 1 relay - doesn’t work to turn on the switch in the app.
  • 1 as a Flush 2 relay - don’t understand why? (when I change device handler to Flush 1 relay, doesn’t help…

Need advice!
As a total newbe on Smartthings, what logs, etc can help?

@Wallace_Walcher did you ever figure this out? I have mine wired as follows:

My prefs are set as follows:

When I try to use this set up Q1/2 outputs seems to be stuck on ‘closed’ - ie, they are making a connection like a push button would but not ‘releasing.’ The 1D is not turning off after 1 second as I have it set.

I think I have a deeper issue. Tagging @erocm1231 on this one too. I cannot get the orange dot to go away on the device.

However, as shown above the IDE is showing the prefs I set. That means the device got them right? It’s further confusing that Input 2 is showing when I am not using that.

If I hit on the device does not seem to do anything. It goes to ‘turning on’ but sticks there.

Any help would be appreciated. Dead in the water on this one.

UPDATE: I turned debug on. It seems there is a problem communicating but the orange dot went away right after debug was turned on. However, then the device went unavailable and once it did that the orange dot came back. So it looked like it fell off the mesh but just a few minutes later it came back online again. I included this one inside the house as I had some issues then I moved it. However, it did not report unavailable until I enabled debug.

I’ll investigate the unavailable then online again problem but it’s odd as this is Z-Wave Plus and not far from the next wired zwave device. But maybe I need to do a repair.

In the meantime, I am just looking for any experience anyone has getting this to work with this handler and a garage/gate opener (or any application that requires a dry contact).

6:46:05 PM: debug Current value of parameter 120 is unknown
6:46:05 PM: debug Current value of parameter 110 is unknown
6:46:05 PM: debug Current value of parameter 100 is unknown
6:46:05 PM: debug Current value of parameter 63 is unknown
6:46:05 PM: debug Current value of parameter 30 is unknown
6:46:05 PM: debug Current value of parameter 12 is unknown
6:46:05 PM: debug Current value of parameter 11 is unknown
6:46:05 PM: debug Current value of parameter 15 is unknown
6:46:05 PM: debug Current value of parameter 10 is unknown
6:46:05 PM: debug Current value of parameter 2 is unknown
6:46:05 PM: debug Current value of parameter 1 is unknown
6:46:05 PM: debug updated()
6:46:05 PM: debug Current value of parameter 120 is unknown
6:46:05 PM: debug Current value of parameter 110 is unknown
6:46:05 PM: debug Current value of parameter 100 is unknown
6:46:05 PM: debug Current value of parameter 63 is unknown
6:46:05 PM: debug Current value of parameter 30 is unknown
6:46:05 PM: debug Current value of parameter 12 is unknown
6:46:05 PM: debug Current value of parameter 11 is unknown
6:46:05 PM: debug Current value of parameter 15 is unknown
6:46:05 PM: debug Current value of parameter 10 is unknown
6:46:05 PM: debug Current value of parameter 2 is unknown
6:46:05 PM: debug Current value of parameter 1 is unknown
6:46:05 PM: debug updated()
6:45:40 PM: debug refresh()
6:45:13 PM: debug on()
6:44:55 PM: debug Current value of parameter 120 is unknown
6:44:55 PM: debug Current value of parameter 110 is unknown
6:44:55 PM: debug Current value of parameter 100 is unknown
6:44:55 PM: debug Current value of parameter 63 is unknown
6:44:55 PM: debug Current value of parameter 30 is unknown
6:44:55 PM: debug Current value of parameter 12 is unknown
6:44:55 PM: debug Current value of parameter 11 is unknown
6:44:55 PM: debug Current value of parameter 15 is unknown
6:44:55 PM: debug Current value of parameter 10 is unknown
6:44:55 PM: debug Current value of parameter 2 is unknown
6:44:55 PM: debug Current value of parameter 1 is unknown
6:44:55 PM: debug configure()
6:44:30 PM: debug Current value of parameter 120 is unknown
6:44:30 PM: debug Current value of parameter 110 is unknown
6:44:30 PM: debug Current value of parameter 100 is unknown
6:44:30 PM: debug Current value of parameter 63 is unknown
6:44:30 PM: debug Current value of parameter 30 is unknown
6:44:30 PM: debug Current value of parameter 12 is unknown
6:44:30 PM: debug Current value of parameter 11 is unknown
6:44:30 PM: debug Current value of parameter 15 is unknown
6:44:30 PM: debug Current value of parameter 10 is unknown
6:44:30 PM: debug Current value of parameter 2 is unknown
6:44:30 PM: debug Current value of parameter 1 is unknown
6:44:30 PM: debug updated()
6:44:30 PM: debug Current value of parameter 120 is unknown
6:44:30 PM: debug Current value of parameter 110 is unknown
6:44:30 PM: debug Current value of parameter 100 is unknown
6:44:30 PM: debug Current value of parameter 63 is unknown
6:44:30 PM: debug Current value of parameter 30 is unknown
6:44:30 PM: debug Current value of parameter 12 is unknown
6:44:30 PM: debug Current value of parameter 11 is unknown
6:44:30 PM: debug Current value of parameter 15 is unknown
6:44:30 PM: debug Current value of parameter 10 is unknown
6:44:30 PM: debug Current value of parameter 2 is unknown
6:44:30 PM: debug Current value of parameter 1 is unknown
6:44:30 PM: debug updated()_**emphasized text**_

I never did get it to work. I then purchased a new garage door and garage
door opener that had it all built in so it is not an issue for me anymore.

Okay, thanks for the reply.

The more I think about it, I can’t even see how the handler operates the Q1/2 relay. The options to set the switch type (mono vs bi-stable are listed for I1 and I2). While I can see the auto on/off parameters are for the Q terminals, I can’t see what would actually trigger the Q terminals to actuate. Maybe just the ‘ALL ON/OFF’?

My issue may just be that my unit is out of range since I moved it. If I ever figure it out I’ll post back. Obviously I’m riding the struggle bus on this one.

Printscreen of settings included.

I did some more troubleshooting on my issue. I brought the relay back in closer to the hub but near to the device it would likely communicate through when installed permanently, did another exclude (ST reported it had excluded an unknown device which was kind of interesting). I did a fresh include and everything configured just fine. While still in the house I tested the set-up and the Q output terminals responded as expected. After all that I took the device back outside and hooked it back up. I still wondered if it would go out of range but so far with half a dozen tests all seems to be okay. So, it looks like the original include may have been flaky.

Now I have it working (fingers crossed), I may play with the handler as having it display ‘tunringon/off’ for what amounts to a momentary set-up is confusing.

Found the solution.
Perhaps someone have use for it.
My switches have previously been connected to a Vera controller.
Did not get them properly in ST. After many tries, they finally came in but did not work no matter how I did. What I did was run a “replace”. Suddenly, it jumped one go. Did exactly the same thing on the second switch and also it started to work. The switches I had trouble with was Qubino Flush Relay 1.

Flush 1 Relay I2 woes
I’ve installed a Flush 1 Relay to switch some outside porch lights and connected a pir sensor to I2. The main relay is switching just fine but the I2 device isn’t working. I see the sensor triggering in the ST logs but the child device status never updates.
I’ve looked through this thread and it seems as if it might be the multichannel association issue? But TBH I’m a bit lost amongst all the different posts. Has anyone got the child devices working with the Flush 1 Relay? If so, please could you post exactly what you did to get them working?

You are lucky. I’ve given up on the Flush Relay - simply can’t get it to pair to the hub. I’ve tried on different days; different methods, you name it, I’ve tried it.

I didn’t think the Flush 1 Relay has sensor capability like you’re describing. I2/3 are for momentary switches. I may not fully understand what you’re trying to do of course.

The pir sensor works like a switch, it takes a permanent live and neutral and returns a switched live. So the permanent live is wired to the live input on the qubino and the switched live goes to the I2 input. In the logs I can see the pir sensor switch behaviour on/off, but that isn’t being reflected in the child device status (using the Motion Detector child device).

Got you. I was also doing some more reading and now see what you are doing. My mistake, sorry.

As for the lack of status update - I don’t have a solid answer other than to say that I do see slow updates of status on these devices sometimes. A refresh on the device in the app usually updates it but of course that’s a pain.

No worries, thanks for responding :slight_smile: I don’t think it’s just delayed status updates, I’ve tried setting up a webcore rule triggered from the child device status and… nothing.

It’d be good just to know that someone has got the child devices working with the Flush 1 Relay so i know it’s possible.

For now, I’ve hit it with a big kludge stick and it’s working. I’ve changed the SensorBinaryReport zwave handler function in the parent device handler from:

def zwaveEvent(physicalgraph.zwave.commands.sensorbinaryv2.SensorBinaryReport cmd) { 
   logging("SensorBinaryReport: $cmd", 2)
}

to:

def zwaveEvent(physicalgraph.zwave.commands.sensorbinaryv2.SensorBinaryReport cmd) { 
   logging("SensorBinaryReport: $cmd", 2)
   def childDevice = childDevices.find{it.deviceNetworkId.endsWith("-i2")}
   if (cmd.sensorValue == 0) {
       childDevice.sendEvent(name: "motion", value: "inactive")
   } else {
       childDevice.sendEvent(name: "motion", value: "active")
   }

}

But this is a pretty ugly hack, I’d much rather find out how to get it to work properly. Anybody got any suggestions? :slight_smile:

@erocm1231 If you have any advice it would be gratefully received.

@erocm1231 Eric, reset of the kWh on the Flush 2 is not working for me. I have tried from the master and child devices and it just seems to do nothing.

Any suggestions?

@xap It has been a while since I have played around with these devices. The only thing I can think of off the top of my head is that the associations aren’t set correctly. You can try tapping on the configure button and watch the logs to see if it sets the associations. Have you by chance used a different handler? It may have changed the associations in a way that would cause problems.

@Nezmo, I feel like it took a while (oddly) for the numbers to reset after sending the command. Did you notice if it finally updated?

So far I have not seen any reset to zero Eric. Very strange.