Ah, got you. No, nothing “new” to expect as this is just an informational note. If that note is there, it simply said a DDF exists and is used (“is used” in my humble interpretation).
So effectively what you are saying is that “someone” made an “empty” DDF for the STARKVIND completely without any useful functionality? 
No, I’m absolutely not saying what you express in your statement. Where did I say anything like that? My comment is very clear what the marked part of your screenshot means.
It was not a statement, but a question. I do understand that the marked part of my screenshot means that there now is a DDF for the STARKVIND. What I don’t understand is what purpose it serves?
It means there is a DDF, full stop. It is a piece of information, added with the 2.25.1 release. With that, the question is perfectly answered in my view.
Excellent! So we both agree that there is a DDF.
Now, let’s move on - what does this DDF offer that I didn’t have before it came along?
You mean before that informational note was added? Nothing more, nothing less. The DDF hasn’t been modified since about the time you wrote your summary up above.
No, I don’t mean that. I mean before there even was a DDF at all for the STARKVIND.
Let’s narrow it down even further; What does this DDF offer?
As far as i can see, the starkvind always has been supported by DDF and not by legacy code:
https://github.com/dresden-elektronik/deconz-rest-plugin/pulls?q=starkvind
Thanks @Mimiix for breaking the loop 
I don’t have a problem with my STARKVIND, quite the contrary - I’m very happy with it.
I’m just trying to understand this DDF thing.
Assuming you are correct (you usually are), does it mean that that fact that I was able to find and retrieve all the STARKVIND parameters through the REST API, was because there was a DDF there all the time (although I didn’t know it) ?
The DDF(Device Descriptor File) is basically the device support. Without it, you can’t use it.
So yes to this:
Interesting… So how come I have a lot of nodes without the DDF “tag” (which I then assume means they don’t have a DDF?), but they all work just fine! Their entities shows up in HA - contrary to what’s the case for the STARKVIND, which do have a DDF, but still is almost invisible to HA.
I must have misunderstood this DDF thing. I thought the main purpose of a DDF was to expose a device with all its whistles and bells - first of all in Phoscon, and then onwards. But that the availability through the REST-API was just an added bonus. After all, most end users have no clue how to use a REST-API.
Does this mean that it isn’t possible to foresee a solution whereby all the entities of the STARKVIND is automatically exposed in HA upon pairing?
Because those are either supported by legacy code or because their bulbs and using ZCL(@Swoop please confirm or deny this. Not sure).
That being said, DDF is replacing legacy code.
So, if DDF’s are replacing legacy code, then surely a correctly created DDF should/must be able to expose all entities of a device? - not just through the REST API, but directly, in an end-user friendly way as we are used to and expect?
I have to say I find it very irritating that we’re running in such circles, as about 80% of the answers you presumably seek are here in this thread. It references the device support request, which you seem to have discovered as well. People are creating some DDFs and sharing it here to make the device usable, also giving an overview what device capabilities a device exposes, and the Pull Requests are available in Github as well. And Mimix is giving you the same answers than I do.
Regardless, a few things to grep up here:
Because those are either supported by legacy code or because their bulbs and using ZCL(@Swoop please confirm or deny this. Not sure).
There is no distinction. The legacy code was designed to pretty much work with all light bulbs, at least in a basic way. This is also the reason why lights typically just work and do not have a mandatory requirement for a DDF. And yes, one main reason for a DDF is to get rid of (parts of) the legacy code.
[…] a correctly created DDF should/must be able to expose all entities of a device?
Simplified yes (and phrase it as conjuctive). Not sure what you mean with entities, better say capabilities.
[…] After all, most end users have no clue how to use a REST-API […]
Right, as the REST API clients like Phoscon or HA do that via a visually more appealing presentation layer, but they do not support all API capabilities.
Just out of curiosity, have you searched for some info around DDFs and the REST API? What was the outcome? Suggestions on how to make that more prominent or understandable are welcome.
1 Like