Hi,

previous versions of Z/IP Gateway was relying on a datastore that could not exceed 65 kbyte, while recent versions have migrated to an sqlite database. 7.13.2 forward should resolve the issue.

Hi,

In general I must advise against using APIs that are undocumented, as they are considered internal, and thus not supported. For reference documentation refer to INS14416: https://www.silabs.com/documents/public/reference-manuals/INS14416-15-7.15.x.pdf

Regarding polling there is a number constraints, mainly tied to the Z-Wave Plus certification requirements that will restricts the polling frequency to prevent media congestion. this means that in networks with more nodes Z-Ware will be poll each of them less frequently in order to meet these requirements.

Z-Ware will also not poll nodes that transmits status updates themselves, such as any Z-Wave Plus v.2 device, which is required to send true status reporting, and sleeping devices such a notification sensors, that will typically wake up and transmit any status change whenever triggered.

The polling time can be set per interface using zwif_xxx_poll, but as previously stated be careful with the Z-Wave Plus requirements, as polling to frequently may prevent certification.

Hi,

The  two unsolicited destinations are identical in terms of what is forwarded.

Since you are referring to Z-Ware, I want to highlight that inclusion are not started from the same port as is used for the unsolicited destination. This means that in practice you always see the node list forwarded as well.

Hi,

The APIs does a lot more than simply relaying a sequence of commands over the RF interface. In the add node example, it will not only assign a Node ID to the joining node, but it will also make the joining node perform a neighbor discovery, and updated the routing table residing on the controller. This is not something that can be faked through senddata commands.

Regarding COMMAND_CLASS_NETWORK_MANAGEMENT_INCLUSION this is a command that is specifically intended to be used on the IP layer on Z/IP Gateway based hosts, and it will have no effect using it on the serial API interface.

Hi,

Where are you seeing the error?

Are the dtlspsk in zipgateway.cfg and app.cfg matching?

Hi,

Can you explain the use case? A Z-wave device will always have a foreign home ID prior to inclusion, so I'm not sure why you would want to prevent this?

If the device is already included in another network (node ID different from 0), it will not transmit smart start inclusion requests, and it will not matter whether it is on the provisioning list or not.

The basic network information is stored on the stick and will move with the stick to a new host, however any higher level information, such as encryption keys are handled by the host, and will have to be transferred in another manner. The same goes for information that is interview during the inclusion, such as wakeup configuration etc. So the controller will only have the most basic information about the end nodes, which is exposed by the node information frame.

Hi,

The problem is that the beams are alternately occupying the RF media, preventing the slaves from transmitting when a frame has been delivered. 

This is unfortunately the nature of a shared media, and there is no work around for this.

Best regards,

Crilles 

Hi,

1. When a device has been added to the provisioning list, inclusion should start automatically, no further actions required. If the device has been powered for a long time, the smart start inclusion request will be transmitted at a longer interval, causing a delay before the inclusion starts.
2. Z/IP Gateway is not scanning, it is more accurately listening. Having the device in active has no effect, as the DSK is considered unique, hence the state is not changed, unless the application actively does so.

Hi,

could you let me know which platform this was seen on?

Best regards,

Crilles