Summary of what this PR do:

• Enables cppcheck and clang-tidy and adds them to the github workflow (only critical issues break the build)
• Clang-tidy gives more false positives it seems but it's still good to have it
• Clang-tidy can be fine tuned in terms of what plugin it uses, I chose a very basic set
• Clang-tidy doesn't work well with ino files, so I renamed the main sketch to gaggiuino.cpp, this makes using Arduino IDE difficult, but I hope that everyone uses something better already. Moreover once the code begin to get bigger and more structured we need to introduce cpp/h files anyway (which would make using Arduino IDE impossible probably).
• Fixes most of the issues reported by cppcheck, the most critical one is this 1d4b2e549493f3b3f6a3be36e0e5cc6b8c1e3dcf
• Adds -Wall build flag and strict lib_compat_mode to all platforms
• Bumps Nextion library to the revision with boolean->bool fixes

I'm undecided on where to leave the USB charger for Arduino. Whether inside/outside the back of the machine :)

Outside:

• look uglier
• practical for Arduino code updates
• more safe in terms of water leaks / contact

Inside:

• neat look
• risk of getting wet
• less practical for updating Arduino code

Did you already experiment with the different possibilities? Where did you left yours?

Hi again, since my previous (first!) pull request was appreciated I prepared another, more radical, one.

LF is the defacto standard since it's used by Mac and Linux and Windows are mostly fine with it (batch files may be the only exception where LF endings cause troubles). Until this commit most of the files in this repo used a LF line endings anyway, the only exception were *.ino files which mostly used CRLF with couple of lines with LF. These mixed line endings cause troubles to those using VSCode since it doesn't support it (https://github.com/microsoft/vscode/issues/127) so it's impossible to save a changed file without normalizing its line endings (and making the commit much bigger). This commit also introduces .gitattribute and .editorconfig files which will ensure correct formating in the future (strangely Arduino IDE doesn't support the latter one https://github.com/arduino/Arduino/issues/8804).

I'm aware that this commit will make using of git blame and exploring of the project history a bit more difficult but it's better to bite the bullet now than later. Also I didn't send this pull request just to make the repo nice and tidy but to prepare the surface for more pull requests I have in the queue.

Here's a nice blog post about git and line edings if you want to learn more: https://www.aleksandrhovhannisyan.com/blog/crlf-vs-lf-normalizing-line-endings-in-git/

Thanks!

Is your feature request related to a problem? Please describe. On dev branch, I see your update on the Steam control wiring which connect gnd and a7 to the switch. That's smart. But I think there is an issue for the steps:

1. Move steam switch wire 4 to steam switch pole 1.
2. Unplug and secure steam switch wire 5.
3. Replace the SSR brew thermostat connected wires with the steam thermostat wires.
4. Bridge the brew thermostat wires(the wires we just disconnected from te SSR in favour of the steam thermostat ones)

Describe the solution you'd like

1. I think there is no need to move steam switch wire 4 to switch pole 1. It can be disconnected directly. Instead move the wire 4 to pole 1. The LED light white wire which connect to wire 4 could be disconnected from LED and have a wire connect the LED light to switch pole 1. My thought is that, when steam switch is on, we could set boiler (brew) SSR to HIGH to make the boiler keep heating until the desired steam temperature reached. And leave the steam thermostat as a safety fallback. The steam thermostate max at 145 C, as long as the steam temperature is not beyond 145 C, it will allow the boiler keep heating if the brew SSR is high.
2. Steam thermostat and wires should remain unchanged as a safety fallback.

My understanding on Gaggia Wire Diagram, the steam thermostat and brew thermostat is kind of in serials. The steam thermostat's output connect directly to boiler, and it has two input source: one is steam switcher, another is the output of brew thermostat. So when steam switch is OFF, the power came from the brew thermostat if it is not exceeding the brew temperature. If the temperature exceeds the brew temperature, then the brew thermostat shut off the power. If steam switch is ON, then the brew thermostat will be shortcut by the steam switch and only steam thermostat in effect.

So with the arduino controlling the brew thermostat (brew SSR), there is no need to have a second power source from steam switch to the steam thermostat and only need to connect the LED to the steam switch to keep the light indication working.

Not an electrician, would love to hear your feedbacks.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

This is awesome project. While I'm waiting for my hardware delivered, I'm reading through the code and figuring out how I could adapt it to the RTD Pt100 which I purchased.

The original code looks like doing 1 read (fail) -> 1 read (fail) - empty loop for GET_KTYPE_READ_EVERY milliseconds -> read -> empty loop -> read. Which seems not matching the minimal interval between two reads. It is two immediately reading and then follow the interval. Is that on purpose?

I have all the items on order that you have listed but I mistakenly got the 3.5" screen. I have loaded up everything in HMI and found that the software wont scale the content to the new screen size. What would be the best way to scale this? Could you share your PNG files?

On the link provided there are some variations, and in all other hardware listings the variant is very handily specified.

So I'm wondering does it matter which of these I order? Can I order the USB-C one without issue?

Thanks for this project!

Is your feature request related to a problem? Please describe. The README does a great job at describing how to build the Gaggiuino. However, the description and feature list is incredibly sparse. I'm not 100% sure what this project would let me do or not do. The videos are a start, but they're not a replacement for documentation.

Describe the solution you'd like

overview

First, a nice OVERVIEW at the top of the README. For example, "this mod lets you control the temperature and pressure profiles of your Gaggia. It allows you to preinfuse your shots. Future features include a built-in scale that lets you graph your shot over time and even automatically stop a shot (will it?). The overall parts list costs around $100 USD (or whatever) if you buy in the United States, or XXX currency in YYY country. However, pre-built machines with similar amounts of control cost many thousands of dollars. You should buy the parts ASAP, because they are back-ordered."

An extended "Features / Uses" section in the README

Each of the bullet points in the "Features / Completeness" list could be its own subsection of the README. I'm not sure what exactly all of these features are, or why I would want them necessarily.

• Temp control: Like the PID mods, this project improves the infamously bad temperature control of the Gaggia. We use a simple pulse-width modulation temperature control system to control temperature. You can set whatever temperature you want (can you?) etc. etc.
• Steam control and alerting: what does this mean?
• Preinfusion: does it just allow for 5 second 1-bar preinfusion? can you do profiles? I'm not sure!
• Realtime pressure feedback:does this require the "pressure sensor" in the EXTENDED FUNCTIONALITY section of the assembly instructions?
• Pressure profiling (realtime feedback loop)
• Manual pressure control: does this require the dimmer module?
• Realtime values update: what values?
• Saving selected values: what selected values?
• Descale program
• Brew start sense: what does this mean?
• Auto shot timer: what does this mean?

A description of the "Extended functionality" parts

What features do I need these parts for?

TL;DR: documentation!

Not a big git person, but I did mark up the Classic Pro wiring schematic to make it a little more clear what goes where. Not sure if this is something you want to include in the instruction GAGGIA_CLASSIC_2019_Wiring_Schematic.pdf s.

DO NOT MERGE BEFORE https://github.com/Zer0-bit/gaggiuino/pull/210

This PR adds cppcheck and clang-tidy static code analyzers to the GH workflows and fix couple of issues found by them. Please pay attention mainly to this d02c05141bfeb02ddb72ecdda44d66929f2486de commit - I'm not sure whether the correct fix is to remove the variable from that place or making it static.

During the process I had to rename the symlink in platformio_src to gaggiuino.cpp and add functions definition and include Arduino.h at the top of the file, that was the easiest way to make the clang-tidy work. I checked that Arduino IDE is fine with it.

Describe the bug After connecting all components, I think my relay isn’t switching. There is no led indicating change. I have heated up my thermocouple from way below the set temperature, to above the set temperature, and I see no led indicating change.

The pinout in the readme states the ground should be connected to relay pin nr. 3. Is this correct? Shouldn’t this be the 5 volt?

• This defines an AUTO_VERSION which contains either:

  • git sha of a commit the firmware binary was built from
  • content of VERSION file (this is supposed to be used mainly for github releases)
  • nogit if none of the previous data are available

• Adding the macro here https://github.com/Zer0-bit/gaggiuino/compare/dev...MartinHruza:gaggiuino:auto-version?expand=1#diff-d6a863d24c8ed77faa8d808068856fe68edbe35756d51aa7aaa80d781803468fR100 is a bit pointless since USB-CDC handshake is too slow

• It would be great to display this somewhere on the LCD so both users and developers would know what version they are actually running