Keg Cop: Keg Monitoring and Control
- Thread starter LBussy
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
The target system is an installation of Raspberry Pints on Debian 11 with the option chosen to enable MQTT. What that does behind the scenes I don't know.
Based on the log output of Alpha 6, I'm inclined to agree with you. To test, I spun up a Debian 11 VM and followed the instructions you gave (correcting the typo in the systemctl commands which had only one t in mosquitto). The test succeeded; the "hello world" message was received (both from the same host and from a different host on my LAN) and printed.
But the console log on Alpha 6 makes it look like it's not making the connection:
Code:
2023-04-27T20:53:06Z V: KegScreen TV: JSON file written.
2023-04-27T20:53:06Z N: UPTIME: Started with no history.
2023-04-27T20:53:06Z N: Deserialized version information.
2023-04-27T20:53:06Z N: Started Keg Cop version 1.2.1-Alpha.6/1.2.1-Alpha.6 (mqtt) [d4d3916].
2023-04-27T20:53:06Z V: Taplist.io: secret or venue not set, skipping send. ('' / '')
2023-04-27T20:53:11Z V: MQTT: Initializing connection to broker: 192.168.1.154 on port: 1883
2023-04-27T20:53:11Z V: MQTT: Connecting.
2023-04-27T20:53:32Z V: Disconnected from MQTT.
2023-04-27T20:53:32Z V: MQTT: Initializing connection to broker: 192.168.1.154 on port: 1883
2023-04-27T20:53:32Z V: MQTT: Connecting.
2023-04-27T20:53:54Z V: Disconnected from MQTT.
2023-04-27T20:53:54Z V: MQTT: Initializing connection to broker: 192.168.1.154 on port: 1883
2023-04-27T20:53:54Z V: MQTT: Connecting.
2023-04-27T20:54:08Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-04-27T20:54:15Z V: Disconnected from MQTT.
2023-04-27T20:54:15Z V: MQTT: Initializing connection to broker: 192.168.1.154 on port: 1883
2023-04-27T20:54:15Z V: MQTT: Connecting.
2023-04-27T20:54:36Z V: Disconnected from MQTT.
2023-04-27T20:54:36Z V: MQTT: Initializing connection to broker: 192.168.1.154 on port: 1883
2023-04-27T20:54:36Z V: MQTT: Connecting.
2023-04-27T20:54:53Z V: Sending /api/v1/info/secret/.
2023-04-27T20:54:53Z V: Sending /api/v1/info/tempcontrol/.
2023-04-27T20:54:53Z V: Sending /api/v1/info/sensors/.
2023-04-27T20:54:53Z V: Sending /api/v1/info/theme/.
2023-04-27T20:54:59Z V: Sending /api/v1/info/secret/.
2023-04-27T20:54:59Z V: Sending /api/v1/info/thisVersion/.
2023-04-27T20:54:59Z V: Sending /api/v1/info/thatVersion/.
2023-04-27T20:54:59Z V: Sending /api/v1/info/tempcontrol/.
2023-04-27T20:54:59Z V: Disconnected from MQTT.
2023-04-27T20:54:59Z V: MQTT: Initializing connection to broker: 192.168.1.154 on port: 1883
2023-04-27T20:54:59Z V: MQTT: Connecting.
2023-04-27T20:54:59Z V: Sending /api/v1/info/theme/.
2023-04-27T20:54:59Z V: Processing PUT to /api/v1/action/clearcalmode/.
2023-04-27T20:54:59Z V: Processing secret header.
2023-04-27T20:54:59Z N: Secret Check: [X-KegCop-Secret]:(651B5AE000001823) is valid.
2023-04-27T20:54:59Z V: Flowmeter Config Save: Saving configuration.
2023-04-27T20:54:59Z V: Flowmeter Config Save: Configuration saved.
2023-04-27T20:55:08Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-04-27T20:55:13Z V: Processing put to /api/v1/config/settings/.
2023-04-27T20:55:13Z N: Settings Update: [rpintshost]:(192.168.1.165) applied.
2023-04-27T20:55:13Z N: Settings Update: [rpintsport]:(1883) applied.
2023-04-27T20:55:13Z N: Settings Update: [rpintsusername]:(RaspberryPints) applied.
2023-04-27T20:55:13Z N: Settings Update: [rpintspassword]:(password) applied.
2023-04-27T20:55:13Z N: Settings Update: [rpintstopic]:(kegcop) applied.
2023-04-27T20:55:13Z V: Keg Cop Save: Saving configuration.
2023-04-27T20:55:13Z V: Keg Cop Save: Configuration saved.
2023-04-27T20:55:13Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-27T20:55:13Z V: MQTT: Connecting.
2023-04-27T20:55:21Z V: Disconnected from MQTT.
2023-04-27T20:55:21Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-27T20:55:21Z V: MQTT: Connecting.
2023-04-27T20:55:42Z V: Disconnected from MQTT.
2023-04-27T20:55:42Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-27T20:55:42Z V: MQTT: Connecting.
2023-04-27T20:56:04Z V: Disconnected from MQTT.
2023-04-27T20:56:04Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-27T20:56:04Z V: MQTT: Connecting.
2023-04-27T20:56:08Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-04-27T20:56:25Z V: Disconnected from MQTT.
2023-04-27T20:56:25Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-27T20:56:25Z V: MQTT: Connecting.
2023-04-27T20:56:48Z V: Disconnected from MQTT.
2023-04-27T20:56:48Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-27T20:56:48Z V: MQTT: Connecting.
2023-04-27T20:57:08Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-04-27T20:57:10Z V: Disconnected from MQTT.
2023-04-27T20:57:10Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-27T20:57:10Z V: MQTT: Connecting.
2023-04-27T20:57:31Z V: Disconnected from MQTT.
OP
OP
I don't know what you are talking about! (I'm sure that developer thought he was being real cute)
That's what it looks like. A good connection looks like this (which just came off my system):
Code:
2023-04-27T21:23:39Z V: MQTT: Initializing connection to broker: mule.local on port: 1883
2023-04-27T21:23:44Z V: MQTT: Resolved mDNS broker name: mule.local (10.0.0.6)
2023-04-27T21:23:47Z V: MQTT: Connecting.
2023-04-27T21:23:47Z N: MQTT: Connected to MQTT, session: falseAll I can think is that I made some mistake publishing this version, or ... I dunno:
1.2.1-Alpha.6 (mqtt) [552d0ab]?
OP
OP
I've probably compiled a couple of times since then, but I’ll put a new version out again as soon as I can.
Last edited:
OP
OP
@danb35 here's a re-release to get you to the tip of the working branch where I am:
https://web.brewflasher.com/fw/90
https://web.brewflasher.com/fw/90
OP
OP
Which version did you load?Hi, after few days of work, the taps were reseted to default
Someone also saw such problem?
Alfa 6
OP
OP
Okay, good to know. Sad for me, but still good to know. I will have to do the nuclear option and keep a backup of that file. I just need to figure out how to detect the failure we are experiencing.
It might get fixed by moving to LittleFS, but it might just take a bunch of time to move to LittleFS and get no return on my investment.
It might get fixed by moving to LittleFS, but it might just take a bunch of time to move to LittleFS and get no return on my investment.
Can i help to collect some logs, but tell me how
OP
OP
You can tell me what sort of restart it was before it lost its mind. You should be able to see this in the /uptime.csv
OP
OP
Ok, i will check
I saw this documentation, trying to put, nothing happens
OP
OP
Use the serial log (or telnet), and you may see an error that gives you some information.
Somehow I'd missed that possibility earlier--that makes checking the logs a lot easier.
"Telnet"?
What year is this?
Y'all are freakin' me out right now
What year is this?
Y'all are freakin' me out right now
If you're concerned about security, "it uses telnet" should be pretty low on your list of concerns, given you can browse to kegcop.local/appconfig.json and download it--passwords and all--with no authentication.
OP
OP
Well, the only password you get there is the Keg Cop AP password. That’s not a lot of help for a would-be hacker.
The problem is not telnet, the problem is letting someone on your WiFi.
Telnet is intended for debugging and the initial releases had it turned off at compile time. I am considering leaving it, but making it configurable.
The problem is not telnet, the problem is letting someone on your WiFi.
Telnet is intended for debugging and the initial releases had it turned off at compile time. I am considering leaving it, but making it configurable.
...and the MQTT password, and credentials for any other services you're publishing to. But agree that:
OP
OP
I agree. I secure a nation-state target for a living and I can be paranoid with the best of them. If a person uses reasonable best practices (like account separation and not reusing passwords) the worst that should be able to happen would be to surreptitiously say you drank 5 gallons of Barleywine over the weekend.
Unfortunately, good security is costly. In this case the cost is storage and processing power, as well as significantly raising the bar for a DIY project. Even if a person could figure out a good way to use SSL/TLS in such a small package with all the other features, it would be a complete project of its own. These core libs are barely capable of maintaining a WiFi connection.
Unfortunately, good security is costly. In this case the cost is storage and processing power, as well as significantly raising the bar for a DIY project. Even if a person could figure out a good way to use SSL/TLS in such a small package with all the other features, it would be a complete project of its own. These core libs are barely capable of maintaining a WiFi connection.
Yea please!
this is output of uptime.csv
Date/Time, Start Reason, Restart Description, Uptime (Secs)
2023-04-25T08:38:50Z, ESP_RST_POWERON, START_COLDBOOT, 1116
2023-04-25T09:00:31Z, ESP_RST_POWERON, START_COLDBOOT, 929
2023-04-25T09:32:45Z, ESP_RST_POWERON, START_COLDBOOT, 956
2023-04-25T09:33:13Z, ESP_RST_POWERON, START_WARMBOOT, 9
2023-04-25T09:58:30Z, ESP_RST_SW, START_WARMBOOT, 1510
2023-04-25T10:56:16Z, ESP_RST_PANIC, START_WARMBOOT, 3467
2023-04-25T16:15:52Z, ESP_RST_PANIC, START_WARMBOOT, 19168
2023-04-25T16:49:55Z, ESP_RST_PANIC, START_WARMBOOT, 2029
2023-04-26T05:47:29Z, ESP_RST_PANIC, START_WARMBOOT, 46609
2023-04-27T05:43:56Z, ESP_RST_SW, START_WARMBOOT, 86169
2023-04-27T20:48:26Z, ESP_RST_SW, START_WARMBOOT, 54250
2023-04-28T09:37:58Z, ESP_RST_POWERON, START_COLDBOOT, 45890
2023-04-28T19:03:30Z, ESP_RST_SW, START_WARMBOOT, 33929
2023-04-29T19:03:39Z, ESP_RST_SW, START_WARMBOOT, 86407
2023-04-30T19:03:48Z, ESP_RST_SW, START_WARMBOOT, 86407
2023-05-01T19:03:57Z, ESP_RST_SW, START_WARMBOOT, 86407
2023-05-02T07:05:47Z, ESP_RST_SW, START_WARMBOOT, 43287
2023-05-03T05:46:01Z, ESP_RST_SW, START_COLDBOOT, 80807
2023-05-03T10:16:23Z, ESP_RST_SW, START_COLDBOOT, 15894
2023-05-04T10:16:32Z, ESP_RST_SW, START_WARMBOOT, 86413
2023-05-04T16:49:57Z, ESP_RST_SW, START_WARMBOOT, 23587
2023-05-04T22:57:56Z, ESP_RST_SW, START_WARMBOOT, 22070
2023-05-05T06:57:46Z, ESP_RST_POWERON, START_WARMBOOT, 28767
2023-05-05T07:49:04Z, ESP_RST_SW, START_WARMBOOT, 3080
2023-05-05T09:38:52Z, ESP_RST_SW, START_WARMBOOT, 6567
2023-05-05T22:05:50Z, ESP_RST_SW, START_WARMBOOT, 44807
2023-05-06T08:39:20Z, ESP_RST_SW, START_WARMBOOT, 37987
2023-05-06T17:11:58Z, ESP_RST_SW, START_WARMBOOT, 30727
2023-05-06T17:12:27Z, ESP_RST_SW, START_WARMBOOT, 35
2023-05-06T17:15:26Z, ESP_RST_SW, START_COLDBOOT, 23
2023-05-07T11:33:58Z, ESP_RST_SW, START_WARMBOOT, 65907
2023-05-08T11:34:08Z, ESP_RST_SW, START_WARMBOOT, 86408
2023-05-09T06:21:37Z, ESP_RST_SW, START_WARMBOOT, 67647
i think when the issue happened it was coldboot
OP
OP
You can either use Telnet (which will obviously not help if there is a crash), or you can plug in the same data cable you used to flash the software and use something like PuTTY to connect to the serial port.
There are a large number of articles and videos on how to do this. The baud rate you will use is 115200.
It would be helpful if this happens again for you to identify the approximate time.
These are crashes:
.. which are troublesome but they do not look like they caused your issue.
This is a description of the start reason codes. The cold boot is where the board was powered off (unplugged.)
Thanks for the answer, is it possible to connect with putty with ip? What port i should use to connect? And what username and password?
OP
OP
Yes, via Telnet (port 22.) There is no authentication.
Hi
I used serial log to collect logs when PUT taps doesn't work for me
this is output:
2023-05-09T15:36:30Z V: Processing put to /api/v1/config/taps/.
2023-05-09T15:36:30Z V: Checking handleTapPost.
2023-05-09T15:36:30Z V: Checking handleTapCal.
2023-05-09T15:36:30Z V: Checking handleSetCalMode.
2023-05-09T15:36:30Z V: Clearing any calibration flags before setting new flags.
2023-05-09T15:37:01Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-05-09T15:39:01Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-05-09T15:40:01Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-05-09T15:40:10Z V: MQTT: No broker configured.
i don't see any error
OP
OP
When a PUT is sent to the /api/v1/config/taps/ endpoint, it cycles the received payload through:
- handleTapPost()
- handleTapCal()
- handleSetCalMode()
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);
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);
OP
OP
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
OP
OP
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);
OP
OP
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.
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
OP
OP
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
Similar threads
