Initialization of AEON Labs ZW130 WallMote Quad fails

Best is probably ot use the log viewer and make sure there is plenty of data for the required node. I’d be especially interested in data that the binding is sending to the node rather than unsolicited data as that’s more likely linked to the initialisation.

This looks quite promising. Two files as the log rotated.
Still no .xml file. Deleted old node44 xml as it was giving a parse exception.!Ak62_W4agNNTiSM8CZN5V3hB9EL8

.1 file is from rotated log

The problem is this -:

It needs some thought on how to handle this…

Please download the latest version of the binding off my site (you are using the development version with security, right?).

Let me know if it’s better or not - it’s slightly experimental but I think it might solve the issue with the initialisation at least… If not, then please provide another log…

Yes, I am, downloaded and started v of binding (and re-installed openhab-transport-serial.)
Many exceptions, so I did a full apt-get upgrade as well. Looked OK in the end.

Log and .xml file generated here:!Ak62_W4agNNTiSbu4-IqyH_xg-tp

Does it look ok?

If you didn’t upgrade to the latest version for the past week or so, then the errors will be correct since there was a breaking change in ESH which caused me to rename a class in the binding and this means that the newer bindings only works with new runtimes.

I’ll try and take a look at the log tomorrow, but if the binding is now generating the XML, then it’s probably good news :).

And I will charge the WallMote again and see how long that lasts.
Are you planning on having another look at the slider function of these remotes?

Yes, I will implement something soon for the slider function. I was hoping that ESH might be convinced to provide more suitable item types, but this seems not to be the case :(.

Hi, Sorry to tag onto the end of this but I was looking to confirm if all versions of the ZW130 should be working now since I’m down in New Zealand and picked up a WallMote buts its a ZW130-B. I’ve tried a number of snapshot builds uto the 30th of July but have gone back to release for now. I’ve even rebuilt my Ubuntu (16.04) VM server again to confirm its was nothing odd there. I’m just starting out with OpenHab so happy to switch between builds / VM servers etc.

I seem to have the same issue with no xml file being created. I’ve also tried to add the Mote via PaperUI and HabAdmin. I just get Unknown Device:

zwave_class_basic ROUTING_SLAVE
zwave_class_generic REMOTE_SWITCH_2
zwave_frequent false
zwave_nodeid 4
zwave_version 0.0
zwave_listening false
zwave_routing true
zwave_wakeup_time 2017-08-01T10:20:10Z
zwave_beaming true
zwave_class_specific SWITCH_REMOTE2_MULTILEVEL

Please let me know if I’m better putting this in a new thread,

Thanks Mark

@markg32 I am using the development Z-wave binding discussed here: OH2 Z-Wave refactoring and testing... and SECURITY
Super long thread, but all info you need is there :slight_smile: (link to binding .jar in first post)

I can confirm that with that binding my European ZW130-C works fine.
Haven’t used the SNAPSHOT binding since I switched to the development binding, so I don’t know its status.

I charged my remote June 27. and battery charge is currently at 21%

1 Like

@markg32: Just a heads up regarding this device. It is not the most reliable as you will see when googling around, but they might come up with a firmware fix someday. The current 1.07 on the Aeon WEB site does not fix the tandrums it runs into every once in a while.

It was discussed here
It also received some bad reviews on Amazon.

Anyway, this is not OH’s fault :slight_smile:

@chris, I’m trying to lower the power level om my ZW130s to see if I can get even better battery life.
Hitting Save throws an exception:

Here are the logs from 3 attempts:

omr@shs2:~$ grep -C 1 powerlevel_level /var/log/openhab2/openhab.log
2017-08-02 19:56:14.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 45: Configuration update received
2017-08-02 19:56:14.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 45: Configuration update powerlevel_level to 9
2017-08-02 19:56:14.151 [ERROR] [] - Exception during HTTP PUT request for update config at 'things/zwave:device:f180343d:node45/config' for thing 'zwave:device:f180343d:node45': java.math.BigDecimal cannot be cast to java.lang.Integer
2017-08-02 19:58:09.821 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Configuration update received
2017-08-02 19:58:09.822 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Configuration update powerlevel_level to 9
2017-08-02 19:58:09.823 [DEBUG] [andclass.ZWavePowerLevelCommandClass] - NODE 47: Creating new message for application command POWERLEVEL_SET, level=9, timeout=0
2017-08-02 19:59:43.606 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 45: Configuration update received
2017-08-02 19:59:43.607 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 45: Configuration update powerlevel_level to 1
2017-08-02 19:59:43.607 [ERROR] [] - Exception during HTTP PUT request for update config at 'things/zwave:device:f180343d:node45/config' for thing 'zwave:device:f180343d:node45': java.math.BigDecimal cannot be cast to java.lang.Integer

Nice if you could have a look at it. It’s the development binding:

openhab> bundle:list | grep Z
  9 | Active   |  80 |     | ZWave Binding

Sorry - I missed this. I’ll take a look tonight (probably it’s easy to find).

I don’t anticipate that this will change battery life though - transmissions are very short, so reducing the power consumption a small mount makes very little difference unless the system is transmitting very often.

@chris, exception gone, but still not working.

2017-08-11 20:57:05.822 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
2017-08-11 20:57:05.822 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
2017-08-11 20:57:06.964 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Configuration update received
2017-08-11 20:57:06.969 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 47: Configuration update powerlevel_level to 9
2017-08-11 20:57:06.970 [DEBUG] [andclass.ZWavePowerLevelCommandClass] - NODE 47: Creating new message for application command POWERLEVEL_SET, level=9, timeout=0
2017-08-11 20:57:06.970 [DEBUG] [ommandClassTransactionPayloadBuilder] - At build null
2017-08-11 20:57:06.971 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 47: Encapsulating message, endpoint 0
2017-08-11 20:57:06.971 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 47: SECURITY not supported
2017-08-11 20:57:06.972 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 47: Command Class COMMAND_CLASS_POWERLEVEL is NOT required to be secured
2017-08-11 20:57:06.972 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 47: Adding to device queue
2017-08-11 20:57:06.972 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 47: Added to queue - size 0
2017-08-11 20:57:06.973 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start

openhab> bundle:list | grep Z
  9 | Active   |  80 |     | ZWave Binding

I don’t see anything wrong - it looks like it’s created the message so I guess it should have sent it next time the device wakes up.

Just a little update to say I think my WallMote Quod is faulty as it won’t even do a firmware update where my other Aeotec devices update just fine with the same laptop and stick… I’ll post an update with how I get on…

I’ve been having difficulties getting my Wallmote to update configuration changes from habmin.
I see in the log that there are still 2 queued messages, but no amount of wake ups gets them successfully sent to the Wallmote, they just get requeued with the original deleted. The heal operation will not work either since the device is reported as not initialised.
@chris I wonder, is there a way to view and remove the messages from the queue ?

You can’t remove them, but it should be clear from the logs what the messages are and I guess there’s probably some sort of problem with timeouts that is also linked?

LOL ! If only they made some sense to me…

I’m trying the route of deleting the device from Openhab, removing from the controller, doing a reset of it and then re-adding. Hoping that this will allow me to start over and then make one change at a time.

Ok, if you can’t sort it out then please post the full debug log somewhere and I’ll have a look. Chances are the problem will come back…