My web address is this https://brewpi/dashboard/fermentation-dashboard
The IP address on my spark one block says 0.0.0.0
Thanks! 
I’m really new to some of this.
This is the output
{"id": "SystemTime", "nid": 3, "groups": [7], "type": "Ticks", "data": {"millisSinceBoot": 95411754, "secondsSinceEpoch": 1562245644, "avgCommunicationTask": 0.96875, "avgBlocksUpdateTask": 0.96875, "avgDisplayTask": 0.96875, "avgSystemTask": 0.96875}}Ok, thanks. Just milliseconds time there. So the update loop is fast enough, running over 100 times per second.
So I’m still puzzled about your filter updating slower than expected. Did you have it set to 30s in the last test?
Are fridge filtered temp and actual temp from the same sensor/setpoint block?
You have a wall mounted sensor, which has some bulk stainless that will be slow to respond to air temperature. Do you also have a simple 6mm diameter sensor?
For the previous tests the filter was set to 3m.
I just changed it to 30s for the test I’m running now. The graph of which I just posted above (the latest graph was with 30s).
Yes I do have a simple sensor. I can try switching them out. But I have to head out soon so I can switch, run a test and get back to you on that tomorrow. Also, should I set Ti to 10m on the Heat or Cool PID or both?
For the cooler 10m will be too quick. Leave that at 1 or 2 hours.
I still see the fridge actual temp responding much faster than the filtered temp. With the filter at 30s, there should only be a 30s lag.
Just to clarify, fridge actual temp=fridge sensor.
Also, will change both PIDs to Ti = 1h
I have switched the sensors. I will keep it running and see what happens.
Thank you!
Strange. The filtered temp should not lag this much. It seems to be filtered more than 30s.
Are you running firmware version dd905882 (on the spark widget) and have the filter at 30s in the Ferment Fridge Setting??
Thank you for providing the data. I implemented 3 improvements from your test results already.
1 Like
That’s really great to hear. Happy to help with improvements.
I’m yet to check on my tests. Will get back to you when I do. Looking forward to these new fixes to be released. Thank you Elco.
Good morning.
Last night’s test were a bit disappointing. Still the root of the issue seems to be a 15-20 minute lag in the filtered temperature.
I also noticed that the setting for Ti=1h did not get applied to the heat PID. This seems to happen to me often with many other setting changes. I seem to have to change them twice for them to apply and show the change in the UI.
I’m running a new test now with Heat Kp=0.2 (it was 0.5 last night) and Ti=1h.
Here is part of the graph from last night. The power went out at midnight due to a storm and the backup power did not switch over for some reason so that rebooted the Spark. But i got enough time to note observations.
Could also use some clarification why my heat PWM target value and current value are so vastly different. How is ‘current value’ derived?
Here is a new test with Fridge Setting=35C. Clearly showing the time lag issue with the filter.
That current value issue will be fixed in next release.
If you want to try it out, open the .env file and change edge to develop. Then run brewblox-ctl update.
I would change it back later though, because we break develop regularly.
1 Like
Okay cool. Thanks! But I think I’ll let it be for now.
Changing the Kp value to 0.2 seems to help quite a bit so far. Will report more later today.
If you need a Kp of 0.2, it is probably best to get a lower power heater.
Also, change the PWM period to something larger than 10s, because 0.2% of 10 seconds is 0.02 seconds. A larger PWM period will work better, because then a small duty cycle will still be active long enough to spin up the fan.
Can you also give me the output of these two URLs so I can check your filter config?
https://brewpi/spark-one/objects/Ferment%20Fridge%20Setting
https://brewpi/spark-one/objects/Ferment%20Beer%20Setting
I still don’t understand why you would have such a long delay with a 30s filter.
Yes that is a good idea. I’ll look into getting a smaller heater.
More observations: I timed the actuator for the heater with a stop watch and noted that it remains on for about 17-18s when Kp was at 0.5/c and heat actuator PWM duration was 10s. Isn’t this a fault? Shouldn’t the actuator pin remain on only for a max of 10s for 100% duty? Yet I’m seeing long duration on-times even with the duty at much less than 100% (maybe around 30%). How is this so?
Here are the outputs you requested. Just FYI, currently I had disabled control when taking the output. Let me know if it matters and I can run a new test and give you the output when it is running.
Fridge setting: {"id": "Ferment Fridge Setting", "nid": 102, "groups": [0], "type": "SetpointSensorPair", "data": {"settingEnabled": false, "filter": 0, "resetFilter": false, "value[degC]": 27.8125, "filterThreshold[delta_degC]": 5.0, "sensorId<TempSensorInterface>": "Ferment Fridge Sensor", "setting[degC]": null, "valueUnfiltered[degC]": 27.8125, "storedSetting[degC]": 35.0}}
Beer Setting
{"id": "Ferment Beer Setting", "nid": 103, "groups": [0], "type": "SetpointSensorPair", "data": {"filter": 3, "settingEnabled": false, "resetFilter": false, "value[degC]": null, "filterThreshold[delta_degC]": 1.0, "sensorId<TempSensorInterface>": "Ferment Beer Sensor", "setting[degC]": null, "valueUnfiltered[degC]": null, "storedSetting[degC]": 20.0}}
Here’s the graph from last night’s test at Kp=0.2
It seems to be a lot better but still needs tweaking I think. I have no idea why it went idle around 0300h. though. Any idea?
Quick question:
I noticed that the Beer Setting and Beer Sensor Blocks are not connected to the Ferment Profile anymore. How do I set this up if I want to apply a temperature profile on my heated water (for testing) using the beer sensor in the water container and the fridge air temperature as the driver?
I see that you beer setting still has the slower filter.
The profile can drive the fridge setting or beer setting when enabled. I would not do cascaded control with a dynamic fridge setting and setpoint driver yet. Just click the action to switch to beer constant and then enable the profile.
1 Like
Some Observations : I’m noticing some real delays in the system as a whole.
I timed the actuator for the heater with a stop watch and noted that it remains on for about 17-18s when Kp was at 0.5/c and heat actuator PWM duration was 10s. Isn’t this a fault? Shouldn’t the actuator pin remain on only for a max of 10s for 100% duty? Yet I’m seeing long duration on-times even with the duty at much less than 100% (maybe around 30%). This seems strange.
Secondly, I timed the graph UI and it only updates every 20s. Is this normal?
Thirdly I noted the Heat PIN curve in the graph. It has 3 points per cycle as expected, one for zero, then 1 and then back to zero. There are no data points on this curve between the first zero and the on state and then between the on state and the last zero which could mean that the minimum time taken by an update is being represented by the Heat PIN cycle which is about 43 seconds. This seems quite slow to me because the actual stopwatch timer said 20s duration of the actuator on-off cycle but the graph shows that it took 43s. Isn’t the pin actuator just a binary 0 or 1?
I hope this makes sense.
I have a strong feeling that there is an overall slowness in the response time between the spark service and the hardware sensors/actuators and UI.