Comments (15)
related to #169
from ramses_cc.
This is teh current test suite, that is passing:
TESTS_SET_ZONE_MODE: dict[str, dict[str, Any]] = {
"00": {"mode": "follow_schedule"},
"01": {"mode": "permanent_override", "setpoint": 18.5},
"02": {"mode": "advanced_override", "setpoint": 19.5},
"03": {"mode": "temporary_override", "setpoint": 20.5, "duration": {"minutes": 90}},
"04": {"mode": "temporary_override", "setpoint": 21.5, "duration": {"hours": 3}},
} # need to add until...
... if there remains an issue, it is in ramses_rf.
from ramses_cc.
Documentation states 'optional'
mode
The permanency of the override. Optional, one of: follow_schedule, advanced_override (until next scheduled setpoint), temporary_override (see: duration and until), or permanent_override (indefinitely).
You add 'mode' it then throws an error about 'until' even with duration set:
duration
The duration of the temporary_override. Mutually exclusive with until. {"minutes": 135}
until
The end of the temporary_override. Mutually exclusive with duration.
from ramses_cc.
Ok, this is the test suite that I'll attempt to get working:
TESTS_SET_ZONE_MODE_GOOD: dict[str, dict[str, Any]] = {
"11": {"mode": "follow_schedule"},
"21": {"mode": "permanent_override", "setpoint": 12.1},
"31": {"mode": "advanced_override", "setpoint": 13.1},
"41": {"mode": "temporary_override", "setpoint": 14.1}, # default duration 1 hour
"52": {"mode": "temporary_override", "setpoint": 15.1, "duration": {"hours": 5}},
"62": {"mode": "temporary_override", "setpoint": 16.1, "until": _UNTIL},
}
TESTS_SET_ZONE_MODE_FAIL: dict[str, dict[str, Any]] = {
"00": {}, # # missing mode
"12": {"mode": "follow_schedule", "setpoint": 11.2}, # # *extra* setpoint
"20": {"mode": "permanent_override"}, # # missing setpoint
"22": {"mode": "permanent_override", "setpoint": 12.2, "duration": {"hours": 5}},
"23": {"mode": "permanent_override", "setpoint": 12.3, "until": _UNTIL},
"29": {"setpoint": 12.9}, # # missing mode
"30": {"mode": "advanced_override"}, # # missing setpoint
"32": {"mode": "advanced_override", "setpoint": 13.2, "duration": {"hours": 5}},
"33": {"mode": "advanced_override", "setpoint": 13.3, "until": _UNTIL},
"40": {"mode": "temporary_override"}, # # missing setpoint
"50": {"mode": "temporary_override", "duration": {"hours": 5}}, # missing setpoint
"59": {"setpoint": 15.9, "duration": {"hours": 5}}, # # missing mode
"60": {"mode": "temporary_override", "until": _UNTIL}, # # missing setpoint
"69": {"setpoint": 16.9, "until": _UNTIL}, # # missing mode
"79": {
"mode": "temporary_override",
"setpoint": 16.9,
"duration": {"hours": 5},
"until": _UNTIL
},
}
from ramses_cc.
It seems a bug in services.yaml
. Not every zone_mode accepts all fields, like follow_schedule
isn't allowed to have any of them. But duration
and until
are declared as required.
To fix the issue change the required state to false on line 290 en 299.
from ramses_cc.
I get a totally different error
Failed to call service ramses_cc/set_zone_mode. value must be one of ['follow_schedule'] for dictionary value @ data['mode']
from ramses_cc.
Please re-open this issue if the bug persists after release 0.41.8 (there are two tracks: 0.31.7 and 0.41.7 - 0.31.x will no longer be maintained).
from ramses_cc.
Upgraded to latest stable (0.31.7.) seems 'mode' which is apparently optional, is not optional.
service: ramses_cc.set_zone_mode
data:
entity_id: climate.living_room
setpoint: 22
duration: {minutes: 60}
This service requires field mode, which must be provided under data:
service: ramses_cc.set_zone_mode
data:
entity_id: climate.living_room
setpoint: 22
duration: {minutes: 60}
mode: temporary_override
This service requires field until, which must be provided under data:
No change from the reported issue, with 0.31.7. Downgrading again to 0.21.4, last 'stable' for me.
from ramses_cc.
Upgraded to latest stable (0.31.7) seems 'mode' which is apparently optional, is not optional.
Version 0.31.11 has been released and it should address this issue. Please let us know if it does not.
No change from the reported issue, with 0.31.7. Downgrading again to 0.21.4, last 'stable' for me.
This is a known bug in 0.31.7.
To be clear - 0.21.4, 0.31.7 and 0.31.11 are all on the 'stable' track, regardless of of being bug-free, or not.
from ramses_cc.
0.31.11 - still same issue. Downgrading to 0.21.4, where the below works:
service: ramses_cc.set_zone_mode
data:
entity_id: climate.living_room
setpoint: 22
duration:
minutes: 60
Mode should be optional (it's currently not) and until should be mutually exclusive with duration (it's currently not)
from ramses_cc.
This is the call I'm using in test/dev:
service: ramses_cc.set_zone_mode
data:
entity_id: climate.01_123456_02
setpoint: 21
duration: {minutes: 60}
... it throws an error: This service requires field mode, which must be provided under data:
But to me, this is obvious that it is mode: temporary_override
.
If we add mode:
, we get:
service: ramses_cc.set_zone_mode
data:
entity_id: climate.01_123456_02
setpoint: 21
mode: temporary_override
duration: {minutes: 60}
... but, it throws an error: This service requires field until, which must be provided under data:
If we use until:
, we get:
service: ramses_cc.set_zone_mode
data:
entity_id: climate.01_123456_02
setpoint: 21
mode: temporary_override
until: "2024-03-16 14:00:00"
... but, it throws an error: This service requires field duration, which must be provided under data:
If we use duration:
and until:
, we get:
service: ramses_cc.set_zone_mode
data:
entity_id: climate.01_123456_02
setpoint: 21
mode: temporary_override
duration: {minutes: 60}
until: "2024-03-16 14:00:00"
... but, it throws an error: Failed to call service ramses_cc.set_zone_mode. extra keys not allowed @ data['duration']. Got None extra keys not allowed @ data['setpoint']. Got None extra keys not allowed @ data['until']. Got None value must be one of [<ZoneMode.SCHEDULE: 'follow_schedule'>] for dictionary value @ data['mode']. Got None
This message should use a str rather than a strEnum.
from ramses_cc.
ok, drama is that this is enforced in two places:
- services.yaml, and
- schemas.py (the voluptuous schemas)
The above code is only testing the latter
from ramses_cc.
This service requires field mode, which must be provided under data:
I'm going to make mode
non-optional. Thus, the above error message is acceptable.
My rationale is as follows. First, it is clear that the mode is:
follow_schedule
if: nosetpoint
temporary_override
if: hasduration
oruntil
But what if it has a setpoint
, and no duration
/until
? You could argue it would be until:
- next scheduled setpoint ->
advanced_override
- indefinitely ->
permanent_override
- for an hour (like a DHW 'boost') ->
temporary_override
Easiest way to resolve the argument, to remove all ambiguity, is to make mode
required.
Similarly, setpoint
is now a required value, if the mode is not follow_schedule
.
I will be doing the same for the set_dhw_mode
service call.
from ramses_cc.
And for DHW, we have:
TESTS_SET_DHW_MODE_GOOD = {
"11": {"mode": "follow_schedule"},
"21": {"mode": "permanent_override", "active": True},
"31": {"mode": "advanced_override", "active": True},
"41": {"mode": "temporary_override", "active": True}, # default duration 1 hour
"52": {"mode": "temporary_override", "active": True, "duration": {"hours": 5}},
"62": {"mode": "temporary_override", "active": True, "until": _UNTIL},
}
TESTS_SET_DHW_MODE_FAIL: dict[str, dict[str, Any]] = {
"00": {}, # # missing mode
"12": {"mode": "follow_schedule", "active": True}, # # *extra* active
"20": {"mode": "permanent_override"}, # # missing active
"22": {"mode": "permanent_override", "active": True, "duration": {"hours": 5}},
"23": {"mode": "permanent_override", "active": True, "until": _UNTIL},
"29": {"active": True}, # # missing mode
"30": {"mode": "advanced_override"}, # # missing active
"32": {"mode": "advanced_override", "active": True, "duration": {"hours": 5}},
"33": {"mode": "advanced_override", "active": True, "until": _UNTIL},
"40": {"mode": "temporary_override"}, # # missing active
"42": {"mode": "temporary_override", "active": False}, # # missing duration
"50": {"mode": "temporary_override", "duration": {"hours": 5}}, # missing active
"59": {"active": True, "duration": {"hours": 5}}, # # missing mode
"60": {"mode": "temporary_override", "until": _UNTIL}, # # missing active
"69": {"active": True, "until": _UNTIL}, # # missing mode
"79": {
"mode": "temporary_override",
"active": True,
"duration": {"hours": 5},
"until": _UNTIL
},
}
NOTE: tests 41/42, and c.f. Zone's 41 - DHW's 41 is what is classically know as a DHW 'boost'
from ramses_cc.
It is currently unclear to me how I test service.yaml (the developer page in the web UI).
from ramses_cc.
Related Issues (20)
- 1 Zone not updating HOT 1
- device type 29 not known to have signature: 0001C826090367FFFF
- Best practice is exactly one gateway HOT 7
- MqttTransport: Calls `_on_connect` multiple times HOT 2
- MqttTransport: Does not close down gracefully HOT 1
- Cant bind to my MVS-15R from orcon
- Entity climate.01:215596 (<class 'custom_components.ramses_cc.climate.RamsesController'>) implements HVACMode(s): heat, off, auto and therefore implicitly supports the turn_on/turn_off methods without setting the proper ClimateEntityFeature. HOT 1
- ramses_rf transmits too many packets per unit time HOT 4
- The integration is not tolerant of temporary issues with the packet source. HOT 8
- 0.31.16 Problem with the serial port: Transport did not initialise HOT 12
- 0.31.16 ramses_cc.get_zone_schedule service failing HOT 2
- Startup hangs with pyserial-asyncio-fast HOT 32
- 0.31.7 known_list does not filter out my next door neighbour's Evohome HOT 11
- [Question] What class to use for dual purpose device? HOT 2
- Packet log not rotating in config_flow HOT 3
- Warning: Detected that custom integration 'ramses_cc' accesses hass.helpers.storage HOT 1
- Missing sensor for bypass_mode Orchon 22f7
- Detected blocking call to open inside the event loop by custom integration 'ramses_cc' HOT 3
- All entities Unknown with Gateway status stuck on Problem HOT 13
- How to fake a Nuaire CO2 Sensor
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ramses_cc.