Aeotec Water Sensor 6 (ZW122) multiple issues

[kpanchen]

Hi, I'm currently switching to zwaver-js-ui and moving all my devices along the way encountered some issues particularly with this Water Leak Sensor (not using HA, just MQTT functionality):

1. I have device on USB power / always awake, configuration is reflecting this but main dashboard indicates that device is sleeping and only receive commands / configuration updates upon button press. Similar device Multisensor 6 which could be powered by battery or USB works correctly and indicates that device is awake.
2. Attempt to include device is S0 secure mode only interviewed endpoint_0 securely and endpoint_1 and 2 non-securely which made them inoperable (not able to tell which probe sensor detected a leak). Non-secure inclusion worked fine.
3. I also noticed that bitmasked parameters not always set configuration correctly, this goes for both devices ZW122 and Multisensor 6 ZW100. As an example if parameter has higher bytes temperature scale and lower bytes recovery limit and scale set first it will set lower part incorrectly to some strange value, manual calculation and parameter set up will set it properly.

Both devices are currently out of support / end of life so 2 and 3 are not that important, non-secure works and params need to set only once. But 1 is interesting issue and probably can be fixed judging that the other device does not behave this way.

Thank you and thank you for your great work!! I can provide more information if needed.
K.

[AlCalzone]

1. From the POV of the Z-Wave network, once a device is included with battery power, it will always be considered a battery-powered device. When you change how a device is powered, you have to exclude and include it again.

2. Please make a driver log of a re-interview, loglevel debug and attach it here as a file (drag & drop into the text field).

3. Can you share specific examples please?

   • What were the partial values before setting the parameter?
   • What did you change?
   • What got sent to the device? (driver log!)
   • What did you expect to get sent instead?

[kpanchen]

1. From the POV of the Z-Wave network, once a device is included with battery power, it will always be considered a battery-powered device. When you change how a device is powered, you have to exclude and include it again.

I've tried to include it multiple times, always powered through USB with the same behaviour - battery device, however in config it is correctly saying that it is USB powered, removing from doc / power disconnection will show that device is on battery, power reconnection showing USB power.

2. Please make a driver log of a re-interview, loglevel debug and attach it here as a file (drag & drop into the text field).

I've included both logs, both inclusion secure and un-secure should be there, please have a look if that is not enough let me know I'll try to reinclude it again in secure mode.

3. Can you share specific examples please?

   • What were the partial values before setting the parameter?
   • What did you change?
   • What got sent to the device? (driver log!)
   • What did you expect to get sent instead?

I will be including / configuring some more devices soon, will pay attention if any such parameters are incorrect.
Thank you,
K.

z-ui_current.log
zwavejs_2023-10-28.log
zwavejs_current.log
z-ui_2023-10-28.log

[kpanchen]

Ok, I've spent a bit of time including my Multisensor 6 and turned out I was wrong:

I was confused by the word "default". So what is happening I have a North American version of the device which is defaulting to Fahrenheit as for US but the rest of the North America as the rest of the world use Celsius (I'm from Canada). So basically default is showing 280 which is 28.0 degrees Celsius but after reset sensor switched to Fahrenheit and set value to 82.4 :) Same with the lower limit. I guess if we can just adjust default to something like "Default: 280C / 824F" and it will be clear. Anyway I won't consider this as an issue, just a cosmetic presentation.

At this point I'm more interested in the "sleeping" water sensor, let me know if you need more information or those logs are enough.

Thank you,
K.

[kpanchen]

Found another one, Parameter 57 - according to documentation 1 is Celsius and 2 is Fahrenheit (NOT 0 and 1):

Default Fahrenheit presented as "Custom 2" and changed "Celsius" presented as "Fahrenheit".

Here's extract from documenation:
High byte is the recover limit value. Low byte is the unit (0x01=Celsius, 0x02=Fahrenheit).

This is all for Aeotec Multisensor 6 ZW100.

Thanks,
K.

[AlCalzone]

however in config it is correctly saying that it is USB powered

I know that some Aeotec devices do this, however this has no influence on how the Z-Wave network considers the device. Even if it says there it is USB powered, if it is considered a sleeping device (battery powered), it will never be used for routing and such. You could ask Aeotec if this is a known issue but I'm not sure they'll fix Gen5 firmware at this point.

I guess if we can just adjust default to something like "Default: 280C / 824F" and it will be clear.

The default value is a number in the configuration file. What we'd need is the ability to change config parameter definitions based on the values of other config params: #5583

Found another one, Parameter 57 - according to documentation 1 is Celsius and 2 is Fahrenheit (NOT 0 and 1):

This is incorrect in our files then.

Attempt to include device is S0 secure mode only interviewed endpoint_0 securely and endpoint_1 and 2 non-securely which made them inoperable (not able to tell which probe sensor detected a leak). Non-secure inclusion worked fine.

The problem is that the sensor is barely connected. Even the first communication attempts that Z-Wave JS does itself are falling back to 9.6 kbit/s. This is the lowest speed and only used if nothing else works.
Often responses are missing, which leads to queries timing out, so Z-Wave JS sometimes cannot discover device functionality. In some cases it's even unable to figure out which commands are supported securely.
I'd a) not use Security S0 for sensors, because it adds two additional commands per actual command, all of which can fail. And b) look into improving the connectivity.

[kpanchen]

Thank you for you answers!

1. I'm ok with 1, when parameters are set device works fine, I don't need it to be a router. AEOTEC treated it as a legacy.
   2 and 3. Thanks for you for acknowledgment.
2. It is really strange and I will blame that particular device for that, I've tried to pair it literally couple of meters from the controller which is a brand new Aeotec stick 700, they still have some issues with the firmware but in general it works fine, I don't see any other issues with the network, Multisensor 6 can be included even from the distance with security 0.

I would agree that really no security needed for that one and that's how it is included now and will stay that way, main functionality is not affected.

Thank you for your such detailed responses! I think we can close and archive this issue now!
K.

[mundschenk-at]

I have the same device, S0 just plain did not work - the firmware is broken and Aeotec will not fix it because the device is too old now.