yes, it worked with the WALLCS wall mount, but that sends a command to turn the Switch ON/OFF (sendCommand(LV_switch1,ON)).
I will update to 2.5.0.M1, see if that helps, i don’t know what you mean with association configuration.
Updating didn’t change anything either, its weird, because the dim level isn’t reported to openhab, but when i turn the light off and on in openhab, it does update to the dim level i set with the wall switch.
thanks, did that, didn’t change anything.
Well, i don’t know what to do anymore, i updated zulu to latest version, openhab to snapshot version #1566, set all zwave devices lifeline to Controller, even reinclude the devices to the controller, but that didn’t work either.
Still when i physically turn on the light, openhab doesn’t recieve the dimmer1 on/off status and dimmer1 level, if i turn it one with openhab it does.
same thing happens with some fibaro wall plugs i got, they don’t recieve the on/off status on the switch_binary channel, only until a rule or i turn them on/off in openhab.
So, any ideas what i can do?
Have you checked the logs to see what is happening?
As already described, the reporting is linked to associations. The latest binding has code to try and prevent accidental removal of the required associations - maybe there is a bug somewhere, or maybe the initialisation failed, or maybe something else. It’s really hard to say without your view from the logs, so I would strongly suggest to check what is happening there.
Look for the associations being set, or removed. If you find an error with this, please report and I’ll take a look.
ill do that, have set my custom zwave logging to debug and see what happens, or post it here.
Ok, its suddenly started working, but the weird thing is im not getting any power usage in openhab, so im clueless, and my wall-cs isn’t identified, just shows as node4 unidentified.
Have to go to work, will check tommorrow.
Hi Chris,
I have a Door Sensor 2 which was setup near the Controller without issue. Prior to the nightly heal, I moved it to its new location which is on the otherside of the house.
After the nightly heal, its still showing it in the old location and is not repeating through the nodes it should be (as the nodes its currently showing its connected to in the Zwave Habmin Map are milllleesss away from where it currently is.
What is required to have the unit update the nodes it routes through/neighbors? Im hoping once thats done it will function correctly
Cheers
Did you change anything? I have one device that is doing the same manual changes not in OH, software ones work fine. I had this before @chris did his magic and it fixed all of my other ones, just not this zipato device.
No, only what i did above, it works now, only the power usage are not updating correctly, the wallcs works aswell, i just send a wake up from the wallcs and openhab picked it up fine after.
I’m having trouble including devices on the latest snapshot build 1566/1567. Anyone else experiencing this? I’ve gotten some devices to load when searching, but they show offline or are unresponsive after linking to a thing.
I also have a problem with connecting the zwave stick on the USB port:
2019-04-13 14:29:48.886 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
2019-04-13 14:29:48.893 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyACM0
2019-04-13 14:29:48.896 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.zwave.handler.ZWaveSerialHandler@107d630': null
java.lang.NullPointerException: null
at org.openhab.binding.zwave.handler.ZWaveSerialHandler.initialize(ZWaveSerialHandler.java:86) ~[?:?]
at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [136:org.openhab.core:2.5.0.201904010543]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [136:org.openhab.core:2.5.0.201904010543]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2019-04-13 14:29:48.933 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'zwave:serial_zstick:512': null
java.lang.NullPointerException: null
at org.openhab.binding.zwave.handler.ZWaveSerialHandler.initialize(ZWaveSerialHandler.java:86) ~[?:?]
at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [136:org.openhab.core:2.5.0.201904010543]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [136:org.openhab.core:2.5.0.201904010543]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
==> /var/log/openhab2/events.log <==
2019-04-13 14:29:48.943 [hingStatusInfoChangedEvent] - 'zwave:serial_zstick:512' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to UNINITIALIZED (HANDLER_INITIALIZING_ERROR
It happens after reboot my Raspberry Pi3b+ Openhab2 snapshot build 1566/1568, didn’t try 1567.
Binding restart :
ssh openhab@localhost -p8101 'bundle:restart org.openhab.binding.zwave'
or whole Openhab2 restart helps:
sudo systemctl restart.openhab2.service
but thid is not a solution. Somebody can help?
Is your whole system running this snapshot, or just the binding is updated?
whole system, came back to 1566 from SD card backup
openHAB 2.5.0~S1566-1 (Build #1566)
227 │ Active │ 80 │ 2.5.0.201904040140 │ ZWave Binding
I will update the binding to avoid this NPE if the port doesn’t exist.
ok, thank you
227 │ Active │ 80 │ 2.5.0.201904040140 │ ZWave Binding
Ultimately the binding still won’t work for you if the port isn’t found - but you won’t have the NPE. We still need to work out why it’s not working. It’s presumably due to the ESH classes that are now being used, but it is working for some, and not others, which makes me think it’s a partial system update issue.
Thank you Chris, I think you’re right, I be waiting for a system update
Hi guys. It’s probably been asked before but I haven’t stumbeled upon it and this thread is huge so please forgive me.
I’m on 2.3 stable and finally I will get some time to upgrade to 2.4 which will be quite time consuming.
I was thinking to facilitate the upgrade by only upgrading the Z-Wave binding prior to upgrading OH. Would that be a good idea or not? If so, should I go for the 2.4 or the 2.5 W-Wave binding? Thanks for any advice.
Nope, you need at least 2.4 stable for recent zwave snapshots. Recommendation is 2.5M1 (Milestone 1)
The zwave database changes fast and 2.4 stable is quite old already (in terms of zwave), so you should go with the latest 2.5 zwave snapshot.
In either case, you need to perform the steps written down here if coming from 2.3:
1 Like