Configuration parameter No.117 allegedly missing from Shelly Qubino Wave 2PM (QNSW-002P16EU) (and maybe others?)

[RaulDJ]

Checklist

• It is not in the configuration DB

• It was not merged recently or has a pending PR

• The device was interviewed completely and has no missing or undefined IDs

Which device is missing?

Shelly Qubino Wave 2PM

Manufacturer ID

0x0460

Product Type

0x0002

Product ID

0x0081

Firmware Version

v10.30.0

Is the device listed on the Z-Wave Alliance website?

It isn't, here's the most similar product: https://products.z-wavealliance.org/products/4961?selectedFrequencyId=-1

Do you have a manual?

Here's the device documentation: https://kb.shelly.cloud/knowledge-base/wave-2pm

Supposedly, there's a 1 byte parameter, "No. 117", that allows the user to reset the device when the apparently trigger happy protection algorithms happen to kick in, such in this case: https://kb.shelly.cloud/knowledge-base/wave-2pm#Wave2PM(EU)-ACmainsdisconnected .

That parameter seems to be common to a lot, if not all, Shelly Qubino devices, and it's further explained in some (but not all) of their manuals: https://products.z-wavealliance.org/ProductManual/File?folder=&filename=cert_portal/certs/1092/Extended_User_Guide_Wave_PlugUKV1.4.pdf

Maybe it's also missing on other configuration files from similar devices from this manufacturer.

Thanks a lot for your attention and the great work, keeping up on all these devices through years.

[AlCalzone]

@QubinoHelp can you clarify which devices have this parameter?

[QubinoHelp]

Currently only the Plug UK and Plug US have this parameter.

The Knowledge Base required an update. Parameter 117 was intended for inclusion, but there has been significant discussion surrounding its implementation.

This feature is undeniably necessary in scenarios like yours or other situations where an individual device needs to be reset without interrupting power to an entire line of devices or appliances.

However, we must not compromise safety. Allowing a reset of, for instance, an overheating power condition without verifying the situation (as might be the case when a user has the device in a remote location) introduces a fire risk.

Given the divided opinions on the matter, we allowed time to pass without removing the parameter from the Knowledge Base. After several meetings, we decided to proceed with adding the parameter as originally intended but included a warning note for customers about resetting the alarm without verifying the state of the device.

We will start to add the parameter 117 to the devices already on the market trough an OTA update, while the ones that will be manufactured in the next half of the year will have this parameter added already.

[RaulDJ]

@QubinoHelp

Thanks a lot for the clarifications. That ability to remotely restore functionality is really needed at least for the "AC mains failure" alarm, as for what I've seen, it seems to happen fairly often with brownouts and such.

I understand that ignoring an overheat or overcurrent alarm without actually checking the physical condition of the devices attached to the relay box would be quite risky, but not being able to do it after a power loss (or a simple brownout) in areas with not great grid stability would be a deal breaker for people in a situation like mine, so I'll be eagerly waiting for those updates.

[AlCalzone]

@QubinoHelp Thanks! I suppose we can add the parameter to our config files then with a $if condition to limit it to appropriate models/firmwares. Let me know if you need help with that.

[QubinoHelp]

@AlCalzone That would be the case yes, we will add also the detached mode parameters that will have to be done with an if condition since they will be implemented in all of our devices but from a certain firmware up.
I will need help when the time come :) thanks.