• Please visit and share your knowledge at our sister communities:
  • If you have not, please join our official Homebrewing Facebook Group!

    Homebrewing Facebook Group

Keg Cop: Keg Monitoring and Control

Homebrew Talk

Help Support Homebrew Talk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
When a PUT is sent to the /api/v1/config/taps/ endpoint, it cycles the received payload through:
  • handleTapPost()
  • handleTapCal()
  • handleSetCalMode()
Since it never outputs any "Processing [%s] (%s) pair" debug, it never received any. What payload are you sending?
 
This is my JS code

const data = {
imperial: true,
taps: [
{
tap: 0,
label: 1,
ppu: 660,
bevname: "Blond Ale",
cap: 18,
remain: 17,
active: 1
},
{
tap: 1,
label: 1,
ppu: 660,
bevname: "Blond Ale",
cap: 18,
remain: 17,
active: 1
},
{
tap: 2,
label: 1,
ppu: 660,
bevname: "Blond Ale",
cap: 18,
remain: 17,
active: 1
}
]
};

const http = new XMLHttpRequest();
http.open('PUT', 'http://kegcop.local/api/v1/config/taps/', true);


// Set content-type
http.setRequestHeader('Content-type', 'application/json');

http.send(data);
When a PUT is sent to the /api/v1/config/taps/ endpoint, it cycles the received payload through:
  • handleTapPost()
  • handleTapCal()
  • handleSetCalMode()
Since it never outputs any "Processing [%s] (%s) pair" debug, it never received any. What payload are you sending?
 
You're over-doing it a little. The API takes one tap at a time. Here is the code I use to generate the payload:

https://github.com/lbussy/keg-cop/b...6e2f3a07382/data_source/settings.js#L603-L630
Ok, so this is your data looks:
data = {
tap: 0,
label: 1,
ppu: 660,
bevname: 'Dima1',
cap: 18,
remain: 13,
taplistioTap: 3,
active: true
};

this is litle different from the documentation
according to documentation there should be imperial (true/false), and no tpalistioTap
anyway, i tried to use the format above and also no result :(
 
Ok, so this is your data looks:
Yes.

this is litle different from the documentation
according to documentation there should be imperial (true/false), and no tpalistioTap
That's for the Tap report (out), not posting data in.

anyway, i tried to use the format above and also no result
Was there any difference in the log? That code is what I am using right now and it works. Are you also adding the secret to the headers?

https://github.com/lbussy/keg-cop/b...6e2f3a07382/data_source/settings.js#L866-L874
 
Yes.


That's for the Tap report (out), not posting data in.


Was there any difference in the log? That code is what I am using right now and it works. Are you also adding the secret to the headers?

https://github.com/lbussy/keg-cop/b...6e2f3a07382/data_source/settings.js#L866-L874
The log is the same as before
I am not using any secret
this is my code now, i am using XMLHttpRequest

// Data that we need to update
const data = {
tap: 1,
label: 1,
ppu: 660,
bevname: "Dima1",
cap: 18,
remain: 13,
taplistioTap: 0,
active: true
};

const http = new XMLHttpRequest();
http.open('PUT', 'http://kegcop.local/api/v1/config/taps/', true);


// Set content-type
http.setRequestHeader('Content-type', 'application/json');

http.send(data);
 
You need to get the secret, and add it to the header as above.

https://github.com/lbussy/keg-cop/b...ceab7c63890783f225092/data/kegcop_pre.js#L395
It's not exactly "secret," it's more to prevent strange things from happening with some security software that randomly does things. Rather than fix it in my environment, I decided to fix it in everyone's.
ok,

i added this line
http.setRequestHeader("X-KegCop-Secret", 'xxx');
when xxx is the secret received from http://kegcop.local/api/v1/info/secret/
this didn't help :(
 
The log should show something now about the secret?
when i getting secret by this command http://kegcop.local/api/v1/info/secret/
i see in the log
2023-05-09T21:55:02Z V: Sending /api/v1/info/secret/.

but when i send put request i see only:
2023-05-09T21:57:17Z V: Processing put to /api/v1/config/taps/.
2023-05-09T21:57:17Z V: Checking handleTapPost.
2023-05-09T21:57:17Z V: Checking handleTapCal.
2023-05-09T21:57:17Z V: Checking handleSetCalMode.
2023-05-09T21:57:17Z V: Clearing any calibration flags before setting new flags. 2023-05-09T21:57:21Z V: KegScreen reporting not enabled, skipping (Temp Report).


i understand that i need to see something like this
handleTapPost(): Processing [tap]:(0) pair.
i see it when i update taps from the web
 
I will have to go through the script and C code to give you an idea. I can say that the JS I provide works - you can copy that code as a starting point.
 
I will have to go through the script and C code to give you an idea. I can say that the JS I provide works - you can copy that code as a starting point.
Ok, thanks!
Can you please point where the "Checking handleTapPost" handler implemented?
I will have to go through the script and C code to give you an idea. I can say that the JS I provide works - you can copy that code as a starting point.
 
Hi,
It happened again
I collected uptime.csv
2023-05-11T08:57:45Z, ESP_RST_SW, START_WARMBOOT, 45714
2023-05-11T11:27:35Z, ESP_RST_SW, START_WARMBOOT, 8968
2023-05-11T13:57:14Z, ESP_RST_SW, START_WARMBOOT, 8968
2023-05-11T15:30:03Z, ESP_RST_PANIC, START_WARMBOOT, 5587
2023-05-11T15:36:29Z, ESP_RST_POWERON, START_COLDBOOT, 330

it happened at 15:30 (all taps reseted to default)
 
Thank you. I am working on a debug version to collect additional information and I should have that available in a few hours.
Thanks
Aditional information that can help (hopefully)
I didnt succed to reproduce the issue when connected to laptop in debug mode. (Tried few hours)
Looks like issue happened on time of pouring beer
 
But the console log on Alpha 6 makes it look like it's not making the connection:
Dan I found something that leads me to believe the fix I intended to be in .6 did not make it. This specifically prevents connecting to MQTT by name. If I am right, your fix for that will be in .7 when I can wrap a couple more things up. If it's working for you now, the new debug probably will not work for you.
 
Help wanted!!!
Alpha/Debug Release 1.2.1-Alpha.7

This release adds important debugging to the issue plaguing some of you where the flowmeter (taps) information gets zapped. Please try this and see if you can catch it happening - it will greatly help. When it happens, navigate to /flowdebuglog.txt and share the information it returns.

https://web.brewflasher.com/fw/135
I left .6 available so you can go back to it if you have to.
 
Just flashed to Alpha 7. Nice to see there's a link to /fs/ on the About page. Not so nice to see this when trying to upload the config files:
1683975644188.png

Guess it's time to reenter manually. Fortunately, JSON isn't hard to read, and it isn't all that much to reenter.
 
Last edited:
Just flashed to Alpha 7. Nice to see there's a link to /fs/ on the About page.
I am torn on that - while we are using it a lot here, I wonder if we leave it as a hidden "ninja switch" when we get things working well.

Not so nice to see this when trying to upload the config files:
Yeah ... well I needed to get that debug version out there to get some data collected. I did just finish the re-work on the upload, and I am considering another release with just that change.

Fortunately, JSON isn't hard to read, and it isn't all that much to reenter.
... said nobody nowhere. :)
 
... said nobody nowhere. :)
I mean, sure, I'd rather not have to do it, but I'd downloaded them anyway (did you intend that people be able to just browse to /appconfig.json? Because you can--which makes it convenient to download that and flowconfig), and it's easy enough to get the necessary information out of it for this purpose.
navigate to /flowdebuglog.txt and share the information it returns.
Is this something that's created only in the event of a crash? Because it's 404 for me.
 
I mean, sure, I'd rather not have to do it, but I'd downloaded them anyway
Just for you (and me, if I am honest), here is Alpha 8 which restores the file upload. Actually, it's a new file upload but the same thing for you:

https://web.brewflasher.com/fw/135
Nothing else was touched; it still has the Tap info debug I desperately need.

(did you intend that people be able to just browse to /appconfig.json? Because you can--which makes it convenient to download that and flowconfig), and it's easy enough to get the necessary information out of it for this purpose.
I could secure it by "secret," but I don't want to make things harder on anyone while chasing this darned bug. It is a bit of a security issue, as we've addressed, however, it's not a state secret and it's unlikely to create any more havoc than someone changing your tap info.

Now when it's stabilized and there exists some potential for a commercial venue to use it, sure.

Is this something that's created only in the event of a crash? Because it's 404 for me.
Yes. It will only be created in the event the controller tries to load the flowmeter (taps) file, and the file is not there or the data is gone. The choice there is the core of my issue, to address it I'd like to know why it's happening. Either one will result in a default file being created which is what wipes out your details.

I appreciate you guys sticking with me through this. The folks on 1.0 or 1.1 will appreciate it as well when this is all fixed!
 
Alpha .9 is ready for testing

https://web.brewflasher.com/fw/135
This is nearly the same as .8 except for some documentation I needed to complete. If you are using .8 there is no reason to update.

Right now I am at a stopping point until I get some feedback on the information in /flowdebuglog.txt in the event of a tap information loss. That information will guide my next steps.
 
Alpha .9 is ready for testing

https://web.brewflasher.com/fw/135
This is nearly the same as .8 except for some documentation I needed to complete. If you are using .8 there is no reason to update.

Right now I am at a stopping point until I get some feedback on the information in /flowdebuglog.txt in the event of a tap information loss. That information will guide my next steps.

Firstly, hello from Sydney Australia. Lee I certainly appreciate all of your work on this project.

This is from the .7 firmware but the flowdebuglog.txt file only has this -

[DEBUGFLOW] Failed to deserialize file.

I'll update to .9 and report back in a few days if/when it happens again.
 
This is from the .7 firmware but the flowdebuglog.txt file only has this -

[DEBUGFLOW] Failed to deserialize file.
That is perfect, thank you. If I can get a couple more reports, and hopefully they are the same, I can put in a fix.
 
Does anyone have a part number for the connector that goes on the breakout for attaching to the swissflo connector? There is some talk a while back that mentions various connectors but none seem to be correct.

In @Thorrak post, Keg Cop: Keg Monitoring and Control, there is a picture showing what appears to be the correct connector. Or is this just a modified incorrect connector?
 
Does anyone have a part number for the connector that goes on the breakout for attaching to the swissflo connector? There is some talk a while back that mentions various connectors but none seem to be correct.

In @Thorrak post, Keg Cop: Keg Monitoring and Control, there is a picture showing what appears to be the correct connector. Or is this just a modified incorrect connector?
John Guest PM450813E Female Connector, 8 mm x 3/8" BSPP (Pack of 10) John Guest PM450813E Female Connector, 8 mm x 3/8" BSPP (Pack of 10): Amazon.com: Industrial & Scientific
 

Latest posts

Back
Top