I’ll try and look tonight - I’m travelling most of the day/evening unfortunately so it might be tomorrow…
Hi dries_dokter,
I am running four WALLC-S on OH1. Some of the WALLC are already in use for more than two years. Until now I did not replace any battery. The switches are used around ten times a day. In my configuration, the wakeup is completely switched off. I hope this will work for you as well.
Jeroen, not sure what you mean: I have been using the switches to satisfactory on OH1 too.
Problem is that I can’t get them to work in OH2 (read the thread). In the process of analysis and trying stuff, I manually wake-up the switches (a lot) and that drains the battery problem much faster than in real live.
But even using them in OH1 I was not able to get 2 years out of the battery(but might have used cheap batteries). However I am not the only one mentioning the battery thing
https://www.robbshop.nl/zwaveme-wandzender-zme-wallc-s (look at “Minpunten”)
Do you have any plans to switch to OH2? Because it would be interesting to compare your experiences with OH2 and WALLC-S with mine…
Hi dries_dokter,
I was triggered by your remark on battery life. I searched on Internet how to get the most out of a battery, and the answer was about lowering the wakeup interval. This is my config on wakeup:
Maybe this setting will help getting you also more than two years out of a battery. But of course during configuration and putting it again and again in management mode will drain your battery in no time. It has also the ten days wakeup interval, which you think it is an error.
Currently OH1 (on raspbian, raspberrypi2) is my ‘production environment’. It must operate to prevent complains of the family members 
In OH1 a lot of rules, scripts and many items are defined. The WALLC-S are used to e.g. control hue bulbs and to switch scenes.
Currently OH2 is installed on the same raspberry. Sometimes I switch by stopping OH1 and starting OH2. I do not include/exclude devices, because it will break the system. Important is that all devices will be recognized and are operable. Among others Fibaro dimmer, switches, roller shutter, binary sensors, zwave.me usb stick and the famous WALLC-S)
I will run the latest OH2 today, to see what happens( without the inclusion / exclusion steps). Let you know what happened.
7 days is in fact the default wake-up time for the WALLC-S 
That’s what I use them for too (and switching of the Stereo/TV/etc)
Would be very much appreciated 
In reality, lowering the wakeup won’t really help much. If you change from never to 1 week, it might reduce life by a few days. If you change from a week to a day, again, you might loose a small amount, but it won’t be noticable - even dropping down to an hour will only make a small amount of difference to life. As you start to reduce further, you will then see significant reduction.
I use 1 hour on my devices and get 1 1/2 to 2 years life on devices like door sensors and motion sensors…
This will be interesting, thanks - can you grab a debug logfile as well please 
Maybe you have already added this, @jeroenvdwaal but just for your convenience:
To get a separate z-wave.log in OH2 add the lines below to : runtime/karaf/etc/org.ops4j.pax.logging.cfg
log4j.logger.org.openhab.binding.zwave = DEBUG, zwave
# File appender - zwave.log
log4j.appender.zwave=org.apache.log4j.RollingFileAppender
log4j.appender.zwave.layout=org.apache.log4j.PatternLayout
log4j.appender.zwave.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n
log4j.appender.zwave.file=${openhab.logdir}/zwave.log
log4j.appender.zwave.append=true
log4j.appender.zwave.maxFileSize=10MB
log4j.appender.zwave.maxBackupIndex=3
# no zwave logging in openhab.log
log4j.additivity.org.openhab.binding.zwave = falseHi,
Thanks for logging settings! I did some testing with the latest cloudbees build. I was able to add a new Thing, called called WALLC-S. So that is nice to start with.
It is recognized with the correct configuration: for four groups A, B, C and D. Three groups are sending scene numbers and the other group is associated with a fibaro dimmer.
The next image shows the group info. It seems that the group info is not shown? Scene sending groups are associated with the ZME_USB1 z-wave stick.
After the device is accepted as a Thing, the following appears:
I am not sure what to expect. I think that there should only one scene activation entry. When I push the different switches on the WALLC-S, both the scene activation numbers are changing simultaneously.
All scenes of the three groups are reported.
The dimmer configuration seems to be correct. However it is not updated when I push the buttons. In the log some error warning is shown:
Now I am totally lost… how did you get to the point that node15 is recognized as a WALLC-S?
Did you do a manual wake-up of the WALLC?
Hope you can also provide the zwave.log files, to see where difference are…
@dries_dokter: Sorry for a short hijack of this thread: When I use your commands to get a separate zwave.log, I indeed will get an own log, but (nearly) all zwave commands are also still logged in the openhab.cfg. Can you confirm this?
Until now I only have made a restart of the openhab service. Maybe I need a full reboot?
Solution: take a look here:
2 Likes
That did the trick! Thanks netmask guy! 
… 
[quote=“jeroenvdwaal, post:48, topic:14113, full:true”]
Hi,
Thanks for logging settings! I did some testing with the latest cloudbees build.[/quote]
Please note that Chris would want a DEBUG log, not an INFO log… (Changed that in my original reply too )
Hi dries_dokter,
The device was recognized after a manual wake-up. First as an unknown device. After the wake-up it became a WALLC-S. Tomorrow I will repeat the test and provide a zwave log file.
Thanks for that Jeroen!
Did it change from unknown to known immediately? At my end this only works if I remove the Thing and re-discover…
I hate to say it, but it’s topics like this that make me wary of trying zwave rather than just simple Wi-Fi devices that have always just worked for me.
I wonder what actual proportion of zwave installs are so problematic? I’d this just a rare case, or is it just really hit and miss? I’ve never once had problems with wemo or wireless tag devices.
I think it is either: me doing something wrong / something not quite as it should be in OH2 / both at the same time. Nothing to do with the principle of zwave.
Looking at how things work in OH1.8 (without any problems, repeatable) I gladly recommend zwave devices to anyone.
Looking at how things could work in OH2: it looks even better than OH1.8… Great thing about zwave: you have all these devices from different manufacturers that all use the same protocol…
But then again, the great thing about OH is: you can pick whatever you want and integrate it to your system… 
1 Like
So, I think the problem is still what I said earlier - when the NIF is received, the binding treats this as a wakeup and sends the request to set the parameter. I don’t think that the device is really awake at this stage, so it isn’t received. In OH1, when the WAKEUP is received, the binding retries the message immediately and we get a response, but in OH2, it doesn’t retry and it times out.
It’s the only difference I can see. In both cases the binding sends exactly the same data, so I don’t think it’s related to what is sent, but more likely, when it is sent.