1. Why is the Profile accessible through both the main menu, as well as the Set menu? This seems repetitive, and possibly confusing.
2. Based on #1, why not have the "Run" function located on the main menu instead of having it inside the "Set" menu?
So basically, the main menu would contain:
1. Run -- choose to then find a profile to execute. However, don't have settings on the Profiles when you choose. So basically, I'd press S to bring up the main menu, then choose "rn", then choose Pr0, for example, and it's done. No settings to bring up, etc. Just a very quick and to-the-point execution of a profile.
2. Set -- show all settings, but also show profiles. Or perhaps, somehow have the profiles as a submenu inside the Set menu. But bottomline, keep the settings of setpoints and durations for profiles somewhere inside the "set" menu, and nowhere else.
Thoughts?
Ok, I'll address this part, since it seems the temperature readings are well within tolerance for you now.
Profiles should not be accessible both from main menu and set menu. If they are, something is wrong...
Ideally (from my point of view, that is from code), everything should be under main menu, but scrolling through 60 points of profile settings to get to the value you want to set is just going to be unusable. So I pretty much had to add submenus.
It might not be obvious to the non coder, but every value to be set, is under a submenu item, which is under a menu item. There is quite a bit of cleverness to get this working at all with this limited hardware. So, in short, I just don't have the freedom to move things around. It just has to be this way, if all the settings needed are going to fit, and not just have one long list.
Don't get me wrong, I hear what you are saying, it probably isn't the MOST intuitive interface, still I think I've done pretty good, given the limitations. Compare with the stock firmware. That would be the alternative, instead F00-F63 where you'd need the manual at hand, to know what you are actually setting...
Hmm, I tried the current version twice and got the same results (buttons don't work) before I reverted back to the previous version (which still worked fine).
Alpha or Nick, any ideas why it might be doing this on mine? Anything different I can try?
BTW, I'm not supplying AC power to it when flashing. Doesn't seem to need it unless you think it might be causing my problem.
Thanks
I have been investigating this a bit, but since I cant reproduce, it is very hard. As I said earlier, I've seen the issue, but not since I gave up on trying to use global state variable.
It seems very strange, that you still have this issue, even with latest code and it worries me. If you have the issue, then it might be due to some slight difference in revisions in the MCU, and then others may suffer from it as well.
I'll see if there is any other way I can pass the state from menu back without incurring RAM penalty, if not I can try to use another register perhaps and see if that solves the issue.
I can send you a PM, when I have uploaded new code, that could affect your situation.
Edit: And yes, do not have the STC-1000 powered when flashing. That is, it should not be plugged in at all. It does not seems like uploading code is the issue for you.
Brewpi is interesting. I've been following it since Uberfridge days. However, there are still several issues with Elco's chosen method of control---and the basic implementation. Really the nicest thing about brewpi is the UI and its Rpi based features.
Specifically, it doesn't support direct heating of a fermentation vessel---ie, a heater attached to the side of the fermenter. Second, it requires a separate Arduino uno/leonardo, and associated hardware for every control point (fermenter, etc). The arduino alone costs more than an STC-1000, and I still need an SSR, and a temperature probe. With case an all, each Brewpi control point will cost around $40. Besides, I've already got the STC-1000's. I have a total of 6 managing my fermentation chamber and 4 separate fermenters. So...free or spend another $240+ for a BrewPi setup?
So, if a primitive protocol could be implemented using the EUSART to allow I2C type of access to several STC-1000's that are then managed by an Rpi (or a Teensy 3.1) that would have a lot of value.
While I think it might be possible to add communication (or rather write a new firmware for this). I don't think it will as useful as you think.
BrewPi is an awesome project. The regulation algorithm it uses 1. requires both beer temp and fridge temp (STC-1000 has just one sensor), 2. I think it would be a real challenge just fitting anything near this algorithm in the tiny controller that the STC-1000 sports.
Anyway, this is well outside this project. But if someone wants to give it a shot, then go for it
Edit: I must admit, I had not read the post carefully enough. If a simpler control algorithm is sufficient, then this can probably be done. You will need to do some hacking on the BrewPi side as well, as it communicates by sending JSON strings. That will not be feasible for this. The PIC16F1828 in the STC-1000 is an order of magnitude smaller than the ATmega328 in the Arduino. So, still anything like this will not be included in this project, but is not unreasonable for another firmware. I think you are even lucky enough that the communication pins can be directed to the pins on the programming header, so they can be easily accessed.