OP
OP
Okay, here's 1.2.1-Alpha.2:
https://web.brewflasher.com/fw/90
I've been hammering on it for about an hour, generally abusing it. This test generally incites a crash so maybe ... ah I won't jinx it. Tell me how it works for you.
Keg Cop: Keg Monitoring and Control
- Thread starter LBussy
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
https://web.brewflasher.com/fw/90
I've been hammering on it for about an hour, generally abusing it. This test generally incites a crash so maybe ... ah I won't jinx it. Tell me how it works for you.
OP
OP
This is fixed in the devel branch, so will be in the next release (of any type).
All right, it's installed on an ESP, tap information reset, Raspberry Pints target updated. I notice, at least in the dark theme, it isn't giving UI feedback when saving settings (the spinning dots thing--surely that's the technical name for it--doesn't appear), but they do nonetheless seem to save. Other than generally "use it and see if it breaks", is there something specific I should be looking for?
OP
OP
Yep - I have that fixed already but it’s not in that version. It will be in the next release.
That’s about it. Due to some core lib issues the thing will still get confused when there’s multiple access points with the same name, HOWEVER that will not cause a crash. It will cause a reset though, but there is logic there that makes it safer.
OP
OP
Okay, here is what I think will be come a Beta and/or Release Candidate:
1.2.1-Alpha.3: BrewFlasher Web Edition
I fixed a nagging calibration bug, fixed the button feedback on submit, and fixed the accuracy reported when going past increments of .0001.
Feedback is welcomed. Positive feedback is really welcomed.
1.2.1-Alpha.3: BrewFlasher Web Edition
I fixed a nagging calibration bug, fixed the button feedback on submit, and fixed the accuracy reported when going past increments of .0001.
Feedback is welcomed. Positive feedback is really welcomed.
OP
OP
Much improved stability!
Wall of text coming:
The ESP_RST_SW is the application resetting itself because it lost connection with the AP. This is not unique, unfortunately, with the ESP devices, this version of the core, and multiple APs with the same name. The good news is, the application is still in control here so it's controlled and not a crash.
@Thorrak was telling me the "fix" was to reset my router.
So here's where we are. There is what is called "Arduino Core for the ESP32." It is what allows "Arduino" programming on the ESP32 devices. In version 1.x.x, all was well, the skies were blue, and the bugs were annoying but manageable. Then came 2.x.x. All of the 1.x.x kids were made fun of as dinosaurs by the new cool kids. The dinosaurs put their heads down in shame and acted like the cool kids. Soon they had drank enough Kool Aide that they were acting like cool kids too.
Before long they were making mistakes, making excuses for their applications' stability. They spend endless hours trying to harden their application against the inevitability that they would crash for no good reason. Things were not good, and it was impossible for the cool kids to see it.
That was me. I apologize to the folks who had such trouble with stability. I moved this back to core 1.0.7 and aside from that thing with multiple APs, which is detectable and recoverable, things seem pretty stable again. I'm going to spend some time seeing if I can't recover better from those.
The reset for the AP "confusion" looks like this:
All of those "[WiFi-event] event: X" messages are the WiFi subsystem (which is closed-source compiled code) crapping itself. After that you see "reconnencting" which is the Keg Cop code trying valiantly to recover (this is the part I am going to work on.) After that you see configurations save (which is good!) and then a controlled reset (ESP_RST_SW in that table above.)
I'm actually pretty encouraged by this. All of the previous features have been maintained, and all reported bugs are fixed. If I can figure out a better method to deal with WiFi losing it's mind, that would button things up. If not, like I said, it's controlled so no danger other than being annoying.
Thanks for sticking with me!
| Date/Time | Start Reason | Restart Description | Uptime (Secs) |
| 2023-04-13T00:36:10Z | ESP_RST_POWERON | START_WARMBOOT | 26 |
| 2023-04-13T02:44:19Z | ESP_RST_SW | START_WARMBOOT | 7689 |
| 2023-04-13T03:20:34Z | ESP_RST_SW | START_WARMBOOT | 2165 |
Wall of text coming:
The ESP_RST_SW is the application resetting itself because it lost connection with the AP. This is not unique, unfortunately, with the ESP devices, this version of the core, and multiple APs with the same name. The good news is, the application is still in control here so it's controlled and not a crash.
@Thorrak was telling me the "fix" was to reset my router.
So here's where we are. There is what is called "Arduino Core for the ESP32." It is what allows "Arduino" programming on the ESP32 devices. In version 1.x.x, all was well, the skies were blue, and the bugs were annoying but manageable. Then came 2.x.x. All of the 1.x.x kids were made fun of as dinosaurs by the new cool kids. The dinosaurs put their heads down in shame and acted like the cool kids. Soon they had drank enough Kool Aide that they were acting like cool kids too.
Before long they were making mistakes, making excuses for their applications' stability. They spend endless hours trying to harden their application against the inevitability that they would crash for no good reason. Things were not good, and it was impossible for the cool kids to see it.
That was me. I apologize to the folks who had such trouble with stability. I moved this back to core 1.0.7 and aside from that thing with multiple APs, which is detectable and recoverable, things seem pretty stable again. I'm going to spend some time seeing if I can't recover better from those.
The reset for the AP "confusion" looks like this:
Code:
[WiFi-event] event: 5
2023-04-12T14:17:46Z W: WiFi lost connection, reconnecting ......................................................................................................
[WiFi-event] event: 5
....
[WiFi-event] event: 4
..
[WiFi-event] event: 7
.
2023-04-12T14:17:57Z W: WiFi lost connection, reconnecting ..
[WiFi-event] event: 1
[WiFi-event] event: 5
2023-04-12T14:17:59Z W: WiFi lost connection, reconnecting ...
[WiFi-event] event: 4
[WiFi-event] event: 7
.
2023-04-12T14:17:59Z W: WiFi lost connection, reconnecting ..
[WiFi-event] event: 1
[WiFi-event] event: 5
2023-04-12T14:18:02Z E: Unable to reconnect WiFI, restarting.
[WiFi-event] event: 4
[WiFi-event] event: 7
2023-04-12T14:18:03Z N: Reboot request - rebooting system.
2023-04-12T14:18:03Z V: Keg Cop Save: Saving configuration.
2023-04-12T14:18:03Z V: Keg Cop Save: Configuration saved.
2023-04-12T14:18:03Z V: Flowmeter Config Save: Saving configuration.
2023-04-12T14:18:03Z V: Flowmeter Config Save: Configuration saved.
[WiFi-event] event: 5
[WiFi-event] event: 3
ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13192
load:0x40080400,len:3028
entry 0x400805e4
2023-04-12T14:18:04Z N: Serial logging started at 115200.All of those "[WiFi-event] event: X" messages are the WiFi subsystem (which is closed-source compiled code) crapping itself. After that you see "reconnencting" which is the Keg Cop code trying valiantly to recover (this is the part I am going to work on.) After that you see configurations save (which is good!) and then a controlled reset (ESP_RST_SW in that table above.)
I'm actually pretty encouraged by this. All of the previous features have been maintained, and all reported bugs are fixed. If I can figure out a better method to deal with WiFi losing it's mind, that would button things up. If not, like I said, it's controlled so no danger other than being annoying.
Thanks for sticking with me!
As far as I can tell, mine is still working on 1.2.1-Alpha2. It's keeping its settings and seems to be tracking pours. And I'm in a Unifi network environment with three APs in likely range of the ESP, so if that's what's causing all the trouble, I should be pretty near a worst-case scenario for it. I'm the only one drinking the beer, and I don't drink more than two in one day, so it isn't super-busy.
And I can now confirm that my six-way flowmeter breakout board works, at least for meters 1-4.
And I can now confirm that my six-way flowmeter breakout board works, at least for meters 1-4.
OP
OP
The multiple APs is what causes my software to have to restart - this is not a crash. I am experimenting with ways to deal with that more gracefully.
Hi,
First of all Excellent project!!!
I started to use kegcop few days ago to monitor the beer in kegs
I noticed that without APIs usage there are no problems, and everything works good
But when i am using API for taps (api/v1/config/taps/) the system crashes
With the latest alfa version looks like it partially recovers, but all taps data is cleaned and start to be default
First of all Excellent project!!!
I started to use kegcop few days ago to monitor the beer in kegs
I noticed that without APIs usage there are no problems, and everything works good
But when i am using API for taps (api/v1/config/taps/) the system crashes
With the latest alfa version looks like it partially recovers, but all taps data is cleaned and start to be default
OP
OP
There are a few bits of information that can help me resolve what you are seeing:
- Confirm which alpha version you have
- Information from "uptime.csv"
- If you are running this with a serial log, the log information around the crash <- This is probably the most important part.
I am running 1.2.1-Alpha.3: BrewFlasher Web Edition
how i can get uptime.csv
and how i can run and collect serial log?
OP
OP
Type it in as your url like: http://kegcop.local/uptime.csv
Depending how you are set up it may display or just download it.
Are you Windows, Mac or Linux?
Should that work on Alpha2 as well? Because it doesn't for me; it 404s.
OP
OP
It should. Navigate to /edit/ and use the username “admin” and password “p@ssword”. You should be able to list files and download it there.
Logging in that way works, but there's no uptime.csv file there.
OP
OP
That’s strange.
Try a fresh flash off Brewflasher and after it starts up see if the file gets created. It might have to do with the crash. I’m not at home right now and can’t confirm I didn’t break that, but I should be able to check in a couple hours.
Try a fresh flash off Brewflasher and after it starts up see if the file gets created. It might have to do with the crash. I’m not at home right now and can’t confirm I didn’t break that, but I should be able to check in a couple hours.
It's there on 1.2.1-alpha3.
So now that I have what seems to be a stable KegCop installation, how do I go about figuring out why pours aren't showing up in Raspberry Pints?
OP
OP
Well, the serial log would be interesting. There should be some very verbose logging in this build that may give us some better information … assuming you are using MQ and not the serial connection for it.
OP
OP
Okay, here's where I am:
I have a pretty good lock on what is and is not working. The async process (a library that allows asynchronous network traffic) is still trash. I am trying to harden things as much as possible and button things up for a release or at least a Beta. This may include a preemptive restart (maybe every 2 hours) to avoid most crashes. I want to get to that stopping point because the NEXT step is a rewrite of much of the code.
Where I am right now is that remaining issue where it loses connection to the network. I am hopeful that I can avoid restarting the controller when that happens. I'm not sure the juice is worth the squeeze there, but I will try it.
On the subject of that rewrite: All signs point to the real likelihood that moving to synchronous TCP and web services will eliminate a lot of instability. That's unfortunate for two reasons:
Anyway, I hope to see my network screw up here in the background to test my latest change. The frequency of those drops gates my testing. Suffice it to say there's lots of downtime while I wait.
I have a pretty good lock on what is and is not working. The async process (a library that allows asynchronous network traffic) is still trash. I am trying to harden things as much as possible and button things up for a release or at least a Beta. This may include a preemptive restart (maybe every 2 hours) to avoid most crashes. I want to get to that stopping point because the NEXT step is a rewrite of much of the code.
Where I am right now is that remaining issue where it loses connection to the network. I am hopeful that I can avoid restarting the controller when that happens. I'm not sure the juice is worth the squeeze there, but I will try it.
On the subject of that rewrite: All signs point to the real likelihood that moving to synchronous TCP and web services will eliminate a lot of instability. That's unfortunate for two reasons:
- We lose some performance (which can be mitigated)
- It's a re-write of a large chunk of code which is work + time + chance to screw new things up
Anyway, I hope to see my network screw up here in the background to test my latest change. The frequency of those drops gates my testing. Suffice it to say there's lots of downtime while I wait.
Last edited:
OP
OP
Pre-Release 1.2.1-Alpha.4 is available, please use BrewFlasher to install:
https://web.brewflasher.com/fw/90
I tried many different ways, and the wifi disconnect issue is so destabilizing that right now I think it's better to do a controlled restart. So this version has that controlled restart (again) and will also restart every two hours, cleanly, to avoid issues with the upstream async libraries.
The only potential downside to this is if you are using Keg Cop to control your kegerator temp. There is a cooling delay of 5 minutes after startup to prevent your compressor from short cycling. That means you will have a 5-minute pause before cooling kicks in again. I don't think this is an issue based on my kegerator out in the garage in the heat of the summer; mine was able to only run about 50% of the time to keep things cool.
I have one more minor bug to fix that some of you may stumble upon, then I'll go to a release candidate. If you are using any of the other Alpha versions, I recommend taking this .4 version.
https://web.brewflasher.com/fw/90
I tried many different ways, and the wifi disconnect issue is so destabilizing that right now I think it's better to do a controlled restart. So this version has that controlled restart (again) and will also restart every two hours, cleanly, to avoid issues with the upstream async libraries.
The only potential downside to this is if you are using Keg Cop to control your kegerator temp. There is a cooling delay of 5 minutes after startup to prevent your compressor from short cycling. That means you will have a 5-minute pause before cooling kicks in again. I don't think this is an issue based on my kegerator out in the garage in the heat of the summer; mine was able to only run about 50% of the time to keep things cool.
I have one more minor bug to fix that some of you may stumble upon, then I'll go to a release candidate. If you are using any of the other Alpha versions, I recommend taking this .4 version.
Can I update to it without it wiping all my settings?
OP
OP
Not with BrewFlasher, but there’s a way to keep them. Please give me a bit to post those instructions.
Last edited:
It isn't that hard to note the relevant settings--there aren't that many of them--but wasn't sure if I needed to. Sounds like I do.
Edit: Alpha4 is now installed. The uptime.csv file is available, which will give me a way of keeping track of it. I also put it on a SSID that's only served by one AP. I'll see about capturing some log output about the MQTT tomorrow.
Edit: Alpha4 is now installed. The uptime.csv file is available, which will give me a way of keeping track of it. I also put it on a SSID that's only served by one AP. I'll see about capturing some log output about the MQTT tomorrow.
Last edited:
Interesting. First, somehow the controller lost the theme, brewery name, temp probe settings, and target settings between last night and tonight. The tap information was preserved. uptime.csv doesn't show anything unexpected:
Code:
Date/Time, Start Reason, Restart Description, Uptime (Secs)
2023-04-17T00:33:37Z, ESP_RST_SW, START_COLDBOOT, 5203
2023-04-17T02:33:39Z, ESP_RST_SW, START_COLDBOOT, 5003
2023-04-17T04:33:40Z, ESP_RST_SW, START_COLDBOOT, 5003
2023-04-17T06:33:41Z, ESP_RST_SW, START_COLDBOOT, 5003
2023-04-17T08:33:42Z, ESP_RST_SW, START_COLDBOOT, 5003
2023-04-17T10:33:43Z, ESP_RST_SW, START_COLDBOOT, 5003
2023-04-17T12:33:44Z, ESP_RST_SW, START_COLDBOOT, 5003
2023-04-17T14:33:45Z, ESP_RST_SW, START_COLDBOOT, 5003
2023-04-17T16:33:46Z, ESP_RST_SW, START_COLDBOOT, 5003
2023-04-17T18:33:47Z, ESP_RST_SW, START_COLDBOOT, 5003
2023-04-17T20:20:57Z, ESP_RST_POWERON, START_COLDBOOT, 5003
2023-04-17T20:33:47Z, ESP_RST_POWERON, START_WARMBOOT, 758Second, after re-entering the MQTT target information, nothing at all is logged wrt MQTT for a pour:
Code:
2023-04-17T20:25:23Z V: Processing put to /api/v1/config/settings/.
2023-04-17T20:25:23Z N: Settings Update: [rpintshost]:(192.168.1.165) applied.
2023-04-17T20:25:23Z N: Settings Update: [rpintsport]:(1883) applied.
2023-04-17T20:25:23Z N: Settings Update: [rpintsusername]:(RaspberryPints) applied.
2023-04-17T20:25:23Z N: Settings Update: [rpintspassword]:(password) applied.
2023-04-17T20:25:23Z N: Settings Update: [rpintstopic]:(kegcop) applied.
2023-04-17T20:25:23Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-17T20:25:23Z V: MQTT: Connecting.
2023-04-17T20:25:23Z V: Keg Cop Save: Saving configuration.
2023-04-17T20:25:23Z V: Keg Cop Save: Configuration saved.
2023-04-17T20:25:23Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-17T20:25:23Z V: MQTT: Connecting.
2023-04-17T20:25:23Z V: Tap 0 showed a small pour of 1 pulses.
2023-04-17T20:25:23Z V: Discarding 1 pulses from tap 0 on pin 4.
2023-04-17T20:25:23Z V: Tap 2 showed a small pour of 1 pulses.
2023-04-17T20:25:23Z V: Discarding 1 pulses from tap 2 on pin 17.
2023-04-17T20:25:43Z V: Disconnected from MQTT.
2023-04-17T20:25:59Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-04-17T20:26:58Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-04-17T20:27:16Z V: Tap 1 is registering 1499 pulses.
2023-04-17T20:27:16Z V2023-04-17T20:27:16Z V: : Debiting 1499 pulses from tap 1 onFlowmeter Config Save: Saving configuration.
pin 16.
2023-04-17T20:27:16Z V: Flowmeter Config Save: Configuration saved.
2023-04-17T20:27:17Z V: KegScreen reporting not enabled, skipping (Pour Report).
2023-04-17T20:27:17Z V: Flowmeter Config Save: Saving configuration.
2023-04-17T20:27:17Z V: Flowmeter Config Save: Configuration saved.
2023-04-17T20:27:43Z V: Tap 1 showed a small pour of 3 pulses.
2023-04-17T20:27:43Z V: Discarding 3 pulses from tap 1 on pin 16.
[snip]
2023-04-17T20:31:59Z V: Sending /api/v1/info/sensors/.
2023-04-17T20:32:09Z V: Sending /api/v1/info/sensors/.
2023-04-17T20:32:10Z V: Tap 1 is registering 1168 pulses.
2023-04-17T20:32:10Z V: De2023-04-17T20:32:b10Zi tVing 1168 pulses from tap 1 on pin 16.
: Flowmeter Config Save: Saving configuration.
2023-04-17T20:32:10Z V: Flowmeter Config Save: Configuration saved.
2023-04-17T20:32:11Z V: KegScreen reporting not enabled, skipping (Pour Report).
2023-04-17T20:32:20Z V: Sending /api/v1/info/sensors/.
OP
OP
I can reproduce the temp probe settings getting wiped when the controller crashes, but those resets you have are all controlled - you should see the config saving right before the reset. The thing is, yours do not look the same as what I get:
| Date/Time | Start Reason | Restart Description | Uptime (Secs) |
| 2023-04-16T14:42:52Z | ESP_RST_SW | START_WARMBOOT | 7184 |
| 2023-04-16T16:42:52Z | ESP_RST_SW | START_WARMBOOT | 7183 |
| 2023-04-16T18:42:54Z | ESP_RST_SW | START_WARMBOOT | 7182 |
| 2023-04-16T20:42:54Z | ESP_RST_SW | START_WARMBOOT | 7183 |
| 2023-04-16T22:42:52Z | ESP_RST_SW | START_WARMBOOT | 7182 |
| 2023-04-17T00:42:59Z | ESP_RST_SW | START_WARMBOOT | 7183 |
| 2023-04-17T02:42:54Z | ESP_RST_SW | START_WARMBOOT | 7189 |
| 2023-04-17T04:42:54Z | ESP_RST_SW | START_WARMBOOT | 7183 |
| 2023-04-17T06:42:57Z | ESP_RST_SW | START_WARMBOOT | 7182 |
| 2023-04-17T08:42:57Z | ESP_RST_SW | START_WARMBOOT | 7183 |
| 2023-04-17T10:43:00Z | ESP_RST_SW | START_WARMBOOT | 7183 |
| 2023-04-17T12:42:59Z | ESP_RST_SW | START_WARMBOOT | 7185 |
| 2023-04-17T14:43:00Z | ESP_RST_SW | START_WARMBOOT | 7183 |
| 2023-04-17T16:43:01Z | ESP_RST_SW | START_WARMBOOT | 7182 |
| 2023-04-17T18:43:02Z | ESP_RST_SW | START_WARMBOOT | 7182 |
| 2023-04-17T20:43:03Z | ESP_RST_SW | START_WARMBOOT | 7182 |
I think somehow I might have uploaded something other than the correct version. What does the "About" page show? It should show:
Hrmum, let me get your version thing squared away first and then I'll figure out the MQTT.
Last edited:
OP
OP
Yeah that's not right - let me get off this call and re-publish.
OP
OP
OK, now running:
Theme, brewery name, kegerator name, temp sensors, and at least the Raspberry Pints target reset on power cycle. Tap information doesn't. There's still zero action on MQTT on a pour; log in the next post.
Code:
2023-04-17T22:04:08Z V: Keg Cop Save: Saving configuration.
2023-04-17T22:04:08Z V: Keg Cop Save: Configuration saved.
2023-04-17T22:04:12Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-04-17T22:04:34Z V: Processing put to /api/v1/config/settings/.
2023-04-17T22:04:34Z N: Settings Update: [rpintshost]:(192.168.1.165) applied.
2023-04-17T22:04:34Z N: Settings Update: [rpintsport]:(1883) applied.
2023-04-17T22:04:34Z N: Settings Update: [rpintsusername]:(RaspberryPints) applied.
2023-04-17T22:04:34Z N: Settings Update: [rpintspassword]:(password) applied.
2023-04-17T22:04:34Z N: Settings Update: [rpintstopic]:(kegcop) applied.
2023-04-17T22:04:34Z V: Keg Cop Save: Saving configuration.
2023-04-17T22:04:34Z V: Keg Cop Save: Configuration saved.
2023-04-17T22:04:34Z V: MQTT: Initializing connection to broker: 192.168.1.165 on port: 1883
2023-04-17T22:04:34Z V: MQTT: Connecting.
2023-04-17T22:04:54Z V: Disconnected from MQTT.
2023-04-17T22:05:03Z V: Processing put to /api/v1/config/taps/.
2023-04-17T22:05:03Z V: Checking handleTapPost.
2023-04-17T22:05:03Z V: handleTapPost(): Processing [tap]:(0) pair.
2023-04-17T22:05:03Z N: Settings Update: processing [tap]:(0).
2023-04-17T22:05:03Z V: handleTapPost(): Processing [label]:(1) pair.
2023-04-17T22:05:03Z N: Settings Update: processing [label]:(1).
2023-04-17T22:05:03Z V: handleTapPost(): Processing [ppu]:(21492) pair.
2023-04-17T22:05:03Z N: Settings Update: [ppu]:(21492) applied.
2023-04-17T22:05:03Z V: handleTapPost(): Processing [bevname]:(Big Man American Stout) pair.
2023-04-17T22:05:03Z N: Settings Update: [bevname]:(Big Man American Stout) applied.
2023-04-17T22:05:03Z V: handleTapPost(): Processing [cap]:(5.0000) pair.
2023-04-17T22:05:03Z N: Settings Update: [cap]:(5.0000) applied.
2023-04-17T22:05:03Z V: handleTapPost(): Processing [remain]:(2.7018) pair.
2023-04-17T22:05:03Z N: Settings Update: [remain]:(2.7018) applied.
2023-04-17T22:05:03Z V: handleTapPost(): Processing [taplistioTap]:(0) pair.
2023-04-17T22:05:03Z N: Settings Update: [taplistioTap]:(0) applied.
2023-04-17T22:05:03Z V: handleTapPost(): Processing [active]:(active) pair.
2023-04-17T22:05:03Z N: Settings update [0], [active]:(active) applied.
2023-04-17T22:05:03Z V: Flowmeter Config Save: Saving configuration.
2023-04-17T22:05:03Z V: Flowmeter Config Save: Configuration saved.
[snip]
2023-04-17T22:06:58Z V: Sending /api/v1/info/uptime/.
2023-04-17T22:06:58Z V: Sending /api/v1/info/resetreason/.
2023-04-17T22:06:58Z V: Sending /api/v1/info/heap/.
2023-04-17T22:07:08Z V: Tap 1 is registering 1680 pulses.
2023-04-17T22:07:08Z V: Debiti2023-04-17T22:07:08Z nVg : 1680 pulses from tap 1 on pin 16.
Flowmeter Config Save: Saving configura2023-04-17T22:07:08Z V: Sending /api/v1/info/uptime/.
tion.
2023-04-17T22:07:08Z V: Sending /api/v1/info/resetreason/.
2023-04-17T22:07:08Z V: Sending /api/v1/info/heap/.
2023-04-17T22:07:08Z V: Flowmeter Config Save: Configuration saved.
2023-04-17T22:07:08Z V: KegScreen reporting not enabled, skipping (Pour Report).
2023-04-17T22:07:12Z V: KegScreen reporting not enabled, skipping (Temp Report).
2023-04-17T22:07:18Z V: Sending /api/v1/info/uptime/.
2023-04-17T22:07:18Z V: Sending /api/v1/info/resetreason/.
OP
OP
On the one hand, I appreciate your testing. On the other, stop finding bugs!
When you say "power cycle," how exactly are you doing this?
Unplugging the USB cable used to flash the new firmware and check the logs, and plugging in the USB charger.
OP
OP
Oddly enough, I was not testing that either.
Tap information is separate from the other configuration, so you've narrowed it down for me. I'll have a look as soon as I can. I'm tracking this as #169.
Last edited:
OP
OP
@danb35 - maybe this would be a good time for you to try the ability to save off and restore the configuration. I know how it works technically, but I'm interested in how it works in practice:
If you want/need to restore these, upload them again. Immediately after uploading them, reset the controller. It should pick up the new configuration. This is incidentally how you would back up and restore settings for an upgrade with BrewFlasher.
"Someday," I'd like to make that fancier ... one insurmountable obstacle at a time.
- Navigate to /edit/ and authenticate with admin/p@ssword
- Download flowconfig.json
- Download appconfig.json
If you want/need to restore these, upload them again. Immediately after uploading them, reset the controller. It should pick up the new configuration. This is incidentally how you would back up and restore settings for an upgrade with BrewFlasher.
"Someday," I'd like to make that fancier ... one insurmountable obstacle at a time.
...and I think I see the problem:
Code:
"rpintstarget": {
"host": "192.168.1.165",
"port": 1883,
"username": "RaspberryPints",
"password": "password",
"topic": "kegcop",
"update": false
},
OP
OP
We’ll look at that. Now I know where to look.
The same thing is true of the URL target--entering a URL still leaves "update" set to "false." But strangely, "update" is set to true for taplist.io, for which I don't have any configuration entered. I don't know if I should be seeing enable/disable buttons for the different targets, but I'm not.
OP
OP
I’m doing important stuff right now (drinking a beer and eating a burger) but I’ll look when I get home.
But if I can upload appconfig.json, presumably I can edit it before I do so. So what happens if I change the configuration to this, and then upload it?
Seems worth testing...
Code:
"rpintstarget": {
"host": "192.168.1.165",
"port": 1883,
"username": "RaspberryPints",
"password": "password",
"topic": "kegcop",
"update": true
},Similar threads
