Danfoss Ally adding more attributes to REST-API

Hello,

I’m missing some attributes to read and change with the restAPI for the Danfoss Ally thermostat with FW 1.18 to configure them in detail.

Is it possible to add the following to be accessible with the Rest-API?
The most interesting for me are the “Radiator covered” (0x4016), “load balancing” (0x4032, 0x4040, 0x404A) and “adaption run” (0x404C, 0x404D) attributes.


This is a extract of the Danfoss documentation found here:

Hello, I think thoses options are available only using the GUI

That’s why this is a feature request, to ask for support on the rest api :sweat_smile:

1 Like

I‘m not very inexperienced in programming as a hobby and read in the DDF topic.
Just before doing a deeper dive I will ask if it is possible to add the requested features with a DDF file? Is it?

I think not yet.
ATM we can’t use custom parameter, and need to add them in code first like here Add some news field for future DDF (Consumption/power device) by Smanar · Pull Request #5890 · dresden-elektronik/deconz-rest-plugin · GitHub

But more important, DDF can only manage returned request, you can’t write an attribute for exemple, but I think this will be soon, manup is adding this feature for Tuya stuff, a “write” stuff for DDF DDF support Tuya manufacturer specific cluster by manup · Pull Request #5868 · dresden-elektronik/deconz-rest-plugin · GitHub

I just saw the pull request added to GitHub about this topic.
In the meantime I read more about the implementation of the Load Balancing with more than one ally in one room.
To do it right it is also necessary to set Load Radiator Room Mean. So this also needs to be added to the REST API.

On the past days I looked again into the DDF topic, but it seems that my request still can‘t be solved with a custom DDF right?
I looked in the DDF editor but didn‘t found the item in the left collumn at all.

It’s better now ^^, as least for RV deconz is able to write and read aditionnal attribute
@BabaIsYou is adding some request too, take a look on this DDF deconz-rest-plugin/th1124zb.json at master · dresden-elektronik/deconz-rest-plugin · GitHub for exemple for “config/externalsensortemp”

But there is a restriction yet, you need to use existing field deconz-rest-plugin/resource.h at master · dresden-elektronik/deconz-rest-plugin · GitHub

Edit:
BTW the “config/externalsensortemp” is not in the code, so if the DDF is working it mean this restriction is removed.

Edit2:
Ok so the restriction is still here, it’s because he is using a patched version with this PR Adding Sinope Thermostat TH11xxZB management of Occupancy specific attribute and Unoccupied heat set point by BabaIsYou · Pull Request #6011 · dresden-elektronik/deconz-rest-plugin · GitHub

The PR #6011 has no link with externalsensortemp, that’s for unoccupiedheatsetpoint and Occupancy specific attrubutes (that I recently updated to reuse an existing config attribute instead of creating a new one for Local_Occupancy because that seems ed to cause some discussion about the proposed name).

config/externalsensortemp is already existing in code https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/generic/items/config_externalsensortemp_item.json and that’s the one I used without patch. Just updating the DDF file to match the specific Stelpro or Sinopé attributes in thermostat.

But you need to have it only in the json file ? Because this field is not present in the c++ code ?

What do you mean by “the field is not present in the c++ code” ? I find it here

Ok, my bad, need to sleep ^^
My search haven’t worked, perhaps a typo.

1 Like

We’re only humans after all ! :wink:

So that means in my case for example for the „load balancing“ there need to be coded a item/function/name/whatever… in the C++ code or the resource.cpp before a custom DDF will work?

Yep exactly, for the moment there is a disscution on field to use or not Current thermostat resource items and proposed candidates · Issue #13 · dresden-elektronik/deconz-rest-plugin-v2 · GitHub

Or if you can “recycle” an exiting one.

THIS was the missing hint!

I now just mapped the device item to a different named item with same datatype available in deconz already.
I can now read the radiator mean load as „state/PM2_5“ through the API.

But looking forward to have a proper integration in the API.

But seriously if you think you have a missing field that can be usefull, purpose it too here Current thermostat resource items and proposed candidates · Issue #13 · dresden-elektronik/deconz-rest-plugin-v2 · GitHub

From manup, the next deconz step is TRV, so can be fastly added.

Did it.