The firmware always logs the temperature triggers and ramp-up/ramp-down table the first time through. It looks like this in the ESPHome log for the Venbot:

[19:58:48][I][ventbot:848]: Temperature triggers: Low 60.5, High 85.1
[19:58:48][I][ventbot:849]: There are 8 ramp steps
[19:58:48][I][ventbot:853]: Fans:            Fan 1       2       3       4
[19:58:48][I][ventbot:858]: Fan control:         1       2       3       -
[19:58:48][I][ventbot:862]:   { 0.0,  0.0, {  0.00,   0.00,   0.00,   0.00}}, /* 1*/
[19:58:48][I][ventbot:862]:   { 2.0,  1.0, {  2.00,   0.00,   0.00,   0.00}}, /* 2*/
[19:58:48][I][ventbot:862]:   { 2.0,  1.0, {  2.00,   2.00,   0.00,   0.00}}, /* 3*/
[19:58:48][I][ventbot:862]:   { 2.0,  1.0, {  2.00,   2.00,   2.00,   0.00}}, /* 4*/
[19:58:48][I][ventbot:862]:   { 5.0,  5.0, { 20.00,  20.00,  20.00,  20.00}}, /* 5*/
[19:58:48][I][ventbot:862]:   { 5.0,  5.0, { 40.00,  40.00,   0.40,  40.00}}, /* 6*/
[19:58:48][I][ventbot:862]:   { 5.0,  5.0, { 60.00,  60.00,  60.00,  60.00}}, /* 7*/
[19:58:48][I][ventbot:862]:   { 5.0,  5.0, { 80.00,  80.00,  80.00,  80.00}}, /* 8*/

A while back, I made two changes related to this in the firmware.

• The table gets logged again if one of the Home Assistant service calls is made to the device. I figured that the reason someone is doing that is for troubleshooting or tuning, so a reminder of that info is helpful.
• The activity right after boot-up now includes cycling through ramp-up and ramp-down. Although the same thing can be achieved by pushing the button on the ESP32 through the opening in the case, that turns out to be pretty inconvenient once the Ventbot is installed into a vent cavity. Sure, you could still trigger that from a Home Assistant service call, but it might not be convenient to use your computer far away from the Ventbot you want to observe. Now, you can just cycle the power and you can see (or, more importantly, hear) the full ramp up and down cycles.

These things got me thinking about what else I could do for convenience and customization. That's something I wondered about at the start of the project but never really got to. 

• I am now thinking I will now report some of the configuration items as ESPHome text sensors (or some other mechanism) so they can be conveniently displayed in Home Assistant. 
• It's a step from there to implementing service calls so that Home Assistant can be used to set configuration values. The values in the ESPHome configuration YAML file would just be defaults that service calls could override.
• I can probably use the ESP32 preferences API to store overridden values in flash to persist across reboots, with maybe another service call implemented to restore defaults (by erasing or replacing the values in flash or something).

Another thing I have pondered is how to give someone control over the Ventbot in a particular room without opening the door to misbehavior. We're all friendly family members here, and it's not an issue. I'm just in the habit of thinking about security. The Home Assistant permissions scheme for dashboards would let me create a separate dashboard for each Ventbot and restrict access to that dashboard to some particular user. I could imagine having a tablet with a Home Assistant dashboard for controlling the Ventbot in a room (though I'm not sure I can imagine spending the money for that limited purpose). I'm already using passwords to guard the APIs, and the Home Assistant server (that I control) could know all those passwords. Separate passwords for Ventbot instances guards against someone operating a rogue client for the ESPHome API. I know this is kind of overkill in the average home environment, but I'll feel better if I get time to implement it instead of just wishing I had.