Simplifies configuration

[ChristianSteffens]

I just started working with SmartEVSE and noticed some issues regarding its configuration.

If needed / expected I can split the different changes into separate MRs.

• Regarding the configuration.yaml for HomeAssistant: The domains needed a matching local suffix (instead of lan) - that's how it's set in the mDNS configuration of the SmartEVSE.
• For the error identifiers and their descriptions the variable StrErrorNameWeb have been defined twice (only the global. / static one remains now).
• I added the serial of the SmartEVSE to the JSON payload.
• It's possible to disable the different meters from the menu by setting the EM_DISABLED value (0) as the minimum allowed value. Previously a mains meter has to be defined as soon as smart or solar mode is active.
• Allowed the usage of EM Meter addresses starting from 0x1.

Furthermore I started renaming and adding some configuration #define. I'm not sure your willing to change them, but I find the current implementation quite error prone. IMHO it would be better to explicitly specify a default, minimum and maximum value for each configuration property and using the allowed values / defines explicitly.

I tried this approach for the MODE, CONFIG, MAINS_METER_MEASURE. Please take a look - I'm happy to apply the changes to the remaining configuration properties as well.

Besides this imminent changes I'd like to propose some other changes and also provide a more detailed README. I did struggle to enable my EV Meter only to noticed (from looking at the code) that I need to explicitly enable the Smart or Solar mode. But that's outside the scope from this MR.

[dingo35]

Hi Christian,

Thank you for putting effort in improving the SmartEVSE code! Comment on your points:

• configuration.yaml : you are right , most networks have .local as a suffix ; however, it is becoming obsolete since (only since a few days!) we have a custom component for integrating SmartEVSE with HomeAssistant: https://github.com/dingo35/ha-SmartEVSEv3; so I'm planning to remove the configuration.yaml entirely since the custom component is much easier and less vulnerable to HomeAssistant changes.
• StrErrorNameWeb: you are absolutely right, this double declaration makes no sense. However, you are deleting the wrong one; it is considered good practice to have as few global variables as possible, so keeping it inside the getErrorNameWeb function is considered better practice. I will change this soon.
• some people consider the serial number "sensitive" information; apart from that, I see no practical use for it in another application? even the custom component detects it automatically ....
• the possibility to disable the Main Meter: when you disable it in Smart Mode or Solar Mode, you are effectively running in Normal Mode. So I am considering to implement this, but then to remove Normal Mode (to avoid confusion by the user, who thinks he's running in Smart/Solar but effectively in Normal). I will be rethinking this because this can be very confusing for users who are used to the original firmware....
• the kWh meter's addresses are reserved for Node SmartEVSEs, so this is a really bad idea....
• in general I do not like your MINIMAL/MAXIMUM/DEFAULT for all configuration defines. It multiplies the number of lines of code, changes (if done correctly) nothing for the end-user, and doesn't improve readability. IMHO it is bad practice to use integers for something else then integers, and we should use enums type (e.g. enum EnableC2_t { NOT_PRESENT, ALWAYS_OFF, SOLAR_OFF, ALWAYS_ON, AUTO }; or enum Mode_t { NORMAL, SMART, SOLAR } . This would make code a little more readable and makes it possible for the compiler to do more checks (so that Mode = 4 would not be allowed).

Also in general we prefer atomic pull requests so we can "pick and choose".....

I´m sorry to be so negative on your PR, I hope I explained it clear enough!

[ChristianSteffens]

the kWh meter's addresses are reserved for Node SmartEVSEs, so this is a really bad idea....

OK, this I understand, but most (if not all) of the meters I use have by default the address 01. But I'll change my meters address.

the possibility to disable the Main Meter: when you disable it in Smart Mode or Solar Mode, you are effectively running in Normal Mode.

Again, this also makes sense. But how do I use only the EV meter in Normal mode? The menu structure only provides the EV meter option in case the mode is Solar or Smart. I don't need any logic in regard to loading, but simply like to track the energy / current during loading.

Using enum instead of defines is even better.

[ChristianSteffens]

The custom component URL is invalid? Or not public?

[dingo35]

Copy / paste error with the link, I updated it.

As to using only the EV meter and running in Normal mode, one could argue: why wouldn't you just run in Smart mode?

But it really is an architectural question. SmartEVSE started with the assumption that you either have no meters and run in Normal mode; if you add a mainsmeter you can guard your mains breakers by running in Smart mode; if you want to have your energy usage monitored you can add an EVmeter. O wait now we can use that to guard that too, even when multiple SmartEVSEs are used (with load balancing = on). Then we added the web-interface, so now people want to read the values from their meters, even when running in Normal mode.

Very legitimate question, but all the logic written before assumes that Normal mode means no meters or only a Sensorbox connected.... Personally I think now that it is best to be able to disable mainsmeter, and then eliminate Normal mode (why would you not use data on charging when it is available?), but that might be a large operation and also error-prone; I do not have the time currently to do that, and I also would like to know the opinions of my fellow developers, and also from the manufacturer.....