[quote=“gduprey, post:19, topic:185623”]My thinking would be to not “penalize” the non-duplicate, non-troublesome item names. Depending on how someone has maintained their Vera setup, all their names may come out fine, where as having all the device IDs means that someone will very likely want to edit every single item they keep.
I have about 320 out of 1300 item definitions with dups, but most are things I don’t think I care about nor will likely leave an item defined for. Most of the things I actually care about are fine.[/quote]
The latest version will append the various (scoped) "id"s only when a duplicate is detected.
I’m hoping it will fix all of the cases occur in practice but there are some off-beat cases where it won’t so I’ve left in the duplicate-detect-and-print stuff.
I had to install xsltproc on my stripped down ubuntu box, and for the benefit, doing either is a pretty minor additional step.
That’s odd. My default Ubuntu/Linarto on the Odroid C1 had it pre-installed. There must be install variations on Ubuntu 14.04 LTS.
I would expect gawk (being pretty new and updated regularly) is pretty i18l compliant and I'm not doing anything in there that would typically break strings with i18l chars in them.
Well, with the version I have now, it’s all contained in the XSLT. Only duplicate-reporting is done outside, so it could potentially break with non Latin-1 assumptions. To be fair, I’m not even sure that Item names can be anything other than ASCII-7, so it could all be moot anyhow.
As for integrating it all into xslt, that would be great! I am not super up on xslt (I've written a few minor transformations and can follow what you did mostly) and wouldn't quite know how to do duplicate checking and resolution. But I'm all for a one-stop shop style experience and minimal dependencies/files.
Well, there’s a version now. Hopefully it’s better than the last one (at generating unique-ish Item names)… time will tell.
My (so far, one) duplicate name within the same device is my power meter. For reasons that make no sense, the device seem to be publishing a LightSensor (it has no light sensor, so this is bogus) and a generic sensor level (which doesn't seem to match anything reported in the more power-specific items). The items are:
Number DUP_30_Panel1MasterCurrentLevel "Panel 1 Master Current Level [%d]" (GDevices,GRoom1) {mios="unit:nightmare,device:30/service/urn:micasaverde-com:serviceId:GenericSensor1/CurrentLevel"} /** SAMPLE=[48] **/ String DUP_30_1_Panel1MasterCurrentLevel "Panel 1 Master Current Level [%s]" (GDevices,GRoom1) {mios="unit:nightmare,device:30/service/urn:micasaverde-com:serviceId:LightSensor1/CurrentLevel"} /** SAMPLE=[0] **/
I have a few of those myself, where Vera has “added” Thermostat StateVariables to Lights (etc). Fun. Lovely little corruptions like that used to occur frequently in UI4, due to threading/concurrency problems that [ultimately] caused LuaState corruptions.
Thanks for all the help in testing this, and in pushing me to do better!