Qubino Flush 1D relay ZMNHNDx - no off update

I figured you were a swede, I'm in Täby so rather close.

I kind of need the measurements for chart purposes, an engine heater is connected to that outlet.
And I couldn't find that particular tick box, only for temp, which is consistent with other modules?

As a last resort I'll set up a trigger or something to turn the outlet off when not needed.
It's when nothing is connected that it generates most entries.

Skickat från min ONE A2003 via Tapatalk

Ok if you need the measurements for the power usage of the engine heater connected to that outlet then you could for example set param 40 to some higher value like 200W or more so that the autoreports when power load changes is only triggered when your engine heater starts.

You could then set param 42 to for example 0 in order to disable the autoreports for time intervals.

I´ll check the tick box later tonight when back at home.

Tanx, I'll check the manual, think I just threw it away without reading up on them.

Skickat från min ONE A2003 via Tapatalk

Manual can be found everywhere on the web. Here is one link.

Sorry! I just realized that the param 40 and 42 doesn't seem to be mentioned in the manual for ZMNHNDx devices?! I read the manual for the normal Flush 1 device (ZMNHADx).
I need to check at home what settings I have. I suspect you can still set param 40 and 42 even though the manual does not mention it but I´ll report back later tonight.

WAIIIT! The Qubino Flush 1D relay has dry contact (i.e. output is separated from the inputs completely so you can control other voltages with the output than the voltage you feed the device with). This means that the Flush 1D relay can not measure energy. You can use the normal Flush 1 relay (ZMNHADx) instead but if I understand you correctly it is the one you are using now right? If so then you can use the param 40 and 42 and read the manual at this link.

I have a flush relay installed and its possible to set param 40, just have to find a suitable level.
Tanx for the tip.


Skickat från min iPad med Tapatalk

For the ZMNHADx and ZMNHNDx there is a tick box under the "Temperature" endpoint where you tick "Hide status and energy message broadcasts in the event log". Then (if it works properly, haven't tried it) you will not see energy messages for the ZMNHADx in the log BUT values will still be saved into the SQL database.

[matt (support)]

So the tiny remaining issue seems to be the fact that when I turn the device ON/OFF via GUI the GUI updates properly but the non-debug log never shows that we have received the ON/OFF state change. So if the GUI would not update based on me pressing ON or OFF in the GUI the GUI would in this case not show the state change.

This actually isn't a problem. The setRelayValue command is ACK'd, which means the module received the command so Indigo updates (and logs) the state change at that point. The other commands broadcast from the module are then ignored because they don't result in a state change. If the module wasn't reachable then the command would NAK and Indigo would not update the state. Basically, Indigo logs and updates the state when it has the first proof the state has changed, which for setRelayValue is when the message is originally ACK'd.

[matt (support)]

By the way have you seen this official statement from Qubino about their change of how output state changes wll be handled for their series 500 devices (like the one we discuss in this thread)?
...
Will this affect Indigo in some way?

That should be okay. Indigo will handle the case correctly since it updates the state both on the ACK and if there is a broadcast from the module. In the latter case it will mostly be ignored by Indigo since the state has already been updated by the former (but is needed for the i2 update case since that is a change originating from the module).

[matt (support)]

Try this beta of Indigo's Z-Wave plugin.

If you don't mind running through your full test suite:

1. the full inclusion debug log after I did a factory reset and a new include to the controller.
2. the full sync debug log into Indigo
3. the full inclusion debug log after a soft reset
4. the full re-sync debug log after the soft reset

That would be appreciated.

I know that is a pain, so if you just want to do a lightweight re-sync that is fine as well. I'm hopeful this gets rid of the "does not support status request command" error message. Try sending both the main device and the I2 device a status request from Indigo as well.

Thanks!

Ok I have now tested the Z-Wave plugin 2.0.56 and it works no good at all compared to prev version.

I can include the device into the controller but when I try to sync the ZMNHNDx into Indigo it times out on the "RequestMultiEndPointInfo" line.
Device is excluded first with factory reset (i.e. pressing the S button more than 6 seconds when excluding it) and then re-included into the controller.

Here is the debug log from the inclusion into the controller (Aeon Labs S5-stick)

Code: Select all

   Z-Wave                          started controller inclusion mode
   Z-Wave Debug                    RCVD inclusionMode ready: 01 07 00 4A 01 01 00 00 B2
   Z-Wave Debug                    RCVD inclusionMode node found: 01 07 00 4A 01 02 00 00 B1
   Z-Wave Debug                    RCVD inclusionMode adding slave node: 01 18 00 4A 01 03 16 11 04 10 01 5E 86 72 5A 73 20 27 25 85 8E 59 70 EF 20 F1
   Z-Wave Debug                    RCVD inclusionMode node respondCmds: 5E 86 72 5A 73 20 27 25 85 8E 59 70
   Z-Wave Debug                    RCVD inclusionMode node added: 01 07 00 4A 01 05 16 00 A0
   Z-Wave Debug                    SENT exitInclusionMode: 01 04 00 4A 05 B4
   Z-Wave Debug                    RCVD exitInclusionMode: 06 (ACK)
   Z-Wave Debug                    RCVD inclusionMode finished: 01 07 00 4A 01 06 16 00 A3
   Z-Wave Debug                    SENT getNodeProtocolInfo: 01 04 00 41 16 AC
   Z-Wave Debug                    RCVD getNodeProtocolInfo: 01 09 01 41 D3 9C 01 04 10 01 ED
   Z-Wave Debug                    . .  getNodeProtocolInfo:       node 022, class name: Relay Power Switch
   Z-Wave Debug                    . .  getNodeProtocolInfo:            class hierarchy: Routing Slave : Relay Switch : Relay Power Switch (04 : 10 : 01)
   Z-Wave Debug                    . .  getNodeProtocolInfo:         base class command: 25
   Z-Wave Debug                    . .  getNodeProtocolInfo:   supported class commands: 20 25 86 27 8E 70 72 73 59 5A 5E 85
   Z-Wave Debug                    . .  getNodeProtocolInfo:     encrypt class commands:
   Z-Wave Debug                    . .  getNodeProtocolInfo:                   features: routing, beaming
   Z-Wave                          controller included module: 022 - Relay Power Switch
   Z-Wave                          stopped controller inclusion mode

And here is the log from when I try to sync it in into Indigo:

Code: Select all

  Z-Wave                          Syncing - started for "022 - Relay Power Switch"
   Z-Wave Debug                    SENT getNodeNeighbors: 01 06 00 80 16 01 01 6F
   Z-Wave Debug                    RCVD getNodeNeighbors: 01 20 01 80 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5C
   Z-Wave Debug                    . .  getNodeNeighbors: nodeId 022, neighbors: 10
   Z-Wave                          Syncing - retrieved module neighbors list: 10
   Z-Wave                          Syncing - assigning return route to "022 - Relay Power Switch"
   Z-Wave Debug                    SENT assignReturnRoute: 01 05 00 46 16 01 AB
   Z-Wave Debug                    RCVD assignReturnRoute: 01 04 01 46 01 BD
   Z-Wave Debug                    RCVD assignReturnRoute: 01 05 00 46 01 00 BD
   Z-Wave Debug                    . .  assignReturnRoute: node 022, success 1
   Z-Wave                          Syncing - assigned return route
   Z-Wave Debug                    SENT requestNodeInfo: 01 06 00 60 16 24 FF 54
   Z-Wave Debug                    RCVD nodeInfoFrame: 01 17 00 49 84 16 11 04 10 01 5E 86 72 5A 73 20 27 25 85 8E 59 70 EF 20 7B
   Z-Wave Debug                    . .  nodeInfoFrame: node 022, combined class list: 20v1 25v1 86v1 27v1 8Ev1 70v1 72v1 73v1 59v1 5Av1 5Ev1 85v1
   Z-Wave Debug                    SENT requestManufactureInfo: 01 09 00 13 16 02 72 04 25 01 A3
   Z-Wave Debug                    RCVD requestManufactureInfo: 01 0E 00 04 00 16 08 72 05 01 59 00 02 00 53 95
   Z-Wave Debug                    . .  requestManufactureInfo: node 022, manufacturerId 0159, productId 00020053
   Z-Wave Debug                    . .  requestManufactureInfo: Qubino, Flush 1D Micro Relay (ZMNHND)
   Z-Wave                          Syncing - retrieved manufacture and model names: Qubino - 0159, Flush 1D Micro Relay (ZMNHND) - 00020053
   Z-Wave Debug                    SENT requestVersInfoGen: 01 09 00 13 16 02 86 11 25 02 41
   Z-Wave Debug                    RCVD requestVersInfoGen: 01 11 00 04 00 16 0B 86 12 03 04 05 01 02 01 00 00 00 63
   Z-Wave Debug                    . .  requestVersInfoGen: node 022, protoVers 4.05, appVers 1.02
   Z-Wave                          Syncing - retrieved protocol version 4.05, app version 1.02
   Z-Wave Debug                    SENT requestVersInfoCmdClass: 01 0A 00 13 16 03 86 13 60 25 03 20
   Z-Wave Debug                    RCVD requestVersInfoCmdClass: 01 0A 00 04 00 16 04 86 14 60 04 15
   Z-Wave Debug                    . .  requestVersInfoCmdClass: node 022, class command 60 using version 4
   Z-Wave Debug                    . .  requestVersInfoCmdClass: node 022, combined class list: 20v1 60v4 25v1 86v1 27v1 8Ev1 70v1 72v1 73v1 59v1 5Av1 5Ev1 85v1
   Z-Wave                          Syncing - retrieved class hierarchy: Routing Slave : Relay Switch : Relay Power Switch (04 : 10 : 01, base 25)
   Z-Wave                          Syncing - retrieved command classes: 20v1 60v4 25v1 86v1 27v1 8Ev1 70v1 72v1 73v1 59v1 5Av1 5Ev1 85v1
   Z-Wave                          Syncing - retrieved encrypt commands: - none -
   Z-Wave                          Syncing - retrieved capabilities: routing, beaming
   Z-Wave Debug                    SENT requestMultiEndPointInfo: 01 09 00 13 16 02 60 07 25 04 B7
   Z-Wave Debug                    timeout waiting for reply from module (retrying)
   Z-Wave Debug                    SENT requestMultiEndPointInfo: 01 09 00 13 16 02 60 07 25 05 B6
   Z-Wave Debug                    timeout waiting for reply from module (retrying)
   Z-Wave Debug                    SENT requestMultiEndPointInfo: 01 09 00 13 16 02 60 07 25 06 B5
   Z-Wave Debug                    timeout waiting for reply from module (retrying)
   Z-Wave Debug                    maximum retry count exceeded waiting reply from module
   Z-Wave Error                    Syncing - failed
   Z-Wave Error                    Timeout waiting for "022 - Relay Power Switch". Module might be asleep, or is unreachable.
   Z-Wave Debug                    terminatingSyncUI


As you can see above it times out on the "requestMultiEndPointInfo" transaction.
I have tested multiple times with multiple factory resets of the device but still the same result.

This is interesting:
I now excluded the Flush 1D relay from the controller again.
Stopped Indigo.
Started OZWCP (OpenZWaveControlPanel)
Used OZWCP to include the ZMNHNDx into the S5 controller.
Changed I2 functionality to binary input.
Did a soft reset/exclusion via OZWCP.
Waited 30 secs.
Included back the device into the controller and it was now visible again in OZWCP with a new node ID (prev Node ID was gone due to the exclusion).
I could now get updates on I2 in OZWCP.

Then I stopped OZWCP and restarted my Indigo DEV.
Did a sync and this time the sync completed (even though it did with the "does not support status command"-error as the last sync line).
I could control the relay but when changing the state of I2 nothing happened in the GUI but debug log shows this

I2 = ON:

Code: Select all

  Z-Wave Debug                    RCVD requestBinarySensorStatus: 01 09 00 04 00 1C 03 30 03 FF 21
   Z-Wave Debug                    . .  requestBinarySensorStatus: node 028, endpoint None, value 255
   Z-Wave Debug                    RCVD requestAlarmSensorStatus: 01 0F 00 04 00 1C 09 71 05 00 00 00 FF 07 08 00 65
   Z-Wave Debug                    . .  requestAlarmSensorStatus: node 028, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
   Z-Wave Debug                    . .  requestAlarmSensorStatus: typeExt 7, valueExt 8, classSubKeyExt 7100000708


and I2 = OFF:

Code: Select all

 Z-Wave Debug                    RCVD requestBinarySensorStatus: 01 09 00 04 00 1C 03 30 03 00 DE
   Z-Wave Debug                    . .  requestBinarySensorStatus: node 028, endpoint None, value 0
   Z-Wave Debug                    RCVD requestAlarmSensorStatus: 01 0F 00 04 00 1C 09 71 05 00 00 00 FF 07 00 00 6D
   Z-Wave Debug                    . .  requestAlarmSensorStatus: node 028, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
   Z-Wave Debug                    . .  requestAlarmSensorStatus: typeExt 7, valueExt 0, classSubKeyExt 7100000700


[matt (support)]

Indigo v7.0.3 is now available and includes several fixes/improvements for Qubino modules. Note there can be a delay before the module reports secondary input (I2, I3, etc.) changes back to Indigo, but they should now work. You should re-sync your Qubino modules after installing the update.

Many thinks to CrazyFin for doing extensive testing both on and off the forum with us to get these working reliably.