Why is dzvents device lookup using name instead of idx

[waltervl]

IDX is unique for devices. But there is also an IDX for scenes and groups, one for cameras, schedules , hardware gateways etc.

So from dzvents perspective the IDX should work as most commands address as specific group of Domoticz objects (devices, scenes, cameras etc). But again it does not work that way...

[solarboy]

I always use device Id's for the reasons mentioned above.

IDX is unique, the name could not be. If the name is not unique then dzvents gets confused as it does not know what unique IDX to map to the name....

I use IDX in my dzvents scripts but you have to be aware you have to have unique device names too.

IDX is not unique, it is only unique for all devices under a single hardware item.
Also (the reason I started this thread to begin with), dzvents only uses the IDX to look up the device name, which is then used in the script. I learned that the hard way with device having the same name and dzvents not triggering the device I expected.

This is not the case. Each Idx corresponds with a unique device/endpoint regardless of hardware device. A device name however can (but should not) be re-used and not be unique.

[Ragdag]

IDX are not unique over your entire Domoticz, only within a Hardware Device


Domoticz allows duplicate names, but it will break the dzvents scripts.
It would already be great if IDX was a combination of Hardware ID IDX + Device IDX, that way it would almost always be unique in the DB and we could move dzvents to purely look up and work on IDX instead of names.
The problem then is still scenes and switches, we coul maybe prefix a Scene IDX with a 2 and a Switch with a 1 or something

[Kedi]

Would that change not break that a lot of current scripts?
I am in favour of using names in dzVents script. It is more readable that way.

[Ragdag]

Would that change not break that a lot of current scripts?
I am in favour of using names in dzVents script. It is more readable that way.

Yes that could break, but there are ways that we could fix that. Maybe, instead of hardware ID IDX being a number we could do letters that way if sdzvents encounters an didx that is only numbers it is old format, if it encounters AA2354 it is the new format. Or a splitting Characters like "-", so it becomes 1-2354
Just thinking out loud

I understand plain names are more human readable but since Domoticz allows duplicate names that is a sure way to get weird behaviour in dzvents.
You can still then do by name in your script you would just declare

Code: Select all

local DEVICE = {
    WASHING_MACHINE = 2357,
}

[Kedi]

I have over 400 devices in my Domoticz of which over 300 devices are used (some of them with an '$' infront) I hardly every experianced 'duplicate names' Once you know that that problem is there, you can just check with every device that is added.
Your solution of declare devices is just a lot of work for people. I have some 100+ dzVents scripts running.
A perhaps a better way is ask for a warning if you create a duplicate name for a device.
So I don't see any problem that justifies the change(s).

[waltervl]

Indeed, a duplicate device name check would solve this issue. I dont know if the name check has to go over all idx entries, so including Hardware gateways, scenes, groups, camera, timeplans, rooms etc. etc.

[Kedi]

I think such a check takes micro-seconds over a database with 400 devices.
Just a warning (with idx of the duplicate) when the device is created would do the trick.

Code: Select all

SELECT COUNT(*) AS aantal FROM DeviceStatus WHERE Name = 'IngevuldeNaam';

[Ragdag]

Let me revisit my own opening posts here, because after digging into the code I was partly wrong and partly right, and I want to correct the record.

Where I was wrong: I said IDX is only unique within a hardware device. That is not correct. Device idx (DeviceStatus.ID) is a primary key, so it is unique across every device in the whole system, plugins included. Two devices can never share an idx. What I was actually looking at in my screenshot is that Scenes and Groups live in a separate table with their own id sequence, so a device idx and a scene/group idx can be the same number. That is a separate namespace overlap, not two devices sharing an idx. So my "make idx a HardwareID+DeviceIDX composite" idea was solving the wrong problem, and I am dropping it.

Where I was right: dzVents really does end up using the name, not the idx, to act on a device. But it is not the lookup, it is the action. Here is the actual path.

domoticz.devices(3081) returns the correct device by idx. Then .switchOff() throws the idx away. In switch_device.lua:

Code: Select all

function device.switchOff()
    return TimedCommand(domoticz, device.name, 'Off', 'device', device.state)
end

The command is keyed by device.name. That becomes a commandArray entry like ['Slaapkamer Luuk - Nachtlampje'] = 'Off', handed to the C++ side. There it first tries to read the key as a number:

Code: Select all

int deviceNo = atoi(deviceName.c_str());   // a name -> 0
if (deviceNo) { ... schedule by idx ... }  // skipped

Because the key is a name, that idx path is skipped and it falls back to resolving the name in SQL:

Code: Select all

SELECT ID FROM DeviceStatus WHERE (Name == 'Slaapkamer Luuk - Nachtlampje')

and it takes the first matching row. With a duplicate name that first row was my [W] usage sensor (idx 3079), not the switch (idx 3081). That is exactly why I got "sending switch commands for switch type 'sensor' is not supported": idx 3081's switchOff was executed against 3079. So the failure is real, I just had the cause slightly off. It is not idx being non-unique, it is the switch action dispatching by name.

What makes this worse is that it is inconsistent within the same adapter. quietOn()/quietOff() already use idx:

Code: Select all

.../json.htm?type=command&param=udevice&...&idx=' .. device.id

and setpoint uses device.id too. But switchOn, switchOff, dimTo, setLevel, switchSelector, toggleSwitch, open, close and stop all pass device.name.

So, two things that would actually fix this:

1. Make the switch/dim actions in dzVents key by idx instead of name (the C++ side already supports numeric keys). This makes domoticz.devices(idx):switchOff() reliable regardless of duplicate names.
2. waltervl, your duplicate-name warning on create/rename is still worth having as a guard, and it also protects the pure name-based scripts that Kedi and others prefer.

[waltervl]

QuietOn()/quietOff() already use idx: This seems to be a workaround to use the API instead of the standard integration. User Waaren did that when the standard lua/dzvents integration had no function for this. Making things a little bit slower and not completely integrated.

[eightyeight]

Just kicking this "issue" up. I am running into the same annoyance but, while calling the device with its IDX in dzvents.

zigbee2mqtt auto discovery creates multiple devices with the same name, so far no issue. But when calling the switch with

local TapwaterElement = domoticz.devices(1357)

TapwaterElement.switchOn().checkFirst()

I get
Zigbee2MQTT-AutoDiscovery: sending switch commands for switch type 'sensor' is not supported (yet...) (0xa4c1381a4dcaffff_current_zigbee2mqtt/Tapwater Element Sonoff)

Now I've renamed the auto created devices but I really loved IDX being the unique identifier used throughout all my scripts and having the names be just that, names in a GUI.

Was this behavior known and a related design choice or is this something to fix in domoticz/dzvents?

[waltervl]

This was a design choice way back in the lua integration (dzvents is a extension oo the lua integration).
So to change a major change in this integration is needed (not impossible with current AI assistance)

[Ragdag]

I've opened an issue with the offer to build a PR.
https://github.com/domoticz/domoticz/issues/7143