dresden-elektronik / deconz-rest-plugin-v2

deCONZ REST-API version 2 development repository.
BSD 3-Clause "New" or "Revised" License
17 stars 0 forks source link

Current thermostat resource items and proposed candidates #13

Open SwoopX opened 2 years ago

SwoopX commented 2 years ago

Currently supported resource items:

State items

Config items

Overview of supported resource items by device

Stelpro smt402ad

Danfoss Ally

Namron 4512737, 4512738

Sinope Th1124zb

Eurotronic Spirit SPZB0001

eCozy thermostat

Proposed candidates

Danfoss Ally and derivatives

Already included in PR 6175

Not yet part of a PR

Bosch Thermostat II

Not yet part of a PR

Smanar commented 2 years ago

state/windowopen Not better to use config/windowsopen ? It's an internal setting, managed by the device, that is enabled or not by the user.

config/locked can make conflict with doorlock, less problem with "childlock"

Some tuya TRV have (at least) 2 heatpoint, one for the day and one for night.

SwoopX commented 2 years ago

state/windowopen Not better to use config/windowsopen ? It's an internal setting, managed by the device, that is enabled or not by the user.

Erm, no? It's a state and cannot be set.

config/locked can make conflict with doorlock, less problem with "childlock"

Thermostats are longer part of the code than door locks. The description was taken from the respective attribute and changing that would be a breaking change to all thermostats using it. Door locks are supposed to use this as well from my perspective.

Some tuya TRV have (at least) 2 heatpoint, one for the day and one for night.

Sorry, I don't know anything about that.

Smanar commented 2 years ago

Erm, no? It's a state and cannot be set.

Arf, ok so it s not same for tuya device, on all of them it's a setting not a return, if it's on it s the device itself that stop the heating according to a delay and a temperature drop.

manup commented 2 years ago

There is also a config/windowopen_set already, the variable is wrongly named RConfigWindowOpen ;)

const char *RConfigWindowOpen = "config/windowopen_set";

Used in https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6054

I have a few questions about the window items:

SwoopX commented 2 years ago

The answer is yes 😄

manup commented 2 years ago

Ok thanks, I start to understand this more :) We should extend/clarify the description for items in the /generic/items JSON files.

I'd suggest we deprecate config/windowopen_set in favor for config/windowopendetectionenabled, imho the name is more descriptive. @Smanar I can add a few lines so that the code supports both in the meantime, like an alias. For the #6054 PR it could use config/windowopendetectionenabled from the beginning.

manup commented 2 years ago

...and perhaps name it config/windowopen_detection_enabled

Kane610 commented 2 years ago

...and perhaps name it config/windowopen_detection_enabled

In pydeconz I named it window_open_detection https://github.com/Kane610/deconz/blob/0b5b0b5cfa5d31ac12f121aee2f99c234ad9c426/pydeconz/models/sensor/thermostat.py#L388

SwoopX commented 2 years ago

...and perhaps name it config/windowopen_detection_enabled

Hm, do we have a naming convention here? 😃 The vast majority is without any underscores.

In pydeconz I named it window_open_detection [...]

I wanted to eliminate any room for interpretation or ambiguity here.

manup commented 2 years ago

Currently we don't but would be nice to have one :) The underscores were introduced for some newer items like for the alarm system config/armed_away_trigger_duration.

Personally I increasingly like the underscore versions better, especially for the long names. On the other hand consistency is important too.. But perhaps moving forward we can vote for a certain style and stick to it.

Smanar commented 2 years ago

I need too state/outdoor_temperature for exemple, the attribute 0x0001.

BabaIsYou commented 2 years ago

Proposed candidates

config/backlight for Sinopé Thermostat #5904

Hencor93 commented 1 year ago

As addition to the proposed candidates for Danfoss Ally and derivates:

config/MountingOrientation - Orientation is the actual direction in which the eTRVis mounted config/HeatAvailable - Heat from heat source is available config/LoadRadiatorRoomMean - Mean radiator load for room calculated by gateway config/SetPointOffset - Offset from the setpoint to adjust over-/underheating config/StartStopAdaptationRun - Control adaption run config/KeypadLockout - Childlock

state/LoadEstimateOnThisRadiator - Reported load from radiator state/HeadSupplyRequest - Heat request from radiator state/AdaptationRunStatus - Status of adaption run

Smanar commented 1 year ago

Childlock is config/locked for me and already in the code, (and using config/lock for doorlock)

Offset from the setpoint to adjust over-/underheating

This one is not config/offset ?

Hencor93 commented 1 year ago

You are totally right. I overlooked them both. Updated my list above for better overview.

Smanar commented 1 year ago

Some one wana make a PR for them ?

I realy need a second heatsetpoint, lot of tuya stuff use a heatpoint classic, and (at least) one more for manu mode or away mode.

9colai commented 9 months ago

I could really use the load balancing feature on my Ally thermostats. I have 2 merged living rooms with 4 radiators. And the radiators tend to work against each other. I'm pretty sure that load balancing would solve that. It's also a standard feature in the Ally hub.

So the following Ally features would be very appreciated: state/loadestimate config/meanloadroom