Closed riker65 closed 1 year ago
Issues are fine. I probably won't enable discussions.
You can look at the documentation here for changing charging parameters and such: https://solarthing.readthedocs.io/en/latest/config/config-server.html
Let me know if you have any questions.
HI thanks,
looks great and like this is the use case I need.
but how to implement.
have to define the server in request program?
not in rover? right?
how to interact: you wrote: what is the command in detail if I want to set the setFloatingChargingVoltageRaw to 14?
nc localhost 5051 setFloatingChargingVoltageRaw 14
you wrote:
nc localhost 5051 batteryVoltage 24.5
thanks for clarification
Best T
not in rover? right?
Can you send me your base.json
? What version of SolarThing are you running? In modern SolarThing versions the rover
program is run through the request
program. Note that even if you are using the program/rover
directory, you are still likely running the request
program as indicated by "type": "request"
in your base.json
.
The first step after setting all of this up is to run
$ nc localhost 5051
After that, you should be able to type stuff like batteryVoltage<ENTER>
or floatingChargingVoltageRaw 140<ENTER>
, replacing <ENTER>
with pressing your enter key.
Hi thanks for fast response
running 2022.3.1 solarthing-2022.3.1.jar
looks like need to upgrade first:-)
{ "type": "request", "source": "rpi3solar", "fragment": 3, "unique": 30, "databases": [ ], "request": [ { "type": "modbus", "io": "/opt/solarthing/program/rover/config/usb_id.json", "devices": { "1": { "type": "rover", "server": { "port": 5051 } } } ] } }
at the moment nc is not running or giving any response, port not listening
Feel free to update if you would like, but SolarThing has supported this feature since v2021.6.1. So no upgrade should be necessary.
First, can you make sure you restarted SolarThing and make sure it hasn't crashed. Can you give me the logs that are in /opt/solarthing/program/rover/logs/log_info.log
, preferably about 30 seconds after you have restarted it.
Hi looks like I fixed the error in base.json nc is now working
trying to update my rover to custom rover also via request
do you have an example structure for more request within base.json
as rpi-temp
and rover?
testing also write data, worked already for lightControlDelayMinutes 5
where do I see in your code the adress you are using for the set function?
really great software thanks !!!!
question: so you use modbus V1.7 protocol manual or is there a new available ?
could not find anything and was wondering about dim: E001H also used in former version 1.1 as charge setting.
thanks a lot
trying to update my rover to custom rover also via request
This isn't required. I added that feature so that you could have multiple directories to configure multiple separate request programs.
do you have an example structure for more request within base.json
You can find more base.json
examples here: https://github.com/wildmountainfarms/solarthing/tree/master/config_templates/base. For RPi temperature, look here: https://github.com/wildmountainfarms/solarthing/blob/master/config_templates/base/mate_template_with_rpi_cpu_temperature.json. That one is an example using the mate
program, but it's very similar to the request program. Just add { "type": "rpi-cpu-temp" }
to the "request"
array in your base.json
.
The documentation here: https://solarthing.readthedocs.io/en/latest/config/config-server.html#changing-paramters-of-a-rover points to the link here: https://github.com/wildmountainfarms/solarthing/blob/master/core/src/main/java/me/retrodaredevil/solarthing/solar/renogy/rover/RoverWriteTable.java. CTRL+F for JsonProperty
and JsonSetter
.
so you use modbus V1.7 protocol manual or is there a new available ?
I have used the v1.7 protocol manual as a reference and an older manual. I have the 1.7 DCC manual, but I do not have the 1.7 renogy rover manual. To implement features in SolarThing I have had to make it compatible with older and newer versions. So whatever model rover you have should be supported.
For write, SolarThing uses that register to change the brightness: https://github.com/wildmountainfarms/solarthing/blob/cd9f6e27788bbc5c228b3cece61700318b4804d8/core/src/main/java/me/retrodaredevil/solarthing/solar/renogy/rover/modbus/RoverModbusSlaveWrite.java#L59. For read, that value is available under the streetLightBrightness
and internally it reads it using register 120H (0x0120
).
I don't know if the brightness percent ever worked. The E001 register is actually mapped to something else in newer renogy products.
thanks a lot, great job
Glad to help! If you need anymore help, feel free to reopen this issue if it relates to what we've talked about, or open an issue at https://github.com/wildmountainfarms/solarthing/issues. (I prefer issues being opened there unless it's strictly related to the documentation).
Hi was testing with an easy value but looks like it is not stored
see nc communication `nc localhost 5051
lightControlDelayMinutes 0 lightControlDelayMinutes 5 success
lightControlDelayMinutes 0 `
what am I doing wrong?
thanks
update same for
systemVoltageSetting 24 success systemVoltageSetting 255
255 is FF which is automatic recognition which I was using.
but wanted to set it manual to 24
Yeah so I don't have any definitive answers. A while back when I messed with this I noticed that some values do not change. There are a couple of possible reasons for this:
user-unlocked
for some settings.You can first try doing batteryType user-unlocked
to see if you can edit other settings now: Note that changing the battery settings may have unintended side effects if you were using different charging parameters. (For instance if you had it set to lithium before, you'll want to make sure you manually change the setpoints to get all the parameters how you want them to be).
I remember having the same problem with the system voltage setting. I think that you either have to change that setting on the charge controller itself, or it needs to be in the user-unlocked
mode. I don't believe that lightControlDelayMinutes works, at least not on most models. Most of the stuff relating to a "street light" is not supported on rover models.
Now, if there is something you are trying to do (such as automate a light coming on after dark via the aux output), let me know and I can try and guide you in the right direction. For automations like that I have used the configuration of actions, which are not a documented part of SolarThing yet. Basically, you write a script in either JSON or this scripting language I made and it can command the aux to be on/off based on values from the charge controller (such as it being night time or 5 minutes after night time).
This is a more advanced route, but I figured I'd mention it since it sounds like you are trying to do something with your aux output.
Thanks for your help,
actually I wanted to use it for custom configuration of charge settings. Controller buttons and display hard to see where I placed it. and for testing with different battery types and voltage setting for LifePO4 would be great.
Will try to find out what can be done without side effects.
Hi, tried
` pi@pi3solar:~$ nc localhost 5051 batteryType user-unlocked
success
batteryType
2
systemVoltageSetting
255
systemVoltageSetting 24
success
systemVoltageSetting
255
` looks unlock worked somehow. I am having issues with my voltagesettings, from my point of view they do not match with a 24V system
Unfortunately renogy support is not realing helping. They focus more on social media but on function.....and support
my overvoltage response chargingVoltageLimitRaw 155
which is 15.5 I think
same
dischargingLimitVoltageRaw 106, which is 10.6V
right.
But for 24V this does not make sense, checking with renogy support
The raw values with always look like they are for a 12V battery. When the charge controller is in 24V mode, it uses these parameters, but they are multiplied by 2. This means that settings for a 24V battery have a resolution of 0.2V. So, a value of 155 is actually 31.0V on a 24V system.
Renogy support is sometimes helpful. I imagine they won't tell you much about their protocol, but would help you with the controller itself if you are having problems.
Hi ok, where do you have the information from? "When the charge controller is in 24V mode, it uses these parameters, but they are multiplied by 2. " resolution of 0.2 volt is quit big
Want to change to custom setting via modbus, but did not archive it yet
which mapping did you use for batteryype user-unlock? is this like self customized?
1: 'open',
2: 'sealed',
3: 'gel',
4: 'lithium',
5: 'self-customized
? modbus document does not show the mapping
Looking at some of the comments I put in that file, my past self said that you have to change the battery type manually, then you can configure parameters over modbus. I say my past self because I don't really remember if this is true or not, but it's worth a shot.
Yeah the modbus document doesn't show a lot of things. It's not a great piece of documentation.
I agree the resolution of 0.2V is big, but that's kind of standard for most charge controllers sadly. I mean, it's basically the same magnitude of resolution you would get on a 12V charge controller.
thanks again,
I am wondering if I let the BMS do the main control, so no need for more resolution on mppt renogy charger, but should be nice to better customize the setting via modbus, did send a mail to renogy....but the are more into social media...
I managed to set different values after I changed user-unlock self-customed
values where persistant after setting batteryType to lithium after that self-customized/user-unlock I could change settings and the retained.
looks like any config are persistent only for lithium battery tpye setting
wondering how to handle the systemchange to 24V and calculation by 2 same for 48V systems, Maybe Renogy should to it in the firmware, otherwise it is misleading.?
looks like any config are persistent only for lithium battery tpye setting
chargingVoltageLimitRaw
155
batteryType self-customized
success
chargingVoltageLimit 29
Got error: Unrecognized field "chargingVoltageLimit" (class me.retrodaredevil.solarthing.solar.renogy.rover.modbus.RoverModbusSlaveWrite), not marked as ignorable (28 known properties: "ledLoadCurrentSettingRaw", "streetLightBrightness", "dischargingLimitVoltageRaw", "overVoltageThresholdRaw", "equalizingChargingIntervalDays", "temperatureCompensationFactorRaw", "overDischargeRecoveryVoltageRaw", "equalizingChargingIntervalRaw", "overDischargeTimeDelaySeconds", "overDischargeVoltageRaw", "temperatureCompensationFactor", "floatingChargingVoltageRaw", "lightControlDelayMinutes", "load", "batteryType", "boostChargingRecoveryVoltageRaw", "address", "lightControlVoltage", "equalizingChargingVoltageRaw", "chargingVoltageLimitRaw", "boostChargingVoltageRaw", "equalizingChargingTimeMinutes", "boostChargingTimeRaw", "equalizingChargingTimeRaw", "systemVoltageSetting", "ledLoadCurrentSettingMilliAmps", "underVoltageWarningLevelRaw", "boostChargingTimeMinutes"])
at [Source: UNKNOWN; byte offset: #UNKNOWN] (through reference chain: me.retrodaredevil.solarthing.solar.renogy.rover.modbus.RoverModbusSlaveWrite["chargingVoltageLimit"])
batteryType
2
systemVoltageSetting
255
batteryType user-unlocked
success
systemVoltageSetting
255
chargingVoltageLimit 29
Got error: Unrecognized field "chargingVoltageLimit" (class me.retrodaredevil.solarthing.solar.renogy.rover.modbus.RoverModbusSlaveWrite), not marked as ignorable (28 known properties: "ledLoadCurrentSettingRaw", "streetLightBrightness", "dischargingLimitVoltageRaw", "overVoltageThresholdRaw", "equalizingChargingIntervalDays", "temperatureCompensationFactorRaw", "overDischargeRecoveryVoltageRaw", "equalizingChargingIntervalRaw", "overDischargeTimeDelaySeconds", "overDischargeVoltageRaw", "temperatureCompensationFactor", "floatingChargingVoltageRaw", "lightControlDelayMinutes", "load", "batteryType", "boostChargingRecoveryVoltageRaw", "address", "lightControlVoltage", "equalizingChargingVoltageRaw", "chargingVoltageLimitRaw", "boostChargingVoltageRaw", "equalizingChargingTimeMinutes", "boostChargingTimeRaw", "equalizingChargingTimeRaw", "systemVoltageSetting", "ledLoadCurrentSettingMilliAmps", "underVoltageWarningLevelRaw", "boostChargingTimeMinutes"])
at [Source: UNKNOWN; byte offset: #UNKNOWN] (through reference chain: me.retrodaredevil.solarthing.solar.renogy.rover.modbus.RoverModbusSlaveWrite["chargingVoltageLimit"])
batteryType sealed
success
boostChargingVoltageRaw
146
batteryType lithium
success
batteryType
4
boostChargingVoltageRaw
144
boostChargingVoltageRaw 142
success
boostChargingVoltageRaw
142
batteryType
4
batteryType sealed
success
boostChargingVoltageRaw
146
chargingVoltageLimit
does not exist. You must use chargingVoltageLimitRaw
and convert appropriately. You probably want:
chargingVoltageLimitRaw 145
That will give you a charging voltage limit of 29.0V. If you have a 48V system, 145 would be 14.5*4=58.0V.
looks like any config are persistent only for lithium battery tpye setting
Not really sure what you mean by this, could you elaborate more? I know for certain that parameters you set then change are persistent while in user mode, I don't know anything about the other modes. I'm not surprised that changing battery types will result in a reset to the modifications you have made to the preset battery types.
Even if I understand better exactly what you are trying to do with your battery parameter configuration, I probably won't have many recommendations for getting it how you want it. You kind of just have to play around with setting and checking values until you have what you want.
SolarThing implements all the Modbus stuff correctly, but the Rover is very picky about how you go about changing things it seems.
Hi, actually I want to limit the loading to SOC 85-90% can only be archieved via custom confiuragion which looks like is only possible for one value Boost Charge Voltage
I am in touch with renogy for that. Solarthing is doing a great job.
only thing I do not understand is the differenc between user-unlock and self-customized
see log:
` 1 batteryType user-unlocked success batteryType 1 BoostChargingRecoveryVoltageRaw unknown field systemVoltageSetting 255 BoostChargingRecoveryVoltageRaw^[[1~^[[3~b unknown field boostChargingRecoveryVoltageRaw 132 boostChargingVoltageRaw 146 boostChargingVoltageRaw 144 success boostChargingVoltageRaw 146
batteryType self-customized success batteryType 1 systemVoltageSetting 255 boostChargingVoltageRaw 146 boostChargingVoltageRaw 142 success boostChargingVoltageRaw 146 batteryType lithium success batteryType 4 systemVoltageSetting 24 boostChargingVoltageRaw 142 `
bootChargingVoltageRaw is only changed for lithium .
this is just for info I think and better understanding what Renogy allows
case "self-customized": case "custom": case "customized": case "user": case "user-unlocked":
are all the same. There is no difference.
However, when you set it to either of those and it does not change to 0
for the batteryType
, that's when you have to set it manually on the charge controller. If the battery type is not 0 or 5, then it is not in the user/self-customized battery type.
Now to explain the user-locked
battery type. In this case, the parameters are the same (it uses the user parameters), however when it is set to mode 5, modbus commands will not be able to change the charging parameters.
The important thing to take away is that if you want to edit the user charging parameters, I believe you must change it manually by selecting it on the charge controller.
This "locked"/"unlocked" logic I'm talking about is all anecdotal and is what I have picked up by playing with the charge controller. It is not documented anywhere.
thanks for clarification
Feel free to reopen this if you need any more help on this.
Otherwise open your next issue at https://github.com/wildmountainfarms/solarthing/issues
Hi
thanks a again for the great software.
having a question but could only raise an issue and no discussion..
Did you try to change settings via the modbus interface already?
Thanks Thomas