All right, thanks very much. Your xml will help. Mine is built in a door opener, which has a 24 Volts DC supply. First I just want to open the door with a output channel. I was impressed how tiny the device is. Its just as big as a thumb. But if you have a DC power supply, which you can find in almost every device with a controller, the implant sensor is a nice option.
It can work in range of 9-30V, sorry for missinf.
There is mine xml, maybe slightly different from one on cd-jackson. When I short input, I can see it in logs but under OUT channel. But attributes works. I have not tested lifelines.
fgbs222_0_0.xml (20.9 KB)
1 Like
So what’s the status in this?
I’m running 2.5.0~M1-1 and when I try to include the node i get the following warning:
NODE 16: Device discovery could not resolve to a thingType! 010F:0502:1000::5.0
/t
My guess is, that the wrong device information is still not corrected. Like I said I am not able to correct it, cause I have no glue of the device data.
Release 2.5.0M1 is from January … you can not have device released in february in january code …
It is defined only in master so it will get into next Milestone, or you can update to SNAPSHOT version to get it now.
As I said, configuration in Chris’s db does not need to work as you expect, at least I have not defined endpoints in there, attributes are ok though.
That is obvisously a good point.
Since this is my production system I’m somewhat reluctant to run snapshots any idea when next milestone is expected?
It
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.