L1/L2/L3 current returned to grid

[AMajland]

Spring is around the corner and then it will be time to look at the automation for charging the electrical cars when there is surplus energy.

The integration proveides the returned power but it would be easier to use the returned current if it can be read from the echelon. Otherwise i'll have to calculate it from power and voltage.

I plan on adjustning the dynamic_charge_limit on my easee home charger on a timer with the surplus current. Something along the line of

If (sensor.echelon_l1_current_returned >0){ currentP1 +=sensor.echelon_l1_current_returned;}
else if (sensor.echelon_l1_current>0) { currentP1 +=sensor.echelon_l1_current;}

or maybe also including the actual current state_inCurrentT so i just set the max to the current current plus the export (so i won't continue to inccrease the limit on phase if it is one of the others that are actually limiting it,

If the echelon does not provide the data i will have to make an automation that just look at the from grid without knowing how much is exported to the grid.

Or would it be better to wait for the upgraded MEP interface with MQTT ?

[glynge]

We don't expect to discontinue the webservice as we use it for our own dashboard. We might add stuff to it, but will try to keep it backwards compatible for now (or create an alternative one, and mark the existing one to me removed later on).
So I guess it is up to the automation you create if MQTT is easier than consuming a webservice?

I've not looked extensively to see if the meter can be asked about reversed current - but I didn't see it when I took a quick look at it - so I don't think so. But the documentation is freely available to look at for everyone (at the OSGP Alliance GitHub - hint, hint :-) ).

I've not studied what the power factor is and if we can do a simple calculation to calculate the mA from the watt, voltage and power factor...
And I guess I can argue that the module was designed to create an interface to the meter data, not create new data based on calculating on meter data... That could simple be done by the consumers of the meter data...
...on the other hand, if I get time to look into it - or someone can read up on it and explain it to me (hint, hint :-) ), I guess we can just as well implement it (if it is at all possible to calculate these figures? I have not looked into it, so I currently have no clue about that :-) ).

Note: I can easily add the Power factor data the existing webservice if you need it?

[AMajland]

I agree that there is no need to for the module to create new data.

That can be done downstream (i.e in homeassistant for me).

The power factor is not that important either for me. The regulation of the ev charger will only be a "ballpark figure" anyway since the pv production and the house other consumption fluctuate much faster than i will be able to adjust the charger since it has to go trough the servers.

[AMajland]

The nex time the sun is out i'l keep an eye out for the whether the RMS current sensors in the 0x30 Full Table Read are with signs - can't see that in the documentation but they are the only RMS currents listed (new meters have averages as well)

Currently i'm just using a lot ....
RMS Current (mA) L1: 4250
RMS Current (mA) L2: 2665
RMS Current (mA) L3: 2997

[glynge]

Hi @AMajland

Thanks :-)

[AMajland]

There was not much sun today either and i did'nt get to look at the raw data in the module live but here is first graphs thath shows current and power and one with returned power (did'nt look good in the same graph)

[AMajland]

Raw response
00 e7 00 00 dc 00 00 00 00 77 05 00 00 00 00 00 00 df 02 00 00 34 0d 00 00 6c 0c 00 00 a7 0e 00 00 3c 5c 03 00 b0 63 03 00 dc 5e 03 00 6f fd ff ff 50 c3 00 00 e6 08 00 00 3a fc ff ff 99 fc ff ff 14 fe ff ff 85 ff ff ff 7b fe ff ff 00 00 00 00 77 05 00 00 00 00 00 00 df 02 00 00 00 00 00 00 00 00 00 00 df 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4b 01 00 00 02 02 00 00 2a 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4b 01 00 00 02 02 00 00 2a 02 00 00 5a 0d 00 00 84 0c 00 00 a2 0e 00 00 8f 5c 03 00 5b 63 03 00 bf 5e 03 00 0f 5e 03 00 2f 65 03 00 0b 61 03 00 00 00 00 00 77 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4b 01 00 00 02 02 00 00 2a 02 00 00 ff 43 dd c2 3b 92 e7 92
shown as

and

So the "Forward RMS mili Amp" is showing abs current - right now it is flowing in reverse direction

[AMajland]

On the above there seems to update timing difference for L1 - This is closer together

But looks like the sign on the power factor can be used to see the direcetion of the current

[AMajland]

Just turned on the some power consumption and got this

Where there forward consumption on L1 and reverse on L2 and L3

So now i think i understand what i see - but i'm not sure that the sign on the power factor will always be like this. Normally the sign will also shift between capacative or inductive loads.

I think that In the wep interface of the module the text "Forward" should be omitted in.
Forward RMS mili Amp.
Forward RMS mili Volt
Forward mili Hz

In the HA integration the description with division between consumption and returned to grid sensors cold be changed to something like.

Meter sensors

Consumption (Forward)

• Energy consumption [kWh] (same value as in the display)
• Power [W] (total, all phases)
• L1 power [W]
• L2 power [W]
• L3 power [W]

Returned to grid (Reverse):

• Energy returned [kWh]
• Power returned (all phases) [W]
• L1 power returned [W]
• L2 power returned [W]
• L3 power returned [W]

Other:

• L1 current [A]
• L2 current [A]
• L3 current [A]
• L1 voltage [V]
• L2 voltage [V]
• L3 voltage [V]
• Frequency [Hz]

and it would be nice to have the power factor added to the web interface anyway. It would be cleaner to look at the sign of that one to determine the direction of the current than user the power and power/returned

[glynge]

Hi @AMajland
I agree on your findings (removing "forward" from A, V and Frequency as it makes no sense at all + adding the powerfactor for completeness)
I think I was far too creative when putting the headlines on the Dashboard page. Sorry about that.
I think the webservice naming is correct (which is a good thing as it is a potentially breaking change), but I also need to check that forward didn't sneak its way into the source code variable names as well :-).
Hopefully I'll soon be able to go into software mode again :-).

[jnxxx]

Hi @AMajland,

Good suggestion. I will update the description in the readme file so sensors are split into these three groups.

I welcome additional attributes in the webservice. And as @glynge also writes, I prefer to keep the existing ones as is to avoid compatibility issues.

For a quick and easy way to determine direction, have you considered creating a template sensor?
For example like this:

template:
  - sensor:
      - name: "Echelon combined total power"
        unit_of_measurement: "W"
        device_class: power
        icon: mdi:flash
        state: >
            {{ states('sensor.echelon_power') | int(0) - states('sensor.echelon_power_returned') | int(0)  }}

I do not have solar cells, so I cannot test it fully. But I think it will show power as positive when you are consuming and negative when you return to the grid.
The example is total for all three phases, but you could similarly make one for each phase.

[AMajland]

Yes considered something like that and even trough i will be adjusting the ev charging based on the indiviusual phases (the lowest surplus set the bar for minimizing buying or the highest for optimizing direct selfconsumtion)

But the combined power can show a nice graph og the balance

I'll probably based on sensors like
'- sensor:
- name: "Echelon L1 current returned"
unit_of_measurement: "A"
icon: mdi:flash
state: >
{{ states('sensor.echelon_l1_power_returned ') | float(0) / states('sensor.echelon_l1_voltage') | float(0) }} `
even trogh it does take the phase (power factor) into account

[AMajland]

Or just include condtions in the automation to use sensor.echelon_l1_power_returned as a conditions for setting the charge current based on sensor.echelon_l1_current or otherwise set it so 0.0

The possibilities are endless when you do it yourself

If i get the meter replaces to one with the summation principle i'll end up having to match the total power anyway and switching the charger from 1 to 3 phases. I.e charge on 1 phase when 1.4kW/ 6A is availabe and switch to 3 phases when i exceed 3.7kW/16A for 4.1kW/6A (I'm not sure if i can have it charge on two faces by setting L3 to zero while allowing i.e 8A on L1/L2 for 3.7W

But i need some sun for testing - not so fun buying the electricy for playing in the middle of the day when it is most often cheaper at night (and i also need the car home :-) )

[AMajland]

Just followed up with the meter company on a email thread from 2019.if I get the meter replaced I will not get a nes/echelon with the mep interface but a Landis+Gyr with something else. ( The correspondence in 2019 was about getting something else than the nes/echelon with an open interface - at that time it was not an option as they only supported the nes/echelon in my area even through they were using Kamstrup in other areas)

[glynge]

As I understand it their concentrators in a given area need to be compatible with the meters - otherwise they cannot collect and read consumption from the meters. I'm not 100% sure, it is just how it was explained to me.
So normally you will have the same (or a limited number of) different meters in a given area (below a concentrator), but in the neighbor area they might use another concentrator and then support a different brand or a different few brands...
I believe smart meters have a limited life (some even have a built in battery). And I think you are right about some of the power companies preferring Landis+Gyr at the moment, but that can changes depending on the deals they get for new hardware etc.

[jnxxx]

Now that we can read the NES/Echelon meter let's hope we can keep this one for a long time.
My Kamstrup water meter and district-heating meter use batteries. But I think it is to make the installation easier, and it is still expected to last for many years.
A power meter has power readily available, so I suspect it is not operating on a battery. But just a guess.

In any case, if it just has an open interface, either unencrypted or with the key available...
My Kamstrup meters both use Wireless M-Bus. But because the encryption key effectively cannot be changed utility companies often do not want to give you the key.
I got it for my water meter, but not for the district-heating meter 😒