Closed jensgraef closed 1 year ago
I had an error compiling with the select suggested by @Bascht74 in Issue #7 using lambda, that the writer ist protected...
select:
- platform: template
name: "Warmwasser Betriebsart"
id: warmwasser_betriebsart
entity_category: config
optimistic: true
options:
- Dauerhaft aus (0)
- Dauerhaft ein (1)
- Automatik (2)
initial_option: Automatik (2)
set_action:
- lambda:
auto index = id(warmwasser_betriebsart).index_of(x);
if (index.has_value()) {
uint8_t command[] = {0x0C, 0x0E, (uint8_t)index.value(), 0x65, 0x65, 0x65, 0x65, 0x65};
budoil->writer.enqueueTelegram(command, 8);
}
Moving the writer to the public area in km271.h worked, but is a quick fix in my opinion. There should better be an interface method for sending telegrams for stuff not already integrated as clean methods.
Moving the writer to the public area in km271.h worked, but is a quick fix in my opinion. There should better be an interface method for sending telegrams for stuff not already integrated as clean methods.
This is what I did (until Jens add select entities or a esphome command for that). This way we can at least explore how to set them up. At the end, those calls may not be needed anymore...
It's fine now. Select can be easyly implemented in YAML and select also works without debug trash.
I still think these should be made via the component because right now we cannot check if the command was processed or read the initial select state. My code is just a basic "hack" to get a feeling how powerful select entities could be...
Could you re-open it for @jensgraef ?
Hi @Bascht74 - I fully agree. This is something I'll have a look into next.
In PR #39 I've added a first select entity. @Bascht74 - if you like you can check it on the branch add-select-entities
I think i spotted a bug or at least an edge case. I purposely set ww heating to "on" using the select option. This works fine unless i reflash the ESP. After that the default value "automatic" is set again. So we need something similar to the ww temperature, where the value is set by the actual value stored in the buderus at restart. What do you think?
Hey @qschneider thanks for testing. I planned to do exactly this. But it seems it does not work :) I'll check it.
@qschneider Ah, there has been a confusion. I've only added a select for hc1_operation_mode. There it works as I expected: After a reflash / reboot, the value is fetched from the control unit. Warm water heating is not yet switched to the improved way.
k, thanks. if you find the time, it would be great to have the hc2 select also.
maybe i'll take the time over holidays to give it a try, now that the mayor programming is done.
@jensgraef Because of select entities are available now this issue could be closed. What Do you think?
@Bascht74: I think so, too. We now have two select entities available. I'd suggest we open new issues if a certain select entity is needed and missing. @qschneider is this fine with you, too?
to me it's fine to proceed like you suggested @jensgraef
Currently we have a binary switch to toggle warm water heating between "auto" and "night". This toggle actually supports "auto", "night" and "day".
Replace this switch by an "select" component to allow the full value range.
See https://github.com/the78mole/esphome_components/issues/4#issuecomment-1336187716 for the original suggestion.