SMA Solar PV Inverters - monitoring over bluetooth

whitecitadel · 2017-08-31T09:35:05.732Z

Thanks @Robert.Wall, using a value of 1.1 for the multiplier on Power2 (solar clamp) of the emonpi has got me within ~10w of the solar generation reading between the clamp and the inverter.

Currently I am putting out ~4600w so I will need to check again late afternoon when production ramps down to see if the value is correct still at lower generation levels.

I am now wondering if I should apply the same correction anywhere else… currently my water is hot so I am not matching immersion to export, that uses a clamp separate to the OEM setup and would be a good check measurement. Due to the way my incoming feed is split to garage and CU my current total consumption is a sum not a measurement at the meter tail.

If there was a cheaper emontx available I would add some more monitoring points

Robert.Wall · 2017-08-31T12:22:29.276Z

whitecitadel:

I am now wondering if I should apply the same correction anywhere else

Not necessarily. The error comes from a combination of sources, only two of which (the supply voltage, also the reference for the measurements, used twice as it happens - once for voltage and once for current, and the line voltage measurement) are common to all 4 power inputs. So if those are the only source of the error, then 1.1 across the board would be right. But they probably aren’t all of the error, so it’s a case of correcting each input separately. (There’s an article in ‘Learn’ about the errors that are possible.)

whitecitadel · 2017-08-31T13:50:09.609Z

Many thanks, I still have my voltage discrepancy on the emonpi, where it suddenly started to read 10v under at 220v when the emontx reads 230v (old thread on this: Change to Voltage Measurements?) but from the start I was never seeing power output over 4500W which did not seem right as the inverter is rated to 5kW and there is 5.7kWp of panels so I should be over 4500W at peak mid-day output.

Looking on multigraph the clamp and the inverter are tracking very closely now, I will see how it goes once production drops to lower numbers and if the inverter kWh/day gets closer to OEM kWh. If I remember I will have to see what the FIT meter compares in a day to the numbers as well.

Robert.Wall · 2017-08-31T14:59:28.529Z

The emon part of the emonPi is all but identical to an emonTx, so it suffers exactly the same set of inaccuracies, and should be calibrated in exactly the same way.

Obvious point: once calibrated, keep the a.c. adapters and c.t’s with their respective inputs, because they are part of the analogue signal processing chain.

Lykke · 2017-12-03T16:55:04.378Z

Peter - did you get this to work? I’m also struggling with a Pi3 and my Linux skills are not exactly stellar

andrewhf01 · 2018-01-10T15:48:45.612Z

Hi Stuart,
I have just connected to my SMA inverter (downloading data every 10s) using your SMA inverter monitoring code/ EmonHub, works perfectly, excellent job.

Just one question, does it continue to access the SMA inverter at the set timeinverval parameter in the EmonHub config file for the whole 24 hours? Would it be possible to increase this ‘automatically’ after sunset similar to that of the BMW Connected Drive Interface, which increases the time interval when not in charge mode?

Many thanks,
Andrew

stuart · 2018-01-10T18:33:34.142Z

Hello @andrewhf01

At the moment the code doesn’t support switching off or reducing sampling time overnight. It would be fairly easy to implement however I’ve not found any issue with 24x7 monitoring - it doesn’t occupy any additional disk space on the emonPI as that still has to record the “blanks” overnight.

Robert.Wall · 2018-01-10T20:02:27.434Z

I think you mean there either: “As it is, it doesn’t occupy any additional disk space…” or “it won’t occupy any less disk space…”

andrewhf01 · 2018-01-10T22:05:17.859Z

Fair comment and I accept that point, changing the the sample frequency will not affect disk space nevertheless being able to change the logging data frequency will. During the day logging a power feed for example, at 10s is good (and is given as a suggested logging frequency in the guide for ‘log locally’) but during the hours of no sunlight logging a zero takes up disk space - see attached a zero logged every 10s for approx 6hrs is 8.6KB of disk space and just once in 6 hrs 9B. Both will give the same appearance when a graphed over time.

Is there a method for reducing the logging frequency of PV systems at night and then increasing it during daylight hours?

pb66 · 2018-01-10T23:02:10.213Z

A phpfina (fixed interval) feed uses 4bytes per datapoint day and night, at a 10s interval that’s 34560bytes per day. The phptimeseries (variable interval) uses 9bytes for each datapoint only as required, therefore only on days with less than 10.67hrs daylight would the storage be reduced. Over the duration of a year, I doubt there would be much difference. IMO it would not justify the extra complexity.

Additionally as the sampling would still need to happen for the data to be made available to drive the logic and make a decision over whether it was daylight or not, even at a reduced sample rate, would that “out of hours” data be recorded too? And if you decrease the sample rate too much to reduce disc usage, could you end up missing the initial daylight? An alternative would be to continuously sample at 10s and only save the data during daylight hours, probably controlled by the input from another source eg the meteorological office or weatherunderground etc.

MichaelMuir · 2018-04-07T01:34:39.954Z

Hello everyone, firstly a big thank you to @stuart for developing this as I’ve been able to successfully integrate my PV system into my Home Assistant automation using MQTT. This meant that I could achieve this with $60 worth of hardware instead of having to spend hundreds on the WebConnect module.

Having read this whole discussion I have identified that I am suffering from the problem reported by @Steve in March 2017 as I too have discovered using the Oxley Solar app that I’m missing the DC power data from one of my 5000TL-21’s arrays. I run a single 5000TL-21 inverter and can only see the contents of one DC string.

@MikeC also describes this behavior and stuart’s recommendation was to modify lines 420 onwards but when I do so I get the following error message:

2018-04-06 17:49:35,791 ERROR SMASolar [‘Traceback (most recent call last):\n’, ’ File “/home/pi/data/sma_emonhub/emonhub/src/interfacers/EmonHubSMASolarInterfacer.py”, line 252, in read\n output.update(SMASolar_library.extract_data(data))\n’, ’ File “/home/pi/data/sma_emonhub/emonhub/src/smalibrary/SMASolar_library.py”, line 422, in extract_data\n outputlist[“DCVoltage1”] = SpotValueOutput(“DCVoltage1”.format(readingtype), toVolt(value))\n’, “NameError: global name ‘toVolt’ is not defined\n”]

Is anyone able to assist me with getting both DC strings to output?

stuart · 2018-04-16T11:58:30.676Z

MichaelMuir:

Oxley Solar app

Interesting bit of software that - it looks like a clone of my code and other open sources but then wrapped in a commercial app with no reference to the open source or my code

whitecitadel · 2018-07-27T07:32:01.786Z

@stuart have there been any code changes in recent releases?

I had this working perfectly, I took it out of the config (commented out emonhub.conf) but now its so hot I was curious just how hot the inverter is as its de-rating a peak times because of the heat.

When I added it back to emonhub.conf I do not get the feed, and the emonhb.log shows:

2018-07-27 08:12:43,123 INFO SMASolar Log into the SMA solar inverter 00:80:25:32:17:22
2018-07-27 08:12:43,124 INFO SMASolar Opening bluetooth address 00:80:25:32:17:22
2018-07-27 08:12:44,293 DEBUG SMASolar initaliseSMAConnection
2018-07-27 08:12:44,476 DEBUG SMASolar packet count = 0101
2018-07-27 08:12:44,477 DEBUG SMASolar packet count = 0102
2018-07-27 08:12:44,477 DEBUG SMASolar logon
2018-07-27 08:12:44,579 DEBUG SMASolar packet count = 0103
2018-07-27 08:12:44,668 DEBUG SMASolar packet count = 0104
2018-07-27 08:12:44,669 DEBUG SMASolar {‘inverterName’: u’SB 5000TL-21 1’, ‘serialNumber’: xxxxx, ‘ClassName’: ‘SolarInverter’, ‘TypeName’: ‘SB 5000TL-21’, ‘susyid’: 138L, ‘Type’: 9076L, ‘Class’: 8001L}
2018-07-27 08:12:44,670 ERROR SMASolar global name ‘re’ is not defined
2018-07-27 08:12:44,671 ERROR SMASolar [‘Traceback (most recent call last):\n’, ’ File “/home/pi/emonhub/src/interfacers/EmonHubSMASolarInterfacer.py”, line 203, in read\n self._login_inverter()\n’, ’ File “/home/pi/emonhub/src/interfacers/EmonHubSMASolarInterfacer.py”, line 98, in _login_inverter\n dictInverterData[“inverterName”] = re.sub(r'[^a-zA-Z0-9]','', dictInverterData[“inverterName”])\n’, “NameError: global name ‘re’ is not defined\n”]

It looks like this line tries the inverter login:

       # Check we have a connection already, if not try and obtain one
       if self._btSocket is None:
          self._login_inverter() <--Line 203

And Line 98 is where the variable is called:

   #Clear rogue characters from name
   dictInverterData["inverterName"] = re.sub(r'[^a-zA-Z0-9]','', dictInverterData["inverterName"])

Is it really an undefined variable? Did some other perl library change?

Bluetooth is working and it can see the inverter:

$ hcitool scan
Scanning …
00:80:25:32:17:22 SMA002d SB 5000TL-21 175 SNxxxx

Nothing changed with the emonpi platform recently:

$ uptime
08:27:31 up 199 days, 9:18, 1 user, load average: 0.07, 0.50, 0.55

I can see that the code looks to have been updated in May though:

pi@emonpi:~/emonhub/src/interfacers $ ls -al EmonHubSMASolarInterfacer.py
-rw-r–r-- 1 pi pi 11532 May 13 18:21 EmonHubSMASolarInterfacer.py

I tried to look in EmonCMS on github but I can’t find the /src tree in the main repository https://github.com/emoncms/emoncms?

Bit stumped why this stopped working…

EDIT:
Ok I see now where the source is on github:
https://github.com/openenergymonitor/emonhub/blob/emon-pi/src/interfacers/EmonHubSMASolarInterfacer.py

I don’t see any changes in the last 6 months apart from an update from Trystan to use an updated interface standard. Hmm.

stuart · 2018-07-27T08:40:59.995Z

Hi @whitecitadel

I’ve not changed the code since 28 Mar 2017 - however looking at the line its failing on its trying to use “re” - regular expression. Perhaps the Python engine has changed/upgraded?

Try removing/comment out

  #Clear rogue characters from name
        dictInverterData["inverterName"] = re.sub(r'[^a-zA-Z0-9]','', dictInverterData["inverterName"])

stuart · 2018-07-27T08:46:43.232Z

whitecitadel:

global name ‘re’ is not defined

Actually, just try adding

import re

to the top of the file near the other imports

whitecitadel · 2018-07-27T09:43:29.158Z

Thanks Stuart, I was looking at this first thing then work got in the way, but some googling while on a conference call showed others have the same problem:
https://github.com/ranger/ranger/issues/823

Talks about changes to commands.py - just curious something has changed as the emonpi is on private subnet so I don’t worry too much about OS updates and only Emonhub has been updated.

I added “import re” below the import for traceback, and that’s fixed it.

The only problem now is that I can see the Inverter is 55.4c and its been cloudy on and off this morning!

stuart · 2018-07-27T09:44:36.722Z

whitecitadel:

The only problem now is that I can see the Inverter is 55.4c and its been cloudy on and off this morning!

Don’t worry, mine is also sitting at 55c although it has been over 80c in the last few weeks !!!

Mine is a transformer less model (3000HF) so doesn’t de-rate in the hot weather.

whitecitadel · 2018-07-27T09:45:47.779Z

Yes I can see de-rate to “only” 4000w on the sunniest days… hate to think how hot it was then!

Seriously considering a velux in the loft space for venting next summer if the global warming is here to stay!

stuart · 2018-07-27T11:07:56.276Z

whitecitadel:

EmonHubSMASolarInterfacer.py

I’ve just done an emoncms update and its broken mine as well - same problem!

I’ll raise a bug

whitecitadel · 2018-07-27T13:55:47.573Z

Thanks - Glad it was not just me!