Add option for auxiliary port

[Sunbuzz]

The main reason I got into this project, was to be able to control my pool circulation pump. I needed a signal from the heatpump when the pool was actually heating, so that I could turn the circulation pump off, the pool circulation pump is about 1kW and I thought it was unnecessary to keep it on 24h a day when the heatpump only heats about 2h a day.

I have this system all set up on a custom forked branch, but I was thinking on making it available to everybody.
The Gateway E32 (which I use) have an auxiliary GPIO port (32) just above the ESP32 chip, and the Gateway S32 has one too (GPIO 22 I think).

I have made it so that you can edit the aux GPIO in the interface, and choose what function it should cater to, thinking others may use this port for something else in the future. I have attached a "pool circulation pump" option with functionality.

If you think this is a good Idea -
I have made a clean branch based on "dev" and I am wondering if you want me to create a pull request.

[proddy]

EMS-ESP is open-source so we welcome any new additions.

The idea of exposing one of the GPIOs in the WebUI is a good idea (we need to vote on what to call it though!) and also having a list of configurable actions like your 'pool circulation pump'. There is already a pin command in EMS-ESP to set any of the ESP's GPIO's to HIGH or LOW. I think Michael uses this to switch external pumps on&off so that could be an additional action to add.

The pump stop delay - is that just a time for switching between on and off?

I would like to see some of the code - is it at https://github.com/Sunbuzz/EMS-ESP32/tree/PumpSwitch ?

@MichaelDvP what do you think?

[Sunbuzz]

The pump delay is how long the circulation should stay on after the heatpump stopped heating the pool.

No, PumpSwitch was a first draft, I'll push the branch now, it's called "ft_aux"
you can find it here: https://github.com/Sunbuzz/EMS-ESP32/tree/ft_aux

[MichaelDvP]

I think Michael uses this to switch external pumps on&off so that could be an additional action to add.

No, this was someone other here. But i have a 3-way-valve for solar heating in the backflow that is now controlled by a tasmota wifi-plug depending on emsesp-values (2 dallas sensors and mixer pump). This is a bit to special for the aux-function.

But for easy configurable actions i like the idea.

[Sunbuzz]

@proddy Did you have any chance to look at the code?

[proddy]

@Sunbuzz not yet, will get it this weekend. I need to finish off some other bugs and changes first

[proddy]

@Sunbuzz I had a look at the code, looks like a solid implementation that's follows the design patterns of EMS-ESP. Perhaps a few minor changes here and there but we can work on those later. One thing worth changing though is the setting "aux_pump_delay" to something generic like "aux_parameter". That way we can extend the Aux functionality to any custom classes which accepts a customizable setting parameter.

So please go ahead and create a PR under the dev branch. Also one for the hpActivity additions which would also be useful to others.

nice work!

[MichaelDvP]

@proddy I think the pump_delay is only for this specific function (see here). For other fuctions a parameter can be renamed and use other value range or value type.
But the aux_parameter brings me to an idea: Adding a generic aux_function with text input of a simple logic function, something like "<shortname> <operator> <value>" e.g. "boiler/wwtemp > 50". What do you think?

@Sunbuzz Have you tested the function? I think that reading the 5BA in boiler does not work. It's a mixer telegram. With read 11 5BA you'll get an answer, but read 8 5BA is maybe empty. Please check this. (That's the way my ems1.0 works, maybe in ems+ this is different).

For all these functions we need a good documentation what the fuction and the parameter do. I think it's not self explaining.

[proddy]

yes, to do this elegantly I was thinking of a plugin type architecture where these aux_functions are simple C++ interfaces in a custom/ folder which is compiled into the binary. The WebUI would request a list of these custom plugins and take an additional parameter and a type (boolean, range, number, string). The condition logic would be hardcoded in the C code. Then in the main code block loop (emsesp:loop()), all the plugins are tested to see if their condition is triggered, and then executes the underlying code.

[Sunbuzz]

@MichaelDvP yes, I have tested it, and it works as supposed.

I noticed a while ago that the boiler keeps a mirror of this telegram in the logs, it is not true for all the telegrams tho, I have found several telegrams in the mixer that is not listed, and they do not have a mirror in the boiler.

But since 5BA is mirrored, I thought using it was a better idea then try to get the value from the mixer class, since I use it in the boiler class.

ems-esp:# read 11 5ba
002+21:40:03.468 N 2: [emsesp] Mixer(0x11) -> Me(0x0B), HpPoolStatus(0x5BA), data: 01 7A 00 06 00
ems-esp:# read 8 5ba
002+21:40:11.280 N 3: [emsesp] Boiler(0x08) -> Me(0x0B), HpPoolStatus(0x5BA), data: 01 7A 00 06 00

[proddy]

@Sunbuzz this is going to be a major new feature if we end up implementing it differently. So could you push the PR to the ft_aux branch instead of dev?

[Sunbuzz]

Sure, I just made a PR agains dev, but I can remove it and make a new one.

[Sunbuzz]

How do we proceed from here?

[proddy]

continue architecting a plugin sub-system where custom functions can be dropped in, as we talked about earlier. The work will be a major change (so not for v3.2) and can be done in this branch. I won't have time just now because I'm working first on the other features.

[glitter-ball]

Could just the hardware hooks go in EMS-ESP and leave all the automation (delays, logic etc.) in the connected system (HA, Domoticz etc.)? I'm assuming most people have the gateway connected to something else which can do all the logic and then keep the gateway implementation really simple. Would that speed delivery and make it more flexible going forward?

If you were really concerned about reliability, you could loop the output of the aux port, or what it's controlling, back into the ADC input (or, better, a binary input) so that, having issued the aux port command, you get feedback to confirm it's happened, as you would in an industrial SCADA system.

[proddy]

having the trigger logic and actions outside EMS-ESP is a better idea and use a home automation system (or node-red). This is why I'm still thinking what to do.

[proddy]

@Sunbuzz in the latest v3.4 we introduced Analog sensors with 3 types (digital read, ADC read and an I/O counter). Could this be extended to your use case? Would we need to add a 'poll frequency' for example?

[proddy]

I was looking through Sunbuzz's code again and it's pretty nifty. There's a new class PoolPump which has its own timers plus he's extended the heatpump entities by adding HpPoolStatus.

@MichaelDvP is this something we should add, following the same design, or could it somehow be merged into our new analogsensor class since it uses a GPIO with a timer.

@Sunbuzz are you still using this?

[MichaelDvP]

Good idea to add this setting as a gpio function in the customization. The pump delay can send via the sensor.offset.
The logic is also connected to boiler, maybe better to leave the poolpump class and call the settings from analogsensors?