Trouble with xml export for new ZWave device

Add-ons Bindings
,
1

I have created a new device in the ZWave database for the recently released supported Yale Assure 2 ZWave module.

When I export the XML file, there are some funky bits that I cannot seem to correct, hoping some manual intervention can help?

  1. A number of parameters have gotten stuck thinking that there is a value in the “Overview” field - I have them empty, but they are still showing up as if there is text, with a header of “Overview” even though there is no text then in the “Overview”… Currently parameters 3, 4, 5, and 12 have this problem. For a handful of these parameters, there is a description that should be preserved, that gets mixed in with the broken overview header, parameters 3, 4, and 12.
  2. Parameter 11 should have a default of 255, and that is the value in the configuration, but in the XML output, it has -1.

Another thing that I had trouble with when testing is that the default channel created for COMMAND_CLASS_ALARM has “alarm_access”, which is a valid option in the name dropdown, however in the code, it looks like we should be using alarm_entry. When the alarm_access is used, the binding logs say that alarm_access is not implemented. When I change that to alarm_entry, it works like a charm!

The other channel created by default was for “alarm_power”, when I actually need “alarm_battery” - these are both valid types, I don’t know if it is even possible to tell from the XML which is the right one…

Oh, right, one last thing - I had initially created a device before I noticed that the lock was not able to be included securely, and so the first XML was missing quite a bit of the config that requires security. So this device I do not plan to submit for review, and need to have it be deleted…

Anyway, I wasn’t sure if we should get the parameters fixed up before I submit #1571 for review, other than these issues, my locally built binding has been working well, I continue to be so grateful for the work that folks have put into making this database and openHAB code!

Thanks,
–Scott

@chris / @Bruce_Osborne

2

The exported OH2 xml file undergoes some sort of html purifier when actually exported for inclusion into the Zwave binding. I had thought about opening a ticket in the DB to apply that purifier when using the OH2 XML export. On a quick review I think your device will look okay once merged. Since it is working I wouldn’t worry about it. If the merged XML version doesn’t display correctly it should be more apparent as to what needs to be fixed.

The zwave bytes are signed so 255 = -1 However, I’m a little surprised that doesn’t jam up the initiation with the rigorous checking that was introduced in OH3.3. Maybe that has been fixed?

The default channels are educated guesses from the uploaded XML file and sometimes need to be changed. The right one is one that works. I use the DEBUG level to look at the byte payload (or use my Zniffer) to figure out the message and then adjust to fit the DB. I did open a ticket to add this to the documentation, but it has been addressed yet,
alarm-channel-mapping2.pdf (525.3 KB)

1 Like
3

Hrm, interesting. So while setting configuration does work (it affects the lock behavior), there is some funkiness.

When I initially added the lock, the settings displayed in openHAB did not match the settings in the the Yale app (bluetooth access), and now that I have set some of the options from openHAB, the settings in the Yale app do not reflect what I have set.

Also, I have not seen this recently, but I was seeing logs like (truncated for the interesting parts and to not tell everyone what my lock codes are :slight_smile: ):

2023-06-21 08:47:42.980 [WARN ] [.core.thing.binding.BaseThingHandler] - Attempt to apply invalid configuration 'Configuration[{key=usercode_code_139; type=String; value=}{key=config_11_1; type=BigDecimal; value=-1}, {key=usercode_code_157; type=String; value=}]' on thing 'zwave:device:6346de675b:node32' blocked. This is most likely a bug: {config_11_1=The value -1 does not match allowed parameter options. Allowed options are: [ParameterOption [value="0", label="Off"], ParameterOption [value="255", label="On"]]}

It seems that maybe sometimes the -1 is being treated as a string, and sometimes as a byte?

I will play around with this some more to see if using -1 instead of 255.

It seems that the min/max values are ignored, or at least not put into the XML, but it would be good to know if I should think of it as a number and make -1 the min, or as a byte and make -1 the max…

Thanks,
–Scott

4

So it is not fixed… in cases like this my thought was to set the min at -1, instead of 0, then set limit to options false. Another option might be set the minimum at -1, but add -1 to the list of options with the same wording as 255 and keep limit to options true. I think both might work. Just a couple of suggestions.

Edit; FYI-There is a similar issue reported on the zwave binding site.

5

OK, after lots of running back and forth (my computer with access to the logs is just out of bluetooth range of the lock), I think I have this as sorted as it is going to get.

Using -1 and 0, instead of 255, and 0, is making almost everything much better. I can now change settings through openHAB, they are changed in the Yale app as well.

One thing that seems to be a bug on the openHAB side. When I make a change through the Yale app, configuration is sent over ZWave, which seems to be processed:

2023-06-24 12:02:06.045 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 32: Incoming command class COMMAND_CLASS_CONFIGURATION, endpoint 0
2023-06-24 12:02:06.045 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 32: Received COMMAND_CLASS_CONFIGURATION V1 CONFIGURATIONCMD_REPORT
2023-06-24 12:02:06.045 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 32: Node configuration report, parameter = 13, value = -1, size = 1
2023-06-24 12:02:06.046 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 32: Got an event from Z-Wave network: ZWaveConfigurationParameterEvent
2023-06-24 12:02:06.046 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 32: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CONFIGURATION, value=org.openhab.binding.zwave.internal.protocol.ZWaveConfigurationParameter@2e7c081e
2023-06-24 12:02:06.046 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 32: Update CONFIGURATION 13/1 to -1
2023-06-24 12:02:06.047 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration pending removed for config_13_1
2023-06-24 12:02:06.047 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 32: Commands processed 1.
2023-06-24 12:02:06.047 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 32: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6061f0b8.
2023-06-24 12:02:06.047 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2023-06-24 12:02:06.048 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1

Notice the -1, it seems to apply the configuration, BUT, the change then does not show up in openHAB on the thing page. Regardless of whether the incoming change is to 0 or -1, the configuration claims to be applied, but it does not show up as changed in the thing page.

NODE 32: Update CONFIGURATION 13/1 to -1

There also is some issue with the two settings around auto locking, both the on/off and the timing. When I get a configuration change report from the device through zwave, it uses 0 and -1, however these values on inverted from all the other on/off values for this device, in that 0 is on, and -1 is off. Also, the values are inverted from what the Yale documentation claims that they should be.

If I set the value to on from the Yale app, I am able to change it to off successfully through openHAB by sending -1. However, when I set the value to off in the Yale app, I am unable to set the value to on.

I am suspecting that the ON value is some value I have yet to discover, and that the device interpreting ANYTHING other than the ON value as OFF…

I only get spotty notifications of configuration changes for the two broken configuration changes, it is quite possible that the only times I have seen a configuration report is when I am sending a change, and that change is just mirrored back, so it is possible that my interpretation of the 0/-1 being inverted are just seeing the value sent, not the value from the actual device.

All this I believe to be bugs on the device side.

6

I have noticed something similar when a config is set from outside the UI page. I added a channel to the Configuration CC (AEON Zw096) to change a device parameter via a rule (say based on time of day) to limit reporting during the night. Anyway the parameter change is reflected in the item and the way the device reports, but the UI thing page doesn’t change. I think that is populated during the “static values” phase of the start-up interview or from the xml, so is not dynamically updated like a channel.

Edit: If the parameter change is sent by OH there are three messages SET, followed by a GET and then a REPORT from the device. The yale app should do the same as I think it is a ZWave standard. However, I’m not sure what traffic OH is getting in that case, maybe just an unsolicited REPORT and it might not know how to handle that.

1 Like