ZWave binding updates

[chris (Chris Jackson)]

@romain

2018-10-27 09:53:29.044 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 2: Security = false

This message is not linked to the secure inclusion, so I wouldn’t worry about this.

[romain]

OK, I’m definitely not understanding all the underlying stuff

Do you have sufficient logs to investigate from your side with those logs ? I can enable TRACE level and post the whole 20MB logs if it helps ?

[thefathefa]

@chris

I’m not sure I follow your point? I think that in all cases I saw, the messages are separate - the setpoint is always sent by itself.

Ok, understood, I have to say that I don’t distinguish very well between the messages, and in the first trace I posted, the processing of battery level & setpoint are very near each other and almost interleaved.
Going back tothe first block of traces, this would be

2018-10-27 10:49:56.708 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 02 03 80 03 43 33

This one would be the battery info?

2018-10-27 10:49:56.729 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 02 06 43 03 01 02 07 2C 9B

And this one would be the setpoint info, which seems to have arrived before the entire processing of the battery info was completed…

Since I did not have this problem when using my super old Zibase and associated openHab binding with this device, I’m not sure I’ll be able to ask the vendor for support, so I guess I’m going to have to filter those “erratic” values (and very temporary as well, because after few seconds there is another message with the right value…
The concrete issue for me is that temperature graphs are “a bit” distorted by the 2000°C reported, even if for a short period of time, so basically I guess I’ll have to filter those values and ensure that they are not saved in database and don’t trigger the various alerts…

Thanks again for your help, Chris.

[chris (Chris Jackson)]

@thefathefa

This one would be the battery info?

The first one is the battery level and the second one is the setpoint.

@thefathefa

Since I did not have this problem when using my super old Zibase

Maybe this device had filtering for such events?

@thefathefa

The concrete issue for me is that temperature graphs are “a bit” distorted by the 2000°C reported, even if for a short period of time

I understand. I could add some filtering, but it’s very complex to get right, and IMHO is something that is not ZWave specific. If someone wants to add such filtering, it would probably be good to add it to the core instead so it is resolved on all bindings.

@thefathefa

Thanks again for your help, Chris.

You’re welcome.

[thefathefa]

Sure, this shouldn’t be done in the binding, I agree.

[sihui]

@thefathefa

so I guess I’m going to have to filter those “erratic” values

Discard outrageous sensor readings

If you create a second item for each sensor item, like Number Temperature "Temperature [%.1f]" (groupA,groupB) Number Temperature_from_sensor "Temperature from sensor [%.1f]" { ...your current binding... } and then a rule like this: import org.openhab.core.library.types.DecimalType // not needed in OH2 rule TemperatureFilter when Item Temperature_from_sensor changed then if ((Temperature.state instanceof DecimalType) && Math::abs((Temperature.state as DecimalType) - (Temperature_from_sen…

[thefathefa]

@sihui, thank you, very convenient;-) I have put this in place and will check how things go…

[Edward_Moyse]

Apologies if this was already covered (I did search, but it’s a long thread) but I have tried to follow the instructions, and kept my old controller.
zwave:serial_zstick:157b8d41438 (Type=Bridge, Status=INITIALIZING, Label=Z-Wave Serial Controller, Bridge=null)

(I have a Zwave plus aeonlabs USB stick in a raspberry pi running the latest snapshot).

However when I look in PaperUI I see " ZWave Plus USB Dongle" and in the log I see:

2018-10-31 13:51:09.281 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:serial_zstick:512' to inbox.

I tried deleting my old controller, and adding this, but I wasn’t sure how to change the thing id using PaperUI (so I wouldn’t have to update my items files). So in the end I added azwave serial controller again using Habmin, with id=157b8d41438, but then I get back in the original situation: I have a serial controller, but PaperUI (and since I see it in the log, presumably openhab itself) wants me to add another dongle.

What am I missing?

Edit: hmm. This controller doesn’t seem to find any things:
zwave:serial_zstick:157b8d41438 (Type=Bridge, Status=INITIALIZING, Label=Z-Wave Serial Controller, Bridge=null)

Maybe I just need to give in and edit my items files…

[mhilbush (Mark)]

@Edward_Moyse

I have a serial controller, but PaperUI (and since I see it in the log, presumably openhab itself) wants me to add another dongle.

There was new core functionality added to auto-detect USB devices. That’s what you’re seeing in the Inbox – the system auto-detecting the zwave USB stick. You can ignore the one that was auto-detected.

[Edward_Moyse]

That means I can’t ever do ‘add all’ though, which is quite annoying. Is there any advantage in using the USB devices? Presumably this new functionality was added for a reason?

[5iver (Scott Rushworth)]

@Edward_Moyse

That means I can’t ever do ‘add all’ though, which is quite annoying.

You can Ignore and Show Ignored items in the Inbox. Once duplicate controller is Ignored, you should be able to use the Add All functionality.

@Edward_Moyse

Is there any advantage in using the USB devices? Presumably this new functionality was added for a reason?

USB Z-Wave and Zigbee controllers used to have to be manually created. They can now be discovered. You could write down all of the configuration for your existing controller, delete it, and then use the newly discovered one. Or just mark it as Ignored.

[berland (Håvard Berland)]

@berland

@chris

@berland

My Z-wave ventilation controller unit does not work any longer with OpenHAB 2.4 snapshot (updated today), the unit is this:

There have been no changes to this device in the database for the better part of a year. You don’t say what you changed from? Were you previously on 2.3 or what?

Yes, coming from 2.3 stable, and the device has just been deleted and then readded in the 2.4 upgrade process, so I don’t know of anything else that has changed than the binding. Do the log messages point anywhere, or should I gather more?

Sorry, this was wrong. The error occured between 2.2 and 2.3, at 2.3 I managed to fix it as described in

Ventilation unit not working in OpenHAB 2.3, XML file is not populated with fanModes

I have the following device: [https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/430 which I did not get to work after an upgrade to OpenHAB 2.3 and simultaneously a full rebuild of the Z-wave network (another thread…) In OH2.3 I could not set fan modes or thermostat values, as the fanModeTypes in the XML-file was not populated - it seems the binding should retrieve that from the z-wave device, but apparently fails at doing so: 2018-06-07 21:51:0…

I have not been able yet to apply the same workaround on 2.4.

[Cernon]

I used Openhab 2.3 and the old Zwavebinding. Now I update to the newest Snapshot with this new binding. Everything works fine. Only one device don’t work.

Vision Security ZS5101 Shock Sensor

I have exclude/inklude it, but now it shows me, „unknown device“.

Its a battery device and I have wakeup it, which worked at the old version, but not at the new one.

Has somebody an idea?

[lenorb (Norberto)]

Hey all, and thanks for the update!

I followed the Recommended update process as per the first message, and it worked great.

These are the things I tried but that did not work well at all.

1. defining the devices in .things without defining channels => what a mess, no device ever really worked, they initialize, then they’re ok, then they’re not and the items never worked

2. installing via paperui worked the best, when I tried removing from paper ui and installing via addons.cfg, it failed and would not work even after a couple of restarts.
   2.a. I was not able to make zwave work at all with that process (addon via addons.cfg), I got the message:

   307 │ Active │ 80 │ 2.4.0.M5 │ org.openhab.binding.zwave
   openhab> java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver
   java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver
   java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver

My plan was to have the devices in .things files, I then gave up that idea and only kept the bridge in a .thing file and had the devices themselves being discovered and added in paperui.

If anyone has pointers about how to make it all work with static .things files for devices, I’d love to know.

here are my things files
bridge:

Bridge zwave:serial_zstick:zStickController "Z-Wave Serial Controller" [
  port="/dev/ttyACM0",
  controller_softreset="false",
  controller_master="true",
  heal_enable="true"
]

devices:

Thing zwave:device:zStickController:node45 "CWS-3101 Wall Switch" (zwave:serial_zstick:zStickController) @ "Some Room" [node_id=45]
Thing zwave:device:zStickController:node50 "Soft Remote Remote Control" (zwave:serial_zstick:zStickController) @ "Kids Room" [node_id=50]

[chris (Chris Jackson)]

@lenorb

If anyone has pointers about how to make it all work with static .things files for devices, I’d love to know.

Please see the following thread -:

ZWave Manual Thing Configuration

This write-up provides a “how-to” to actually get this configuration completed for Z-Wave for those that don’t want to use the automatic configuration that the binding provides. Z-Wave things can be configured in the same way as other OH2 bindings - for general information refer to the OH2 documentation. Note that at the time of writing, text configuration of things is only available in the development version of the binding - not the master or snapshot versions. At the time of writing, there …

[shorty707]

just saw this on the log by coincidence.
not sure if it is interesting

0:13:21.391 [ERROR] [ave.internal.protocol.ZWaveController] - NODE 50: Restore from config: Error deserialising XML file. com.thoughtworks.xstream.converters.ConversionException:  : ParseError at [row,col]:[427,1]
Message: XML document structures must start and end within the same entity. :  : ParseError at [row,col]:[427,1]
Message: XML document structures must start and end within the same entity.
---- Debugging information ----
message             :  : ParseError at [row,col]:[427,1]
Message: XML document structures must start and end within the same entity.
cause-exception     : com.thoughtworks.xstream.io.StreamException
cause-message       :  : ParseError at [row,col]:[427,1]
Message: XML document structures must start and end within the same entity.
class               : org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveDeviceResetLocallyCommandClass
required-type       : org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveDeviceResetLocallyCommandClass
converter-type      : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
path                : /node/endpoints/entry/endPoint/supportedCommandClasses/entry[15]/COMMAND_CLASS_DEVICE_RESET_LOCALLY
line number         : 427
class[1]            : java.util.concurrent.ConcurrentHashMap
converter-type[1]   : com.thoughtworks.xstream.converters.collections.MapConverter
class[2]            : org.openhab.binding.zwave.internal.protocol.ZWaveEndpoint
class[3]            : org.openhab.binding.zwave.internal.protocol.ZWaveNode
version             : 1.4.7
-------------------------------

is a qubino din rail dimmer (got 16 of those)

[Anquietas86 (Josh Hagger)]

Anyone know what might be causing this?
https://community.openhab.org/t/fibaro-dimmer-issues-after-upgrade/56320

Regards,
Josh

[shorty707]

@romain

Shortly after that it comes to the “REQUEST NIF” state and does not advance any more.

On the recent versions of openhab / zwave I have this constantly.
After a restart randomly nodes get stuck at REQUEST_NIF … also mains.
Evey restart other nodes are affected. I was thinking my slow Pi2 just can’t handle the 80 zwave devices … however I did not inestigate deeply and it could be another problem.

[jwiseman (Mr. Wiseman (OH 4.2 Snapshot on Pi4))]

Hi Chris,

Great work on your zWave binding; I follow your threads and your always so responsive which makes me believe this is your full time job

Anyway; I’m running OH2.3 on a Synology NAS and I have NOT upgraded to OH2.4 but I’m running your zWave 2.4 M4 build w/o any issues.

Can you point me to where you store your zWave binding downloads so I can get the zWave 2.4 M5.x ?

Best, Jay

[chris (Chris Jackson)]

@jwiseman

I follow your threads and your always so responsive which makes me believe this is your full time job

It sure feels like it sometimes .

@jwiseman

Can you point me to where you store your zWave binding downloads so I can get the zWave 2.4 M5.x ?

They aren’t stored anywhere as such - but there’s is the CI server where the builds are done, so the latest build can always be found here.