KegLand Questions and Answers

[clickeral]

Both this one and the one that has 1/2" BSP fittings. Both plate chillers have a threaded post on the bottom/back of them

@KegLand-com-au still no update on what bolts the standoffs on the back of both plate chillers use

 

[razz]

@KegLand-com-au With the website currently stating orders are at a 9 day backlog, does that include pick ups?
Thanks in advance.

 

[curmudgeon]

Your website recently had 3/8" ball lock disconnects, spruiked as good for transfers (no argument there, brilliant) however they seem to have disappeared in favour of The Big Jumper (Closed Transfer Line Kit) which are 5/16" with a duo adapter, not quite the same thing, are you going to stock the new style disconnects with a genuine 3/8" connector?

 

[Ballaratguy]

Yes the 2" Blanking plate and tri-clover clamp comes included with this fermenter.

If you are not opening the lid mid fermentation then dead head space is not really an issue. One of the issues with dead head space is when you open the lid it's hard to evacuate the oxygen out of the head space but if you are not opening the lid then this is not an issue.


We do also have some new dry hop equipment that will arrive soon that will enable you to dry hop more easily without as much oxygen exposure and this might also reduce this issue too.

Hmmmm I’d be very interested in learning more about the dry hopping equipment when you can release those details

 

[Bourkie]

They'd be shooting themselves in the leg if the API was not well documented and published to any interested party. There's no point building a platform and then not letting people use it to create solutions.

I can guarantee that Kegland will not be able to satisfy all the feature requests coming from their users. Having an open platform would allow Kegland to concentrate on the core features while third parties can experiment with all sorts of fancy features. Over time, the most successful third party stuff can be migrated into the core, especially if the API is published under an Open Source license.

Couldn't agree more, which is why I am curious about the roadmap. I have asked a number of times, but it is always glossed over, which is why I am curious. No point moving to a closed platform, where we're solely reliant on KL devs.

 

[Mysticbrewer]

@KegLand-com-au With the website currently stating orders are at a 9 day backlog, does that include pick ups?
Thanks in advance.

Kl has said that Pickups are first priority than express then all other orders in chronological order.

 

[Warwick]

@KegLand-com-au - my wish list please:

- Flow control ball-lock disconnect
- FermZilla Lid with pre-drilled hole for Thermowell
- Omega OYL-071 Lutra Kveik Dried Yeast

 

[KegLand-com-au]

They'd be shooting themselves in the leg if the API was not well documented and published to any interested party. There's no point building a platform and then not letting people use it to create solutions.

I can guarantee that Kegland will not be able to satisfy all the feature requests coming from their users. Having an open platform would allow Kegland to concentrate on the core features while third parties can experiment with all sorts of fancy features. Over time, the most successful third party stuff can be migrated into the core, especially if the API is published under an Open Source license.

We are actively working on the code and on average we have released an updated firmware for the RAPT fermentation chamber once every 6 weeks. The online portal is being updated on a weekly basis also. So given this is the case I am interested to know why you feel so strongly that "we will not be able to satisfy all the feature requests". All feature requests are being evaluated at the moment so please send us your feature requests if you have any.

We will release an API to the public but we are also working on several other RAPT devices that will work in conjunction with each other. As we have several other new items to be released soon that will all work together it would not be wise for us to release an API now and have other people work on code only for us to change the range of API calls a few months later. At some time next year we will have released quite a few other RAPT connected products that will work with each other and the frequency of RAPT device releases will slow down. This will be a good time for us to release an API to the public as you would be able to deal with an environment that is changing less frequently. So in short, yes an API will be made available but it's something that you will have to wait for as several other RAPT physical devices will be finished and released before this happens.

 

[KegLand-com-au]

Kl has said that Pickups are first priority than express then all other orders in chronological order.

Pickups and express orders are still getting processed fairly quickly and generally less than 12hrs (working hours, not during the night time for instance). With that said please wait until you get the email notification that your order is available for pickup before driving down here.

 

[KegLand-com-au]

@KegLand-com-au still no update on what bolts the standoffs on the back of both plate chillers use

Sorry I forgot to get back to you on this one. These are M5 bolts. We have now put a link to the M5 bolts on our website in the descriptoin as you can see below:

https://www.kegland.com.au/chillout-mkiii-30-plate-heat-exchanger.html
Thanks for letting us know about this. Let us know if you need any more information.

 

[peteru]

We are actively working on the code and on average we have released an updated firmware for the RAPT fermentation chamber once every 6 weeks. The online portal is being updated on a weekly basis also.

That makes sense, as these products are still under active development. Based on the customer feedback seen here, it's likely to require a similar sustained level of effort for quite a while, just to polish the features that are expected right now. Every new feature and every newly released product will require additional effort.

So given this is the case I am interested to know why you feel so strongly that "we will not be able to satisfy all the feature requests". All feature requests are being evaluated at the moment so please send us your feature requests if you have any.

I'm basing my assessment on more than three decades of experience developing software, firmware, protocols and APIs and teaching this stuff at the tertiary level. I've seen many different approaches and results ranging from unmitigated failures, through acceptable solutions and even some great success stories. There's no guaranteed recipe for success, but there are certainly some approaches that tend to have higher success rates than others. One of the things I've seen repeatedly is that APIs that are published early and in a forum that encourages vigorous discussion, tend to lead to better final designs. Critical review is vital when it comes to discovering blind spots or "thinkos". In some cases these reviews can encourage redesigns before too much effort is invested heading down the wrong path. Developing consistent, orthogonal APIs with a small footprint is best done when you consider the widest possible scenario of use cases and distil all the requirements to the core basics. When you continue developing an API internally until you consider it final and ready for public release, you run a very real risk that someone will find unexpected weaknesses in the API after you have committed to it. Once that happens, you have very little room to move. You either break compatibility or start cluttering the API with workarounds. On the other hand, when you develop the API in the open you do so with the understanding that the API is evolving, that there will be changes and that developers are active enough to both provide feedback on your changes and keep their own code up to date. At some point during that consultative process you discover that certain parts of the development API are stable enough to officially bless them as a stable release. Because those stable parts of the API have seen (hopefully rigorous) review and have been tested by multiple consumers under differing circumstances, it's very likely that the design is going to be at least adequate.

As to why I don't think you'll be able to satisfy all the feature requests coming from the user base? Very simply, it's not cost effective. There will be people out there that will want something that is esoteric, not considered a core feature and will likely cost a fair bit to develop. As you say, you are "evaluating" the requests, which certainly means a cost/benefit analysis. If the return on investment for a feature is not obvious, it will simply not get done or it will be put on the back burner. There are people, such as myself, who may be willing to sink in a major amount of effort into developing something that "scratches their own itch". The initial commitment to start on that development path usually happens on the spur of the moment. If the initial hurdle to getting involved is too big, nothing ever happens. As a rule of thumb, if a potential developer can't get started in one day/evening, they are very unlikely to become engaged. That typically means having all the documentation and a few working examples ready to download from a publicly accessible location. Any hurdles you put up, such as requiring license or non-disclosure agreements, applying for special keys or accounts or requiring developer reviews and approvals will result in attrition. Put up enough of these barriers and there will be minimal to no uptake.

We will release an API to the public but we are also working on several other RAPT devices that will work in conjunction with each other. As we have several other new items to be released soon that will all work together it would not be wise for us to release an API now and have other people work on code only for us to change the range of API calls a few months later.

See above. You would benefit from early feedback during development so that you can eventually stabilise a good API. There's no need to get the API to the final version behind closed doors. Most developers will understand that an API in development is subject to change and that it is their responsibility to keep up with the changes. It is however important to spend a bit of effort on documenting the changes and the rationale behind making them. This is a good thing as it requires in-depth thinking and justification for changes. Doing so leads to better designs, better documentation and higher quality code.

At some time next year we will have released quite a few other RAPT connected products that will work with each other and the frequency of RAPT device releases will slow down. This will be a good time for us to release an API to the public as you would be able to deal with an environment that is changing less frequently. So in short, yes an API will be made available but it's something that you will have to wait for as several other RAPT physical devices will be finished and released before this happens.

It's great to hear that the roadmap includes a public API. This will no doubt allow others to add value to the RAPT eco-system. Do consider opening up developer access earlier, perhaps as an open beta, so that you can benefit from external input. No matter how much you pay your developers and how good they are, there will be someone out there that will have an idea that they didn't even consider. Of course, there will also be some tyre kickers, but that's OK. Sometimes they ask interesting question that get the core developers thinking along new lines.

please send us your feature requests if you have any.

I'd like to see a feature for controlled natural carbonation in pressure fermenters. In particular, the ability to close a valve once the SG reaches a preset (say within 10% of expected FG) and then have the pressure / temperature regulated to reach a desired level of carbonation. Say, I wanted to get my IIPA to finish at 2.3 volumes CO2, fermenting at 18C, once it reaches 1.022, I want to start building up pressure, take it to 20C for a day or two to clean up, down to 16C over 8 hours, then wait to reach expected FG. Once at FG, hold at 6C and 2.3 CO2 volumes until I'm ready to transfer to serving keg. I'd like the means to monitor the fermenter pressure during this process and to open and close a CO2 pressure valve as required to maintain the desired head pressure at different temperatures. Ideally the algorithm would take into account that there is a considerable amount of time required to re-absorb CO2 into the beer when temperature drops. A simple lookup of temperature vs equilibrium pressure is not sufficient.

Anyway, long post. It would have been better to chat in person over a few pints...

Next time someone from KegLand is in Sydney, please come and chat to brewers from Flat Rock Brew Club over a bunch of beers.

 

[Wolff]

@KegLand-com-au - My Blowtie 2 spunding valve (KL15042) isn't holding pressure. I've disasembled a couple of times, replaced the short length of tubing + disconnects used and it will still slowly release pressure. Do you have any tips to troubleshoot or remedy? Cheers!

 

[mynameisrodney]

@KegLand-com-au - My Blowtie 2 spunding valve (KL15042) isn't holding pressure. I've disasembled a couple of times, replaced the short length of tubing + disconnects used and it will still slowly release pressure. Do you have any tips to troubleshoot or remedy? Cheers!

Put a carb cap on a coke bottle and fill it with CO2. Put your blow-tie on. Submerge the lot in a bucket of water and look where the bubbles are coming out. Once you know where it's leaking from it will be easier to fix.

If there are no bubbles when you do this, check the fermenter itself including post o-ring.

 

[brisie]

Is there a tracking number or shipped notice with freight finders?

 

[RRising]

PSA!!! Anyone wanting a 360 Core mini actuator, they are currently in stock at the moment.

 

[brisie]

Bloody hell my 118L Keg finally turns up and only a ????? could have designed the 4" tri clover 4 Inch Tri-Clover Kegmenter Lid with Ball Lock Posts, Floating Dip tube and PRV the keg is about 1 meter long and the silicon hose is 800mm long leaving a heap of in valuable beer behind.
After I rang the ?????? they offered to give extra long hose to reach the bottom posted on my next order. So I've had to make a new order costing me near $280 just for a piece of silicon! plus some stuff for my ???? to have added on.

Edited by moderator. Content and intention remains the same.

 

[fifis101]

PSA!!! Anyone wanting a 360 Core mini actuator, they are currently in stock at the moment.

I'd love to get one. They seem like the perfect setup but they are very expensive. For the price I'm just going to stick with my elcheapo for the little time I use it. It's just way easier to fill a few PET bottle straight out of the taps. It's pretty rare I take a keg or mini keg anywhere.

 

[RRising]

I'd love to get one. They seem like the perfect setup but they are very expensive. For the price I'm just going to stick with my elcheapo for the little time I use it. It's just way easier to fill a few PET bottle straight out of the taps. It's pretty rare I take a keg or mini keg anywhere.

I know what you mean, i bought one on a whim a year ago and have only used it once or twice, it is a very nice bit of kit though.

 

[fifis101]

I know what you mean, i bought one on a whim a year ago and have only used it once or twice, it is a very nice bit of kit though.

Yeah I'd definitely get one if I were to use it more often. I just think mini kegs are more effort than what they're worth. It's just so quick and easy to fill a few bottles, which can easily fit in any esky or fridge etc.

 

[KegLand-com-au]

That makes sense, as these products are still under active development. Based on the customer feedback seen here, it's likely to require a similar sustained level of effort for quite a while, just to polish the features that are expected right now. Every new feature and every newly released product will require additional effort.



I'm basing my assessment on more than three decades of experience developing software, firmware, protocols and APIs and teaching this stuff at the tertiary level. I've seen many different approaches and results ranging from unmitigated failures, through acceptable solutions and even some great success stories. There's no guaranteed recipe for success, but there are certainly some approaches that tend to have higher success rates than others. One of the things I've seen repeatedly is that APIs that are published early and in a forum that encourages vigorous discussion, tend to lead to better final designs. Critical review is vital when it comes to discovering blind spots or "thinkos". In some cases these reviews can encourage redesigns before too much effort is invested heading down the wrong path. Developing consistent, orthogonal APIs with a small footprint is best done when you consider the widest possible scenario of use cases and distil all the requirements to the core basics. When you continue developing an API internally until you consider it final and ready for public release, you run a very real risk that someone will find unexpected weaknesses in the API after you have committed to it. Once that happens, you have very little room to move. You either break compatibility or start cluttering the API with workarounds. On the other hand, when you develop the API in the open you do so with the understanding that the API is evolving, that there will be changes and that developers are active enough to both provide feedback on your changes and keep their own code up to date. At some point during that consultative process you discover that certain parts of the development API are stable enough to officially bless them as a stable release. Because those stable parts of the API have seen (hopefully rigorous) review and have been tested by multiple consumers under differing circumstances, it's very likely that the design is going to be at least adequate.

As to why I don't think you'll be able to satisfy all the feature requests coming from the user base? Very simply, it's not cost effective. There will be people out there that will want something that is esoteric, not considered a core feature and will likely cost a fair bit to develop. As you say, you are "evaluating" the requests, which certainly means a cost/benefit analysis. If the return on investment for a feature is not obvious, it will simply not get done or it will be put on the back burner. There are people, such as myself, who may be willing to sink in a major amount of effort into developing something that "scratches their own itch". The initial commitment to start on that development path usually happens on the spur of the moment. If the initial hurdle to getting involved is too big, nothing ever happens. As a rule of thumb, if a potential developer can't get started in one day/evening, they are very unlikely to become engaged. That typically means having all the documentation and a few working examples ready to download from a publicly accessible location. Any hurdles you put up, such as requiring license or non-disclosure agreements, applying for special keys or accounts or requiring developer reviews and approvals will result in attrition. Put up enough of these barriers and there will be minimal to no uptake.



See above. You would benefit from early feedback during development so that you can eventually stabilise a good API. There's no need to get the API to the final version behind closed doors. Most developers will understand that an API in development is subject to change and that it is their responsibility to keep up with the changes. It is however important to spend a bit of effort on documenting the changes and the rationale behind making them. This is a good thing as it requires in-depth thinking and justification for changes. Doing so leads to better designs, better documentation and higher quality code.



It's great to hear that the roadmap includes a public API. This will no doubt allow others to add value to the RAPT eco-system. Do consider opening up developer access earlier, perhaps as an open beta, so that you can benefit from external input. No matter how much you pay your developers and how good they are, there will be someone out there that will have an idea that they didn't even consider. Of course, there will also be some tyre kickers, but that's OK. Sometimes they ask interesting question that get the core developers thinking along new lines.



I'd like to see a feature for controlled natural carbonation in pressure fermenters. In particular, the ability to close a valve once the SG reaches a preset (say within 10% of expected FG) and then have the pressure / temperature regulated to reach a desired level of carbonation. Say, I wanted to get my IIPA to finish at 2.3 volumes CO2, fermenting at 18C, once it reaches 1.022, I want to start building up pressure, take it to 20C for a day or two to clean up, down to 16C over 8 hours, then wait to reach expected FG. Once at FG, hold at 6C and 2.3 CO2 volumes until I'm ready to transfer to serving keg. I'd like the means to monitor the fermenter pressure during this process and to open and close a CO2 pressure valve as required to maintain the desired head pressure at different temperatures. Ideally the algorithm would take into account that there is a considerable amount of time required to re-absorb CO2 into the beer when temperature drops. A simple lookup of temperature vs equilibrium pressure is not sufficient.

Anyway, long post. It would have been better to chat in person over a few pints...

Next time someone from KegLand is in Sydney, please come and chat to brewers from Flat Rock Brew Club over a bunch of beers.

Thanks for this feedback. We really appreciate it. Would definitely like to take you up on this offer and a few of us will be up in Sydney next year so we will endevourt to meet you and the Flat Rock Brew Club crew. I am going to discuss the points you have raised in our next internal meeting and see what we come up with.