Aeotec Siren won't turn on Topic is solved

[Bostjan]

Hi,

I have an interesting problem I can not explain and solve. I had one Aeotec Siren Gen5 which works fine. Then I purchased another one, but this one will not switch on via Domoticz's device, but will switch on via OZW control panel. If it would be hardware or Z-wave problem then it would work in OZW control panel, but it does. What could be the problem?

Here is the screenshot of the log:

Siren.PNG (7.58 KiB) Viewed 1193 times

[Bostjan]

I figured it out by myself.
Orphaned device from previous Z-Wave node was causing problems as it was having same ID. After deleting it, siren turns on/oof just fine.

This is just another example of existing "gap" between Z-Wave nodes and Domoticz devices and no ability to link/reallocate/delete them together with Z-Wave inclusion/exclusion. There are pending changes to at least simply see which device belong to which node, but would be nice to also have ability to realocate device to different node, ask to delete devices together with node exclusion, etc,...

[lost]

Orphaned device from previous Z-Wave node was causing problems as it was having same ID
(...)
There are pending changes to at least simply see which device belong to which node, but would be nice to also have ability to realocate device to different node, ask to delete devices together with node exclusion, etc,...

Quite strange to get a z-wave node ID reallocated: Controller seems to manage them in it's own firmware (by sigma design) and always increment IDs. So the only way to get one reallocated, as IDs size looks to be a byte, would be to have included some over the size limit (255)?

For node/devices relationship, at least in device page you can filter using a pattern. As device IDs include node ID, this ease managing them a bit. For delete, I agree this may ease things. But deleting device will also delete it's database stores. So you may not be able to use the "replace" function if you change a failed device by the same one, after re-inclusion, to keep useful previous device data. So this may be an useful feature, but only after user consent IMO.

[Bostjan]

Orphaned device from previous Z-Wave node was causing problems as it was having same ID
(...)
There are pending changes to at least simply see which device belong to which node, but would be nice to also have ability to realocate device to different node, ask to delete devices together with node exclusion, etc,...

Quite strange to get a z-wave node ID reallocated: Controller seems to manage them in it's own firmware (by sigma design) and always increment IDs. So the only way to get one reallocated, as IDs size looks to be a byte, would be to have included some over the size limit (255)?

Maybe I wrongly expressed myself - there was no automatic reallocation of Z-Wave nodes. I experienced that as I excluded and included the node by myself.

For node/devices relationship, at least in device page you can filter using a pattern. As device IDs include node ID, this ease managing them a bit. For delete, I agree this may ease things. But deleting device will also delete it's database stores. So you may not be able to use the "replace" function if you change a failed device by the same one, after re-inclusion, to keep useful previous device data. So this may be an useful feature, but only after user consent IMO.

Using filter pattern works almost fine - the problem is that there are cases where it doesn't or it gets clumsy. For example, some specific devices gets their ID not as HEX combination of node/instance/etc. but are converted and written as decimal. In this case two different devices could "easily" get same ID string representation although from different Z-wave nodes.