New variable instead of #define in xdrv_49_pid.ino aka PID controller

[krishy2]

If you plan to use the PID controller with #define PID_SHUTTER enabled, the code will update the shutter in every second. Thus makes all the shutter command unusable.
After a reboot it should make a full close to init it properly. Or any other case a shutter setting is needed to the valve it needs a reflash now.

In my opinion this should be a variable.
#define PID_SHUTTER 1 // Number of the shutter here. Otherwise leave this commented out

If so, 0 could mean no shutter command should be issued, any other int should work as now.

It needs 1 bool variable to hold it and an conditional of that variable is 0 or not.

[Wintespe]

Try to set PidUpdateSecs to 0 and TelePeriod to your requested time.

From the source code:
Specifies the interval time in seconds to execute the pid algorithm.
If PidUpdateSecs = 0 the algorithm is only triggerd each time a new temperature value is received. This time is specified by TELE_PERIOD.
A value of 15 seconds may well be appropriate for a domestic room heating application.

[krishy2]

It is not about how often is the pid running. It is about decoupling from shutter.
Anyway, if PidUpddateSecs=0 Pid should run continuously (=every program cycle).
It is not about a room thermostat, rather a proper PID regulator.

[Wintespe]

Anyway, if PidUpddateSecs=0 Pid should run continuously (=every program cycle).
No, PidUpddateSecs=0 means update within TelePeriod

In
void PIDRun(void)

the shutter is driven. The time for this is specified in TelePeriod.

So that's the PID Algorithm

void PIDShowSensor()

is decoupled from the shutter.

Read along:

#17636

[krishy2]

I do understand how it is working, I went through the code. I’m thinking about how it should work.

In my opinion a decoupling from Shutter would be necessary, which could be achieved with very less effort. Decoupling means not even the teleperiod could effect any output on shutter.
Example: you need to run a calibration on shutter (=3-way valve), for example on init, or any manual need.

PidUpdateSecs: this means the fastest PID could be 1s sampling, so with rule of thumb tau > 10s process could be handled. For a heat mixing app it could be slow. However the sensor could be sent on every change, not just when pid runs and pid could be fed with pidpv on every change.

I’m not thinking about an alternative thermostat, rather a proper process control.

[Wintespe]

In my opinion a decoupling from Shutter would be necessary, which could be achieved with very less effort. Decoupling means not even the teleperiod could effect any output on shutter.
Example: you need to run a calibration on shutter (=3-way valve), for example on init, or any manual need.

A temporary total decoupling is possibly with:

PidAuto

Auto mode 1 or 0 (for manual).This can be used to enable or disable the control (1=enable auto mode, 0=disabled, manual mode). When in manual mode the output is set the value defined for PidManualPower

PidManualPower

Power output when in manual mode or fallback mode if too long elapses between process values.

So you can turn off the controller totally.
Faster times than 1 second, could work, but might make Tasmota sweat.
In this case you have to extend
bool Xdrv49(byte function)

[krishy2]

The controller is turned off, but manual power still commanded to shutter on every teleperiod. Thats why I guessed this solution With #define SHUTTER change to a variable.

[krishy2]

So you can turn off the controller totally. Faster times than 1 second, could work, but might make Tasmota sweat.

That could be a good reason not to make shorter processing time.

[Wintespe]

Just implement your own command. This is not witchcraft. Or use an existing command like

void CmndSetAuto(void)

There you simply evaluate the parameter and control either the original value (0 and 1) or your variable.

[isabido]

I would like to run this PID on a ShellyEM to perform power control. For this you would need to execute the PID as quickly as possible. The ideal would be to at least evaluate the power value at a sample rate between 10 or 20ms.

Would this be possible?

Thanks for your help!

[isabido]

It seems that the update speed of the active power register is more than enough!

[sfromis]

Sampling at network frequency is by far not "needed" for PID control. If you have some process control application with such needs, it is way outside of how Tasmota works, as this is designed for heating purposes, typically room temperature, where every minute would not at all be a low sample rate.

[isabido]

OK, I left a value of 20ms/50hz, as a result of some substantial improvement compared to the 500ms I currently have. Really 50ms or 100ms would be enough of an improvement, I think!

Although from what you tell me, Tasmota due to its philosophy is not designed to work at those sampling speeds. Is there any technical reason or impossibility on the part of the ESP32?

Thanks again for your answer.

[sfromis]

Well you specifically suggested faster than that, "at least evaluate the power value at a sample rate between 10 or 20ms".

The sensor cycle in Tasmota is designed for environmental sensors, typically temperature, humidity, air quality, light level, etc. It supports a lot of different sensors and other drivers, in a framework calling drivers at intervals, to enable reporting of values, and things like thermostat control. Process control needing subsecond control are just very different use cases.

The driver for ADE7953 is for energy monitoring purposes, to follow consumption, not for process control, and does most processing every second. Very different purposes would take a different/adapted driver, and the many other activities in Tasmota would mean trouble to expectations of guaranteed stable and fast response every cycle, which is generally key to process control.

You did not give any hints of what your use case is.

[isabido]

Here I leave you so you can get a better idea of the installation. It is an installation at home to take advantage of the photovoltaic surplus to heat water.

NOTE, the temperature probe that you will see in the diagram is only for INFORMATION, the PID is not controlled by it.

It is about making a zero discharge to the grid, when there is a surplus of 1000W, for example, it is sent to a heating resistance to heat water.

Currently it is working very well, especially when there is no one at home and consumption is very regular, but the moment you start turning on different high-load appliances at home, the PID needs to respond faster, that is where those 500ms stay. somewhat rare.

Actually the balance at the end of the day is practically 0.1kwh discharged. Which is practically perfect.

But this need is more than anything to learn and integrate the PID within the ESP32 itself, which will give more reliability and fewer communication failures that the entire system may have in node-red.

[wjohn007]

I managed a similar task with a pure Tasmota solution without PID. Maybe these ideas will help.
#19095 (comment).
A Balance of about 100Wh/ day is also my experience.

[isabido]

Thanks for sharing your idea! But doing it with a PID is more of a challenge for learning than for practicality.

Actually right now the solution is working in NODE-RED without any major problem, but I had the challenge of integrating everything into a single ESP32 and the PID inside it.

Another idea I had was to use these two sensors connected to the ADCs to calculate the power.

and then use the DAC to control the DIMMER.