DNS for Real Devices

[cag014 731]

From what I can see, most devices don’t have serial numbers at all.

Devices of the same type (for example, an Aeon Lab switch) often share the same “dummy” serial numbers, as well as the same type, base type, and other properties.

This raises a question: if you have several devices of the same type, and their data is identical (including endPointId), how do you know which device ID you need to control?

For instance, I have two UBS (Universal Binary Switches by Fibaro). Each one has two temperature sensors and two motion sensors, and when you look at their properties, they appear to be absolutely identical.

 

59 minutes ago, Łukasz997 said:

for VD and child devices field serialNumber is replaced with properties.manufacturer filled with hand assigned SN. 

So, you’re saying I need to remember the manually assigned serial number, while at the same time you claim I don’t have to remember names and rooms?

From my personal experience, I’ve never changed a room name or device name in years…

 

Don’t get me wrong—I truly appreciate your effort to tackle this “ancient” problem, and I look forward to seeing your final solution.👍

[Łukasz997 117]

The devices I own do have serial numbers - in total, over 250 endpoints.

There is no need to remember any numbers.

 

DNSfD does not answer the question: “how do I, as a human, distinguish between two identical UBS devices?”

It answers a question: “how can the system remain stable when device IDs change and their data APPEARS to be identical?”  
Additional idea was to use dynamically created data to avoid big qa variables (I’m trying to move away from this). All of this has already been explained in detail in previous posts in this thread.

 

HC3 has for years pushed us toward bad habits by treating deviceId as only  identity.

This is an attempt - in my opinion quite successful - to decouple the system from fragile device IDs. 

In one form or another, DNSfD should be built into the controller by manufacturer.

[Łukasz997 117]

I have simplified DNSfD usage from the user side down to the bare minimum. All fallbacks related to ID initialization and ID updates after device reinstallation have been moved into the client code. There is now only a single subscription line (the case without VD and chD registration - one more line by one case).

Please login or register to see this code.

In that line, you choose via out = "Dev, G" | "Dev" | "G" whether you want to use global variables and/or local ones, which now take the form self.Dev.variable_name - o.e. hub.getValue(self.Dev.SENSOR, "value"). Additionally, you provide a function (any name) that, after successfully receiving the requested ID values, will start the QuickApp. All rest is done automatically.

 

I cannot make it any simpler.

 

Simplest example. Instead of non-reliable ID we use reliable SSN df7fe2c3. DNSfD returns current ID to our quickapp and logic may continue. ID is assigned to - due to setting "out" - both global test1 and to qa variable self.Dev.test1. Name of the variable is name of the key in 'attach' call.

function QuickApp:go() is called after succesful initial delivery of ID - here we put the quickapp code, like we do in onInit().
When ID changes due to device deletion or hub crash and we add it again under new ID, name, room, whatever - DNS recognizes it as the same physical device and automatically deliver new ID to our quickapp (without necessity of restarting quickapp).

Please login or register to see this attachment.

 

List of all SSNs to easy choose device(s) we need and to include it's SSN in HTClient.attach call:

Please login or register to see this image.

/monthly_2026_01/image.png.923c31ca3c8d554649944614dda02350.png" />

 

And two kind of reports to show current subscriptions (by client and by device):

 

Edited January 19 by Łukasz997

[Łukasz997 117]

This is in reference to the recently discussed topic of Z-Wave 2 -> 3 migration in the new controller firmware. From what I understand, after the migration some devices - not all - receive new ID numbers.

 

I verified as much as possible that DNSfD operates reliably (but the client has undergone 2x complete redesign). Aferr the last firmware update incident it has not surprised me again, so I decided to replace hard-coded device ID references in the remaining QuickApps to DNSfD subscriptions.

Across the system I currently have 121 references to various devices (DNSfD has a counter). I hope that if I perform Z-Wave migration, DNSfD will truly demonstrate its strength. Or - fail... 

 

My earlier assumption that QuickApp code would require only minimal changes due to new "identity abstraction" turned out to be far too optimistic. The problem appears wherever a device ID is used in call to a persistent mechanism inside QA or ID is substituted to other variable. in such cases, when device ID changes updating via DNSfD resolves nothing.

In practice there are two possible approaches: a deeper refactoring of the application or a “sanitary restart” of the QA whenever a subscribed device ID changes. In latest client I added exactly such an option.

The restart does the application state to be lost, but the major benefit is that all used devices are still guaranteed to operate with their current IDs.

[Łukasz997 117]

As I mentioned in earlier posts, DNSfD did not support replacing a physical device by another of identical kind. For example, one device breaks down and is replaced by user with another one, which however must hold different SSN. Clients are subscribed to the old SSN, but that device no longer exists... 
Until now, user have to find references to old SSN in all interested quick apps and change them manually to new.

 

I removed this limitation by introducing the ability to replace devices. Change is introduced once and then populated automatically.

It works like this: with a separate small program, user send the DNS server a list of replacements (editing it directly in file): the SSN of the old device paired with the SSN of the replacement.

The server checks who is subscribed to those (old) SSNs. It loads the code of all subscribers and, wherever it finds a subscription to the old SSN, it replaces it with new one. Then saves modified Quick App. Before saving, the user sees the migration plan, which must be either accepted or rejected. 

From now on, after a device replacement, user no longer has to dig through the code of their Quick Apps (probably many).

 

This modification was made possible by looking into how it was implemented in 

Please login or register to see this link.

 

Otherwise, I would not have known that the controller API treats Quick Apps somewhat like files, and tricks like this are possible.

 

 

Please login or register to see this attachment.