Open Hapattaja opened 8 months ago
Sounds good! I’m using native api instead of mqtt and I had to modify the code a little for that reason. Now it’s harder to import upstream changes. Splicing it up would make it easier, I assume. I also welcome getting the logic out of the main config!
I suggest a small refactoring, where the actual critical logic of MitsuRunner would be separated from the configuration of a device and other configurations not directly related to MitsuRunner. The goal is that you wouldn't have to touch MitsuRunner's files at all.
This would make it possible to change MitsuRunner logic/version by only changing the include definition in device's main configuration yaml or replacing MitsuRunner's files. This makes it also more safe to update a new version of MitsuRunner.
(Of course the final solution is to create an external component, but implementing needs more work and I think it could be done later.)
I think that MitsuRunner relies on DS18B20 sensors, so it would be wise to configure them in mitsurunner.yaml. Additional sensor filters (calibration etc.) can be added by extending existing sensor definition. But for example MQTT configuration should not be a part of MitsuRunner although MitsuRunner currently requires it without changing the code.
Sensor names and ids could be substitutional also, maybe with some kind of prefix so if there will be more sensors in the future, the sensors would be named automatically consistently. There are some different approaches and needs some thinking to get it "right".
(https://esphome.io/guides/configuration-types.html#packages-as-templates)
If you like this kind of approach, please let me know. I could do a working draft with minimal changes to the current code.
Folder structure example
Main device configuration (tarkkala-main-heatpump-monitor.yaml) example
Sensor calibration example, other settings are still in mitsurunner.yaml
./packages/mitsurunner/mitsutunner.yaml