Remove TP link from main

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[PoulKlemmensen]

Sorry for this. Don't want to make any changes to your code..... Wanted to work in my own version.... Sorry ....

[PoulKlemmensen]

I did not want to make any changes to your code.... Only wanted to have a copy of yours and work in that....

[thorrak]

Hah, no worries. If you’re interested in the v16 changes let me know and I’ll get you access to a few more repos. You can see where my head is at in the “rest” files. ;)

[PoulKlemmensen]

I am new to this, but want to try something out..... Hope not to disturb you more than necessary. Want to change your Kasa plug with Tasmota devices. Then to start with hardcode the names and see how far I can get with that....

[thorrak]

Oh, definitely. Let me know how I can help! Happy to provide guidance where I can!

[PoulKlemmensen]

Hi John... If you at some point have 3 minutes, I do have a question. No rush, I have plenty of time.... But I would like to add a parameter to the settings page in the arduino. I have unpacked the js file, but it seems like you are making this somewhere else... ?? Or ??

I have changed my code, so the fan inside the cooler will keep running for x minutes after the cooling have stopped. I have added the code to my version, but it would be nice to add the parameter to the settings page.... If I can figure that out as well.

[lbussy]

Poul, leaving aside the technical challenge for a bit:

The belief that you only need a fan while actively cooling is flawed. It might be an argument if the system were static in between cycles. The problem is your brew actively generates heat. Eventually, the heat will trigger a cooling cycle, but the sampling your temperature sensor does will be much more effective if the fan is always mixing up those stale pockets of warm air in your chamber.

Just something to consider.

[thorrak]

No worries at all -- that is definitely not well documented at the moment. Here's some notes for you:

BrewPi-ESP firmware changes

Storing a configuration option in BrewPi-ESP

Since this is a "BrewPi-ESP only" thing, I'd recommend adding the configuration option to the ExtendedSettings class. When updating this, you will need to do four things:

• Add a default value to setDefaults
• Update the toJson method to translate your setting to JSON
• Update loadFromSpiffs to properly load the value from a JSON file written out to SPIFFS
• Update processSettingsKeypair to handle updates to the value (mostly coming from the web interface)

Note -- For processSettingsKeypair, the other configuration options in ExtendedSettings all require some kind of special handling once set (e.g. resetting the LCD when the invert setting is changed). For what you are describing I'm guessing you probably won't need any kind of special handling, so you probably only will need a line like this one to update the setting in the singleton.

Handling updates from the web interface

Serving extended settings will automatically pick up the new entry due to the change you made above to toJson. You will need to make changes to properly parse incoming changes to your new setting, though. That's done in this function.

Once you've got that done, I think that the changes necessary to process/save/present the settings are complete -- then it's time to move onto the web interface.

Editing the web interface

The user interface can be found in this repo. It is written in JavaScript using Vue 3 + Vite -- the development server (and ability to point it at an actual BrewPiDevice) makes adding new features much easier.

My recommendation is to base all development on the v16 branch of the repo -- I've gone ahead and added some development notes to the Readme of this repo as well to help you out.

You're going to have to make changes in a couple places for this to work:

ExtendedSettings Store

All loading/saving of Extended Settings is handled in ExtendedSettingsStore.js. Take a look at that file -- it should be pretty straightforward what changes you need to make for the most part.

The main thing to be aware of is the fact that you will need to add a parameter to setExtendedSettings -- once you've done that, you will also need to update the corresponding call in the component (see below).

ExtendedSettings Component

The user interface itself for editing the setting is the ExtendedSettings.vue component.

This is the display of the form control for updating a setting (in this case a checkbox - not sure what kind of control you will need, but I can help find one elsewhere (or construct one) if you need).

The form control binds to one of these variables and is submitted via the function I mentioned earlier in the store here.

The values that are displayed are actually pulled into a cache in the component at load time by this function. This may be horrible practice (or there may be a reason not to do this) -- if you (or anyone reading this!) are a Vue expert, please feel free to let me know a better way. ;)

All said - there's a lot of places that the change needs to be made, but in most cases it's a few lines of code here and there. Writing this out probably took longer than it will take you to make the changes, but hey -- now it's documented!

[PoulKlemmensen]

@lbussy. You are completely right, and I will make that change at some point. This exercise for me is to try and create a version of the ESP32, solder free. But for me, the problem is, that the Kasa is not available in an EU version. My goal is to try and create it using Tasmota instead.

But as pointed out by @thorrak, it might not be that generic, but that might be ok for me. The next step for me is to try and get the Tasmota into the code. I have figured out to download code to the ESP32 and to make changes to the Vue web part as well, with help from @thorrak (Thanks!!). And I can get the Tasmota hardcoded into the Setup actuators part.

I have made a fork of the two repositories, but I am not that much into Github. Hope that this is ok, and that I don't interfere too much with your code.... But as I can understand by doing that, I have a way of keeping my version up to date. And you can chose to use whatever I am making.....

[thorrak]

You certainly won’t interfere with anything on my side, but you may find future upgrades require a slight bit of work to integrate with your changes. That said, pull requests are always welcome!