I just realized that the tap labels / tapid aren't populating in the web interface after update in the alpha[1.1.0-Alpha.3] release (tapio branch)

The actual update of the object works (confirmed via API):

But, the web interface doesn't seem to pull the data correctly:

Chamber setpoint changes work in F, not in C. Reported in this post.

I've posted some info at https://www.homebrewtalk.com/threads/keg-cop-keg-monitoring-and-control.692880/page-6#post-9300514

When I click on the tan(ish) bar showing temperature on the main Keg Cop (ESP32) web page, I get two error messages:
Settings Error: Settings update failed.
Temps Warning: Unable to retrieve temperature data.

After that happens, when I use the menu to choose any other page, I get a 404 error. The only page that doesn't happen on is the external Keg Cop documentation menu link. I can't get out of the 404 error loop using the menu at all. Only when I manually remove the /404 in the URL can I get back to the Keg Cop (ESP32) web gui. This also happens when I'm on the Temperature Sensors for Kegerator page and click on the link "Control point: Keg Sensor" -- the same exact results as previously explained.

If I never click on those two links, the Keg Cop web page (ESP32) works perfectly.

I get the same results in both Brave and Edge browsers.

See if we need to incorporate this.

Add support for Kasa switches:

https://github.com/thorrak/brewpi-esp8266/tree/experimental/src/tplink

I have a tower temp probe and a fan to blow cold air up there when needed. The fan is pretty noisy and I don't want it running all the time.
I currently use CraftbeerPi3 to control my Kegerator and it has the ability to turn the fan on/off based on the tower temperature probe. Could you add this feature into KegCop so that it can do the same?

The subroutine that allows manually entering pours seems to be generating watchdog resets when using the web interface as well

For anyone else reading this, this is NOT a user workflow bug, this is just something that bugs me.

The default WiFi AP password in the config JSON is "kegcop21":

This differs from the fallback if no config file is present:

Dear Lee,

it is fun to see what you are working on over here. It looks like an excellent project. Kudos!

May I humbly ask you a specific question, as I see you are using MQTT within your architecture. In the README, it says:

Keg Cop will report pours to Raspberry Pints via MQTT or a web endpoint with a generic JSON packet.

Can you outline the typical JSON message(s) emitted by this appliance, and the corresponding MQTT topic structure? Is it some measurement values?

I am asking because I am thinking that Kotori may be a sweet complement for your system ¹. It is easy to write adapters for individual device families, and if that would fit together in any way, I will be happy to provide a corresponding adapter for Keg Cop.

With kind regards,
Andreas.

Somehow in all the fun I re-introduced a 404 issue when clicking on a temperature bar on /temps/.

Add support for the Uno per kegscreen-mvp #12.

The 404 problem certainly appears to be fixed. But I do now get a different problem. It looks like a possible typo in the web page link.

When looking at the “Temperatures” page and clicking on one of the tan/orange temperatures shown, it goes to a bad link (see in the screenshot below)

192.168.2.247settings.htm’s DNS address could not be found. Diagnosing the problem.

DNS_PROBE_POSSIBLE

Originally posted by @rkhanso in #51 (comment)

From Danb35 on HBT:

I started moving all the information down--tap 4's name/volume to tap 5, tap 3 to tap 4, etc. But when I went to put tap 1's information into tap 2, tap 2 started behaving the same way--no response at all to the update button. Turns out the remaining volume (which I'd copied from Raspberry Pints) had too many digits (3.32419). Shortening it to 3.3242 allowed it to accept the value. So then I moved all the data back up one slot, and tap 1 saves properly now. There's surely no need to measure volume to 0.00001 gal., but this seems an odd failure mode.

I can’t calibrate the flow meter with the new devel firmware. I was able to successfully calibrate it in 1.0.0, however.

When I go to the calibrate page, Select Tap 9 (that’s the one and only I’m using since the 1-sided PCB made it easier), Config by volume, enter in some ounces measured, but don’t get a 0 to show up in the Pulses box until the flow starts. No pulses seen at all.

Originally posted by @rkhanso in #51 (comment)

Similar to a previous and now closed issue #9, when I change the numbers on the Temperature Sensor Control page, nothing changes in the temperature output on the Temperature Sensors data page. Calibration is not possible.

E.g.: https://docs.kegcop.com/en/latest/context/settings/temperature/api/v1/info/sensors/index.html

I also noticed a spelling error – Temperatire

When you choose a tap, it shows in the GUI the correct tap number for all except for Tap 9 (It says Tap 8 Configuration)

I'm using the Keg Screen functionality as a sort of 'web hook' to allow for reactive updates to an LCD screen instead of constantly polling the API.

I'm mostly using the temp and pour reports for my LCD, but while testing I noticed that the tapinfo report was always failing.

Here's a serial log of what I see. You can see I navigate to the taps page and toggle a tap to be active.
This triggers the tap report POST, but it fails.

2022-06-21T14:21:06Z V: Processing post to /api/v1/config/taps/.
2022-06-21T14:21:06Z V: Checking handleTapPost.
2022-06-21T14:21:06Z V: Processing [tap]:(1) pair.
2022-06-21T14:21:06Z N: Settings update, processing [tap]:(1).
2022-06-21T14:21:06Z V: Processing [ppu]:(21120) pair.
2022-06-21T14:21:06Z N: Settings update, [ppu]:(21120) applied.
2022-06-21T14:21:06Z V: Processing [beername]:(Test1) pair.
2022-06-21T14:21:06Z N: Settings update, [beername]:(Test1) applied.
2022-06-21T14:21:06Z V: Processing [cap]:(5.0000) pair.
2022-06-21T14:21:06Z N: Settings update, [cap]:(5.0000) applied.
2022-06-21T14:21:06Z V: Processing [remain]:(4.8000) pair.
2022-06-21T14:21:06Z N: Settings update, [remain]:(4.8000) applied.
2022-06-21T14:21:06Z V: Processing [active]:(active) pair.
2022-06-21T14:21:06Z N: Settings update [1], [active]:(active) applied.
2022-06-21T14:21:06Z W: Warning: Previous transaction for Taps POST is in an unknown state (0).
2022-06-21T14:21:06Z V: Checking handleTapCal.
2022-06-21T14:21:06Z V: Processing [tap]:(1) pair.
2022-06-21T14:21:06Z V: Processing [ppu]:(21120) pair.
2022-06-21T14:21:06Z V: Processing [beername]:(Test1) pair.
2022-06-21T14:21:06Z V: Processing [cap]:(5.0000) pair.
2022-06-21T14:21:06Z V: Processing [remain]:(4.8000) pair.
2022-06-21T14:21:06Z V: Processing [active]:(active) pair.
2022-06-21T14:21:07Z V: Checking handleSetCalMode.
2022-06-21T14:21:07Z V: Clearing any calibration flags before setting new flags.
2022-06-21T14:21:07Z V: Processing [tap]:(1) pair.
2022-06-21T14:21:07Z V: Processing [ppu]:(21120) pair.
2022-06-21T14:21:07Z V: Processing [beername]:(Test1) pair.
2022-06-21T14:21:07Z V: Processing [cap]:(5.0000) pair.
2022-06-21T14:21:07Z V: Processing [remain]:(4.8000) pair.
2022-06-21T14:21:07Z V: Processing [active]:(active) pair.
2022-06-21T14:21:07Z V: MQTT: No broker configured.

From my testing the pour, temp, and cooling reports all POST just fine.
I have not tested the kick report.

When clicking a tap on the main screen it seems to only follow a numerical order no matter what taps are inactive or renumbered. I currently have taps 1, 2, 4, and 5 active. I have also renumbered taps 4 and 5 to show up as 3 and 4 on the home screen. When clicking the renumbered tap 3, which is actually tap 4, it takes me to tap 3 settings even though tap 3 is inactive.

Similar to #35, the various temp sensor settings are called different things depending on if it's in the JSON being emitted or the form being posted back. Example for the room sensor:

Called "calroom" / "enableroom" when being posted back:

but just called "room" / "roomenabled" when being emitted in the JSON:

Found a bug in the taplistio implementation -- This line should be

if (flow.taps[tapid].taplistioTap <= 0 || flow.taps[tapid].taplistioTap > 255)

On occasion, the WiFi connection will disconnect and fail to reconnect:

[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
[WiFi-event] event: 1
[WiFi-event] event: 5
[WiFi-event] event: 4
[WiFi-event] event: 7
[WiFi-event] event: 1
[WiFi-event] event: 5
[WiFi-event] event: 4
[WiFi-event] event: 7
2023-04-12T14:18:03Z N: Reboot request - rebooting system.
[WiFi-event] event: 5
[WiFi-event] event: 3

This seems to be the same as Wifi connection fails - only works after router reboot #8412 in the ESP8266 core for Arduino, and is explained REALLY well in ESP32 STA deauth frame causing reconnect issues (IDFGH-6544) #8192. The tracing tablatronix did here almost mirrors what I saw.

So now, I get to find a more graceful way (e.g. a hack) to recover from this because even if the newer core is better, it exhibits quite a bit more instability.

Thankfully, this results in a controlled restart (under Keg cop control) so it's not horrible. The worst part of it is that the compressor lockout may cause a kegerator to be off while that timeout runs out.

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.
Unplugging the USB cable used to flash the new firmware and check the logs, and plugging in the USB charger.

I think the latest library update broke some functionality with the HTTP POST.

Previously, I was using the Keg Screen target functionality of Keg Cop to send reactive reports to an LCD screen.
I specified the port in the target field (e.g. http://keezer-lcd.local:8080 ) and it worked fine.
Since the latest update, after the library and platform update, the port specification seems to be ignored.

I can see requests come in only if I start a server on port 80 regardless of which port I set in the target field.
For example: if I start the server on port 80 then I see requests even if it say port 8080, 8334, 1337, etc in the keg screen target field -- this leads me to believe that the code is ignoring the port designation altogether now.

This may be outside of the scope of the intended use.
Is keg screen only foreseen to operate on port 80?

As mentioned at https://www.homebrewtalk.com/threads/keg-cop-keg-monitoring-and-control.692880/post-9308518, I think it'd be helpful for Keg Cop to allow for entering the quantity of beer in a keg using weight. Given empty weight of the keg, full weight (preferably allowing for units different than the system default for either--for example, I'd be using US gallons for my system, but the math is simpler with kilograms, as is parsing the input values), and specific gravity of its contents, the quantity of liquid can be easily and precisely determined.

See if we can sort the file list without too much trouble.

As reported in this post there may be an issue with the number of connections or how they are stored. When using @thorrak's branch, so far, the crashes seem diminished/eliminated. Tracking an issue here.

The page docs/planning/index.rst has an error:

Daisy-Chain Boards: These small boards, one per flowmeter, connect the flowmeter(2) into the system. There is an “In” and an “Out” port, creating a chain of up to six sensors. The first on the chain is always number one, and so on.

This is a throwback to an earlier design and should show a max of nine sensors in a 3-3-3 configuration.

Recomonmark seems to be deprecated, move to MyRST.

Need a case to cover the Daisy Chain board.

This board will be one per flow meter, and just a "dust cover" really for the board. No electronic components are present except for the PCB-mount RJ45 connectors.

The board is intended to strap to the beer line with zip-tie slots on the board. The case should just snap over the top. This could leverage the RJ45s as stand-offs, or incorporate stand-offs in the lid to be printed. The part that clips to the sides could be tabs clipping over the board.

I expect this will print upside-down. It might be nice to have numbers, 1-8 in the cover to denote which sensor is plugged in. Also, so means of denoting "In" and "Out" on the two RJ45s to keep things straight.

Version 1.0.0 works fine
Just installed version 1.1.0. Reconnected to my wifi. that works. Web page works. However, none of the settings changes can be saved. Getting error Settings Error: Settings update failed.
Not sure where and how to debug

When calibrating the flow meter I choose the correct tap (#9) and then check the Volume button and press “Do Config by Volume". In the older versions of firmware, on the next screen a 0 would populate right away in the Pulses box and when I got some flow going, the count would increase. In the Development firmware, a zero doesn’t immediately show up in the Pulses box and nothing happens when get some flow going. Pulses don’t increment, but the fact that it behaves different between v1.0.0 and devel makes me think it’s a firmware/coding problem and nothing on my end. It doesn’t matter whether I enter any ounces first or not, it doesn’t appear to count pulses. I’ve tried choosing different Tap numbers and that doesn’t make any difference either (didn’t expect it to though).

With the new libs and platform libs, SPIFFS Editor is broken (/edit.) This will not be enabled when in release mode, however it's annoying as hell and I am going to leave this open till I fix it or get tired of seeing this issue open.

On some resets (such as when a new firmware is pushed) the temperature sensor and control settings get cleared.

When selecting a tap from the Calibrate section, the arrow for the dropdown is missing. This makes you hold the left mouse button in order for the menu to appear. Could not get the menu working at all on a tablet

The internal tap IDs (0-8) and the tap IDs as displayed in the interface (1-9) don't match

Temperature calibration does not seem to apply.

excuse me while I go cry about the implication.

Unfortunately, mDNS service discovery doesn't seem to reliably announce the _kegcop._tcp. service when attempting to browse services on the network.

I think this relates to espressif/arduino-esp32#7156

Currently the cooling only works when wired Normally Open (it says so in the docs to do this 😄).

However, some people don't feel comfortable building their own high voltage relays so opt for off-the-shelf products (e.g. powerswitch tail from adafruit or the IoT Relay from Digital Loggers).

As such, it would be nice to allow inverting the Cooling signal to be wired as Normally Closed.

Looking at code, I think it's as simple as turning the HIGH/LOW argument of the digitalWrite function into a variable within the thermostat.cpp.

I'll try to do this update myself and submit a pull request.

Thoughts?

From #20

I'm not sure what happened, but as of these last few builds I can no longer monitor serial out.
As soon as I connect via PuTTY it causes a panic (see log below).
Also, rebooting doesn't fix it. I have to hold the 'boot' button for a few seconds before it will properly reload the firmware.

If I don't connect on the serial line and just let it go then it works fine and I can interact with it via the webpage / API.

    rst:0x1 (POWERON_RESET),boot:0x13 (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:0x3fff0018,len:4
    load:0x3fff001c,len:1044
    load:0x40078000,len:10044
    load:0x40080400,len:5872
    entry 0x400806ac

    1970-01-01T00:00:00Z N: Serial logging started at 115200.
    1970-01-01T00:00:00Z V: Starting WiFi.
    *WM: [1] Free heap: 246792
    *WM: [1] ESP SDK version: v3.3.5-1-g85c43024c
    *WM: [3] allocating params bytes: 20
    *WM: [2] Added Parameter: name
    *WM: [1] AutoConnect.
    *WM: [2] esp_wifi_set_country: US
    *WM: [2] ESP32 event handler enabled.
    *WM: [2] Connecting as WiFi client.
    *WM: [3] STA static IP:
    *WM: [2] setSTAConfig static ip not set, skipping.
    *WM: [1] Connecting to saved AP: REDACTED
    *WM: [3] Using password: REDACTED
    *WM: [3] WiFi_enableSTA: enabled.
    *WM: [3] Mode after delay: STA
    *WM: [2] 30000 ms connectTimeout set.
    *WM: ▒▒] 30000 ms timeout, waiting for connection................Guru Meditation Error: Core panic'ed (Interrupt wdt timeout on CPU0)
    Core 0 register dump:
    PC 0x40086e6 PS 0x00060834 A0 0x8012c10 A1 0x3fa3e
    A2 0x3fc604 A3 0x00000000 A4 0x00000000 A5 0x3fcd0
    A6 0x00000002 A7 0x00000100 A8 0x8008a44 A9 0x3fa3f
    A10 0x00000005 A11 0x00060c3 A12 0x00060c0 A13 0x3fa488
    A14 0x00000017 A15 0x00000000 SAR 0x00000020 EXCCAUSE 0x00000005
    EXCVADDR 0x00000000 LBEG 0x4000ce LEND 0x4000cf LCOUNT 0xffff

    ELF file SHA256: 000000000000000

    Backtrace:0x40086e6:0x3fa3e 0x4012c0d0x3fa420 0x4012c19:0x3fa450 0x40130ff0x3fa480 0x40089be0x3fa4b

    ore 1 register dump:
    PC 0x4018762a PS 0x00060834 A0 0x8016d1e A1 0x3fb7a
    A2 0x00000000 A3 0x00000001 A4 0x80089d0 A5 0x3fba0
    A6 0x00000000 A7 0x3fb4a A8 0x00060023 A9 0x3fb310
    A10 0x00000000 A11 0x00000001 A12 0x80089d0 A13 0x3fb8b
    A14 0x00000000 A15 0x3fb4a SAR 0x00000000 EXCCAUSE 0x00000005
    EXCVADDR 0x00000000 LBEG 0x00000000 LEND 0x00000000 LCOUNT 0x00000000

    ELF file SHA256: 000000000000000

    Backtrace:0x4018762a0x3fb7a 0x4016d1b0x3fb7c 0x4008b7d0x3fb7e 0x40089be0x3fb800

    Rebooting...

When on the Temperatures page and clicking on any of the tan/orange temperature graph/columns, the link it wants to take you doesn't exist. It appears to want to take you to the Settings page, but the URL has a typo.

http://192.168.2.247settings.htm/#sensorcontrol <<<---where it wants to take me, but a bad link.
http://192.168.2.247/settings/#sensorcontrol <<<--- I think this is where you intended it should take me.

The setting to enable/disable temperature control is called two different things in the code. It is called "controlenabled" when being output as part of the settings JSON, but the field to set it is called "enablecontrol"

Where it is output:

Where it is read:

Not any limiting issue, but it's network traffic we don;t need:

index.htm:

2023-04-13T16:14:13Z V: Sending /api/v1/info/secret/.
2023-04-13T16:14:13Z V: Sending /api/v1/info/secret/.
2023-04-13T16:14:13Z V: Sending /api/v1/info/sensors/.
2023-04-13T16:14:13Z V: Sending /api/v1/info/sensors/.
2023-04-13T16:14:14Z V: Sending /api/v1/config/theme/.
2023-04-13T16:14:14Z V: Sending /api/v1/config/theme/.

settings.htm:

2023-04-13T16:15:17Z V: Sending /api/v1/info/thatVersion/.
2023-04-13T16:15:17Z V: Sending /api/v1/info/thatVersion/.
2023-04-13T16:15:17Z V: Sending /api/v1/info/secret/.
2023-04-13T16:15:17Z V: Sending /api/v1/info/secret/.
2023-04-13T16:15:17Z V: Sending /api/v1/info/thisVersion/.
2023-04-13T16:15:17Z V: Sending /api/v1/info/thisVersion/.
2023-04-13T16:15:17Z V: Sending /api/v1/info/tempcontrol/.
2023-04-13T16:15:17Z V: Sending /api/v1/config/theme/.
2023-04-13T16:15:17Z V: Sending /api/v1/config/theme/.

temps.htm:

2023-04-13T16:16:27Z V: Sending /api/v1/info/sensors/.
2023-04-13T16:16:27Z V: Sending /api/v1/info/sensors/.
2023-04-13T16:16:28Z V: Sending /api/v1/info/secret/.
2023-04-13T16:16:28Z V: Sending /api/v1/info/secret/.
2023-04-13T16:16:28Z V: Sending /api/v1/config/settings/.
2023-04-13T16:16:28Z V: Sending /api/v1/config/theme/.
2023-04-13T16:16:28Z V: Sending /api/v1/config/theme/.

help.htm:

2023-04-13T16:17:28Z V: Sending /api/v1/config/theme/.
2023-04-13T16:17:28Z V: Sending /api/v1/config/theme/.

about.htm:

2023-04-13T16:17:55Z V: Sending /api/v1/info/secret/.
2023-04-13T16:17:55Z V: Sending /api/v1/info/secret/.
2023-04-13T16:17:55Z V: Sending /api/v1/info/thisVersion/.
2023-04-13T16:17:55Z V: Sending /api/v1/info/thisVersion/.
2023-04-13T16:17:55Z V: Sending /api/v1/info/uptime/.
2023-04-13T16:17:55Z V: Sending /api/v1/info/uptime/.
2023-04-13T16:17:55Z V: Sending /api/v1/info/resetreason/.
2023-04-13T16:17:55Z V: Sending /api/v1/info/resetreason/.
2023-04-13T16:17:55Z V: Sending /api/v1/config/theme/.
2023-04-13T16:17:55Z V: Sending /api/v1/config/theme/.
2023-04-13T16:17:56Z V: Sending /api/v1/info/heap/.
2023-04-13T16:17:56Z V: Sending /api/v1/info/heap/.