The documentation is now available from the Z-Wave alliance in the "core stack working group. Z-Wave Alliance Login is required.

https://sdomembers.z-wavealliance.org/wg/CSWG/

It looks like the destination device is out of range. Do you possibly  have a Zniffer trace available?

I have just tested this an I am seeing the same as you.

The reason is that the demo apps are communicating insecurely, even if a DTLS key is specified.

I will file a bug report on this.

Refer to INS14416-15 section 4.3.2.2, regarding zwnet_add_sec2_grant_key:

Note that it is possible to not grant any key and yet to accept S2 bootstrapping, i.e. granted_keys=0 and accept_s2=1.

https://www.silabs.com/documents/public/reference-manuals/INS14416-15-7.15.x.pdf

You can find the instructions in the doxygen documentation included with Z/IP Gateway:

$ cmake -DDISABLE_DTLS=True ..

It is likely not the Z-Ware client but the lower layers that are sending multiple copies of a frame, as an ack is not received by the controller. It would be easier to say for certain if you can share a Zniffer trace showing the behavio

Depending on your usage you may be able to clone the home ID of one controller to another, if the two controllers have been included in the same network at the same time. 

I think a process like:

• controller A includes controller B.
• Controller A does a controller shift to controller B.
• Controller B excludes controller A

Will result in both controller having same home ID.

Also some older controllers relies on hardcode home IDs instead of random home IDs making this kind of issues even easier to trigger.

Depending on your usage you may be able to clone the home ID of one controller to another, if the two controllers have been included in the same network at the same time. 

I think a process like:

• controller A includes controller B.
• Controller A does a controller shift to controller B.
• Controller B excludes controller A

Will result in both controller having same home ID, while none of them knows of the other controller. This is also an issue, as it may trigger duplicate node ID assignments.

Also some older controllers relies on hardcode home IDs instead of random home IDs making this kind of issues even easier to trigger.

Hi, thanks for the update.

First check /tmp/zipgateway.log to see if Z/IP Gateway is running as intended, it will be clear if it is not.

Next try to ping Z/IP Gateway. The default IPv6 is fd00:aaaa::3

For me it looks like this:
 

$ ./gw_discovery 
Scanning for Z/IP gateway ...
Press 'x' to exit ...
	IPv6 Address: xxxx:xxxx:xxxx:0:5405:c6ff:feef:7cd2
	IPv6 Address: fd00:aaaa::5405:c6ff:feef:7cd2
	IPv6 Address: xxxx:xxxx:xxxx::0:ba27:ebff:fe95:2ca4
Binding to host IP:xxxx:xxxx:xxxx::0:5405:c6ff:feef:7cd2, interface index: 3

Received report:1/3 with gw count:0
Binding to host IP:fd00:aaaa::5405:c6ff:feef:7cd2, interface index: 3
Gw discovery received 1 responses

Received report:2/3 with gw count:1

---Gateways found---
(0) fd00:aaaa::3 [unknown]
Press 'x' to exit ...
Binding to host IP:2a00:7660:a0b:0:ba27:ebff:fe95:2ca4, interface index: 3

Received report:3/3 with gw count:0

---Gateways found---
(0) fd00:aaaa::3 [unknown]
Press 'x' to exit ...

When comparing with your setup, it is remarkable that your host does not have any IPv6 addresses, and this may be an indicator that your host either is not accepting router advertisements, or Z/IP Gateway is not running.