Renogy Battery support

[acmagn]

Added: -Renogy Battery plugin -new RenogyBattery device + linting in soladevice.py -Renogy battery example in .ini file -README update to "Currently Supported"

[Anto79-ops]

Hey, nice additions. How do I download or clone (and try) the entire script with your battery changes already implemented? Also, when you say Renogy Battery. does this include both the battery with built-in bluetooth AND the battery with BT-2 module required? thanks

[acmagn]

Hey Anto79-ops. If Olen doesn't pull it in soon to the main branch here, you can grab it from my forked repo. To your second question: It's a good question. I'll answer more in-depth in the issues thread, but I would say it's definitely worth a try.

[acmagn]

Note: capacity reading can be a bit off sometimes, but still more accurate and provides more useful info than Renogy Battery's readings. Actively working on solution. Highly suggest this blog to have a general sense of your battery's remaining capacity based on voltage: https://www.renogy.com/blog/expectations-vs-reality-making-sense-of-battery-voltage-percentages/

[Anto79-ops]

Hey Anto79-ops. If Olen doesn't pull it in soon to the main branch here, you can grab it from my forked repo. To your second question: It's a good question. I'll answer more in-depth in the issues thread, but I would say it's definitely worth a try.

just tried your script and placed the mac address of my BT-2 module in ini file, and unfortnalt,y couldn't get it work. The script found the mac address, tried to connected but then said "error importing RenogyBattery", and then just went on with the discovery.

[Anto79-ops]

Not sure if this will help in the decoding of stuff but the mod bus for the regular battery i.e. the one without the Bluetooth built-in bt module is published here

https://github.com/Grmume/renogy-smart-battery/files/8134043/Lithium.Iron.Battery.BMS.Modbus.Protocol.V1.7.zh-CN.en.1.pdf

[acmagn]

Anto79-ops -- It should at least connect. That to me indicates a Bluetooth issue -- your device with the BT app might still be connected to it, try temp disabling bluetooth on it and giving it another go.

[Anto79-ops]

thanks, I disable bt and it still does the same. What happens is that it finds the device. and says "Error importing RenogyBattery" then goes on the to next devices on the list and then stops when its gets to the end. For comparison, when the script connects to my BT-1 with the Rover it does the same thing, it finds the the device but then it says "sucessfully imported SolarLink". If you have any other suggestion to try, please let me know I'd be happy to do so.

[acmagn]

Oh my mistake! I see the issue now. in your solar-monitor.ini file it needs to be: "type = RenogyBatt" not "type = RenogyBattery" Maybe this is my mistake for naming it "RenogyBatt".

[Anto79-ops]

oh no, now I made the mistake. The error was indeed this "Error importing RenogyBatt" ...here's the actualy debug, I cut it short as it lists all my devices...you'll see "..."

2022-03-04 15:25:00,868 DEBUG   : Creating new DataLogger
2022-03-04 15:25:00,869 DEBUG   : Creating new MQTT-logger
2022-03-04 15:25:00,885 DEBUG   : MQTT Sending CONNECT (u0, p0, wr0, wq0, wf0, c1, k60) client_id=b'raspberrypi'
2022-03-04 15:25:00,900 INFO    : Adapter status - Powered: True
2022-03-04 15:25:00,905 INFO    : Starting discovery...
2022-03-04 15:25:00,913 DEBUG   : MQTT Received CONNACK (0, 0)
2022-03-04 15:25:02,765 DEBUG   : Found 47 BLE-devices so far
2022-03-04 15:25:03,882 DEBUG   : Found 66 BLE-devices so far
2022-03-04 15:25:04,982 DEBUG   : Found 72 BLE-devices so far
2022-03-04 15:25:06,080 DEBUG   : Found 76 BLE-devices so far
2022-03-04 15:25:07,181 DEBUG   : Found 80 BLE-devices so far
2022-03-04 15:25:08,273 DEBUG   : Found 82 BLE-devices so far
2022-03-04 15:25:09,371 DEBUG   : Found 84 BLE-devices so far
2022-03-04 15:25:10,478 DEBUG   : Found 88 BLE-devices so far
2022-03-04 15:25:11,583 DEBUG   : Found 91 BLE-devices so far
2022-03-04 15:25:12,694 DEBUG   : Found 91 BLE-devices so far
2022-03-04 15:25:13,810 DEBUG   : Found 93 BLE-devices so far
2022-03-04 15:25:14,911 DEBUG   : Found 93 BLE-devices so far
2022-03-04 15:25:16,025 DEBUG   : Found 94 BLE-devices so far
2022-03-04 15:25:17,134 DEBUG   : Found 95 BLE-devices so far
2022-03-04 15:25:18,242 DEBUG   : Found 96 BLE-devices so far
2022-03-04 15:25:18,433 INFO    : Found 96 BLE-devices
2022-03-04 15:25:18,479 DEBUG   : Processing device 76:4a:52:7b:35:18 76-4A-52-7B-35-18
2022-03-04 15:25:18,485 DEBUG   : Processing device 0c:56:36:df:97:cd 0C-56-36-DF-97-CD
.
.
.
2022-03-04 15:25:18,545 DEBUG   : Processing device cc:6e:a4:4e:5a:fa [TV] Samsung 8 Series (65)
2022-03-04 15:25:18,549 DEBUG   : Processing device c4:64:e3:4d:23:88 BT-TH-E34D2388
2022-03-04 15:25:18,550 INFO    : Trying to connect to c4:64:e3:4d:23:88...
2022-03-04 15:25:18,566 ERROR   : Error importing RenogyBatt
2022-03-04 15:25:18,566 ERROR   :
2022-03-04 15:25:18,571 DEBUG   : Processing device 7d:bd:bd:f6:bf:e3 None
2022-03-04 15:25:18,576 DEBUG   : Processing device 53:88:12:b6:ba:9a 53-88-12-B6-BA-9A
.
.
.
2022-03-04 15:25:18,939 DEBUG   : Processing device 60:21:13:b5:c4:29 60-21-13-B5-C4-29
2022-03-04 15:25:18,941 INFO    : Terminate with Ctrl+C
2022-03-04 15:26:01,067 DEBUG   : MQTT Sending PINGREQ
2022-03-04 15:26:01,077 DEBUG   : MQTT Received PINGRESP

[acmagn]

Based on the code, I think this is a library importing error. You said you copied the files so I just want to confirm that the new plugins file: plugins/RenogyBatt/__init__.py exists and is in this position?

[Anto79-ops]

Hi, good point... just checked and all is in position as you said. I used the "git clone https://github.com/acmagn/solar-monitor.git" on the terminal line, changed some settings in the ini file to my mac address.

[Olen]

Hi,

I'll look into this in a day or two

[acmagn]

Thank you Olen! Anto79-ops - I just tried a git clone and a fresh install to insure I didn't make a mistake with the git repo. The last two things I can think of: 1) The battery in solar-monitor.ini needs to be named [renogy_battery_X] (This was to avoid additional changes to Olen's code).

[renogy_battery_1]
 type = RenogyBatt
 mac = 11:11:11:11:11:11
 reconnect = True

2) I added some library dependencies in the RenogyBatt/__init__.py. (Edited to avoid confusion) All but dateutil come with the standard Python library (End edit), but maybe if you're using an older version/custom environment you don't have them installed. These are: dateutil re datetime

[Anto79-ops]

Thank you Olen! Anto79-ops - I just tried a git clone and a fresh install to insure I didn't make a mistake with the git repo. The last two things I can think of:

1. The battery in solar-monitor.ini needs to be named [renogy_battery_X] (This was to avoid additional changes to Olen's code).

[renogy_battery_1]
type = RenogyBatt
mac = 11:11:11:11:11:11
reconnect = True

2. I added some library dependencies in the RenogyBatt/__init__.py. These all come with the standard Python library, but maybe if you're using an older version/custom environment you don't have them installed. These are: dateutil re datetime

It works!! IT was the libraries!! it running as we speak! awesome and thank you!

[Anto79-ops]

and to add, it took about 3 or 4 attempts BUT I was able to connect to both the BT-1 and BT-2 modules, and now its reporting both battery stats and Rovery Stats....awesome!

[acmagn]

Great! I'm happy to hear that, thanks for reporting.

[acmagn]

Oh this was my mistake. I was wrong about library dateutil. It is technically a third-party extension of datetime. This is good to know. I added it to the requirements file to avoid this problem in the future. Thanks!

[Anto79-ops]

its all good! now that its been report for a an hour or so, this is what I see:

Capacity, voltage for each of the 4 cells, 2 battery temperatures, battery current, battery state, battery voltage.

1. I'll have to modify the SOC% because its reporting 103% SOC (no problem, you mentioned the before). Also why have an algorithm based on voltage anyways. Doesn't the battery report SOC% automatically?
2. Why are there 2 temperatures reported? Does my my battery have two temp monitors or just a duplicate entry?
3. There are several entities that are reported as 0, like charge current, charge cycles, charge power, charge voltage, input current, input voltage, input power, and power. What are these supposed to show?

[acmagn]

Hey Anto79-ops -- Your questions are good and are helping me clean up my code, so thank you! Everything you listed matches what the code is attempting to grab from the batteries. 1) I released a fix for capacity, it should be a bit more accurate now. It was actually just reporting on total remaining capacity (I had decided for myself that I'd rather have this number). The code now reports on both: so now you can read remaining capacity or SOC % (or both!) -- As a side note, if the readings are still weird for you, let me know I may have an idea for a fix, as this may be connected to you using the BT-2 device instead of built-in BT. (note-- it may take a while (days?) for code's SOC readings to sync with your battery). I actually had a hard time identifying the battery's SOC% reading from the bluetooth sniffing. But from using these batteries for about 6-months now, I found that the battery's SOC readings were awful and would often give me completely wrong measurements, off by > 20% sometimes. I don't know what your experience has been with this, but it motivated me to attempt my own SOC calculations. 2) From the Bluetooth sniffing I did, the double reading seems very deliberate so I believe there are two temperature sensors. (I read a value from the battery to determine how many sensors there are.) 3) I did some clean-up on these empty-values. The way I was reading the MQTT output allowed me to ignore these and forgot to remove them. Now only values that SHOULD be sent will be.

[Anto79-ops]

awesome and thanks! I'm running the script now and i'll give it a few hours, but noticed off the bat, im getting a lot of these messages as the code runs:

WARNING: [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]

Would know the modbus codes for the battery be useful to you to determing what you are reading?

[acmagn]

Regarding that warning: I've only gotten it twice in the past 14 hours or so, I'm not sure why you're getting it so much more than me. But I wrote it off as too inconsistent to do anything about it. Regarding modbus: my understanding is pretty limited. I understand most of what I want from the battery is in function code 3, but knowing the specific modbus layout for the battery may be helpful to clean up what I'm doing.

[Anto79-ops]

just wanted to provide an update on some things I observed. The script was running for a good 5 hours with good reporting. But a few values were a bit bizzare, and I think I have an idea why:

1. At around say, midnight, both temperatures were reporting in 6000oC range. After I confirmed my battery was not a on fire, I disconnted the BT and reconnected with the DC Home app and it reported a normal temperature of -6 oC
2. The SOC reading is still a bit off, it was reading maybe around 90% and as the battery was charging, it did go up incrementally with charge which was nice. But overnight (my battery runs some landscape lights) uses about 7 ah in the night. The battery SOC went down incrementally from around 94.3% then it just dropped to 49% (suddenly). Again, confirming with the DC home app, the SOC battery was at around 80% in the morning.

A couple of things for the observations above:

1. I suspect the temperature went crazy when the actual battery temperature went below 0oC. Can you confirm your script can handle negative values? For example, even restarting the script now this morning, my actual battery temperature is -6oC but the script resporting it at +6547.2oC
2. You said you had some ideas about the SOC readings, just curious about what they are!

Still script is awesome, by the way! might need some tweeaks here and there but awesome so far.

[Olen]

Regarding temperature. I believe some of the devices I looked at are reporting negative values as extreme high positive values. Or in other words, if temperature is reported for instance as a 12 bit number, if the first bit is zero, the measurement is positive, but if the first bit is one, the temperature is negative. And only the remaining 11 bits are actual temperature values.

This can be worth investigating.

[acmagn]

Thank you for the feedback! 1) Your suspicion is correct and Olen is correct. My batteries never drop below zero (they're partially inside) so I forgot to handle negative values. To expand on Olen's answer, Olen is describing a binary method called Signed Magnitude. The only negative value I can look at is the current, for which they're using Two's Compliment. I think based on the numbers Anto79-ops gave, they're using Two's Compliment again. I'll update this to the temperature reading. I hope that crazy temp reading didn't set off an alarm! 2) Do you have Li-ion batteries? If you don't the SOC readings are definitely going to get messed up. Otherwise, if you could let me know of other weird jumps you notice (general time-stamp would be great), I can refine my method. It will naturally jump around a bit, maybe even for a few days, but should hopefully level-off after a while.

Here are my ideas/research for SOC reading: I think the best method for Li-ion batteries, and the one I believe Renogy is using, is coulomb-counting. But by the nature of taking readings at increments, this will get de-synced. And multiple times I've had my batteries reach full-charge when Renogy's app thought my batteries were only at like 80% (I thought there was something wrong with my solar charger at first). So my solution is: Mostly use coulomb-counting, but auto-correct de-sync with voltage if the voltage-to-SOC reading gets too far from what value the coulomb-counting method is saying. So -- some jumping around will occur, as the code will not know exactly what the battery's SOC is at start: but eventually, only occasional re-syncing should occur. I implemented it simple at first to see if it generally works, but plan on refining it as I see its performance. TLDR: I'm using coulomb-counting + voltage auto-correct for de-syncing.

[Anto79-ops]

Awesome @Olen and @acmagn.

I figure it was the negative value issue because even Renogy got it wrong on the DC home app. I told them about the bug in the DC Home app that when my battery goes below zero, it wouldn't actually report a number but this "---". After 1 to 2 months, they released a fix for the app and as of early Jan 2022, I was able to see negative temperatures in the app. So, i figure this was also the problem here.

As for the SOC, no problem I can even give you the history plots because im logging all the data via Grafana/InfluxDB, so just let let me know when you want the data and I'll send it do you. I have Renogy's 100 amp self-heating LFP battery (RBT100LFP12SH). What it interesting about this battery is when the temperature goes below zero, shuts off charging and diverts the incoming amps (when available) to the internal heater untill the temperature is above 5oC and then it starts to charge (this is extra information).

I'll keep an eye for your temperature update/fix and keep you posted.

Cheers

[Anto79-ops]

Just wondering about another line 91 here and polling for voltage and current.

If I modify this number 9 to increase the number of times it checks for the current, would that work? What number would be OK to check the current value more often?

 elif self.poll_loop_count == 9:
            # Voltage and Current change more often, check these more
            data = self.create_poll_request('VoltageAndCurrent')

with my self-heating battery, what it does every 10 minutes it checks to see if there are enough amps to turn on, so it turns on the heater, and then goes negative amps (-3.7 amps) and then turns off so that the battery is back to 0 amps. However, I noticed that sometimes the current is stuck at -3.7 amps, because that was the last state. Does this have something to do with the polling or how often the battery sends data out?

EDIT: actually, I suspect MQTT refresh page was not set properly, so you can ignore the above.

[acmagn]

Let me know if you want that info on how to have it check current more often. It is somewhere else though. I uploaded some code to handle negative temperatures -- let me know if you have any issues with it.

[Anto79-ops]

Awesome. I've been running the new script since this morning and the temperature issue seems to have corrected itself. My battery was at -6 when I first started the script and the sun came out, heaters turned on and it warmed up to + 11 so no issues there when it crosses 0 degrees Celsius.

SOC is still all over the place I hit 107%, but I'll give it a few more days as you suggested. Just curious on this topic there's no way you can read the batteries SOC output? Like you said the SOC from renogy seems to be pretty good in terms of coulomb counting and some sort of voltage correction. But I wouldn't know what's involved to get this data.

I wouldn't mind knowing actually how you can poll more for current more often.

[Olen]

Hi,

I have now had a a quick look at the PR, and I have just some comments.

What is the main difference between the core "BatteryDevice" class and the "RenogyBatteryDevice" class? If the difference is small, would it be better to just modify the main class, and have it accept a parameter for battery type to accomodate for any minor differences?

The BatteryDevice is a subclass of PowerDevice to have one place to modify certain parameters and default values. Are the parameters for this battery so different from those values, so it justifies a new class?

Also, I think the calculation in the of the negative current:

        if value > 255:
            value = value - 655.34

should be done in the plugin, so all plugins export "human readable" values.

[acmagn]

Hi Olen, Thanks for reviewing it over, your comments make sense. I can probably integrate RenogyBatteryDevice with BatteryDevice. I was being over-cautious with touching other device code because I can't directly test those batteries. And yeah I'll move the negative current calculation, your reasoning makes sense I'll upload these changes next week.

Anto79-ops: I may have time next week to review the bluetooth data and try to find the SOC. I wasn't personally that interested in it, so I didn't try very hard originally. And you can have poll more frequently in solardevice.py -- under def device_poller() line 281. But it's polling about once a second right now, you could end up overwhelming the device. If the current update is greater than 3 seconds, I would say either no update came back or something else happened.

[Anto79-ops]

@acmagn thanks for this information and for trying to determine the SOC broadcast.

Personally, for me, I think the SOC reported by the battery is pretty good. I actually tested this using a battery tester. The video is in the Renogy Community forum (in your DC Home App), its part 3 of the unboxing and review video for the built-in Bluetooth battery.

You mentioned that you had a pretty awful experience with Renogy's SOC number. You can calibrate the batteries SOC meter by fully discharging down to around 10 or 11 V and then charging fully back up to 14.4 (or 14.5 V). Now it knows the min and max and from there, it just uses the coulomb counting to determine the SOC at any time. It’s more complicated then that of course, as I’m over simplifying it, but that is the basic working of it I believe.

I mentioned Modbus before (which is what Renogy uses), here's a document that may help if you get some hex addresses, you can convert it to integers and sniff out everything.

https://github.com/Grmume/renogy-smart-battery/files/8134043/Lithium.Iron.Battery.BMS.Modbus.Protocol.V1.7.zh-CN.en.1.pdf

[Anto79-ops]

One thing I wanted to mention also, which may or may not be related to the script, but I can't seem to keep the BT-2 module connected for more than 24hrs. At first, they both are connected and reporting, then after a while the BT-2 disconnects while the BT-1 continues to report the Rover stats. This could perhaps the Pi is being overwhelmed (but why would the BT-1 stay connected?). Both devices are at the same distance to the Pi about 40 feet but straight line of site through a window. I can't rules our environment or hardware limitations, but is there anything in the script that can affect connectivity to the BT-2? I realize this is not going to be easy to troubleshoot.

[Olen]

I want to add GPL v3.0 LICENSE to this project. Is that OK for you?

[acmagn]

Yeah GPL license sounds great.

Anto79-ops: Would your batteries stay connected to your app? I sometimes had to reconnect there as well. I had to set the reconnect = True in solar-monitor.ini. Since they would disconnect from the app sometimes as well, I assumed it wasn't due to the code.

[Anto79-ops]

Yes, for sure definitely connections to my phone are less than stellar. Constant disconnects and hard time connecting for sure. I always assumed it was my phone and it could very well be my phone.

I'm not sure what the case is here. I believe I have reconnect = true. Just curious what exactly happens in this case? How often does it try to reconnect?

[acmagn]

I think it may be an issue with the BT module. Even when I was manually connected with a bluetooth interface for testing, it would randomly disconnect me. I didn't look too closely at the code's reconnect (was already implemented). Weirdly enough, my battery disconnected without reconnecting for the first time last night. I'll take a closer at the function and have it attempt reconnecting with more determination.

Also that modbus file may be useful, I'll review it and see if I can translate it to the BT calls. Initial glance shows me that the physical addresses don't exactly match to the BT addresses, but it could give me some leads.

[acmagn]

Hey Olen -- I merged the license commit, merged the RenogyBattery class into the Battery class, and moved the negative value handling to the plugin. It should be good to go for your review.

Anto79-ops -- I finally figured out the SOC value (done differently from all the other values, naturally). So you can get it from the soc readings sent out and just ignore the other capacity readings. It appears the value is based on total capacity. If I'm wrong, you'll get weird values, so just let me know.

[Anto79-ops]

@acmagn got it! It's running as we speak. Thank you for the update and your efforts. The reconnect every 10 seconds is exactly what this script was missing thank you for adding that. The soc so far is reporting exactly what the DC home app is saying, and my capacity it also reporting correctly.

I may need to invest another PiZero or perhaps a USB Bluetooth dongle because I couldn't get them both to run the Regulator and battery to run at the same time. At the moment I think distance is really killing me, but right now it's running just a battery script. Keep you all posted. Thanks again @acmagn.

[Olen]

Hi, and thanks for the PR.

I see that you changed some of the "maxdiff"s. Is this because the renogy is reporting more fluctutating values that still are correct?

The maxdiff is just a safety I have when validating the reported data, because I noticed that sometimes the devices are reporting values that - while inside the correct limits - are most probably not correct. E.g. a battery reports SOC = 1000 (e.g. 100%) and then, a second later, it reports SOC = 750 (e.g 75%). This is a highly unlikely change in SOC without any intermediate steps, so I try to catch them as "invalid". Usually, the next reporting is then 1000 again, so it avoids huge spikes of errorneus reports.

If the renogy batteries are reporting a (valid) bigger diff between measurements, I think maybe we should add that inside the init of the BatteryDevice class (or maybe PowerDevice class).

class BatteryDevice(PowerDevice):
  (...)
  def __init__(self, parent=None):
    (...)
    if self.type == 'RenogyBatt':
      self._dsoc['maxdiff'] = 1000 

(I think this should work as the type is part of the parent device. If not, you might need to add "type" as a parameter to the class initialisation)

But other that that, this looks fine to me.

[acmagn]

Thanks for the feedback. I made some adjustments and here are my comments: 1) The SOC change was for testing and I forgot to change it back. 2) The capacity max diff was a bit too small for me -- however I adjusted it to a more reasonable number. If you think the max diff is still too big, I am happy to implement the approach you mentioned. 3) To the original change I made to current max diff: I believe it makes the most sense to keep it very high. It really depends on what you're using your batteries for. I am living off my batteries and will use them to cook. The moment I turn on the electric stovetop my current spikes dramatically.

[Olen]

I'll accept your maxdiffs. If it causes issues for others, we can always make new adjustments.

[Anto79-ops]

You may wish to also update the Readme to now show support for renogy batteries that have built-in Bluetooth and BT-2 modules.

[acmagn]

Sounds good, thank you Olen. And thanks Anto79-ops for your help refining the code.

[Anto79-ops]

@acmagn no problem and thank you!

I managed to solve my connectivity issues (for now at least), I got long range USB Bluetooth dongle for my RPi Zero 2 W and disabled the internal BT antenna...and yes, what a difference it makes. Connectivity it much improved and I can now connect to the BT1 and BT2 modules easily and it stays connected for at least 8 hours to both!

Ok, now I have been able to do this and have it connected just wanted to know if something broke in the code for the Renogy Battery. Using the lastest merged script from Olen's site, all values for the regulator and battery are reporting as normal, except the invididual cell voltages (all 4 of them in my case) are NOT reporting. It worked in a previous version for yours, Also, the capacity number (i.e. 100 in my case) my also not be reporting, however, I have to confirm that still because that rarely changes. But everything else is working (battery temp, voltage, current, SOC, etc) except for the indivdual cell voltages and possibly the capacity number. Just curious if you are experiencing this also?

EDIT: just saw the capcity number being reported, so it is reporting but it seems to be incorrect. Should be 100 but is reporting 65. It was reporting correctly before of 100. By the way, the SOC is reporting perfectly fine!

[Anto79-ops]

Just wanted to provide another update, for those who would like to run this script on a RPi Zero 2W with both the regulator (Renogy Rover, BT-1 module) and Renogy Battery plugin (with the BT-2 module) at the same time and are having connection problems, I highly recommed getting a long-range usb adapter like this:

https://www.lm-technologies.com/product/bluetooth-v4-0-dual-mode-long-range-usb-adapter-lm1010/

After installing this, disable the internal RPi BT. With the LM1010 Its been 3 solid days of pure data streaming with no disconnects (or reconnect attempts). My BT-1 and BT-2 module is about 50 ft away from the RPi which is through a window and behind a television).

@acmagn i'm still not seeing updates for the individual cell voltages using the combined script. Just curious if you've noticed anything like this also.

[acmagn]

@Anto79-ops Glad to hear you've figured out your connection issues. My RPi sits incredibly close (2 feet?) to the batteries so I wasn't having this issue.

I would not trust the capacity data for now, but thank you for the updates on how it's doing.

Regarding the cell voltages: yeah you're right, something stopped working. They update so rarely I didn't notice. I'll look into this and get back to you when I figure it out. I should have some time this week to figure out the issue.

[acmagn]

I fixed the issue, please see new pull request for solution: https://github.com/Olen/solar-monitor/pull/11

[Anto79-ops]

@acmagn thanks so much for your efforts on the latest script!

I'm trying to troubleshoot here, I've been running your new script, for about 8 hrs now, and im still not seeing for the voltage for the cells (but everything else is working just fine!)

I looked for "cell_{i}_voltage" in the mqtt, where i= 1,2,3, or 4, and nothing and it doesn't discover something new with MQTT (with auto-discovery on). and even the script doesn't shoot out lines related to cell voltage.

I was looking back at my history (via Gradana/InfluxDB), but because of my connenivity issues with the BT-2 dropping off after max 24 hrs (which by way, with the new long range BT dongle, I hit 8 days with no disconnects only to try the new script I had to stop it so that is solved!), but anyways, it seems something happened on Mar 14th. Right now, my mqtt is reporting a constant 3.6 V for each cell since Mar 14 (before that, it was a constant 3.3V).

Just to give you an idea, my battery runs loads at night, and voltage goes up and down every day.

Any thoughts as to why it still not reporting cell voltages?

[acmagn]

HI @Anto79-ops, This is a difficult one, cell voltage is reporting consistently for me. I think the only way for me to help you on this one is if you: Change debug = True in solar-monitor.ini , restart the service, wait for lines to pop up like (maybe 2 minutes?): DEBUG "Cell Count: 4" DEBUG "CellmVoltage 0 33 => 330" Then send me these with the preceding maybe 30 lines or so. I can then take a look at any errors coming up or different values coming from your batteries versus mine and see what's going on. Edit: I also highly suggest not leaving debug on with the service running for too long on a raspberry pi. The file gets big real quick.

[Anto79-ops]

Hi @acmagn

some good news, when in debug mode, I clearly see the cell count =4 and each of the cell voltages and they change

Here's what I did: I restarted the service with debug on. My battery was full (14.5V) and 3.6V per cell, so I put a load on the battery and the voltage chaged accordingly for each cell. Below is part of my debug (I wish I just upload the file). One thing I noticed, when the cell voltage changes, I don't see the corresponding info line (i.e. publish to broker), its possible its not sending it to the datalogger/broker? See below, let me know if this snippet helps

2022-04-05 16:08:31,423 INFO    : [renogy_battery_1] Sending new data state: discharging
2022-04-05 16:08:31,424 DEBUG   : Publishing to MQTT 192.168.1.139: solar/renogy_battery_1/state/state = discharging
2022-04-05 16:08:31,425 DEBUG   : MQTT Sending PUBLISH (d0, q0, r1, m122), 'b'solar/renogy_battery_1/state/state'', ... (11 bytes)
2022-04-05 16:08:31,434 DEBUG   : Published to MQTT
2022-04-05 16:08:31,438 DEBUG   : Starting new HTTP connection (1): server:80
2022-04-05 16:08:31,450 DEBUG   : [renogy_battery_1] Could not find state
2022-04-05 16:08:31,451 DEBUG   : [renogy_battery_1] Could not find health
2022-04-05 16:08:31,455 WARNING : [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]
2022-04-05 16:08:31,457 WARNING : [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]
2022-04-05 16:08:31,458 WARNING : [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]
2022-04-05 16:08:31,459 DEBUG   : [renogy_battery_1] Write to characteristic done for: [0000ffd1-0000-1000-8000-00805f9b34fb]
2022-04-05 16:08:31,460 WARNING : [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]
2022-04-05 16:08:31,461 WARNING : [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]
2022-04-05 16:08:31,462 WARNING : [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]
2022-04-05 16:08:31,462 WARNING : [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]
2022-04-05 16:08:31,463 WARNING : [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]
2022-04-05 16:08:31,464 DEBUG   : [renogy_battery_1] Write to characteristic done for: [0000ffd1-0000-1000-8000-00805f9b34fb]
2022-04-05 16:08:31,465 WARNING : [renogy_battery_1] Write to characteristic failed for: [0000ffd1-0000-1000-8000-00805f9b34fb] with error [In Progress]
2022-04-05 16:08:31,466 DEBUG   : [renogy_battery_1] Write to characteristic done for: [0000ffd1-0000-1000-8000-00805f9b34fb]
2022-04-05 16:08:31,466 DEBUG   : [renogy_battery_1] Write to characteristic done for: [0000ffd1-0000-1000-8000-00805f9b34fb]
2022-04-05 16:08:31,468 DEBUG   : [renogy_battery_1] Writing data to 0000ffd1-0000-1000-8000-00805f9b34fb - bytearray(b'main recv da ta[30] [') (6d61696e207>
2022-04-05 16:08:31,470 DEBUG   : CellCount 4
2022-04-05 16:08:31,470 DEBUG   : CellmVoltage 0 36 => 3.6
2022-04-05 16:08:31,471 DEBUG   : CellmVoltage 0 36 => 3.6
2022-04-05 16:08:31,472 DEBUG   : CellmVoltage 0 36 => 3.6
2022-04-05 16:08:31,472 DEBUG   : CellmVoltage 0 36 => 3.6
2022-04-05 16:08:31,474 DEBUG   : [renogy_battery_1] Could not find health
2022-04-05 16:08:31,476 DEBUG   : [renogy_battery_1] Write to characteristic done for: [0000ffd1-0000-1000-8000-00805f9b34fb]
2022-04-05 16:08:31,478 DEBUG   : [renogy_battery_1] Writing data to 0000ffd1-0000-1000-8000-00805f9b34fb - bytearray(b'main recv da ta[30] [') (6d61696e207>
2022-04-05 16:08:31,479 DEBUG   : Voltage 0 144 => 14.4
2022-04-05 16:08:31,480 DEBUG   : Current 254 242 => 652.66
2022-04-05 16:08:31,481 DEBUG   : SOC 1 134 0 => 9984.0. Divided by capacity: 99.84
2022-04-05 16:08:31,481 DEBUG   : [renogy_battery_1] Value of _dsoc changed from 998.4100000000001 to 998.4000000000001
2022-04-05 16:08:31,482 DEBUG   : [renogy_battery_1] Value of _mcurrent changed from -220.00000000002728 to -2680.0000000000637
2022-04-05 16:08:31,483 DEBUG   : Seconds pass is 5.178581
2022-04-05 16:08:31,483 DEBUG   : [renogy_battery_1] Value of _mcapacity changed from 99995.51359930563 to 99991.1441715869
2022-04-05 16:08:31,484 DEBUG   : [renogy_battery_1] Value of _mvoltage out of bands: Changed from 14400.0 to 14400.0 (no diff)
2022-04-05 16:08:31,485 INFO    : [renogy_battery_1] Sending new data current: -2.7
2022-04-05 16:08:31,485 DEBUG   : Publishing to MQTT 192.168.1.139: solar/renogy_battery_1/current/state = -2.7
2022-04-05 16:08:31,486 DEBUG   : MQTT Sending PUBLISH (d0, q0, r1, m123), 'b'solar/renogy_battery_1/current/state'', ... (4 bytes)
2022-04-05 16:08:31,494 DEBUG   : Published to MQTT
2022-04-05 16:08:31,474 DEBUG   : [renogy_battery_1] Could not find health
2022-04-05 16:08:31,476 DEBUG   : [renogy_battery_1] Write to characteristic done for: [0000ffd1-0000-1000-8000-00805f9b34fb]
2022-04-05 16:08:31,478 DEBUG   : [renogy_battery_1] Writing data to 0000ffd1-0000-1000-8000-00805f9b34fb - bytearray(b'main recv da ta[30] [') (6d61696e207>
2022-04-05 16:08:31,479 DEBUG   : Voltage 0 144 => 14.4
2022-04-05 16:08:31,480 DEBUG   : Current 254 242 => 652.66
2022-04-05 16:08:31,481 DEBUG   : SOC 1 134 0 => 9984.0. Divided by capacity: 99.84
2022-04-05 16:08:31,481 DEBUG   : [renogy_battery_1] Value of _dsoc changed from 998.4100000000001 to 998.4000000000001
2022-04-05 16:08:31,482 DEBUG   : [renogy_battery_1] Value of _mcurrent changed from -220.00000000002728 to -2680.0000000000637
2022-04-05 16:08:31,483 DEBUG   : Seconds pass is 5.178581
2022-04-05 16:08:31,483 DEBUG   : [renogy_battery_1] Value of _mcapacity changed from 99995.51359930563 to 99991.1441715869
2022-04-05 16:08:31,484 DEBUG   : [renogy_battery_1] Value of _mvoltage out of bands: Changed from 14400.0 to 14400.0 (no diff)
2022-04-05 16:08:31,485 INFO    : [renogy_battery_1] Sending new data current: -2.7
2022-04-05 16:08:31,485 DEBUG   : Publishing to MQTT 192.168.1.139: solar/renogy_battery_1/current/state = -2.7
2022-04-05 16:08:31,486 DEBUG   : MQTT Sending PUBLISH (d0, q0, r1, m123), 'b'solar/renogy_battery_1/current/state'', ... (4 bytes)
2022-04-05 16:08:31,494 DEBUG   : Published to MQTT
2022-04-05 16:08:31,496 DEBUG   : Starting new HTTP connection (1): server:80
2022-04-05 16:08:31,508 DEBUG   : [renogy_battery_1] Could not find current
2022-04-05 16:08:31,509 INFO    : [renogy_battery_1] Sending new data soc: 99.84
2022-04-05 16:08:31,510 DEBUG   : Publishing to MQTT 192.168.1.139: solar/renogy_battery_1/soc/state = 99.84
2022-04-05 16:08:31,511 DEBUG   : MQTT Sending PUBLISH (d0, q0, r1, m124), 'b'solar/renogy_battery_1/soc/state'', ... (5 bytes)
2022-04-05 16:08:31,513 DEBUG   : Published to MQTT
2022-04-05 16:08:31,521 DEBUG   : Starting new HTTP connection (1): server:80
2022-04-05 16:08:31,532 DEBUG   : [renogy_battery_1] Could not find soc
2022-04-05 16:08:31,533 DEBUG   : [renogy_battery_1] Could not find health
2022-04-05 16:08:31,535 DEBUG   : [renogy_battery_1] Write to characteristic done for: [0000ffd1-0000-1000-8000-00805f9b34fb]
2022-04-05 16:08:31,537 DEBUG   : [renogy_battery_1] Writing data to 0000ffd1-0000-1000-8000-00805f9b34fb - bytearray(b'main recv da ta[30] [') (6d61696e207>
2022-04-05 16:08:31,539 DEBUG   : TemperatureCount 3
2022-04-05 16:08:31,540 DEBUG   : Temperature 0 90 => 9.0
2022-04-05 16:08:31,541 DEBUG   : [renogy_battery_1] Value of _dkelvin out of bands: Changed from 2821.0 to 2821.0 (no diff)
2022-04-05 16:08:31,541 DEBUG   : [renogy_battery_1] Value of _bkelvin out of bands: Changed from 2821.0 to 2821.0 (no diff)
2022-04-05 16:08:31,542 DEBUG   : Temperature 0 90 => 9.0
2022-04-05 16:08:31,543 DEBUG   : [renogy_battery_1] Value of _dkelvin out of bands: Changed from 2821.0 to 2821.0 (no diff)
2022-04-05 16:08:31,543 DEBUG   : [renogy_battery_1] Value of _bkelvin out of bands: Changed from 2821.0 to 2821.0 (no diff)
2022-04-05 16:08:31,544 DEBUG   : Temperature 0 90 => 9.0
2022-04-05 16:08:31,544 DEBUG   : [renogy_battery_1] Value of _dkelvin out of bands: Changed from 2821.0 to 2821.0 (no diff)
2022-04-05 16:08:31,545 DEBUG   : [renogy_battery_1] Value of _bkelvin out of bands: Changed from 2821.0 to 2821.0 (no diff)
2022-04-05 16:08:31,546 DEBUG   : [renogy_battery_1] Could not find health
2022-04-05 16:08:37,588 DEBUG   : SOC 1 133 247 => 9983.1. Divided by capacity: 99.831
2022-04-05 16:08:37,589 DEBUG   : [renogy_battery_1] Value of _dsoc changed from 998.32 to 998.3100000000001
2022-04-05 16:08:37,591 DEBUG   : [renogy_battery_1] Value of _mcurrent changed from -1370.0000000000045 to -1180.0000000000637
2022-04-05 16:08:37,592 DEBUG   : Seconds pass is 0.168039
2022-04-05 16:08:37,593 DEBUG   : [renogy_battery_1] Value of _mcapacity changed from 99989.61095897887 to 99989.54838195542
2022-04-05 16:08:37,594 DEBUG   : [renogy_battery_1] Value of _mvoltage out of bands: Changed from 14300.0 to 14300.0 (no diff)
2022-04-05 16:08:37,596 INFO    : [renogy_battery_1] Sending new data current: -1.2
2022-04-05 16:08:37,597 DEBUG   : Publishing to MQTT 192.168.1.139: solar/renogy_battery_1/current/state = -1.2
2022-04-05 16:08:37,598 DEBUG   : MQTT Sending PUBLISH (d0, q0, r1, m141), 'b'solar/renogy_battery_1/current/state'', ... (4 bytes)
2022-04-05 16:08:37,607 DEBUG   : Published to MQTT
2022-04-05 16:08:37,610 DEBUG   : Starting new HTTP connection (1): server:80
2022-04-05 16:08:37,666 DEBUG   : [renogy_battery_1] Could not find current
2022-04-05 16:08:37,668 INFO    : [renogy_battery_1] Sending new data soc: 99.831
2022-04-05 16:08:37,669 DEBUG   : Publishing to MQTT 192.168.1.139: solar/renogy_battery_1/soc/state = 99.831
2022-04-05 16:08:37,670 DEBUG   : MQTT Sending PUBLISH (d0, q0, r1, m142), 'b'solar/renogy_battery_1/soc/state'', ... (6 bytes)
2022-04-05 16:08:37,679 DEBUG   : Starting new HTTP connection (1): server:80
2022-04-05 16:08:37,681 DEBUG   : Published to MQTT
2022-04-05 16:08:37,738 DEBUG   : [renogy_battery_1] Could not find soc
2022-04-05 16:08:37,739 DEBUG   : [renogy_battery_1] Could not find health
2022-04-05 16:08:37,742 DEBUG   : [renogy_battery_1] Write to characteristic done for: [0000ffd1-0000-1000-8000-00805f9b34fb]
2022-04-05 16:08:37,743 DEBUG   : [renogy_battery_1] Writing data to 0000ffd1-0000-1000-8000-00805f9b34fb - bytearray(b'main recv da ta[30] [') (6d61696e207>
2022-04-05 16:08:37,745 DEBUG   : CellCount 4
2022-04-05 16:08:37,746 DEBUG   : CellmVoltage 0 35 => 3.5
2022-04-05 16:08:37,746 DEBUG   : CellmVoltage 0 35 => 3.5
2022-04-05 16:08:37,747 DEBUG   : CellmVoltage 0 35 => 3.5
2022-04-05 16:08:37,748 DEBUG   : CellmVoltage 0 35 => 3.5
2022-04-05 16:08:37,749 DEBUG   : [renogy_battery_1] Could not find health
2022-04-05 16:08:37,752 DEBUG   : [renogy_battery_1] Write to characteristic done for: [0000ffd1-0000-1000-8000-00805f9b34fb]
2022-04-05 16:08:37,753 DEBUG   : [renogy_battery_1] Writing data to 0000ffd1-0000-1000-8000-00805f9b34fb - bytearray(b'main recv da ta[30] [') (6d61696e207>
2022-04-05 16:08:37,755 DEBUG   : Voltage 0 143 => 14.3
2022-04-05 16:08:37,755 DEBUG   : Current 255 150 => 654.3000000000001
2022-04-05 16:08:37,756 DEBUG   : SOC 1 133 246 => 9983.0. Divided by capacity: 99.83
2022-04-05 16:08:37,757 DEBUG   : [renogy_battery_1] Value of _dsoc changed from 998.3100000000001 to 998.3
2022-04-05 16:08:37,758 DEBUG   : [renogy_battery_1] Value of _mcurrent changed from -1180.0000000000637 to -1039.9999999999636
2022-04-05 16:08:37,758 DEBUG   : Seconds pass is 0.16665
2022-04-05 16:08:37,759 DEBUG   : [renogy_battery_1] Value of _mcapacity changed from 99989.54838195542 to 99989.49666548407
2022-04-05 16:08:37,760 DEBUG   : [renogy_battery_1] Value of _mvoltage out of bands: Changed from 14300.0 to 14300.0 (no diff)
2022-04-05 16:08:37,761 INFO    : [renogy_battery_1] Sending new data current: -1.0
2022-04-05 16:08:37,761 DEBUG   : Publishing to MQTT 192.168.1.139: solar/renogy_battery_1/current/state = -1.0