You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What do you want to achieve? Is your feature request related to a problem?
Looking at the Miele API documentation, it looks like potentially there is a targetTemperature action, which I assume would allow the target set-point to be written to a type=21 device both for either the fridge or freezer?
An example use case why I am looking for this is our house knows from the occupation sensors, when to activate security lighting at lower levels, turn down heating in the building / activate security measures, etc.... It knows we are out for more than a day we are away, so it would make sense for it to turn the freezer to a more economical setting such as -18 rather than the -22 we run it at. If I have read the documentation correctly, then the implementation of the target_setpoints for each setpoint as a writable point, would facilitate it using these actions?
I am assuming hopefully not incorrectly that this is available, as the Miele app implements this (and you would have hoped for cost purposes and maintainability that it uses the same API).
It would make sense if implemented that setpoint's against freezers are protected against going above -18 in temperature and not lower than -30, just to protect the end devices.
A sensible range could be applied to the fridges as well, 3 to 7 say within the bindings code, prior to transmitting the request.
I was trying to locate the source code to have a look, and submit a possible adjustment after testing, but Im guessing this is closed source at the moment, hence a new feature request 🤞
The text was updated successfully, but these errors were encountered:
I was trying to locate the source code to have a look, and submit a possible adjustment after testing, but Im guessing this is closed source at the moment, hence a new feature request
The code is open sourced here. We are currently in the review process of getting the binding integrated into openHAB, the PR can be found here. Once the openHAB maintainers merged the PR we are happy about further contributions from the community. You can also have a look at the forum thread where we usually post updates.
Apart from that, we will check your feature request some time next year because we are all vacationing at the moment, I just had to make clear that the code is open-source 😉
What do you want to achieve? Is your feature request related to a problem?
Looking at the Miele API documentation, it looks like potentially there is a targetTemperature action, which I assume would allow the target set-point to be written to a type=21 device both for either the fridge or freezer?
An example use case why I am looking for this is our house knows from the occupation sensors, when to activate security lighting at lower levels, turn down heating in the building / activate security measures, etc.... It knows we are out for more than a day we are away, so it would make sense for it to turn the freezer to a more economical setting such as -18 rather than the -22 we run it at. If I have read the documentation correctly, then the implementation of the target_setpoints for each setpoint as a writable point, would facilitate it using these actions?
I am assuming hopefully not incorrectly that this is available, as the Miele app implements this (and you would have hoped for cost purposes and maintainability that it uses the same API).
It would make sense if implemented that setpoint's against freezers are protected against going above -18 in temperature and not lower than -30, just to protect the end devices.
A sensible range could be applied to the fridges as well, 3 to 7 say within the bindings code, prior to transmitting the request.
I was trying to locate the source code to have a look, and submit a possible adjustment after testing, but Im guessing this is closed source at the moment, hence a new feature request 🤞
The text was updated successfully, but these errors were encountered: