Sonos: Add Channel for UDN to prevent hardcoding UDNs everywhere

[AfromD]

To have cleaner code, I wish it would be possible to have an item containing the UDN of a zone. I would like to code like this:
sendCommand(SonosFernseher_Add, SonosBadezimmer_UDN.state)
This is more legible, and it prevents the hardcoding of strings into my rules, which might make things more complicated than necessary when I change things or items or hardware.
Currently, I help myself by defining empty items and then populating them by hand (hardcoding, but at least only in one central spot):
String SonosBadezimmer_UDN "UDN"

rule "Populate Sonos UDN items" when System started then SonosWohnzimmer_UDN.postUpdate("RINCON_000E5823463A01400") SonosBadezimmer_UDN.postUpdate("RINCON_000E5810648001400") SonosKinderzimmer_UDN.postUpdate("RINCON_000E5850024001400") SonosSchlafzimmerR_UDN.postUpdate("RINCON_5CAAFD080BC801400") SonosSchlafzimmerL_UDN.postUpdate("RINCON_5CAAFD080C0401400") SonosFernseher_UDN.postUpdate("RINCON_000E58B001FC01400") end

It would be nicer and more robust if the binding could provide me with the UDN. Then I don't have to configure that in multiple places (me in the thing definition and rules, other people probably all over the place)

[maggu2810]

Isn't the UDN already present as a thing property?

[AfromD]

You have to specify the Udn for the thing configuration. Is there a way to reference it in a rule? I didn't find that anywhere. If it is as easy as SonosSchlafzimmer.udn, I didn't see anyone using that thus far.
I am still learning how the objects and structures in OH all work together, so might well be I am just unaware of things.

[lolodomo]

The UDN is already set as thing setting and thing property, that will be strange to add a channel for that.

I will have to check but you can probably use the name you use in the thing UID rather than the UDN in case you have not the default thing UID with UDN.

[AfromD]

According to a forum discussion, thing properties are not available to rules. In that case, it would be no harm to expose a property that is needed for commands in an item I think.

[maggu2810]

In that case we should think about whether properties could be made readable by rules instead of adding channels only because we want to access that information in rules.
Similar to: #1654, #3001

[AfromD]

Or being creative, adjusting all methods that require the UDN to accept a thing as parameter and then figure out the UDN internally.

[lsiepel]

Adding a method overload would be easier to use over UDN strings from users perspective:
sendCommand(SonosFernseher_Add, SonosBadezimmer)

[cweitkamp]

we should think about whether properties could be made readable by rules

I second that idea. It would be a great advantage if we can access the properties of things in rules.

[kaikreuzer]

I agree with @maggu2810 and @cweitkamp. Adding a channel for the UDN doesn't really make any sense, so I'll close this issue.