@plonkster I want to pick your brains a bit here.

My system is set to grow in 5kVA steps,by adding parallel Quattro's.

I also want to take opportunistic advantage of other roof space that may be in smaller blocks, mixing and matching Fronius inverters.

I know there is an overall 1:1 relationship, but because of the smaller and irregular blocks of roof space available, I am considering using a combination of smaller Fronius inverters.

My questions relate to this scenario.

I recall in a past thread, you indicated that a Venus would max out on the number PV inverters at 4? but this was being worked on.

So, the first question is, is there any progress on that front?

Secondly, you indicated in the same thread that this could be overcome by grouping all PV inverters through one meter. Geography precludes me doing this to all PV inverters in my eventual plan.

My next question is ESS design related, do I have the freedom to deploy meters throughout the system at my discretion, could I for instance combine two fronius inverters and still have a third on another meter and maybe one without a meter.  Could I meter whatever I want and assign it  a function and even define that it is additive or subtractive to the power flow of a certain point the system? Or is the ESS such the meter points are prescribed and inflexible?

Thanks

 

2 hours ago, phil.g00 said:

I recall in a past thread, you indicated that a Venus would max out on the number PV inverters at 4? but this was being worked on.

It's more of a problem on the Color Control, which has a much slower processor, only a single core, and DDR2 RAM that is not on-chip as in some other designs. On the Venus-GX (based on beaglebone black) it is already faster, and ironically the Raspberry Pi 3 is by far the fastest supported board (4 cores at 1.2Ghz)! When I said you are pretty much limited to a number somewhere below 10 it was in the context of the CCGX. Also, it is worse for 3-phase.

Let me get into a bit more detail: Venus uses what might be considered the defacto standard for IPC (inter-process communication), a system called dbus. Everything is event-driven: When a value changes a signal is sent to any process that's subscribed to it with the new information. This saves time and resources in querying for information. But moving all those messages between processes causes some CPU load. Processes that publish information related to power (such as the Fronius process) have to publish this information relatively often (because it is used for zero-feedin control) and therefore creates a LOT of load. Obviously it is three times worse for 3-phase.

Further, the default overview screen (with the little balls moving between blocks) uses quite a bit of CPU too. The way it renders requires updating large parts of screen real estate, and this device has no accelerated graphics. In other words, you can often get it to perform better by using the Tiled overview, or even better, just leaving it on the device list screen.

So long story short, it simply runs out of steam around 4 PV-inverters, especially if its 3-phase. This number is not exact... it's a bit of a thumbsuck. It will be better on the Venus-GX< but I don't know by how much.

It is being worked on, mostly be trying to reduce the amount of data sent across dbus. Trouble is... you have to send Power values relatively often. And that has an effect on the entire system, because every time you send such an event, the rest of the system calculates the total values (displayed on the screen) and these aggregated values are sent in another event, and then the balls-view updates and repaints, causing more CPU on top of that. So it is a bit of a snowball effect and simply reducing traffic is not doing it.

3 hours ago, phil.g00 said:

So, the first question is, is there any progress on that front?

Very little. Some traffic has been reduced in v2.30.

3 hours ago, phil.g00 said:

Secondly, you indicated in the same thread that this could be overcome by grouping all PV inverters through one meter. Geography precludes me doing this to all PV inverters in my eventual plan.

Correct. A grid meter can be configured to appear as a PV-inverter. By connecting all your PV-inverters through a central point connected to such a meter, you can make them appear as one. But then zero-feedin doesn't work.

3 hours ago, phil.g00 said:

Or is the ESS such the meter points are prescribed and inflexible?

That one... :-)

Interesting, second person to ask my this question today.

If you look here, around June 21, that's when some things got removed from dbus. An experiment to publish other non-Power values less often didn't yield enough of an improvement... the trouble is the power values.

@plonkster, Firstly thanks.

I take from what you say that the meter on the in-feed is equally as hungry on resources. It'll be reporting in equally as often.

Although the system is 1 phase, I may want use a 3 phase meter for Zero feed-in. (L1+L2+L3=0). I see this is an option in the documentation.

This depends on how my grid meter behaves, I still have to test things. But, a 3ph meter will be a heavy draw on resources. That's the bad news.

So the good news is I have a Venus (as yet un-commissioned), but it has a slightly better processor and no screen to deal with. 

It appears as if only the Fronius units reported a larger step change in output at the send end, the traffic would slow down.

Or maybe if the system only recalculated everything when the change exceeded |x| value from the value that triggered the last calculation.

I may have to look into this Pi solution if I run aground.

 

1 minute ago, phil.g00 said:

I take from what you say that the meter on the in-feed is equally as hungry on resources. It'll be reporting in equally as often.

Strangely enough... not. The meter samples every 500ms (ET340) and the modbus registers updates maybe once a second (in other words these meters are actually quite slow), and then there is the comms delays, so energy meters tend to fluctuate less and therefore causes less load.

3 minutes ago, phil.g00 said:

I may want use a 3 phase meter for Zero feed-in

It only creates traffic when a value CHANGES. With L2 and L3 permanently at zero, it won't create any comms load. This also means that systems with multiple very big PV-inverters (where the energy counters also update fairly often, because it generates 0.1kwh literally every couple of seconds) are even worse.

5 minutes ago, plonkster said:

With L2 and L3 permanently at zero, it won't create any comms load

It is good to know that a meter is less traffic, but L2 and L3 wont be at zero. I want to test my grid meter but the ideal situation is if backfeed on L1, offsets in feeds on L2 & L3. 

@plonkster I've been reading through past threads.

It seems as if at one time you fancied Eastron SDM meter as the CG alternative.

I am not knowledgeable about the Modbus protocol, but I suppose its not as simple as changing the Eastron meter's slave address to designated CG meter address and baud rate.

Is it worthwhile pursuing, or would one have to remap all the relevant dbus addresses?

I suppose it would too much to expect it all slotted into place.

 

 

Stop press:

https://github.com/swissembedded/em/tree/master/basicapps/eastronlib

If I didn't know any better that meter seems to be supported.

Aagh, no it's supported by someone else.

2 hours ago, phil.g00 said:

I am not knowledgeable about the Modbus protocol, but I suppose its not as simple as changing the Eastron meter's slave address to designated CG meter address and baud rate.

Carlo Gavazzi's own meters doesn't even have the same register mapping... I'd be very surprised if the Eastron matches any of it. At least the register that shows the meter model is the same... so one can detect what kind of meter you have and adapt.

Modbus is really just a serial way of saying "please read address 0x1002" and then it sends back a 16-bit value. 32-bit values are handled by reading two consecutive 16-bit values. If you know what value is at what address, you can read the thing.

Here is an example of the kind of information you need. This is just the top half of the registers for the EM24:

And the important register for finding out what kind of meter. Thankfully all their meters (ET112, ET340, EM24) uses 0xBH, so this bit is easy.

So to support another meter... if it uses 0xBH for identification... then it is easy. If not... well then it gets a bit more hairy and it might be easier to smack together something in python (CCGX already has python-modbus on it) to read that meter.

In my best Tom Cruise voice:

You had me at "0xBH".

I don't know, its got a table similar to your first one in the manual if that means anything.

I attach a bit of it.

I can't see a table like your second one though.  It may or may not be possible to write a physical address to the meter.

You could read 0x40043, maybe there is something in the serial number that identifies it (starts with XX for example). That's about the only thing that might work.

On the CCGX there is a "driver model" that has to auto-detect the device they support, or terminate if not. And the system simply calls all RS485 "drivers" until one of them accepts the device. So for seamless operation, it must be possible to detect the device through some or other means.

OK, I just want get my head around this.

You are saying if there is an address/attribute that uniquely identifies the meter as this meter,  then Venus would know what it was and be able to talk to it.

I see you can set a 4 digit password, as one the addresses. How about Victron designated password ?   Too messy?

 

40 minutes ago, phil.g00 said:

You are saying if there is an address/attribute that uniquely identifies the meter as this meter,  then Venus would know what it was and be able to talk to it.

I'm saying that if there is a way to identify it, then it would be possible to write a driver (currently none exists) that would fit into the driver philosophy used on the CCGX, and it could auto-detect the meter.

Without a way to identify it... it can still work... but a human being will have to install and configure the driver. In other words the human being does the identification. And it will never be supported "out of the box".

Ok, I've written to Eastron to tell them to pull finger, the Gavazzi boys have market monopoly.