sullen wharf
Power meter splitter - relays data from one power meter to two inverters via 4-port RS485 USB adapter. Also displays data from power meter and both inverters. Uses a Waveshare ESP32-S3 board that conveniently has two USB connectors, one used for OTG and the other for programming.
hushed dagger
Wow! You implemented USB OTG vs using 8x GPIO for 4x rs485 transceiver? Interesting! I guess that is a fair bit of GPIO needed when the LCD etc already use allot of pins.
magic knot
Wow! You implemented USB OTG vs using 8x GPIO for 4x rs485 transceiver? Interest...
An S3 has at most 3 uarts.
hushed dagger
You're right.. and "The Software UART is only available on the ESP8266. It is not available on ESP32 and variants." According to ESPhome docs
still birch
Huh, is there a reason it doesn't support software uart? Just not worth implementing when there are so many hardware ones?
magic knot
Huh, is there a reason it doesn't support software uart? Just not worth implemen...
Right. software uart is terrible. 🙂
still birch
fair, but sometimes you just really need one more (I imagine) 😅
sullen wharf
Wow! You implemented USB OTG vs using 8x GPIO for 4x rs485 transceiver? Interest...
Yes. Unfortunately only 3 are usable at a time as the S3 can only support 8 simultaneous USB endpoints - 9 would be needed to run all 4 at the same time. There is already one RS485 on the board itself, plus CAN.
hushed dagger
I was planning on doing something similar with 3x UART (didnt know that was the max until now) to talk to my 3x Deye 12Kw single phase inverters. And may still do that so I can aggregate the data locally on one ESPhome device. But am also recently considering having 3x ESP32 devices one for each inverter.. It may be easier for me to copy updates to each then too.. Wasn't planning LCDs locally but on a remote ESPhome LCD like that waveshare one. My ESPhome code is based on the great examples in the YAMLs shared here by Slipx https://github.com/slipx06/Sunsynk-Home-Assistant-Dash I highly recommend his https://github.com/slipx06/sunsynk-power-flow-card it is amazing too!
sullen wharf
I was particularly keen to use that RS485 box since it has isolation, and I needed at least 3 RS485 on one device - it polls the power meter then uses that data to emulate a power meter to the inverters. The screen is. a bonus but I haven't spent any time prettying it up yet.
But it does mean I have up to 5 uarts available - 3 on USB, one more on the USB programming port (UART0) and the on-board RS485, which I may be using yet to talk to the inverters directly.
hushed dagger
Nice! are yours Deye inverters? My 12Kw ones don't actually have access to all the settings over RS-485 ports (but different models do) so I am using the RS-232 port that their wifi dongle usually plugs into, the protocol is still modbus its just over rs-232 physical layer.. It provides 12V on one pin that I use to power the ESP32, no isolation necessry since all the power and data from that inverter. I was going to use isolated rs-232 transceivers if I do more than one interface per ESP32.
sullen wharf
Goodwe inverters. Currently talking to them over WiFi from HA, but that has issues.
Like when HA dies. Like right now.
hushed dagger
HA down? my 8 or so installs have been super reliable knock on wood
cant speak for Goodwe, but having local control of the Deye is a huge game changer.. their cloud is unreliable and slow.. its like night and day
sullen wharf
I don't think the Goodwe cloud even lets me control it, and the reporting is crap. I plan to disconnect them from the net after a firmware upgrade. The HA issue appears to have been due to a prior replacement of the CM4 module without updating the static DNS lease config in the router, not sure why it worked at all but for some reason today the local DNS wasn't resolving and I thought the IP address was down too, but that turned out to be that it just had a different address, since the static lease wasn't being applied. 💩
sullen wharf
Wow! You implemented USB OTG vs using 8x GPIO for 4x rs485 transceiver? Interest...
And another reason for using the USB was just that the hardware is much neater. Wiring up multiple RS485 expansion boards would have involved a lot more wiring and soldering, with additional points of failure. Or a custom board.
hushed dagger
You are defintely a software guy 😉 I would have done anything to not implement USB OTG.. but I could solder one up in 30 minutes or something, or design a PCB but not worth it for one off units.
sullen wharf
Well, I do both, but you're right, I prefer software solutions. Not least because a good software implementation is often useful to someone else and that gives me the feel-good factor, not so easy with hardware to share.
magic knot
It's also a lot easier to change later if necessary. 🙂
hushed dagger
Yes I definitely appreciate your contributions to the project! Thanks
hushed dagger
I just saw that M5stack finally released the new RS232 nano adapter! been wanting this part for awhile as it eliminates all my soldering.. Just cut off the end of any DB9 cable and screw in the 4 wires and you have a RS232 adapter for any Deye inverter or others that follow the same standard ( I think lots of chinese inverters have this standard DB9 + 12V on one pin) https://shop.m5stack.com/products/atomic-rs232-base-w-o-atom-lite
sullen wharf
I've just figured out that I can use this to pretty much completely control inverter operation by adjusting the reported power export/import value. I'll pre-set the inverters to zero export limit, they already have an implicit zero import goal, so if the inverter sees an export value, it will reduce PV power (or increase battery charge), and if it sees imported power, it will maximise PV power and if necessary start discharging the battery. I may have to combine that with selective charge/discharge limits which I can already do via the CANbus adapters I have between the batteries and the inverter - that will likely be necessary to equalise battery charge/discharge rates and states between the two inverters. I suspect I'll need a PID algorithm to manage this without introducing instability.
hushed dagger
You can't do what you want with the settings built into the inverters?
sullen wharf
It requires several different parameters to be set - for example to switch to exporting from the battery needs it to be set into a different mode, then there is a grid export limit setting. And the wifi interface is unreliable - uses UDP. RS485 would be more reliable, but right now with the firmware installed that doesn't support modbus, only a similar protocol using aa55 headers - currently no support for that in ESPHome. I am getting the firmware updated, which should make modbus available. Whereas the power meter interface is very reliable - it's a basic part of the inverter operation, and I already have the hardware in place - I don't have RS485 wired to the management port.
So another software solution to avoid more hardware (and other software)
slender bane
An S3 has at most 3 uarts.
Still reckon the "timeshared UART" approach of redefining the pins for the hardware peripheral could be a win. It just needs a .claim() and .release() wrapped around any request/response conversations 🙂
And then you could do 10 UARTs if you needed to!
hushed dagger
Still reckon the "timeshared UART" approach of redefining the pins for the hardw...
Interesting! I hadn't heard of that before! Does it require a custom component or can be done in a Lambda somehow? Are there examples online?
slender bane
To be clear, this is not (yet) a thing. The theory is sound, but it would require fairly significant development to integrate it into something like ESPHome, primarily because all existing UARTComponent implementations assume permanent ownership of the underlying uart, and are not built to take and relinquish ownership when needed.
hushed dagger
Yes makes sense.. I think it would be hard to manage some types of data if you didn't know when the data will be received. I guess you could also use an external multiplexor to similar effect just more hardware needed.
slender bane
It’s similar in concept to the rs485 “gpio to transmit”, just one step removed. Ie call function to claim/reconfigure the uart peripheral, do tx, receive complete response, call function to relinquish the uart peripheral, let other components claim it if necessary. The others would likely have attempted to claim the peripheral and failed because it was already claimed, but now it’s available…
And yes, this is explicitly only suitable for request/response protocols, where you know when the remote end is finished talking.