DNS for Real Devices

[Sankotronic 2,370]

Hi @Łukasz997,

 

I might be wrong since my HC3 is still with just one Fibaro eye included and one Fibaro DW sensor. Everything else are my Quick apps on which I'm working on to decide what approach is the best to have them working.

 

Anyway, it is very difficult to monitor z-wave devices (Zigbee even more) and their replacement since they do not have anything to catch and keep on when replaced, except their type and installation time. What you need to do is use your solution to make database of all devices and where they are used at the first scan. Next scan should check the difference and mark all devices that are not present any more (deleted) and another list that find new devices installed and then offer to users to compare this two lists and connect new installed device with the one removed if was replacement. Does that make any sense?

 

BTW I'm thinking only about z-wave and Zigbee devices since Quick apps can have unique identifier and therefore easily recognized if there is replacemet installed instead of the deleted one. Also, I have a question: why comčicate with generating SSN when that is definitely different for device that replaces the old one? Can you simply explain that to me since I failed to see advantage? maybe it is useful if some static info is used to generate those, like type of device, location (room), and name (not very good since it depends on user input)?

[Łukasz997 117]

Good morning @Sankotronic,

thank you for your valuable contribution to the discussion.
By the way, my idea does not handle the situation in which one physical device is replaced by another unit of the same model. And about Zigbee I only know that there are problems with it in Fibaro, nothing more (I haven't one).

 

If I understand your concept correctly, you are proposing a system that works similarly to classical backup systems (o.e. Veeam in VMware - I have encountered this at work). First a full “disk-to-disk” backup, then a series of incremental backups, and periodically again a full, synthetic backup (obligatory! Cannot base on diffs only). And the tape always stores a full backup.

 

Translating this to our discussion, such a system would have to:

- store the first full state of all devices,

- store the history of all differences between consecutive scans,

- be able to apply all of this together and synthesize the current state,

- provide this information instantly, unlike a backup system, which can afford a long restore procedure.

I assume that a well-implemented system like this could be a stable “source of truth” and indeed would not need immutable fields such as a hardware serial number. But logically the topic is not simple; I am only writing how it seems to me.

 

However, in practice it has several important drawbacks:

- high algorithmic complexity, very high design complexity (proving that it works),

- a very large amount of data by Fibaro standards (the number of fields in JSON),

- difficulty debugging this on a functioning home (my case),

- large memory appetite: the full state + the entire history of differences,

- no possibility to keep this only in RAM - it must be stored persistently, which in Fibaro means gigantic QA variables, very questionable,

- lack of transactional behaviour: if writing such a big structure is interrupted halfway, the system will lose its functional integrity,

- significant CPU load when merging system state.

 

I propose a synthetic serial number, and you propose a synthetic system state. In a sense both approaches are similar… by name.

 

However, DNSfD goes in another direction.

Instead of merging a history of states, it takes a very small subset of fields from the current JSON, computes a synthetic serial number (SSN) from them, and uses it as a “fingerprint” of the device. It does not store what it gets from api.get in full, only a distillate at  1/100 of the original size. This is much simpler, although - as we see - not without drawbacks. The fact that an SSN can be generated uniquely is not a theory, but the result of tests: in my installation (several hundred devices) no SSN duplicate has appeared. The example with productInfo and firmware change showed that some fields must be excluded, however. I removed them from the algorithm and focused on those that are stable across firmware versions and do not depend on the user. I continue testing.

 

A system based on diffs can be built, but it will be complicated, heavy and difficult to maintain. As example of the art of programming - l like it  
DNSfD is lighter, simple and deterministic - provided that we find fields that are simultaneously unique and stable.

Edited December 9, 2025 by Łukasz997

[Łukasz997 117]

By the way: support for child devices is added. This is working for sure, because depends on hand-assigned number. Set of this number - to see what is occupied and to choose free number - is displayed in the app.

 

[Łukasz997 117]

The more I think about @Sankotronic idea, the more interesting it seems to me.
That would be something! Maybe as an alternative to the built-in backup, with integrated some sort of dynamic device re-mapping mechanism and on-demand ID tracking, something along those lines. For a moment I was even tempted to give it a try. But no, it’s too complicated, and who knows if it’s even doable...

[Sankotronic 2,370]

Hi @Łukasz997,

 

Think it more simple. First run will make list of all devices with minimum required data: {device id, type, created date, room ID, isPlugin and parentId} if is child or slave device.

For simplicity and easier looping through the devices table I make it like this:

Please login or register to see this code.

Next run will make another table e.g. second_run_dev that then can be compared with first run and found removed or added devices. From there then next step can be planned if found that there is difference between this two tables. For example, deleted devices data can be then moved to deleted_dev table while new installed to new_devices and then either use some logic to find if new device is replacement for the deleted one, or give user possibility to select deleted and then new installed device and tell system to update.

Note that current_dev table must be updated at the end of action to the current system state while other tables can be emptied to be ready for next check.

 

Sorry, writing this in hurry, but I hope it is clear how I look at this problem. 

[Łukasz997 117]

Reading your reply, I come to the conclusion that both of us are facing exactly the same challenge: finding stable fields that describe a device. I thought you would want to store full structures and, using some algorithm, detect subtle changes that would answer the question: is this the same physical device, or just the same model? But no - you also reduce it to processing a “distillate” of the data.

The difference is that I solve this more simply, turning that distillate into an SSN. You, on the other hand, add a whole layer of snapshots and state comparisons on top of it.

But the underlying problem we are trying to solve is identical. DNSfD has already proven that it does what it is supposed to do. Whether it is now using the right set of fields - we will know soon.

[Sankotronic 2,370]

1 hour ago, Łukasz997 said:

Reading your reply, I come to the conclusion that both of us are facing exactly the same challenge: finding stable fields that describe a device.

That is true. My Yubii HUAS will know how to check and find its components since all Quick Apps will have unique filed(s) and therefore it is easy to find out if any of the Quick apps are deleted, replaced or installed.

 

Completely different situation is with physical devices and Quick apps done by other users. I do not see how system can find out if new installed device is replacement for the old one, except that user is involved. Also, I have question for you: how you find what physical device is used by e.g. quick app or scene? I mean, finally, I guess it is goal to automate correcting scenes and quick apps if device they used is deleted and another one installed.

[Łukasz997 117]

1 godzinę temu, Sankotronic napisał:

Completely different situation is with physical devices and Quick apps done by other users. I do not see how system can find out if new installed device is replacement for the old one, except that user is involved. Also, I have question for you: how you find what physical device is used by e.g. quick app or scene? I mean, finally, I guess it is goal to automate correcting scenes and quick apps if device they used is deleted and another one installed.

If a real physical replacement of the device takes place - this is not a DNSfD problem, because such a situation always requires a user decision anyway. The SSN of the new unit will not match the old one - and this is the correct behaviour. DNSfD does not work with scenes, only with QuickApps (a limitation of Fibaro). 

 

How DNS "knows"?

In the case of physical devices, DNSfD does not try to detect where references to specific devices were used. This is not needed. It is the QA subscribes to DNSfD which devices it uses - this is literally a single line of code. The subscription does three things: initializes QA variables at startup, blocks the QA from starting if the data has not arrived (the QA will not start with var = nil), automatically delivers new IDs when they change.

 

The user defines only 3 simple functions. And that is all - the rest happens completely automatically, via system events and callbacks. After inint - QA continues to refer to devices using their ID in the usual way. So the modifications to the QA code exist, but they are minimal.

If a device was removed and added again → the SSN stays the same → DNSfD knows it is the same unit. If it is a different physical unit → the SSN will be different → for DNSfD it is a new device.

A QA does not store an ID like “123”, but asks DNS: “give me the ID of the device with SSN xyz”. And DNSfD keeps the mapping SSN → current ID.

 

QA "done by other user" need also one line of code: "please assign a solid serial number for me", and that's all. Rest is done the same way as with the physical device.

 

[Sankotronic 2,370]

Hi @Łukasz997,

 

So, at the end, user's quick app still need modification to work with DNSfD properly as I understand now?

 

Also, as I understand all quick apps needs DNSfD to work properly so can interact with it and get proper ID for the devices they use?

 

9 hours ago, Łukasz997 said:

QA "done by other user" need also one line of code: "please assign a solid serial number for me", and that's all. Rest is done the same way as with the physical device.

 

Almost same here. With my Yubii UHAS, every quick app must have unique string saved to property "model". When UHAS Quick app is started/restarted it will look for other quick apps that it needs to interact with using simple api call. That means if any quick app was reinstalled, after restarting UHAS everything will continue to work as before replacement since new device ID's will be fetched. This is of course valid for both quick apps master and their child devices.

 

For all my Yubii UHAS devices I will provide information needed so that users can add a line of code to their quick apps to find and use them. Information will include unique string and all available actions. I will also provide information how to make user quick app a full member of Yubii UHAS so that, for example, any changes to the system does not require HC3 to be rebooted.

 

It seems that the problem with physical devices is still something to work on. As I see it, users will still have to do some work, but I hope to minimize it as much as possible. I know I can do that for Yubii UHAS devices at least.

 

[Łukasz997 117]

1 godzinę temu, Sankotronic napisał:

So, at the end, user's quick app still need modification to work with DNSfD properly as I understand now?

Also, as I understand all quick apps needs DNSfD to work properly so can interact with it and get proper ID for the devices they use?

Yes, a QuickApp code needs a minimal modification, JSON fields remains unmodified. But DNSfD is not a mandatory system for all QAs. This is client-server model.

I understand that you want to create a product that integrates with the system as easily as possible. I don’t have such assumptions - DNS is for users who have some technical knowledge. Besides, I believe that a fully automatic solution is basically impossible in Fibaro. But - good luck!

 

[Sankotronic 2,370]

53 minutes ago, Łukasz997 said:

Besides, I believe that a fully automatic solution is basically impossible in Fibaro. But - good luck!

Thanks! I still have to learn and test lots of things on HC3 since Fibaro is not good in providing developer information for their product. 

 

1 hour ago, Łukasz997 said:

DNS is for users who have some technical knowledge.

Yubii UHAS is for users without technical knowledge and have no time or no will to learn developing in LUA, but just want add some devices, do some simple setup and have some nice automation to enjoy.

[Christb 33]

On 12/7/2025 at 6:17 PM, Łukasz997 said:

I found a better field to use

Which one?

[Łukasz997 117]

Physical devices:

type

baseType

properties.endPointId

properties.deviceRole

properties.serialNumber

 

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

 

[Łukasz997 117]

For interested: I found that deviceRole is vunerable - because it can be modified in the interface (not in all devices). I will check if it can be simply removed without consequences - it helps to differentiate endpoint devices of one physical hardware...
 

Please login or register to see this image.

/monthly_2025_12/image.png.8029c9327dc27043f51717514b9290da.png" />

[cag014 731]

Just to add a small contribution to this topic:

I am using a JSON devTable (Global Variable) created by QA during initialization, with the following structure: roomName.devName = devID

If a device is re‑included, it’s obvious that you’ll give it the same name as before, and it will be placed in the same room.

If a new device is added (meaning a new name or a new room), it will automatically be added to the table.

So, when I need to use the device in QA or a scene, I simply run:

id=json.decode(hub.getGlobalVariable("devTable"))

 

Then I can use the device, for example:

Please login or register to see this code.

As you can see, I never need to manually change any ID in the code. Even if a new device is added, I still don’t need to know its ID.

 

 

 

 

 

[Sankotronic 2,370]

Hi @cag014,

 

That looks very much like HomeTable that is automatically made and updated. I guess you manage to solve problem with spaces and special characters in the name of rooms and devices?

@petrkl12 made quick app:

 

[cag014 731]

3 hours ago, Sankotronic said:

I guess you manage to solve problem with spaces and special characters in the name of rooms and devices?

Yes, that's correct

Spaces are removed, and underscores are used for special characters.

[Łukasz997 117]

12 godzin temu, cag014 napisał:

Just to add a small contribution to this topic:

I am using a JSON devTable (Global Variable) created by QA during initialization, with the following structure: roomName.devName = devID

DNSfD is immune to changes like room assignment or device name - you do not have to remember those and you can change them freely. Clients will still receive the correct IDs. This solution really shows its power, for example in the case of a serious system failure and rebuilding it on the same hardware (I have personally been in a situation where a Z-Wave migration from 3 to 2 was necessary).

 

However, it is sensitive to the fact of physically a different device. If you replace a broken Smart Implant with a new one, DNSfD will not treat this as a "swap", but as a completely new piece of hardware. In that case, clients will lose their subscriptions (because old SSN is no longer present) and a new SSN will appear in the system. So, in the clients subscription parameters need to be changed to new SSN.

 

That is why, with topics like these, being aware of the rules is so important.

[cag014 731]

But what "property" you are using to identify the device? 

 

 

[Łukasz997 117]

Its mentioned few messages before. I remove deviceRole as its not safe. those data is taken to compute synthetic serial number (like CRC)  and used as a virtual fingerprint of any qa, child process and most of the physical devices. 
To make it clear I recommend to read all this thread… 

 

W dniu 10.12.2025 o 16:00, Łukasz997 napisał:

Physical devices:

type

baseType

properties.endPointId

properties.deviceRole

properties.serialNumber

 

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