You can take your Milestone version of Z-wave and compile it with updated config. Or you can take only snapshot version of Z-wave binding.
Anyway, SNAPSHOTS are stable enough to run in home, most of the time. And if you find problem you can report it and help … it will be better to report it sooner than to report it after release (if the problem happens only in some special case, it is not very likely to be found and you meet it in Release anyway)
OK,
Uninstalled M1 binding
Put the snapshot jar in addons directory.
Looking in the karaf console it shows up as active.
openhab> bundle:list -s |grep zwave
230 │ Active │ 80 │ 2.5.0.201904131605 │org.openhab.binding.zwave
No zwave functionality after restart.
The following in openhab.log (and yes the same serial port as before with no changes in rights)
2019-04-15 16:23:05.169 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port ‘/dev/ttyAMA0’
2019-04-15 16:23:05.184 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyAMA0
Any suggestions?
/t
In Thing config for your USB controller, in properties, you have to set port to use, I have /dev/ttyAMA0 but also /dev/ttyACM0 which is used. Try to switch it, maybe it got reset when changing version.
The “thing” for the z-wave controller is still there with the proper configuration of serial port, but no connection.
It seems there are others with the same issues regarding the serial port and current snapshot.
My bad 
Changing the access permissions on the serial port made it work with the snapshot. Now I just need to figure out if I need to exclude and include the node in order for the binding to recognize the “Smart Implant”.
/t
Hi,
thank you for adding smart implant to database.
I‘d like to connect out1 and out2 to my garage door up and down). additionally i want to connect a contact sensor to in1 for checking if the door is closed or not.
is this configuration possible?
when in1 or in2 is closed, switch state in oh is not being updated. both are associated with controller. what can i do to solve this?
thank you!
oliver
Fibaro promised (or at least I think they did, otherwise you could just use https://manuals.fibaro.com/binary-sensor/ ) that this will be possible, but mine device, when I close in, it is reported as closed out. Maybe it is just bad configuration in openhab and can be fixed, but for now, it seems that by closing in, you autoclose out.
That shouldnt be the case. The old version was designed like you described thr behavior. The new version, which is the implant, can be switched independed if the in signal is high or low. Inputs are not connected to the outputs. There is something wrong in the xml file
You will need my new version of the definition that is not approved yet and would only be in a snapshot.
I think what you want is possible when we get protection working. Then you set LOCAL to 2 for endpoints 5 and 6. That will disconnect the inputs from the outputs but I am struggling getting this working just now.
I am going to send the logs over to Chris to see if he can see what needs fixing to get protection working.
This all assumes firmware 5.1
note protection is not correct on my current posted version and even if it was it would not work
Separated IN and OUT should be possible by setting parameter 20/21 to higher than 1, at least they have it explained like that in examples.
I’m using the version from 2019-05-04.
Sounds like protection is the feature I’m looking for 
But with the current version, I think, the state of in1 and in2 should also be reported to oh (in1 and in1 are configured as alarm inputs and both are associated with controller)?
my smart inplant has fw 5.1.
In current version:
Output 1 is a binary switch and can be controlled by RF to that channel and also reports back if it is switched
Output 2 is a binary switch and can be controlled by RF to that channel and also reports back if it is switched
Input 1 will report an alarm if it is triggered by closing ( or opening if set that way) and by default will also switch Output 1 (which would trigger your door openers so not useful).
Input 2 will report an alarm if it is triggered by closing ( or opening if set that way) and by default will also switch Output 2 (which would trigger your door openers so not useful).
On my garage doors I am using out1 and out 2 and parameter 156 and 157 to automatically switch off after 1s. This works for my doors as it imitates a press of a button.
When protection is working I was also going to make use of input 1 and 2 as you suggest to report if the door is open or closed.
Will post if there is any change and protection is fixed.
Hi,
I have sent some logs to Chris to see if he can see why protection is not working.
The last changes I need to make are to
Endpoint 7
Notification Type Event Event /State
Parameter
System [0x09]
System hardware failure
with manufacturer proprietary failure code [0x03]
Device Overheat
[0x03]
Endpoint 8-13
Notification Type Event
System [0x09] System hardware failure [0x01]
Can anyone advise what the channels would be to support.
I can’t find by trial and error as the overheat is over 85C.
Robert
Today I received my DHT22 sensor. But I can see no channel for temp and humidity. I also tried to reinclude the device.
Should DHT22 already work with latest z-wave binding?
Thanks,
Oliver
The version that supports that will not be in a release. It should work if you download the version from the database and follow the guide to add to a JAR.
You will need to exclude and include with the sensor attached.
Ok. Thank you!
I will give it a try.
Will it be included in future releases?
I am sure it will be when protection is fixed and it is all reviewed.
Before you try a couple of things to be aware of:
You will see a local protection channel when you use this version but it does not work just now. If you try to change it from 0 unprotected to 2 no action it will not send the data to the device. It will look like it has in the interface but nothing will change on the device
The only other things that may not work are the system notifications for overheat or external sensor failures. The system overheat alarm is 85C so unless you are installing in a very hot place it should not be needed.