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…
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.
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
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.
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:
@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?
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.
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…
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.
@chris, I understand your analysis. Looking at the log, that indeed appears to be happening…
But how, in your opinion, would I (we) deal with this? What is your proposal on that (if any)?