Adding external device support

[abratchik]

This is to implement FR/Issue #167.

The scope of changes includes adding the configuration of an unused GPIO for digital on/off switch for controlling any external device (in example, external ventilation fan in the boiler room or an alarm buzzer or any other device).

Configuration looks as follows:

The state of the GPIO output is visible on the Dashboard and also in the HA Settings. It can be also managed from the Home Assistant automation thus adding extra option for controlling the boiler room.

The side change was also to refactor the HaHelper class in order to reduce the redundancy in the class methods. This refactoring was done with help of the Github AI Co-Pilot and modifies only binary sensors and switches, however, the same approach can be applied to other components and sensors, thus reducing the code and improving maintainability. Overall recommendation from the Co-Pilot is as follows:

1. Put initialization of repeated doc fields into a method initCommonDocFields()
2. Create generic parameterized helpers for publishing different entities like input fields, binary sensors, switches etc. The specific methods in this case will become simple one-liners. This PR implements parameterized helpers for switches and binary sensors only as this was necessary for the scope of the change.

[Laxilef]

Hi @abratchik,

Thanks for the PR. Although I already expressed my opinion on this idea in the issue #167, here are my thoughts: I think this could be useful if implemented the same way as sensors are implemented: an array of switch configurations rather than a single switch. And, since there is already critically little free memory on the ESP8266, the implementation should be only for the ESP32.

[abratchik]

Hi @Laxilef,

thanks for the comment. Agree that generalization would be nice. I may look into it a bit later. BTW, regarding the memory issues. I looked through the code architecture of the OT gateway and found that there are many places where there is a lot of redundancy and boilerplate code, which may be contributing to the overall memory consumption. What do you think of migrating the whole project to a framework, which could offload secondary tasks and simplify development and support? I'm tinkering with esp8266-react now - looks like a nice light-weight platform for esp providing React support for the frontend and MQTT/OTA/. Another option is Tasmota although I did not explore it yet. Migrating to one of those should be fairly straightforward I guess but you can get much better community support for your project.

[Laxilef]

Tasmota already has the ability to work with opentherm. The esp8266-react library uses ESPAsyncWebServer (asynchronous web server), which will take all the remaining memory on 8266, I've already tried it.

I don't want to make an analogue of tasmota or esphome, these are great projects, but you shouldn't mix everything together. It is more correct to use tasmota/esphome separately to manage powerful loads (ventilation, pumps, etc.) and use scripts in HA.