Adding EPEVER inverter to influxdata

[Maikeleg]

I have a SolarThing setup running with much joy on a raspberry pi 3B+ running influxdb, telegraf and grafana Really like this project, thanks and compliments I have a EPEVER Tracer and EPEVER inverter connected on the same RS485 cable. How can I readout data from the inverter? Is there a place to configure which fields are expected as data from the inverter as it also reads out the tracer data fields or do I only have to find the channel the inverter is on and what type should I use in the base.json? My tracer is on channel 1 (device 1)

Sorry for all questions, I'm reading all documentation and reallyt trying to find how to set this up but cannot find it Thanks again for all efforts making this awesome software

Maikel

[retrodaredevil]

SolarThing currently does not support EPEVER Inverters. SolarThing also does not have support for configuring fields to read from unsupported devices such as EPEVER Inverters.

I also want to stress that you will not be able to use another program that supports monitoring your inverter unless you connect two different RS485 adapters to your Raspberry Pi (and also make sure the two RS485 lines are separate). Whatever program uses your RS485 adapter to read from one or both of your devices will not allow that serial port to be used by other applications. I say this because if not being able to monitor your inverter is a deal breaker for whether or not you use SolarThing, you should find a different program that supports the monitoring of both at the same time. As much as I'd love to add support for an EPEVER Inverter, I don't have an EPEVER Inverter and am not willing to sink time into getting support for something I will not use. If you are set on being able to monitor both devices, I think using a Python library would be your best bet. There are some Python libraries out there for monitoring EPEVER Tracer units. As much as I don't want to link you away from SolarThing this library might help: https://github.com/fatyogi/epever-upower-tracer. I can't comment on how well that will work since I've never used it. There are also numerous other repos that support the EPEVER tracer, but finding ones like that that also support your inverter might be difficult. You might be able to mix and match Python libraries for monitoring your devices as long as both Python libraries you choose use the same modbus library (minimal modbus for instance). If that's the case then you might be able to get them to work together with the same serial port connection. All this, of course, requires some tinkering with Python, which may or may not be what you want to do.

Sorry I threw a lot of information at you. Just want to give you all the options. Sorry I don't have a better answer for you.

[Maikeleg]

SolarThing currently does not support EPEVER Inverters. SolarThing also does not have support for configuring fields to read from unsupported devices such as EPEVER Inverters.

I also want to stress that you will not be able to use another program that supports monitoring your inverter unless you connect two different RS485 adapters to your Raspberry Pi (and also make sure the two RS485 lines are separate). Whatever program uses your RS485 adapter to read from one or both of your devices will not allow that serial port to be used by other applications. I say this because if not being able to monitor your inverter is a deal breaker for whether or not you use SolarThing, you should find a different program that supports the monitoring of both at the same time. As much as I'd love to add support for an EPEVER Inverter, I don't have an EPEVER Inverter and am not willing to sink time into getting support for something I will not use. If you are set on being able to monitor both devices, I think using a Python library would be your best bet. There are some Python libraries out there for monitoring EPEVER Tracer units. As much as I don't want to link you away from SolarThing this library might help: https://github.com/fatyogi/epever-upower-tracer. I can't comment on how well that will work since I've never used it. There are also numerous other repos that support the EPEVER tracer, but finding ones like that that also support your inverter might be difficult. You might be able to mix and match Python libraries for monitoring your devices as long as both Python libraries you choose use the same modbus library (minimal modbus for instance). If that's the case then you might be able to get them to work together with the same serial port connection. All this, of course, requires some tinkering with Python, which may or may not be what you want to do.

Sorry I threw a lot of information at you. Just want to give you all the options. Sorry I don't have a better answer for you.

Thanks a lot, not the answer I wanted to hear haha but fully understandable. I will explore the link and information you've given me. Thanks for your reply

[retrodaredevil]

You can probably still use SolarThing and use something else to monitor your inverter, but you would definitely have to have two RS485 adapters. Also, there's a chance that it's possible to have 2 RS485 adapters connected to the same bus, both as masters, but I wouldn't put money on it. I'm not familiar enough with RS485 to tell you whether or not its possible, but this is relevant: https://electronics.stackexchange.com/questions/451684/rs-485-network-with-multiple-masters. I believe RS485 is designed in a way that allows multiple devices to send data on the same line as long as it is not at the same time.

Alternatively, like I said earlier, you can separate your tracer and inverter so that their RS485 line are not connected and then give each device its own RS485 adapter. Although I assume you don't want to do that as it's common for inverters/charge controllers sharing the same serial communication to also share data such as battery temperature so you only need one temperature sensor.

[Maikeleg]

You can probably still use SolarThing and use something else to monitor your inverter, but you would definitely have to have two RS485 adapters. Also, there's a chance that it's possible to have 2 RS485 adapters connected to the same bus, both as masters, but I wouldn't put money on it. I'm not familiar enough with RS485 to tell you whether or not its possible, but this is relevant: https://electronics.stackexchange.com/questions/451684/rs-485-network-with-multiple-masters. I believe RS485 is designed in a way that allows multiple devices to send data on the same line as long as it is not at the same time.

Alternatively, like I said earlier, you can separate your tracer and inverter so that their RS485 line are not connected and then give each device its own RS485 adapter. Although I assume you don't want to do that as it's common for inverters/charge controllers sharing the same serial communication to also share data such as battery temperature so you only need one temperature sensor.

Thanks, I just read your reply now. In the mean time I found some options to get the inverter implemented with different scripts and RS485 adapter. Now what I was wondering; because the inverter communicates on the same bus with a different device ID and with different data fields, is it possible to edit one or more files in the SolarThing configuration to implement these data fields? That would be so much better because its much more reliable and I'm happy to share all information that I find out. If it's possible could you give me a short fly-over how SolarThing reads the data from the RS485 adapter? Or give me some locations and file names, I'll try to find out myself once I have some leads. If that's really not possible, then that's ok but I figured "Not asked is no chance anyway"

[retrodaredevil]

is it possible to edit one or more files in the SolarThing configuration to implement these data fields?

Yeah it's definitely possible. Just not something I'm willing to work on at the moment. If you want to mess with it to get it working I'll try to point you in the right direction. Note that the structure of the project is much larger and more difficult to understand than most simple Python scripts that are out there. I've been meaning to write documentation for the overall structure of the project, but it seems I'm behind on writing documentation for some of the normal use cases anyway.

First I'll focus on how I read data from the rover. I'm going to have perma links for f818a11f7d5ef3e62d99550d95899ef0bf907ec6 as that is the latest commit on master at the moment. RoverModbusSlaveRead.java is the class that has much of the logic for doing the reading of particular registers. Notice this class implements RoverReadTable. RoverReadTable is also implemented by ImmutableRoverStatusPacket which is a concrete implementation of RoverStatusPacket. This particular structure allows me to use RoverStatusPackets#createFromReadTable() to read from a RoverReadTable implementation and create a RoverStatusPacket. I end up passing a RoverModbusSlaveRead to that method and that's where all of the reading takes place. The tracer code also has similar classes (I meant to put in links for the tracer classes but ended up doing the rover classes. Should give you a good idea either way no matter which one you look at)

Now that's at a pretty high level. Notice that all of those classes are in the core module. The logic to actually call these methods exists in the client module, which is the module that contains most of the logic to make solarthing.jar work. The client module contains configuration and logic to correctly setup PacketListReceivers. The ModbusDataRequester class is one of the objects created directly from the configuration. Notice that ModbusRequester currently has two subtypes: RoverModbusRequester and TracerModbusRequester. Note that both of those classes have logic to tell the modbus stuff what registers it can perform bulk requests on, so there is a lot of code in there that is for performance and isn't necessary to understand what is actually happening.

Should you decide to try to implement a EpeverModbusRequester, you can base it off of TracerModbusRequester. It's quite a lot of code to understand and most people that use SolarThing don't have much Java experience so I rarely get contributors.

[Maikeleg]

is it possible to edit one or more files in the SolarThing configuration to implement these data fields?

Yeah it's definitely possible. Just not something I'm willing to work on at the moment. If you want to mess with it to get it working I'll try to point you in the right direction. Note that the structure of the project is much larger and more difficult to understand than most simple Python scripts that are out there. I've been meaning to write documentation for the overall structure of the project, but it seems I'm behind on writing documentation for some of the normal use cases anyway.

First I'll focus on how I read data from the rover. I'm going to have perma links for f818a11 as that is the latest commit on master at the moment. RoverModbusSlaveRead.java is the class that has much of the logic for doing the reading of particular registers. Notice this class implements RoverReadTable. RoverReadTable is also implemented by ImmutableRoverStatusPacket which is a concrete implementation of RoverStatusPacket. This particular structure allows me to use RoverStatusPackets#createFromReadTable() to read from a RoverReadTable implementation and create a RoverStatusPacket. I end up passing a RoverModbusSlaveRead to that method and that's where all of the reading takes place. The tracer code also has similar classes (I meant to put in links for the tracer classes but ended up doing the rover classes. Should give you a good idea either way no matter which one you look at)

Now that's at a pretty high level. Notice that all of those classes are in the core module. The logic to actually call these methods exists in the client module, which is the module that contains most of the logic to make solarthing.jar work. The client module contains configuration and logic to correctly setup PacketListReceivers. The ModbusDataRequester class is one of the objects created directly from the configuration. Notice that ModbusRequester currently has two subtypes: RoverModbusRequester and TracerModbusRequester. Note that both of those classes have logic to tell the modbus stuff what registers it can perform bulk requests on, so there is a lot of code in there that is for performance and isn't necessary to understand what is actually happening.

Should you decide to try to implement a EpeverModbusRequester, you can base it off of TracerModbusRequester. It's quite a lot of code to understand and most people that use SolarThing don't have much Java experience so I rarely get contributors.

Thanks a LOT, I'll read through all this and if I decide to write something myself I'll at least let you know. So great you respond so quickly (quicker than me haha) and throughly, much apreciated, your whole project here on GitHub actually is.

[retrodaredevil]

Feel free to reopen this issue if you are going to look into this more. I will close this for now but can also reopen it if you would like me to add the help wanted tag.