Project approach / purpose discussion

[jblance]

Use this issue to further discuss purpose
I'll update the discussion doc with content from here
Also note here (or PR) any alterations needed in discussion doc

[DMIINC]

Hi Jblance and others,

Thank you Jblance for all the help.

What is outlined in WIP discussion is something I have been thinking of since August of last year and is my ultimate goal for this year minus the electric car. The goal was to get one this year however due to virus outbreak that is placed on hold for now. However once solar panels are installed my goal would be to integrate different energy storage device instead of the car. Electric hot water heater inline with gas water heather already present in the home. During winter when sun is not as abundant as it is in summer use time of use tariff with power company to supplement power needs (charge batteries to certain level) which would help lower down the energy cost.

What I have:
53 KWh of LiFePo4 cells equally divided into 3 power walls.
3 LV5048 inverter/chargers
9 KW of solar panels waiting on HOA gods or a judge for approval to be installed.
3 Dumb BMS's. However they are well built and serve their purpose amazingly good. They limit charge/discharge at 120A and monitor cell voltage. If cell voltage is above or below limits they stop everything.
3 Balancers/monitors JKBMS (jblance is almost intimate with them, lol) for purpose of monitoring cell health.

Since Lithium chemistry has almost flat discharge curve at 0.2 C rate it is impossible to tell SOC by just looking at cell/power wall voltage. Reasonably accurate SOC device must be used in order to implement what is outlined in WIP discussion.

Reasonably accurate SOC device must take in to account Voltage, Amperage and Temp from power wall according to documentation I have read.

So far I have:
Volts provided by JKBMS
Amps provided by ADS1115
Temp provided by DHT22

All going to Raspberry Pi. I think with devices above I could implement majority of what is outlined in WIP discussion. I would preferably use solid state (SSR) relay to control when hot water heather would be operational depending on SOC of my power walls.

i.e. if SOC=>85% then SSR=on

When it comes to coding all of this in python, my skills are equal to .01% of jblance's. When it comes to physicaly integrating this properly I have no issues what so ever.

I do enjoy DIY projects and have accomplished many of them. I prefer DIY over someone else's solution that might not be able to accomplish everything I needed to do.

Thank you all,

[volkerjaenisch]

Sorry for the long delay. I was occupied with a new roof, a new greenhouse and lots of customer projects.

Today I started to code an intergration in Homeassistant (HASS) for the MPP-solar code.

So far I found no code samples to implement the device/subdevice structure we need for the modelling of mpp-solar devices. The developer documentation of HASS is more than sparse.

I asked for advice on the HASS dev-code chat channel, still waiting for an answer.

Meanwhile I will implement all the boilerplate for a Integration doing NOOP but works with the development system of HASS.

Cheers,
Volker

[jblance]

Hi
No problem re delay - none of us are doing this full time :-)
I have looked at HASS integrations too - I think this is the way to go.
I dont think the mpp-solar code is correct to integrate - even with the current usage there are 3 different 'inverter' types (or protocol formats / definitions)

I still think we need to do an inverter state model with configuration that allows different command protocols (as well as battery / battery monitor models)

Relays etc are (should) be covered by the switch functionality - but we may need to extend the base switch to allow more separation / security / safe guards. "Alexa turn off all switches... Power goes off"

[DMIINC]

For purpose of going in right direction here is what I have so far:

Repurposed PC that has Ubuntu 20.04 installed.
mpp-solar service running (3x LV5048 connected via USB to serial cables)
jkbms service running (3x jkbms connected via Bluetooth BLE)
Influxdb
Grafana
Virtual Box with HASS.IO installed (working great)
Started playing with ESP Home since I have couple of ESP32 and associated sensors. Generic setup is easy. Will need to determine if writing software for ESP32 module is better solution rather then taking sensor inputs and letting HASS manipulate data.

[volkerjaenisch]

Does the mpp-solar code run on ESP32?
I am happy with ESP32 as plattform for sensor data. Currently I am trying to get MQTT to run on an ESP32. If this succeeds I will try to port the mpp-solar code.

[volkerjaenisch]

While porting to ESP32 I run into some obstacles.

I use the stock MicroPython ToolChain. I freeze the mppsolar package and bundle it into the MicroPython image. To get more libs I utilize https://github.com/micropython/micropython-lib to drag selected modules into the image.

I already have MicroPython extended by the following libs from that source:

• argparse.py
• ffilib.py
• fnmatch.py
• glob.py
• logging.py
• posixpath.py
• stat.py

Now I run into this error:

MicroPython v1.12-483-g22806ed5d on 2020-05-31; ESP32 module with ESP32
Type "help()" for more information.
>>> import mppsolar
>>> mppsolar.main()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "mppsolar/__init__.py", line 50, in main
  File "mppsolar/mpputils.py", line 31, in __init__
  File "mppsolar/mppinverter.py", line 162, in __init__
  File "mppsolar/mppinverter.py", line 84, in getCommandsFromJson
  File "os/path.py", line 14, in abspath
  File "os/__init__.py", line 77, in getcwd
NameError: name 'getcwd_' isn't defined

This is a strong indicator that certain file system operations on ESP32 are not possible. These operations originate in your design decision to store the scheme of the Commands in JSON files.

Does your heart really belong to these JSON files? Why not put them into a single well documented python file?
This approach may be also of use if we have to deal with deviations in the protocols of different inverters. We can come up with per inverter protocols files

Cheers,
Volker

[DMIINC]

Just a quick question? I like idea of using ESP32 to handle Inverter commands and get data out of them. Would one ESP32 be able to handle 2 or 3 inverters in parallel?

[volkerjaenisch]

My knowledge on the ESP32 with Python is one day old.

In general the ESP32 has a lot of computing power, more than an Arduino. I fought my first Doom multiplayer battles on hardware less powerfull :-).

Do you mean
a) two/three inverter stacks or
b) a single inverter stack with two/three inverters?

b) is no problem and already covered by MPP-Solar.
a) is possible since the ESP32 has up to 3 UARTs. But an ESP32 costs near to nothing so I would assign an ESP32 for each inverter stack.

Utilizing ESP32 for data aquisition does not solve any problem with data management. We just push some functionality from the framework e.g. HASS or ESP HOME to the data aquisitioning device.

The ongoing experiments will show if this approach is possible and worth the efford.

[jblance]

My thought for the esp32 was to simplify it down to a serial sender / receiver with mqtt. Basically it would subscribe to a commands topic and (maybe with some security) send any commands that get published to the topic to the inverter (serial port). It would then publish the raw response.

All the complicated bits could then be somewhere else.

That's where my head was going anyway....
Thoughts?

[DMIINC]

@volkerjaenisch single inverter stack with 3 inverters. Cost of ESP32 is not an issue however,
@jblance Idea of ESP32 running inverters is very interesting however having additional pieces of hardware does create additional possible failure points ,more things to maintain and more cables to run etc,.... Sometimes reliability comes with simplicity.

My $0.00002 I might be wrong.

[volkerjaenisch]

@DMIINC I understand your concern. But on the other hand as @jblance said: "Then the complicated things have to be done elsewhere". This would be a distribution of complexity over several components.

My approach aims to locate the "Inverter complexity" in the ESP32 and keep the other things as simple as possible. The ESP32-MPP-Solar module then can be included in any home automation much easier.

At the curren tstate of project I cannot estimate how much of the internal state the inverters or other devices involved have to be distributet to the controlling software (e.g. home automatization). If it would be 100% of the state then probably the idea of @jblance is more fitting. If it is 20% my approach may be the sensible way to go.

In general if you have a complex problem there are seldom simple ways to go. From my experience building complex systems with lots nines of reliability for a living is, that is a good approach is to not distribute the complexity. "Divide et impera" as the romas said :-).

Of the ESP32s you can have a bunch lying around for small money. If one of them goes down, just flash another with the MPP-Solar-software-Image and be online as fast as you can replace it physically. If you have a more complex system like a Raspberry you will need more time to flash, configure etc. And while the ESP32 is down only the single device it controls is offline but the rest of the system is still online.

You see that there are two sides of the coin and both are not shiny. I would suggest that we go for both approaches *1) *2) in parallel and look which one will develop better.

1. We utilize the ESP32 only as serial to WLAN bridge with very limited ability. The complexity is in the external controlling software which utilizes mppsolar. Since we already have 4 serial_device_types in the mppsolar software it will be not great deal to come up with a fifth one, which is the ESP32 remote-protocol.

2. We utilize the ESP32 as controller running mppsolar for e.g. the inverter stack. The interface to the external controlling instance is an MQTT protocol as complex as needed. This MQTT protocol has also to be programmed for case 1) so I see here also no doubling of effort.

[DMIINC]

I agree on divide and rule approach and yes parallel development is a must. Those are basics. I also try to think of any projects in my home from standpoint of WAF or FAF.