Can’t use the linked version. Controller says: Serial Error Port {0} does not exist.
Did you configure the port (in the controller Thing)? You’ll also need to delete and rediscover your zwave Things to use the dev binding. This does not mean exclude/reinclude.
Yes, I have a pine64 so /dev/ttyS2 works in stable / snapshot but not in that dev jar.
Presumably recompiling the same code will result in the same error 
…
Probably, no idea where the problem is or how to resolve it.
Have you restarted? What does dmesg -T | grep tty show? It should show the new port, if it moved. Also, consider setting up some udev rules so that you won’t lose the port again. Of course, that may not be your issue. Which version of OH are you using?
Currently reinstalling whole openhab installation but was running 2.3.0. (and will do again)
dmesg shows:
root@openHABianPine64:/home/openhabian# dmesg -T | grep tty
[Thu Jun 28 00:16:32 2018] Kernel command line: console=tty0 console=ttyS0,115200n8 no_console_suspend earlycon=uart,mmio32,0x01c28000 mac_addr= root=/dev/mmcblk0p2 ro rootwait
[Thu Jun 28 00:16:32 2018] console [tty0] enabled
[Thu Jun 28 00:16:39 2018] uart0: ttyS0 at MMIO 0x1c28000 (irq = 32) is a SUNXI
[Thu Jun 28 00:16:40 2018] console [ttyS0] enabled
[Thu Jun 28 00:16:40 2018] uart1: ttyS1 at MMIO 0x1c28400 (irq = 33) is a SUNXI
[Thu Jun 28 00:16:40 2018] uart2: ttyS2 at MMIO 0x1c28800 (irq = 34) is a SUNXI
[Thu Jun 28 00:16:40 2018] uart3: ttyS3 at MMIO 0x1c28c00 (irq = 35) is a SUNXI
[Thu Jun 28 00:16:40 2018] uart4: ttyS4 at MMIO 0x1c29000 (irq = 36) is a SUNXI
[Thu Jun 28 00:16:45 2018] systemd[1]: Created slice system-serial\x2dgetty.slice.
but that’s not the problem. On the pine64 the serial port is uart2.
Shutdown OH, unplug/replug the stick, and run this again (looks like you have a few USB devices).
It’s not a USB device. Anyway got it up and running, seems like i can’t get the controller to exclude/include with the dev binding at all.
- Turned off the fuse
- Turned it back on
- Set the controller to exclude
- Press 5 times on the switch (monostable)
All well under a minute.
EDIT:
Got it to work after hours of stuggle.
To get the Qubino devices excluded I had to hold the S button for more than 6-seconds even though the manual explicitly tells you not do so on 230V.
I had to manually set the lifeline group to the controller to get it to work though.
This shouldn’t be needed as the new binding should automatically set the lifeline independant of the database. Please provide a debug log of this if possible and I’ll take a look.
I’ll try with a second device before I do anything.
EDIT:
It works without setting association manually. It’s just the ZMNHDD1 exclusion/inclusion process that is mental.
To exclude:
- The manual says to connect the module to power supply (flicked the circuit braker)
- Enabled exclude on controller
- Hold the S-button for over 6 seconds (about ten). The manual says NOT to do this when attached to 230v but it’s the only way I got it to work.
I found the good old open-zwave-control-panel to be helpful here, vary clear if the exclude worked (and very easy to exclude too). Openhab2 exclusion worked as well ofc (when i finally got things right) but it’s kind of hard to tell if the exclusion worked or not.
Include
- Turned off the power (to the z-wave device)
- Enabled inclusion mode
- Switched the power back on.
- Auto inclusion completed.
Where is the exclusion enable button in OpenHAB? To include I simply go to inbox>zwave, but don’t know how to exclude
I use Habmin for anything Zwave. Configuration> Things> select controller> Tools> Show Advanced Settings> Exclude Devices
You can do this through PaerUI> Configuration> Things> select controller> edit> Show More> Exclude Devices
Thanks a lot!!
1 Like
I now have another problem with Fibaro FGD212… Excluded and included multiple times but can’t get the lifeline reporting to work. If i start open-zwave control-panel i can see the events when the switch is triggered. But nothing in the openhab2 log:tail.
It warns about “TODO: Implement Application Update Request Handling of New ID Assigned (64).” though.
EDIT: I have another FGD212 having problems with openhab2. I can see the SwitchMultilevel event in open-zwave-control-panel from both devices.
Tried home assistant and everything works.
I have a DIN DIMMER ZMNHSD1
It does have an off behaviour… when I change the dimming value e.g. from 0 to 70
it will light up to 70% however while dimming up the device reports a value to the controller e.g. 36 and the UI will show now the dimming value is 36 also it actually really went up to 70
… anybody expieriencing this?
It sounds like you’re sending the command, and then the command polling goes out (based on the time set for it) and returns before the dimmer is actually at the value that was originally sent. Do you have a slow fade set? You could confirm with a log, and may be able to remedy this by extending the command poll period. I believe this is only in the development branch.
I also found that one… is that ms ? 1500 = 1,5 s?
I changed it to 300 by coincidence … which would even be faster but that improved the situation a bit… odd
or the 1500 is only displayed but the real default which was set?
Yes - it is in milliseconds.
I don’t understand this point? 1500 is the default. Before this setting was added, the binding used to send the GET request immediately after the SET and this caused problems with some devices.
I can only describe it by my observation as I did not log it.
But I guess for a new device it shows 1500 in habmin but that value is not really set? My experience on default “felt” like it was performing a GET request or Poll instantly as this was exactly the behaviour on the UI.
.