I thought it might be a good idea to add a tag to my data so I could identify past batches in the future. I formatted my data and sent it through node-red-contrib-influxdb without errors. I did a search using the influxdb admin CLI and could see the data including the tag. However, in Grafana my graph lines went blank for the same time period. My singlestat dials were not affected. A sample of the graph is included below. Any clues on why?
No, sorry. I haven't used tags.
I suppose I should ask before I go on. I started this at 8:49 last night but didn't realize until 10:21 that I had forgotten to close the lid on the freezer. I think it should be ok but will defer to your opinion.
The yellow line is the brewbox, blue is bucket and red is power. Arg!
If I am interpreting that correctly it is showing full cool power (actually 5%) but even after you closed the lid the box temperature is only going down slowly, so I think you were right in what you suggested before, that 5% is not enough. Obviously the box temperature needs to be able to get below the setpoint reasonably quickly. Maybe try it at 10%, or even 15.
Ok. Here is the graph for the last trial. total time 36 hours.
Apart from the length of time it takes to get to setpoint it looks pretty stable to me.
Another note about yeast.
Yeast behaves differently in aerobic and anaerobic conditions. When yeast is first pitched it is in an aerobic environment and will multiply. When I pitch a yeast I also aerate the wort/must to promote yeast growth. This gives the yeast the upper hand in the competition with any stray bacteria that may have gotten into the wort/must. When the yeast has used up all the oxygen it begins to consume sugars. All that is to say, a little bit longer to get to set point is not always bad. The warmer temperature also promotes yeast growth and in that condition it's not consuming sugar so no off flavors are generated. The yeast can take 12 to 24 hours to use up all the oxygen.
I agree that 10-20% power is called for but no need to overly rush the process. The main goal is a steady temp at setpoint.
Most yeasts will pitch safely at 70F.
Power set to 15%, lid up, waiting for a reset.
BTW: UK's Nottingham ale yeast is happy from 59F to 72F and along with about 9lbs two row Munich barley with 1/2lb of cara-pils and a pound of light brown sugar, fermenting at 60F makes a really smooth, tasty lawn mower beer. 
Wow, this is a slow process (I mean the thing you are trying to control, not the thread). I think you have the Integral Time at 9999, which I suggested because that is usually something 'large' compared to the process times. However 9999 is less than 3 hours, which is definitely not large for this process, I think the integral may well be causing the overshoot there. Stick it up to 16 hours (57600) for the next run ( that being about half what appears to be the natural oscillation period).
Ok, done. Won't the higher power setting change all that?
Changing the gain should not affect the natural frequency.
The more I know the more I know how little I know.
The natural frequency (the frequency at which it will go unstable if you push the gain up too much) is the frequency at which the phase shift round the loop is 180 degrees, which means that at that frequency what should be negative feedback is actually positive feedback (as it is shifted 180 degrees) so if there is enough gain in the system it will oscillate, and if there is less gain then that is the frequency that it 'rings' at when you hit it or do what you are doing which is starting up from cold (or hot in this case).
The power and temperature seem to be fairly steady so I'm calling it.
The gap in data was cause by my tweeking. I didn't realize I wasn't saving data for over an hour.
Here is the complete cycle.
I lost a sensor so had to reboot which explains the drop in power at the very end.
That looks good. From the point of view of a control engineer it is overly stable, I think you could probably half the PB, is it still at 10? That should bring it in a bit quicker and probably cut the undershoot down. However if you are happy with what you have then that's fine.
Are you going to try and do the same with the heater now? Since the ambient is high at the moment, to do that you could disconnect the wire from the PID to the Range node and instead put an Inject node feeding the Range node, set to once a minute, injecting a numeric of something like 0.7, which looks like it should cool it down a bit below the setpoint. Then wire the output of the PID direct to the heater timeprop node. Change the PID Initial Integral to 0 and Output when Disabled to 0 and with the PID disabled let the box and bucket cool down to 5 or 10 degrees below sp. Then enable the PID and the heater should then control it up to the setpoint against the constant cool input. Bit of a waste of power I know, but other than that you will have to wait till winter to do it, unless you put an aircon unit in the garage to cool it down, but that would be even more wasted power
The PB is still 10 and I do think I'll cut it in half. I would really like to eliminate as much of the undershoot as possible. What about the derivative? Isn't that supposed to dampen the over shoot?
I think I'll wait until colder weather to work on the heater. It will be much easier to deal with temperatures if it's naturally cold.
For the final setup:
The PID, when both heat and cool are desired, will have a single PB, I and D which means the Split Heat/Cool will have to compensate for the differences or a compromise will have to be made between heat and cool parameters. Is that right?
Yes it can, but the PB should be sorted first, if you keep bringing that down to the point at which the process starts to 'ring' rather than just dropping below the setpoint and coming up to it then it might be worth trying some derivative. However, with a sensor that has a resolution of 1/16 C on such a slow process as yours I suspect that it is unlikely that derivative will help much. For example if the temperature is only moving at 0.5 degrees/hour that is only 1 click of resolution every seven minutes. The derivative reacts to rate of change of pv and if it, as far as the algorithm can see, changes only once every 7 minutes there is not much for it to get its teeth into.
